Methods and apparatus for performing GNSS measurements

GB2633882APending Publication Date: 2025-03-26SAMSUNG ELECTRONICS CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
GB2024003789
Authority / Receiving Office
GB · GB
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-05-12
Filing Date
2024-03-15
Publication Date
2025-03-26

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

A user equipment, UE, 10, in a wireless communication network (in Non-Terrestrial Network, NTN cell 20), configured to: determine to perform a global navigation satellite system (GNSS) measurement (as
Need to check novelty before this filing date? Find Prior Art

Description

BACKGROUND Field

[0001] Certain examples of the present disclosure relate to methods, apparatus and / or systems for performing GNSS measurements during connected mode Discontinuous Reception (DRX). In particular, certain examples relate to methods, apparatus and / or systems for performing, by a UE, GNSS measurements during an off period of connected mode DRX (C-DRX). In various examples, the GNSS measurement is triggered by the network, while in other examples the GNSS measurement is triggered autonomously by the UE. In various examples, the UE is configured to indicate that a GNSS measurement was performed during C-DRX. 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 - NR; Radio Resource Control (RRC); Protocol specification; (e.g., V17.3.0). [2] 3GPP TS 36.331 - LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification; (e.g., V17.3.0). [3] RP-202689 - New Study WID on NB-loT / eTMC support for NTN (December 2020). [4] RP-211557 - Solutions for NR to support non-terrestrial networks (NTN) (March 2021). [5] RP-220953 - NR NTN (Non-Terrestrial Networks) enhancements (March 2022). [6] RP-223519 - Revised WID on loT NTN enhancements (December 2022). [7] R2-2304612 - LS on GNSS position fix during inactive state of Connected DRX for improved GNSS operations (May 2023). 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)). As noted in 3GPP RP-202689 [3], loT operation is critical in remote areas with low / no cellular connectivity for many different industries. The capabilities of NB-loT and eMTC are a good fit for many applications but some applications may require satellite connectivity to provide coverage beyond terrestrial deployments.

[0010] NR NTN was a work item in Rel-17 to specify adaptation to allow NR to function over NTN (RP-211557 [4]).

[0011] Non-Terrestrial Network access may be through LEO, MEO and GEO, as well as through High-Altitude Platform Systems (HAPS).

[0012] Figure 1 is a representation of an NTN, whereby a UE 10 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.

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

[0014] The work item description for loT NTN Rel-18 is the following (referring to RP-223519 [6]): 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 RLE, 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

[0015] 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.

[0016] 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

[0017] 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.

[0018] 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.3.0___________________________ SIB19 SIB19 contains satellite assistance information for NTN access. SIB19 information element SIB19-rl7 ::= 'X'omoE { ntn-Config-rl7 t-Service-rl7 referenceLocation-rl7 distanceThresh-rl7 ntn-NeighCellConfigList-rl7 lateNonCriticalExtension N T N - C o n f i g - r 17 ygggggg (Q..549755813887) ReferenceLocation-r17 ljX\E7ER(0. .65525) NTN-NeighCellConfigList-rl ntn-NeighCellConfiqListExt-vl720 ] ] NTN-NeighCellConfigList-rl / NTN-NeighCellConfigList-rl7 :: NeighCellConfig-rl7 ELUERLE ( ElEE (1. . rnaxCel INTN-rl7 ) ) EE NTN- NTN-NeighCellConfig-rl7 : ntn-Config-rl7 NTN-Contig-rl7 carrierFreq-rl7 physCellId-rl7 ARFCN-ValueNR PhysCellld. ______________________________________SIB19 field descriptions_____________________________________ distancefhresh 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 [201. 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. nin-NeighCeiiConfigLisi, nin-NeighCeiiConfigListExi 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.___________________________________________________________________ referenceLocation Reference location of the serving cell provided via NTN quasi-Earth fixed system and is used in locationbased measurement initiation in RRC IDLE and RRC INACTIVE, as defined in TS 38.304

[20] ,___________ t-Service Indicates the time information on when a cell provided via NTN quasi-Earth fixed system is going to stop serving the area it is currently covering. The field indicates a time in multiples of 10 ms after 00:00:00 on Gregorian calendar date 1 January, 1900 (midnight between Sunday, December 31, 1899 and Monday, January 1,1900). The exact stop time is between the time indicated by the value of this field minus 1 and the time indicated by the value of this field. 38.331 V17.3.0 In loT NTN SIB31 contains the required information to access an loT NTN cell: --------------------------36.331 V17.3.0-------------------------- - SystemlnformationBlockType31 The IE SystemlnformationBlockTypeSl contains satellite assistance information for the serving cell. Systemlnfo^^ is only signalled in a NTN cell. SystemlnformationBlockType31 information element — ASIUGTARl 3yst emlnfor’:.-t ± r.m ImskType ?1-rl ’ ::= Frl'FEnCE [ le±”±iiqdatelliteinfo-rl~f I Th --1-: - - lExtonn ' 'IT G—r- STRING ' ’FTB N< T ' i inj.' o____■ m ±_-il :: . Lx [ ephemeris Int :-rl" CETI ZE ±1 __-1Z-±qiii^t-± ' E -±1 >±Llt-ilE d±-il : O A AOfOoPOS nt r-T:. . :t-rr INTEGER StstiiiiffitaRgSMH INTEGER stGSisaS: nt ?-10 dhOrodtPaBldtddN -rl" INTEGER Hl. _ G" 1 / u.l. -P, i i J i '.yDm. j I. i ■ Ui- i\1. ; . . 1 -Ti ।, [ Jt, Jill, ’-[.'mll'm -: : 0 S 77 7 7-. { ... . ,± ' It 3® —! -rl- INTEGER iTS-i-TGEa: stamAt INTEGER ................................. k-Offset-r±~ -- _ ±- -NIR 1 1 1 . . 1RJ=I , OPTIONAL, — / ±±5 Gp 7) OPTIONAL, — Neel OP CPTB 1 PL — P-d Cp OPTIONAL, — Neel OP 5 — A3IU3TOE SystemlnformationBlockType31 field descriptions i epochTime i Epoch time of the satellite ephemeris data and common TA parameters, see TS 36.213

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

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

[23] , Unit in ms.___________________ I nta-Common i 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 *10 3 [ If the field is absent, the UE uses the (default) value of 0.____________________________________________________ [ nta-CommonDrift : Drift rate ofthe common TA, see TS 36.213

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

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

[23] , Unit in second. I Value s5 corresponds to 5 seconds, value sf O corresponds to 10 seconds and so on.______________________________________________ 10 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 15 vector (vX, vY, vZ) 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

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] 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

[0024] Both loT NTN and NR NTN are heavily reliant on GNSS in order to synchronize in frequency and in time, as well as to determine correct configuration(s) and whether the UE is allowed to operate in the cell or not. However, due to the nature of how GNSS is usually 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 specification. It is rather specified as a requirement that the UE shall have a recent and precise enough GNSS position. For instance the UE is required to have determined its own position to be used for time and frequencysynchronization and in loT NTN the UE is required to report its GNSS validity duration in certain RRC messages. Furthermore, if the GNSS is deemed to be invalid and the UE is in connected mode, the UE shall move to idle mode.

[0025] 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'.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] Some aspects of these discussions include how to report the GNSS fix duration, i.e. reporting how much time it takes a UE to perform a GNSS measurement, when to report either the GNSS fix time duration or the GNSS validity duration and how to model and trigger the GNSS measurements. SUMMARY

[0030] 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.

[0031] According to a first aspect of the present disclosure, there is provided a user equipment (UE) in a wireless communication network, the UE comprising: a receiver, a transmitter, and at least one processor configured to: determine to perform a global navigation satellite system (GNSS) measurement while the UE is in connected mode discontinuous reception (C-DRX) and outside a C-DRX active time; and transmit, to a first entity in the network, information on a time related to performing the GNSS measurement.

[0032] According to various examples, the information comprises: a first time based on a first time period between switching from the C-DRX active time and performing the GNSS measurement, and a second time period for performing the GNSS measurement; or a second time based on the first time period, the second time period, and a third time period between a time when the UE determined to perform the GNSS measurement and the end of the C-DRX active time.

[0033] According to various examples, the at least one processor is configured to: perform the GNSS measurement after a first C-DRX active time and before a second C-DRX active time; wherein the first time period is between switching from the first C-DRX active time and performing the GNSS measurement; and wherein the third time period is between the time when the UE determined to perform the GNSS measurement and the end of the first C-DRX active time.

[0034] According to various examples, the first time period is between a time when the C-DRX active period ends and a time when the GNSS measurement is performed.

[0035] According to various examples, the at least one processor is configured to: maintain radio link monitoring (RLM). For example, the at least one processor is configured to maintain RLM during C-DRX when the UE is capable of performing the GNSS measurement during C-DRX.

[0036] According to various examples, the at least one processor is configured to: acquire system information. For example, the at least one processor is configured to acquire system information during C-DRX when the UE is capable of performing the GNSS measurement during C-DRX.

[0037] According to various examples, the system information corresponds to system information block (SIB) 31 (SIB31).

[0038] According to various examples, the at least one processor is configured to: transmit, to the first entity, an indication that the GNSS measurement was performed during C-DRX or outside the C-DRX active time, when transmitting the information on the time.

[0039] According to various examples, the at least one processor is configured to: receive, from the first entity during the first C-DRX active time, a trigger to perform the GNSS measurement outside of the C-DRX active time.

[0040] According to various examples, the trigger is one of: a command to perform the GNSS measurement; or a DRX command medium access control (MAC) control element (CE) or a long DRX command MAC CE.

[0041] According to various examples, the at least one processor is configured to: in response to receiving the command, enter C-DRX or enter C-DRX based on a C-DRX configuration configured to be used when performing the GNSS measurement.

[0042] According to various examples, the trigger is received via radio resource control (RRC), MAC CE or downlink control information (DCI) signalling.

[0043] According to a second aspect of the present disclosure, there is provided a first entity in a in a wireless communication network, the first entity comprising: a transmitter, a receiver, and at least one processor configured to: receive, from a UE in the network, information on a time related to performance of a GNSS measurement by the UE while in C-DRX and outside a C-DRX active time of the UE.

[0044] According to various examples, the information comprises: a first time based on a first time period between switching from the C-DRX active time and performing the GNSS measurement, and a second time period for performing the GNSS measurement; or a second time based on the first time period, the second time period, and a third time period between a time when the UE determined to perform the GNSS measurement and the end of the C-DRX active time.

[0045] According to various examples, the at least one processor is configured to: receive, from the UE, an indication that the GNSS measurement was performed during C-DRX or outside the C-DRX active time, when transmitting the information on the time.

[0046] According to various examples, the at least one processor is configured to: transmit, to the UE, a trigger to perform the GNSS measurement outside of the C-DRX active time.

[0047] According to various examples, the trigger is one of: a command to perform the GNSS measurement; or a DRX command medium access control (MAC) control element (CE) or a long DRX command MAC CE.

[0048] According to various examples, the trigger is transmitted via radio resource control (RRC), MAC CE or downlink control information (DCI) signalling.

[0049] According to various examples, the first entity includes a core network (CN) or a base station.

[0050] According to a third aspect of the present disclosure, there is provided a method of a UE in a wireless communication network, the method comprising: determining to perform a GNSS measurement while the UE is in C-DRX and outside a C-DRX active time; and transmitting, to a first entity in the network, information on a time related to performing the GNSS measurement.

[0051] According to various examples, the information comprises: a first time based on a first time period between switching from the C-DRX active time and performing the GNSS measurement, and a second time period for performing the GNSS measurement; or a second time based on the first time period, the second time period, and a third time period between a time when the UE determined to perform the GNSS measurement and the end of the C-DRX active time.

[0052] According to various examples, the method comprises: performing the GNSS measurement after a first C-DRX active time and before a second C-DRX active time; wherein the first time period is between switching from the first C-DRX active time and performing the GNSS measurement; and wherein the third time period is between the time when the UE determined to perform the GNSS measurement and the end of the first C-DRX active time.

[0053] According to various examples, the first time period is between a time when the C-DRX active period ends and a time when the GNSS measurement is performed.

[0054] According to various examples, the method comprises: maintaining radio link monitoring (RLM). For example, the at least one processor is configured to maintain RLM during C-DRX when the UE is capable of performing the GNSS measurement during C-DRX.

[0055] According to various examples, the method comprises: acquiring system information. For example, the at least one processor is configured to acquire system information during C-DRX when the UE is capable of performing the GNSS measurement during C-DRX.

[0056] According to various examples, the system information corresponds to system information block (SIB) 31 (SIB31).

[0057] According to various examples, the method comprises: transmitting, to the first entity, an indication that the GNSS measurement was performed during C-DRX or outside the C-DRX active time, when transmitting the information on the time.

[0058] According to various examples, the method comprises: receiving, from the first entity during the first C-DRX active time, a trigger to perform the GNSS measurement outside of the C-DRX active time.

[0059] According to various examples, the trigger is one of: a command to perform the GNSS measurement; or a DRX command medium access control (MAC) control element (CE) or a long DRX command MAC CE.

[0060] According to various examples, the method comprises: in response to receiving the command, entering C-DRX or enter C-DRX based on a C-DRX configuration configured to be used when performing the GNSS measurement.

[0061] According to various examples, the trigger is received via radio resource control (RRC), MAC CE or downlink control information (DCI) signalling.

[0062] According to a fourth aspect of the present disclosure, there is provided a method of a first entity in a in a wireless communication network, the method comprising: receiving, from a UE in the network, information on a time related to performance of a GNSS measurement by the UE while in C-DRX and outside a C-DRX active time of the UE.

[0063] According to various examples, the information comprises: a first time based on a first time period between switching from the C-DRX active time and performing the GNSS measurement, and a second time period for performing the GNSS measurement; or a second time based on the first time period, the second time period, and a third time period between a time when the UE determined to perform the GNSS measurement and the end of the C-DRX active time.

[0064] According to various examples, the method comprises: receiving, from the UE, an indication that the GNSS measurement was performed during C-DRX or outside the C-DRX active time, when transmitting the information on the time.

[0065] According to various examples, the method comprises: transmitting, to the UE, a trigger to perform the GNSS measurement outside of the C-DRX active time.

[0066] According to various examples, the trigger is one of: a command to perform the GNSS measurement; or a DRX command medium access control (MAC) control element (CE) or a long DRX command MAC CE.

[0067] According to various examples, the trigger is transmitted via radio resource control (RRC), MAC CE or downlink control information (DCI) signalling.

[0068] According to various examples, the first entity includes a core network (CN) or a base station.

[0069] According to a fifth aspect of the present disclosure, there is provided a computer program or computer-readable storage medium comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any of the above aspects or examples.

[0070] 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

[0071] 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 a representation of various timers associated with DRX; Figure 4 shows a representation of performing GNSS measurement during C-DRX according to certain examples of the present disclosure; Figure 5 shows a representation of performing GNSS measurement during C-DRX as triggered by receiving a Long DRX Command MAC CE according to certain examples of the present disclosure; Figure 6 is a block diagram illustrating an example structure of a network entity in accordance with certain examples of the present disclosure. Figure 7 is a flow diagram illustrating a method in accordance with various examples of the present disclosure. Figure 8 is a flow diagram illustrating a method in accordance with various examples of the present disclosure. DETAILED DESCRIPTION

[0072] 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.

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

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] Certain examples of the present disclosure relate to methods, apparatus and / or systems for performing GNSS measurements during connected mode Discontinuous Reception (DRX). In particular, certain examples relate to methods, apparatus and / or systems for performing, by a UE, GNSS measurements during an off (OFF) period of connected mode DRX (C-DRX). In various examples, the GNSS measurement is triggered by the network, while in other examples the GNSS measurement is triggered autonomously by the UE. In various examples, the UE is configured to indicate that a GNSS measurement was performed during C-DRX.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] As described above, current 3GPP Release 1 loT NTN discussions include how to report the GNSS fix duration, i.e. reporting how long time it takes a UE to perform a GNSS measurement, when to report either the GNSS fix time duration or the GNSS validity duration and howto model and trigger the GNSS measurements. Various examples, embodiments, aspects etc. of the present disclosure aim to aim to address one or more of these issues.

[0088] Connected mode Discontinuous Reception (DRX) is a useful feature to allow a UE to save power in a modern cellular 3GPP network. Connected mode DRX (C-DRX) defines occasions when a UE is not required to monitor for physical downlink control channel (PDCCH) assignments or system information from the network, i.e. the UE can partly power down its receiver (e.g., reduce the amount of power consumed by the receiver). DRX may be configured per UE and may be controlled by the network.

[0089] In E-UTRAN, DRX is defined by a set of timers, but in general the following is defined: - On-duration: This is the duration in downlink subframes that the UE waits to receive PDCCH assignments. This is configured as part of DRX cycle. The UE stays awake if it successfully decodes a PDCCH assignment and the duration to stay awake is the inactivity timer. - Inactivity-timer: This is the duration in downlink subframes that the UE waits after decoding a PDCCH. This allows the network to continue keeping the UE awake if more data is to be transmitted. - Active-time: This is the duration that the UE is awake, which includes the on-duration, the time during the inactivity timer, the time after a (downlink (DL) or uplink (UL)) Hybrid automatic repeat request (HARQ) Round Trip Time (RTT) timer has expired and several more cases. Thus the active-time changes depending on how the UE is scheduled by the network.

[0090] The DRX cycle may either be in a so-called short DRX cycle, or a long DRX cycle which are differentiated by the length of the DRX cycle. The short and long DRX cycle can be switched using the Long DRX Command MAC CE or the DRX Command MAC CE. In some examples, the short DRX cycle can be as short as 2 subframes up to 640 subframes. In some examples, the long DRX cycle can have lengths from 10 up to 2560 subframes. This was extended for eMTC use case up 10240 subframes, in some examples of the long DRX cycle.

[0091] For NB-loT there is only a single DRX cycle to simplify the procedures.

[0092] For the above, a number of timers / durations have been defined: - onDurationTimer. Timer for the On-duration. - drx-lnactivityTimer. Timer for the inactivity timer - drx-retransmissionTimer. The time to stay awake (DL or UL) after HARQ RTT. HARQ RTT timer. The number of subframes before a downlink assignment for HARQ retransmission is expected by the MAC entity. - UL HARQ RTT timer. The number of subframes before a uplink retransmission grant is expected by the MAC entity.

[0093] Furthermore, the parameter drxShortCycleTimer decides for how long a short DRX cycle shall be active until the Long DRX cycle is used. It may be a multiple of the Short DRX cycle length.

[0094] Figure 3 is a representation of the operation of at least some of these timers. That is, Fig. 3 shows a DRX procedure for the downlink illustrating how the active-time turns on and off with drx-Onduration, drx-lnactivityTimer and drx-RetransmissionTimer.

[0095] One 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 transmitting and receiving data. This is because of cheaper filters and receivers in an loT device (i.e., having fewer capabilities), which contrasts that of 5G NR devices that are able to perform these actions simultaneously.

[0096] In 3GPP RAN1 loT NTN, performing a GNSS measurement during Connected mode DRX has been discussed. It was realised that already introduced connected mode DRX defines certain down-periods, originally used for the UE to save power, can be used to perform GNSS measurements. To this end, RAN1 sent a LS (liaison statement) to RAN2 with the following (referring to R2-2304612 [7]): RANI has discussed GNSS position fix during inactive state of Connected DRXfor improved GNSS operations and agreed the following conclusion. Conclusion From RANI perspective, UE is not forbidden to autonomously re-acquire GNSS position fix during inactive state of Connected DRX. • Note: The configured DL / UL transmissions during inactive state of Connected DRX should not be impacted • Note: details are up to RAN2 Send an LS to RAN2 for the conclusion.

[0097] As it may be very beneficial to utilize the C-DRX periods for performing GNSS measurements, there are however some considerations with respect to the current state of the art of performing GNSS measurements in RRC connected mode that are yet to be solved. These include: • How to trigger a GNSS measurement utilizing C-DRX? o For instance, how does a network configure a UE to perform a GNSS measurement during C-DRX either when triggered by the network or when UE performs GNSS measurements autonomously? • Under which circumstances a GNSS measurement may be performed during C-DRX? • How to adjust currently agreed procedures such as how a UE reports GNSS fix time?

[0098] Various examples of the present disclosure aim to address at least to some extent one or more of these issues.

[0099] According to an example of the present disclosure, there is provided methods for performing, reporting and / or configuring GNSS measurements to be performed under / during C-DRX.

[00100] It will be appreciated that all embodiments, examples, aspects etc. disclosed herein may also apply for NR NTN or LTE-M / eMTC NTN, in addition to loT NTN.

[00101] In the present disclosure, the wording “performing measurements” (or similar) may more specifically include the meanings: “performing measurements given all other conditions are fulfilled” and / or “if supported, performing measurements” or “if applicable, performing measurements”, and / or any other suitable meaning within the broader field of the wording “performing measurements”. In other words, in some examples performing measurements may be dependent on other already- introduced conditions, while in other examples performing measurements may be independent of already-introduced conditions. That is, any other conditions for performing measurements such as those given by prior art may still be considered.

[00102] In the present disclosure, reference to the UE reporting, or to the UE signalling or the UE indicating etc., may include the case of the UE making a transmission to the network (e.g., CN) or to a base station (e.g., eNB, gNB etc.), directly or indirectly.

[00103] According to various examples of the present disclosure, performing a GNSS measurement during C-DRX means that the UE performs the GNSS position fix during the period when the UE is not monitoring PDCCH or receiving any data. In other words, the UE is configured to perform GNSS position fix during the time outside the DRX active time. This is illustrated in Figure 4. As can be seen in Figure 4, GNSS measurement is performed between the active times or following the end of an active time.

[00104] In various embodiments, the UE may be configured to (e.g., required to) report (e.g., to the network or a base station) its capabilities concerning performing the GNSS measurement during C-DRX. This can then be used by the network either to configure the UE with a suitable configuration (e.g., a configuration including an indication or instruction to perform GNSS measurement during C-DRX, such as during the off-period of C-DRX), or to allow the network to know what to expect from the UE (e.g., that the UE will measure GNSS during C-DRX, such as during the off-period of C-DRX).

[00105] As an example, once the UE has reported its capabilities, the network may not command / trigger the UE to perform a GNSS measurement. This can be done via UE capabilities or other signaling, for example the RRC signaling of UElnformationRequest / UEInformationResponse

[00106] In current Rel-18 loT NTN discussions, a GNSS measurement may be triggered dynamically through a command by the network or the UE may autonomously start a GNSS measurement.

[00107] In one example, utilizing C-DRX to perform a GNSS measurement may be configured by the command to perform the GNSS measurement (e.g., receiving the command, e.g. from the network, may configure the UE to perform GNSS measurement during C-DRX). In other words, upon receiving the command to perform the GNSS measurement, the UE interprets the command as being to utilize C-DRX to perform the GNSS measurement. For example, this command may be via RRC, MAC CE and / or DCI. Further, this signaling may be in the form of a bit / flag that informs (or indicates to) the UE that GNSS measurement fix shall be performed in the OFF period of C-DRX. It may, for instance, imply that the GNSS measurement shall only be performed during the Long DRX period.

[00108] In various embodiments, the command to perform a GNSS measurement may also trigger C-DRX to start (e.g., at the UE). For example, some options for this are: • The command to perform a GNSS measurement may trigger the UE to enter Long DRX. • The command to perform a GNSS measurement may trigger the UE to enter DRX. • The command to perform a GNSS measurement may be the actual DRX Command MAC CE or the Long DRX Command MAC CE. The latter example is illustrated in Figure 5. • The command to perform a GNSS measurement may have the UE to enter a C-DRX configuration specifically configured to be used when performing GNSS measurement; o This C-DRX configuration can be configured beforehand by RRC signalling.

[00109] As briefly mentioned above, Fig. 5 is a representation of GNSS measurement being triggered by the long DRX MAC CE command. It can be seen that eNB 200 earlier configures UE 100 to perform GNSS measurement during long DRX. Accordingly, after receiving the long DRX MAC CE command from the eNB 200, the UE 100 performs (or attempts to perform) GNSS measurement in the off period of C-DRX, i.e., in the time(s) between the active-time(s).

[00110] In some examples, the configuration to use C-DRX OFF periods to perform a GNSS measurement may be configured by RRC signalling.

[00111] In various examples where GNSS measurements are autonomously triggered by a UE, the UE may (additionally or alternatively to any of the configurations described above) be configured to perform the GNSS measurements during the C-DRX OFF periods. In another embodiment a UE may be configured such that it shall perform GNSS measurements in the C-DRX OFF periods only for Long DRX. In other words, even if the UE is capable of performing GNSS measurements in the C-DRX OFF periods, the UE will not do so for Short DRX but instead will perform GNSS measurements only for the case of Long DRX

[00112] In various examples relating to both of the methods of triggering measurement (i.e., network-controlled and autonomous), the time that the UE has to perform the GNSS measurement may be extended to account for the C-DRX. That is, it may take longer for a UE to complete the GNSS measurement if a UE has to utilize C-DRX. In the case where the GNSS measurement configuration is broadcasted there may be multiple durations of how long a UE has to perform a GNSS measurement before declaring the GNSS measurement a failure.

[00113] In one embodiment, there is no bound on how long a UE has (i.e., how much time a UE can spend) to attempt to perform a GNSS measurement, as long as the old GNSS measurement is still valid, if the UE utilizes C-DRX OFF periods to perform GNSS measurement.

[00114] In one embodiment, if the UE is capable of performing a GNSS measurement during C-DRX, the UE does not need to be triggered by the network to perform a GNSS measurement, neither does the UE need to take into account the configurations that trigger UE-autonomous triggering of the GNSS measurement. This means that the UE autonomously performs the GNSS measurement. Thus if the UE indicates (e.g., to the network) the capability of performing GNSS measurement during C-DRX, the UE may not have to perform one or more of the related actions that UEs only capable of performing GNSS measurement have to perform. Some examples of such “related actions” that the UE may not have to perform are as follows: perform GNSS measurement before going to connected mode from idle mode, perform GNSS measurement before re-establishing (performing RRC Connection Re-establishment procedure), perform GNSS measurement before resuming (performing RRC Resume procedure), performing GNSS measurement before a handover; report the GNSS position fix time; report the GNSS validity duration; and / or going to RRC idle mode when the GNSS validity duration is about to time out.

[00115] According to various embodiments of the present disclosure, in order for a GNSS measurement to be performed during the C-DRX OFF time, there may need to be some requirements, conditions or scenarios in which this is performed.

[00116] For example, during a very short DRX period it is unlikely that a UE will be able to tune away from the cellular carrier to perform a GNSS measurement, which is not on the same carrier. This process may take several milliseconds, so if the DRX cycle is too short, then very little measurements may take place or some measurements may not be completed.

[00117] Accordingly, in one embodiment of the present disclosure, the network may configure the UE to determine (or decide) whether to perform the GNSS measurement during the Short DRX or Long DRX period.

[00118] In one embodiment, the UE may determine (or decide) whether to perform the GNSS measurement during the Short DRX or Long DRX period. For example, this decision may be based on the time required to complete the GNSS measurement. In another example, the UE may choose to perform GNSS measurement during the Short or Long DRX considering one or more UE resources. For example, a UE resource may include the energy status (e.g., remaining battery charge, type of power supply etc.) at the UE.

[00119] In one embodiment, the GNSS measurement may only take place during the Long DRX cycle (i.e., the UE may be configured in this way). Alternatively, the GNSS measurement may also take place during the Short DRX cycle (i.e., the UE may be configured to allow this). The ability to perform a GNSS measurement during any of the Short or Long DRX may be signaled as a UE capability. This can for instance be a UE capability to support each Short and Long DRX, or only for Short or Long DRX. In one example, if the UE indicates (e.g., to the network or a base station such as an eNB or gNB) its capability to support the Short DRX, it can be assumed that the Long DRX is also supported.

[00120] In one embodiment, the GNSS measurement during C-DRX may only be performed with DRX parameters with a large enough DRX cycle, or a large enough DRX OFF time. For example, this can be hardcoded, e.g., a threshold or minimum amount of OFF time (e.g., in ms) may be configured in the UE. To give an example, at least 200 ms of OFF time may be hardcoded to be required for any GNSS measurement to start to take place. In another embodiment, the UE may be configured to signal the minimum time needed to perform a GNSS measurement.

[00121] In another embodiment, the UE may be configured to signal to (or request from) the network specific DRX configuration (or DRX parameters) that is preferred in order to perform a GNSS measurement. This can consist of the onDurationTimer, the drx-lnactivityTimer, the short DRX cycle, and / or the Long DRX cycle. In another example, the UE can signal, to the network, specific recommendation on DRX configuration (or DRX parameters) that is preferred by the UE in order to perform a GNSS measurement. In a further example, the network may then provide the UE with GNSS measurement configuration information which takes into account the specific recommendation from the UE, for use by the UE in performing GNSS measurement (e.g., scheduling measurement).

[00122] In one example, the network may provide the UE requested (or recommended) DRX configuration (or DRX parameters) or part of those configuration, or different configuration. In one example, the UE may provide (or request or recommend) a range of values for DRX parameters, and the network may select part or all parameters in this range of values.

[00123] In one embodiment, if the network does not configure the UE preferred DRX configuration, e.g. Short DRX cycle and / or Long DRX cycle, the UE may use DRX configuration provided by RRC or broadcasted in system information.

[00124] Alternatively, the UE may signal the turn around time from DRX active time to perform a GNSS measurement on a GNSS carrier or the opposite direction. This way the network can roughly calculate a suitable DRX configuration.

[00125] When a network schedules a UE, the active-time is expanded in order to further enable scheduling (e.g., enable the receipt of PDCCH or PDSCH). Scheduling the UE too much when a UE is performing a GNSS measurement during C-DRX may have a detrimental impact on GNSS measurements. Thus in various embodiments of the present disclosure, the network will not schedule the UE with too much data to disrupt the GNSS measurement. This can for instance be that the network will not schedule the UE resulting in more than a specified or predetermined number of subframes (e.g., ‘X’ subframes) outside of the onDuration.

[00126] A UE may need to report the GNSS fix time to allow for a network to be able to correctly configure a GNSS measurement. However, the time to perform a GNSS measurement may become ambiguous when performed during C-DRX. For instance, it is likely that it will take a longer time for a GNSS measurement to be performed if it is done during C-DRX compared to doing so when the UE completely tunes away (e.g., tune to a completely different carrier).

[00127] Thus, in some embodiments, the UE is configured to report the full time of performing the GNSS measurement including C-DRX ON time. This can be useful as it will also account for (e.g., include) the time of switching in between C-DRX active time and performing the GNSS measurement (e.g., the reported time includes the time for performing the GNSS measurement and a part of the C-DRX active time between the time (in the active time) when the UE determines to perform GNSS measurement (either by network instruction or autonomously) and the time when the UE switches from the active time to the off period in which the GNSS measurement is performed). In another embodiment, the UE only includes the time that was actually spent to perform the GNSS measurement and the switch time, but not the C-DRX active time period.

[00128] Similarly, in some examples, when a UE reports that a GNSS measurement has occurred, for instance via the GNSS fix time being reported, the UE may indicate that the GNSS measurement took place during C-DRX.

[00129] For instance, when a GNSS measurement occurs during C-DRX, the UE may be be configured to always report it to the network. This is because otherwise there is a risk that the network will not be aware of the measurement having taken place.

[00130] In one embodiment, radio link monitoring (RLM) does not need to be suspended when a GNSS measurement is performed during C-DRX. This is because RLM will be suspended during GNSS measurements being performed (without C-DRX). This is useful as normal procedures may still be maintained.

[00131] In another embodiment, the acquisition of the SIB31 does not need to be cancelled when performing a GNSS measurement. This is because it was agreed that a UE may postpone acquisition of the SIB31, which is vital for a UE NTN to synchronize. By not postponing the SIB31 acquisition, this reduces the risk of the UE performing a radio link failure.

[00132] There now follows a number of non-limiting examples of the present disclosure:

[00133] According to a first example, there is provided a first network entity (e.g., a UE) configured to: determine to perform a GNSS measurement; and perform the GNSS measurement based on information associated with C-DRX for the network entity (e.g., such as the C-DRX itself).

[00134] According to a second example there is provided the first network entity of the first example, wherein the first network entity is configured to perform the GNSS measurement in an off period of the C-DRX or outside of an active time of the C-DRX (e.g., between active times).

[00135] According to a third example, there is provided the first network entity of the first example or the second example, wherein the information associated with C-DRX includes information on an active time of the C-DRX, information on a capability of the UE to perform GNSS measurement in C-DRX, information on a length of the DRX cycle, and / or information on a long DRX cycle or a short DRX cycle.

[00136] According to a fourth example, there is provided the first network entity of any of the first example to the third example, wherein the first network entity is configured to determine to perform the GNSS measurement in response to receiving a transmission from a second network entity (e.g., the network) or autonomously (e.g., based on one or more conditions being fulfilled at the first network entity).

[00137] According to a fifth example, there is provided the first network entity of the fourth example, wherein the transmission indicating to perform GNSS measurement is a MAC CE or an RRC command, or wherein the one or more conditions include the GNSS position of the first network entity being invalid (e.g., determined / detected / identified to be invalid) or about to be invalid based on a validity duration (e.g., gnss-ValidityDuration). For example, regarding the latter, if only a specified amount of time, or less, is left before expiration of the validity duration, it may be determined that the one or more conditions are fulfilled so GNSS measurement is to be autonomously performed by the first network entity.

[00138] According to a sixth example, there is provided the first network entity of the fourth example or the fifth example, wherein the transmission indicating to perform GNSS measurement is a DRX Command MAC CE or a Long DRX Command MAC CE; and wherein the first network entity is configured (e.g., previously configured by the second network entity) to perform GNSS measurement during C-DRX upon receiving the DRX Command MAC CE or the Long DRX Command MAC CE.

[00139] According to a seventh example, there is provided the first network entity of the fourth example, the fifth example or the sixth example, wherein receiving the transmission indicating to perform GNSS measurement triggers C-DRX to start at the first network entity. For example, the first network entity may be configured, upon receiving the transmission, to enter long DRX, enter DRX, or enter a C-DRX configuration specifically configured to be used when performing GNSS measurement.

[00140] According to an eighth example, there is provided the first network entity of any of the first example to the seventh example, wherein the first network entity is configured to transmit the result of the GNSS measurement to a third network entity (e.g., this may be the second network entity referred to above, or a different network entity) and, optionally, transmit (together with or separately to the result) an indication that the GNSS measurement is performed based on the C-DRX.

[00141] According to a ninth example, there is provided the first network entity of the eighth example, wherein the indication indicates that the GNSS measurement was performed during the off period of the C-DRX.

[00142] According to a tenth example, there is provided the first network entity of any of the first example to the ninth example, wherein the first network entity is configured to signal (or transmit), to a fourth network entity (which may be the second network entity or the third network entity, or a different network entity) capability information indicating that the first network entity is capable of performing GNSS measurement based on C-DRX (e.g., in an off-duration of C-DRX).

[00143] Figure 6 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.

[00144] 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 herein.

[00145] Figure 7 is a flow diagram illustrating a method according to various examples of the present disclosure. The method is performed by a UE in a wireless communication network.

[00146] In operation S110, the UE determines to perform a GNSS measurement while the UE is in C-DRX and outside a C-DRX active time.

[00147] In operation S120, the UE transmits, to a first entity in the network, information on a time related to performing the GNSS measurement.

[00148] Figure 8 is a flow diagram illustrating a method according to various examples of the present disclosure. The method is performed by a first entity in a wireless communication network. In various examples, the first entity includes a CN or a base station (e.g. eNB, gNB).

[00149] In operation S210, the first entity receives, from a UE in the network, information on a time related to performance of a GNSS measurement by the UE while in C-DRX and outside a C-DRX active time of the UE. Optionally (not illustrated in Figure 8), the first entity receives, from the UE, an indication that the GNSS measurement was performed during C-DRX or outside the C-DRX active time, when transmitting the information on the time.

[00150] 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.

[00151] 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.

[00152] 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.

[00153] 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.

[00154] While the present disclosure has been shown, illustrated 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.

[00155] 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 5 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 CSI Channel Status Information Mode 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 ML Machine Learning TS Technical Specification MME Mobility Management Entity UDM Unified Data Manager MN Master Node UDR Unified Data Repository MNO Mobile Network Operator UE User Equipment MPTCP MultiPath TCP UL Uplink MT Mobile Termination UM Unacknowledged Mode NAS Non-Access Stratum UP User Plane NB Narrowband UPF User Plane Function NRF Network Repository Function URLLC Ultra-Reliable and Low-Latency NG-RAN Next Generation Radio Access Communication Network URSP UE Route Selection Policy NG-eNB Next Generation eNB XRM Extended Reality and Media NSA Non-Standalone

Claims

1. A user equipment (UE) in a wireless communication network, the UE comprising:a receiver,a transmitter, andat least one processor configured to:determine to perform a global navigation satellite system (GNSS) measurement while the UE is in connected mode discontinuous reception (C-DRX) and outside a C-DRX active time; andtransmit, to a first entity in the network, information on a time related to performing the GNSS measurement.

2. The UE of claim 1, wherein the information comprises:a first time based on a first time period between switching from the C-DRX active time and performing the GNSS measurement, and a second time period for performing the GNSS measurement; ora second time based on the first time period, the second time period, and a third time period between a time when the UE determined to perform the GNSS measurement and the end of the C-DRX active time.

3. The UE of claim 2, wherein the at least one processor is configured to:perform the GNSS measurement after a first C-DRX active time and before a second C-DRX active time;wherein the first time period is between switching from the first C-DRX active time and performing the GNSS measurement; andwherein the third time period is between the time when the UE determined to perform the GNSS measurement and the end of the first C-DRX active time.

4. The UE of claim 2 or claim 3, wherein the first time period is between a time when the C-DRX active period ends and a time when the GNSS measurement is performed.

5. The UE of any previous claim, wherein the at least one processor is configured to: maintain radio link monitoring (RLM).

6. The UE of any previous claim, wherein the at least one processor is configured to: acquire system information.

7. The UE of claim 6, wherein the system information corresponds to system information block (SIB) 31 (SIB31).

8. The UE of any previous claim, wherein the at least one processor is configured to: transmit, to the first entity, an indication that the GNSS measurement was performed during C-DRX or outside the C-DRX active time, when transmitting the information on the time.

9. The UE of any of claims 1 to 7, wherein the at least one processor is configured to: receive, from the first entity during the first C-DRX active time, a trigger to performthe GNSS measurement outside of the C-DRX active time.

10. The UE of claim 9, wherein the trigger is one of:a command to perform the GNSS measurement; ora DRX command medium access control (MAC) control element (CE) or a long DRX command MAC CE.

11. The UE of claim 10, wherein the at least one processor is configured to: in response to receiving the command, enter C-DRX or enter C-DRX based on a C-DRX configuration configured to be used when performing the GNSS measurement.

12. The UE of any of claims 9 to 11, wherein the trigger is received via radio resource control (RRC), MAC CE or downlink control information (DCI) signalling.

13. A first entity in a in a wireless communication network, the first entity comprising: a transmitter, a receiver, andat least one processor configured to:receive, from a user equipment (UE) in the network, information on a time related to performance of a global navigation satellite system (GNSS) measurement by the UE while in connected mode discontinuous reception (C-DRX) and outside a C-DRX active time of the UE.

14. The first entity of claim 13, wherein the information comprises:a first time based on a first time period between switching from the C-DRX active time and performing the GNSS measurement, and a second time period for performing the GNSS measurement; ora second time based on the first time period, the second time period, and a third time period between a time when the UE determined to perform the GNSS measurement and the end of the C-DRX active time.

15. The first entity of claim 13 or claim 14, wherein the at least one processor isconfigured to:receive, from the UE, an indication that the GNSS measurement was performed during C-DRX or outside the C-DRX active time, when transmitting the information on the time.

16. The first entity of claim 13 or claim 14, wherein the at least one processor is configured to:transmit, to the UE, a trigger to perform the GNSS measurement outside of the C-DRX active time.

17. The first entity of claim 16, wherein the trigger is one of:a command to perform the GNSS measurement; ora DRX command medium access control (MAC) control element (CE) or a long DRX command MAC CE.

18. The first entity of claim 16 or claim 17, wherein the trigger is transmitted via radio resource control (RRC), MAC CE or downlink control information (DCI) signalling.

19. The first entity of any of claims 13 to 18, wherein the first entity includes a core network (CN) or a base station.

20. A method of a user equipment (UE) in a wireless communication network, the method comprising:determining to perform a global navigation satellite system (GNSS) measurement while the UE is in connected mode discontinuous reception (C-DRX) and outside a C-DRX active time; andtransmitting, to a first entity in the network, information on a time related to performing the GNSS measurement.

21. The method of claim 20, wherein the information comprises:a first time based on a first time period between switching from the C-DRX active time and performing the GNSS measurement, and a second time period for performing the GNSS measurement; ora second time based on the first time period, the second time period, and a third time period between a time when the UE determined to perform the GNSS measurement and the end of the C-DRX active time.

22. A method of a first entity in a in a wireless communication network, the method comprising:receiving, from a user equipment (UE) in the network, information on a time related to performance of a global navigation satellite system (GNSS) measurement by the UE while in connected mode discontinuous reception (C-DRX) and outside a C-DRX active time of the UE.

23. The method of claim 22, wherein the information comprises:a first time based on a first time period between switching from the C-DRX active time and performing the GNSS measurement, and a second time period for performing the GNSS measurement; ora second time based on the first time period, the second time period, and a third time period between a time when the UE determined to perform the GNSS measurement and the end of the C-DRX active time.

24. The method of claim 22 or claim 3, further comprising:receiving, from the UE, an indication that the GNSS measurement was performed during C-DRX or outside the C-DRX active time, when transmitting the information on the time.

25. 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 claims 22 to 24.37