Method and apparatus for mobility in non-terrestrial networks

Abstract

A base station (BS) receives a first message from a user equipment (UE) comprising a capability of the UE to be redirected from an E-UTRAN terrestrial network (TN) to a New Radio (NR) non-terrestrial

Description

Technical Field The technical field relates generally to implementing techniques to support mobility in nonterrestrial networks (NTNs) and in some implementations to a non-terrestrial network (NTN) from a terrestrial network. Background In recent years, there has been a rapid development in communications technologies that are compliant with third generation partnership project (3GPP™) standards. A 4th generation (4G) wireless communication standard (sometimes referred to as long term evolution (LTE™) was designed to support mobile internet and higher speeds for activities, such as video streaming and gaming. The 3GPP™ standards then developed a fifth generation (5G) of mobile wireless communications, which provides a step change in the delivery of better and faster communications, for example powering businesses, improving communications within homes and spearheading advances such as driverless cars. A sixth generation (6G) wireless communication standard is currently under development, as the planned successor to 5G, and will likely be significantly faster. Like its predecessors, 6G networks will likely be broadband cellular networks, in which the service area is divided into small geographical areas called cells. 6G networks are expected to be even more diverse than their predecessors and are likely to support applications beyond current mobile use scenarios, such as virtual and augmented reality (VR / AR), ubiquitous instant communications, pervasive intelligence and the Internet of Things (loT). It is expected that mobile network operators will adopt flexible decentralized business models for 6G, with local spectrum licensing, spectrum sharing, infrastructure sharing, and intelligent automated management underpinned by mobile edge computing, artificial intelligence (AI), short-packet communication and blockchain technologies. Non-Terrestrial Networks (NTNs) is an emerging area in 3GPP™ discussions for 5Gthat aim to provide 5G cellular coverage using space borne and / or air borne platforms, where traditional ground-based networks have difficulty in providing coverage and / or capacity. loT NTN was a 3GPP study and work item in 3GPP release 17 to provide Non-Terrestrial Network access for E-UTRAN loT devices (NB-IoT and LTE-M / eMTC) [RP-202689], And NR NTN was a work item in Rei-17 to specify adaptation to allow NR to function over NTN [RP-211557], Non-Terrestrial Network access may be through Lower Earth Orbit (LEO), Medium Earth Orbit (MEO) and Geostationary Orbit (GEO), as well as through High-Altitude Platform Systems (HAPS). Referring to FIG. 1, a known simplified cellular architecture diagram 100 illustrates a first nonterrestrial base station / satellite 102 supporting communications within a coverage area 104, including communication support for a wireless communication unit, sometimes referred to as a terminal device, such as a user equipment UE 106. In 4G as well as 5G, the UE 106 is able to support traditional Human Type Communications (HTC) or the new emerging Machine Type Communications (MTC). The UE 106 is considered to be active when communicating and in the operational state technically known as radio resource control (RRC) connected. 4G or LTE™, which Internet of Things (loT) (NB-IoT and LTE-M) is based on, has two RRC states; RRC connected mode and RRC idle mode. 5G / 5G new radio (NR) has three RRC states; RRC connected mode, RRC inactive mode and RRC idle mode, where RRC inactive is a newly introduced mode. RRC idle and RRC inactive operation are to a large part similar and a differentiation to large part in the procedures used to go to RRC connected mode. The known simplified cellular architecture diagram 100 comprises a connection 120 connects the first non-terrestrial base station / satellite 102 and a second terrestrial base station 108 via a gateway 114. For RRC- idle state UEs 106, a cell re-selection process may be warranted, if the signal strength from the current serving cell (i.e., non-terrestrial base station 102) deteriorates as the UE transitions from base station 102 to 108. Similarly, a cell re-selection process is performed for ‘RRC idle state UEs when the UE nears the cell edge of the current cell 104 that it is camped on, and is able to receive a signal from the neighbour base station 108. For loT, this is a known 4G or E-UTRAN cell reselection process, which is also driven by signal strength measurements of the base stations carried out by the UE. Again, a A dB threshold is enacted to avoid repeated cell re-selections in a ‘ping-pong’ effect. Thus, the 3 GPP™ LTE™ (and NR) cell reselection, i.e., the act of camping on another cell, is an autonomous decision based on radio signal measurements performed by UEs 106 based on signals received from serving base station 102 and one or more neighbour base station(s) 112, sometimes referred to as fifth generation Node Bs (gNB) or eNBs and configured thresholds related to such radio signal measurements. In RRC connected mode, the threshold A dB is set to avoid ping-pong type handover and cell re-selection exchanges near the cell border, as the instantaneous signal strengths can vary dynamically. The serving gNB 102 can instruct each individual UE 106 to provide these measurement reports and the measurement frequency can be adapted depending on whether a particular UE is nearing a cell edge, for example. Also, cell reselection processes happen on an individual UE basis, based on the measurements of the current camped-on and neighbour base stations (gNBs). In RRC idle mode / state, thresholds are also used to govern the cell reselections, but they are not used by comparing one cell with the serving cell as is done in RRC connected mode. In cell reselection in idle mode, the cells will, for instance, compute a ranking based on parameters such as thresholds and the measured signal strength. In the ‘RRC- idle’ state, the current camped-on base station (gNB) 102 is able to instruct the UEs 106 on an individual basis in order to carry out these measurements and the UE 106 themselves will initiate and carry out the cell re-selection process. Narrowband Internet of Things (NB-IoT) is a 3GPP™-defined network based on 4G Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) that supports ultra-low complexity devices with very narrow bandwidth that was introduced in 3GPP Release 13. The use case of NB-IoT is to serve massive 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; and power efficient operation by allowing the UE to sleep for very long times, relaxed requirements and more efficient signalling to establish with a cell. LTE-M (LTE-Machine) or eMTC (enhanced Machine Type Communication) 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. Similarly to NB-IoT, 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-IoT, the LTE-M inherits most feature of a regular LTE device, but with some adaptations for low complexity considerations. 5 As NTN has a number of NTN-specific information elements that are only required when accessing an NTN cell, and also due to the rather large information elements, it was agreed that new system information block (SIB) was needed. In NR NTN, SIB 19 contains the required information to access an NTN cell, with the SIB 19 field descriptions shown in Table 1 below. 10 Table 1: SIB 19 field descriptions i distanceThresh ; Distance from the serving cell reference location and is used in location-based measurement initiation in RRC_IDLE i and RRC_INACTIVE, as defined in TS 38.304

[20] , Each step represents 50m. This field is only present in an NTN i cell. i movingReferenceLocation i Reference location of the serving cell of an NTN Earth moving system at a time reference. It is used in location- i based measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304

[20] , The time reference i of this field is indicated by epochTime in ntn-Config of the serving cell. This field is excluded when determining ; changes in system information, i.e., changes to movingReferenceLocation should neither result in system i information change notifications nor in a modification of valueTag in SIB1. This field is only present in an NTN cell. i ntn-Config ; Provides parameters needed for the UE to access NR via NTN access such as Ephemeris data, common TA i parameters, k_offset, validity duration for UL sync information and epoch. In a TN cell, this field is only present in i ntn-NeighCellConfigList and ntn-NeighCellConfigListExt. i ntn-NeighCellConfigList, ntn-NeighCellConfigListExt i Provides a list of NTN neighbour cells including their ntn-Config, carrier frequency and PhysCellld. This set includes i 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- i NeighCellConfigList applies. Network provides ntn-Config for the first entry of ntn-NeighCellConfigList. If the ntn- i Config is absent for any other entry in ntn-NeighCellConfigList, the ntn-Config provided in the previous entry in ntn- i NeighCellConfigList applies. i referenceLocation i Reference location of the serving cell provided via NTN quasi-Earth fixed system and is used in location-based i measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304

[20] , This field is only present ; in an NTN cell. i satSwitchWithReSync i Provides parameters for the target satellite required to perform satellite switch with re-synchronization. This field is ; only present in an NTN cell and its presence indicates that satellite switch without PCI change is supported in the ; cell. ; distanceThresh ; Distance from the serving cell reference location and is used in location-based measurement initiation in RRC_IDLE i and RRC_INACTIVE, as defined in TS 38.304

[20] , Each step represents 50m. This field is only present in an NTN i cell. i movingReferenceLocation i Reference location of the serving cell of an NTN Earth moving system at a time reference. It is used in location- i based measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304

[20] , The time reference i of this field is indicated by epochTime in ntn-Config of the serving cell. This field is excluded when determining ; changes in system information, i.e., changes to movingReferenceLocation should neither result in system i information change notifications nor in a modification of valueTag in SIB1. This field is only present in an NTN cell. i t-Service i Indicates the time information on when a cell provided via NTN system is going to stop serving the area it is i currently covering. This field applies for both service link switches in NTN quasi-Earth fixed system and feeder link i switches for both NTN quasi-Earth fixed and Earth moving system. 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 i Monday, January 1, 1900). The exact stop time is between the time indicated by the value of this field minus 1 and i the time indicated by the value of this field. The reference point for t-Service is the uplink time synchronization i reference point of the cell. This field is only present in an NTN cell. satSwitchWith ReSync field descriptions i ssb-TimeOffset i Indicates the time offset between the SSB from source and target satellite at the uplink time synchronization i reference point. It is given in number of subframes. i t-ServiceStart i Indicates the time information on when the target satellite is going to start serving the area currently covered by the i serving satellite. The field indicates a time in multiples of 10 ms after 00:00:00 on Gregorian calendar date 1st i January 1900 (midnight between Sunday, December 31,1899, and Monday, January 1, 1900). The exact start time ; is between the time indicated by the value of this field minus 1 and the time indicated by the value of this field. It is known that the IE SystemInformationBlockType31 contains satellite assistance information for the serving cell. SystemInformationBlockType31 is only signalled for an NTN cell. The 5 SystemInformationBlockType31 field descriptions are illustrated in table 2 below: Table 2: SystemlnformationBlockType31 field descriptions i distanceThresh ; Distance from the serving cell reference location and is used in location-based measurement initiation in RRC_IDLE i (as specified in TS 36.304 [4]) and RRC_CONNECTED. Each step represents 50m. epochTime Epoch time of the satellite ephemeris data and common TA parameters, see TS 36.213

[23] , This field also indicates the epoch time for the reference location of earth moving cells if present. The reference point for epoch time of the serving satellite ephemeris and Common TA parameters is the uplink time synchronization reference point when this field is provided in an NTN cell and the eNB when this field is provided in a TN cell. 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(-NB) is transmitted. E-UTRAN always includes epochTime when SIB31(-NB) 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 RRCConnectionReconfiguration 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. kOffset 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 xio-3 ps. Actual value = field value * 32.55208 x10-3. If the field is absent, the UE uses the (default) value of 0. nta-CommonDrift Drift rate of the common TA, see TS 36.213

[23] , Unit of ps / s. Step of 0.2 xio-3 ps / s. Actual value = field value * 0.2 xio-3. 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 xio-4 ps / s2. Actual value = field value * 0.2 xl0-4. If the field is absent, the UE uses the (default) value of 0. orbital Para meters Instantaneous values of the satellite orbital parameters. The signalled values are valid at least for the duration as defined by ul-SyncValidityDuration and epochTime. referenceLocation Reference location of the NTN quasi-earth fixed cell or earth moving cell, used in location-based measurement initiation in RRC_IDLE (as specified in TS 36.304 [4]) and RRC_CONNECTED. If configured by an earth moving cell, the broadcast reference location corresponds to the epoch time, and the UE derives the real-time reference location based on the serving satellite ephemeris, see TS 36.304 [4], ; state Vectors ; Instantaneous values of the satellite state vectors. The signalled values are valid at least for the duration as defined by i ul-SyncValidityDuration and epochTime. i ul-SyncValidityDuration i Validity duration of the satellite ephemeris data and common TA parameters, i.e. maximum time duration (from i epochTime) during which the UE can apply the satellite ephemeris without acquiring new satellite ephemeris, see TS i 36.213

[23] , Unit in second. ; Value s5 corresponds to 5 seconds, value s10 corresponds to 10 seconds and so on. i The ul-SyncValidityDuration is only updated when at least one of epochTime, nta-CommonParameters, ephemerisinfo i is updated. The system information contains the following: (i) Serving cell Ephemeris elements, which allows a UE to calculate the satellite position for doppler and time pre-compensation. This can be of three formats: a. PVT format - which describes a (X,Y,Z) position as well as a speed vector (vX, vY, vZ). 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; b. Orbital parameters (also referred to as Keplerian format) provides parameters that indicate how a celestial body / satellite moves in space, which is then used to infer the satellite position and allows for accurate synchronization and prediction of future NTN payload position. Altogether they occupy 164 bits; and c. TLE ephemeris elements (only used for Discontinuous Coverage in loT NTN). Altogether they occupy 189 bits. (ii) Timing Advance (TA) common parameters - this provides the common timing advance parameters which is introduced to compensate for the feeder link delays. The signalling consists of (in total taking up 57 bits): a. Absolute TA common, taking up 23 bits; b. Drift of the TA common - how the TA common drifts, i.e., the first derivative, taking up 19 bits; and c. Variation of the TA common - how the TA common varies, i.e., the second derivative of the TA common, taking up 15 bits. (iii) Synchronization validity duration - used to define how long the ephemeris and TA common is valid. (iv) Epoch time - when the synchronization validity duration should start. (v) K-Offset - scheduling offset for timing relationship in NTN. (vi) K-Mac - Scheduling offset used when the downlink and uplink frame timing is not aligned. (vii) NR NTN specific information also include (as part of 3 8.3 31): a. T-Service (signalled in SIB3 in loT NTN). b. Reference location and distance threshold - used for location-based measurement initiation in RRC IDLE and RRC Connected mode. c. Neighbour cell ephemeris, which is used for idle mode measurements. In Release 18 loT NTN, a new System Information Block was introduced for the purpose of signalling the neighbour cell assistance information for measurement purposes, which is SystemInformationBlockType33. The SystemInformationBlockType33 contains similar information elements as for those for serving cell, such as the ephemeris elements, TA common parameters, epoch time etc. It does not contain a synchronization validity duration, as the synchronization requirements are less stringent compared to serving cell synchronization. Instead, it has an element neighValidityDuration that indicates the validity for all of the ephemeris elements. The new SIB is allowed to be broadcasted in a terrestrial network to allow for loT TN to loT NTN idle and connected mode mobility. Table 3: The SystemInformationBlockType33 field descriptions: SysteminformationBiockfype33 field descriptions ; epochTime ; Epoch time of the neighbour satellite ephemeris data and common TA parameters, see TS 36.213 i

[23] , The reference point for epoch time of the neighbour satellite ephemeris and Common TA i parameters is the uplink time synchronization reference point. i epochTime is the starting time of a DL subframe indicated by startSFN and startSubframe. If this ; field is absent, the UE uses epoch time of the serving cell, otherwise the field is based on the timing i of the serving cell, i.e. the SFN and sub-frame number indicated in this field refers to the SFN and i sub-frame of the serving cell. The startSFN indicates the SFN nearest to the frame where the i message indicating the epochTime is received. i k-Mac ] i Scheduling offset used when downlink and uplink frame timing are not aligned at the eNB, see TS i 36.213

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

[23] , Unit in ms. i neighValidityDuration i Validity duration of the neighbour satellite ephemeris data and common TA parameters, i.e. ; maximum time duration (from epochTime) during which the UE can apply the satellite ephemeris i without acquiring new satellite ephemeris, see TS 36.213

[23] , Unit in second. i Value s5 corresponds to 5 seconds, value s10 corresponds to 10 seconds and so on. i If this field is absent, the UE uses validity duration from the serving cell assistance information. i nta-Common ] i Network-controlled common TA, see TS 36.213

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

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

[23] , Unit of ps / s2. i Step of 0.2 xio-4 ps / s2. Actual value = field value * 0.2 xi o-4. ; ; If the field is absent, the UE uses the (default) value of 0. i t ServiceStartNeigh I i Indicates the earliest time when the area covered by the current serving cell is going to be covered ; by the neighbour cell(s) served by the satellite indicated by satellite I d. This field is only present for i the neighbour cell(s) provided via NTN quasi-Earth fixed system. As the ephemeris constantly changes due to the movement of the NTN pay load, there is a need to make sure that the UE is correctly synchronized. Thus, whenever an UE connects to an eNB, the UE needs to read the system information. In the lower part of FIG. 1, a timing diagram illustrates the ephemeris synchronization operation, where in a) SIB31 functions as normal in 150 and b) where the UE fails to read SIB31 in 160 during T318, which then expires and triggers Radio Link Failure (RLF). As illustrated, a timer T317 152 associated with the ephemeris element that is started every time SIB31 is read. At expiry of T317 152, the UE is no longer considered synchronized and it will have to re-acquire SIB31 in order to stay synchronized. In NR NTN, the UE 106 shall ensure that it has a recent ephemeris (SIB 19 in NR) by reading the SIB in time by UE implementation. In loT NTN, since an loT UE (LTE-M and NB-IoT UE) is not expected to be able to acquire system information in connected mode, the UE 106 tunes away and is likely unreachable while reading SIB31. If the loT NTN UE is unable to read the SIB31 within a second timer T318 154 with a configured duration, the UE performs RLF at 170 in a similar manner to other cases where RLF is performed. The T317 timer is different compared to a normal timer in RRC does not commens 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 152 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 a 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. In NTN, using the position of the UE 106 in certain procedures is a lot more useful compared to a terrestrial network owing to the very large cells. Similarly, for quasi earth-fixed cells, where the satellite moves but the cell illuminated on the ground changes with time, using time to initiate or stop certain procedures can be very useful. One such example where time or position is useful is for idle mode cell reselection as this is used to select a cell to camp on. In 3 GPP Rei-18, one enhancement that enables starting measurements has been introduced based on time and position. In non-NTN, there are conditions for triggering measurement initiation in both NR and E-UTRAN. The conditions are based on measured signal strength and signal quality. The detailed conditions are that the received signal strength level (Srxlev) is larger than a broadcasted threshold SnonlntraSearchP and the received signal quality level is larger than a broadcasted threshold SnonlntraSearchQ. Both of these thresholds are broadcasted in SystemInformationBlockType3. Referring now to FIG. 2, a known NTN idle mode measurement triggering mechanism 200 is illustrated, based on UE position. For the measurement-initiation based on position, the UE is allowed to not perform measurements of E-UTRAN and inter-RAT frequencies of equal or lower priority if the distance from the UE to a reference location is smaller than a threshold. Else the UE shall perform measurement of E-UTRAN and inter-RAT frequencies of equal or lower priority. The distance threshold 210 and the reference location 220 is broadcasted by the network. For moving cell cases, where the cell sweeps the earth as the satellite moves, there is the possibility of configuring the reference location 220 to moving. The condition is still the same, only that the reference location 220 moves. In both of these cases, the non-NTN condition needs to be fulfilled, i.e., that the received signal strength level (Srxlev) is larger than SnonlntraSearchP and the received signal quality level is larger than SnonlntraSearchQ. For the time-based measurement initiation, the UE shall perform intra-frequency, inter-frequency and inter-RAT measurements before the time indicated by a broadcasted threshold t-Service. Another parameter t-ServiceStartNeigh can optionally also be signalled to indicate when to start the measurements and how the UE uses this parameter is up to implementation. Referring now to FIG. 3 a known E-UTRAN connected mode handover procedure 300, by a UE 106 from a source eNB 310 to a target eNB 312, is illustrated. 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. At 320, the UE 106 performs neighbour cell measurements, which are configured by the network. At 325, a measurement report (of a neighbour cell) is triggered and sent to the eNB. At 330 after the source eNB 310 having decided based on measurement report or any other information whether to initiate an handover, at 335 the source eNB 310 sends a Handover Request to target eNB 312. The target eNB 312 performs admission control at 340 and at 345, and sends an Handover Request Acknowledge to the source eNB 310. At 350, the source eNB 310 triggers a handover command, which is sent to the UE 106. This handover command consists of the RRC message RRCConnectionReconfiguration, containing the mobilityControlInfo field. At 355, the UE 106 prepares for handover and performs a handover to the target eNB 312 via the random access procedure. If a neighbour cell measurement is configured to be performed in a NTN cell, then as being discussed in Rei-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 broadcasted fashion using SIB. Referring now to FIG. 4, a known mobility from NR to E-UTRAN, by a UE 106 from a source eNB 310 to a target eNB 312, procedure 400 is illustrated. When performing handover from NR to E-UTRAN, this is done via the RRC message MobilityFromNRCommand. At 420, an RRC message MobilityFromNRCommand is sent from a source gNB 310 (NR) to the UE 106, and contains the handover command based on the specific RAT that the UE shall perform mobility to. At 430, the UE 106 prepares the configuration across the PHY / MAC / RLC / PDCP / RRC layers. At 440, the UE 106 and target eNB 312 exchange Msgl / Msg2 messages. Msgl is a random access preamble, essentially a signal indicating only a single number. The signal is design to allow for the eNB / gNB to use signal processing to easily identify the timing of the UE, as well as identify multiple Msgl sent by different UEs in the same RACH slot. Msg2 contains the reply to Msgl, with the number indicated in Msgl, along with a timing advance adjustment which was identified by receiving Msgl. It also contains an uplink grant, which is used to send Msg3 or the RRCConnectionReconfigurationComplete at 450. At 450, in the case of handover to E-UTRAN a message sent by UE 106 to target eNB 312 contains the E-UTRAN RRCConnectionReconfigurationcomplete. 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. Referring now to FIG. 5, a known mobility procedure 500 triggered via the RRCConnectionReconfiguration command, by a UE 106 from a source eNB 310 to a target eNB 312, is illustrated. When a UE 106 in E-UTRAN operates in 5GC, the UE 106 uses NR PDCP and SDAP instead of LIE PDCP (i.e. no SDAP). At 510, an RRCConnectionReconfiguration command is sent from a source gNB 310 (NR) to the UE 106, and contains the handover type and EPC-to-5GC information. At 520, the UE 106 initiates an inter-RAT mobility, since the source is EPC and the target is 5GC. At 530, the UE 106 prepares the configuration across the PHY / MAC / RLC / NR PDCP / SDAP / RRC layers. At 540, the UE 106 and target eNB 312 exchange Msgl / Msg2 messages. At 550, in the case of handover to E-UTRAN a message sent by UE 106 to target eNB 312 contains the E-UTRAN RRCConnectionReconfigurationcomplete. Referring now to FIG. 6, a known mobility procedure 600 performed via RRC Connection release procedures, i.e., so-called re-direction, by a UE 106 from a source eNB 310 to a target eNB 312, is illustrated. In this case an eNB 310 makes a connection release decision at 620 and sends a UE a RRC Connection Release message, which contains redirectedCarrierlnfo, to the UE 106 at 630. The UE may be in RRC CONNECTED or attempting to connect when receiving the RRC Connection Release. This procedure is useful for instance when there is no Xn inter-node setup between the RATs, which is required for connected mode mobility, or when there is urgent load balancing needed and the network would like to avoid the overhead of configuring connected mode handovers, as this involves configuring measurements and sending the handover command. The re-direction from E-UTRAN to NR contains the following fields: Frequency of the carrier to re-direct to; Subcarrier spacing of the SSBs; and The SSB Measurement Timing Configuration (SMTC). For the UE to perform idle mode procedures, such as cell (re-)selection for intra-frequency cells, inter-frequency cells as well as inter-RAT frequencies / cells (GERAN - 2G, UTRA - 3G, cdma2000 - 3G and NR - 5G). The following SIBs are broadcasted in eMTC or E-UTRAN for the purposes of idle mode cell search procedures: SIB3 - Common cell reselection info; SIB4 - Information to perform Intra-frequency cell reselection; SIB5 - Information to perform Inter-frequency cell reselection. In an NR cell, SIB5 is broadcasted to perform inter-RAT measurements of an E-UTRAN cell; SIB6 - Information to perform UTRA Inter-RAT cell reselection; SIB7 - Information to perform GERAN Inter-RAT cell reselection; SIB8 - Information to perform CDMA2000 inter-RAT cell reselection; SIB24 - Information to perform NR inter-RAT cell reselection. SIB24 is broadcasted in an E-UTRAN cell to perform inter-RAT measurements of an NR cell. This gives information important about an NR cell required to measure an NR cell; SIB27 - Information to perform NB-IoT inter-RAT cell selection. The following SIBs are broadcasted in NB-IoT for the purposes of idle mode cell search procedures: SIB3-NB: Common cell reselection info; SIB4-NB: Information to perform Intra-frequency cell reselection; SIB5-NB: Information to perform Inter-frequency cell reselection; SIB27-NB: Information to perform GERAN inter-RAT cell reselection. 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 5. When a UE in E-UTRAN operates in 5GC, the UE uses NR PDCP and SDAP instead of LTE PDCP (i.e. no SDAP). In RAN#102, the following objective has been proposed, with no solution put forward: Mobility enhancements [RAN2, RAN4]: Specify support for IDLE mode mobility from E-UTRAN TN to NR NTN, where E-UTRAN TN provides satellite information in SIB. In light of the above, the inventor has recognised and appreciated that there are still a lot of E-UTRAN (4G LTE) sites in modern deployments, especially in rural sites, as 5G is more specialized in urban sites to absorb higher traffic requirements etc, and it is believed that these sites will remain for a long time. As NTN would typically serve a so-called ultra-rural use case where there are no terrestrial sites, it is plausible to believe that the mobility between NTN and TN is most likely to occur between the rural 4G LTE sites and NTN. Thus, the inventor has recognised and appreciated that the mobility between E-UTRAN and NR NTN is considered very important. In both loT NTN and NR NTN in Release 18, the possibility of broadcasting NTN assistance information was introduced. This is mainly targeting (E-UTRA) loT TN 710, 711 to (E-UTRA) loT NTN 712, 722 mobility, and NR TN to NR NTN mobility 700, as illustrated in FIG. 7. So far, no methods to handle E-UTRA TN to NR NTN have been introduced. Summary A base station, a wireless communication unit and methods of mobility for a base station and a wireless communication unit are described according to the Claims. Brief Description of the Drawings Further details, aspects and embodiments will be described, by way of example only, with reference to the drawings. In the drawings, similar reference numbers are used to identify like or functionally similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. FIG. 1 illustrates a known simplified non-terrestrial cellular architecture. FIG. 2 illustrates a known NTN idle mode measurement triggering based on position. FIG. 3 illustrates a known E-UTRAN connected mode handover procedure. FIG. 4 illustrates a known mobility from NR to E-UTRAN procedure. FIG. 5 illustrates a known mobility triggered via the RRCConnectionReconfiguration command. FIG. 6 illustrates a known mobility procedure 600 performed via RRC Connection release procedures. FIG. 7 illustrates a simplified example of a mobility requirement (E-UTRA) loT TN to (E-UTRA) loT NTN mobility, and NR TN to NR NTN mobility. FIG. 8 illustrates a 3GPP™ 5G communication system with NTN base stations, adapted in accordance with some example embodiments. FIG. 9 illustrates one example of geographical areas in which a UE is required to measure NTN cells or frequencies, and areas in which the UE is not required to measure NTN cells, in accordance with some example embodiments. FIG. 10 illustrates a block diagram of an NTN base station communicating with a UE, adapted in accordance with some example embodiments. FIG. 11 illustrates an example of the flowchart that leads to a determination of whether (or not) the UE shall measure NTN cells or frequencies, in accordance with some example embodiments. FIG. 12 illustrates a simplified message sequence chart of Redirecting a UE from eNB (E-UTRAN) to NTN gNB (NR NTN), in accordance with some example embodiments. FIG. 13 illustrates a further simplified message sequence chart of signalling a satellite ID in SIB33, which is then referred to in a release message, in accordance with some example embodiments. Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and / or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various example embodiments. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments. It will be further appreciated that certain actions and / or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein. Detailed Description The inventor has recognised and appreciated that there are several considerations for handling E-UTRA TN to NR NTN mobility. First, measuring NTN is a lot more power consuming compared to measuring a terrestrial cell. Hence, the inventor has recognised and appreciated that methods to minimize measuring NTN cells should be introduced. Secondly, the inventor has recognised and appreciated the difficulty in how a UE can be re-directed from a terrestrial E-UTRAN cell towards an NR NTN cell. Examples herein described propose approaches around methods for performing mobility between a terrestrial network to a non-terrestrial network, where both a terrestrial network TN and non-terrestrial network NTN can be NR or E-UTRAN (LTE). Although examples herein described are directed to E-UTRAN TN to NR NTN mobility, it is envisaged that some of the approaches described below are applicable for one or more of: NR TN to E-UTRAN NTN, or for E-UTRAN NTN to NR NTN, NR NTN to E-UTRAN NTN, or even E-UTRAN NTN to E-UTRAN NTN and NR NTN to NR NTN mobility. It is also envisaged that the approaches described below apply equally to eNBs, gNBs, NG-RAN or NG-eNB. Hence, it is envisaged that the terms are to be considered interchangeably. 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. It is also envisaged that an E-UTRAN (cell) is (in a loose sense) the base station of an eMTC / LTE-M cell. Thus, the term ‘E-UTRAN’ should be considered, in one example, an ToT NTN base station’. In 3GPP™ so far, only loT is supported for LTE NTN and not ordinary non-loT LTE NTN. It should be noted that examples herein described are not limited to loT NTN E-UTRAN as it is envisaged that “ordinary” non-IoT LTE NTN are also supported. It is also envisaged that the approaches described herein are also applicable if non-Standalone NTN is supported, i.e., EN-DC (E-UTRAN-NR Dual Connectivity) is supported in the future. Similarly, it is also envisaged that the approaches described herein are also applicable for mobility from terrestrial, non-NTN, base stations. Example embodiments are described with reference to radio access networks, which term encompasses and is considered to be equivalent to and interchangeable with communication cells, namely the facilitation of communications within a cell that may access other parts of the communication system as a whole. Although some examples embodiments target loT NTN, it is envisaged that the concepts herein described may also be relevant for 5G NR. Referring now to FIG. 8, part of a wireless communication system 800 is shown in outline, in accordance with one example embodiment. In this example embodiment, the wireless communication system 800 is compliant with, and contains network elements capable of operating over, a 4th generation (4G), a 5th generation (5G) or 6th generation (6G) wireless communication system, which are currently under discussion in the third Generation Partnership Project (3GPP™). The wireless communication system 800 architecture consists of radio access network (RAN) and core network (CN) elements (not shown), with the core network elements being coupled to external networks (named Packet Data Networks (PDNs)), such as the Internet or a corporate network. As illustrated, the CN is operably connected to two NodeBs (eNB 810 and gNB 812), with respective, coverage areas (or cells) 880, 885. A plurality of wireless communication units 825 communicate with the serving eNB 810 or gNB 812. In accordance with example embodiments, at least one eNB 810, gNB 812 and at least one UE 870, 875 (amongst other elements) have been adapted to support the concepts hereinafter described. In this example, the main components of the RAN include a TN eNB 810 and an NTN eNB 812, in a form of a satellite, which perform many standard base station functions and are connected to the CN via an SI interface / feeder link and to the wireless communication units 825 via a Uu interface. A wireless communication system will typically have a large number of such infrastructure elements, including a number of terrestrial base stations where, for clarity purposes, only a limited number are shown in FIG. 8. Each of the TN eNB 810 and the NTN gNB 812 are able to control and manage the radio resource related functions for a plurality of wireless communication units 825. Each of the wireless communication units 825 comprise a transceiver unit operably coupled to signal processor (with one wireless communication unit illustrated in such detail for clarity purposes only). The system comprises many other wireless communication units 825 and eNBs 810 and gNBs 812, which for clarity purposes are not shown. In some optional examples, for example in the illustrated 5G system, the wireless communication units (e.g., UEs 825, 870, 875), when they are in a RRC-idle state, may be able to initiate a cell re-selection procedure in response to the conducted measurements. In accordance with examples herein described, a wireless communication system comprises a first base station, such as NTN eNB 810, supporting a first network and a second base station, such as gNB wireless base station 812 supporting a second terrestrial network, and a plurality of wireless communication units 825, 870, 875. In this example, at least one of the first network and second network is a non-terrestrial network, NTN, the first base station 810 comprising: a transceiver; and a processor, operably coupled to the transceiver and arranged to send a transmission 822 to at least a first wireless communication unit 870 of the plurality of wireless communication units, wherein the transmission 822 comprises an instruction to the at least first wireless communication unit 870 to: perform a search for radio signal transmissions from the eNB wireless base station 812 of the second network; and perform radio signal measurements on said transmissions from the eNB wireless base station 812 of the second network. The first wireless communication unit 870 comprises a communication unit processor that is configured to process the instruction and in response to a determination that the first network is a NTN, the communication unit processor decides not to perform radio signal measurements on said radio signal transmissions from the first network. FIG. 9 illustrates one example of geographical areas in which a UE is required to measure NTN cells or frequencies, and areas in which the UE is not required to measure NTN cells, in accordance with some example embodiments. Referring now to FIG. 10, more detailed block diagrams of an eNB or gNB TN or NTN wireless base station (equivalent in functionality details to eNB or gNB TN or NTN base station 810, 812 in FIG. 8) and a wireless communication unit (such as a UE 870, 875) are illustrated, where the respective communications units have been adapted in accordance with some example embodiments. The eNB or gNB TN or NTN wireless base station 810, 812 contains an antenna 1002, for receiving transmissions, coupled to an antenna switch or duplexer 1004 that provides isolation between receive and transmit chains within the eNB or gNB TN or NTN wireless base station 810, 812. One or more receiver chains, as known in the art, include receiver front-end circuitry 1006 (effectively providing reception, filtering and intermediate or base-band frequency conversion). The receiver front-end circuitry 1006 is coupled to a signal processor 1008 (generally realized by a digital signal processor (DSP)). A skilled artisan will appreciate that the level of integration of receiver circuits or components may be, in some instances, implementation-dependent. The controller 1014 maintains overall operational control of the eNB or gNB TN or NTN wireless base station 810, 812. The controller 1014 is also coupled to the receiver front-end circuitry 1006 and the signal signal processor 1008. In some examples, the controller 1014 is also coupled to a frequency generation circuit 1017 and a memory device 1016 that selectively stores operating regimes, such as decoding / encoding functions, synchronization patterns, code sequences, and the like. A timer 1018 is operably coupled to the controller 1014 to control the timing of operations (e.g., transmission or reception of time-dependent signals) within the eNB or gNB TN or NTN wireless base station 870, 875. As regards the transmit chain, this essentially includes an input interface 1020, coupled in series through transmitter / modulation circuitry 1022 and a power amplifier 1024 to the antenna 1002, antenna array, or plurality of antennas. The transmitter / modulation circuitry 1022 and the power amplifier 1024 are operationally responsive to the controller 1014. The signal processor 1008 in the transmit chain may be implemented as distinct from the signal processor in the receive chain. Alternatively, a single processor may be used to implement a processing of both transmit and receive signals, as shown in FIG. 10. Clearly, the various components within the eNB or gNB TN or NTN wireless base station 810, 812 can be realized in discrete or integrated component form, with an ultimate structure therefore being an application-specific or design selection. The processor 1008 and transceiver (e.g., transmitter / modulation circuitry 1022 and receiver front-end circuitry 1006) of the eNB or gNB TN or NTN wireless base station 810, 812 are configured to facilitate mobility of a served wireless communication unit, such as a UE, to or from another eNB or gNB TN or NTN wireless base station, according to at least one of the operations in accordance with the approach described in one of FIG. 11, FIG. 12 or FIG. 13. The eNB or gNB TN or NTN wireless base station 810, 812 is configured to determine whether (or not) the UE 870 shall measure TN or NTN cells or frequencies, in accordance with some example embodiments. The processor 1008 and transmitter / modulation circuitry 1022 are configured to send a message to a wireless communication or broadcast an SIB to the wireless communication unit 870, 875 to instigate the wireless communication unit searching for a second base station and performing radio signal measurements from a second eNB or gNB TN or NTN wireless base station. FIG. 10 also shows a high-level block diagram of the wireless communication unit (a user equipment UE in 3GPP parlance) 870, 875 contains an antenna 1052, for receiving transmissions, coupled to an antenna switch or duplexer 1054 that provides isolation between receive and transmit chains within the wireless communication unit 870, 875. One or more receiver chains, as known in the art, include receiver front-end circuitry 1056 (effectively providing reception, filtering and intermediate or base-band frequency conversion). The receiver front-end circuitry 1056 is coupled to a signal processor 1058 (generally realized by a digital signal processor (DSP)). A skilled artisan will appreciate that the level of integration of receiver circuits or components may be, in some instances, implementation-dependent. The controller 1064 maintains overall operational control of the wireless communication unit 870, 875. The controller 1064 is also coupled to the receiver front-end circuitry 1056 and the signal processor 1058. In some examples, the controller 1064 is also coupled to a frequency generation circuit 1067 and a memory device 1066 that selectively stores operating regimes, such as decoding / encoding functions, synchronization patterns, code sequences, and the like. A timer 1068 is operably coupled to the controller 1064 to control the timing of operations (e.g., transmission or reception of time-dependent signals) within the wireless communication unit 870, 875. As regards the transmit chain, this essentially includes an input interface 1070, coupled in series through transmitter / modulation circuitry 1072 and a power amplifier 1074 to the antenna 1052, antenna array, or plurality of antennas. The transmitter / modulation circuitry 1072 and the power amplifier 1074 are operationally responsive to the controller 1064. The signal processor 1058 in the transmit chain may be implemented as distinct from the signal processor in the receive chain. Alternatively, a single processor may be used to implement a processing of both transmit and receive signals, as shown in FIG. 10. Clearly, the various components within the wireless communication unit 870, 875 can be realized in discrete or integrated component form, with an ultimate structure therefore being an application-specific or design selection. The processor 1058 and transceiver (e.g., transmitter / modulation circuitry 1072 and receiver front-end circuitry 1056) of the wireless communication unit 870, 875 are configured to communicate with the eNB or gNB TN or NTN wireless base station 810, 812 on a first frequency that is set by frequency generation circuit 1067. In accordance with some examples, the processor 1058 and transceiver (e.g., transmitter / modulation circuitry 1072 and receiver front-end circuitry 1056) of the wireless communication unit 870, 875 are configured to facilitate mobility of the wireless communication unit, such as a UE, to or from an alternative eNB or gNB TN or NTN wireless base station, according to at least one of the operations in accordance with the approach described in one of FIG. 11, FIG. 12 or FIG. 13. If this example describes mobility from an eNB TN to a gNB NTN, the processor 1058 and receiver front-end circuitry 1056 are configured to camp the UE on, say, a terrestrial eNB TN cell. The processor 1058 of the UE checks the serving cell signal, which in some examples, checks the serving cell signal for LTE-M and E-UTRAN. In one example, the receiver front-end circuitry 1056 and processor 1058 checks whether (or not) the received signal strength level, Srxlev, is larger than a threshold SnonlntraSearchP and whether (or not) the signal quality Squal is larger than a threshold SnonlntraSearchQ. Once signal strength measurements on the serving cell frequencies have been performed by the wireless communication unit 870, 875, the processor 1058 is configured to ensure that the UE location has been acquired and that the UE supports the location based measurement initiation for a serving cell. The processor 1058 is configured to check if the parameters distanceThresh and referenceLocation are present in a received SIB33. If the parameters distanceThresh and referenceLocation are present in SIB33 the processor 1058 of the UE evaluates whether the distance from UE location to referenceLocation is smaller than the distance threshold. Dependent upon the radio signal measurements and the above determinations, the processor 1058 of the UE identifies whether (or not) the processor 1058 and receiver front-end circuitry 1056 of the UE is to (or is not to) perform measurements of the NTN cells. In some examples, the NTN frequencies or cells can be identified by the presence of satelliteld and the TN frequencies or cells can be identified by the non-presence of satelliteld. In some examples, and as part of NTN enhancements, there have been conditions introduced where the UE can avoid measuring neighbouring cells in idle mode based on both time and UE position. However, this is only specified as part of NTN, thus it is not possible to use these conditions in a terrestrial network, let alone a TN-NTN network. So, in one example, it is envisaged that methods for relaxing measurements may be applied when the UE is camping on a terrestrial network. In some examples, the UE may be configured to only apply the methods to measurement relaxation methods to cells that are NTN cells. This means that the UE will always be required to measure terrestrial cells, regardless of whether the NTN conditions are fulfilled or not. As an example of how a specification may define this condition, it can be such that the UE will only relax measurements, i.e., not perform measurements, on the cells or frequencies that have a satelliteld field (or the information element satelliteAssistancelnfoList provided in SIB3 for intra-frequency, in SIB5 for inter-frequency and SIB24 for NR frequencies) configured. This is because the satelliteld is used to associate a frequency with a specific satellite assistance info element, which contains the ephemeris for a specific satellite. It can also be such that on the cells or frequencies that have are associated with a satellite or a NTN, the UE can relax. A further associated condition may for instance be that SIB33 is broadcast by the TN but SIB31 is not broadcast, or that SIB33 is broadcast. This is because SIB33 are broadcasted to provide neighbour satellite assistance information, which can be broadcasted in a TN or an NTN, while SIB31 is only required to be broadcasted in a NTN. By only broadcasting SIB33 and not SIB31, 5 the UE is made aware that the cell is not an NTN, but a TN providing assistance information for TN-NTN mobility. Thus, a wireless communication unit (e.g., a UE) is configured to communicate with a first base station supporting a first network and a second base station supporting a second network, wherein the first network is a first non-terrestrial network, NTN and the second network is one of: a terrestrial network, TN, a second NTN. The wireless communication unit comprising: a transceiver; and a wireless communication unit processor, operably coupled to the transceiver and arranged to receive a transmission from the second network that comprises an instruction to the wireless communication unit to perform a search for radio signal transmissions from the first network; and perform radio signal measurements on said radio signal transmissions from the first network. The wireless communication unit processor is configured to process the instruction and in response to a determination that the first network is a NTN, the communication unit processor decides not to perform radio signal measurements on said radio signal transmissions from the first network. The cells or frequencies that the UE is required to measure can for instance be only inter-frequency, intra-frequencies or inter-RAT frequencies. As an example, the measurement triggering based on distance, when the condition is triggered, the UE is not required to measure 10 inter-RAT NTN frequencies or cells, and not inter-frequency NTN cells. The NTN inter-RAT frequencies in this case would be NR NTN frequencies, or could potentially be NB-IoT inter-RAT frequencies. In the case where only mobility between E-UTRAN and NR NTN is allowed, and intra-RAT E-UTRAN to E-UTRAN (or loT NTN) mobility is not allowed, the NTN cells would only apply to NR NTN frequencies or cells. 15 In another example, the NTN inter-RAT frequency may be NTN GERAN (2G) or NTN UTRA (3G). In this example, the NTN frequencies to measure may also be differentiated as to whether they are in a specific frequency band. For instance, the UE may not be required to measure Frequency Range 2 (FR2) NTN inter-frequencies, only Frequency Range 1 (FR1) NTN inter-frequencies. This may be important as a single network may support different types of devices and use cases where the UE antenna form factor may be very different. As an example, a Very Small Aperture Terminal (VSAT) UE, which is a common terminology for satellite terminal antennas that are roughly more than 30cm in diameter large, may be able to camp or connect to an FR2 NTN frequency, while a handheld UE may not have this capability. Similarly, in other examples, the cell or frequencies that the UE is required to measure can be of higher priority, or equal or lower priority than the current cell that the UE is camping on. As an example, the UE may be required to only measure intra-frequency and inter-frequencies and inter-RAT frequencies of higher priority, while the inter-frequency and inter-RAT frequencies of equal or lower priorities are not required to be measured. Alternatively, the UE may be configured to measure but apply less stringent measurement requirements. As some of the information fields are in NTN related System Information, or in System Information that would not be suitable for non-NTN UEs, some of the parameters may be introduced in the new SIB33, e.g., a referenceLocation and distanceThresh that is normally signalled in SystemInformationBlockType31. The reference location could then be either the approximate location of the gNB location, or the centre of the cell. The reference location can also be the center of a terrestrial network shared by many cells. Thus, a group of cells within an area would use the same values to trigger NTN measurement initiation. It is envisaged in some examples that these can have the field names referenceLocationTN and distanceThreshTN, t-ServiceStart. This parameter is configured per neighbouring satellite in SIB33, but can for TN->NTN mobility purposes be signalled as a general parameter in SIB33 to apply for all NTN cells and their associated frequencies. Name of the parameter can be t-ServiceStartNeigh. For example, the UE is not required to measure any NTN cells or frequencies before the time has reached t-ServiceStartNTN In another example, when the condition is fulfilled where the UE is required to measure NTN cells, the UE may not be considered required to measure TN cells. In another example, the NTN inter-frequency and inter-RAT frequencies or cells may always be considered to be of lower priority. This can be useful as measuring NTN cells will likely be more power consuming. The specific condition for measuring NTN cells as applied above can for instance be: (i) The distance to the referencelocation is larger than distanceThresh: This may trigger or require the UE to measure NTN cells or frequencies. This may cause the UE to not measure TN cells, or to relax measurements of TN cells or frequencies. (ii) The distance to the referenceLocation is smaller than distanceThresh: This may trigger or require the UE to measure TN cells or frequencies. This may cause the UE to not measure NTN cells or frequencies. (iii) The time has reached parameter t-ServiceStartNTN: This may trigger or require the UE to start measuring NTN cells. This may cause the UE to not measure NTN cells or frequencies. Referring now to FIG. 11, an example flowchart 1100 is illustrated to determine whether (or not) the UE shall measure NTN cells or frequencies, in accordance with some example embodiments. At 1110, the UE camps on a terrestrial cell. At 1120, the UE checks the serving cell signal. In this example, the UE checks the serving cell signal for LTE-M and E-UTRAN, and checks whether (or not) the received signal strength level, Srxlev, is larger than a threshold SnonlntraSearchP and whether (or not) the signal quality Squal is larger than a threshold SnonlntraSearchQ. If it is larger in 1120, at 1130 the UE ensures that the UE location has been acquired and that the UE supports the location-based measurement initiation for a TN. At 1140, the UE checks if the parameters distanceThresh and referenceLocation are present in SIB33. If the parameters distanceThresh and referenceLocation are present in SIB33 in 1140, at 1150 the UE evaluates whether the distance from UE location to referenceLocation is smaller than the distance threshold. If it is evaluated as TRUE at 1150, the UE does not perform measurements of the NTN cells at 1160, where potentially the NTN frequencies or cells can be identified by the presence of satelliteld and the TN frequencies or cells can be identified by the non-presence of satelliteld. If it is evaluated as FALSE at 1150, the UE does perform measurements of NTN cells at 1170, where potentially the NTN frequencies or cells can be identified by the presence of satelliteld and the TN frequencies or cells can be identified by the non-presence of satelliteld. In some examples, it is envisaged that the NTN cells measured may be of a lower or equal priority inter-frequency or inter-RAT frequency NTN cells. In the above examples, the reference location and the distance threshold creates a circle. In a further example, it is envisaged that other geometrical shapes may be introduced to determine whether to measure NTN cells. For example, it is envisaged that a square as defined by a parameter which represents the diagonal d. In other examples, it is envisaged that a hexagonal may be defined by a parameter which represents a hexagonal diameter. In these cases, it is envisaged that a condition may instead be “if the UE is inside the square or hexagonal as defined by parameter X, then the UE may not measure the NTN cells”. In some examples, it is envisaged that the above methods may be applicable for RSS (Resynchronization Secondary Signal)-based measurements, or only for non-RSS based measurements, i.e., measuring on E-UTRAN Cell Reference Signals (CRS’s) or 5G NR Secondary Synchronization Blocks (SSBs). Releasing a UE from E-UTRAN to NR NTN Since idle mode mobility also includes mobility that is triggered by the RRC Connection release procedures, it is important to ensure that these procedures are enhanced with NTN in mind. The UE shall be able to be released or redirected from an E-UTRAN TN cell to a NR NTN cell or frequency. Thus, in one example, the network can release a UE from RRC CONNECTED in an E-UTRAN TN cell to RRC IDLE or RRC INACTIVE in an NR NTN cell. This means that the UE may be re-directed from an E-UTRAN TN cell to an NR NTN cell. Referring now to FIG. 12, a further simplified message sequence chart 1200 illustrates redirecting a UE from an eNB (E-UTRAN) to an NTN gNB (NR NTN), in accordance with some example embodiments. Again, in this further example, at 1210 an UE 870 sends a message to an eNB 810 that includes the UE’s capability to be redirected from E-UTRAN to an NR NTN. The eNB 810 makes a release decision at 1220 and at 1230 sends a RRCConnectionRelease message (that includes an indication to redirect the UE to a satellite {using a redirectionCarrierinfo + satellite ID}). At 1240, the UE 870 then enters an idle mode of operation. At 1250, the UE 870 then performs Cell selection operation using the received redirectionCarrierinfo + satellite ID and NTN assistance information. At 1260, the UE detects the NTN gNB 812 and at 1270 the UE 870 performs an RRC Connection Setup operation with the NTN gNB 812. The re-direction or release may occur as the UE is in RRC CONNECTED, or may occur when the UE is attempting to connect to the E-UTRAN TN cell, i.e., when the UE is not yet in RRC CONNECTED. When the UE is re-directed from RRC CONNECTED, this can be due to the network detecting that it may be more suitable for the UE to be connected to an NR NTN cell, for instance if the position or location information of the UE indicates that it would be more suitable to be connected to an NTN cell. As an example, the UE may be configured to measure a non-terrestrial cell and after the network detects through measurement reports, the network will release or redirect the UE to an NTN cell. When the UE is re-directed or released when attempting to connect to the E-UTRAN TN cell, this may for instance be in response to an RRC Connection Request or an RRC Resume Request, or a RRC Re-establishment Request message sent by a UE. In one example, NR NTN specific information is configured when a UE is released or redirected. This may for instance be one or more of the following. In one example, the NR NTN specific information may be an ephemeris information element of the NR NTN frequency or cell. This can be a single ephemeris element or a list of ephemeris elements, which may mean that the UE is either re-directed towards a single cell, a set of cells associated with a satellite on the frequency, or a set of cells associated with a set of satellites on the frequency. This for instance allow for further ephemeris elements beyond what is signalled in SystemInformationBlockType33, or may allow that SystemInformationBlockType33 is not signalled. Alternatively, it is envisaged that this can be NR NTN ephemeris, NR NTN cell assistance information, or the loT NTN ephemeris or loT NTN cell assistance information. In one example, the NR NTN specific information may be a satelliteld of the NR NTN frequency or cell. In this manner, the satelliteld will then be associated with an ephemeris element that is signalled in the SystemInformationBlockType33. This would be a more efficient way of signalling the ephemeris, which has the limitation that only already signalled ephemeris elements may be used. Alternatively, this may also be a single satelliteld or a set of satellitelds. In one example, the NR NTN specific information may be an ephemeris information element or the satelliteld of the NR NTN frequency cell. In this example, this is a flexible combination of the options as it always the network to signal any of the options, depending on the circumstances as outlined by the advantages and disadvantages above. An example of this option can be seen in Example #2 below. In some cases, it is envisaged that it may occur that the UE is released or redirected with a satellite ID, but have not acquired the SIB33 in order to associate the satellite ID with an ephemeris or a neighbour cell assistance information element. In this case the UE may be configured to first acquire the SIB33 before releasing the connection to the eNB. The UE may alternatively be configured to acquire the SIB33 before performing cell selection after having been released. Alternatively, the network may ensure that it only signals a satellite ID in an RRC Connection release message if the UE has acquired the SIB33. Referring now to FIG. 13, a further simplified message sequence chart 1300 illustrates signalling a satellite ID in SIB33, which is then referred to in a release message, in accordance with some example embodiments. Again, in this further example, an eNB 810 sends a Broadcasting satellite ephemeris in an SIB33 message with an associated satellite identifier (ID) 1310 to a UE 870. The eNB 810 makes a release decision at 1320 and at 1330 sends a RRCConnectionRelease message (that includes an indication to redirect the UE to a satellite {using a redirectionCarrierinfo + satellite ID}. At 1340, the UE 870 then enters an idle mode of operation. At 1350, the UE 870 then performs Cell selection operation using the received redirectionCarrierinfo + satellite ID and NTN assistance information. At 1360, the UE detects the NTN gNB 812 and at 1370 the UE 870 performs an RRC Connection Setup operation with the NTN gNB 812. In one example, the RRC Connection release to NTN indicates that the UE shall or shall attempt to connect to an NTN cell only. This is different to a normal release or re-direct procedure, which does not indicate any specific node to connect to. It may for instance be such that the frequency band indicated by the RRC Connection Release message may indicate that a UE shall connect to NTN. In one example, the UE indicates that it is capable of performing redirection from E-UTRAN to NR NTN. This capability can be separated from any other NTN capabilities, and be a E-UTRAN UE capability. This would be signalled in the information element UE-EUTRA-Capability. It can be a part of Inter-RAT NR Parameters IRAT-ParametersNR-rl 5. In another further example of the redirection capabilities, the UE may signal that it is capable of being redirected from E-UTRAN to an: NR NTN FR1 frequency or alternatively FR1 -1 or FR1 -2 frequency; NR NTN FR2 frequency or alternatively FR2-1 or FR2-2 frequency; NR NTN Lower Earth Orbit (LEO) or non-Geostationary Earth Orbit (NGSO) satellite frequency; NR NTN Geostationary Earth Orbit (GEO) satellite frequency. In some examples, it is envisaged that further enhancements may be supported. For example, in one enhancement, it is envisaged that a mechanism to acquire SIB33 may be supported. Here, it is mandatory for the UE to acquire certain system information blocks (SIBs) when a UE is in idle mode, which includes SIB1 to SIB 8 and depending on support of certain features the SIB 17, SIB21, SIB24, SIB25, SIB26, SIB28, SIB29 and SIB30. For an NB-IoT UE SIB1 to SIB5 and SIB22 is mandatory to acquire in idle mode. It is envisaged that it will likely not be mandatory for a UE to acquire the NTN assistance information in SIB33. However, if the UE does not acquire the satellite assistance information and attempts to measure a frequency as if it is a terrestrial frequency, then it is likely to fail the measurement and not detect anything. Thus, in some examples, it is envisaged that there may be some additional conditions provided on how to acquire the SIB33. In one example, one such condition envisaged is that if the UE has acquired SIB24, and there is a satellite ID for a frequency which the UE supports, the UE shall acquire the SIB33. For example, this may be applicable for a UE in RRC IDLE, RRCINACTIVE and RRC_CONNECTED. In another example, E-UTRAN TN to NR NTN mobility may only be configured for E-UTRAN eNBs connected to a 5G Core network (5GC). It is envisaged that this may be important as NR NTN operation is only supported where the NR NTN gNB is connected to 5GC. If the E-UTRAN eNB is only connected via EPC, then it is likely that the E-UTRAN TN cell and NR NTN cell would not be coordinated enough. Otherwise, the UEs would, in addition to performing TN to NTN, and inter-RAT mobility, also perform inter-Core Network mobility (from EPC to 5GC). In another example, a specific SSB Measurement Timing Configuration (SMTC) for NTN may be introduced when measuring NR NTN cells when an UE is camping on a E-UTRAN cell. In this example scenario, it is envisaged that the UE shall consider the offset in the SMTC window to be defined by the UE propagation delay. This is because when the UE measures an NR NTN cell, the SSBs, which are the signals used to measure the NR NTN cells, will be moving in time, which means that the offset needs to be tracked. In a terrestrial network where the UE in an E-UTRAN cell measures an NR TN cell, the SSB offset is signalled, whereas in a non-terrestrial network the SSB offset is tracked according to the movement of the satellite. The tracking can be performed once a UE has determined that it shall measure an NR NTN cell. Example implementations: #la In this example, if the reference location and distance threshold is broadcast in SIB31, it is envisaged that the UE applies the already existing methods. However, in accordance with examples described herein, if the reference location and distance threshold are broadcast in SIB33, then the UE is configured to apply the condition on whether to measure the inter-frequencies and inter-RAT frequency cells of equal or lower priority, but only to the cells or frequencies that have an associated satellite ID broadcast. Measurement rules for cell re-selection In this example, and based on 36.304 V18.0.0, it is envisaged that the following approach for applying NB-IoT measurement rules for cell re-selection may be adopted. When evaluating Srxlev and Squal of non-serving cells for reselection purposes, the UE shall use parameters provided by the serving cell. The following rules may be used by the UE to limit needed measurements. If the measurements are performed using RSS as specified in

[10] and the serving cell fulfils SrxleV >SlntraSearchP: If distanceThresh and referenceLocation are broadcast in SystemInformationBlockType31, and if the UE supports location-based measurement initiation and has obtained its location information: If referenceLocation is set to fixedCell, referenceLocation is used as serving cell reference location. If referenceLocation is set to movingCell, the UE derives the serving cell reference location based on ephemeris, epochTime, referenceLocation and the UE location. If the distance between the UE and the serving cell reference location is shorter than distanceThresh, the UE may choose not to perform intra-frequency measurements. Else, the UE shall perform intra-frequency measurements. Else, the UE may choose not to perform intra-frequency measurements. Else if the serving cell fulfils Srxlev >SintraSearohP and Squal >SintraSearohQ, the UE may choose not to perform intra-frequency measurements. Otherwise, the UE shall perform intra-frequency measurements. Here, the UE shall apply the following rules for E-UTRAN inter-frequencies and inter-RAT frequencies which are indicated in system information and for which the UE has priority provided as defined previously. For an E-UTRAN inter-frequency or inter-RAT frequency with a reselection priority higher than the reselection priority of the current E-UTRA frequency the UE shall perform measurements of higher priority E-UTRAN inter-frequency or inter-RAT frequencies according to TS 36.133

[10] . For an E-UTRAN inter-frequency with an equal or lower reselection priority than the reselection priority of the current E-UTRA frequency and for inter-RAT frequency with lower reselection priority than the reselection priority of the current E-UTRAN frequency: If the measurements are performed using RSS as specified in

[10] and the serving cell fulfils SrxleV >SnonlntraSearchP: If distanceThresh and referenceLocation are broadcast in SystemInformationBlockType31 or in SystemInformationBlockType33, and if the UE supports location-based measurement initiation and has obtained its location: If referenceLocation is set to fixedCell, the referenceLocation is used as serving cell reference location. If referenceLocation is set to movingCell, the UE derives the serving cell reference location based on ephemeris, epochTime, referenceLocation and the UE location. If the distance between the UE and serving cell reference location is shorter than distanceThresh the UE may choose to: If broadcast in SystemInformationBlockType31, not to perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority unless the UE is triggered to measure an E-UTRAN inter-frequency which is configured with redistributionlnterFreqlnfo. Else, the UE shall perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority according to TS 36.133

[10] , If broadcast in SystemInformationBlockType33, not to perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority, where the frequencies have an associated satelliteld configured, unless the UE is triggered to measure an E-UTRAN inter-frequency which is configured with redistributionlnterFreqlnfo. Else, the UE shall perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority according to TS 36.133

[10] , Else, the UE may choose not to perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority unless the UE is triggered to measure an E-UTRAN inter-frequency which is configured with redistributionlnterFreqlnfo. Else if the serving cell fulfils Srxlev >SnonlntraSearohP and Squal >SnonlntraSearohQ: If distanceThresh and referenceLocation are broadcast in SystemInformationBlockType31 or in SystemInformationBlockType33, and if the UE supports location-based measurement initiation and has obtained its location: If referenceLocation is set to fixedCell, the referenceLocation is used as serving cell reference location. If referenceLocation is set to movingCell, the UE derives the serving cell reference location based on ephemeris, epochTime, referenceLocation and its current location. If the distance between the UE and serving cell reference location is shorter than distanceThresh, the UE may choose to: If broadcast in SystemInformationBlockType31, perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority unless the UE is triggered to measure an E-UTRAN inter-frequency which is configured with redistributionlnterFreqlnfo. Else, the UE shall perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority according to TS 36.133

[10] , If broadcast in SystemInformationBlockType33, perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority, where the frequencies have an associated satelliteld configured, unless the UE is triggered to measure an E-UTRAN inter-frequency which is configured with redistributionlnterFreqlnfo. Else, the UE shall perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority according to TS 36.133

[10] , Else, the UE may choose not to perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority unless the UE is triggered to measure an E- UTRAN inter-frequency which is configured with redistributionlnterFreqlnfo. Otherwise, the UE shall perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority according to TS 36.133

[10] , If the UE supports relaxed monitoring and s-SearchDeltaP is present in SystemInformationBlockType3, the UE may further limit the needed measurements, as specified in clause 5.2.4.12. If t-Service is present in SystemInformationBlockType3 of the serving cell, UE shall perform intra-frequency, inter-frequency or inter-RAT measurements, before the time t-Service regardless whether the serving cell fulfils Srxlev> SintraSearohP and Squal >SintraSearohQ, or Srxlev >SnonintraSearchP and Squal >SnonintraSearohQ. The exact time to start measurements before t-Service is up to UE implementation and t-ServiceStartNeigh if present in SystemInformationBlockType33 may be used to decide on when to start measurements. UE shall perform measurements of higher priority inter-frequencies or inter-RAT frequencies regardless of the remaining service time of the serving cell. SystemInformationBlockType33 The IE SystemInformationBlockType33 contains satellite assistance information for neighbour cells. SystemInformationBlockType33 information element - ASN1 START SystemInformationBlockTypeXX-rl8 ::= SEQUENCE { neighSatelliteInfoList-rl8 NeighSatelliteInfoList-rl8 OPTIONAL, — Need OR neighValidityDuration-rl8 ENUMERATED {s5, slO, sl5, s20, s25, s30, s35, s40, s45, s50, s55, s60, sl20, si80, s240, s900} OPTIONAL, - Need OP lateNonCriticalExtension OCTET STRING OPTIONAL, ..., [[ referenceLocationTN-rl9 ReferenceLocation-rl 8 OPTIONAL, — Need OP distanceThreshTN-rl9 INTEGER(0.65535) OPTIONAL - Need OP ]] NeighSatelliteInfoList-rl8 ::= SEQUENCE (SIZE(l..maxSat-rl8)) OF NeighSatellitelnfo-rl8 NeighSatellitelnfo-rl 8 ::= SEQUENCE { satelliteld-rl8 ephemerislnfo-rl 8 state Vectors orbitalParameters nta-CommonParameters-18 Satelliteld-rl8, CHOICE { EphemerisStateVectors-rl 7, EphemerisOrbitalParameters-rl 7 SEQUENCE { nta-Common-rl 8 INTEGER (0.. 8316827) OPTIONAL, - Need OP nta-CommonDrift-rl8 INTEGER (-261935..261935) OPTIONAL, - Need OP nta-CommonDriftVariation-rl 8 INTEGER (0. .29479) OPTIONAL - Need OP epochTime-rl8 SEQUENCE { startSFN-rl8 INTEGER (0.. 1023), startSubFrame-rl 8 INTEGER (0..9) OPTIONAL, — Need OP k-Mac-rl8 INTEGER (1..512) OPTIONAL, - Need OP t-ServiceStartNeigh-rl8TimeOffsetUTC-rl7 OPTIONAL, -Need OR - ASN1STOP Example implementations #lb Measurement rules for cell re-selection In this example, and based on 36.304 V18.0.0, it is envisaged that the following approach for applying NB-IoT measurement rules for cell re-selection may be adopted. When evaluating Srxlev and Squal of non-serving cells for reselection purposes, the UE shall use parameters provided by the serving cell. Following rules are used by the UE to limit needed measurements: If the measurements are performed using RSS as specified in

[10] and the serving cell fulfils SrxleV >SlntraSearchP: If distanceThresh and referenceLocation are broadcast in SystemInformationBlockType31, and if the UE supports location-based measurement initiation and has obtained its location information: If referenceLocation is set to fixedCell, referenceLocation is used as serving cell reference location. If referenceLocation is set to movingCell, the UE derives the serving cell reference location based on ephemeris, epochTime, referenceLocation and the UE location. If the distance between the UE and the serving cell reference location is shorter than distanceThresh, the UE may choose not to perform intra-frequency measurements. Else, the UE shall perform intra-frequency measurements. Else, the UE may choose not to perform intra-frequency measurements. Else if the serving cell fulfils Srxlev >SintraSearohP and Squal >SintraSearohQ, the UE may choose not to perform intra-frequency measurements. Otherwise, the UE shall perform intra-frequency measurements. The UE shall apply the following rules for E-UTRAN inter-frequencies and inter-RAT frequencies which are indicated in system information and for which the UE has priority provided as previously defined: For an E-UTRAN inter-frequency or inter-RAT frequency with a reselection priority higher than the reselection priority of the current E-UTRA frequency the UE shall perform measurements of higher priority E-UTRAN inter-frequency or inter-RAT frequencies according to TS 36.133

[10] . For an E-UTRAN inter-frequency with an equal or lower reselection priority than the reselection priority of the current E-UTRA frequency and for inter-RAT frequency with lower reselection priority than the reselection priority of the current E-UTRAN frequency: If the measurements are performed using RSS as specified in

[10] and the serving cell fulfils Srxlev >SnonlntraSearchP: If distanceThresh and referenceLocation are broadcast in SystemInformationBlockType31, and if the UE supports location-based measurement initiation and has obtained its location: If referenceLocation is set to fixedCell, the referenceLocation is used as serving cell reference location. If referenceLocation is set to movingCell, the UE derives the serving cell reference location based on ephemeris, epochTime, referenceLocation and the UE location. If the distance between the UE and serving cell reference location is shorter than distanceThresh the UE may choose not to perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority unless the UE is triggered to measure an E-UTRAN inter-frequency which is configured with redistributionlnterFreqlnfo. Else, the UE shall perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority according to TS 36.133

[10] , Else, the UE may choose not to perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority unless the UE is triggered to measure an E-UTRAN inter-frequency which is configured with redistributionlnterFreqlnfo. Else if the serving cell fulfils Srxlev >SnonlntraSearchP and Squal >SnonlntraSearohQ: If distanceThresh and referenceLocation are broadcast in SystemInformationBlockType31, and if the UE supports location-based measurement initiation and has obtained its location: If referenceLocation is set to fixedCell, the referenceLocation is used as serving cell reference location. If referenceLocation is set to movingCell, the UE derives the serving cell reference location based on ephemeris, epochTime, referenceLocation and its current location. If the distance between the UE and serving cell reference location is shorter than distanceThresh, the UE may choose not to perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority unless the UE is triggered to measure an E-UTRAN inter-frequency which is configured with redistributionlnterFreqlnfo. Else, the UE shall perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority according to TS 36.133

[10] , If t-ServiceStartNeighNTN is broadcast in SystemInformationBlockType33 and if the time has not yet passed t-ServiceStartNeighNTN, the UE may choose not to perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority, where the frequencies have an associated satelliteld configured, unless UE is triggered to measure an E-UTRAN inter-frequency which is configured with redistributioninfo. Else the UE shall perform measurement of E-UTRAN inter-frequencies and inter-RAT frequency cells of equal or lower priority according to TS 36.133

[10] , Else, the UE may choose not to perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority unless the UE is triggered to measure an E-UTRAN inter-frequency which is configured with redistributionlnterFreqlnfo. Otherwise, the UE shall perform measurements of E-UTRAN inter-frequencies or inter-RAT frequency cells of equal or lower priority according to TS 36.133

[10] , If the UE supports relaxed monitoring and s-SearchDeltaP is present in SystemInformationBlockType3, the UE may further limit the needed measurements, as specified in clause 5.2.4.12. If t-Service is present in SystemInformationBlockType3 of the serving cell, UE shall perform intra-frequency, inter-frequency or inter-RAT measurements, before the time t-Service regardless whether the serving cell fulfils Srxlev> SintraSearohP and Squal >SintraSearohQ, or Srxlev >SnonintraSearchP and Squal >SnonintraSearohQ. The exact time to start measurements before t-Service is up to UE implementation and t-ServiceStartNeigh if present in SystemInformationBlockType33 may be used to decide on when to start measurements. UE shall perform measurements of higher priority inter-frequencies or inter-RAT frequencies regardless of the remaining service time of the serving cell. SvstemInformationBlockTvpe33 The IE SystemInformationBlockType33 contains satellite assistance information for neighbour cells. SystemInformationBlockType33 information element - ASN1 START SystemInformationBlockTypeXX-rl8 ::= SEQUENCE { neighSatellitelnfoList-r 18 neigh V alidityDuration-r 18 s60,sl20,s!80, s240, s900} lateNonCriticalExtension NeighSatelliteInfoList-rl8 OPTIONAL, —Need OR ENUMERATED {s5, slO, s!5, s20, s25, s30, s35, s40, s45, s50, s55, OPTIONAL, - Need OP OCTET STRING OPTIONAL, ..., [[ t-ServiceStartNeighNTN-r!9 T imeOffsetUT C-r 17 OPTIONAL, -Need OR ]] } NeighSatelliteInfoList-rl8 ::= SEQUENCE (SIZE(l..maxSat-rl8)) OF NeighSatelliteInfo-rl8 NeighSatelliteInfo-rl8 ::= SEQUENCE { satelliteld-rl8 ephemerislnfo-r 18 state Vectors orbitalP ar ameters }, nta-CommonParameters-18 Satelliteld-rl8, CHOICE { Ephemeris State Vectors -r 17. EphemerisOrbitalParameters-rl 7 SEQUENCE { nta-Common-r!8 INTEGER (0..8316827) OPTIONAL, -Need OP nta-CommonDrift-rl8 INTEGER (-261935..261935) OPTIONAL, -Need OP nta-CommonDriftVariation-rl8 INTEGER (0..29479) OPTIONAL -Need OP SEQUENCE { epochTime-rl8 startSFN-r!8 INTEGER (0..1023), startSubFrame-rl8 INTEGER (0..9) } OPTIONAL, - Need OP k-Mac-r!8 INTEGER (1..512) OPTIONAL, -Need OP t-ServiceStartNeigh-rl8 TimeOffsetUTC-rl7 OPTIONAL, —Need OR... } - ASN1STOP Example implementations #2 In this example, and based on 36.331 VI8.0.0, it is envisaged that the following approach for applying RRCConnectionRelease may be adopted. Here, the RRCConnectionRelease message is used to command the release of an RRC connection, or to complete an UP-EDT procedure, including: Signalling radio bearer: SRB1; RLC-SAP: AM; Logical channel: DCCH; Direction: E-UTRAN to UE. RRCConnectionRelease message - ASN1 START RRCConnectionRelease ::= SEQUENCE{ rrc-Transactionldentifier RRC-Transactionldentifier, criticalExtensions CHOICE { cl CHOICE { rrcConnectionRelease-r8 RRCConnectionRelease-r8-IEs, spare3 NULL, spare2 NULL, spare 1 NULL }, criticalExtensionsFuture SEQUENCE {} } } RRCConnectionRelease-r8-IEs ::= SEQUENCE{ releaseCause ReleaseCause, redirectedCarrierlnfo RedirectedCarrierlnfo OPTIONAL, — Need ON idleModeMobilityControlInfo nonCriticalExtension IdleModeMobilityControlInfo OPTIONAL, — Need OP RRCConnectionRelease-v890-IEs OPTIONAL . . . OMITTED . . . RedirectedCarrierlnfo ::= eutra geran utra-FDD utra-TDD cdma2000-HRPD cdma2000-lxRTT utra-TDD-rlO nr-rl 5 nr-r!7 nr-NTN-r!9 } . . . OMITTED . . . CarrierlnfoNR-r 15 carrierFreq-r!5 CHOICE { ARFCN-ValueEUTRA. CarrierFreqsGERAN, ARFCN-ValueUTRA, ARFCN-ValueUTRA, CarrierFreqCDMA2000, CarrierFreqCDMA2000, ..., CarrierFreqListUTRA-TDD-rl 0, Carri erlnfoNR-r 15, Carri erlnfoNR-r 17. Carri erlnfoNR-NTN -r 19 ::= SEQUENCE { ARFCN-ValueNR-rl5, subcarrierSpacingSSB-rl5 ENUMERATED {kHz!5, kHz30, kHz!20, kHz240}, smtc-rl5 MTC-SSB-NR-rl5 OPTIONAL -Need OP } CarrierInfoNR-rl7 ::= SEQUENCE { carrierFreq-r 17 ARF CN -V alueNR-r 15, subcarrierSpacingSSB-rl7 ENUMERATED {kHz!5, kHz30, kHz!20, kHz240, kHz480, spare 1}, smtc-rl7 MTC-SSB-NR-rl5 OPTIONAL -Need OP } CarrierInfoNR-NTN-rl9 ::= SEQUENCE { carrierFreq-rl9 ARFCN-ValueNR-rl5, subcarrierSpacingSSB-rl9 ENUMERATED {kHz!5, kHz30, kHz!20, kHz240, kHz480, spare 1}, smtc-rl9 MTC-SSB-NR-rl5 OPTIONAL -Need OP ntn-AssistanceInfo-rl9 CHOICE { satelliteld-List SEQUENCE (SIZE(l..maxSat-rl8)) OF Satelliteld-rl8, satelliteFullList SEQUENCE (SIZE(l..maxSat-rl8)) OF NeighSatelliteInfo-rl8 } } - ASN1ST0P 5 A further example to indicate to the UE 870 that the UE of the RRCConnectionRelease field descriptions, as shown in Table 4. Table 4: RRCConnectionRelease field descriptions i altFreqPriorities i Indicates that the UE shall apply the alternative cell reselectionpriorities, when available. This field is not configured i together with idleModeMobilityControlInfo. i carrierFreq or bandClass ; The carrier frequency (UTRA, E-UTRA, and NR) and band class (HRPD and 1xRTT) for which the associated i cellReselectionPriority is applied. For NR, the ARFCN-ValueNR corresponds to a GSCN value as specified in TS i 38.101

[85] , i carrierFreqs i The list of GERAN carrier frequencies organised into one group of GERAN carrier frequencies. i celllnfoList i Used to provide system information of one or more cells on the redirected inter-RAT carrier frequency. The system i information can be used if, upon redirection, the UE selects an inter-RAT cell indicated by the physCellld and i carrierFreq (GERAN and UTRA TDD) or by the physCellld (other RATs). The choice shall match the i redirectedCarrierlnfo. In particular, E-UTRAN only applies value utra-TDD-r10 in case redirectedCarrierlnfo is set to i utra-TDD-r10. i cel I Li s t i Indicates a list of cells configured as RAN area. For each element, in the absence of plmn-ldentity the UE considers i the registered PLMN. Total number of cells across all PLMNs does not exceed 32. i cn-Type i The cn-Type is used to indicate that the UE is redirected from 5GC to EPC or 5GC when redirectedCarrierlnfo i indicates E-UTRA frequency. i drb-ContinueROHC ; This field indicates whether to continue or reset the header compression protocol context for the DRBs configured with i the header compression protocol. Presence of the field indicates that the header compression protocol context i continues when UE initiates UP-EDT in the same cell, while absence indicates that the header compression protocol i context is reset. I dummy i This field is not used in the specification. If received it shall be ignored by the UE. i extendedWaitTime i Value in seconds for the wait time for Delay Tolerant access requests. RRCConnectionRelease field descriptions aitFreqPriorities Indicates that the UE shall apply the alternative cell reselectionpriorities, when available. This field is not configured together with idleModeMobilityControlInfo. freq Priori tyListX Provides a cell reselection priority for each frequency, by means of separate lists for each RAT (including E-UTRA). The UE shall be able to store at least 3 occurrences of FreqsPriorityGERAN. If E-UTRAN includes freqPriorityListEUTRA-v9eO and / or freqPriorityListEUTRA-v1310 it includes the same number of entries, and listed in the same order, as in freqPriorityListEUTRA (i.e. without suffix). Field freqPriorityListExt includes additional neighbouring inter-frequencies, i.e. extending the size of the inter-frequency carrier list using the general principles specified in 5.1.2. EUTRAN only includes freqPriorityListExtEUTRA if freqPriorityListEUTRA (i.e., without suffix) includes maxFreq entries. If E-UTRAN includes freqPriorityListExtEUTRA-v1310 it includes the same number of entries, and listed in the same order, as in freqPriorityListExtEUTRA-r12. idleModeMobilityControlInfo Provides dedicated cell reselection priorities. Used for cell reselection as specified in TS 36.304 [4], For E-UTRA and UTRA frequencies, a UE that supports multi-band cells for the concerned RAT considers the dedicated priorities to be common for all overlapping bands (i.e. regardless of the ARFCN that is used). measIdleConfig Indicates a one-shot measurement configuration to be stored and used by the UE while in RRC_IDLE or RRC_INACTIVE. mpsPrioritylndication Indicates the UE can set the establishment cause to highPriorityAccess for a new connection following a redirect to E-UTRA or set the resume cause to highPriorityAccess for a resume following a redirect to E-UTRA. If the target RAT is NR, see TS 38.331

[82] , The eNB / ng-eNB sets the indication only for UEs authorized to receive MPS treatment as indicated by ARP and / or QoS characteristics at the eNB / ng-eNB, and it is applicable only for this instance of release with redirection to carrier / RAT included in the redirectedCarrierlnfo field in the RRCConnectionRelease message. noLastCel IU pdate Presence of the field indicates that the last used cell for (G)WUS shall not be updated. periodic-RNAU-timer Refers to the timer that triggers the periodic RNAU procedure in UE. Value min5 corresponds to 5 minutes, value min10 corresponds to 10 minutes and so on. ran-Area Indicates whether TA code(s) or RAN area code(s) are used for the RAN notification area. The network uses only TA code(s) or RAN area code(s) to configure a UE. Total number of TACs across all PLMNs does not exceed 16. Total number of RAN-AreaCode across all PLMNs does not exceed 32. ran-Notifi cation Areainfo Network ensures that the UE in RRC_INACTIVE always has a valid ran-NotificationArealnfo. ran AreaConfig List Indicates a list of RAN area codes or RA code(s) as RAN area. For each element, in the absence of plmn-ldentity the UE considers the registered PLMN. ran-pagingCycle Refers to the UE specific cycle for RAN-initiated paging. Value rf32 corresponds to 32 radio frames, rf64 corresponds to 64 radio frames and so on. RRCConnectionRelease field descriptions i aitFreqPriorities i Indicates that the UE shall apply the alternative cell reselectionpriorities, when available. This field is not configured ; together with idleModeMobilityControlInfo. i redirectedCarrierlnfo i The redirectedCarrierlnfo indicates a carrier frequency (downlink for FDD) and is used to redirect the UE to an ; E-UTRA or an inter-RAT carrier frequency, by means of the cell selection upon leaving RRC_CONNECTED as i specified in TS 36.304 [4], The value geran can only be included after successful security activation when UE is i connected to 5GC. i releasecause i The releaseCause is used to indicate the reason for releasing the RRC Connection. The cause value cs- i FallbackHighPriority is only applicable when redirectedCarrierlnfo is present with the value set to utra-FDD, utra-TDD i or utra-TDD-r10. E-UTRAN should not set the releaseCause to loadBalancingTAURequired or to cs- ; FallbackHighPriority if the extendedWaitTime is present. The network should not set the releaseCause to i loadBalancingTAURequired if the UE is connected to 5GC. The network does not set the releaseCause to rrc- i Suspend if the UE is configured with a DAPS bearer, i.e. if source PCell resources after a DAPS handover have not i been released. I releaseldleMeasConfig i Indicates that the UE shall release the idle / inactive measurement configurations, if configured. i rrc-lnactiveConfig i Indicates configuration for the RRC_INACTIVE state. The network does not configure this field when the UE is i redirected to an inter-RAT carrier frequency or if the UE is configured with a DAPS bearer. i smtc i The SSB periodicity / offset / duration configuration of the redirected target NR frequency. It is based on the timing i reference of EUTRAN PCell. If the field is absent, the UE uses the SMTC configured in the measObjectNR having the i same SSB frequency and subcarrier spacing i subcarrierSpacingSSB i Indicate subcarrier spacing of SSB of redirected target NR frequency. Only the values 15 kHz or 30 kHz (FR1), 120 ! kHz or 240 kHz (FR2-1), 120kHz or 480kHz (FR2-2) are applicable. i systeminformation i Container for system information of the GERAN cell i.e. one or more System Information (SI) messages as defined in i TS 44.018

[45] , table 9.1.1. i t320.......................................................................................................................................................................................................................................i i Timer T320 as described in clause 7.3. Value minN corresponds to N minutes. [1323 [ i Timer T323 as described in clause 7.3. Value minN corresponds to N minutes. i utra-BCCH-Container i Contains System Information Container message as defined in TS 25.331

[19] , i waitTime ; Wait time value in seconds. Table 5: Conditional presence Explanation 5GC The field is optionally present, Need ON, if the UE is connected to 5GC; otherwise the field is not present. BLCE-IDLEeDRX The field is optionally present, Need OR, if the UE is a BL UE or UE in CE and the UE is connected to 5GC and IDLE mode eDRX is configured and ran-PagingCycle-r15 is absent; otherwise the field is not present. EARFCN-max The field is mandatory present if the corresponding carrierFreq (i.e. without suffix) is set to maxEARFCN. Otherwise the field is not present. EarlySec When the UE is connected to 5GC, the field is mandatory present. When the UE is connected to EPC, the field is optionally present, Need ON, if the UE supports UP-EDT or UP transmission using PUR or early security reactivation and releaseCause is set to rrc-Suspend; otherwise the field is not present. IdlelnfoEUTRA The field is optionally present, Need OP, if the IdleModeMobilityControlInfo (i.e. without suffix) is included and includes freqPriorityListEUTRA; otherwise the field is not present. INACTIVE The field is mandatory present in this release. NoRedirect-r8 The field is optionally present, Need OP, if the redirectedCarrierlnfo (i.e. without suffix) is not included; otherwise the field is not present. Redirection The field is optionally present, Need ON, if the redirectedCarrierlnfo is included and set to geran, utra-FDD, utra-TDD or utra-TDD-r10; otherwise the field is not present. Redirection2 The field is optionally present, Need OR, if redirectedCarrierlnfo is included; otherwise the field is not present. UP-EDTorPUR The field is optionally present, Need ON, if the UE supports UP-EDT or UP transmission using PUR and releaseCause is set to rrc-Suspend; otherwise the field is not present. In particular, it is envisaged that the aforementioned inventive concept can be applied by a semiconductor manufacturer to any integrated circuit comprising a signal processor configured to perform any of the aforementioned operations. Furthermore, the inventive concept can be 5 applied to any circuit that is able to configure, process, encode and / or decode signals for wireless distribution. It is further envisaged that, for example, a semiconductor manufacturer may employ the inventive concept in a design of a stand-alone device, such as a digital signal processor, or application-specific integrated circuit (ASIC) and / or any other sub-system element. It will be appreciated that, for clarity purposes, the above description has described example 10 embodiments with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units or processors, for example with respect to the signal processor may be used without detracting from the concepts described herein. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization. Aspects may be implemented in any suitable form including hardware, software, firmware or any combination of these. Example embodiments may optionally be implemented, at least partly, as computer software running on one or more data processors and / or digital signal processors or configurable module components such as FPGA devices. Thus, the elements and components of an embodiment may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. Although the concepts have been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in other examples. In the claims, the term ‘comprising’ does not exclude the presence of other elements or steps. Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and / or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate. Thus, examples have been described that provide improved mobility of communication units from terrestrial base stations or base stations such as NTN airborne gNBs, eNBs, to NTN base stations, such as satellite base stations. In accordance with examples herein described, a number of approaches are provided to enable the network to request or ensure that the UE performs measurements on terrestrial frequencies if indicated to do so, wherein the aforementioned disadvantages with prior art arrangements have been substantially alleviated. Abbreviations / Definitions In the present disclosure, the following acronyms / definitions are used. 3 GPP 6G 5G 3rd Generation Partnership Project 6th Generation 5th Generation 5GC 5G Core 5GS ACK AM AMF AS 5G System Acknowledge Acknowledged Mode Access and Mobility management Function Access Stratum BL CA CCCH CDMA CE CIoT CN C-RNH CS DC DCCH DRB EDGE EDT eMTC EN eNB EPC EPS E-UTRA E-UTRAN GEO GERAN gNB GSM HAPS HARQ ID IE loT LEO Bandwidth-reduced Low-complexity Carrier Aggregation Common Control Channel Code Division Multiple Access Coverage Enhancement Cellular loT Core Network Cell RNTI Circuit Switched Dual Connectivity Dedicated Control Channel Data Radio Bearer Enhanced Data rates for Global Evolution Early Data Transmission enhanced Machine Type Communication E-UTRAN NR Base Station Evolved Packet Core Evolved Packet System Evolved Universal Terrestrial Radio Access Evolved Universal Terrestrial Radio Access Network Geosynchronous Equatorial Orbit GSM EDGE Radio Access Network 5G Base Station Groupe Special Mobile High Altitude Platform Station Hybrid Automatic Repeat Request Identity / Identifi cation Information Element Internet of Things Lower Earth Orbit LTE LTE-M MAC MCG MEO MME NAS NB BS NG NR NTN PCell PDCP PDU PSCell RAN RAT RB RLC RLF RNTI ROHC RRC SI SAP SCG SIB SRB S-TMSI TAU TM TMSI TN TS Txxx UE UP X2 / Xn Long Term Evolution LTE Machine Type Communication Medium Access Control Master Cell Group Medium Earth Orbit Mobility Management Entity Non Access Stratum Narrow Band Base Station Next Generation New Radio Non-Terrestrial Network Primary Cell Packet Data Convergence Protocol Protocol Data Unit Primary and Secondary Cells Radio Access Network Radio Access Technology Radio Bearer Radio Link Control Radio Link Failure Radio Network Temporary Identifier Robust Header Compression Radio Resource Control Interface between RAN and CN Service Access Point Secondary Cell Group System Information Block Signalling Radio Bearer Short TMSI Tracking Area Update Transparent Mode Temporary Mobile Subscriber Identity Terrestrial Network Technical Specification Timer xxx User Equipment User Plane Interface between RAN nodes.

Images