Mobility between terrestrial and non-terrestrial networks

Abstract

Mobility of a User Equipment (UE) to a Non-Terrestrial Network (NTN) such as a high-altitude platform or low earth orbit (LEO) satellite. In a first method, the UE receives from a first base station,

Description

BACKGROUND Field Certain examples of the present disclosure provide one or more techniques for mobility between a Terrestrial Network (TN) and a Non Terrestrial Network (NTN). For example, certain examples of the present 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 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR) networks. Description of the Related Art Herein, the following document may be referenced: [1] 3GPP TS 36.331 V17.5.0 “Radio Resource Control (RRC)”, Release 17, June 2023. [2] 3GPP TS 38.331 V17.5.0 “Radio Resource Control (RRC)”, Release 17, June 2023. [3] 3GPP TS 36.423 V17.5.0 “X2 application protocol (X2AP)”, Release 17, June 2023. Various acronyms, abbreviations and definitions used in the present disclosure are defined at the end of this description. 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. 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). Internet of Things (loT) 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) loT devices (e.g. Narrowband (NB)-loT and Long Term Evolution Machine Type Communication (LTE-M), including enhanced Machine Type Communication (eMTC)). As noted in 3GPP RP-202689, loT operation is critical in remote areas with low / no cellular connectivity for many different industries. The capabilities of NB-loT and eMTC are a good fit for many applications but some applications may require satellite connectivity to provide coverage beyond terrestrial deployments. 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). Following the work items in Release 17 there were work items to enhance NR NTN (RP-220953, RAN#95-e March 2022) and loT NTN (RP-220979, RAN#95-e March 2022) in Release 18. 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 loT NTN. The work item description for loT NTN Release 18 is reproduced below (RP-223519): 4.1.1 loT-NTN Performance Enhancements in Rel-18 to address remaining issues from Rel-17 This work considers Rel-17 loT-NTN as baseline as well as Rel-17 NR-NTN outcome and the further loT-NTN performance enhancements objectives are listed below: Disabling ofHARQ feedback to mitigate impact ofHARQ stalling on UE data rates [RAN1,RAN2] Study and specif / 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. [RANI, RAN2] • NOTE: The need for RAN4 Core requirements for this objective will be identified after the conclusion on the need for improvements. 4.1.2 Mobility enhancements The following mobility enhancements objectives are listed. Support of neighbour cell measurements and corresponding measurement triggering before RLE, using Rel-17 (TN) NB-loT, eMTC as a baseline. [RAN2] Support signalling in system information of neighbour cell ephemeris, for eMTC and NB-loT [RAN2] 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] Define UE RRM core requirements for the above mobility enhancement features [RAN4], 4.1.3 Further enhancement to discontinuous coverage 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], Overview of NB-loT and LTE-M NB-loT is a 3GPP-defined network based on 4th Generation (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-loT is to serve massive loT 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: Support for enhanced coverage through low bandwidth and extreme amounts of repetitions. 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. 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-loT, the use case is to serve massive loT, but with more capabilities. Instead of being an entirely new type of device with major air interface changes as in NB-loT, the LTE-M inherits most feature of a regular LTE device, but with some adaptations for low complexity considerations. Overview of NTN System Information 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. In NR NTN, SIB19 contains the required information to access an NTN cell: ------------------------------3GPPTS 38.331 V17.5.0------------------------------ SIB19 SIB19 contains satellite assistance information for NTN access. SIB19 information element ntn-C-'-Tif ig-r utn^HeigRCil 1 11 ■ -1 r -Hi 'i 11 i 1IT1 -3:i.ii--rl^ -1*17 Rtf in.-. riL'icatiori-i'l^ 17113W17 nTr<’ii- / :-?^llc-nfigLiit~r^^ .1.’ i - nj ■ IT1I-1I-1 Th ’-11 ' IA_ -1^ t-rl- : — :T-ighCellCC'iifi / --l- ntn^Confio-El7 c a r ri e r Er e q -x 1T phyxC^lild-xl" 1TT1’-1 _: fi:-xl~ .• 1’ . , Eh / - • l.A -.. SIB19 field descriptions distanceThresh Distance from the serving cell reference location and is used in location-based measurement initiation in RRCJDLE and RRCJNACTIVE, as defined in TS 38.304

[20] , Each step represents 50m. ntn-Config Provides parameters needed for the UE to access NR via NTN access such as Ephemeris data, common TA parameters, k_offset, validity duration for UL sync information and epoch.___________________________________________________________________________ ntn NeighCellConfigUst, nin-NeighCeiiConfigUstExi Provides a list of NTN neighbour cells including their ntn-Config, carrier frequency and PhysCellld. This set includes all elements of ntn-NeighCellConfigList and all elements of ntn-NeighCellConfigListExt. If ntn-Config is absent for an entry in ntn-NeighCellConfigListExt, the ntn-Config provided in the entry at the same position in ntn-NeighCellConfigList applies. Network provides ntn-Config for the first entry of ntn-NeighCellConfigList. If the ntn-Config is absent for any other entry in ntn-NeighCellConfigList, the ntn-Config provided in the previous entry in ntn-NeighCellConfigList applies. referenceLocation Reference location of the serving cell provided via NTN quasi-Earth fixed system and is used in locationbased measurement initiation in RRC IDLE and RRC INACTIVE, as defined in TS 38.304

[20] . t-Service Indicates the time information on when a cell provided via NTN quasi-Earth fixed system is going to stop serving the area it is currently covering. The field indicates a time in multiples of 10 ms after 00:00:00 on Gregorian calendar date 1 January, 1900 (midnight between Sunday, December 31,1899 and Monday, January 1, 1900). The exact stop time is between the time indicated by the value of this field minus 1 and the time indicated by the value of this field. ------------------------------3GPP TS 38.331 V17.5.0------------------------------ In loT NTN, SIB31 contains the required information to access an loT NTN cell: - SystemlnformationBlockType31 The IE SystemlnformatioriBlockType 31 contains satellite assistance information for the serving cell. SystemlnformationBlockType31 is only signalled in a NTN cell. SystemlnformationBlockType31 information element 3 / e temliif _ rmati . .-1 _ 3 :T / f e il-iV IE i lai"!:-: , IstelloriCritic31 Extension OCTET ETEZ1JG t'iclnf: -ri ~ 11 11 cCC' r u- -i bi I -i 1 :-- ---.-I CEQUEHCE : CHOICE { E / E- dl / bt ‘ ’ Ct - in: - ul ■ E[ 1 : i. .-u n b i t -tl ['.4 1-,1110 I r- i-, CEQCETCE — _ _ lElR 1 L1 . . d 1 C d _ ‘ I i FT 101IAL, 'mCCL, nt 3-i Y irnr_. 1 ri / 3ri ion- L-1 _ . —k -- 11$$ EUU1SFATE1. { 3S:5r:3: la, -lr, _ , $35, s4<', . $5$, $55, , 1120, 112 ", 1-4", 5 epochTime-rl-' FECTE / FE atavtEFli-rl" (1.. .1021), at artSutF r ?: a-rl- FETE FER nj . , -ETIdll^L, — E-Tffaat-rl 7 TFT””. -,. -), 10 im.-. L-.:v . . . -512 / I33333333333333333333333t --llv- A,?1U3T< >E- SystemlnformationBlockType31 field descriptions epochtime Epoch time of the satellite ephemeris data and common TA parameters, see TS 36.213

[23] , The reference point for epoch time of the serving satellite ephemeris and Common TA parameters is the uplink time synchronization reference point. epochTime is the starting time of a DL subframe indicated by startSFN and startSubframe. For serving cell, the startSFN indicates the current SFN or the next upcoming SFN after the frame where the message indicating the epochTime is received. If the field is absent, the UE uses the starting time of the DL subframe corresponding to the end of the SI window during which the SI message carrying SIB31 is transmitted. E-UTRAN always includes epochTime when SystemlnformationBlockType31 is provided through dedicated signalling. In case of handover or conditional handover, this field is based on the timing of the target cell, i.e. the startSFN and startSubFrame number indicated in this field refers to the SFN and sub-frame of the target cell, and UE considers the target cell epoch time (indicated by the startSFN and startSubFrame in this field) to be the frame nearest to the frame where RRCConnectfonReconffguratfon message is received.____________ k-Mac Scheduling offset used when downlink and uplink frame timing are not aligned at the eNB, see TS 36.213

[23] , Unit in ms. If the field if absent, the UE uses the (default) value of 0._______________________________________________________ k-Offset Scheduling offset used in the timing relationships in NTN, see TS 36.213

[23] , Unit in ms.____________________ nta-Common Network-controlled common TA, see TS 36.213

[23] , Unit of ps. Step of 32.55208 xw3ps. Actual value = field value * 32.55208 xw3. If the field is absent, the UE uses the (default) value of 0. nta-Commonbrift Drift rate of the common TA, see TS 36.213

[23] , Unit of ps / s. Step of 0.2 x 10 3 ps / s. Actual value = field value * 0.2 *103. If the field is absent, the UE uses the (default) value of 0. nta-CommonDriftVariation Drift rate variation of the common TA, see TS 36.213

[23] , Unit of ps / s2. Step of 0.2 xi O’4 ps / s2 Actual value = field value * 0.2 x10'4. If the field is absent, the UE uses the (default) value of 0. orbiialParameiers Instantaneous values of the satellite orbital parameters. The signalled values are only valid for the duration as defined by ul-SyncValidityDuration and epochTime. stateVectors Instantaneous values of the satellite state vectors. The signalled values are only valid for the duration as defined by ul-SyncValidityDuration and epochTime.________________________________________________________ ul-SyncValidityburaiion Validity duration of the satellite ephemeris data and common TA parameters, i.e. maximum time duration (from epochTime) during which the UE can apply the satellite ephemeris without acquiring new satellite ephemeris, see TS 36.213

[23] , Unit in second. Value s5 corresponds to 5 seconds, value s10 corresponds to 10 seconds and so on. ------------------------------3GPPTS 36.331 V17.5.0------------------------------ The system information contains the following: - 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: o Position, Velocity, Time (PVT) format. This describes a (X,Y,Z) position as well as a speed vector (vX, vY, vZ). o Orbital parameters. This describes the orbital movements of the satellite which is then used to infer the satellite position. 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): o Absolute TA common (23 bits). o Drift of the TA common, defining how the TA common drifts, i.e. the first derivative of the TA common (19 bits). o Variation of the TA common, defining how the TA common varies, i.e. the second derivative of the TA common (15 bits). - Synchronization validity duration. This is used to define how long the ephemeris and TA common is valid. - Epoch time. This defines when the synchronization validity duration should start. - K-Offset. This is a scheduling offset for timing relationship in NTN. K-Mac. This is a scheduling offset used when the downlink and uplink frame timing is not aligned. NR NTN specific information also includes (as part of 3GPP TS 38.331): o T-Service (signalled in SIB3 in loT NTN). o Reference location and distance threshold. This is used for location-based measurement initiation in RRC IDLE and RRC Connected mode. o Neighbour cell ephemeris. This is used for idle mode measurements. Overview of NTN System Information Acquisition 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). In loT 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 reacquire SIB31 in order to stay synchronized. In loT NTN, since an loT UE (LTE-M and NB-loT 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. If the loT 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. 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. 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. Overview of NTN Ephemeris Formats There are three ways of signalling the ephemeris in NTN: 1. PVT format, 2. Orbital ephemeris elements, and 3. TLE ephemeris elements (only used for Discontinuous Coverage in loT NTN). PVT Format PVT format signals XYZ position along with the speed vector vXYZ. This can be seen in the following information element: ------------------------------3GPPTS 36.331 V17.5.0------------------------------ - EphemerisStateVectors The IE EphemerisStateVectors provides satellite ephemeris in format of position and velocity state vectors in ECEF. EphemerisStateVectors information element -- '-jii[."r'-.HT r ir tn i i. ,’i ,t • -. i .sit i _ n.'.-rl positicnT-L-l-poc itionii-rl-’ --el: city k-ri ’ "el z 2i22yS-2ateVector-rl v it p. nFt ’ v ::- THTFRF.R '-kk. k ' . . - f. M -11 ) k <11. -, Cl. -.11. -. . l - l : : ::- I HWalk: । - 1k. : - k:. . Ik 111 k ) — A.k-ilkKk EphemerisStateVectors field descriptions positionX, positionY, positionZ X, Y, Z coordinate of satellite position state vector in ECEF. Unit in meter. Step of 1.3 m. Actual value = field value *1.3. velociiyVX, velocityVY, veiocityVZ X, Y, Z coordinate of satellite velocity state vector in ECEF. Unit in meter / second. Step of 0.06 m / s. Actual value = field value * 0.06. 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. Orbital Ephemeris Format 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. Ephemeris orbital elements are signalled by the following elements (164 bits total): SemiMajorAxis (33 bits) - Eccentricity (20 bits) - Periapsis (28 bits) Longitude (28 bits) Inclination (27 bits) - Anomaly (28 bits) TLE Orbital Parameters 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. 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): Inclination (21 bits) - Argument of perigee (22 bits) - Right ascension of the ascending node (22 bits) - Mean anomaly (22 bits) - Eccentricity (24 bits) Mean Motion (34 bits) B* signalled by (i) a decimal (18 bits), and (ii) an exponent (5 bits) Epoch star (21 bits) Overview of GNSS measurements in loT NTN Both loT 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 loT 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 3(a) UE is released (i.e. moved to RRC Idle mode) by eNB, and in Figure 3(b) UE releases itself, as defined in 3GPP TS 36.331 v17.5.0: ______________________ pp 36 331 \ / 17 5 0 5.3.3.21 UE actions upon indication of out-of-date GNSS position Upon indication that the GNSS position has become out-of-date while in RRCCONNECTED, the UE shall: I >perform the actions upon leaving RRC CONNECTED as specified in 5.3.12, with release cause 'other'. ----------------------3GPPTS 36.331 V17.5.0---------------------- One of the goals in 3GPP loT NTN Release 18 is to introduce measurement gaps where the UE may perform GNSS measurements. Overview of E-UTRAN and eMTC connected mode mobility 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. A typical procedure is described below and illustrated in Figure 4. 1. UE performs neighbour cell measurements, which are configured by the network. 2. A measurement report (of a neighbour cell) is triggered and sent by UE to source eNB. 3. Source eNB decides, based on measurement report or any other information, whether to initiate a handover. 4. When source eNB decides to initiate a handover, source eNB sends a Handover Request to target eNB. 5. Following admission control at target eNB, source eNB receives a Handover Request Acknowledge from target eNB. 6. The source eNB triggers a handover command which is sent to UE. This handover command comprises the RRC message RRCConnectionReconfiguration, containing the mobilitycontrol Info field. 7. UE prepares for handover and performs a handover via the random access procedure. If a neighbour cell measurement is configured to be performed in an NTN cell, then as currently being discussed in Release 18 loT 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. Overview of Inter-RAT mobility 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. In idle mode for inter-RAT mobility the following system information is broadcast: 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. SIB5 is broadcast in an NR cell to perform inter-RAT measurements of an E-UTRAN cell. 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). The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present invention. SUMMARY It is an aim of certain examples of the present 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 certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein. The present invention 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 present invention. Other aspects, advantages and salient features of the invention will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates an exemplary NTN Release 17 architecture and scenario; Figure 2 illustrates an exemplary ephemeris synchronization operation; in Figure 2(a) SIB31 functions as normal, and in Figure 2(b) UE fails to read SIB31 during T318 which then expires and triggers RLF; Figure 3 illustrates an exemplary loT NTN GNSS validity operation; Figure 3(a) 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 3(b) the UE releases itself autonomously according to the specification; Figure 4 illustrates an exemplary handover procedure; Figure 5a illustrates an exemplary procedure for mobility from NR to E-UTRAN; Figure 5b illustrates an example of mobility triggered via RRCConnectionReconfiguratiorr, Figure 6 illustrates an exemplary procedure for sending gnss-ValidityDuration during loT NTN handover according to 3GPP TS 36.331 V17.5.0; Figure 7 illustrates examples of configuring the reporting of loT NTN information during TN -NTN mobility; in Figure 7(a) information is reported to NTN cell, and in Figure 7(b) information is not reported to TN cell; Figure 8 illustrates an example of providing GNSS information (e.g. GNSS validity duration) to a target eNB during TN-NTN mobility; Figure 9a illustrates an example of whether NTN information is included when performing a handover / mobility from a certain type of network to another; Figure 9b illustrates examples of mobility between E-UTRAN NTN / TN EPC, E-UTRAN NTN / TN 5GC, and / or NR NTN / TN 5GC; 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; Figure 10b illustrates an example of including needed information in an RRCConnectionReconfigurationComplete message when the UE performs certain mobility; 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; Figure 12 illustrates an exemplary method, for a UE, for mobility to an NTN; Figure 13 illustrates an exemplary method, for a UE, for inter- RAT mobility; and Figure 14 is a block diagram of an exemplary network entity that may be used in certain examples of the present disclosure. DETAILED DESCRIPTION The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of the present invention, 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 invention. The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings. 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 present invention. 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 invention. 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. 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. 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. 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. The skilled person will appreciate that the techniques described herein may be used in any suitable combination. Certain examples of the present disclosure provide one or more techniques for mobility between a TN and an NTN. For example, certain examples of the present 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 present invention 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. 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. 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. The skilled person will appreciate that the present invention is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 5G. • 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. • 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. • One or more further elements or entities may be added to the examples disclosed herein. • One or more non-essential elements or entities may be omitted in certain examples. • 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. • 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. • Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example. • Information carried by two or more separate messages in one example may be carried by a single message in an alternative example. • The order in which operations are performed and / or the order in which messages are transmitted may be modified, if possible, in alternative examples. Certain examples of the present 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. Certain examples of the present 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. 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. 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. 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): => P4: The new parameter for remaining GNSS validity duration is introduced in RRCConnectionReconfigurationComplete forMTC Handover. => This mechanism is not configurable, and the UE always reports. The current procedure (3GPP TS 36.331 V17.5.0) is illustrated in Figure 6. 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. 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. Certain examples of the present disclosure provide one or more techniques for performing mobility between a terrestrial network and a non-terrestrial network. In certain examples, both the terrestrial network and the non-terrestrial network may be NR or E-UTRAN (LTE). In the present 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 “loT NTN base station”. In 3GPP so far, only loT is supported for LTE NTN and not “ordinary” non-loT LTE NTN. The skilled person will appreciate that the techniques described herein are not limited to loT NTN E-UTRAN, as “ordinary” non-loT 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. 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. Certain examples of the present 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. In certain examples, the second message may include the information relating to the GNSS measurement only if the second base station is associated with the NTN cell. In certain examples, the first message may comprise an RRCConnectionReconfiguration message. In certain examples, the RRCConnectionReconfiguration message may comprise mobilityControlInfo. In certain examples, the second message may comprise an RRCConnectionReconfigurationComplete message. In certain examples, the information relating to a GNSS measurement may comprise gnss-validityDuration (e.g. in accordance with a remaining time of a GNSS validity duration). In certain examples, 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). In certain examples, the information relating to a GNSS measurement may comprise gnss-PositionFixDuration (e.g. indicating a time duration required to acquire a GNSS position). In certain examples, the first base station may be associated with a Terrestrial Network (TN) cell. In certain examples, the information relating to a GNSS measurement may comprise Internet of Things (loT) NTN information. Certain examples of the present 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. In certain examples, the first base station may be associated with an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) TN cell. In certain examples, the second base station may be associated with a New Radio (NR) NTN cell. In certain examples, the satellite information may comprise ephemeris. In certain examples, the satellite information may comprise a satellite ID. In certain examples, the satellite ID may be associated with frequency information for cell reselection. In certain examples, the one or more SIBs may comprise one or more NTN-specific SIBs. In certain examples, 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). In certain examples, the UE may be in an idle mode (e.g. RRC idle mode). In certain examples, 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. Certain examples of the present 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. In certain examples (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. In certain examples (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. systemlnformationBlockType31dedicated). In certain examples (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. In certain examples (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 In certain examples (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). 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. In certain examples (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. In certain examples (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. In certain examples (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. In certain examples (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). In certain examples (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. In certain examples (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. In certain examples (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. In certain examples (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. In certain examples (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. MobilityFromNRCommandy, and if the received message includes certain information (e.g. system! nformationBlockType31 dedicated), applying, by the UE, a configuration based on the information. In certain examples (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). Certain examples (e.g. an eighteenth example) of the present 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. In certain examples (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. In certain examples (e.g. a twentieth example according to the eighteenth or nineteenth examples), translating the configuration information may comprise one or more of: taking ntn-UISyncValidityDuration (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-lnfo fields; and translating cell SpecificKoffset to k-Offset. In certain examples (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-UISyncValidityDuratiorr, using signalled absolute values instead of signalled values for nta-CommonParameters fields; and translating k-offset to cellSpecificKOffset. In certain examples (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.). In certain examples (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). In certain examples (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. satellitelD) relating to NTN information (e.g. ephemeris) from broadcast information (e.g. SIB24 for E-UTRAN, or SIB5 for NR). Certain examples of the present disclosure provide a User Equipment (UE) ora Base Stations (BS) configured to perform a method according to any example, aspect, embodiment and / or claim disclosed herein. Certain examples of the present 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. Certain examples of the present disclosure provide a computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any example, aspect, embodiment and / or claim disclosed herein. Certain examples of the present 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. Sending needed information during TN NTN mobility To address the problem of ambiguity of when to report certain needed information for operating in an loT NTN cell, one or more of the following techniques may be applied. In certain examples, the loT NTN information may be provided when connecting to a target NTN cell, whereas the loT 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 loT NTN information during the handover may comprise one or more of the following options: 1. The UE reports the loT NTN information when the target cell is an NTN cell. An example is given in specification example 1 further below. 2. The UE reports the loT NTN information when the RRCReconfiguration message (containing the mobilityControlInfo), i.e. the handover command sent by source cell, contains the dedicated SIB31, i.e. systemlnfoBlockType31dedicated. 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. In certain examples, 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): • When performing mobility from TN to NTN, the UE will send the needed information in the RRCConnectionReconfigurationComplete message to the NTN cell. • When performing mobility from NTN to TN, the UE will not send the information needed for NTN operation. In certain examples, as the problem described above suggests, the needed information reported loT NTN may comprise one or more of the following non-limiting examples: 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. 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 certain examples, the U E 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. Capability of performing GNSS measurement simultaneously during downlink and / or uplink transmissions. Last time a GNSS measurement was performed. - GNSS measurement failure. This may comprise information on of GNSS measurement failure during a GNSS measurement. In certain examples, 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 loT 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. TN-NTN inter-RAT mobility In certain examples, 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 loT NTN) cell and an NR NTN cell. Certain examples may relate to one or more of the following possibilities (as illustrated in Figure 9): - E-UTRAN NTN to NR NTN cell o In this case, the loT NTN information may not be needed and the NR NTN cell is unlikely to be able to read the information. So, the loT NTN information does not need to be sent by the UE. - NR NTN cell to E-UTRAN NTN cell o In this case the E-UTRAN NTN cell may need to have the loT NTN information for normal operation. o In certain examples, it may not be necessary to provide the loT 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 loT NTN information such as gnss-ValidityDuration may not be relevant. In certain examples, the UE capability with respect to NR NTN of the UE performing the handover may be known from the signalled capabilities. In certain examples the UE capability may be signalled between source and target cells. o In certain examples, this may be specified by requiring that the NR NTN-capable UE signal infinity value or any other suitable value. - NR TN to E-UTRAN NTN cell o In this case the UE may send the loT NTN information. In the following cases the UE may not send the loT NTN information to the target cell o E-UTRAN TN to NR NTN cell o E-UTRAN NTN to NR TN cell o NR NTN to E-UTRAN TN cell In certain examples, the UE may be specially configured to provide the loT 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 loT NTN, such as gnss-ValidityDuration. This may be useful as there may be quick handovers back to the NTN from the TN network. In certain examples, when a UE performs mobility from NR (TN or NTN) to E-UTRAN NTN, the systemlnformationBlockType31dedicated(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. 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: - E-UTRAN EPC to E-UTRAN 5GC or E-UTRAN 5GC to E-UTRAN EPC - EN-DC EPC to E-UTRAN 5GC or E-UTRAN 5GC to EN-DC EPC - E-UTRAN EPC to NR 5GC or NR 5GC to E-UTRAN EPC 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. In one embodiment, when the UE performs mobility: • from E-UTRAN NTN / TN EPC to E-UTRAN NTN 5GC, • from E-UTRAN NTN / TN 5GC to E-UTRAN NTN EPC, • from EN-DC NTN / TN to E-UTRAN NTN 5GC • from E-UTRAN NTN / TN 5GC to EN-DC NTN • from NR NTN / TN 5GC to E-UTRAN NTN EPC, 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. 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 systemlnformationBlockType31 in the RRCConnectionReconfiguration or MobilityFromNRCommand when performing inter-CN mobility. 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 systemlnformationBlockType31 in the newly defined RRC message (or signalling or procedure) when performing inter-CN mobility. A specification example of this can be seen in specification example 5 further below. Connected mode measurements for mobility purposes 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. In certain examples, 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 loT NTN cell / frequency. Examples of the translation or omission may include one or more of the following: ntn-UISyncValidityDuration (T430 in NR NTN) may be taken as the value for ul-SyncValidityDuration (T317 in E-UTRAN NTN). - ta-lnfo 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). cell Sped ficKoffset may be translated in to k-Offset - certain fields, such as ta-Report, polarization etc., may be either not signalled by the network or ignored by the UE if signalled. In certain examples, 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. Examples of the translation or omission may include one or more of the following: ul-SyncValidityDuration may be taken as the value for ntn-UISyncValidityDuration. 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). k-offset may be translated in to cellSpecificKOffset 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. In certain examples, 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. 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. Idle mode measurements for mobility purposes When measuring a cell in idle mode, the UE may need to rely on broadcast information in various SIBs. In order to “tie” an inter-RAT ephemeris element to an inter-RAT frequency, an Identity (ID) relating to the ephemeris, such as an satellitelD (as already introduced in loT NTN) may be used. Thus, in certain examples, a satellitelD 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. Figure 12 illustrates an exemplary method, for a UE, for mobility to an Non Terrestrial Network (NTN). 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). 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). 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'). Figure 13 illustrates an exemplary method, for a UE, for inter-RAT mobility. 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). 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). 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. 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. 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). Figure 14 is a block diagram of an exemplary network entity that may be used in examples of the present 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. 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. Specification Examples The following illustrate examples in which the specification may be modified to incorporate one or more of the techniques described herein. Example 1 3GPPTS 36.331 V17.5.0 5.3.5.4 Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE (handover) If the RRCConnectionReconfiguration message includes the mobilityControlInfo and the UE is able to comply with the configuration included in this message, the UE shall: ... OMITTED ... 1> start synchronising to the DL of the target PCell; 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. ... OMITTED ... 1> else (if daps-HO is not configured): 2> reset MCG MAC and SCG MAC, if configured; 2> release uplinkDataCompression, if configured; 2> re-establish PDCP for all RBs configured with pdcp-config that are established; NOTE 2: The handling of the radio bearers after the successful completion of the PDCP reestablishment, 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], NOTE 2a: At handover the reestablishPDCP flag will be set for all RBs configured with NR PDCP in nr-RadioBearerConfigl or nr-RadioBearerConfig2 TS 38.331

[82] which will cause the PDCP entity to be re-established also for these RBs. 2> re-establish MCG RLC and SCG RLC, if configured, for all RBs that are established; ... OMITTED ... 1> apply the value of the newUE-Identity as the C-RNTI in the target MCG; 1 >if the RRCConnectionReconfiguration message includes the fullConfig: 2> perform the radio configuration procedure as specified in 5.3.5.8; 1> configure lower layers in accordance with the received radioResourceConfigCommon-. 1> if the received RRCConnectionReconfiguration message includes the rach-Skip'. 2> configure lower layers to apply the rach-Skip for the target MCG, as specified in TS 36.213

[23] and 36.321 [6]; 1> if UE supports timing advance reporting and the received radioResourceConfigCommon includes the ta-Report'. 2> instruct the associated MAC entity to trigger Timing Advance reporting; I >configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received mobility Controlinfo; ... OMITTED ... 1 >if the received RRCConnectionReconfiguration includes the systemlnformationBlockType 1 Dedicated. 2> perfom the actions upon reception of the Systemlnformat^ message as specified in 5.2.2.7; 1> if the received RRCConnectionReconfiguration includes the systemlnformationBlockType 31 Dedicated'. 2> perform the actions upon reception of the SystemlnformationBlockType 31 message as specified in 5.2.2.39; 1> perform the measurement related actions as specified in 5.5.6.1; 1> if the RRCConnectionReconfiguration message includes the measConfig'. 2> perform the measurement configuration procedure as specified in 5.5.2; 1> perform the measurement identity autonomous removal as specified in 5.5.2.2a; ... OMITTED... 1> if the RRCConnectionReconfiguration message includes the sl-V2X-ConfigDedicated or mob ilityControllnfo V2X: 2> perform the V2X sidelink communication dedicated configuration procedure as specified in 5.3.10.15a; 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). 1> if the UE is configured to operate in EN-DC as result of this procedure, forward upperLayerlndication, as if the UE receives this field from SIB2, to upper layers, otherwise indicate upper layers absence of this field; 1> set the content of RRCConnectionReconfigurationComplete message as follows: OMITTED 2> if the target cell is an GE-rs-eeaasae-tad-t® NTN cell: 3> include gnss-validityDuration in accordance with the remaining time of the GNSS validity duration; 1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission; 1> if MAC successfully completes the random access procedure; or 1 >if MAC indicates the successful reception of a PDCCH transmission addressed to C-RNTI and if rach-Skip is configured: 2> stop timer T304; 2> if daps-HO is configured for any DRB: 3> stop timer T310 for the source PCell, if running; 3> for each DAPS bearer trigger UL data switching, as specified in TS 36.323 [8]; 2> release rach-Skip-, 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; 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; 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. ... OMITTED ... 2> the procedure ends; 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 mohilityControlInfo. ........................3GPPTS 36.331 V17.5.0------------------------ ------------------------3GPPTS 36.331 V17.5.0------------------------ 5.3.5.4 Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE (handover) If the RRCConnectionReconfiguration message includes the mobilityControlInfo and the UE is able to comply with the configuration included in this message, the UE shall: ... OMITTED ... 1> start synchronising to the DL of tire target PCell; 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. ... OMITTED ... 1> else (if daps-HO is not configured): 2> reset MCG MAC and SCG MAC, if configured; 2> release uplinkDataCompression, if configured; 2> re-establish PDCP for all RBs configured withpdcp-config that are established; NOTE 2: The handling of the radio bearers after the successful completion of the PDCP reestablishment, 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], NOTE 2a: At handover the reestablishPDCP flag will be set for all RBs configured with NR PDCP in nr-RadioBearerConfigl or nr-RadioBearerConfig2 TS 38.331

[82] which will cause the PDCP entity to be re-established also for these RBs. 2> re-establish MCG RLC and SCG RLC, if configured, for all RBs that are established; ... OMITTED ... 1> apply the value of the newUE-Identity as the C-RNTI in the target MCG; 1 >if the RRCConnectionReconfiguration message includes the fullConfig'. 2> perform the radio configuration procedure as specified in 5.3.5.8; 1> configure lower layers in accordance with the received radioResourceConfigCommon\ 1 >if the received RRCConnectionReconfiguration message includes the rach-Skip'. 2> configure lower layers to apply the rach-Skip for the target MCG, as specified in TS 36.213

[23] and 36.321 [6]; 1> if UE supports timing advance reporting and the received radioResourceConfigCommon includes the ta-Report: 2> instruct the associated MAC entity to trigger Timing Advance reporting; 1> configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received mobilityControlInfo; ... OMITTED ... 1> if the received RRCConnectionReconfiguration includes the systemlnformationBlockTypel Dedicated: 2> perfom the actions upon reception of the SystemlnformationBlockTypel message as specified in 5.2.2.7: 1 >if the received RRCConnectionReconfiguration includes the systemlnformationBlockType 31 Dedicated: 2> perform the actions upon reception of the SystemlnformationBlockType 31 message as specified in 5.2.2.39; 1> perform the measurement related actions as specified in 5.5.6.1; 1 >if the RRCConnectionReconfiguration message includes the measConfig: 2> perform the measurement configuration procedure as specified in 5.5.2; 1> perform the measurement identity autonomous removal as specified in 5.5.2.2a; ... OMITTED... 1> if the RRCConnectionReconfiguration message includes the sl-V2X-ConfigDedicated or mobilityControlInfo V2X: 2> perform the V2X sidelink communication dedicated configuration procedure as specified in 5.3.10.15a; 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). I >if the UE is configured to operate in EN-DC as result of this procedure, forward upperLuyerlndication. as if the UE receives this field from SIB2, to upper layers, otherwise indicate upper layers absence of this field; 1> set the content of RRCConnectionReconfigurationComplete message as follows: ... OMITTED ... 2> if the received included 3> include gnss-validityDuration in accordance with the remaining time of the GNSS validity duration; 1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission; 1> if MAC successfully completes the random access procedure; or 1 >if MAC indicates the successful reception of a PDCCH transmission addressed to C-RNTI and if rach-Skip is configured: 2> stop timer T304; 2> it daps-HO is configured for any DRB: 3> stop timer T310 for the source PCell, if running; 3> for each DAPS bearer trigger UL data switching, as specified in TS 36.323 [8]; 2> release rach-Skip-, 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; 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; 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. ... OMITTED ... 2> the procedure ends; 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. ------------------------3GPPTS 36.331 V17.5.0------------------------ Example 3 8.2 Basic mobility procedures 8.2.1 Handover Preparation 8.2.1.1 General [text omitted] if the 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. 9.1.1 Messages for Basic Mobility Procedures 9.1.1.1 HANDOVER REQUEST This message is sent by the source eNB to the target eNB to request the preparation of resources for a handover. Direction: source eNB target eNB. lE / Group Name Presence Range IE type and reference Semantics description Criticality Assigned Criticality Message Type M 9.2.13 YES reject IAB Node Indication O ENUMERATED (true, ...) YES reject gnss-ValidityDuration O aaX YES ------------------------3GPPTS 36.423 V17.5.0------------------------ ------------------------3GPPTS 38.423 V17.5.0------------------------ 8.2 Basic mobility procedures 8.2.1 Handover Preparation 8.2.1.1 General [text omitted] If the IE is contained in the HANDOVER REQUEST message, the target NG- RAN shall, if supported, store the received infonnatioii in the UE context, and use this information, as needed, during the handover from IN to NTN. 9.1.1 Messages for Basic Mobility Procedures 9.1.1.1 HANDOVER REQUEST 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. Direction: source NG-RAN node -o target NG-RAN node. lE / Group Name Presence Range IE type and reference Semantics description Criticality Assigned Criticality Message Type M 9.2.13 YES reject gnss-ValidityDuration O XXX Y •" b reject ........................3GPPTS 38.423 V17.5.0------------------------ Changes are indicated in bold 3GPPTS 38.331 V17.5.0------------------------ SIB19 S1B19 contains satellite assistance information for NTN access. SIB19 information element ■ ' :: lit U-1 t Ri- L I - / n-i • j ij,. _ । -| ra R rair."'- k".' L ntri-lRighkal latRRnC-riti [ [ ] J , t[ ntn-NeighCellConflgListEutran-rl8 NTN-NeighCellConfigListEutran-rlS OFTIONKL K4BN:::::::::::::::::::::::::::::::::::::::::::::N:N:N:Ni:hhhhibbbbbbbl::::::::::::::::::::::00^^H^ NTN-NeighCellConfigListEutran-rl8 ::= (SX2E(1..maxCeIlNTN-rl7)) OF NTN- NeighCellConfigEutra-rl8 OMOtOO'O::.: 1:11:-I'l'Iit! ]- I ■ 11 : i' i 1 i' 11~: . '<11 M-r; NTN-NeighCellConfigEutran-rl8 ntn-Config-rlS carrierFreq-rl8 physCel11 d- rl 8 } ARFCN-ValueNR PhysCellld SIB19 field descriptions n tn-Neigh Cell ConfigListEutran Provides a list of NTN E-UTRAN neighbour cells. The field ntn-Conflg contains the field ServingSatellitelnfo (or NeighSatellitelnfo) as In 36.331 including their ntn-Conflg, carrier frequency and PhysCellld. ------------------------3GPPTS 38.331 V17.5.0------------------------ ------------------------3GPPTS 36.331 V17.5.0------------------------ 5.4.2.3 Reception of the RRCConnectionReconfiguration by the UE If the UE is able to comply with the configuration included in the RRCConnectionReconfiguration message, the UE shall: 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): 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); 1 >if the RRCConnectionReconfiguration message includes thetuUConfig and the source RAT was E-UTRA (i.e., intra-RAT inter-system handover): 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); 2> release / clear all current common radio configurations; 2> for each srb-Identity value included m the srb-ToAMModhst (SRB reconfiguration): 3> apply the specified configuration defined in 9.1.2 for the corresponding SRB; 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; 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; 3> if the handoverType in securityConfigHO is set to fivegc-ToEPC (i.e, the UE is connecting to EPC): 4> release the PDCP entity and establish it with an E-UTRA PDCP entity; 3> else if the handoverType in securityConfigHO is set to epc-To5GC (i.e., the UE is connecting to 5GC): 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

[82] , clause 9.2.1; 3> associate the RLC bearer of this SRB with the established PDCP entity; 1> apply the default physical channel configuration as specified in 9.2.4; 1 >apply the default semi-persistent scheduling configuration as specified in 9.2.3; 1> apply the default MAC main configuration as specified in 9.2.2; 1> start timer T304 with the timer value set to t304, as included in the mobilityControlInfo', 1> consider the target PCell to be one on the frequency indicated by the carrierFreq with a physical cell identity indicated by the targetPhysCellld', 1> start synchronising to the DL of the target PCell; 1 >set the C-RNTI to the value of the newUE-Identity, 1> for the target PCell, apply the downlink bandwidth indicated by the dl-Bandwidth; 1> for the target PCell, apply the uplink bandwidth indicated by (the absence or presence of) the ul-Bandwidth; 1> configure lower layers in accordance with the received radioResourceConfigCommon', 1> configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received mobilityControlInfo-, 1> perform the radio resource configuration procedure as specified in 5.3.10.0; 1> if the handoverType in securityConfigHO is set to fivegc-ToEPC'. 2> indicate to higher layer that the CN has changed from 5GC to EPC; 2> derive the key K6nb based on the mapped Kasme key as specified for interworking between EPS and 5GS in TS 33.501

[86] ; 2> store the nextHopChainingCount-rl 5 value; 1> else if the handoverType in securityConfigHO is set to intra5GC~. 2> if the keyChangelndicator-rl 5 received in the securityConfigHO is set to TRUE'. 3> forward nasContainer to the upper layers, if included; 3> update the Ka.a key based on the Kamf key, as specified m TS 33.501

[86] ; 2> else: 3> update the K6nb key based on the current KgNB or the NH, using the nextHopChainingCount-rl 5 value indicated in the SecurityConfigHO, as specified in TS 33.501

[86] ; 2> store the nextHopChainingCount-rl5 value; 1> else if the handoverType in securityConfigHO is set to epc-To5GC'. 2> forward the nas-Container to the upper layers; 2> derive the K«nb key, as specified in TS 33.501

[86] ; 1> else: 2> forward the nas-SecurityParamToElJTRA to the upper layers; 2> derive the K6nb key, as specified in TS 33.401

[32] ; 1> derive the KRRdnt key associated with the integrityProtAlgorithm, as specified in TS 33.401

[32] ; 1> derive the KRRCenc key and the Kupenc key associated with the cmheringA Igor Uhm. as specified in TS 33.401

[32] ; 1 >if capable of user plane integrity protection: 2> derive the Kupmt key associated with the integrityProtAlgorithm, as specified in TS 33.401

[32] ; 1> if the received includes the 2> perform (he actios* upon reception of the message as specified 1> if the received RRCConnectionReconfiguration includes the sk-Counter. 2> perform key update procedure as specified in in TS 38.331

[82] , clause 5.3.5.7; 1> if the received RRCConnectionReconfiguration includes the nr-SecondaryCellGroupConfig'. 2> perform NR RRC Reconfiguration as specified in TS 38.331

[82] , clause 5.3.5.3; 1> if the received RRCConnectionReconfiguration includes the nr-RadioBearerConfigP. 2> perfonn radio bearer configuration as specified in TS 38.331

[82] , clause 5.3.5.6; 1> if the received RRCConnectionReconfiguration includes the nr-RadioBearerConfig2\ 2> perform radio bearer configuration as specified in TS 38.331

[82] , clause 5.3.5.6; 1 >if the handoverType in securityConfigHO is set to fivegc-ToEPC or if the handove rType-vl 5 30 is not present: 2> configure lower layers to apply the indicated integrity protection algorithm and the KRRCmt key 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; 2> configure lower layers to apply the indicated ciphering algorithm, the KRRCenc key and the Kupenc key 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 successfill completion of the procedure; 1> if the received RRCConnectionReconfiguration includes the sCellToAddModList. 2> perform SCell addition as specified in 5.3.10.3b; 1 >if the RRCConnectionReconfiguration message includes the measConfig'. 2> perform the measurement configuration procedure as specified in 5.5.2; I >perform the measurement identity autonomous removal as specified in 5.5.2.2a; 1 >if the RRCConnectionReconfiguration message includes the otherConfig'. 2> perform the other configuration procedure as specified in 5.3.10.9; 1> if the RRCConnectionReconfiguration message includes wlan-Offloadlnfo'. 2> perform the dedicated WLAN offload configuration procedure as specified in 5.6.12.2; 1> if the RRCConnectionReconfiguration message includes rclwi-Configuration'. 2> perform the WLAN traffic steering command procedure as specified in 5.6.16.2; 1> if the RRCConnectionReconfiguration message includes Iwa-Configuration'. 2> perform the LWA configuration procedure as specified in 5.6.14.2; 1> if the RRCConnectionReconfiguration message includes Iw ip-Configuration'. 2> perform the LWIP reconfiguration procedure as specified in 5.6.17.2; 1> set the content of RRCConnectionReconfigurationComplete message as follows: 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'. 3> include rlf-InfoAvailable', 2> if the UE has MBSFN logged measurements available for E-UTRA and if the RPLMN is included inplmn-IdentityList stored in VarLogMeasReport and if T330 is not running: 3> include logMeasAvailableMBSFN', 2> else if the UE has logged measurements available for E-UTRA and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport'. 3> include the logMe as Available, 3> if Bluetooth measurement results are included in the logged measurements the UE has available: 4> include the logMeasAvailableBT', 3> if WLAN measurement results are included in the logged measurements the UE has available: 4> include the logMeasAvailable WLAN', 2> if the UE has connection establishment failure information available in VarConnEstFailReport and if the RPLMN is equal to plmn-Identity stored in VarConnEstFailReport. 3> include connEstFaillnfoAvailable', 2> if the received RRCConnectionReconfiguration message included nr-SecondaryCellGroupConfig'. 3> include seg-ConfigResponseNR m accordance with TS 38.331

[82] , clause 5.3.5.3; 2> if the target cell is an NTN ceH: 3> include in accordance with the remaining time of the GNSS validity duration; 1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new configuration; 1 >if the RRCConnectionReconflguration message does not include rlf-TimersAndConstants set to setup-. 2> use the default values specified in 9.2.5 for timer T310, T311 and constant N310, N311; 1> if MAC successfully completes the random access procedure: 2> stop timer T304; 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; 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; 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. 2> enter E-UTRA RRC CONNECTED, upon which the procedure ends; NOTE 2: The UE is not required to determine the SFN of the target PCell by acquiring system information from that cell before performing RA CH access in the target PCell. 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. ------------------------36.331 V17.5.0 example------------------------ 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. It will be appreciated that examples of the present 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. 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 certain examples of the present disclosure. Accordingly, certain examples 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. While the invention has been shown and described with reference to certain examples, 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 invention, as defined by the appended claims. Abbreviations / Definitions In the present disclosure, the following acronyms / definitions are used. 3GPP 3rd Generation Partnership Project 5 4G 4th Generation 5G 5th Generation rr'r- ObU 5G Core CN Core Network eMTC enhanced Machine Type Communications 10 eNB Base Station EN-DC E-UTRAN-NR Dual Connectivity en-gNB gNB that can connect with EPC and eNB EPC Evolved Packet Core E-UTRAN Evolved Universal Terrestrial Radio Access Network 15 GNSS Global Navigation Satellite System GEO Geosynchronous Equatorial Orbit gNB 5G Base Station HAPS High Altitude Platform Station ID Identity / ldentifi cation 20 IE Information Element loT Internet of Things LEO Lower Earth Orbit LTE Long Term Evolution LTE-M Long Term Evolution Machine Type Communication 25 MTC Machine-Type Communications NB Narrowband NG Next Generation NG-RAN Next Generation Radio Access Network NR New Radio 30 NTN Non-Terrestrial Network PDCP Packet Data Convergence Protocol PVT Position, Velocity, Time RAN Radio Access Network RAT Radio Access Technology 35 RLF Radio Link Failure RRC Radio Resource Control SDAP Service Data Adaption Protocol SIB System Information Block TA Timing Advance 40 TLE Two-Line Element TN Terrestrial Network TS Technical Specification Txxx Timer xxx UE User Equipment 45 X2 / Xn Interface between RAN nodes

Claims

1. 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; andin 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.

2. A method according to claim 1, wherein the second message includes the information relating to the GNSS measurement only if the second base station is associated with the NTN cell.

3. A method according to claim 1 or 2, wherein the first message comprises an RRCConnectionReconfiguration message.

4. A method according to claim 3, wherein the RRCConnectionReconfiguration message comprises mobilityControlInfo.

5. A method according to any preceding claim, wherein the second message comprises an RRCConnectionReconfigurationComplete message.

6. A method according to any preceding claim, wherein the information relating to a GNSS measurement comprises gnss-validityDuration (e.g. in accordance with a remaining time of a GNSS validity duration).

7. A method according to any preceding claim, wherein the information relating to a GNSS measurement comprises a GNSS measurement duration (e.g. for enabling configuration of a duration of a measurement gap when the UE performs a GNSS measurement).

8. A method according to any preceding claim, wherein the information relating to a GNSS measurement comprises gnss-PositionFixDuration (e.g. indicating a time duration required to acquire a GNSS position).

9. A method according to any preceding claim, wherein the first base station is associated with a Terrestrial Network (TN) cell.

10. A method according to any preceding claim, wherein the information relating to a GNSS measurement comprises Internet of Things (loT) NTN information.

11. 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; andreceiving, from the first base station in one or more certain System Information Blocks (SIBs), satellite information for NTN access.

12. A method according to claim 11, wherein the first base station is associated with an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) TN cell.

13. A method according to claim 11 or 12, wherein the second base station is associated with a New Radio (NR) NTN cell.

14. A method according to claim 11, 12 or 13, wherein the satellite information comprises ephemeris.

15. A method according to any of claims 11 to 14, wherein the satellite information comprises a satellite ID.

16. A method according to claim 15, wherein the satellite ID is associated with frequency information for cell reselection.

17. A method according to any of claims 11 to 16, wherein the one or more SIBs comprise one or more NTN-specific SIBs.

18. A method according to any of claims 11 to 17, wherein a first part of the satellite information (e.g. ephemeris) is 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) is provided in a second SIB (e.g. SIB24).

19. A method according to any of claims 11 to 18, wherein the UE is in an idle mode (e.g. RRC idle mode).

20. A method according to any of claims 11 to 19, wherein the UE does not send certain 5 NTN information (e.g. a GNSS validity duration and / or a GNSS measurement duration) to the second base station.

21. A UE configured to perform a method according to any preceding claim.10 22. A network (or wireless communication system) comprising a UE according to claim 21,and first and second base stations.

23. 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 15 to any of claims 1 to 20.

24. A computer or processor-readable data carrier having stored thereon a computer program according to claim 23.

Images