Method and apparatus for mobility between terrestrial and non-terrestrial networks

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. There is disclosed a first method, for a User Equipment (UE), for mobility to a Non Terrestrial Network (NTN). The first method comprises: receiving, from a first base station to which the UE is connected, a first message relating to a handover of the UE; and in response to the first message, transmitting, to a second base station to which the UE is to be handed over, a second message relating to the handover, wherein, if the second base station is associated with an NTN cell, the second message includes information relating to a Global Navigation Satellite System (GNSS) measurement. There is also disclosed a second method, for a UE, for inter-Radio Access Technology (RAT) mobility. The second method comprises: performing a procedure for mobility of the UE from a first base station to a second base station, wherein the first base station is associated with a Terrestrial Network (TN) cell of a first RAT type and the second base station is associated with an NTN cell of a second RAT type; and receiving, from the first base station in one or more certain System Information Blocks (SIBs), satellite information for NTN access.

Description

METHOD AND APPARATUS FOR MOBILITY BETWEEN TERRESTRIAL AND NON-TERRESTRIAL NETWORKS

[0001] Various embodiments of the disclosure provide one or more techniques for mobility between a Terrestrial Network (TN) and a Non Terrestrial Network (NTN). For example, various embodiments of the disclosure provide one or more techniques for providing certain information, for example Global Navigation Satellite System (GNSS) information, when performing mobility between a TN and an NTN in 3rdGeneration Partnership Project (3GPP) 5thGeneration (5G) New Radio (NR) networks.

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in “Sub 6GHz” bands such as 3.5GHz, but also in “Above 6GHz” bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz (THz) bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] It is an aim of various embodiments of the disclosure to address, solve and / or mitigate, at least partly, at least one of the problems and / or disadvantages associated with the related art, for example at least one of the problems and / or disadvantages described herein. It is an aim of various embodiments of the disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein.

[0009] The disclosure is defined in the independent claims. Advantageous features are defined in the dependent claims. Embodiments or examples disclosed in the description and / or figures falling outside the scope of the claims are to be understood as examples useful for understanding the disclosure.

[0010] Aspects of the disclosure are to address at least the above-mentioned problems and / or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the disclosure is to provide efficient communication methods in a wireless communication system.

[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] Figure 1 illustrates an exemplary NTN Release 17 architecture and scenario;

[0013] Figure 2 illustrates an exemplary ephemeris synchronization operation; in Figure 2A SIB31 functions as normal, and in Figure 2B UE fails to read SIB31 during T318 which then expires and triggers RLF;

[0014] Figure 3 illustrates an exemplary IoT NTN GNSS validity operation; Figure 3A illustrates an expected network-controlled operation where the network releases the UE to ensure that eNB knows the state of the UE, and in Figure 3B the UE releases itself autonomously according to the specification;

[0015] Figure 4 illustrates an exemplary handover procedure;

[0016] Figure 5A illustrates an exemplary procedure for mobility from NR to E-UTRAN;

[0017] Figure 5B illustrates an example of mobility triggered via RRCConnectionReconfiguration;

[0018] Figure 6 illustrates an exemplary procedure for sending gnss-ValidityDuration during IoT NTN handover according to 3GPP TS 36.331 V17.5.0;

[0019] Figure 7 illustrates examples of configuring the reporting of IoT NTN information during TN - NTN mobility; in Figure 7a information is reported to NTN cell, and in Figure 7b information is not reported to TN cell;

[0020] Figure 8 illustrates an example of providing GNSS information (e.g. GNSS validity duration) to a target eNB during TN-NTN mobility;

[0021] Figure 9A illustrates an example of whether NTN information is included when performing a handover / mobility from a certain type of network to another;

[0022] Figure 9B illustrates examples of mobility between E-UTRAN NTN / TN EPC, E-UTRAN NTN / TN 5GC, and / or NR NTN / TN 5GC;

[0023] Figure 10A illustrates an example of providing dedicated SIB31 when performing mobility from a source gNB (e.g. NR) to a target eNB (e.g. an E-UTRAN) NTN;

[0024] Figure 10B illustrates an example of including needed information in an RRCConnectionReconfigurationComplete message when the UE performs certain mobility;

[0025] Figure 11 illustrates an example of measuring NR NTN frequency / cells while in RRC connected mode with an E-UTRAN cell by translating E-UTRAN NTN ephemeris to NR NTN equivalent;

[0026] Figure 12 illustrates an exemplary method, for a UE, for mobility to an NTN;

[0027] Figure 13 illustrates an exemplary method, for a UE, for inter- RAT mobility; and

[0028] Figure 14 is a block diagram of an exemplary network entity that may be used in various embodiments of the disclosure.

[0029] Figure 15 illustrates a block diagram of a user equipment that illustrates various hardware components.

[0030] Figure 16 illustrates a block diagram of a base station that illustrates various hardware components.

[0031] Figure 17 illustrates a block diagram of a network entity that illustrates various hardware components.

[0032] Aspects of the disclosure are to address at least the above-mentioned problems and / or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the disclosure is to provide a terminal and a communication method thereof in a wireless communication system.

[0033] 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 regarded as merely exemplary. 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.

[0034] The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings.

[0035] Detailed descriptions of techniques, structures, functions, operations or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the disclosure.

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

[0037] Throughout the description and claims of this specification, the words “comprise”, “include” and “contain” and variations of the words, for example “comprising” and “comprises”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof.

[0038] Throughout the description and claims of this specification, the singular form, for example “a”, “an” and “the”, encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects.

[0039] Throughout the description and claims of this specification, language in the general form of “X for Y” (where Y is some action, process, operation, function, activity or step and X is some means for carrying out that action, process, operation, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y.

[0040] Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof described or disclosed in conjunction with a particular aspect, embodiment, example or claim are to be understood to be applicable to any other aspect, embodiment, example or claim described herein unless incompatible therewith.

[0041] The skilled person will appreciate that the techniques described herein may be used in any suitable combination.

[0042] Various embodiments of the disclosure provide one or more techniques for mobility between a TN and an NTN. For example, various embodiments of the disclosure provide one or more techniques for providing certain information, for example GNSS information, when performing mobility between a TN and an NTN in 3GPP 5G NR networks. However, the skilled person will appreciate that the disclosure is not limited to these examples, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards, including any existing or future releases of the same standards specification, for example 3GPP 5G.

[0043] The functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in the same or any other suitable communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function or purpose within the network. For example, the functionality of a NG-RAN node (e.g. a base station, eNB or gNB) in the examples below may be applied to any other suitable type of entity performing RAN functions.

[0044] A particular network entity may be implemented as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[0045] The skilled person will appreciate that the disclosure is not limited to the specific examples disclosed herein. For example:

[0046] The techniques disclosed herein are not limited to 3GPP 5G.

[0047] - One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations.

[0048] - One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information.

[0049] - One or more further elements or entities may be added to the examples disclosed herein.

[0050] - One or more non-essential elements or entities may be omitted in various embodiments.

[0051] - The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example.

[0052] - The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example.

[0053] - Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example.

[0054] - Information carried by two or more separate messages in one example may be carried by a single message in an alternative example.

[0055] - The order in which operations are performed and / or the order in which messages are transmitted may be modified, if possible, in alternative examples.

[0056] Various embodiments of the disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method therefor. Various embodiments of the disclosure may be provided in the form of a system (e.g. network or wireless communication system) comprising one or more such apparatuses / devices / network entities, and / or a method therefor.

[0057] Herein, the following document may be referenced:

[0058] [1] 3GPP TS 36.331 V17.5.0 "Radio Resource Control (RRC)", Release 17, June 2023.

[0059] [2] 3GPP TS 38.331 V17.5.0 "Radio Resource Control (RRC)", Release 17, June 2023.

[0060] [3] 3GPP TS 36.423 V17.5.0 "X2 application protocol (X2AP)", Release 17, June 2023.

[0061] Various acronyms, abbreviations and definitions used in the disclosure are defined at the end of this description.

[0062] One of the areas currently under development in 3GPP 5G wireless technology is support for NTNs. An NTN is a network in which one or more nodes (e.g. a Next Generation Radio Access Network (NG-RAN) node) are provided by a non-terrestrial infrastructure, for example a satellite or High Altitude Platform Station (HAPS). Advantages of using an NTN include (i) extending coverage to regions, such as remote areas, with limited or no coverage from more traditional terrestrial networks, (ii) providing continuous coverage in the event of inoperability of traditional terrestrial networks, such as during natural disasters, and (iii) enhancing overall reliability, resilience and capacity when used in conjunction with existing terrestrial networks. Figure 1 illustrates an exemplary NTN Release 17 architecture and scenario.

[0063] A satellite network implementing a network node provides coverage through one or more radio beams forming a "footprint" on the surface of the Earth defining a coverage area or cell. An NTN cell may be Earth-moving (i.e. moving over the Earth's surface according to the motion of the satellite, for example in the case of a Lower Earth Orbit (LEO) satellite), Earth-fixed (i.e. a fixed area of the Earth's surface, for example in the case of a Geosynchronous Equatorial Orbit (GEO) satellite) or quasi-Earth-fixed (i.e. a fixed area of the Earth's surface but is maintained for only a limited time as the satellite passes by).

[0064] Internet of Things (IoT) NTN was 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 Communication (LTE-M), including enhanced Machine Type Communication (eMTC)). As noted in 3GPP RP-202689, IoT operation is critical in remote areas with low / no cellular connectivity for many different industries. The capabilities of NB-IoT and eMTC are a good fit for many applications but some applications may require satellite connectivity to provide coverage beyond terrestrial deployments.

[0065] NR NTN was a work item in Release 17 to specify adaptation to allow NR to function over NTN (RP-211557, RAN#91-e March 2021).

[0066] Following the work items in Release 17 there were work items to enhance NR NTN (RP-220953, RAN#95-e March 2022) and IoT NTN (RP-220979, RAN#95-e March 2022) in Release 18.

[0067] Due to the movement of satellites in a non-stationary orbit (e.g. LEO), the cells that a UE see will be moving (i.e. Earth-moving cells). This results in frequent UE handover from one cell to another, and this handover of service will happen constantly. In view of this, mobility is one of the key issues in both NR NTN and IoT NTN.

[0068] The work item description for IoT NTN Release 18 is reproduced below (RP-223519):

[0069] 4.1.1 IoT-NTN Performance Enhancements in Rel-18 to address remaining issues from Rel-17

[0070] This work considers Rel-17 IoT-NTN as baseline as well as Rel-17 NR-NTN outcome and the further IoT-NTN performance enhancements objectives are listed below:

[0071] - Disabling of HARQ feedback to mitigate impact of HARQ stalling on UE data rates [RAN1,RAN2]

[0072] - Study and specify needed improved GNSS operations for a new position fix for UE pre-compensation during long connection times and for reduced power consumption. Simultaneous GNSS and NTN NB-IoT / eMTC operation is not assumed. [RAN1, RAN2]

[0073] NOTE: The need for RAN4 Core requirements for this objective will be identified after the conclusion on the need for improvements.

[0074] 4.1.2 Mobility enhancements

[0075] The following mobility enhancements objectives are listed.

[0076] - Support of neighbour cell measurements and corresponding measurement triggering before RLF, using Rel-17 (TN) NB-IoT, eMTC as a baseline. [RAN2]

[0077] - Support signalling in system information of neighbour cell ephemeris, for eMTC and NB-IoT [RAN2]

[0078] - Re-use the solutions introduced in Rel-17 NR NTN for mobility enhancements for eMTC, with minimum necessary changes to adapt them to eMTC [RAN2]

[0079] - Define UE RRM core requirements for the above mobility enhancement features [RAN4].

[0080] 4.1.3 Further enhancement to discontinuous coverage

[0081] - Study and specify, if needed, mobility management enhancements and power saving enhancements for discontinuous coverage, taking into account the conclusions from the SA2 study FS_5GSAT_Ph2. [RAN2, RAN3].

[0082] Overview of NB-IoT and LTE-M

[0083] NB-IoT is a 3GPP-defined network based on 4thGeneration (4G) E-UTRAN that supports ultra-low complexity devices with very narrow bandwidth that was introduced in 3GPP Release 13. The use case of NB-IoT is to serve massive IoT application, where requirements for instance are to support enhanced coverage, power-efficient operation and a massive number of devices. Some of the features introduced are:

[0084] - Support for enhanced coverage through low bandwidth and extreme amounts of repetitions.

[0085] - Power efficient operation by allowing the User Equipment (UE) to sleep for very long times, relaxed requirements and more efficient signal to establish with a cell.

[0086] LTE-M or eMTC is a 3GPP-defined network that is an extension of 4G E-UTRAN that supports low-complexity devices with more narrow bandwidths compared to normal LTE and further simplifications of procedures. Similar to NB-IoT, the use case is to serve massive IoT, but with more capabilities. Instead of being an entirely new type of device with major air interface changes as in NB-IoT, the LTE-M inherits most feature of a regular LTE device, but with some adaptations for low complexity considerations.

[0087] Overview of NTN System Information

[0088] As NTN has a number of NTN-specific information elements that are only required when accessing an NTN cell, and also due to the relatively large information elements, it was agreed that new System Information Blocks (SIBs) are needed.

[0089] In NR NTN, SIB19 contains the required information to access an NTN cell:

[0090] ------------------------------ 3GPP TS 38.331 V17.5.0 ------------------------------

[0091] - SIB19

[0092] SIB19 contains satellite assistance information for NTN access.

[0093] SIB19 information element

[0094]

[0095]

[0096] ------------------------------ 3GPP TS 38.331 V17.5.0 ------------------------------

[0097] In IoT NTN, SIB31 contains the required information to access an IoT NTN cell:

[0098] ------------------------------ 3GPP TS 36.331 V17.5.0 ------------------------------

[0099] - SystemInformationBlockType31

[0100] The IE SystemInformationBlockType31 contains satellite assistance information for the serving cell. SystemInformationBlockType31 is only signalled in a NTN cell.

[0101] SystemInformationBlockType31 information element

[0102]

[0103]

[0104] ------------------------------ 3GPP TS 36.331 V17.5.0 ------------------------------

[0105] The system information contains the following:

[0106] - Serving cell ephemeris elements. This allows the UE to calculate the satellite position for doppler and time pre-compensation. This information may be provided in two formats:

[0107] -- Position, Velocity, Time (PVT) format. This describes a (X,Y,Z) position as well as a speed vector (vX, vY, vZ).

[0108] -- Orbital parameters. This describes the orbital movements of the satellite which is then used to infer the satellite position.

[0109] - Timing Advance (TA) common parameters. This provides the common timing advance parameters which is introduced to compensate for the feeder link delays. The signalling comprises the following (in total taking up 57 bits):

[0110] -- Absolute TA common (23 bits).

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

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

[0113] - Synchronization validity duration. This is used to define how long the ephemeris and TA common is valid.

[0114] - Epoch time. This defines when the synchronization validity duration should start.

[0115] - K-Offset. This is a scheduling offset for timing relationship in NTN.

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

[0117] - NR NTN specific information also includes (as part of 3GPP TS 38.331):

[0118] -- T-Service (signalled in SIB3 in IoT NTN).

[0119] -- Reference location and distance threshold. This is used for location-based measurement initiation in RRC IDLE and RRC Connected mode.

[0120] -- Neighbour cell ephemeris. This is used for idle mode measurements.

[0121] Overview of NTN System Information Acquisition

[0122] As ephemeris information constantly changes due to the movement of the NTN payload (e.g. satellite), there is a need to make sure that the UE is correctly synchronized. Thus, whenever a UE connects to an eNB, the UE needs to read the system information (e.g. SIB19 or SIB31).

[0123] In IoT NTN, every time SIB31 is read, a timer (T317) associated with the ephemeris element is started. At expiry of T317, the UE is no longer considered synchronized and should re-acquire SIB31 in order to stay synchronized.

[0124] In IoT NTN, since an IoT UE (LTE-M and NB-IoT UE) is not expected to be able to acquire system information in connected mode, the UE tunes away and is likely unreachable while reading SIB31.

[0125] If the IoT NTN UE is unable to read the SIB31 within a timer (T318) with a configured duration, the UE performs Radio Link Failure (RLF) similar to other cases where RLF is performed. This operation can be seen in Figure 2.

[0126] In NR NTN, the UE shall ensure that it has a recent ephemeris (SIB19 in NR) by reading the SIB in time by UE implementation.

[0127] The T317 timer is different compared to a normal timer in Radio Resource Control (RRC) as it is not started at having received the SIB31. This is because the ephemeris has an epoch time, which is the reference point in time of when the ephemeris is defined. Thus the T317 is started from the epoch time, which may be in the past or in the future relative to have received SIB31. This means that in an UE implementation, the timer may be started with a different value with what was signalled according to what was signalled in the field ul-SyncValidityDuration in SIB31.

[0128] Overview of NTN Ephemeris Formats

[0129] There are three ways of signalling the ephemeris in NTN:

[0130] 1. PVT format,

[0131] 2. Orbital ephemeris elements, and

[0132] 3. TLE ephemeris elements (only used for Discontinuous Coverage in IoT NTN).

[0133] PVT Format

[0134] PVT format signals XYZ position along with the speed vector vXYZ. This can be seen in the following information element:

[0135] ------------------------------ 3GPP TS 36.331 V17.5.0 ------------------------------

[0136] - EphemerisStateVectors

[0137] The IE EphemerisStateVectors provides satellite ephemeris in format of position and velocity state vectors in ECEF.

[0138] EphemerisStateVectors information element

[0139]

[0140]

[0141] ------------------------------ 3GPP TS 36.331 V17.5.0 ------------------------------

[0142] The position elements (X, Y, Z respectively) each occupy 26 bits and the speed elements (vX, vY, vZ) each occupy 18 bits. Altogether they occupy 132 bits.

[0143] Orbital Ephemeris Format

[0144] The ephemeris orbital parameters (also referred to as Keplerian format) provide parameters that indicate how a celestial body moves in space, which allows for accurate synchronization and prediction of future NTN payload position.

[0145] Ephemeris orbital elements are signalled by the following elements (164 bits total):

[0146] - SemiMajorAxis (33 bits)

[0147] - Eccentricity (20 bits)

[0148] - Periapsis (28 bits)

[0149] - Longitude (28 bits)

[0150] - Inclination (27 bits)

[0151] - Anomaly (28 bits)

[0152] TLE Orbital Parameters

[0153] The Two-Line Element (TLE) parameters are based on TLE set, which is industry-acknowledged data format for signalling the movement of a celestial body. Whereas the PVT and orbital ephemeris formats may be used to perform accurate synchronization, TLE parameters may be used primarily for long term prediction. For example, the TLE parameters allow for accurate satellite-pass prediction of up to several days in the future.

[0154] A full set of TLE parameters can occupy more than 50 Bytes of data containing many fields not required in 3GPP. Therefore, a reduced set of TLE parameters may be used instead, for example based on the following (totalling 189 bits):

[0155] - Inclination (21 bits)

[0156] - Argument of perigee (22 bits)

[0157] - Right ascension of the ascending node (22 bits)

[0158] - Mean anomaly (22 bits)

[0159] - Eccentricity (24 bits)

[0160] - Mean Motion (34 bits)

[0161] - B* signalled by (i) a decimal (18 bits), and (ii) an exponent (5 bits)

[0162] - Epoch star (21 bits)

[0163] Overview of GNSS measurements in IoT NTN

[0164] Both IoT NTN and NR NTN are heavily reliant on GNSS in order to synchronize in frequency and in time as well as to determine correct configuration and whether the UE is allowed to operate in the cell or not. However, GNSS function is typically provided in a separate part of a device, and how GNSS operates is not standardized. This means that it is not specified when a UE shall perform GNSS measurement in the current specification. Rather, it is specified as a requirement that the UE shall have a recent and precise enough GNSS position. For instance, the UE is required to have determined its own position to be used for time and frequency-synchronization, and in IoT NTN the UE is required to report its GNSS validity duration in certain RRC messages. Furthermore, if the GNSS information is deemed to be invalid and the UE is in connected mode, the UE shall move to idle mode. This operation can be seen in Figure 3. In Figure 3A UE is released (i.e. moved to RRC Idle mode) by eNB, and in Figure 3B UE releases itself, as defined in 3GPP TS 36.331 v17.5.0:

[0165] ---------------------- 3GPP TS 36.331 V17.5.0 ----------------------

[0166] 5.3.3.21 UE actions upon indication of out-of-date GNSS position

[0167] Upon indication that the GNSS position has become out-of-date while in RRC_CONNECTED, the UE shall:

[0168] 1> perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause 'other'.

[0169] ---------------------- 3GPP TS 36.331 V17.5.0 ----------------------

[0170] One of the goals in 3GPP IoT NTN Release 18 is to introduce measurement gaps where the UE may perform GNSS measurements.

[0171] Overview of E-UTRAN and eMTC connected mode mobility

[0172] E-UTRAN connected mode mobility functions similar to other cellular standards and connected mode mobility is also supported for E-UTRAN eMTC. A standard connected mode handover is performed only when triggered by the eNB.

[0173] A typical procedure is described below and illustrated in Figure 4.

[0174] 1. UE performs neighbour cell measurements, which are configured by the network.

[0175] 2. A measurement report (of a neighbour cell) is triggered and sent by UE to source eNB.

[0176] 3. Source eNB decides, based on measurement report or any other information, whether to initiate a handover.

[0177] 4. When source eNB decides to initiate a handover, source eNB sends a Handover Request to target eNB.

[0178] 5. Following admission control at target eNB, source eNB receives a Handover Request Acknowledge from target eNB.

[0179] 6. The source eNB triggers a handover command which is sent to UE. This handover command comprises the RRC message RRCConnectionReconfiguration, containing the mobilityControlInfo field.

[0180] 7. UE prepares for handover and performs a handover via the random access procedure.

[0181] If a neighbour cell measurement is configured to be performed in an NTN cell, then as currently being discussed in Release 18 IoT NTN, the UE needs to have the ephemeris of the neighbouring NTN cell in order to allow for time-frequency synchronization to measure neighbouring cell. The ephemeris will be provided in a broadcast fashion using SIB.

[0182] Overview of Inter-RAT mobility

[0183] When performing handover from NR to E-UTRAN, this is done via the RRC message MobilityFromNRCommand. The RRC message MobilityFromNRCommand contains the handover command based on the specific Radio Access Technology (RAT) that the UE shall perform mobility to. In the case of handover to E-UTRAN the message contains the E-UTRAN RRCConnectionReconfiguration. This is illustrated in Figure 5.

[0184] In idle mode for inter-RAT mobility the following system information is broadcast:

[0185] - SIB24 is broadcast in an E-UTRAN cell to perform inter-RAT measurements of an NR cell. This gives important information about an NR cell required to measure an NR cell.

[0186] - SIB5 is broadcast in an NR cell to perform inter-RAT measurements of an E-UTRAN cell.

[0187] Inter-RAT mobility procedures are also invoked when a so-called inter-CN mobility (or sometimes called inter-system mobility) is performed. This occurs when mobility is performed between two cells with different core networks. One such example is when performing mobility from E-UTRAN EPC to E-UTRAN 5GC or the reverse direction. In this case the mobility is triggered via the RRCConnectionReconfiguration. One example can be seen in Figure 5B. When a UE in E-UTRAN operates in 5GC, the UE uses NR PDCP and SDAP instead of LTE PDCP (i.e. no SDAP).

[0188] The above information is presented as background information only to assist with an understanding of the 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 disclosure.

[0189] Having a valid GNSS location is very important in a non-terrestrial network, as the UE uses the GNSS position in order to maintain synchronization with a network, by estimating the distance between UE and the eNB on the ground via the satellite. When the GNSS position is not valid, the UE shall not under any circumstances perform any type of uplink transmissions as it can cause a lot of interference. Thus when the GNSS is no longer valid, the UE shall move to RRC idle autonomously.

[0190] The reporting of the GNSS validity duration was introduced in Release 17 as a way to indicate to a network how long before a UE would lose its GNSS validity and thus go to RRC idle. This is considered essential for an eNB, as it may be very cumbersome for eNB implementation to handle UEs that may or may not be in RRC connected mode.

[0191] The GNSS validity duration is sent at the point of UE performing handover in order to provide the information to the target gNB. In Release 17 the two related agreement was taken (in contribution R2-2206626):

[0192] - P4: The new parameter for remaining GNSS validity duration is introduced in RRCConnectionReconfigurationComplete for MTC Handover.

[0193] - This mechanism is not configurable, and the UE always reports.

[0194] The current procedure (3GPP TS 36.331 V17.5.0) is illustrated in Figure 6.

[0195] According to the current procedure, the UE will include the GNSS validity duration if the UE is connected to NTN, as seen in Step 3 of Figure 6. This means that if a UE is currently connected to NTN and then is instructed to perform mobility to a target TN cell, the UE will be considered to still be connected to NTN in Step 3 of Figure 6, and thus will include the gnss-ValidityDuration. Similarly, if the UE is connected to a TN cell and then is instructed to perform mobility to a NTN cell, the UE may not include the gnss-ValidityDuration as the UE is currently not connected to NTN when Step 3 of Figure 6 is evaluated.

[0196] Furthermore, in the future it may become possible to perform inter-RAT mobility NTN / TN mobility in a fully integrated E-UTRAN-NR-NTN / TN network. The different mobility options are illustrated in Figure 9. In these case there are still some open issues on how to signal certain fields and for instance configuring measurements etc. For instance, the ephemeris elements in E-UTRAN NTN and NR NTN have been designed slightly differently requiring methods to ensure that a UE in an NR NTN cell can measure an E-UTRAN NTN cell.

[0197] Various embodiments of the disclosure provide one or more techniques for performing mobility between a terrestrial network and a non-terrestrial network. In various embodiments, both the terrestrial network and the non-terrestrial network may be NR or E-UTRAN (LTE).

[0198] In the disclosure, an E-UTRAN (cell) may be (in a loose sense) the base station of an eMTC / LTE-M cell. Thus "E-UTRAN" can be interpreted as "IoT NTN base station". In 3GPP so far, only IoT is supported for LTE NTN and not "ordinary" non-IoT LTE NTN. The skilled person will appreciate that the techniques described herein are not limited to IoT NTN E-UTRAN, as "ordinary" non-IoT LTE NTN may be supported. For example, certain techniques may be applicable if non-Standalone NTN is supported, i.e. E-UTRAN-NR Dual Connectivity (EN-DC) is supported in the future. Similarly, certain techniques concern terrestrial, non-NTN, base stations.

[0199] In the description below, the description may apply to eNBs, gNBs, NG-RAN or NG-eNB. For instance, in some cases the below description may be for an eNB, but it may also apply for NG-eNB (eNB is connected to EPC, while NG-eNB is connected to 5GC). In some cases below, there may also be methods explicitly for an NG-eNB, en-gNB, gNB, or NG-RAN.

[0200] Various embodiments of the disclosure provide a method, for a User Equipment (UE), for mobility to a Non Terrestrial Network (NTN), the method comprising: receiving, from a first base station to which the UE is connected, a first message relating to a handover of the UE; and in response to the first message, transmitting, to a second base station to which the UE is to be handed over, a second message relating to the handover, wherein, if the second base station is associated with an NTN cell, the second message includes information relating to a Global Navigation Satellite System (GNSS) measurement.

[0201] In various embodiments, the second message may include the information relating to the GNSS measurement only if the second base station is associated with the NTN cell.

[0202] In various embodiments, the first message may comprise an RRCConnectionReconfiguration message.

[0203] In various embodiments, the RRCConnectionReconfiguration message may comprise mobilityControlInfo.

[0204] In various embodiments, the second message may comprise an RRCConnectionReconfigurationComplete message.

[0205] In various embodiments, the information relating to a GNSS measurement may comprise gnss-validityDuration (e.g. in accordance with a remaining time of a GNSS validity duration).

[0206] In various embodiments, the information relating to a GNSS measurement may comprise a GNSS measurement duration (e.g. for enabling configuration of a duration of a measurement gap when the UE performs a GNSS measurement).

[0207] In various embodiments, the information relating to a GNSS measurement may comprise gnss-PositionFixDuration (e.g. indicating a time duration required to acquire a GNSS position).

[0208] In various embodiments, the first base station may be associated with a Terrestrial Network (TN) cell.

[0209] In various embodiments, the information relating to a GNSS measurement may comprise Internet of Things (IoT) NTN information.

[0210] Various embodiments of the disclosure provide a method, for a User Equipment (UE), for inter-Radio Access Technology (RAT) mobility, the method comprising: performing a procedure for mobility of the UE from a first base station to a second base station, wherein the first base station is associated with a Terrestrial Network (TN) cell of a first RAT type and the second base station is associated with a Non Terrestrial Network (NTN) cell of a second RAT type; and receiving, from the first base station in one or more certain System Information Blocks (SIBs), satellite information for NTN access.

[0211] In various embodiments, the first base station may be associated with an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) TN cell.

[0212] In various embodiments, the second base station may be associated with a New Radio (NR) NTN cell.

[0213] In various embodiments, the satellite information may comprise ephemeris.

[0214] In various embodiments, the satellite information may comprise a satellite ID.

[0215] In various embodiments, the satellite ID may be associated with frequency information for cell reselection.

[0216] In various embodiments, the one or more SIBs may comprise one or more NTN-specific SIBs.

[0217] In various embodiments, a first part of the satellite information (e.g. ephemeris) may be provided in a first SIB (e.g. SIB19, SIB31 or any other suitable SIB for providing satellite information), and a second part of the satellite information (e.g. satellite ID associated with the ephemeris) may be provided in a second SIB (e.g. SIB24).

[0218] In various embodiments, the UE may be in an idle mode (e.g. RRC idle mode).

[0219] In various embodiments, the UE may not send certain NTN information (e.g. a GNSS validity duration and / or a GNSS measurement duration) to the second base station.

[0220] Various embodiments of the disclosure (e.g. a first example) provide a method, for mobility between a Terrestrial Network (TN) and a Non-Terrestrial Network (NTN), the method comprising: when mobility between a TN and an NTN is to be performed, determining whether certain NTN information related to the NTN is required; and selectively transmitting, by a User Equipment (UE), the NTN information based on the result of the determination.

[0221] In various embodiments (e.g. a second example according to the first example), determining whether the NTN information is required may comprise determining that the NTN information is required if a target cell is an NTN cell.

[0222] In various embodiments (e.g. a third example according to the first or second examples), determining whether the NTN information is required may comprise: receiving, by a UE, a handover request message (e.g. RRCConnectionReconfiguration); and determining that the NTN information is required if the handover request message includes certain information (e.g. a dedicated System Information Block (SIB), e.g. systemInformationBlockType31dedicated).

[0223] In various embodiments (e.g. a fourth example according to the first, second or third examples), selectively transmitting based on the result of the determination may comprise: transmitting, by the UE, the NTN information if it is determined that the NTN information is required; and / or not transmitting the NTN information if it is determined that the NTN information is not required.

[0224] In various embodiments (e.g. a fifth example according to any of the first to fourth examples), transmitting the NTN information may comprise: transmitting, by a UE, the NTN information to a target NTN cell; and

[0225] In various embodiments (e.g. a sixth example according to any of the first to fifth examples), transmitting the NTN information may comprise: transmitting, by a UE, the NTN information to a source cell (e.g. in advance of mobility); and forwarding, by the source cell to a target NTN cell, the NTN information (e.g. during handover preparation).

[0226] In certain (e.g. a seventh example according to any of the first to sixth examples) examples, the determination of whether the NTN information is required may be performed by a UE and / or a source cell.

[0227] In various embodiments (e.g. an eighth example according to any of the first to seventh examples), selectively transmitting the NTN information may comprise: transmitting, by the UE, the NTN information in response to receiving a message (e.g. from a source cell) requesting the NTN information.

[0228] In various embodiments (e.g. a ninth example according to any of the first to eighth examples), the NTN information may comprise one or more of: information relating to Global Navigation Satellite System (GNSS) validity duration; information relating to GNSS measurement duration; information relating to capability of performing GNSS measurement simultaneously during downlink and / or uplink transmissions; information relating to last time a GNSS measurement was performed; and information relating to GNSS measurement failure.

[0229] In various embodiments (e.g. a tenth example according to any of the first to ninth examples): a source cell may be a TN cell or an NTN cell, and a target cell may be a TN cell or an NTN cell.

[0230] In various embodiments (e.g. an eleventh example according to any of the first to tenth examples): a source cell may be a cell of a first RAT type (e.g. E-UTRAN or NR), and a target cell may be a cell of a second RAT type (e.g. NR or E-UTRAN).

[0231] In various embodiments (e.g. a twelfth example according to any of the first to eleventh examples), the NTN information may be selectively transmitted based on one or more of: a RAT type of a source cell and / or a RAT type of a target cell; whether the source cell is a TN cell or an NTN cell and / or whether the target cell is a TN cell or an NTN cell; and network and / or UE configuration and / or capability.

[0232] In various embodiments (e.g. a thirteenth example according to the twelfth example), selectively transmitting the NTN information may comprise one or more of: the NTN information is not transmitted if the source cell is an E-UTRAN NTN cell and the target cell is an NR NTN cell; the NTN information is transmitted if the source cell is an NR NTN cell and the target cell is an E-UTRAN NTN cell, or the NTN information is not transmitted if the source cell is an NR NTN cell and the target cell is an E-UTRAN NTN cell, optionally based on a signalled UE capability; the NTN information is transmitted if the source cell is an NR TN cell and the target cell is an E-UTRAN NTN cell; the NTN information is not transmitted if the source cell is an E-UTRAN TN cell and the target cell is an NR NTN cell; the NTN information is not transmitted if the source cell is an E-UTRAN NTN cell and the target cell is an NR TN cell; and the NTN information is not transmitted if the source cell is a NR NTN cell and the target cell is an E-UTRAN TN cell.

[0233] In various embodiments (e.g. a fourteenth example according to any of the first to thirteenth examples), mobility between a TN and an NTN may comprises mobility from a TN to an NTN and / or mobility from an NTN to a TN.

[0234] In various embodiments (e.g. a fifteenth example according to any of the first to fourteenth examples), selectively transmitting the NTN information may comprise transmitting the NTN information when performing mobility from an NTN cell to a TN cell.

[0235] In various embodiments (e.g. a sixteenth example according to any of the first to fifteenth examples), in the case of performing mobility from NR to E-UTRAN NTN, the method may further comprise: receiving, by the UE, a certain message (e.g. MobilityFromNRCommand); and if the received message includes certain information (e.g. systemInformationBlockType31dedicated), applying, by the UE, a configuration based on the information.

[0236] In various embodiments (e.g. a seventeenth example according to the sixteenth example), the method may further comprise: if the received message does not include the certain information, acquiring, by the UE, the information through broadcast information (e.g. SIB31).

[0237] Various embodiments (e.g. an eighteenth example) of the disclosure provide a method, for mobility between a first RAT type (e.g. NR or E-UTRAN) and an NTN of a second RAT type (e.g. E-UTRAN or NR), the method comprising: receiving, by a User Equipment (UE), from a source cell of the first RAT type, configuration information relating to the first RAT type; translating, by the UE, the configuration information; and performing, by the UE, measurements on one or more neighbour NTN cells of the second RAT type based on the translated configuration information.

[0238] In various embodiments (e.g. a nineteenth example according to the eighteenth example), the method may further comprise: transmitting, by the UE, a measurement report based on the measurements.

[0239] In various embodiments (e.g. a twentieth example according to the eighteenth or nineteenth examples), translating the configuration information may comprise one or more of: taking ntn-UlSyncValidityDuration (T430 in NR NTN) as the value for ul-SyncValidityDuration (T317 in E-UTRAN NTN); using signalled absolute values instead of signalled values for ta-Info fields; and translating cellSpecificKoffset to k-Offset.

[0240] In various embodiments (e.g. a twenty first example according to the eighteenth, nineteenth or twentieth examples), translating the configuration information may comprise one or more of: taking ul-SyncValidityDuration as the value for ntn-UlSyncValidityDuration; using signalled absolute values instead of signalled values for nta-CommonParameters fields; and translating k-offset to cellSpecificKOffset.

[0241] In various embodiments (e.g. a twenty second example according to any of the eighteenth to twenty first examples), translating the configuration information may comprise: ignoring certain fields (e.g. ta-Report, polarization etc.).

[0242] In various embodiments (e.g. a twenty third example according to any of the eighteenth to twenty second examples), the configuration information may relate to a connected mode (e.g. RRC connected mode) and / or an idle mode (e.g. RRC idle mode).

[0243] In various embodiments (e.g. a twenty fourth example according to any of the first to twenty third examples), when measuring a cell in idle mode, the method may comprise: acquiring an ID (e.g. satelliteID) relating to NTN information (e.g. ephemeris) from broadcast information (e.g. SIB24 for E-UTRAN, or SIB5 for NR).

[0244] Various embodiments of the disclosure provide a User Equipment (UE) or a Base Stations (BS) configured to perform a method according to any example, aspect, embodiment and / or claim disclosed herein.

[0245] Various embodiments of the disclosure provide a network (or wireless communication system) comprising a UE and one or more BSs according to any examples, aspects, embodiments and / or claims disclosed herein.

[0246] Various embodiments of the 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 example, aspect, embodiment and / or claim disclosed herein.

[0247] Various embodiments of the disclosure provide a computer or processor-readable data carrier having stored thereon a computer program according to any example, aspect, embodiment and / or claim disclosed herein.

[0248] Sending needed information during TN NTN mobility

[0249] To address the problem of ambiguity of when to report certain needed information for operating in an IoT NTN cell, one or more of the following techniques may be applied.

[0250] In various embodiments, the IoT NTN information may be provided when connecting to a target NTN cell, whereas the IoT NTN information is not provided when connecting to a target non-NTN cell, i.e. a TN cell. For example, a condition for reporting the IoT NTN information during the handover may comprise one or more of the following options:

[0251] 1. The UE reports the IoT NTN information when the target cell is an NTN cell. An example is given in specification example 1 further below.

[0252] 2. The UE reports the IoT NTN information when the RRCReconfiguration message (containing the mobilityControlInfo), i.e. the handover command sent by source cell, contains the dedicated SIB31, i.e. systemInfoBlockType31dedicated. An example is given in specification example 2 further below. This may be more flexible as there can be other use cases where the ephemeris may be needed and the cell is not an NTN cell.

[0253] In various embodiments, options 1 and 2 above have the following implications on mobility between TN and NTN, i.e. from TN to NTN or from NTN to TN (as illustrated in Figure 7):

[0254] - When performing mobility from TN to NTN, the UE will send the needed information in the RRCConnectionReconfigurationComplete message to the NTN cell.

[0255] - When performing mobility from NTN to TN, the UE will not send the information needed for NTN operation.

[0256] In various embodiments, as the problem described above suggests, the needed information reported IoT NTN may comprise one or more of the following non-limiting examples:

[0257] - GNSS validity duration. This may be needed as the network needs to know how long a UE will stay in RRC connected mode before moving to RRC idle mode, due to not having a valid GNSS validity duration.

[0258] - GNSS measurement duration. This may be needed to enable the network to configure a duration of a measurement gap when a UE performs a GNSS measurement in RRC connected mode. In various embodiments, the UE may signal to the network that the GNSS measurement was performed in a terrestrial network. The UE may also include information for instance whether the GNSS measurement was performed using assistance information.

[0259] - Capability of performing GNSS measurement simultaneously during downlink and / or uplink transmissions.

[0260] - Last time a GNSS measurement was performed.

[0261] - GNSS measurement failure. This may comprise information on of GNSS measurement failure during a GNSS measurement.

[0262] In various embodiments, the UE is requested to provide this information in advance of the TN-NTN mobility, thus it is not reported by the UE during TN-NTN mobility. Instead it is sent by the source cell to the target cell after having been reported by the UE. An example of this is illustrated in Figure 8. Instead, the IoT NTN information of a UE is sent to the target eNB (or gNB or NG-RAN) via X2 (or Xn) in the handover preparation phase (inter-node signalling). For example, the source eNB (or gNB or NG-RAN) may include information, for example the gnss-ValidityDuration Information Element (IE) and / or any other information related to GNSS, in the HANDOVER REQUEST message.

[0263] TN-NTN inter-RAT mobility

[0264] In various embodiments, the techniques described above under the heading "Sending needed information during TN NTN mobility" may also be performed when performing mobility between an E-UTRAN (e.g. an IoT NTN) cell and an NR NTN cell. Various embodiments may relate to one or more of the following possibilities (as illustrated in Figure 9):

[0265] - E-UTRAN NTN to NR NTN cell

[0266] -- In this case, the IoT NTN information may not be needed and the NR NTN cell is unlikely to be able to read the information. So, the IoT NTN information does not need to be sent by the UE.

[0267] - NR NTN cell to E-UTRAN NTN cell

[0268] -- In this case the E-UTRAN NTN cell may need to have the IoT NTN information for normal operation.

[0269] -- In various embodiments, it may not be necessary to provide the IoT NTN information. This is because a device that is capable of NR NTN should be able to acquire GNSS without tuning away from the operations on the cellular band. This means that IoT NTN information such as gnss-ValidityDuration may not be relevant. In various embodiments, the UE capability with respect to NR NTN of the UE performing the handover may be known from the signalled capabilities. In various embodiments the UE capability may be signalled between source and target cells.

[0270] -- In various embodiments, this may be specified by requiring that the NR NTN-capable UE signal infinity value or any other suitable value.

[0271] - NR TN to E-UTRAN NTN cell

[0272] -- In this case the UE may send the IoT NTN information.

[0273] - In the following cases the UE may not send the IoT NTN information to the target cell

[0274] -- E-UTRAN TN to NR NTN cell

[0275] -- E-UTRAN NTN to NR TN cell

[0276] -- NR NTN to E-UTRAN TN cell

[0277] In various embodiments, the UE may be specially configured to provide the IoT NTN information when performing mobility from an NTN to a TN. This may be useful if the TN network may need some information on the IoT NTN, such as gnss-ValidityDuration. This may be useful as there may be quick handovers back to the NTN from the TN network.

[0278] In various embodiments, when a UE performs mobility from NR (TN or NTN) to E-UTRAN NTN, the systemInformationBlockType31dedicated (dedicated SIB31) may be provided and applied by the UE in the MobilityFromNRCommand. An example of this is illustrated in Figure 10. If not provided by the NR cell, the UE may acquire the broadcast SIB31.

[0279] In another special case, inter-CN mobility involving E-UTRAN may need to be considered. For example, Inter-CN mobility can be performed in the following cases:

[0280] - E-UTRAN EPC to E-UTRAN 5GC or E-UTRAN 5GC to E-UTRAN EPC

[0281] - EN-DC EPC to E-UTRAN 5GC or E-UTRAN 5GC to EN-DC EPC

[0282] - E-UTRAN EPC to NR 5GC or NR 5GC to E-UTRAN EPC

[0283] In these cases it needs to be considered whether NTN info needs to be included (or provided) to the target cell for normal functioning. Without including the NTN info, the inter-CN mobility would not be supported for NTN.

[0284] In one embodiment, when the UE performs mobility:

[0285] - from E-UTRAN NTN / TN EPC to E-UTRAN NTN 5GC,

[0286] - from E-UTRAN NTN / TN 5GC to E-UTRAN NTN EPC,

[0287] - from EN-DC NTN / TN to E-UTRAN NTN 5GC

[0288] - from E-UTRAN NTN / TN 5GC to EN-DC NTN

[0289] - from NR NTN / TN 5GC to E-UTRAN NTN EPC,

[0290] the UE will include the needed NTN information to the target eNB in the RRCConnectionReconfigurationComplete message. The diagram can be seen in Figure 9B and the procedures can be seen in Figure 10B. In the other mobility cases, the UE will not include the NTN info.

[0291] In another embodiment, the network, for example, a (target) eNB connected to EPC or NG-RAN (which can be NG-eNB or gNB, both connected to 5GC) includes the systemInformationBlockType31 in the RRCConnectionReconfiguration or MobilityFromNRCommand when performing inter-CN mobility.

[0292] In alternative example, the network, for example, a (target) eNB connected to EPC or NG-RAN (NG-eNB or gNB) connected to 5GC includes the systemInformationBlockType31 in the newly defined RRC message (or signalling or procedure) when performing inter-CN mobility.

[0293] A specification example of this can be seen in specification example 5 further below.

[0294] Connected mode measurements for mobility purposes

[0295] In the case of performing connected mobility from NR (TN or NTN) to E-UTRAN NTN, the UE first would need to perform measurements, and similar to when performing mobility from E-UTRAN (TN or NTN) to NR NTN. In NR NTN it may be assumed that the neighbouring cells that the UE is performing mobility to are either NR TN or NR NTN. However, if there are E-UTRAN NTN that shall also be measured, this may be be indicated, for example as the configuration of E-UTRAN and NR NTN is different.

[0296] In various embodiments, the NR NTN-Config is signalled by an NR NTN cell for an E-UTRAN NTN neighbouring cell / frequency, but certain fields are translated or omitted. This translation can be configured for instance using a new RRC field eutran-NTN or similar, which indicates that the frequency or cell is an E-UTRAN and / or IoT NTN cell / frequency.

[0297] Examples of the translation or omission may include one or more of the following:

[0298] - ntn-UlSyncValidityDuration (T430 in NR NTN) may be taken as the value for ul-SyncValidityDuration (T317 in E-UTRAN NTN).

[0299] - ta-Info fields. In this case, not the signalled values, i.e. the signalled integers, but rather the signalled absolute values may be used. This is because the signalled integers that are later translated to an absolute value are different. This may apply to the TA common, the TA drift (first time-derivative of the TA common) and the TA drift variation (second time-derivate of the TA common).

[0300] - cellSpecificKoffset may be translated in to k-Offset

[0301] - certain fields, such as ta-Report, polarization etc., may be either not signalled by the network or ignored by the UE if signalled.

[0302] In various embodiments, the E-UTRAN NTN-Config may be signalled by an E-UTRAN NTN cell for an NR NTN neighbouring cell / frequency, but certain fields are translated or omitted. This translation can similarly be configured for instance using a new RRC field nr-NTN or similar, which indicates that the cell / frequency is NR NTN.

[0303] Examples of the translation or omission may include one or more of the following:

[0304] - ul-SyncValidityDuration may be taken as the value for ntn-UlSyncValidityDuration.

[0305] - nta-CommonParameters fields. In this case, not the signalled values, i.e. the signalled integers, but rather the signalled absolute values may be used. This is because the signalled integers that are later translated to an absolute value are different. This may apply to the (n)TA common, the (n)TA drift (first time-derivative of the (n)TA common) and the TA drift variation (second time-derivate of the (n)TA common).

[0306] - k-offset may be translated in to cellSpecificKOffset

[0307] Certain signalling examples described above may apply to both connected mode and RRC idle mode. In the case of RRC connected mode, the UE may be configured the above dedicatedly. An example of the above techniques in RRC connected mode is illustrated in Figure 11.

[0308] In various embodiments, the NR NTN cell may signal the E-UTRAN NTN configuration for a specific E-UTRAN NTN cell or frequency. Similarly, the E-UTRAN NTN cell may signal the NR NTN configuration transparently for a cell or frequency. If this is broadcast, then an explicit flag may be included to indicate this.

[0309] The neighbouring NTN inter-RAT ephemeris (NR NTN ephemeris or E-UTRAN NTN ephemeris) may be signalled in the NTN-specific SIB or in any other suitable SIB.

[0310] Idle mode measurements for mobility purposes

[0311] When measuring a cell in idle mode, the UE may need to rely on broadcast information in various SIBs.

[0312] In order to "tie" an inter-RAT ephemeris element to an inter-RAT frequency, an Identity (ID) relating to the ephemeris, such as an satelliteID (as already introduced in IoT NTN) may be used. Thus, in various embodiments, a satelliteID may be introduced for an inter-RAT frequency or cell. In E-UTRAN this may be introduced, for example, in SIB24 as part of CarrierFreqNR. And in NR, this may be introduced, for example, as part of SIB5 in CarrierFreqEUTRA.

[0313] Figure 12 illustrates an exemplary method, for a UE, for mobility to an Non Terrestrial Network (NTN).

[0314] Referring to Figure 12, in a first operation 1201, the UE receives, from a first base station to which the UE is connected (e.g. a base station associated with a Terrestrial Network (TN) cell), a first message relating to a handover of the UE (e.g. an RRCConnectionReconfiguration message comprising mobilityControlInfo).

[0315] In a second operation 1202, in response to the first message, the UE transmits, to a second base station to which the UE is to be handed over, a second message relating to the handover (e.g. an RRCConnectionReconfigurationComplete message).

[0316] In the second operation 1202, it is determined whether the second base station is associated with an NTN cell. If (e.g. only if) the second base station is associated with an NTN cell, the second message transmitted in the second operation 1202 includes information relating to a Global Navigation Satellite System (GNSS) measurement (e.g. gnss-validityDuration and / or gnss-PositionFixDuration).

[0317] Figure 13 illustrates an exemplary method, for a UE, for inter-RAT mobility.

[0318] Referring to Figure 13, in a first operation 1301, the UE (e.g. a UE in an idle mode) performs a procedure for mobility of the UE from a first base station to a second base station. The first base station is associated with a TN cell of a first Radio Access Technology (RAT) type (e.g. a base station associated with an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) TN cell) and the second base station is associated with an NTN cell of a second RAT type (e.g. a base station associated with a New Radio (NR) NTN cell).

[0319] In a second operation 1302, the UE receives, from the first base station in one or more certain System Information Blocks (SIBs) (e.g. SIB19, SIB24, SIB31 and / or any other suitable SIB for providing satellite information), satellite information for NTN access (e.g. ephemeris and / or a satellite ID associated with frequency information for cell reselection).

[0320] The skilled person will appreciate that the various techniques disclosed herein are not only applicable to satellite payloads, but can also apply to other platforms, for example HAPS. Accordingly, references to "satellite" may include references not only to satellites but also other NTN platforms or payloads.

[0321] The skilled person will appreciate that the various techniques disclosed herein are not only applicable to "serving" cells and "neighbouring" cells but to any other suitable types of cells, which may be referred to as "first" and "second" cells, respectively.

[0322] The skilled person will appreciate that the various techniques disclosed herein may be applied to gNB, NG-RAN cases and all related RRC signalling and / or messages, and to X2, Xn, S1, NG, F1 signalling and messages, and / or related network entities (e.g. MME, AMF, other).

[0323] Figure 14 is a block diagram of an exemplary network entity that may be used in examples of the disclosure. For example, a UE and / or base station in the examples of Figures 1-13 may comprise an entity of Figure 14. The skilled person will appreciate that a network entity may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[0324] The entity 1400 comprises a processor (or controller) 1401, a transmitter 1403 and a receiver 1405. The receiver 1405 is configured for receiving one or more messages from one or more other network entities, for example as described above. The transmitter 1403 is configured for transmitting one or more messages to one or more other network entities, for example as described above. The processor 1401 is configured for performing one or more operations, for example according to the operations as described above.

[0325] Specification Examples

[0326] The following illustrate examples in which the specification may be modified to incorporate one or more of the techniques described herein.

[0327] Example 1

[0328] ------------------------ 3GPP TS 36.331 V17.5.0 ------------------------

[0329] 5.3.5.4 Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE (handover)

[0330] If the RRCConnectionReconfiguration message includes the mobilityControlInfo and the UE is able to comply with the configuration included in this message, the UE shall:

[0331] ...OMITTED...

[0332] 1> start synchronising to the DL of the target PCell;

[0333] NOTE 1: The UE should perform the handover as soon as possible following the reception of the RRC message triggering the handover, which could be before confirming successful reception (HARQ and ARQ) of this message.

[0334] ...OMITTED...

[0335] 1> else (if daps-HO is not configured):

[0336] 2> reset MCG MAC and SCG MAC, if configured;

[0337] 2> release uplinkDataCompression, if configured;

[0338] 2> re-establish PDCP for all RBs configured with pdcp-config that are established;

[0339] NOTE 2: The handling of the radio bearers after the successful completion of the PDCP re-establishment, e.g. the re-transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of the SN and the HFN, is specified in TS 36.323 [8].

[0340] NOTE 2a: At handover the reestablishPDCP flag will be set for all RBs configured with NR PDCP in nr-RadioBearerConfig1 or nr-RadioBearerConfig2 TS 38.331

[0082] which will cause the PDCP entity to be re-established also for these RBs.

[0341] 2> re-establish MCG RLC and SCG RLC, if configured, for all RBs that are established;

[0342] ...OMITTED...

[0343] 1> apply the value of the newUE-Identity as the C-RNTI in the target MCG;

[0344] 1> if the RRCConnectionReconfiguration message includes the fullConfig:

[0345] 2> perform the radio configuration procedure as specified in 5.3.5.8;

[0346] 1> configure lower layers in accordance with the received radioResourceConfigCommon;

[0347] 1> if the received RRCConnectionReconfiguration message includes the rach-Skip:

[0348] 2> configure lower layers to apply the rach-Skip for the target MCG, as specified in TS 36.213

[0023] and 36.321 [6];

[0349] 1> if UE supports timing advance reporting and the received radioResourceConfigCommon includes the ta-Report:

[0350] 2> instruct the associated MAC entity to trigger Timing Advance reporting;

[0351] 1> configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received mobilityControlInfo;

[0352] ...OMITTED...

[0353] 1> if the received RRCConnectionReconfiguration includes the systemInformationBlockType1Dedicated:

[0354] 2> perfom the actions upon reception of the SystemInformationBlockType1 message as specified in 5.2.2.7;

[0355] 1> if the received RRCConnectionReconfiguration includes the systemInformationBlockType31Dedicated:

[0356] 2> perform the actions upon reception of the SystemInformationBlockType31 message as specified in 5.2.2.39;

[0357] 1> perform the measurement related actions as specified in 5.5.6.1;

[0358] 1> if the RRCConnectionReconfiguration message includes the measConfig:

[0359] 2> perform the measurement configuration procedure as specified in 5.5.2;

[0360] 1> perform the measurement identity autonomous removal as specified in 5.5.2.2a;

[0361] ...OMITTED...

[0362] 1> if the RRCConnectionReconfiguration message includes the sl-V2X-ConfigDedicated or mobilityControlInfoV2X:

[0363] 2> perform the V2X sidelink communication dedicated configuration procedure as specified in 5.3.10.15a;

[0364] NOTE 2d: In case of conditional reconfiguration the text "if the received RRCConnectionReconfiguration. . ." corresponds to applying the stored RRCConnectionReconfiguration message (according to 5.3.5.9.5).

[0365] 1> if the UE is configured to operate in EN-DC as result of this procedure, forward upperLayerIndication, as if the UE receives this field from SIB2, to upper layers, otherwise indicate upper layers absence of this field;

[0366] 1> set the content of RRCConnectionReconfigurationComplete message as follows:

[0367] ...OMITTED...

[0368] 2> if the target cell is an UE is connected to NTN cell:

[0369] 3> include gnss-validityDuration in accordance with the remaining time of the GNSS validity duration;

[0370] 1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission;

[0371] 1> if MAC successfully completes the random access procedure; or

[0372] 1> if MAC indicates the successful reception of a PDCCH transmission addressed to C-RNTI and if rach-Skip is configured:

[0373] 2> stop timer T304;

[0374] 2> if daps-HO is configured for any DRB:

[0375] 3> stop timer T310 for the source PCell, if running;

[0376] 3> for each DAPS bearer trigger UL data switching, as specified in TS 36.323 [8];

[0377] 2> release rach-Skip;

[0378] 2> apply the parts of the CQI reporting configuration, the scheduling request configuration and the sounding RS configuration that do not require the UE to know the SFN of the target PCell, if any;

[0379] 2> apply the parts of the measurement and the radio resource configuration that require the UE to know the SFN of the target PCell (e.g. measurement gaps, periodic CQI reporting, scheduling request configuration, sounding RS configuration), if any, upon acquiring the SFN of the target PCell;

[0380] NOTE 3: Whenever the UE shall setup or reconfigure a configuration in accordance with a field that is received it applies the new configuration, except for the cases addressed by the above statements.

[0381] ...OMITTED...

[0382] 2> the procedure ends;

[0383] NOTE 4: The UE is not required to determine the SFN of the target PCell by acquiring system information from that cell before performing RACH access in the target PCell, except for BL UEs or UEs in CE when sameSFN-Indication is not present in mobilityControlInfo.

[0384] ------------------------ 3GPP TS 36.331 V17.5.0 ------------------------

[0385] Example 2

[0386] ------------------------ 3GPP TS 36.331 V17.5.0 ------------------------

[0387] 5.3.5.4 Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE (handover)

[0388] If the RRCConnectionReconfiguration message includes the mobilityControlInfo and the UE is able to comply with the configuration included in this message, the UE shall:

[0389] ...OMITTED...

[0390] 1> start synchronising to the DL of the target PCell;

[0391] NOTE 1: The UE should perform the handover as soon as possible following the reception of the RRC message triggering the handover, which could be before confirming successful reception (HARQ and ARQ) of this message.

[0392] ...OMITTED...

[0393] 1> else (if daps-HO is not configured):

[0394] 2> reset MCG MAC and SCG MAC, if configured;

[0395] 2> release uplinkDataCompression, if configured;

[0396] 2> re-establish PDCP for all RBs configured with pdcp-config that are established;

[0397] NOTE 2: The handling of the radio bearers after the successful completion of the PDCP re-establishment, e.g. the re-transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of the SN and the HFN, is specified in TS 36.323 [8].

[0398] NOTE 2a: At handover the reestablishPDCP flag will be set for all RBs configured with NR PDCP in nr-RadioBearerConfig1 or nr-RadioBearerConfig2 TS 38.331

[0082] which will cause the PDCP entity to be re-established also for these RBs.

[0399] 2> re-establish MCG RLC and SCG RLC, if configured, for all RBs that are established;

[0400] ...OMITTED...

[0401] 1> apply the value of the newUE-Identity as the C-RNTI in the target MCG;

[0402] 1> if the RRCConnectionReconfiguration message includes the fullConfig:

[0403] 2> perform the radio configuration procedure as specified in 5.3.5.8;

[0404] 1> configure lower layers in accordance with the received radioResourceConfigCommon;

[0405] 1> if the received RRCConnectionReconfiguration message includes the rach-Skip:

[0406] 2> configure lower layers to apply the rach-Skip for the target MCG, as specified in TS 36.213

[0023] and 36.321 [6];

[0407] 1> if UE supports timing advance reporting and the received radioResourceConfigCommon includes the ta-Report:

[0408] 2> instruct the associated MAC entity to trigger Timing Advance reporting;

[0409] 1> configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received mobilityControlInfo;

[0410] ...OMITTED...

[0411] 1> if the received RRCConnectionReconfiguration includes the systemInformationBlockType1Dedicated:

[0412] 2> perfom the actions upon reception of the SystemInformationBlockType1 message as specified in 5.2.2.7;

[0413] 1> if the received RRCConnectionReconfiguration includes the systemInformationBlockType31Dedicated:

[0414] 2> perform the actions upon reception of the SystemInformationBlockType31 message as specified in 5.2.2.39;

[0415] 1> perform the measurement related actions as specified in 5.5.6.1;

[0416] 1> if the RRCConnectionReconfiguration message includes the measConfig:

[0417] 2> perform the measurement configuration procedure as specified in 5.5.2;

[0418] 1> perform the measurement identity autonomous removal as specified in 5.5.2.2a;

[0419] ...OMITTED...

[0420] 1> if the RRCConnectionReconfiguration message includes the sl-V2X-ConfigDedicated or mobilityControlInfoV2X:

[0421] 2> perform the V2X sidelink communication dedicated configuration procedure as specified in 5.3.10.15a;

[0422] NOTE 2d: In case of conditional reconfiguration the text "if the received RRCConnectionReconfiguration. . ." corresponds to applying the stored RRCConnectionReconfiguration message (according to 5.3.5.9.5).

[0423] 1> if the UE is configured to operate in EN-DC as result of this procedure, forward upperLayerIndication, as if the UE receives this field from SIB2, to upper layers, otherwise indicate upper layers absence of this field;

[0424] 1> set the content of RRCConnectionReconfigurationComplete message as follows:

[0425] ...OMITTED...

[0426] 2> if the received RRCConnectionReconfiguration included systemInformationBlockType31dedicated UE is connected to NTN:

[0427] 3> include gnss-validityDuration in accordance with the remaining time of the GNSS validity duration;

[0428] 1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission;

[0429] 1> if MAC successfully completes the random access procedure; or

[0430] 1> if MAC indicates the successful reception of a PDCCH transmission addressed to C-RNTI and if rach-Skip is configured:

[0431] 2> stop timer T304;

[0432] 2> if daps-HO is configured for any DRB:

[0433] 3> stop timer T310 for the source PCell, if running;

[0434] 3> for each DAPS bearer trigger UL data switching, as specified in TS 36.323 [8];

[0435] 2> release rach-Skip;

[0436] 2> apply the parts of the CQI reporting configuration, the scheduling request configuration and the sounding RS configuration that do not require the UE to know the SFN of the target PCell, if any;

[0437] 2> apply the parts of the measurement and the radio resource configuration that require the UE to know the SFN of the target PCell (e.g. measurement gaps, periodic CQI reporting, scheduling request configuration, sounding RS configuration), if any, upon acquiring the SFN of the target PCell;

[0438] NOTE 3: Whenever the UE shall setup or reconfigure a configuration in accordance with a field that is received it applies the new configuration, except for the cases addressed by the above statements.

[0439] ...OMITTED...

[0440] 2> the procedure ends;

[0441] NOTE 4: The UE is not required to determine the SFN of the target PCell by acquiring system information from that cell before performing RACH access in the target PCell, except for BL UEs or UEs in CE when sameSFN-Indication is not present in mobilityControlInfo.

[0442] ------------------------ 3GPP TS 36.331 V17.5.0 ------------------------

[0443] Example 3

[0444] ------------------------ 3GPP TS 36.423 V17.5.0 ------------------------

[0445] 8.2 Basic mobility procedures

[0446] 8.2.1 Handover Preparation

[0447] 8.2.1.1 General

[0448] [text omitted]

[0449] If the gnss-ValidityDuration IE is contained in the HANDOVER REQUEST message, the target eNB shall, if supported, store the received information in the UE context, and use this information, as needed, during the handover from TN to NTN.

[0450] 9.1.1 Messages for Basic Mobility Procedures

[0451] 9.1.1.1 HANDOVER REQUEST

[0452] This message is sent by the source eNB to the target eNB to request the preparation of resources for a handover.

[0453] Direction: source eNB → target eNB.

[0454]

[0455] ------------------------ 3GPP TS 36.423 V17.5.0 ------------------------

[0456] ------------------------ 3GPP TS 38.423 V17.5.0 ------------------------

[0457] 8.2 Basic mobility procedures

[0458] 8.2.1 Handover Preparation

[0459] 8.2.1.1 General

[0460] [text omitted]

[0461] If the gnss-ValidityDuration IE is contained in the HANDOVER REQUEST message, the target NG-RAN shall, if supported, store the received information in the UE context, and use this information, as needed, during the handover from TN to NTN.

[0462] 9.1.1 Messages for Basic Mobility Procedures

[0463] 9.1.1.1 HANDOVER REQUEST

[0464] This message is sent by the source NG-RAN node to the target NG-RAN node to request the preparation of resources for a handover.

[0465] Direction: source NG-RAN node → target NG-RAN node.

[0466]

[0467] ------------------------ 3GPP TS 38.423 V17.5.0 ------------------------

[0468] Example 4

[0469] Changes are indicated in bold

[0470] ------------------------ 3GPP TS 38.331 V17.5.0 ------------------------

[0471] - SIB19

[0472] SIB19 contains satellite assistance information for NTN access.

[0473] SIB19 information element

[0474]

[0475]

[0476] ------------------------ 3GPP TS 38.331 V17.5.0 ------------------------

[0477] Example 5

[0478] ------------------------ 3GPP TS 36.331 V17.5.0 ------------------------

[0479] 5.4.2.3 Reception of the RRCConnectionReconfiguration by the UE

[0480] If the UE is able to comply with the configuration included in the RRCConnectionReconfiguration message, the UE shall:

[0481] 1> if the RRCConnectionReconfiguration message does not include the fullConfig and the UE is connected to 5GC (i.e., delta signalling during intra 5GC handover):

[0482] 2> re-use the source SDAP and PDCP configurations (i.e., current SDAP / PDCP configurations for all RBs from source RAT prior to the reception of the inter-RAT handover RRCConnectionReconfiguration message);

[0483] 1> if the RRCConnectionReconfiguration message includes the fullConfig and the source RAT was E-UTRA (i.e., intra-RAT inter-system handover):

[0484] 2> except the MCG C-RNTI, release / clear all current dedicated radio resources and configurations, including all SDAP (if configured), PDCP, RLC, logical channel configurations for the DRBs and the logged measurement configuration (if configured);

[0485] 2> release / clear all current common radio configurations;

[0486] 2> for each srb-Identity value included in the srb-ToAddModList (SRB reconfiguration):

[0487] 3> apply the specified configuration defined in 9.1.2 for the corresponding SRB;

[0488] 3> apply the corresponding default RLC configuration for the SRB specified in 9.2.1.1 for SRB1 or in 9.2.1.2 for SRB2;

[0489] 3> apply the corresponding default logical channel configuration for the SRB as specified in 9.2.1.1 for SRB1 or in 9.2.1.2 for SRB2;

[0490] 3> if the handoverType in securityConfigHO is set to fivegc-ToEPC (i.e, the UE is connecting to EPC):

[0491] 4> release the PDCP entity and establish it with an E-UTRA PDCP entity;

[0492] 3> else if the handoverType in securityConfigHO is set to epc-To5GC (i.e., the UE is connecting to 5GC):

[0493] 4> release the PDCP entity and establish it with an NR PDCP and apply the corresponding default PDCP configuration for the SRB as specified in TS 38.331

[0082] , clause 9.2.1;

[0494] 3> associate the RLC bearer of this SRB with the established PDCP entity;

[0495] 1> apply the default physical channel configuration as specified in 9.2.4;

[0496] 1> apply the default semi-persistent scheduling configuration as specified in 9.2.3;

[0497] 1> apply the default MAC main configuration as specified in 9.2.2;

[0498] 1> start timer T304 with the timer value set to t304, as included in the mobilityControlInfo;

[0499] 1> consider the target PCell to be one on the frequency indicated by the carrierFreq with a physical cell identity indicated by the targetPhysCellId;

[0500] 1> start synchronising to the DL of the target PCell;

[0501] 1> set the C-RNTI to the value of the newUE-Identity;

[0502] 1> for the target PCell, apply the downlink bandwidth indicated by the dl-Bandwidth;

[0503] 1> for the target PCell, apply the uplink bandwidth indicated by (the absence or presence of) the ul-Bandwidth;

[0504] 1> configure lower layers in accordance with the received radioResourceConfigCommon;

[0505] 1> configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received mobilityControlInfo;

[0506] 1> perform the radio resource configuration procedure as specified in 5.3.10.0;

[0507] 1> if the handoverType in securityConfigHO is set to fivegc-ToEPC:

[0508] 2> indicate to higher layer that the CN has changed from 5GC to EPC;

[0509] 2> derive the key KeNBbased on the mapped KASMEkey as specified for interworking between EPS and 5GS in TS 33.501

[0086] ;

[0510] 2> store the nextHopChainingCount-r15 value;

[0511] 1> else if the handoverType in securityConfigHO is set to intra5GC:

[0512] 2> if the keyChangeIndicator-r15 received in the securityConfigHO is set to TRUE:

[0513] 3> forward nas-Container to the upper layers, if included;

[0514] 3> update the KeNBkey based on the KAMFkey, as specified in TS 33.501

[0086] ;

[0515] 2> else:

[0516] 3> update the KeNBkey based on the current KgNBor the NH, using the nextHopChainingCount-r15 value indicated in the SecurityConfigHO, as specified in TS 33.501

[0086] ;

[0517] 2> store the nextHopChainingCount-r15 value;

[0518] 1> else if the handoverType in securityConfigHO is set to epc-To5GC:

[0519] 2> forward the nas-Container to the upper layers;

[0520] 2> derive the KeNBkey, as specified in TS 33.501

[0086] ;

[0521] 1> else:

[0522] 2> forward the nas-SecurityParamToEUTRA to the upper layers;

[0523] 2> derive the KeNBkey, as specified in TS 33.401

[0032] ;

[0524] 1> derive the KRRCintkey associated with the integrityProtAlgorithm, as specified in TS 33.401

[0032] ;

[0525] 1> derive the KRRCenckey and the KUPenckey associated with the cipheringAlgorithm, as specified in TS 33.401

[0032] ;

[0526] 1> if capable of user plane integrity protection:

[0527] 2> derive the KUPintkey associated with the integrityProtAlgorithm, as specified in TS 33.401

[0032] ;

[0528] 1> if the received RRCConnectionReconfiguration includes the systemInformationBlockType31Dedicated:

[0529] 2> perform the actions upon reception of the SystemInformationBlockType31 message as specified in 5.2.2.39;

[0530] 1> if the received RRCConnectionReconfiguration includes the sk-Counter:

[0531] 2> perform key update procedure as specified in in TS 38.331

[0082] , clause 5.3.5.7;

[0532] 1> if the received RRCConnectionReconfiguration includes the nr-SecondaryCellGroupConfig:

[0533] 2> perform NR RRC Reconfiguration as specified in TS 38.331

[0082] , clause 5.3.5.3;

[0534] 1> if the received RRCConnectionReconfiguration includes the nr-RadioBearerConfig1:

[0535] 2> perform radio bearer configuration as specified in TS 38.331

[0082] , clause 5.3.5.6;

[0536] 1> if the received RRCConnectionReconfiguration includes the nr-RadioBearerConfig2:

[0537] 2> perform radio bearer configuration as specified in TS 38.331

[0082] , clause 5.3.5.6;

[0538] 1> if the handoverType in securityConfigHO is set to fivegc-ToEPC or if the handoverType-v1530 is not present:

[0539] 2> configure lower layers to apply the indicated integrity protection algorithm and the KRRCintkey immediately, i.e. the indicated integrity protection configuration shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate the successful completion of the procedure;

[0540] 2> configure lower layers to apply the indicated ciphering algorithm, the KRRCenckey and the KUPenckey immediately, i.e. the indicated ciphering configuration shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate the successful completion of the procedure;

[0541] 1> if the received RRCConnectionReconfiguration includes the sCellToAddModList:

[0542] 2> perform SCell addition as specified in 5.3.10.3b;

[0543] 1> if the RRCConnectionReconfiguration message includes the measConfig:

[0544] 2> perform the measurement configuration procedure as specified in 5.5.2;

[0545] 1> perform the measurement identity autonomous removal as specified in 5.5.2.2a;

[0546] 1> if the RRCConnectionReconfiguration message includes the otherConfig:

[0547] 2> perform the other configuration procedure as specified in 5.3.10.9;

[0548] 1> if the RRCConnectionReconfiguration message includes wlan-OffloadInfo:

[0549] 2> perform the dedicated WLAN offload configuration procedure as specified in 5.6.12.2;

[0550] 1> if the RRCConnectionReconfiguration message includes rclwi-Configuration:

[0551] 2> perform the WLAN traffic steering command procedure as specified in 5.6.16.2;

[0552] 1> if the RRCConnectionReconfiguration message includes lwa-Configuration:

[0553] 2> perform the LWA configuration procedure as specified in 5.6.14.2;

[0554] 1> if the RRCConnectionReconfiguration message includes lwip-Configuration:

[0555] 2> perform the LWIP reconfiguration procedure as specified in 5.6.17.2;

[0556] 1> set the content of RRCConnectionReconfigurationComplete message as follows:

[0557] 2> if the UE has radio link failure or handover failure information available in VarRLF-Report and if the RPLMN is included in plmn-IdentityList stored in VarRLF-Report:

[0558] 3> include rlf-InfoAvailable;

[0559] 2> if the UE has MBSFN logged measurements available for E-UTRA and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport and if T330 is not running:

[0560] 3> include logMeasAvailableMBSFN;

[0561] 2> else if the UE has logged measurements available for E-UTRA and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport:

[0562] 3> include the logMeasAvailable;

[0563] 3> if Bluetooth measurement results are included in the logged measurements the UE has available:

[0564] 4> include the logMeasAvailableBT;

[0565] 3> if WLAN measurement results are included in the logged measurements the UE has available:

[0566] 4> include the logMeasAvailableWLAN;

[0567] 2> if the UE has connection establishment failure information available in VarConnEstFailReport and if the RPLMN is equal to plmn-Identity stored in VarConnEstFailReport:

[0568] 3> include connEstFailInfoAvailable;

[0569] 2> if the received RRCConnectionReconfiguration message included nr-SecondaryCellGroupConfig:

[0570] 3> include scg-ConfigResponseNR in accordance with TS 38.331

[0082] , clause 5.3.5.3;

[0571] 2> if the target cell is an NTN cell:

[0572] 3> include gnss-validityDuration in accordance with the remaining time of the GNSS validity duration;

[0573] 1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new configuration;

[0574] 1> if the RRCConnectionReconfiguration message does not include rlf-TimersAndConstants set to setup:

[0575] 2> use the default values specified in 9.2.5 for timer T310, T311 and constant N310, N311;

[0576] 1> if MAC successfully completes the random access procedure:

[0577] 2> stop timer T304;

[0578] 2> apply the parts of the CQI reporting configuration, the scheduling request configuration and the sounding RS configuration that do not require the UE to know the SFN of the target PCell, if any;

[0579] 2> apply the parts of the measurement and the radio resource configuration that require the UE to know the SFN of the target PCell (e.g. measurement gaps, periodic CQI reporting, scheduling request configuration, sounding RS configuration), if any, upon acquiring the SFN of the target PCell;

[0580] NOTE 1: Whenever the UE shall setup or reconfigure a configuration in accordance with a field that is received it applies the new configuration, except for the cases addressed by the above statements.

[0581] 2> enter E-UTRA RRC_CONNECTED, upon which the procedure ends;

[0582] NOTE 2: The UE is not required to determine the SFN of the target PCell by acquiring system information from that cell before performing RACH access in the target PCell.

[0583] NOTE 3: If the handover is from NR and target CN is 5GC, the delta configuration on PDCP and SDAP can be used for intra-system inter-RAT handover. For other cases, source RAT configuration is not considered when the UE applies the reconfiguration message of target RAT.

[0584] ------------------------ 36.331 V17.5.0 example ------------------------

[0585] Figure 15 illustrates a block diagram of a user equipment that illustrates various hardware components.

[0586] As shown in FIG. 15, the UE according to an embodiment may include a transceiver 1510, a memory 1520, and a processor 1530. The transceiver 1510, the memory 1520, and the processor 1530 of the UE may operate according to a communication method of the UE described above. However, the components of the UE are not limited thereto. For example, the UE may include more or fewer components than those described above. In addition, the processor 1530, the transceiver 1510, and the memory 1520 may be implemented as a single chip. Also, the processor 1530 may include at least one processor. Furthermore, the UE of FIG. 16 corresponds to the UE of the FIG. 4.

[0587] The transceiver 1510 collectively refers to a UE receiver and a UE transmitter, and may transmit / receive a signal to / from a base station or a network entity. The signal transmitted or received to or from the base station or a network entity may include control information and data. The transceiver 1510 may include a RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and a RF receiver for amplifying low-noise and down-converting a frequency of a received signal. However, this is only an example of the transceiver 1510 and components of the transceiver 1510 are not limited to the RF transmitter and the RF receiver.

[0588] Also, the transceiver 1510 may receive and output, to the processor 1530, a signal through a wireless channel, and transmit a signal output from the processor 1530 through the wireless channel.

[0589] The memory 1520 may store a program and data required for operations of the UE. Also, the memory 1520 may store control information or data included in a signal obtained by the UE. The memory 1520 may be a storage medium, such as read-only memory (ROM), random access memory (RAM), a hard disk, a CD-ROM, and a DVD, or a combination of storage media.

[0590] The processor 1530 may control a series of processes such that the UE operates as described above. For example, the transceiver 1510 may receive a data signal including a control signal transmitted by the base station or the network entity, and the processor 1530 may determine a result of receiving the control signal and the data signal transmitted by the base station or the network entity.

[0591] Figure 16 illustrates a block diagram of a base station that illustrates various hardware components.

[0592] As shown in FIG. 16, the base station according to an embodiment may include a transceiver 1610, a memory 1620, and a processor 1630. The transceiver 1610, the memory 1620, and the processor 1630 of the base station may operate according to a communication method of the base station described above. However, the components of the base station are not limited thereto. For example, the base station may include more or fewer components than those described above. In addition, the processor 1630, the transceiver 1610, and the memory 1620 may be implemented as a single chip. Also, the processor 1630 may include at least one processor.

[0593] The transceiver 1610 collectively refers to a base station receiver and a base station transmitter, and may transmit / receive a signal to / from a terminal(UE) or a network entity. The signal transmitted or received to or from the terminal or a network entity may include control information and data. The transceiver 1610 may include a RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and a RF receiver for amplifying low-noise and down-converting a frequency of a received signal. However, this is only an example of the transceiver 1610 and components of the transceiver 1610 are not limited to the RF transmitter and the RF receiver.

[0594] Also, the transceiver 1610 may receive and output, to the processor 1630, a signal through a wireless channel, and transmit a signal output from the processor 1630 through the wireless channel.

[0595] The memory 1620 may store a program and data required for operations of the base station. Also, the memory 1620 may store control information or data included in a signal obtained by the base station. The memory 1620 may be a storage medium, such as read-only memory (ROM), random access memory (RAM), a hard disk, a CD-ROM, and a DVD, or a combination of storage media.

[0596] The processor 1630 may control a series of processes such that the base station operates as described above. For example, the transceiver 1610 may receive a data signal including a control signal transmitted by the terminal, and the processor 1630 may determine a result of receiving the control signal and the data signal transmitted by the terminal.

[0597] Figure 17 illustrates a block diagram of a network entity that illustrates various hardware components.

[0598] As shown in FIG. 17, the network entity includes a transceiver 1710, a memory 1720, and a processor 1730. The transceiver 1710, the memory 1720, and the processor 1730 of the network entity may operate according to a communication method of the network entity described above. However, the components of the terminal network entity are not limited thereto. For example, the network entity may include fewer or a greater number of components than those described above. In addition, the processor 1730, the transceiver 1710, and the memory 1720 may be implemented as a single chip. Also, the processor 1730 may include at least one processor.

[0599] The network entity includes at least one entity of a core network. For example, the network entity includes an Access and mobility management function (AMF), a session management function (SMF), a policy control function (PCF), a network repository function (NRF), a user plane function (UPF), a network slicing selection function (NSSF), an authentication server function (AUSF), a unified data management (UDM) and a network exposure function (NEF), but the network entity is not limited thereto. For example, the network entity includes a user equipment (UE), a base station (BS).

[0600] The transceiver 1710 collectively refers to a network entity receiver and a network entity transmitter, and may transmit / receive a signal to / from a base station or a UE. The signal transmitted or received to or from the base station or the UE may include control information and data. In this regard, the transceiver 1710 may include an RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and an RF receiver for amplifying low-noise and down-converting a frequency of a received signal. However, this is only an example of the transceiver 1710 and components of the transceiver 1710 are not limited to the RF transmitter and the RF receiver.

[0601] The transceiver 1710 may receive and output, to the processor 1730, a signal through a wireless channel, and transmit a signal output from the processor 1730 through the wireless channel.

[0602] The memory 1720 may store a program and data required for operations of the network entity. Also, the memory 1720 may store control information or data included in a signal obtained by the network entity. The memory 1720 may be a storage medium, such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD, or a combination of storage media.

[0603] The processor 1730 may control a series of processes such that the network entity operates as described above. For example, the transceiver 1710 may receive a data signal including a control signal, and the processor 1730 may determine a result of receiving the data signal.

[0604] The techniques described herein may be implemented using any suitably configured apparatus and / or system. Such an apparatus and / or system may be configured to perform a method according to any aspect, embodiment, example or claim disclosed herein. Such an apparatus may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). The one or more elements may be implemented in the form of hardware, software, or any combination of hardware and software.

[0605] It will be appreciated that examples of the disclosure may be implemented in the form of hardware, software or any combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape or the like.

[0606] It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement various embodiments of the disclosure. Accordingly, various embodiments provide a program comprising code for implementing a method, apparatus or system according to any example, embodiment, aspect and / or claim disclosed herein, and / or a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection.

[0607] While the disclosure has been shown and described with reference to various embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the disclosure, as defined by the appended claims.

[0608] Abbreviations / Definitions

[0609] In the disclosure, the following acronyms / definitions are used.

[0610] 3GPP 3rdGeneration Partnership Project

[0611] 4G 4thGeneration

[0612] 5G 5thGeneration

[0613] 5GC 5G Core

[0614] CN Core Network

[0615] eMTC enhanced Machine Type Communications

[0616] eNB Base Station

[0617] EN-DC E-UTRAN-NR Dual Connectivity

[0618] en-gNB gNB that can connect with EPC and eNB

[0619] EPC Evolved Packet Core

[0620] E-UTRAN Evolved Universal Terrestrial Radio Access Network

[0621] GNSS Global Navigation Satellite System

[0622] GEO Geosynchronous Equatorial Orbit

[0623] gNB 5G Base Station

[0624] HAPS High Altitude Platform Station

[0625] ID Identity / Identification

[0626] IE Information Element

[0627] IoT Internet of Things

[0628] LEO Lower Earth Orbit

[0629] LTE Long Term Evolution

[0630] LTE-M Long Term Evolution Machine Type Communication

[0631] MTC Machine-Type Communications

[0632] NB Narrowband

[0633] NG Next Generation

[0634] NG-RAN Next Generation Radio Access Network

[0635] NR New Radio

[0636] NTN Non-Terrestrial Network

[0637] PDCP Packet Data Convergence Protocol

[0638] PVT Position, Velocity, Time

[0639] RAN Radio Access Network

[0640] RAT Radio Access Technology

[0641] RLF Radio Link Failure

[0642] RRC Radio Resource Control

[0643] SDAP Service Data Adaption Protocol

[0644] SIB System Information Block

[0645] TA Timing Advance

[0646] TLE Two-Line Element

[0647] TN Terrestrial Network

[0648] TS Technical Specification

[0649] Txxx Timer xxx

[0650] UE User Equipment

[0651] X2 / Xn Interface between RAN nodes

Claims

1.A method performed by a user equipment (UE) in a wireless communication system, the method comprising:receiving, from a first base station associated with a source cell, a first message for a handover from the source cell to a target cell; andtransmitting, to a second base station associated with the target cell, a second message based on the handover,wherein the target cell is a non terrestrial network (NTN) cell and the second message includes global navigation satellite system (GNSS) related information.2.The method of claim 1,wherein the GNSS related information includes information on a GNSS validity duration.3.The method of claim 1,wherein the GNSS related information includes information on a time duration required for a GNSS position.4.The method of claim 1,wherein the source cell is a terrestrial network (TN) cell associated with an evolved universal terrestrial radio access network (E-UTRAN) and the target cell is the NTN cell associated with new radio (NR).5.The method of claim 4, further comprising:receiving, from the first base station, a system information block (SIB) including satellite information for an access to the NTN cell.6.The method of claim 5,wherein the SIB is an SIB 24 and the SIB includes information on a satellite identifier.7.The method of claim 1,wherein the first message is a radio resource control (RRC) connection reconfiguration message.8.The method of claim 7,wherein the second message is a RRC connection reconfiguration complete message.9.A user equipment (UE) in a wireless communication system, the UE comprising:a transceiver; anda controller coupled with the transceiver and configured to:receive, from a first base station associated with a source cell, a first message for a handover from the source cell to a target cell; andtransmit, to a second base station associated with the target cell, a second message based on the handover,wherein the target cell is a non terrestrial network (NTN) cell and the second message includes global navigation satellite system (GNSS) related information.10.The UE of claim 9,wherein the GNSS related information includes information on a GNSS validity duration.11.The UE of claim 9,wherein the GNSS related information includes information on a time duration required for a GNSS position.12.The UE of claim 9,wherein, the source cell is a terrestrial network (TN) cell associated with an evolved universal terrestrial radio access network (E-UTRAN) and the target cell is the NTN cell associated with new radio (NR).13.The UE of claim 12, wherein the controller is further configured to:receive, from the first base station, a system information block (SIB) including satellite information for an access to the NTN cell.14.The UE of claim 13,wherein the SIB is an SIB24 and the SIB includes information on a satellite identifier.15.The UE of claim 9,wherein the first message is a radio resource control (RRC) connection reconfiguration message, andwherein the second message is a RRC connection reconfiguration complete message.

Images