Methods and apparatus for closed-loop time correction in Internet of Things (IoT) non-terrestrial networks (NTNs)

Abstract

A method to manage Global Navigation Satellite System (GNSS) position information at a user equipment (UE), 100, in a non-terrestrial network (NTN) which comprises the UE and a network node (e.g. eNB)

Description

Field

[0001] Certain examples of the present disclosure relate to methods, apparatus and / or systems for performing closed-loop time correction in internet of things (loT) nonterrestrial networks (NTNs). In particular, certain examples relate to methods, apparatus and / or systems for managing global navigation satellite systems (GNSS) position validity and invalidity durations for loT devices operating in NTNs. Description of Related Art

[0002] The content of the following documents is referred to below and / or their content provides background information that the following disclosure should be considered in the context of: [1] 3GPP TS 38.331 v17.6.0 [2] 3GPP TS 36.331 v17.6.0 [3] 3GPP TS 36.321 v17.6.0 [4] RP-202689 - New Study WID on NB-loT / eTMC support for NTN (December 2020). [5] R P-211557 - Solutions for NR to support non-terrestrial networks (NTN) (March 2021). [6] RP-220953 - NR NTN (Non-Terrestrial Networks) enhancements (March 2022). [7] RP-223519 - Revised WID on loT NTN enhancements (December 2022). Note: the indicated version numbers are provided for illustrative purposes, other (including future) versions of these documents are considered also.

[0003] Wireless or mobile (cellular) communications networks in which a mobile terminal (e.g., user equipment (UE), such as a mobile handset) communicates via a radio link with a network of base stations, or other wireless access points or nodes, have undergone rapid development through a number of generations. The 3rd Generation Partnership Project (3GPP) design, specify and standardise technologies for mobile wireless communication networks. Fourth (4th) Generation (4G) and Fifth Generation (5G) systems (5GS) are now widely deployed, while beyond 5G (B5G) and 6G systems are being considered.

[0004] 3GPP standards for 4G systems include an Evolved Packet Core (EPC) and an Enhanced-UTRAN (E-UTRAN: an Enhanced Universal Terrestrial Radio Access Network). The E-UTRAN uses Long Term Evolution (LTE) radio technology. LTE is commonly used to refer to the whole system including both the EPC and the E-UTRAN, and LTE is used in this sense in the remainder of this document. LTE should also be taken to include LTE enhancements such as LTE Advanced and LTE Pro, which offer enhanced data rates compared to LTE.

[0005] In 5G systems a new air interface has been developed, which may be referred to as 5G New Radio (5G NR) or simply NR. NR is designed to support the wide variety of services and use case scenarios envisaged for 5G networks, though builds upon established LTE technologies. B5G systems, such as 6G, are currently being considered and developed, and are expected to at least partly build on 5G systems.

[0006] New frameworks and architectures are being developed as part of 5G network (and beyond, such as 6G networks) in order to increase the range of functionality and use cases available through 5G networks.

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

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

[0009] Internet of Things (loT) NTN was a 3GPP study and work item in 3GPP Release 17 to provide Non-Terrestrial Network access for E-UTRAN loT devices (Narrowband (NB)-loT and Long Term Evolution Machine Type Communication (LTE-M), including enhanced Machine Type Communication (eMTC)) [4], New Radio (NR) NTN was a work item in Rel-17 to specify adaptation to allow NR to function over NTN [5]. 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).

[0010] Figure 1 is a representation of an NTN, whereby a UE 10 (e.g. an loT device) in a NTN cell 20 associated with NTN entity 25 (which may be a (LEO, MEO or GEO) satellite or HAPS controlling cell 20) has an access link with the NTN entity 25. The NTN entity 25 has a feeder link with gateway 30, through which base station 40 (e.g., eNB or gNB) and CN 50 are accessed or available.

[0011] Following the Work items in Release 17 there were work items to enhance NR NTN [RP-220953, RAN#95-e March 2022] [6] and loT NTN [RP-223519, RAN#98-e December 2022] [7] in Release 18.

[0012] The work item description for loT NTN Rel-18 is the following (referring to RP-223519 [7]): 4.1.1 loT-NTN Performance Enhancements in Rel-18 to address remaining issues from Rel-17 This work considers Rel-17 loT-NTN as baseline as well as Rel-17 NR-NTN outcome and the further loT-NTN performance enhancements objectives are listed below: Disabling of HARQ feedback to mitigate impact of HARQ stalling on UE data rates [RAN1,RAN2] Study and specify needed improved GNSS operations for a new position fix for UE pre-compensation during long connection times and for reduced power consumption. Simultaneous GNSS and NTN NB-loT / eMTC operation is not assumed. [RAN1, RAN2] • NOTE: The need for RAN4 Core requirements for this objective will be identified after the conclusion on the need for improvements. 4.1.2 Mobility enhancements The following mobility enhancements objectives are listed. Support of neighbour cell measurements and corresponding measurement triggering before RLF, using Rei 17 (TN) NB-loT, eMTC as a baseline. [RAN2] Support signalling in system information of neighbour cell ephemeris, for eMTC and NB-loT[RAN2] Re-use the solutions introduced in Rel-17 NR NTN for mobility enhancements for eMTC, with minimum necessary changes to adapt them to eMTC [RAN2] Define UE RRM core requirements for the above mobility enhancement features [RAN4], 4.1.3 Further enhancement to discontinuous co verage Study and specify, if needed, mobility management enhancements and power saving enhancements for discontinuous coverage, taking into account the conclusions from the SA2 study FS_5GSAT_Ph2. [RAN2, RAN3]. Overview of NB-loT and LTE-M

[0013] Narrowband (NB)-loT is a 3GPP-defined network based on 4G E-UTRAN that supports ultra-low complexity devices with very narrow bandwidth that was introduced in 3GPP Release 13. The use case of NB-loT is to serve massive loT application, where requirements for instance are to support enhanced coverage, power-efficient operation and a massive number of devices. Some of the features introduced are: Support for enhanced coverage through low bandwidth and extreme amounts of repetitions. - Power efficient operation by allowing the UE to sleep for very long times, relaxed requirements and more efficient signal to establish with a cell.

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

[0015] 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 blocks (SIB) was needed.

[0016] In NR NTN SIB19 contains the required information to access an NTN cell (referring to TS 38.331 [1], TS 36.331 [2]): ------------------------------38.331 V17.6.0---------------------------- SIB19 SIB19 contains satellite assistance information for NTN access. SIB19 information element SIB19-rl7 : := 388;:ANOE { ntn-Config-r17 t-Service-rl7 referenceLocation-rl7 distanceThresh-rl7 ntn-NeighCelIConfigList-r17 lateNonCriticalExtension [ [ ntn-NeighCellConfigListExt-vl720 J J NTM-Conf ig-r!7 OBTAIN AL, iNA-ARr (0.. 54 9755013887 ) OOTAAAA, R e f e renceLoc ati on-r17 O 8 T1ONA1, ATodR ( 0 . . 65525 ) 09110070,, NTN-NeighCelIConfigList-r17 0211opal, NTN-NeighCelIConfigList-r 17 O8T1ON; NTN-NeighCellConfigList-rl7 :: NeighCellConfig-rl7 NTN-NeighCelIConfig-rl7 ::= ntn-Config-rl7 carrierFreq-r!7 physCellId-rl7 AMA (3128(1..maxCellNTN-rl7A 08 NTN ANOL { NTN-Config-rl7 ARFCN-ValueNR PhysCellld SIB19 field descriptions distanceThresh Distance from the serving cell reference location and is used in location-based measurement initiation in RRC_ IDLE and RRC INACTIVE, as defined in TS 38.304

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

[20] ,_______________________ t-Service Indicates the time information on when a cell provided via NTN quasi-Earth fixed system is going to stop serving the area it is currently covering. The field indicates a time in multiples of 10 ms after 00:00:00 on Gregorian calendar date 1 January, 1900 (midnight between Sunday, December 31, 1899 and Monday, January 1, 1900). The exact stop time is between the time indicated by the value of this field minus 1 and the time indicated by the value of this field. --------------------------38.331 V17.6.0------- In loT NTN SIB31 contains the required information to access an loT NTN cell: 36.331 V17.6.0 - SystemlnformationBlockType31 The IE SystemInformationBlockType31 contains satellite assistance information for the serving cell. SystemInformationBlockType31 is only signalled in a NTN cell. SystemlnformationBlockType31 information element -- ASN1START SystemlntormationBlockT yp e 31 - r 1i servingSatelliteInfo-rl7 lateNonCriticalExtension ::= SEQUENCE { ServingSatelliteInfo-rl7, OCTET STRING OPTIONAL, INTEGER INTEGER (-26193 INTEGER OPTIONAL, OPTIONAL, OPTIONAL — Need OP — Need OP — Need OP IMERATED {s5 s45, s50, s55, s60 s25, s30, s35, s40, sl20, sl80, s240, s900}, epochTirne-rl7 SEQUENCE { startSFN-rli INTEGER 3tartSubFrame-rli INTEGER (0..1023), (0..9) k-Ma c-rl7 INTEGER (0..1023), INTEGER (1..512) OPTIONAL, OPTIONAL, — Need OP -- Need OP — ASN1STOP SystemlnformationBlockType31 field descriptions epochtime ] Epoch time of the satellite ephemeris data and common TA parameters, see TS 36.213

[23] , The reference point for I epoch time of the serving satellite ephemeris and Common TA parameters is the uplink time synchronization [ reference point. I 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 i epochTime is received. i If the field is absent, the UE uses the starting time of the DL subframe corresponding to the end of the SI window i during which the SI message carrying SIB31(-NB) is transmitted. [ E-UTRAN always includes epochTime when SIB31(-NB) is provided through dedicated signalling. I In case of handover or conditional handover, this field is based on the timing of the target cell, i.e. the startSFN and i startSubFrame number indicated in this field refers to the SFN and sub-frame of the target cell, and UE considers the I 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 I ms. [ If the field if absent, the UE uses the (default) value of 0.______________________________________________________________________i k-Offset Scheduling offset used in the timing relationships in NTN, see TS 36.213

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

[23] , Unit of ps. i Step of 32.55208 xio 3ps. Actual value = field value * 32.55208 xw3 i Jllhe.fiejdjsi nta-CommonDrift Drift rate ofthe 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 xio3. I If the field is absent, the UE uses the (default) value of 0._________________________________________________________________I nta-CommonbriftVariation I Drift rate variation of the common TA, see TS 36.213

[23] . Unit of ps / s2. I Step of 0.2 xw4ps / s2. Actual value = field value * 0.2 x10'4. [ If the field is absent, the UE uses the (default) value of 0. i orbitalParameters [ Instantaneous values ofthe satellite orbital parameters. The signalled values are only valid for the duration as defined i stateVectors Instantaneous values of the satellite state vectors. The signalled values are only valid for the duration as defined by [ ul-SyncV^idityDuration and epochTime.____________________________________________________________________________________________________________________________________________________________________I ul-SyncValidityDu ration ] Validity duration ofthe 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 [ 36.213

[23] , Unit in second. ] Value s5 corresponds to 5 seconds, value s 10 corresponds to 10 seconds and so on. I ----------------------------36.331 V17.6.0-------------------------- 5 The system information contains the following: Serving cell Ephemeris elements - which allows UE to calculate the satellite position for doppler and time pre-compensation. This can be of two formats: o PVT format - which describes a (X,Y,Z) position as well as a speed vector (vX, vY, vZ) 10 o Orbital parameters - this describes the orbital movements of the satellite which is then used to infer the satellite position - TA common parameters - this provides the common timing advance parameters which is introduced to compensate for the feeder link delays. The signaling consists of (in total taking up 57 bits) o Absolute TA common, taking up 23 bits o Drift of the TA common - how the TA common drifts, i.e the first derivative, taking up 19 bits o Variation of the TA common - how the TA common varies, i.e the second derivative of the TA common, taking up 15 bits Synchronization validity duration - used to define how long the ephemeris and TA common is valid - Epoch time - when the synchronization validity duration should start - K-Offset - scheduling offset for timing relationship in NTN K-Mac - Scheduling offset used when the downlink and uplink frame timing is not aligned NR NTN specific information also include (as part of 38.331): o T-Service (signaled in SIB3 in loT NTN) o Reference location and distance threshold - used for location-based measurement initiation in RRC IDLE and RRC Connected mode o Neighbour cell ephemeris ■ This is used for idle mode measurements Overview of Acquisition of NTN System Information

[0017] As the ephemeris constantly changes due to the movement of the NTN payload, there is a need to make sure that the UE is correctly synchronized. Thus whenever UE connected to an eNB, the UE needs to read the system information.

[0018] Furthermore, there is a timer (T317) associated with the ephemeris element that is started every time SIB31 is read. At expiry of T317, the UE is no longer considered synchronized and it will have to re-acquire SIB31 in order to stay synchronized.

[0019] In NR NTN, the UE shall ensure that it has a recent ephemeris (SIB19 in NR) by reading the SIB in time by UE implementation. In loT NTN, since an loT UE (LTE-M and NB-loT UE) is not expected to be able to acquire system information in connected mode, the UE tunes away and is likely unreachable while reading SIB31.

[0020] If the loT NTN UE is unable to read the SIB31 within a timer (T318) with a configured duration, the UE performs RLF similar to other cases where Radio Link Failure (RLF) is performed. Overview of Global Navigation Satellite System (GNSS) Measurements in loT NTN

[0021] In NTN, it is not only the UE that moves, but also the network node that provides coverage as part of the gNB (due to the satellite 25 being transparent as seen in Figure 1).

[0022] In a terrestrial network, the eNB adjusts the timing based on Timing Advance Commands, also known as closed loop time correction. In a non-terrestrial network the UE compensates for the timing by self pre-compensating. The UE can do this by knowing the satellite position, the satellite to gNB pre-compensating factor, as well as UEs own position. The UE thus calculates its UE-specific TA. The UE also uses this to perform frequency pre-compensation, as the satellite movement will also produce very large doppler offsets.

[0023] As timing is important in an OFDMA system, both loT NTN and NR NTN are heavily reliant on GNSS. The UE also uses position to determine correct configuration and whether the UE is allowed to operate in the cell or not. However, due to the nature of how GNSS operations are usually is in a separate part of the device and that how GNSS operates is not standardized, it is not specified when a UE shall perform GNSS measurement in current specifications. It is rather specified as a requirement that the UE shall have a recent and precise enough GNSS position. In loT NTN the UE is also required to report its GNSS validity duration in certain RRC messages. Furthermore, if the GNSS position (e.g. GNSS position measurement information of the UE, GNSS position of the UE, GNSS measurement(s) of the UE, UE position coordinates etc.) is deemed to be invalid and the UE is in connected mode, the UE shall move to idle mode. This is to ensure clean use of the spectrum from the network point of view. This operation can be seen in Figure 2, (a) UE is released (i.e. moved to RRC Idle mode) by eNB, (b) UE releases itself [36.331 v17.6.0]:

[0024] This operation can be seen in Figure 2A and Figure 2B (from TS 36.331 [2]) relating to loT NTN GNSS validity operation. In Figure 2A, UE 100 is released (i.e. moved to RRC Idle mode) by eNB 200 - this being network-controlled operation where the network releases the UE to ensure that eNB knows the state of the UE; while in Figure 2B, UE 100 releases itself - this being the UE releasing itself autonomously according to the specification. According to TS 36.331 [2]: 5.3.3.21 UE actions upon indication of out-of-date GNSS position Upon indication that the GNSS position has become out-of-date while in RRC_CONNECTED, the UE shall: 1> perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause ‘other’.

[0025] In Fig. 2A, it is shown that: • In step 1, the UE 100 performs GNSS measurement; • In step 2, the UE 100 establishes communication with eNB 200; • In step 3, the UE 100 transmits GNSS validity duration to the eNB 200; • Following step 3, the UE 100 enters connected mode; • In step 4, the eNB 200 releases the UE 100 due to GNSS validity duration (e.g., GNSS validity duration being low). The UE 100 may move to idle mode.

[0026] Similarly, in Fig. 2B it is shown that: • In step 1, the UE 100 performs GNSS measurement; • In step 2, the UE 100 establishes communication with eNB 200; • In step 3, the UE 100 transmits GNSS validity duration to the eNB 200; • Following step 3, the UE 100 enters connected mode; • In step 4, the UE 100 autonomously leaves connected mode. The UE 100 may move to idle mode.

[0027] In the current 3GPP Rel-18 loT NTN discussions there are two methods for the UE to perform a GNSS measurement in connected mode : - The UE being dynamically triggered by the network to perform a GNSS measurement; o This can for instance be via a MAC CE or an RRC command. - The UE autonomously performing a GNSS measurement; o This can be done in so-called GNSS measurement gaps defined by the network. o This can be triggered by the GNSS position being invalid, or about-to-be invalid, as defined by the already introduced parameter gnss-ValidityDuration.

[0028] In addition to these discussion it is also discussed how a UE can remain in RRC connected mode if the UE does not have a valid GNSS position. It was thus agreed that under certain circumstances, the UE may remain in RRC connected mode temporarily if the GNSS position is out-of-date. During this duration, instead of continuing to self-pre-compensate using GNSS position and satellite position, the network may revert to using closed loop Timing advance commands to adjust the timing. This duration is configured via RRC. In the standards discussions this duration has gone under the name “duration X’, “Uplink transmission extension”, but for the purposes of this invention we use the wording “GNSS invalid duration”. Other suitable names may for instance be “closed loop TA duration". SUMMARY

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

[0030] The present invention is defined in the independent claims. Advantageous features are defined in the dependent claims.

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

[0032] Embodiments / examples of the present disclosure are further described hereinafter with reference to the accompanying drawings, in which: Figure 1 shows a representation of a NTN; Figure 2A shows an example call flow chart of a method including an operation of a UE being released according to network control; Figure 2B shows an example call flow chart of a method including an operation of a UE releasing itself autonomously; Figure 3 shows an example where a GNSS invalid duration is defined and which follows a GNSS position becoming invalid; Figure 4 shows an example of a lack of precision with respect to GNSS position validity duration; Figure 5 shows an example where a UE reports a start of a GNSS invalid duration when GNSS position is out-of-date; Figure 6 shows an example where the GNSS invalid duration is started before the GNSS position is considered invalid; Figure 7a shows an example where the GNSS invalid duration is stopped in response to a certain condition / trigger; Figure 7b shows an example where a GNSS invalid duration is stopped in response to a radio link failure. Figure 8 shows an example where an eNB is not permitted to handover a UE to another cell whilst the GNSS invalid duration is on-going; Figure 9 shows an example of a MAC CE enhanced with indication that the GNSS validity duration is 0 and that the GNSS invalid duration has started; Figure 10 is a block diagram illustrating an example structure of a network entity in accordance with certain examples of the present disclosure; Figures 11 to 21 relate to network energy saving using a repeater node described in the latter section of this disclosure. Figure 11 illustrates an example of a network-controlled repeater (NCR) communication architecture, in which NCR-mobile termination (MT) is the control link to control the NCR-Fwd link at the NCR; Figure 12 illustrates an example of an NCR periodic forwarding configuration; Figure 13 illustrates an example of Cell discontinuous transmission (DTX) along with its configured fields; Figure 14 illustrates an example of Cell discontinuous reception (DRX) along with its configured fields; Figure 15 illustrates an example of Cell DTX configured to NCR-Fwd, where the NCR-Fwd does not forward on the access link during Cell DTX non-active time (in this Figure, “gNB TX OFF” is from the perspective of the NCR-Fwd); Figure 16 illustrates an example of Cell DRX configured to NCR-Fwd, where the NCR-Fwd does not forward on the backhaul link during Cell DRX non-active time (in this Figure, “gNB RX OFF” is from the perspective of the NCR-Fwd); Figure 17 illustrates an example in which Cell DTX and Cell DRX are aligned; Figure 18 illustrates an example of Cell DTX and Cell DRX applied per-NCR beam, in which the Cell DTX configuration is different for different beams while the Cell DRX configuration is the same across the NCR beams; Figure 19 illustrates an example of alignment of Cell DTX between gNB, NCR-Fwd and UE to allow for normal gNB / cell operation; Figure 20 illustrates an example of configuring the Cell DRX to an NCR such that network functions can be maintained; and Figure 21 is a block diagram of an exemplary network entity that may be used in certain examples of the present disclosure. DETAILED DESCRIPTION

[0033] The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of certain examples of the present disclosure. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the invention or disclosure.

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

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

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

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

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

[0039] Throughout the description, the expression “at least one of A, B and / or C” (or the like), the expression “and / or”, and the expression “one or more of A, B and / or C” (or the like) should be seen to separately include all possible combinations, for example: A, B, C, A and B, A and C, A and B and C.

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

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

[0042] The following examples are applicable to, and use terminology associated with, 3GPP 4G and 5G. However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples or to 3GPP 4G or 5G, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards. The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of 3GPP 4G or 5G NR or any other relevant standard. For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function, operation or purpose within the network. In particular, the following disclosure should be considered at least in relation to 6G also, which is expected to use at least part of the 5G architecture, or equivalent, and to which the present disclosure also relates.

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

[0044] The skilled person will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 4G, 5G, B5G or 6G. • One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations. • One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information. • One or more further elements, entities and / or messages may be added to the examples disclosed herein. • One or more non-essential elements, entities and / or messages may be omitted in certain examples. • The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example. • The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example. • Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example. • Information carried by two or more separate messages in one example may be carried by a single message in an alternative example. • The order in which operations are performed may be modified, if possible, in alternative examples. • The transmission of information between network entities is not limited to the specific form, type and / or order of messages described in relation to the examples disclosed herein.

[0045] Certain examples of the present disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method therefor. Such an apparatus / device / network entity may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). Certain examples of the present disclosure may be provided in the form of a system (e.g., a network) comprising one or more such apparatuses / devices / network entities, and / or a method therefor.

[0046] It will be appreciated that examples of the present disclosure may be realized in the form of hardware, software or a combination of hardware and software. Certain examples of the present disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and / or apparatus in accordance with any aspect, example and / or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program.

[0047] All proposals, embodiments, and examples in this invention may also apply for NR NTN or LTE-M / eMTC NTN.

[0048] In this disclosure the wording “performing measurements” may also mean “performing measurements given all other conditions are fulfilled” or “if supported, performing measurements” or “if applicable, performing measurements”, or any other suitable wording. In other words, whether performing measurements may be dependent on other already introduced conditions or independent of already introduced conditions i.e. any other conditions for performing measurements such as those given by prior art may still be considered.

[0049] An issue of performing GNSS measurement in RRC connected mode is that an loT UE may not have the capability to simultaneously perform GNSS measurements and transmit and receive data. These limitations are because of cheaper filters and receivers in an loT device, which contrasts to that of 5G NR devices that are able to perform these actions simultaneously.

[0050] Due to these limitations, there has been work on enabling GNSS measurements in RRC connected mode for loT devices. One proposed solution is where a UE tunes away from cellular communication frequencies to perform the GNSS acquisition.

[0051] Another solution, related to using self pre-compensation in loT NTN, is to use closed-loop TA compensation based on Timing Advance Commands. In relation to this, it was agreed that after the GNSS position are no longer considered valid, the UE can remain in RRC connected mode through the network utilizing Timing Advance commands. The period in which GNSS position is no longer considered valid and the UE can remain in RRC connected mode may be termed a GNSS invalid duration or other appropriate term such as GNSS measurement information invalid duration, GNSS information invalid duration, GNSS position invalid duration, GNSS invalid period, GNSS timing invalid duration etc. or any combination or equivalent thereof. This can be seen in Figure 3, where steps 1,2,3, and 5 corresponds to 1, 2, 3, and 4 respectively of Figure 2B. The approach of Figure 3 may also build upon the method of Figure 2a. The present disclosure focuses on approaches for the management of this GNSS invalid duration.

[0052] In particular, in Figure 3, although the GNSS position is no longer valid, timing is maintained via a timing advance command MAC CE.

[0053] However, it is still open whether the GNSS invalid duration is defined as an extension to the GNSS validity duration, or whether it is a separate duration. If it is a separate duration, there are several open issues: When is the GNSS invalid duration stopped What actions does a UE take when the GNSS invalid duration is started.

[0054] For example, one can consider the GNSS validity duration as introduced in 3GPP Release 17. The GNSS validity duration was designed as a way for the network to get an approximate idea of when the GNSS position of a UE would be invalid, which is important for the network to know as the UE action is to move to RRC idle upon GNSS position being invalid. However, the GNSS validity duration was not designed with precision in mind, with the values being 10 - 60s, 5 mins up to 120 mins including infinity. This is because the GNSS validity duration cannot be exactly known, as the movements of a mobile UE can be highly irregular and cannot be fully predictable, especially over a very long time horizon. If these characteristics are combined with the GNSS invalid duration which has the configurable duration [500, 750, 1280, 1920, 2560, 5120, 10240] subframes, then it becomes clear that there may be a mismatch in terms of precision and that there may need to be supplementary methods to solve some related issues. This issue can be seen in Figure 4, where the arrow 400 shows the uncertainly in when the GNNS position becomes out-of-date (i.e. invalid) compared to the start of the GNSS invalid duration 402. Consequently, issues may occur when the GNSS position is still considered valid when in fact it is invalid or vice versa.

[0055] It has previously been set out that the GNSS invalid duration may be modelled in two ways: Extending the GNSS validity duration Introducing a new timer. Such as timer can be modelled by a timer in RRC (T3XX).

[0056] As has also previously been set out that, upon the expiry of GNSS invalid duration, the UE shall move to RRC idle if the GNSS position is still invalid. Reporting Start of GNSS Invalid Duration

[0057] As mentioned above, there may be issues in the precision of the GNSS invalid duration, and the GNSS validity duration, as the GNSS validity duration is likely very fuzzy (i.e. its end time is not well-defined). One issue is that the GNSS position may become invalid before or after the time indicated (by the UE-reported GNSS validity duration) due to the fuzziness and in this case it may be vital for the UE to indicate to the network when the GNSS position is no longer valid and the GNSS invalid duration has started.

[0058] One approach to indicate the start of the GNSS invalid duration is to indicate this using existing signaling techniques such as GNSS validity duration report MAC CE. This can be done either by using a specific flag indicating that the GNSS invalid duration has started. Similarly, it may also be indicated that the GNSS remaining validity duration is 0 and that the GNSS invalid duration has started. Two examples of this can be seen in specification Examples #1. Figure 5 also provides an example of such an approach.

[0059] As can be seen in Figure 5, at the start of the GNSS invalid duration, the UE 100 sends an indication to the eNB 200 such that the eNB and the network has accurate timing information on the end of the GNSS valid duration and / or the start of the GNSS invalid duration.

[0060] Other ways of indicating the end of the GNSS valid duration and / or the start of the GNSS invalid duration can for instance be through any RRC message, such as an RRC measurement report or any other newly defined RRC message.

[0061] The reporting of the start of the GNSS invalid duration may be configurable by RRC or MAC, for instance through a flag gnss-lnvalidDurationReport. Starting GNSS Invalid Duration

[0062] The GNSS invalid duration should start at the time of GNSS position being out-of-date. However, with the issue of the GNSS position being out-of-date being a relatively fuzzy and imprecise concept, it would be advantageous to have new methods and conditions on starting GNSS invalid duration.

[0063] In accordance with an example of the present disclosure, the UE is allowed to start the GNSS invalid duration before the GNSS position being out-of-date. This start can be configured by the network, or can be up to the UE. It can for instance be configured as an interval of when the UE is allowed to start the duration. For instance it can be defined that the UE is allowed to start the GNSS invalid duration up to Y seconds before the GNSS position is considered invalid according to the previously reported value (the value reported in gnss-ValidityDuration in msg5). This can be seen in Figure 6. The benefit of this approach is that the GNSS validity can be more flexible to real-world scenarios and to potentially rounding the UE-reported gnss-ValidityDuration.

[0064] In another example, if the UE detects issues with the GNSS position, for instance the UE knows that it has moved a certain position, based on measurements other than GNSS, then the GNSS invalid duration may be triggered. In other words, the GNSS invalid duration may start when it detected that the GNSS position has become out-of-date even though the GNSS valid duration has not yet expired. Stopping GNSS Invalid Duration

[0065] If the GNSS invalid duration is modelled as a new timer, either in RRC or in MAC, there should be conditions for stopping the timer to ensure that behaviour of the UE will be predictable.

[0066] One example of a stopping condition is that the UE has successfully completed a GNSS measurement and so has a valid GNSS position. This is needed as otherwise the GNSS invalid duration timer will continue run. This stopping condition may be invoked both when the UE is RRC connected or in RRC idle / inactive. An example of this is seen in Figure 7a.

[0067] In Figure 7a, whilst the GNSS invalid duration is running, the UE 100 successfully performs a GNSS measurement and stops the GNSS invalid duration since the GNSS position is no longer invalid or deemed to be invalid. The GNSS measurement may be triggered by the network (e.g. eNB) as shown in Figure 7a or it may be triggered by the UE itself in response to any appropriate condition, such as a timer expiry or detection of sufficient movement of the UE etc. Furthermore, conditions / triggers for stopping the GNSS invalid duration are set out below. If the GNSS invalid duration is modelled in RRC: The GNSS invalid duration needs to be stopped at several events that are related to moving to RRC idle or changing cells: If the UE is moved to RRC idle mode due to any condition such as being released by RRC Connection Release, Radio Link Failures, suspension of RRC, RRC Release requested by higher layers, Data Inactivity, etc. This is needed, otherwise the timer may continue to run and if the UE connects to another cell, the timer may continue to run and triggering UE to move to RRC idle. Some of these cases are triggered by receiving a message or indication from the eNB, and some of these cases are triggered in response to some condition in the UE. An example of this occurring during RLF can be seen in Figure 7b. Triggering of RRC re-establishment or triggering of a handover. This is important as both RRC re-establishment may result in connecting to a new cell, and in that case the timer needs to be stopped to not cause issues in the new cell. The triggering of the RRC re-establishment is triggered by the UE itself and the handover is triggered by the UE receiving a handover command, or in response to a condition configured in a conditional handover command. If the duration in modelled as a MAC timer: The GNSS invalid duration shall be stopped at MAC reset or at MAC reconfiguration. This is important as MAC reset occurs at many events such as handovers and during other cases.

[0068] In some instances, the GNSS invalid duration should not be stopped or “paused” during the duration when a UE is performing a GNSS measurement. However at the stopping of the GNSS invalid duration, the UE shall not move to RRC idle.

[0069] The GNSS invalid duration timer may also be defined to be associated with a Serving cell, which means that it cannot continue to run in another cell, or when the UE is not in RRC connected.

[0070] If the GNSS invalid duration is modelled by extending the GNSS validity duration, there may need to be some conditions on making the GNSS position no longer to be considered valid. This is normally not needed, but if the GNSS validity duration is considered valid when it is in fact not, there are some conditions needed. Some examples are: GNSS position no longer considered valid if GNSS invalid duration has been configured and UE performs any of the following: Moving to RRC idle due to any conditions RRC Connection Release to RRC idle or RRC suspension Radio Link failure RRC Release requested by higher layers Moving to RRC idle due to any other conditions Triggering of RRC re-establishment or triggering of a handover MAC reset Further GNSS Invalid Duration Considerations

[0071] In another example, whether the GNSS invalid duration was on-going during an RLF is reported in the RLF report. This can for instance be a flag that indicates that the GNSS invalid duration was on-going at the time of the failure. Similarly it may also indicate for how long the GNSS invalid duration had been on-going.

[0072] It may also be advantageous to have further considerations on how the network handles a UE when the UE is in GNSS invalid duration i.e. when the GNSS invalid duration is on-going / running.

[0073] In one example, a network may not be allowed to trigger a handover when the UE is in GNSS invalid duration. This can be a network requirement. This can be advantageous as it may cause network issues if a UE is in GNSS invalid duration and then the UE performs handover to another cell when the UE cannot properly synchronize due to no valid GNSS position. Thus an eNB may only be allowed to release the UE during this state.

[0074] Figure 8 provides an example where the eNB is not permitted to handover the UE to another cell whilst the GNSS invalid duration is on-going.

[0075] In another example relating to the problem whereby the handover is not prohibited, the source cell indicates to the target cell that the UE is under the GNSS invalid duration. The UE being under GNSS invalid duration means that the network has to configure handovers that give more time for the UE to complete the handover. This can be done by configuring a longer handover time, T304 timer.

[0076] Figure 9 provides an example of a MAC CE enhanced with indication that the GNSS validity duration is 0 and that the GNSS invalid duration has started and that may be sent from the UE to an eNB.

[0077] An example amendment to 36.331 [2] is set out below. 5.3.3.21 UE actions upon indication of out-of-date GNSS position Upon indication that the GNSS position lias become out-of-date while in RRCCONNECTED. the UE shall: 1> if the UE does not support performing GNSS fix in GNSS measurement gap: 12> perform the actions upon leaving RRC CONNECTED as specified in 5.3.12, with release cause 'other'; 1> else if no indication of network triggered GNSS measurement is received from lower layers, and gnss-AutonomousEnabled is not configured: 2> perform the actions upon leaving RRC CONNECTED as specified in 5.3.12, with release cause 'other'. 1> if GNSS invalid duration has been configured: 2> start T3YY with the value gnss-InvalidDuration 2> indicate to the MAC entity to report the start of the GNSS invalid duration

[0078] An example in which a MAC CE defined in [3] is utilised as set out above and illustrated in Figure 9 is shown below, where the changes are shown in bold. 6.1.3.yy GNSS Validity Duration Report MAC Control Element The GNSS Validity Duration Report MAC Control Element is identified by a MAC PDU subheader with LCID as specified in table 6.2.1-2. It has a fixed size and consists of a single octet defined as follows (Figure 6.1.3.yy-l): - R: Reserved bit, set to 0; - GNSS Validity Duration: the field corresponds to the remaining GNSS validity duration defined in the TS 36.331 [8], - C: Indicates that the GNSS validity duration is 0 and that the GNSS invalid duration has started.

[0079] Figure 10 is a block diagram of an exemplary apparatus, or network entity, that may be used in examples of the present disclosure. The skilled person will appreciate said entity may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[0080] The entity 1000 comprises a processor (or controller) 1001, a transmitter 1003 and a receiver 1005. The receiver 1005 is configured for receiving one or more messages from one or more other network entities, for example as described above. The transmitter 1003 is configured for transmitting one or more messages to one or more other network entities, for example as described above. The processor 1001 is configured for performing one or more operations, for example according to the operations as described above.

[0081] It will be appreciated that, in each example / embodiment / aspect etc. described above, one or more features or operations may be omitted, modified or moved (e.g., to change the order of the features or the operations), if desired and appropriate. Additionally, one or more features or operations from any example / embodiment may be combined with features or operations from any other example / embodiment. In particular, regardless of whether or not a pointer towards a combination of features / examples is found herein, the present disclosure should be considered to include all combinations of two or more of the embodiments, examples etc. disclosed herein, and all combinations of two or more of the features disclosed herein.

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

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

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

[0085] While the present disclosure has been shown, illustrated and described with 5 reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the disclosure.

[0086] The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application 10 and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. Acronyms and Definitions (as may be used herein) 3GPP 3rd Generation Partnership Project NTN Non-Terrestrial Network 5G 5th Generation NW Network 5GC 5G Core NWDAF Network Data Analytics Function 5QI 5G QoS Identifier OS Operating System 5GS 5G System OSAPP OS Application 5GSM 5G System Session Management PCF Policy Control Function 5GMM 5G System Mobility Management PCC Policy and Charging Control AF Application Function PCO Protocol Configuration Options Al Artificial Intelligence PDR Packet Detection Rule AIML Artificial Intelligence / Machine PDU Protocol Data Unit Learning PMF Performance Measurement Function AM Acknowledged Mode PSA PDU session anchor AMF Access and Mobility Management QFI QoS Flow Identifier (ID) Function QoE Quality of Experience AS Application Server QoS Quality of Service ASP Application Service Provider RACH Random Access Channel ATSSS Access Traffic Steering Switching RAN Radio Access Network & Splitting RAT Radio Access Technology AUSF Authentication Server Function RLC-AM Radio Link Control Acknowledge CDRX Connected Mode Discontinuous Mode Reception RLC-UM Radio Link Control Unacknowledge CE Control Element Mode CSI Channel Status Information RRC Radio Resource Control DCAF Data Collection Application RSD Route Selection Descriptor Function SA Standalone DNN Data Network Name SBA Service-Based Architecture DNS Domain Name Server SBI Service-Based Interface DRB Data Radio Bearer SCEF Service Capability Exposure Function DRX Discontinuous Reception SCP Service-Based Communication Proxy eNB Evolved Node B SCTP Stream Control Transmission EPS Evolved Packet System Protocol FQDN Fully Qualified Domain Name SDAP Service Data Adaptation Protocol GBR Guaranteed Bit Rate SDU Service Data Unit gNB Next generation Node B SIM Subscriber Identity Module GNSS Global Navigation Satellite System SLA Service Level Agreement GPSI Generic Public Subscription SM Session Management Identifier SMF Session Management Function IAB Integrated Access and Backhaul SN Secondary Node ID Identity / ldentifier S-NSSAI Single Network Slice Selection loT Internet of Things Assistance Information IMEI International Mobile Equipment SSB Synchronization Signal Block Identities SSC Session and Service Continuity IP Internet Protocol SUPI Subscription Permanent Identifier l-SMF Intermediate SMF TAI Tracking Area Identity LMF Location Management Function TE Terminal Equipment MA-PDU Multiple Access PDU TM Transparent Mode MAC Medium Access Control TS Technical Specification ML Machine Learning UDM Unified Data Manager MME Mobility Management Entity UDR Unified Data Repository MN Master Node UE User Equipment MNO Mobile Network Operator UL Uplink MPTCP MultiPath TCP UM Unacknowledged Mode MT Mobile Termination UP User Plane NAS Non-Access Stratum UPF User Plane Function NB Narrowband URLLC Ultra-Reliable and Low-Latency NRF Network Repository Function Communication NG-RAN Next Generation Radio Access URSP UE Route Selection Policy Network XRM Extended Reality and Media NG-eNB Next Generation eNB NSA Non-Standalone Further examples related to closed-loop time correction in internet of things (loT) nonterrestrial networks (NTNs) are set out in the following numbered clauses. 1. A method for managing Global Navigation Satellite System (GNSS) position information at a user equipment (UE) in a non-terrestrial network comprising the UE and a network node (e.g. eNB) providing coverage to the UE, the method comprising: starting, at the UE, an invalid duration indicating that GNSS position information of the UE is invalid; and reporting, by the UE to the network node, the start of the invalid duration. 2. The method of clause 1, wherein the invalid duration is started in response to the GNSS position information of the UE becoming out-of-date. 3. The method of clauses 1 or 2, wherein the invalid duration is started in response to movement of the UE exceeding a threshold. 4. The method of any preceding clause, wherein the invalid duration is started in response to there being less than a predetermined period before expiry of a duration during which the GNSS position information at the UE is considered valid (e.g. a GNSS validity duration). 5. The method of any preceding clause, wherein the invalid duration is started in response to expiry of a duration during which the GNSS position information at the UE is considered valid (e.g. a GNSS validity duration). 6. The method of any preceding clause, wherein the invalid duration is stopped in response to one or more of: a successful GNSS measurement at the UE, expiry of the invalid duration, entry of the UE into an radio resource control (RRC) idle mode, a radio link failure at the UE, a release of an RRC connection triggered by the eNB, data transmission inactivity by the UE, RRC reestablishment by the UE, a handover of the UE, a medium access control (MAC) reset at the UE, and a MAC reconfiguration at the UE. 7. The method of any preceding clause, wherein the invalid duration is implemented as an RRC timer or a MAC timer. 8. The method of any preceding clause, wherein the reporting includes transmitting, from the UE to the network node, a MAC control element (CE) indicating a zero value for a duration in which the GNSS position information is considered valid (e.g. GNSS validity duration). 9. The method of any preceding clause, wherein handover of the UE is not permitted if the invalid duration is on-going. 10. The method of any preceding clause, wherein the invalid duration is an extension of a duration during which the GNSS position information at the UE is considered valid 11. The method of any preceding clause, wherein the GNSS position information is used for NTN communications. 12. The method of any preceding clause, wherein the UE is an Internet of Things (loT) device, a Narrowband (NB) loT device, a Long Term Evolution Machine Type Communications (LTE-M) device, or an enhanced Machine Type Communications (eMTC) device. 13. A user equipment (UE) comprising a processor, a receiver, and a transmitter, wherein the processor in combination with the receiver and transmitter is configured to implement the method of any of the preceding clauses. Network Energy Saving using Repeater Node

[0087] Following examples of the present disclosure provide one or more techniques for implementing network energy saving when using a repeater node. For example, certain examples provide one or more techniques for implementing Network Energy Saving (NES) when using a Network Controlled Repeater (NCR) in a 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR) network. Description of Related Art Overview of Network-Controlled Repeater (NCR)

[0088] In order to provide enhanced network coverage, a variety of different types of network nodes have been developed. For example, a Radio Frequency (RF) repeater may be deployed to amplify and forward any signal that it receives to supplement coverage provided by a regular cell. An enhanced type of repeater node, called a Network-Controlled Repeater (NCR), is currently under development and is a Release 18 Study Item / Work Item (3GPP RP-213700).

[0089] Figure 11 illustrates the network architecture of NCR communication. As shown, the NCR comprises NCR-Mobile Termination (MT) and NCR-Forward (Fwd) functions / entities.

[0090] NCR-Fwd receives and forwards data, signals, transmissions and the like between Base Station (gNB) and User Equipment (UE) via a backhaul link between gNB and NCR-Fwd, and an access link between NCR-Fwd and UE. An NCR may perform forwarding without decoding the data, signals, transmissions and the like.

[0091] NCR-MT is the entity that terminates the Control Link with gNB. NCR-MT receives control signals from gNB via a control link, and configures and controls NCR-Fwd based on the control signals, such as general configurations and short-term control link information.

[0092] Once configured, NCR-Fwd provides an amplify-and-forward function that is transparent to the UE. Accordingly, gNB may communicate with UE directly or through the NCR.

[0093] To enable easy deployment of NCR nodes, an NCR is configured to be transparent to a UE whether it is communicating through an NCR or not. For example, when an NCR is deployed, to make the NCR transparent to the UE for a random access procedure, the gNB may allocate a set of Synchronization Signal Block (SSB) indices to the NCR when the NCR registers to the network (while other SSB indices remain with gNB), for example as described in 3GPP R1-2203741, Section 5. The UE may then perform the random access procedure via SSBs transmitted via SSB indices allocated to the NCR as though the random access procedure was performed via the gNB.

[0094] The NCR-MT part of the NCR is expected to function almost like a normal UE, meaning that the NCR configurations are signalled similar to a normal UE. This means that NCR-MT will have a full protocol stack, but it is expected that some functionality that is normally used by a UE may not be applicable and will not be implemented by the NCR-MT and / or configured by the network.

[0095] There are three types of forwarding configurations for an NCR: - Periodic forwarding. o This is configured and activated via Radio Resource Control (RRC). - Aperiodic forwarding. o This is partly configured via RRC, but activated via Downlink Control Information (DCI) (DCI format 2_8). The DCI format 2_8 indicates the time resource as well as the beam index to be used for forwarding, while the beam width is configured via RRC. Semi-Persistent forwarding. o This is partly configured via RRC and activated via Medium Access Control (MAC) Control Element (CE) (using the NCR Access Link Beam Indication MAC CE). o The MAC CE includes the resource set Identity (ID) (used to select one of forwarding semi-persistent resource lists signalled via RRC) and the beam index ID of the spatial resources to be used for forwarding.

[0096] The forwarding operation of NCR have the following characteristics: - Forwarding can be done in RRC connected mode and RRC inactive. When an NCR-MT is in RRC inactive, only the periodic forwarding is applicable as the network cannot control the aperiodic forwarding. If a Beam Failure occurs and a Beam Failure Recovery (BFR) procedure is triggered, the NCR-Fwd will cease to forward and then continue forwarding once the beam failure has been recovered. Overview of Network Energy Saving (NES)

[0097] NES is a Release 18 Work Item (Wl) to introduce methods to allow for energy savings for a network (see 3GPP RP-230566), rather than UEs. This is because a significant amount of Operating Expenditure (OPEX) for operators is spent on energy costs. The work item followed a Study Item where a base station energy consumption model was developed and different methods for energy savings were evaluated. The Study Item resulted in a Technical Report: 3GPP TR 38.864, “Study on network energy savings for NR” (version is V18.1.0, Release 18, March 2023).

[0098] The objective of the work item are: Specify Synchronization Signal Block (SSB)-less Secondary Cell (SCell) operation. o This allows a network to de-activate the SSBs on cells other than the Primary Cell (PCell) in a cell that operates Carrier Aggregation. Specify enhancement on cell Discontinuous Transmission (DTX) I Discontinuous Reception (DRX) mechanism. o DRX is a legacy feature that allows a UE to power down monitoring to save UE power consumption. o Cell DTX / DRX allows a network to power down either transmission or reception operation. This is done by configuring a UE to not monitor or to not transmit in certain opportunities. Specify techniques in spatial and power domain. o Enhancements on Channel State Information (CSI) and beam management-related procedures. o Enhancements on CSI-related procedures to enable efficient adaptation of power offset values between Physical Downlink Shared Channel (PDSCH) and CSI-Reference Signal (RS). - Specify mechanisms to prevent legacy UEs from camping on cells using Release -18 NES. o This is needed because if a UE camps on a cell that regularly shuts down to save power, then an unaware UE will re-select to another cell, potentially causing issues. - Specify Conditional Handover (CHO) procedure enhancements for cells in NES mode. Inter-node beam activation.

[0099] Cell DTX / DRX is introduced to allow for a network to reduce power consumption by partly turning off transmit and receive functionality. The Cell DTX and DRX are dedicatedly configured per UE in RRC CONNECTED, which means that there may be flexibility in how the cell or gNB is turned OFF. For instance, a specific sector can be turned OFF, or the whole cell or gNB may be turned OFF. While Cell DTX and / or Cell DRX is on-going, the cell shall still not affect random access procedure, SSB transmissions, paging and system information broadcasting.

[00100] When Cell DTX is configured and during the so-called DTX non-active duration, the UE will not monitor Physical Downlink Control Channel (PDCCH) or Semi Persistent Scheduling (SPS) occasions. During this time, the UE may still transmit in the uplink, such as transmissions via Configured Grants (Physical Uplink Shared Channel (PUSCH)) and Scheduling Requests (Physical Uplink Control Channel (PUCCH)).

[00101] When Cell DRX is configured, the UE shall not perform transmissions during the so-called DTX non-active duration. This includes transmissions on Configured Grant (CG) and Scheduling Request (SR) resources. This to ensure that nothing is being transmitted by the UE so that a gNB does not have to monitor for any transmissions.

[00102] Both Cell DTX and DRX has an on-duration, which is the active duration, and a cycle that specifies the periodic repetition of the active duration and the non-active duration.

[00103] The Cell DTX and Cell DRX are both configured via RRC, but the activation to start the Cell DTX and Cell DRX cycle are done via DCI via a new DCI format. For the new DCI format, a new Radio Network Temporary Identifier (RNTI), nes-RNTI, is introduced. The DCI to activate or deactivate Cell DTX or Cell DRX will indicate things such as: - Field for activation / deactivation of Cell DTX. Field for activation / deactivation of Cell DRX. Field for which serving cell that the activation / deactivation concerns.

[00104] The Cell DTX and Cell DRX is configured in MAC-CellGroupConfig, which is a part of CellGroupConfig, in turn may be a part of RRCReconfiguration.

[00105] The above information on NCR, NES, and cell DTX / DRX is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present disclosure.

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

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

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

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

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

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

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

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

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

[00115] Certain examples of the following disclosure provide one or more techniques for implementing network energy saving when using a repeater node. For example, certain examples provide one or more following techniques for implementing NES when using an NCR in a 3GPP 5G NR network. However, the skilled person will appreciate that the following disclosure is not limited to these examples, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards, including any existing or future releases of the same standards specification, for example 3GPP 5G, 5G-advanced or 6th Generation (6G).

[00116] The functionality of the various following network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in the same or any other suitable communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function or purpose within the network.

[00117] For example: the functionality of a repeater node or the like (e.g. NCR) in the examples below may be applied to any other suitable type of entity performing a repeater and / or forwarding function; the functionality of a base station or the like (e.g. eNB, gNB, NB, Radio Access Network (RAN) node, access point, wireless point, transmission / reception point, radio unit, etc.) in the examples below may be applied to any other suitable type of entity performing RAN functions; and the functionality of a UE or the like (e.g. electronic device, user device, mobile station, subscriber station, customer premises equipment, terminal, remote terminal, wireless terminal, vehicle terminal, etc.) in the examples below may be applied to any other suitable type of device.

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

[00119] The skilled person will appreciate that the following disclosure is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 5G. • One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations. • One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information. • One or more further elements or entities may be added to the examples disclosed herein. • One or more non-essential elements or entities may be omitted in certain examples. • The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example. • The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example. • Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example. • Information carried by two or more separate messages in one example may be carried by a single message in an alternative example. • The order in which operations are performed and / or the order in which messages are transmitted may be modified, if possible, in alternative examples.

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

[00121] In the Release 18 work item of NCR a simplified NCR was introduced, and at the same time NES is being discussed. As NCR is performing repeating, it is important to consider the energy costs of operating such a network node.

[00122] Cell DTX / DRX is introduced to allow a gNB or a cell to power down momentarily. During these moments of powering down, the gNB or cell will not perform any transmissions or receive any transmissions. This is different from a legacy gNB or cell, which is expected to always be “ON”, either, for instance, transmitting broadcasted synchronization signals, or receiving transmissions from a UE.

[00123] If Cell DTX / DRX is employed in a network where NCRs operate, there may be a range of problems. One of these is that, when a cell is turned OFF, as the NCR is an amplify-and-forward repeater, the NCR may not have any gNB signal to amplify, and thus amplifies noise.

[00124] Certain examples of the following disclosure provide one or more techniques for allowing an NCR to adapt to a network employing NES, for example Release 18 NES operation.

[00125] Certain examples of the following disclosure provide a method, for a repeater node (e.g. an NCR) capable of forwarding transmissions between a base station and a User Equipment (UE), wherein the base station is capable of cell discontinuous transmission and / or cell discontinuous reception (CDTR), the method comprising: determining a CDTR state and / or CDTR configuration of the base station; and setting a state and / or configuration of the repeater node based on the determined CDTR state and / or CDTR configuration.

[00126] In certain examples, the state and / or configuration of the repeater node may comprise one or more of: a forwarding state and / or configuration of the repeater node (or a certain logical entity of the repeater node, e.g. NCR-Fwd); and a state and / or configuration of the repeater node (or a certain logical entity of the repeater node, e.g. NCR-MT) relating to transmission of control information.

[00127] In certain examples, forwarding transmissions between the base station and the UE may comprise one or more of: forwarding transmissions received from the UE (e.g. on an access link) to the base station (e.g. on a backhaul link); and forwarding transmissions received from the base station (e.g. on the backhaul link) to the UE (e.g. on the access link).

[00128] In certain examples, the CDTR state of the base station may comprise one or more of: cell discontinuous transmission (DTX) is active; cell DTX discontinuous transmission is inactive; cell discontinuous reception (DRX) is active; and cell DRX is inactive.

[00129] In certain examples, the CDTR configuration of the base station may comprise one or more of: a cell DTX non-active period (or active period); a cell DRX nonactive period (or active period); and a forwarding periodicity mode (e.g. periodic, aperiodic, semi-periodic).

[00130] In certain examples, setting the state and / or configuration of the repeater node may comprise one or more of: setting an uplink forward state of the repeater node (or certain logical entity of the repeater node, e.g. NCR-Fwd), for forwarding transmissions received from the UE to the base station, to active during a period when the cell DRX is active; setting the uplink forward state to inactive during a period when the cell DRX is inactive; setting an downlink forward state of the repeater node (or certain logical entity of the repeater node, e.g. NCR-Fwd), for forwarding transmissions received from the base station to the UE, to active during a period when the cell DTX is active; and setting the downlink forward state to inactive during a period when the cell DTX is inactive.

[00131] In certain examples, setting the state and / or configuration of the repeater node may comprise deactivating or switching off the repeater node (or a certain logical entity of the repeater node, e.g. NCR-Fwd) during a period when both cell DTX and cell DRX are inactive.

[00132] In certain examples, setting the state and / or configuration of the repeater node may comprise one or more of: setting an uplink forward state to inactive during a part of a period when the cell DRX is inactive, and setting the uplink forward state to active during a part of a period when the cell DRX is inactive (e.g. inactive for data reception, but not for non-data reception, e.g. SSB, RACH, SIB, etc.); and setting a downlink forward state to inactive during a part of a period when the cell DTX is inactive, and setting the downlink forward state to active during a part of a period when the cell DTX is inactive (e.g. inactive for data transmission, but not for non-data transmission, e.g. SSB, RACH, SIB, etc.).

[00133] In certain examples, setting the state and / or configuration of the repeater node may comprise one or more of: setting an uplink state of the repeater node (or certain logical entity of the repeater node, e.g. NCR-MT), for transmitting information (e.g. control information) to the base station, to active during a period when the cell DRX is active; setting the uplink state to inactive during a period when the cell DRX is inactive; setting an downlink state of the repeater node (or certain logical entity of the repeater node, e.g. NCR-MT), for monitoring information (e.g. control information) transmitted by the base station, to active during a period when the cell DTX is active; and setting the downlink state to inactive during a period when the cell DTX is inactive.

[00134] In certain examples, setting the state and / or configuration of the repeater node may comprise setting the state and / or configuration separately for uplink forwarding and downlink forwarding.

[00135] In certain examples, setting the state and / or configuration of the repeater node may comprise setting the state and / or configuration separately for a first logical entity of the repeater node (e.g. NCR-Fwd) and a second logical entity of the repeater node (e.g. NCR-MT).

[00136] In certain examples, setting the state and / or configuration of the repeater node may comprise setting the state and / or configuration separately for a first beam (or beam group) of the repeater node and a second beam (or beam group) of the repeater node.

[00137] In certain examples, setting the state and / or configuration of the repeater node may comprise setting the state and / or configuration for one or more certain forwarding periodicity modes only.

[00138] In certain examples, the state and / or configuration of the repeater node may be set based on a first logical entity of the repeater node (e.g. NCR-Fwd) being in an active state, and a second logical entity of the repeater node (e.g. NCR-MT) being in an inactive state (e.g. RRC inactive).

[00139] In certain examples, setting the state and / or configuration of the repeater node may comprise setting the state and / or configuration based on one or more exceptions.

[00140] In certain examples, setting the state and / or configuration of the repeater node may comprise setting the state and / or configuration based on one or more of: the capability of support for CDTR by the repeater node; the capability of support for CDTR by the base station; and the capability of support for CDTR by one or more UEs connected to the base station via the repeater node.

[00141] In certain examples, the state and / or configuration of the repeater node may be set based on one or more of: explicit signalling; implicit signalling; static configuration; default configuration; network configuration; RRC configuration; DCI; MAC CE; Cell DTX and / or Cell DRX configuration; nes-RNTI.

[00142] In certain examples, the method may further comprise indicating, by the repeater node (ora certain logical entity of the repeater node, e.g. NCR-MT), whether the repeater node is capable of supporting CDTR and / or whether the repeater node is implementing CDTR.

[00143] Certain examples of the present disclosure provide a repeater node (e.g. NCR) configured to perform a method according to any example, aspect, embodiment and / or claim / clause disclosed herein.

[00144] Certain examples of the present disclosure provide a network (or wireless communication system) comprising a base station, a UE, and a repeater node according to any example, aspect, embodiment and / or claim / clause disclosed herein.

[00145] Certain examples of the present disclosure provide a computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any example, aspect, embodiment and / or claim / clause disclosed herein.

[00146] Certain examples of the present disclosure provide a computer or processor-readable data carrier having stored thereon a computer program according to any example, aspect, embodiment and / or claim / clause disclosed herein.

[00147] Various specific but non-limiting examples will now be described in more detail.

[00148] In the present disclosure, the wording “NCR-Fwd ON” I ’’NCR forwarding” or “NCR-Fwd OFF” I ’’NCR ceasing forwarding”, or similar wording, may be used to indicate that NCR-Fwd is operating, i.e. forwarding. This has been defined in NCR 3GPP Release 18.

[00149] The skilled person will appreciate that additional / different states may be defined in the future, for example in 6G. For instance, “NCR-Fwd ON”, “NCR-Fwd partial ON” and / or “NCR-Fwd OFF”, may be defined indicating intermediate steps where the NCR is not forwarding fully. This may be include, for instance, only using one or more of the following to forward: (i) a (sub)set of beams, (ii) a part of the configuration, (iii) a set of the time-resources, (iv) a part of the bandwidth, and / or (v) less than full power, etc.

[00150] The skilled person will appreciate that the concept of not forwarding may be applied in per-direction. For example, in some cases the NCR may not forward signals / transmissions / data from the gNB on the access link (i.e. downlink signals / transmissions / data), and in some cases the NCR may not forward signals / transmissions / data on the backhaul link (i.e. forward uplink signals / transmissions / data from UE to gNB). Cell DTX and Cell DRX NCR

[00151] In certain examples, for the Cell DTX and Cell DRX to enable both power saving and predictable operation, the forwarding operation of the NCR may be adapted, for example according to one or more of the following techniques.

[00152] In certain examples, during the Cell DTX non-active duration, the NCR does not forward on the access link. In certain examples, during this time, the NCR may still forward on the backhaul. An example of this is illustrated in Figure 15.

[00153] In certain examples, during the Cell DRX non-active duration, the NCR does not perform backhaul forwarding. In certain examples, during this time, the NCR may still forward on the access link. An example of this is illustrated in Figure 16.

[00154] A specification example of how this can be implemented in MAC is disclosed further below in Specification Example 1.

[00155] In certain examples, if the Cell DRX and Cell DTX are both configured, then in the duration in which the Cell DRX and Cell DTX coincide (e.g. the Cell DRX and Cell DTX non-active durations overlap), the NCR-Fwd may be turned OFF. If the Cell DRX and Cell DTX are completely aligned (i.e. Cell DRX and Cell DTX non-active durations are the same, or similarly that the Cell DRX and Cell DTX have the same cycle), for instance either via configuration or via requirement, the NCR-Fwd may be turned OFF during the combined Cell DRX and DTX. An example of this is illustrated in Figure 17.

[00156] In certain examples, to allow for less complicated configurations of an NCR configured with Cell DTX and Cell DRX, an NCR may be configured only with overlapping Cell DTX and Cell DRX (i.e. overlapping non-active durations). In this case, the NCR-Fwd will remain OFF during the non-active duration.

[00157] In certain examples, the NCR-MT may also conform to the Cell DTX and DRX in a similar manner to above. For example, NCR-MT will not transmit during Cell DRX non-active duration, and NCR-MT will not monitor during Cell DTX non-active duration.

[00158] Any suitable techniques may be used for configuring an NCR to adapt to Cell DTX and Cell DRX, for example as described above. In certain examples, RRC configuration may be used, for example using the RRC fields that are also used for configuring UEs, i.e. CellDTX-Config or CellDRX-Config. In cases where it may be advantageous to allow a distinction whether only NCR-MT or NCR-Fwd applies the configuration, a field may be introduced to make the distinction. A specification example of this is disclosed further below in Specification Example 2.

[00159] In certain examples, a separate RRC field for Cell DTX or Cell DRX may be introduced specifically for NCR-Fwd. This can for instance be configured as part of NCR-FwdConfig. This may be important if there is a need to configure different Cell DTX and / or Cell DRX for NCR-MT and NCR-Fwd.

[00160] In the present disclosure, applying Cell DTX and / or Cell DRX to / for NCR (or a specific logical entity of NCR, e.g. NCR-Fwd or NCR-MT), configuring Cell DTX and / or Cell DRX to / for NCR (or a specific logical entity of NCR), or similar wording, may refer to configuring the NCR (or a specific logical entity of NCR) with (or based on) a Cell DTX and / or Cell DRX configuration, for example according to one or more of the techniques disclosed herein.

[00161] As described above, there are three different ways of configuring or starting forwarding, namely periodic, aperiodic and semi-periodic. In certain examples, the Cell DTX and / or Cell DRX configuration of NCR may be applied only to one or more certain types of forwarding. For instance, the Cell DTX and Cell DRX may be applied only to periodic forwarding. This may be useful as periodic forwarding is both started and configured using RRC, while aperiodic and semi-periodic forwarding is configured but started by DCI and MAC CEs.

[00162] In certain examples, the DCI may indicate whether the Cell DTX and Cell DRX shall apply to NCR or not. This may be useful in cases in which starting Cell DTX and / or Cell DRX shall be applied by NCR. In other examples this may not be the case.

[00163] The above configurations may be implicit or explicit. For instance, if a Cell DTX or Cell DRX configuration is sent to an NCR, it may be implicit how an NCR should apply the configuration. As another example, if the Cell DTX and / or Cell DRX are configured to an NCR-MT, it may be implicit that only the NCR-MT shall apply the configuration and that NCR-Fwd shall not apply it. A specification example of this is disclosed further below in Specification Example 3. Per-NCR beam configuration for Cell DTX and / or Cell DRX

[00164] In certain examples, Cell DTX and / or Cell DRX may be configured per NCR beam. This would for instance allow that certain beams will be configured with Cell DTX and Cell DRX at certain points, while some other beams are always ON. In another example, Cell DRX-groups and / or Cell DTX-groups may be defined and the configuration may be applied per group.

[00165] This for instance allows the Cell DTX and / or Cell DRX to be configured per sector. In certain examples, if there are different Cell DTX and / or Cell DRX configurations, then the NCR or NCR-MT may only enter Cell DTX or Cell DRX non-active duration if all the beams are in Cell DRX or Cell DRX. An example of per-NCR beam configuration of Cell DTX is illustrated in Figure 18.

[00166] In certain example, the DCI (and subsequently PDCCH scrambled by nes-RNTI) that activates the Cell DTX and / or Cell DRX may indicate which beam that Cell DTX or DRX concerns. This can for instance allow for more granular Cell DTX and / or DRX. In another example, each separate beam may be configured to define whether it should be affected by Cell DTX and / or Cell DRX. This can for instance allow for a more flexible configuration whereby a set of periodic beam-forwarding occasions may not be affected by Cell DTX and / or Cell DRX and a different set of beam-forwarding occasions are not affected. For example, this may be configured with an Information Element (IE) applyCellDTX-DRXwith the values DTX, DRX or DTX-DRX, where DTX or DRX implies only applying DTX or DRX, and DTX-DRX implies applying both DTX and DRX. Non-presence of the field may mean that the NCR does not apply the Cell DTX or DRX to the beam-specific forwarding configuration. This can for instance allow that certain very wide NCR beams can remain forwarding and unaffected by the Cell DTX and Cell DRX, while the narrower beams will be affected, thus saving power while maintaining gNB normal operations. RRC inactive forwarding aspects

[00167] In certain examples, the NCR may be configured to also apply the Cell DTX / DRX to NCR-Fwd operations when an NCR-MT is in RRC inactive and NCR-Fwd is performing forwarding. This may be a separate configuration that is for instance configured in RRC inactive configuration (SuspendConfig) in RRCRelease.

[00168] In order for an NCR to know when the energy saving starts, an NCR-MT may have to monitor nes-RNTI, similar to a UE. This may also need to be applied in RRC inactive. However, as monitoring further RNTIs in RRC inactive is generally not preferred, as an alternative, the power saving operations may be indicated to an NCR by means of paging. This can for instance be done through the following options: - A bit-field nes-PowerSaving may be included in Short Message (this is a part of PDCCH addressed by Paging (P)-RNTI that a network uses to indicate system info modification, emergency indication etc). Using RRC message Paging: o There can for instance be a field in the Paging message indicating starting gNB power saving operation. o A specific ue-ldentity can be assigned for this purpose.

[00169] In another example, when the NCR-MT enters RRC inactive, the NCR does not apply the Cell DTX and Cell DRX for NCR-Fwd and forwards according to a previous forwarding configuration. This means that when the NCR-MT enters RRC inactive via RRC Release, the Cell DTX and Cell DRX is not used or followed. Exceptions

[00170] In certain examples, a gNB may be expected to be able to maintain services through Cell DTX and Cell DRX. Accordingly, there may be certain exceptions to the Cell DTX and Cell DRX configured to an NCR. For example, these exceptions may be configured by a donor gNB if there are UEs that are connected via the NCR that do not support Cell DTX and Cell DRX, or if there are services that need to be maintained. Implementing one or more exceptions may make NCR-Fwd continue to forward despite NCR being configured with Cell DTX and / or Cell DRX.

[00171] An exception for Cell DRX can for instance be defined such that if NCR-Fwd detects anything on the forward link, the NCR-Fwd will forward the uplink transmission to the donor gNB on the backhaul link. Similarly, an exception for Cell DTX can for instance be defined such that if NCR-Fwd detects anything being transmitted on the backhaul link, the NCR-Fwd will forward the downlink transmission to the donor gNB on the access link.

[00172] In certain examples, one or more exception, such as those described above may be defined if the NCR-Fwd detects any signal having a signal strength above a certain threshold. For example, the threshold may be defined in the Cell DTX or Cell DRX configuration, or may be a threshold configured for all cases. In certain examples, the threshold may be implicit / hardcoded.

[00173] One or more exceptions for Cell DTX and / or Cell DRX may for instance be configured via DCI, MAC CE or RRC. Aligning NCR and UE configurations

[00174] As the Cell DTX / DRX may be specific to a device (e.g. a UE or an NCR) there may need to be alignment between what is configured to a UE and what is configured with an NCR. If these are not aligned, then a UE that is being served / connected via an NCR may suffer problems.

[00175] In certain examples, the gNB aligns the NCR and the associated UE configurations. This alignment may be done so that certain functions that gNB is required to maintain, such as random access, SSB transmissions, paging and system information broadcasting, can still forwarded by the NCR. An example of this is illustrated in Figure 19, where the Cell DTX pattern configured to the NCR is reduced (e.g. has a shorter overall duration) compared to the Cell DTX pattern configured to the UE. Thus there can be requirements that the configuration of Cell DTX and Cell DRX to NCR shall still allow for normal gNB operations.

[00176] As another example, the NCR-MT and NCR-Fwd may be configured with different Cell DTX and / or Cell DRX patterns. There may for instance be a requirement that the NCR-Fwd and NCR-MT are not configured with the same Cell DTX and Cell DRX patterns. This is so that the NCR-Fwd can still perform certain gNB functions, such as random access, SSB-transmission, paging and system information. An example of this is illustrated in Figure 20. Different patterns may also be used so that NCR-MT can reach and remain reachable while the NCR-Fwd is not forwarding.

[00177] In certain examples, if a UE moves from being served directly by a gNB to being served by an NCR, then the Cell DTX and Cell DRX configuration may need to be reconfigured.

[00178] In certain examples, there may be UEs that support Cell DTX and an NCR that does not support Cell DTX (e.g. the NCR only supports Cell DRX, or only certain energy saving features). In this case, the forwarding may need to be stopped by the network implementation. This can for instance be done when the network has identified that a UE is connected via the NCR. The network may then reconfigure the NCR to not forward at all during the Cell DTX duration. The above example may also be applicable in the case that an NCR does not support Cell DRX, and Cell DRX is configured to a UE. Capabilities

[00179] In certain examples, the NCR-MT may indicate whether the NCR has implemented Cell DTX and / or Cell DRX. In certain examples, it may be indicated whether Cell DTX and / or Cell DRX has been implemented and / or is supported for NCR-MT, NCR-Fwd, or both. In some examples, if NCR indicates the support of Cell DTX and Cell DRX, it may be implicit that NCR-MT and NCR-Fwd support the actions related to Cell DTX or Cell DRX. In other examples, it may be implicit that only one logical entity (e.g. NCR-MT) supports the actions related to Cell DTX and Cell DRX. In this case, a separate capability bit may indicate that the other logical entity (e.g. NCR-Fwd) supports the actions related to Cell DTX and Cell DRX. In certain examples, it may be indicated whether NCR supports one of the Cell DTX or Cell DRX. Specification Examples Specification Example 1 ..............Based on endorsed running MAC CR R2-2308393 -.......... 5.x Cell Discontinuous Transmission and Reception The MAC entity may be configured by RRC per Serving Cell with a periodic cell DTX and / or cell DRX pattern (i.e., Active and Non-Active Periods). The cell DTX functionality controls UE’s monitoring activity of PDCCH and configured downlink assignments in RRCCONNECTED. For all activated Serving Cells configured with cell DTX, the MAC entity may monitor PDCCH and configured downlink assignments using the cell DTX operation specified in this clause and other clauses of this specification. The cell DRX functionality controls Scheduling Request and configured uplink grant transmission activity in RRC COXNECTED, For all activated Serving Cells configured with cell DRX, the MAC entity may transmit configured uplink grant transmissions and Scheduling Request using the cell DRX operation specified in this clause and other clauses of this specification. Editor’s note: FFS whether to support multiple cell DTX / DRX pattern configurations. RRC controls cell DTX operation by configuring the following parameters in CellDTX-Config: - celldtx-onDurationTimer. the active duration at the beginning of a cell DTX cycle; - celldtx-StartOffset'. defines the subframe where the cell DTX cycle starts; - celldtx-SlotOffset'. the delay before starting the celldtx-onDurationTimer, - celldtx-Cycle'. the cell DTX cycle period. RRC controls cell DRX operation by configuring the following parameters in CellDRX-Config. - celldrx-onDurationlm the active duration at the beginning of a cell DRX cycle; - celldrx-StartOffset'. defines the subframe where the cell DRX cycle starts; - celldrx-SlotOffset'. the delay before starting the celldrx-onDurationTimer, - celldrx-Cycle'. the cell DRX cycle period. Editor’s note: TBC whether cell DTX / DRX is configured per serving cell. Instances of “for the Serving Cell” and “for each Seivmg Cell” will be removed if it is configured per MAC Editor’s note: TBC whether cell DTX / DRX parameters can be configured with different values If C ell DTX is configured for an NCR-Fwd and cdldtx-OnDurationTimer is running, the NCR-Fwd does not forward on the access link. If Cell DRX is configured for an NCR-Fwd and celhlrx-OndurutionTimer is running, the NCR-Fwd does not perform backhauling. For each Serving Cell configured with CellDTX-Config, the MAC entity shall: 1> if cell DTX activation indication has been received from lower layers for this Serving cell, as specified in TS 38.213 [x]; or 1 >if cell DTX deactivation indication has not been received from lower layers for this Serving cell, as specified in TS 38.213 [x]: 2> if [(SFN x 10) + subframe number] modulo (celldtx-Cycle) = (celldtx-StartOJfset)'. 3> start celldtx-onDurationTimer for this serving cell after celldtx-SlotOffset from the beginning of the subframe. 1 >if cell DTX deactivation indication has been received from lower layers for this Serving cell, as specified in TS 38.213 [x]: 2> stop celldtx-onDurationTimer, if running. For each Serving Cell configured with CellDttX-Config. the MAC entity shall: 1 >if cell DRX activation indication has been received from lower layers for this Serving cell, as specified in TS 38.213 [x]; or 1 >if cell DRX deactivation indication has not been received from lower layers for this Serving cell, as specified in TS 38.213 [x]: 2> if [(SFN x 10) + subframe number] modulo (celldrx-Cycle) = (celldrx-StartOffset): 3> start celldrx-onDurationTimer for this serving cell after celldrx-SlotOffset from the beginning of the subframe. 1> if cell DRX deactivation indication has been received from lower layers for this Serving cell, as specified in TS 38.213 [x]: 2> stop celldtx-onDurationTimer, if running. When CellDTX-Config is configured for a Serving Cell, the cell DTX Active Period includes the time while: - celldtx-onDurationTimer is running for the associated Serving Cell; or - cell DTX deactivation indication has been received from lower layers for this Serving cell, as specified in TS 38.213 [x]. When CellDRX-Config is configured for a Serving Cell, the cell DRX Active Period includes the time while: - celldrx-onDurationTimer is running for the associated Serving Cell; or - cell DRX deactivation indication lias been received from lower layers for this Serving cell, as specified in TS 38.213 [x]. The cell DTX Non-Active Period includes the time outside the cell DTX Active Period. The cell DRX Non-Active Period includes the time outside the cell DRX Active Period CellDRX-Config The IE CellDRX-Config is used to configure cell DRX related parameters. Editor’s note: As a placeholder current range of on-duration, cycle and offset is same as in C-DRX, pending RAN2 discussion and decision. CellDRX-Config information element ___________________________________CellDRX-Config field descriptions__________________________________ celldrx-CycleStartOffset celldrx-Cycle in ms and celldrx-StartOffset in multiples of 1 ms.__________________________________________________ celldrx-onDurationTimer Value in multiples of 1 / 32 ms (subMilliSeconds) or in ms (millisecond). For the latter, value ms1 corresponds to 1 ms, value ms2 corresponds to 2 ms, and so on._________________________________________________________ celldrx-SlotOffset Value in 1 / 32 ms. Value 0 corresponds to 0 ms, value 1 corresponds to 1 / 32 ms, value 2 corresponds to 2 / 32 ms, and so on._________________________________________________________________________________________ ncr-CellDRX-ApplyOption Indicates where to apply the CellDRX-Config if configured for an NCR. applyToMT means that it is applied to NCR-MT only, applyToFwd means that it is applied to NCR-Fwd and applyToBoth means that it is applied to both NCR-MT and NCR-Fwd. - CellDTX-Config The IE CellDTX-Config is used to configure cell DTX related parameters. Editor’s note: As a placeholder current range of on-duration, cycle and offset is same as in C-DRX, pending RAN2 discussion and decision. CellDTX-Config information element ___________________________________CellDTX-Config field descriptions__________________________________ celldtx-CycleStartOffset celldtx-Cycle in ms and celldrx-StartOffset in multiples of 1 ms.__________________________________________________ celldtx-onDuration Timer Value in multiples of 1 / 32 ms (subMilliSeconds) or in ms (millisecond). For the latter, value ms1 corresponds to 1 ms, value ms2 corresponds to 2 ms, and so on._________________________________________________________ celldtx-SlotOffset Value in 1 / 32 ms. Value 0 corresponds to 0 ms, value 1 corresponds to 1 / 32 ms, value 2 corresponds to 2 / 32 ms, and so on._________________________________________________________________________________________ join tCellD TXDRXconfig If set to true, the UE shall also apply a cell DRX configuration with the same parameters as in CellDTX-Config. ncr- Cel ID TX-ApplyOp tion Indicates where to apply the CellDTX-Config if configured for an NCR. applyToMT means that it is applied to NCR-MT only, applyToFwd means that it is applied to NCR-Fwd and applyToBoth means that it is applied to both NCR-MT and NCR-Fwd. -------Based on endorsed running RRC CR R2-2307528 -- - MAC-CellGroupConfig The IE MAC-CellGroupConfig is used to configure MAC parameters for a cell group, including DRX and cell DTX / DRX. Editor's note: FFS whether the Cell DTX / DRX configuration and activation is per MAC entity or per serving cell. MAC-CellGroupConfig information element I-’- 1 —'1- I lit ' • ii -'I'jt. :■ .'..'li- ”1111 I'. ' ' 1 : : • I ' 6 4 l t i q 1-.- -..- K‘-l ■ I." .-' ::. lul ill'll. I'l.- -O'’ . I ■ , 1 ' i 11: r ''''-'"'^ / / / / / / / i / ^ ■' / 1; ' r • • • . : phr-f.j.z.L? .skipH]: lio o -AS- Ji-ntig ::77iAO$iiOS / lA'Z<:::::::: 1 11 PHR-Co f_? itdiRiviraxiO fi >:-t^ ................................................. : :::::::::: : lii / llllllllllll / / : / ::l!il / 3 / 6:il / 7.-., yiiiiiiiy--::-y::g$y^^g::-::::::. cal—I la a c dalalnacc_— _ryTi nier- .’aTd-d-ian / i wTi - r 3.-,-:-: • .i-.-li- dill ix- I a . I I h-LM1-,!' a- I I -. Ich-Lj.. .jlil. rlt l_.it luii-rl a- '-f , .- '11D-E FF-3' '-11 H'BSsSaHSlgSaaafiaaiygiSggsilSittti ' - t: 1 n । h-I ' ’ - In I I ! iqF ■ ' |U' . I I : [ li ibl- J} ililillillllo^ anhan-.a a 3 iic'Jf IxnF.TiiCunf i.gurci:-_l ■' / li / / / / / / / iiiiiiiill / / / lull I1' 't:™: I . . ; . I i ' .:1 i >|| i -1 r- -11 I । ■ -.-: -i i dri-CaiMi c£::c -cl 7 u U . -I-; - ME’-EFR-il" rJi-lnl_ a_ _ EIE-EFF_-il" rgbg / iBri / illiggsigggiogyl / O I-..? {true} EE7 / Ft' (trua : Hi F" '1 . [ mi il. ■ j; . .' I >H lx I I. ( [■.■■_.•• . p’] - । | , | iSeiHgSsiSaggiiiiiiii8Kgg8aa:EiiigExSSgi§iSSiiiyii iSsiisSHBsiggRiS'SgSSiyi®??:?:?:?:! -'jh-dnliii iR-Fn-. SgBg / gigggKgggigoOgRs / girOi / i / i / siO t ar-'J.ji. 11 J-al FatupEalaaaa [ TR 1-F.IITI .' I -. .--..1 in II. i .-I -I 1" : : ,,-..1:. i .’p- -.11 1 I." ’ i.: : :-. I '. , ■■ ■ • l-I.IIT f- ----1 F.i 1 - l. >l.i . I -I T' "i’. ’ ‘ ' 'i ( : ( ' FlHllli'-ji 11._ :-11 ' -: .-, I-' r-Fi 11- ’ fiaT -idikdLi. t-l1~ <- '1 / / / / / / 0^- / / 0^10:0^61 / / 7 / ^:0010 / / / / / / 8 / 6: / / / / / 7 / 0717 / 7 / / ^6 / 60 / / / / / / :^ 3p-_lfl_|' ll.-ll-.l” . , 77117717 / 16 / SSOO0iOss8O:6 / :®Ss6SO6OOvO® / 67:i:i:i:i3£iiig^ f_g-rl^ } :-FJ IT I - i I ' - I . ll ,T-K’, ' - ■-M1TI-: I .') i 'IF' -11." - ?-CF-RnTI-rl7 1 ) -I::’ -lEF-R’ITI- F-3R-RIITI-1-1" I ) ■-F I'EE-MITI- c^lldrr-I'rAfiri-rlJ R33 . cReRj; { dll DIR- :: Adia-rl 3 } . . . OMITTRE . . MAC-CellGroupConfig field descriptions ... OMITTED ... celldrx-Config Used to configure cell DRX as specified in TS 38.321 [3], If configured to NCR-MT, only the NCR-MT applies this field.___________________________________________________________________________________________________________________________________ celldtx-Config Used to configure cell DTX as specified in TS 38.321 [3]. If configured to NCR-MT, only the NCR-MT applies this field. ... OMITTED ...

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

[00181] The entity 2100 comprises a processor (or controller) 2101, a transmitter 2103 and a receiver 2105. The receiver 2105 is configured for receiving one or more messages from one or more other network entities, for example as described above. The transmitter 2103 is configured for transmitting one or more messages to one or more other network entities, for example as described above. The processor 2101 is configured for performing one or more operations, for example according to the operations as described above.

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

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

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

[00185] While the present disclosure has been shown and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the disclosure, as defined by the appended claims / clauses. Acronyms In the present disclosure, the following acronyms / definitions may be used. 3GPP 3rd Generation Partnership Project 5G 5th Generation 6G 6th Generation BFR Beam Failure Recovery CDTR Cell DTX and / or Cell DRX CE Control Element CG Configured Grant CHO Conditional Handover CR Change Request CSI Channel State Information DCI Downlink Control Information DL Downlink DRX Discontinuous Reception DTX Discontinuous Transmission eNB Base Station Fwd Forward gNB 5G Base Station ID Identity / ldentification IE Information Element MAC Medium Access Control MT Mobile Terminated NB Base Station NCR Network-Controlled Repeater NES Network Energy Saving NR New Radio OPEX Operating Expenditure PCell Primary Cell PDCCH Physical Downlink Control Channel PDSCH Physical Downlink Shared Channel P-RNTI Paging RNTI PUCCH Physical Uplink Control Channel PUSCH Physical Uplink Shared Channel RAN Radio Access Network Rei Release RNTI Radio Network Temporary Identifier RRC Radio Resource Control RS Reference Signal Rx Receive SCell Secondary Cell SPS Semi Persistent Scheduling SR Scheduling Request SSB Synchronization Signal Block TR Technical Report TS Technical Specification Tx Transmit UE User Equipment UL Uplink Further examples related to network energy saving using repeater nodes are set out in the following numbered clauses. 1. A method, for a repeater node (e.g. an NCR) capable of forwarding transmissions between a base station and a User Equipment (UE), wherein the base station is capable of cell discontinuous transmission and / or cell discontinuous reception (CDTR), the method comprising: determining a CDTR state and / or CDTR configuration of the base station; and setting a state and / or configuration of the repeater node based on the determined CDTR state and / or CDTR configuration. 2. A method according to clause 1, wherein the state and / or configuration of the repeater node comprises one or more of: a forwarding state and / or configuration of the repeater node (or a certain logical entity of the repeater node, e.g. NCR-Fwd); and a state and / or configuration of the repeater node (or a certain logical entity of the repeater node, e.g. NCR-MT) relating to transmission of control information. 3. A method according to clauses 1 or 2, wherein forwarding transmissions between the base station and the UE comprises one or more of: forwarding transmissions received from the UE (e.g. on an access link) to the base station (e.g. on a backhaul link); and forwarding transmissions received from the base station (e.g. on the backhaul link) to the UE (e.g. on the access link). 4. A method according to clauses 1, 2 or 3, wherein the CDTR state of the base station comprises one or more of: cell discontinuous transmission (DTX) is active; cell DTX discontinuous transmission is inactive; cell discontinuous reception (DRX) is active; and cell DRX is inactive. 5. A method according to any preceding clause, wherein the CDTR configuration of the base station comprises one or more of: a cell DTX non-active period (or active period); a cell DRX non-active period (or active period); and a forwarding periodicity mode (e.g. periodic, aperiodic, semi-periodic). 6. A method according to any preceding clause, wherein setting the state and / or configuration of the repeater node comprises one or more of: setting an uplink forward state of the repeater node (or certain logical entity of the repeater node, e.g. NCR-Fwd), for forwarding transmissions received from the UE to the base station, to active during a period when the cell DRX is active; setting the uplink forward state to inactive during a period when the cell DRX is inactive; setting an downlink forward state of the repeater node (or certain logical entity of the repeater node, e.g. NCR-Fwd), for forwarding transmissions received from the base station to the UE, to active during a period when the cell DTX is active; and setting the downlink forward state to inactive during a period when the cell DTX is inactive. 7. A method according to any preceding clause, wherein setting the state and / or configuration of the repeater node comprises deactivating or switching off the repeater node (or a certain logical entity of the repeater node, e.g. NCR-Fwd) during a period when both cell DTX and cell DRX are inactive. 8. A method according to any preceding clause, wherein setting the state and / or configuration of the repeater node comprises one or more of: setting an uplink forward state to inactive during a part of a period when the cell DRX is inactive, and setting the uplink forward state to active during a part of a period when the cell DRX is inactive (e.g. inactive for data reception, but not for non-data reception, e.g. SSB, RACH, SIB, etc.); and setting a downlink forward state to inactive during a part of a period when the cell DTX is inactive, and setting the downlink forward state to active during a part of a period when the cell DTX is inactive (e.g. inactive for data transmission, but not for non-data transmission, e.g. SSB, RACH, SIB, etc.). 9. A method according to any preceding clause, wherein setting the state and / or configuration of the repeater node comprises one or more of: setting an uplink state of the repeater node (or certain logical entity of the repeater node, e.g. NCR-MT), for transmitting information (e.g. control information) to the base station, to active during a period when the cell DRX is active; setting the uplink state to inactive during a period when the cell DRX is inactive; setting an downlink state of the repeater node (or certain logical entity of the repeater node, e.g. NCR-MT), for monitoring information (e.g. control information) transmitted by the base station, to active during a period when the cell DTX is active; and setting the downlink state to inactive during a period when the cell DTX is inactive. 10. A method according to any preceding clause, wherein setting the state and / or configuration of the repeater node comprises setting the state and / or configuration separately for uplink forwarding and downlink forwarding. 11. A method according to any preceding clause, wherein setting the state and / or configuration of the repeater node comprises setting the state and / or configuration separately for a first logical entity of the repeater node (e.g. NCR-Fwd) and a second logical entity of the repeater node (e.g. NCR-MT). 12. A method according to any preceding clause, wherein setting the state and / or configuration of the repeater node comprises setting the state and / or configuration separately for a first beam (or beam group) of the repeater node and a second beam (or beam group) of the repeater node. 13. A method according to any preceding clause, wherein setting the state and / or configuration of the repeater node comprises setting the state and / or configuration for one or more certain forwarding periodicity modes only. 14. A method according to any preceding clause, wherein the state and / or configuration of the repeater node is set based on a first logical entity of the repeater node (e.g. NCR-Fwd) being in an active state, and a second logical entity of the repeater node (e.g. NCR-MT) being in an inactive state (e.g. RRC inactive). 15. A method according to any preceding clause, wherein setting the state and / or configuration of the repeater node comprises setting the state and / or configuration based on one or more exceptions. 16. A method according to any preceding clause, wherein setting the state and / or configuration of the repeater node comprises setting the state and / or configuration based on one or more of: the capability of support for CDTR by the repeater node; the capability of support for CDTR by the base station; and the capability of support for CDTR by one or more UEs connected to the base station via the repeater node. 17. A method according to any preceding clause, wherein the state and / or configuration of the repeater node is set based on one or more of: explicit signalling; implicit signalling; static configuration; default configuration; network configuration; RRC configuration; DCI; MAC CE; Cell DTX and / or Cell DRX configuration; nes-RNTI. 18. A method according to any preceding clause, further comprising indicating, by the repeater node (or a certain logical entity of the repeater node, e.g. NCR-MT), whether the repeater node is capable of supporting CDTR and / or whether the repeater node is implementing CDTR. 19. A repeater node (e.g. NCR) configured to perform the method of any of clauses 1 to 18. 20. A network (or wireless communication system) comprising a repeater node according to clause 20, a base station and a UE. 21. A computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any of clauses 1 to 18. 22. A computer or processor-readable data carrier having stored thereon a computer program according to clause 21.

Claims

1. A method for managing Global Navigation Satellite System (GNSS) position information at a user equipment (UE) in a non-terrestrial network comprising the UE and a network node (e.g. eNB) providing coverage to the UE, the method comprising:starting, at the UE, a timer indicating that GNSS position information of the UE is invalid; andstopping, at the UE, the timer in response to the UE initiating RRC re-establishment.

2. The method of claim 1, wherein handover of the UE is not triggered if the timer is running.

3. The method of claims 1 or 2, wherein the timer is implemented as a radio resource control (RRC) timer.

4. The method of any preceding claim, further comprising reporting, by the UE to the network node, the start of the timer.

5. The method of any preceding claim, wherein the timer is started in response to the GNSS position information of the UE becoming out-of-date.

6. The method of any preceding claim, wherein the timer is started in response to movement of the UE exceeding a threshold.

7. The method of any preceding claim, wherein the timer is started in response to there being less than a predetermined period before expiry of a duration during which the GNSS position information at the UE is considered valid (e.g. a GNSS validity duration).

8. The method of any preceding claim, wherein the timer is started in response to expiry of a duration during which the GNSS position information at the UE is considered valid (e.g. a GNSS validity duration).

9. The method of any preceding claim, wherein the timer is stopped in response to one or more of: a successful GNSS measurement at the UE, expiry of the timer, entry of the UE into an RRC idle mode, a radio link failure at the UE, a release of an RRC connection triggered by the eNB, data transmission inactivity by the UE, a medium access control (MAC) reset at the UE, and a MAC reconfiguration at the UE.

10. The method of claim 4, wherein the reporting includes transmitting, from the UE to the network node, a MAC control element (CE) indicating a zero value fora duration in which the GNSS position information is considered valid (e.g. GNSS validity duration).

11. The method of any preceding claim, wherein the GNSS position information is used for NTN communications.

12. The method of any preceding claim, wherein the UE is an Internet of Things (loT) device, a Narrowband (NB) loT device, a Long Term Evolution Machine Type Communications (LTE-M) device, or an enhanced Machine Type Communications (eMTC) device.

13. A user equipment (UE) comprising a processor, a receiver, and a transmitter, wherein the processor in combination with the receiver and transmitter is configured to implement the method of any of the preceding claims.

14. A computer-readable recording medium having stored thereon computer-executable instruction which when executed by a computer cause the computer to perform the method of any of claims 1 to 12.58

Images