EP4649774A1

EP4649774A1 - Methods for performing gnss position fix and reporting gnss validity duration using the c-drx

Info

Publication number: EP4649774A1
Application number: EP24713838.1A
Authority: EP
Inventors: Ming-Hung Tao; Chih-Hsiang Wu
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2023-02-16
Filing date: 2024-02-16
Publication date: 2025-11-19
Also published as: WO2024173884A1; CN120712891A

Abstract

Methods for UEs and NEs such as base stations communicating via satellite (103, 105) use a c-DRX mechanism to avoid the UE frequently switching between connected and idle mode due to limited validity of a GNSS position fix procedure. The UE (102) and the NE (104) maintain (822, 824) the connection after the UE position obtained using the GNSS position fix procedure is no longer valid during a c-DRX OFF period.

Description

METHODS FOR PERFORMING GNSS POSITION FIX AND REPORTING GNSS VALIDITY DURATION USING THE C-DRX

FIELD OF THE DISCLOSURE

[0001] This document generally describes methods and devices operating in wireless communication systems such as (but not limited to) the ones described in 3^rd Generation Partnership Project (3GPP) technical specifications, known as fifth generation (5G) communication systems. More particularly, embodiments relate to enabling a user equipment (UE) that communicates via non-terrestrial network (NTN) radio access networks (RANs) to perform a Global Navigation Satellite System (GNSS) position fix procedure and report using a connected mode discontinuous reception (c- DRX) cycle.

BACKGROUND

[0002] This background description is provided for the purpose of generally presenting the technical context and problems. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that do not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0003] The 5G technology provides a unified framework for wireless communications including enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine type communication (mMTC).

Augmenting terrestrial networks, 3GPP has expanded communications to non-terrestrial networks (NTNs) with 5G new radio (NR) technologies, or with the Long-Term-Evolution (LTE) technologies tailored for the Narrowband Internet-of-Thing (NB-loT) or the enhanced Machine Type Communication (eMTC) scenarios. In an NTN, a radio frequency transceiver is mounted on a satellite, an uncrewed aircraft system (UAS, e.g., a drone, a balloon, a plane) or another suitable apparatus. For simplicity, such apparatuses are referred to as satellites. In addition to satellites, an NTN can include one or more satellite-gateways (simpler called “sat-gateways”) that connect the NTN to a public data network, feeder links between sat-gateways and satellites, service links between satellites, and inter-satellite links when satellites form constellations.

[0004] A satellite can belong to one of several types based on altitude, orbit, and beam footprint size. The types include Low-Earth Orbit (LEO) satellite, Medium-Earth Orbit (MEO) satellite, Geostationary Earth Orbit (GEO) satellite, UAS platform (including High Altitude Platform Station, HAPS), and High Elliptical Orbit (HEO) satellite. GEO satellites are also known as the Geosynchronous Orbit (GSO) satellites, and LEO/MEO satellites are also known as the non-GSO (NGSO) satellites. A GSO satellite can communicate with one or several sat-gateways deployed over a satellite targeted coverage area (e.g., a region or even a continent). A non-GSO satellite at different times can communicate with one or several serving sat-gateways. An NTN is designed to ensure service and feeder link continuity between successive serving sat-gateways, with sufficient overlapping serving time to proceed with mobility anchoring and handover.

[0005] The NB-loT and eMTC technologies are expected to be particularly suitable for loT devices operating in remote areas with limited or no terrestrial connectivity. Such loT devices can be used in a variety of industries including, for example: transportation (maritime, road, rail, air) and logistics; solar, oil, and gas harvesting; utilities; farming; environmental monitoring; and mining. For remote loT connectivity, satellite connectivity provides coverage beyond terrestrial deployments. Satellite NB- loT or eMTC is defined in a complementary manner to terrestrial deployments. [0006] When connected to a wireless network, a UE applies a UE-specific timing advance (TA) to an uplink (UL) transmission, so a base station receives the uplink transmission within a desired (scheduled) time window. The UE calculates this TA based on the distance between the UE and the base station. When a satellite forms part of the base station, however, this distance may change rapidly due to the movement of the UE and also the movement of the satellite.

[0007] The UE calculates the distance using the UE’s position assessed based on signals the UE receives from Global Navigation Satellite System (GNSS) (procedure known as a GNSS position fix) and satellite’s location inferred from satellite ephemeris information, which is received in a dedicated system information block, SIB19. The UE position obtained during the GNSS position fix procedure is associated with a certain GNSS validity duration. If the UE is unable to perform or to report the GNSS position fix within the GNSS validity duration, the UE switches to an idle state and may later reconnect after successfully performing and reporting the GNSS position fix. A network entity (NE) assumes the UE is in an idle state if the NE did not receive the GNSS position report within the GNSS validity duration.

[0008] This frequent switching between the connected state and the idle state causes significant UE power consumption, which is undesirable, particularly if the UE is a narrowband internet of things (NB-loT) device that is not able to communicate with the satellite and perform the GNSS position fix simultaneously. Nowadays, the network configures measurement gaps for NB-loT devices to perform the GNSS position fix. However, frequent reconfiguring needed for the measurement gap adds to power consumption.

SUMMARY

[0009] Generally speaking, the techniques described below allow a UE to conduct the GNSS position fix procedure during the inactive reception periods occurring when operating in a connected mode discontinuous reception (c-DRX) mode.

[0010] UEs according to various embodiments use the discontinuous reception mechanism to decrease UE power consumption while performing and reporting the GNSS position fix. An NE (e.g., a base station) directs a UE connected via an NTN to switch to c-DRX during which the UE alternates inactive reception periods (i.e. , a c-DRX OFF period of a C-DRX cycle, with the UE’s receiver being off and therefore unable to receive signals) and active reception periods in a c-DRX ON period with the UE’s receiver back on and thus able to receive signals. The UE then performs the GNSS position fix procedure during a c-DRX OFF period and does not switch to the idle state as long as this c-DRX OFF lasts, even if the GNSS validity duration has expired. At the beginning of the immediately following c-DRX ON period of the c-DRX cycle, the UE may continue refraining from switching to the idle state during a GNSS validity report time interval, as long as the UE reports the successful completion of the GNSS position fix. The reporting may alternatively occur during the c-DRX OFF period. Reporting the successful completion of the GNSS position fix may include indicating a remaining GNSS validity duration value. If the GNSS validity period lasts more than one c-DRX cycle, the UE may perform the GNSS position fix during the last c-DRX OFF period of a c-DRX cycle prior to the GNSS validity period’s end or (when such a mechanism is activated) during the penultimate c-DRX OFF period prior to the GNSS validity period’s end.

[0011] When failing to successfully complete the GNSS position fix or to report it before the end of the GNSS validity report time interval, the UE switches to the idle state. When the NE does not receive a report indicating a successful completion of the GNSS position fix by the end of the GNSS validity period, the c-DRX OFF period of the c-DRX cycle and, optionally also the GNSS validity report time interval, the NE considers the UE to have switched to the idle state.

[0012] UEs and NEs each having a processor and a transceiver (e.g., a transmitter and a receiver) are configured to perform methods according to these techniques.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments.

[0014] Fig. 1 is a block diagram of a wireless communication system including a UE and an NE able to perform methods for reporting GNSS validity within a c-DRX mechanism according to various embodiments.

[0015] Fig. 2 illustrates an NTN arrangement with transparent payload implementation.

[0016] Fig. 3 represents an LTE user plane protocol stack usable for communications exchanged in the NTN arrangement illustrated in Fig. 2.

[0017] Fig. 4 represents an LTE control plane protocol stack usable for communications exchanged in the NTN arrangement illustrated in Fig. 2. [0018] Fig. 5A illustrates a first scenario in which a conventional UE switches from a connected state and an idle state when the GNSS validity duration expires.

[0019] Fig. 5B illustrates a second scenario in which the conventional UE performs a GNSS position fix procedure in a configured measurement gap.

[0020] Fig. 6A illustrates a first scenario in which a UE performs a GNSS position fix operation during a c-DRX OFF period according to an embodiment.

[0021] Fig. 6B illustrates a second scenario in which a UE is not able to conduct the GNSS position fix procedure or is not able to obtain its GNSS position while conducting the GNSS position fix during a first c-DRX OFF period according to an embodiment.

[0022] Fig. 6C illustrates a third scenario in which a UE is able to conduct a GNSS position fix successfully, but the UE is not able to report its GNSS validity duration to the BS before the gnss-validityReport timer expires according to an embodiment.

[0023] Figs. 7A - 7C are timelines illustrating scenarios in which a UE determines when to conduct a GNSS position fix procedure when the GNSS validity duration lasts for multiple c-DRX cycles according to various embodiments.

[0024] Fig. 8 is a messaging diagram illustrating UE and NE behavior when the UE conducts the GNSS position fix during a c-DRX OFF period and remains in connected state after the GNSS validity timer expires, according to an embodiment.

[0025] Fig. 9 is a messaging diagram illustrating UE and NE behavior when the UE fails to conduct the GNSS position fix during a c-DRX OFF period, and hence transitions to the idle state at the beginning of the next c-DRX ON period, according to an embodiment.

[0026] Fig. 10 is a messaging diagram illustrating UE and NE behavior when a UE fails to report the GNSS validity duration during the c-DRX ON period following the expiry of the GNSS validity duration, according to an embodiment.

[0027] Fig. 11 is a messaging diagram illustrating UE and NE behavior when the GNSS validity lasts more than one c-DRX cycle, and the UE conducts a GNSS position fix procedure one c-DRX cycle before to the GNSS validity duration expires, based on a first value in an early GNSS position fix indication, according to an embodiment. [0028] Fig. 12 is a messaging diagram illustrating UE and NE behavior when the GNSS validity lasts more than one c-DRX cycle, and a UE conducts the GNSS position fix after the GNSS validity duration expires in a c-DRX OFF period, based on a second value in an early GNSS position fix indication, according to an embodiment.

[0029] Fig. 13 is a flow diagram of a UE method in which the UE conducts a GNSS position fix procedure after the GNSS validity duration expires without transitioning to the idle state, by relying on the c-DRX mechanism according to an embodiment.

[0030] Fig. 14 illustrates a flow diagram of a UE method in which a UE conducts a GNSS position fix procedure in a c-DRX OFF period, based on an early GNSS position fix indication according to an embodiment.

[0031] Fig. 15 illustrates a flow diagram of a UE method in which the UE conducts a GNSS position fix procedure during a c-DRX OFF period when the next c-DRX ON period extends beyond the GNSS validity duration according to an embodiment.

[0032] Fig. 16 illustrates a flow diagram of a UE method during which the UE conducts a GNSS position fix procedure during a c-DRX OFF period prior to the GNSS validity expiring during a c-DRX ON period according to an embodiment.

[0033] Fig. 17 illustrates a flow diagram of an NE method for determining the RRC state for the UE configured with a c-DRX configuration, upon the expiry of UE’s GNSS validity duration according to an embodiment.

DETAILED DESCRIPTION OF THE DRAWINGS

[0034] Methods and devices described in this section embody techniques related to enabling a UE that communicates via an NTN RAN to perform to perform GNSS position fix procedures during inactive reception periods of c-DRX cycles, and then to report corresponding GNSS validity duration during active periods of the c-DRX cycles. The embodiment descriptions in this section refer to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The detailed descriptions do not preclude other embodiments within the scope of the appended claims (for example, applying one or more methods to another radio access technology than 5G). The embodiments are not limited to the described configurations but may be extended to other arrangements.

[0035] Referring first to Fig. 1 , a wireless communication system 100 includes a UE 102, a base station (BS) 104, a BS 106, and a core network (CN) node hosting the CN 110. The BSs 104 and 106 are RAN nodes that operate in a RAN 105 connected to the CN 110. The CN 110 may be an evolved packet core (EPC) 111 , a fifth generation (5G) core (5GC) 116 or a CN implementing a different technology such as (but not limited to) a sixth generation (6G) core.

[0036] The BS 104 covers a cell 124, and the BS 106 covers a cell 126. If the BS 104 is a gNB, the cell 124 is an NR cell. If the BS 104 is an ng-eNB or eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if the BS 106 is a gNB, the cell 126 is an NR cell, and if the BS 106 is an ng-eNB or eNB, the cell 126 is an E-UTRA cell. The cells 124 and 126 can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. As illustrated in Fig. 1 , cell 124 is an NTN cell having an oval footprint. That is, communications to/from BS 104 travel from/to the UE 104 via satellite 103. In contrast cell 124 is a terrestrial network cell. It should be understood that although Fig. 1 shows different types of cells, this is merely an example, the type and number of cells should not be construed as limiting. In general, the RAN 105 can include any number of BSs, and each of the BSs can cover one, two, three, or any other suitable number of cells. The UE 102 supports a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the BSs 104 and 106. Each of the BSs 104 and 106 may connect to the CN 110 via an S1 or NG interface. The BSs 104 and 106 may be interconnected via an X2 or Xn interface.

[0037] Among other components, the EPC 111 may include a Mobility Management Entity (MME) 112, a Serving Gateway (SGW) 114, and a Packet Data Network Gateway (PGW) 116. The MME 112 is configured to manage authentication, registration, paging, and other related functions. The SGW 112 in general is configured to transfer userplane packets related to audio calls, video calls, Internet traffic, etc. The PGW 116 provides connectivity from a UE to one or more external packet data networks, e.g., an Internet network and/or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 116 includes an Access and Mobility Management Function (AMF) 117, a Session Management Function (SMF) 118 and a User Plane Function (UPF) 119. Generally speaking, the AMF 117 is configured to manage authentication, registration, paging, and other related functions, the SMF 117 is configured to manage PDU sessions, and the UPF 119 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc. The EPC 111 may include other and more modules than the ones illustrated in Fig. 1 , and the 5GC 116 may include other and more functions than the ones illustrated in Fig. 1. The EPC modules and/or 5GC functions are hosted by one or more wireless and/or wired communication devices including processors.

[0038] As illustrated in Fig. 1 , the base station 104 supports a cell 124, and the base station 106 supports a cell 126. The cells 124 and 126 can partially overlap, so that the UE 102 can select, reselect, or hand over from one of the cells 124 and 126 to the other. To directly exchange messages or information, the base station 104 and base station 106 can support an X2 or Xn interface. In general, the CN 110 can connect to any suitable number of base stations supporting NR cells and/or EUTRA cells.

[0039] As discussed in detail below, the UE 102 and/or NEs of the RAN 105 may use various methods described in this section when the radio connection between the UE 102 and the RAN 105 is suspended (e.g., when the UE 102 operates in an inactive or idle state of the protocol for controlling radio resources between the UE 102 and the RAN 105). For clarity, the examples below refer to the RRCJNACTIVE or RRCJDLE state of the RRC protocol.

[0040] The UE 102 is equipped with processing hardware that includes one or more general-purpose processors and/or special-purpose processing units 121 , and a non- transitory computer-readable memory 120 storing device data and/or machine-readable instructions executable on the processor 121. The processor 121 prepares uplink (UL) data that the UE 102 transmits in the UL direction and/or processes downlink (DL) data the UE receives in the DL direction. The UE processing hardware also includes a transmitter 122 configured to transmit UL data and a receiver 123 configured to receive data in the uplink direction or other hardware that enables UE’s wireless communication and may be collectively named “transceiver.”

[0041] The BS 104 is equipped with processing hardware that includes one or more general-purpose processors or special-purpose processing units 127 and a non- transitory computer-readable memory 130 storing device data and/or instructions that the processor 127 may execute. The BS 104 includes a processor 127 to prepare DL data that the BS 104 transmits in the DL direction, and/or to process UL data the BS 104 receives in the UL direction. The processing hardware may also include a transmitter 128 configured to transmit DL data and a receiver 129 configured to receive UL data (or other equivalent hardware collectively named “transceiver”). The BS 106 can include generally similar components.

[0042] Fig. 2 illustrates an NTN arrangement representing a certain type of NTN deployment referred to as a transparent payload architecture, which involves a satellite gateway 207 and a “transparent” satellite 103. The satellite 103 implements a frequency conversion and an RF amplifier in both the UL and DL directions. The satellite operates in a manner similar to that of an analogue RF repeater. As a result, the satellite 103 repeats signals received via a feeder link (between the NTN gateway 207 and the satellite 103) to the service link (between the satellite 103 and the UE102) in the DL direction and vice versa in the UL direction. The Satellite Radio Interface (SRI) on the feeder link is the Uu, and the NTN gateway 207 supports all necessary functions to forward the signals of the Uu interface. The NTN gateway 207 may be collocated with the BS 104 or may be connected to the BS 104 via a wired link. The BS 104 may be connected to more than one NTN gateway. Different transparent satellites may be connected to the same BS on the ground, via the same NTN gateway, or via different NTN gateways.

[0043] Although the transparent payload architecture illustrated in Fig. 2 is the current focus of the 3GPP development, the regenerative payload architecture that installs the eNB functions on the satellite is a foreseeable future NTN deployment. In such an architecture, the Uu only exists between the satellite and the UE. However, the methods described in this section are usable for the transparent payload architecture as well as the regenerative payload architecture.

[0044] The NTN user plane protocol stack (of the transparent payload architecture) involving the UE 102, the satellite 103, the NTN gateway 207, the eNB 104, and the SGW 114 is illustrated in Fig. 3. Although Fig. 3 shows an LTE protocol stack, the NTN- related aspects apply to 5G as well with the RAN 104 being a gNB and the SGW being replaced by and UPF. The diagram of the NTN user plane protocol stack is similar to that of the terrestrial network (TN), with the addition of two new nodes, the satellite 103 and the NTN gateway 207, being placed in the middle of the Uu interface.

[0045] A physical layer (PHY) of EUTRA provides transport channels to the EUTRA MAC sublayer, which in turn provides logical channels to the EUTRA RLC sublayer. The EUTRA RLC sublayer then provides RLC channels to an EUTRA PDCP sublayer and, in some cases, to an NR PDCP sublayer. The PDCP sublayer in turn can provide data transfer services to Service Data Adaptation Protocol or a radio resource control (RRC) sublayer (not shown). The UE 102, in some implementations, supports both the EUTRA and the NR stack, thereby supporting a handover between EUTRA and NR BSs and/or a dual connectivity over EUTRA and NR interfaces. The EUTRA PDCP sublayer and the NR PDCP sublayers receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.” [0046] Similarly, the NTN control plane protocol stack illustrated in Fig. 4 is also similar to that of the TN. Although Fig. 4 shows an LTE protocol stack, the NTN-related aspects apply to a 5G protocol as well with the RAN 104 being a gNB and the MME being replaced by and AMF. same for FIG. 4 (gNB, SGC AMF) On the control plane, the EUTRA PDCP sublayer and the NR PDCP sublayer can provide signaling radio bearers or RRC sublayer to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer and the NR PDCP sublayer can provide Data Radio Bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer can be SDAP PDlls, Internet Protocol (IP) packets or Ethernet packets.

[0047] In terms of the satellite moving pattern, there are three types of service links that are supported in NTN:

• Earth-fixed: provisioned by beam(s) continuously covering the same geographical areas all the time (e.g., the case of GEO/GSO satellites)

• Quasi-Earth-fixed: provisioned by beam(s) covering one geographic area for a limited period and a different geographic area during another period (e.g., the case of LEO/MEO satellites capable of using steerable beams)

• Earth-moving: provisioned by beam(s) whose coverage area slides over the Earth surface (e.g., the case of LEO/MEO satellites using fixed or non-steerable beams).

[0048] With LEO/MEO satellites, the eNB can provide either quasi-Earth-fixed cell coverage or Earth-moving cell coverage. With GEO satellites, the eNB can provide Earth fixed cell coverage.

[0049] Whenever transmitting any signal/data to a BS in the UL direction, each UE has to apply a UE-specific timing advance (TA) that is calculated based on the distance between the UE and the connected satellite, so that all the UL transmissions can arrive precisely at desired timing scheduled by the BS. Hence every UE needs to keep tracking its own position as well as the position of the connected satellite. To avoid interfering with other UEs or the BS, a UE is not allowed to perform any UL transmission without a valid UE position or a valid satellite position information. As a UE position may become invalid after a certain period of time (depending on UE’s mobility), a UE may need to periodically acquire its GNSS position from the GNSS module in order to continue performing the UL transmissions to the BS (as described, for example, in 3GPP TS 36.331 ). The UE may obtain its valid GNSS position before connecting to a NTN cell, and moves to the idle state if the GNSS position is outdated. As previously mentioned, a NB-loT device (UE) is not able to perform simultaneously radio communication with the BS and a GNSS position fix procedure. [0050] Figs. 5A and 5B are timelines (times flowing from left to right) of scenarios illustrating a conventional (e.g., Rel 17) UE’s behavior related to GNSS validity. In these figures, action labels are underlined while time interval labels are not. Fig. 5A illustrates a conventional UE switching between the RRC_connected and the RRCJdle states when a GNSS validity duration expires. In this example, the UE conducts 504 a GNSS position fix procedure yielding the UE’s GNSS position associated with a GNSS validity duration 560. The GNSS validity duration 560 indicates how long (i.e., from to to ti in Fig. 5A) the GNSS position information remains valid. The UE then performs 511 an RRC Connection Establishment procedure with the BS. During the RRC Connection Establishment procedure, the UE reports to the BS the remaining GNSS validity duration. The UE then remains in the connected state until the GNSS validity duration expires (ti in this example). Upon the expiry of the GNSS validity duration, the UE moves into the idle state and the BS also transitions the UE to the idle state at the same time, since both UE and BS have the same understanding with regard to when UE’s GNSS validity duration expires. Later, in order to be able to communicate with the BS, the UE conducts 526 another GNSS position fix procedure to obtain its GNSS position before establishing 532 the connection with the BS. This conventional UE behavior illustrated in Fig. 5A switches frequently between the idle and connected states. While such switching is adequate for small amounts of data with long intervals between completed transmissions, if the data exchange between the UE and the BS takes a longer time to conclude, repeated switching between RRC states causes considerable signaling overheads and UE power consumption.

[0051] 3GPP has recently adopted some techniques to alleviate the problem caused by UE’s switching between RRC states related to conducting the GNSS position fix and updating the GNSS validity duration. Fig. 5B illustrates one of these techniques. The UE is configured with a measurement gap 561 , at the time when the UE needs to conduct another GNSS position fix procedure (i.e., close to but before the end of the first GNSS validity duration 560). The UE and the BS do not exchange data during the measurement gaps. Upon conducting 526 the GNSS position fix procedure during measurement gap 561 and reporting 532 to the BS a remaining GNSS validity duration, the UE remains in the connected state during the second GNSS validity duration 564 (at the end of which another GNSS position fix procedure may be conducted during another measurement gap 565). Hence, the overhead signaling and the power consumption due to switching RRC states are avoided. However, substantial signaling overhead persists because the network has to configure a measurement gap 561 , 565 for the UE once per GNSS validity duration.

[0052] Some embodiments now described using existing mechanisms such as c- DRX, which temporarily put the UE in an inactive state, to provide an improved solution to the above-described problems related to the UE conducting a GNSS position fix. The UE conducting the GNSS position fix procedure during a c-DRX OFF period eliminates the need to configure measurement gaps because the UE does not receive data during the c-DRX OFF period.

[0053] Figs. 6A, 6B, and 6C are timelines of scenarios illustrating a UE’s behavior related to GNSS validity using a c-DRX mechanism according to some embodiments. Fig. 6A illustrates the UE conducting the GNSS position fix procedure during a c-DRX OFF period of a C-DRX cycle (also called “c-DRX OFF period”). In these scenarios, the UE first conducts 604 a GNSS position fix procedure (for obtaining the GNSS position and GNSS validity duration 660 foto ti), and then establishes 611 an RRC connection with a BS (initiated, for example, by sending to the BS, an RRC Connection Setup Request message that includes a remaining GNSS validity duration reported by the UE). The UE then receives 616 from the BS an RRC Connection Reconfiguration message including a c-DRX configuration. Based on the c-DRX configuration, the UE starts a drx-inactivity timer at t2 and enters a c-DRX OFF period upon the expiry of the drx-inactivity timer (i.e. , at ts, a drx nactivity time interval 661 after receiving the c-DRX configuration), where the c-DRX OFF period can belong to either a short DRX cycle or a long DRX cycle. Because the GNSS validity duration expires (at ti) during the c-DRX OFF period, the UE does not have to transition to the idle state (as does a conventional UE). As long as the UE can complete a GNSS position fix procedure 626 before the start t4 of the next c-DRX ON period, the UE does not have to switch to idle state. At the beginning t4 of the next c-DRX ON period (which can belong to either a short DRX cycle or a long DRX cycle), the UE starts another timer (“gnss-validity Report") measuring a GNSS validity report time interval 662. Before this other timer expires at ts, the UE has to report its remaining GNSS validity duration to the BS (otherwise the UE would have had to transition to the idle state). Further in Fig. 6A, as the UE reports 632 its GNSS validity duration to the BS before ts, the UE remains in the connected state during the c- DRX ON period. After the c-DRX ON period, the second GNSS validity duration 664 expires during the next c-DRX OFF period, and the UE conducts again a GNSS position fix procedure before the start of the next c-DRX ON period.

[0054] Fig. 6B illustrates a scenario similar to the one illustrated in Fig. 6A, with the difference that, during UE’s c-DRX OFF period, the UE in Fig. 6B is not able to conduct the GNSS position fix procedure (626 merely indicates where the procedure could have been performed) or is not able to obtain its GNSS position while conducting the GNSS position fix procedure. Therefore, although the UE in Fig. 6B does not need to transition into the idle state when the GNSS validity duration expires (since the GNSS validity duration expires during the c-DRX OFF period), the UE transitions 629 to the idle state at the beginning of the next c-DRX ON period (i.e. , at t4).

[0055] Fig. 6C illustrates yet another scenario similar to the one in Fig. 6A, with the difference that although the UE in Fig. 60 successfully conducts 626 the GNSS position fix procedure at t4, it is not able to report its GNSS validity duration to the BS before the gnss-validityReport timer expires at ts. As a result, upon the expiry of the gnss- validityReport timer, the UE transitions 629 to the idle state at ts. The BS also releases the UE into the idle state at the same time (i.e., at ts).

[0056] In summary, the UE behavior illustrated in Figs. 6A - 6C are as follows. The UE does not transition into the idle state upon the expiry of GNSS validity duration, if the UE is in a c-DRX OFF period. The UE starts a (gnss-validityReport) timer upon entering into the c-DRX ON period, if the GNSS validity duration has been reset (after successfully conducting the GNSS position fix procedure) during the previous c-DRX OFF period. The UE then reports to BS the remaining GNSS validity duration before the expiry of the (gnss-validityReport) timer. The UE transitions into the idle state if unable to report the remaining GNSS validity duration to the BS before the expiry of the (gnss-validityReport) timer. Meanwhile, the BS (1 ) does not transition the UE into an idle state upon the expiry of UE’s GNSS validity duration, if the UE is in a c-DRX OFF period, (2) starts another (gnss-validityReport) timer when UE’s c-DRX ON period begins, after UE’s GNSS validity timer has expired, and (3) releases the UE context and transitions the UE to the idle state upon the expiry of the gnss-validityReport timer. [0057] Figs. 7A - 7C are timelines illustrating scenarios in which a UE determines when to conduct a GNSS position fix procedure when the GNSS validity duration 660 lasts for multiple c-DRX cycles according to various embodiments. Details shown in Figs. 6A - 6C are not repeated in Figs. 7A - 7C with the following understandings. The initial position fix procedure 704 is analogous to position fix procedure 604, and the subsequent position fix procedure 726 is analogous to position fix procedure 626. Any of the scenarios of Figs. 6A - 6C occurring after a successful or unsuccessful position fix 626 may occur after a successful or unsuccessful position fix 726 of any of Figs. 7A - 7C.

[0058] In Fig. 7A, the GNSS validity duration 660 expires during the c-DRX OFF period of the 5^th c-DRX cycle after successfully conducting 704 a GNSS position fix procedure. Because the GNSS validity duration in Fig. 7A expires in a c-DRX OFF period, the UE may perform similarly to UE’s behavior illustrated in Fig. 6A: the UE conducts 726 the GSNN position before the next c-DRX ON period (i.e. , the c-DRX ON period of the 6^th c-DRX cycle).

[0059] In a different scenario, the GNSS validity duration in Fig. 7B expires in a c- DRX ON period, and hence the UE should conduct the GNSS position fix procedure 726 during the c-DRX OFF period before that c-DRX ON period (otherwise the UE transitions 729 to the idle state during the c-DRX ON period when the GNSS validity duration expires).

[0060] Fig. 7C illustrates an alternative UE behavior to the behavior illustrated in Fig. 7A. Here, the UE conducts the GNSS position fix procedure one c-DRX cycle earlier than the c-DRX cycle where the GNSS validity duration expires. That is, in Fig. 7C, the UE conducts 726 the GNSS position fix procedure during the c-DRX OFF period of the 4^th c-DRX cycle, given that the GNSS validity duration 660 expires in the c-DRX OFF period of the 5^th c-DRX cycle.

[0061] If the UE uses the approach illustrated in Fig. 7A, the BS has to make sure the c-DRX ON period of the 5^th c-DRX cycle does not extend beyond the GNSS validity duration, for example by not sending any DL data to the UE, or by sending a DRX command MAC CE to the UE, before or upon the expiry of the GNSS validity duration. On the other hand, if the UE uses the approach illustrated in Fig. 7C, the BS does not need to tightly control how long a c-DRX ON period can be extended.

[0062] Figs. 8-12 are messaging diagrams illustrating UE and NE behavior according to various embodiments and different scenarios. Similar events in Figs. 8-12 are labeled with the similar reference numbers, with differences discussed below where appropriate. For example, event 816 is similar to event 1116/1216, event 818 is similar to event 1118A/B/C, and event 828 is similar to event 1128.

[0063] Fig. 8 is a messaging diagram 800 illustrating a scenario (similar to the timeline in Fig. 6A) in which a UE conducts a GNSS position fix and remains in the connected state by utilizing the c-DRX OFF periods. The UE 102 is initially 802 in the idle state and camps on the NTN cell 124 managed by the BS 104, via the service link provided by the satellite 103. The UE 102 then conducts 804 a GNSS position fix procedure by measuring/receiving the signal emitted by GNSS satellites (e.g., GNSS satellite 308). A UE may conduct 804 the GNSS position fix procedure upon receiving a demand from its upper layer(s) to establish the connection with the BS 104. The UE starts the GNSS validity duration timer (i.e. , gnss-validityDuration) upon successfully conducting the GNSS position fix procedure. The UE 102 then transmits 806 an RRC Connection Request message to the BS 104 for establishing the connection with the BS 104 via satellite 103. In response to the RRC Connection Request message, the BS 104 transmits 808 an RRC Connection Setup message to the UE 102, for establishing an SRB1 (Signaling Radio Bearer 1 ). In response to receiving the RRC Connection Setup message, the UE 102 transmits 810 an RRC Connection Setup Complete message to the BS, and then transitions 812 to the connected state. The RRC Connection Setup Complete message includes the remaining gnss-validityDuration. The events 806, 808, and 810 are collectively referred to in Figs. 8 and 9-12 as a procedure for “RRC connection establishment and GNSS validity reporting” 811 .

[0064] The BS 104 determines 814 a c-DRX configuration for the UE 102, and then transmits 816 an RRC Reconfiguration message including the determined c-DRX configuration to the UE 102. The c-DRX configuration may be determined based on the remaining gnss-validityDuration reported by the UE 102. The c-DRX configuration may include: (1 ) a duration of the ON period (for both the short and long c-DRX cycle), (2) a c-DRX inactivity timer indicating a time interval for the UE to remain connected (i.e., connection is ON in an c-DRX ON period) after the reception of messages on a physical downlink control channel (PDCCH), (3) a long c-DRX cycle value, and (4) a short c-DRX cycle value. The c-DRX configuration may indicate a sequence of short and long c- DRX cycles. For example, three short c-DRX cycles may be followed by two long c- DRX cycles. This means that the UE is configured to switch from short DRX cycle to long DRX cycle if no data activity takes place for three contiguous short DRX cycles. The duration of the ON period of the short DRX cycles may be the same as for long DRX cycles.

[0065] To comply with the c-DRX configuration, upon the expiry of the c-DRX inactivity timer, the UE 102 starts 818 a c-DRX OFF period during which UE’s receiver is OFF so the UE does not monitor the PDCCH. At a later time, the gnss- validityDuration timers expire 820 both on the UE side and on the BS side. Different from conventional UE behavior, the UE 102 does not transition to the idle state but instead remains 822 in the connected state. Similarly, the BS 104 does not release the UE context, but maintains 824 the connection with the UE 102 upon the expiry of the gnss-validityDuration timer during a c-DRX OFF period.

[0066] The UE 102 then conducts 826 a GNSS position fix procedure during the remaining c-DRX OFF period (after the GNSS validity duration ended in this scenario) and restarts the gnss-validityDuration timer when the GNSS position fix procedure is successful. Before conducting the GNSS position fix procedure during the c-DRX OFF period, UE 102 may need to make sure the GNSS position fix procedure can be completed before the beginning of the next c-DRX ON period. In other words, some scenarios may start the GNSS position fix 826 prior to the gnss-validityDuration timer expiration 820 (e.g., if there is not enough time between the gnss-validityDuration timer expiration 820 and the c-DRX ON start time 828 to conduct a complete GNSS position fix procedure).

[0067] When the c-DRX OFF period ends and the c-DRX ON period begins, the UE 102 starts 828 a gnss-validityReport timer and starts monitoring PDCCH. The BS 104 also starts 830 a similar gnss-validityReport timer for the UE 102 (triggered by both the expiry of UE’s gnss-validityDuration timer and the starting of the c-DRX ON period). Later but before the gnss-validityReport timer expires, the UE 102 obtains an UL transmission grant and transmits 832 the remaining gnss-validityDuration to the BS 104 through an UL dedicated control channel message (e.g., UEAssistancelnformation). The message may also indicate an updated UE location. Upon successfully transmitting the gnss-validityDuration to the BS 104, the UE 102 stops 840 the gnss-validityReport timer. Similarly, upon successful receiving the gnss-validityDuration (i.e. , remaining GNSS validity duration), the BS 104 stops 842 the gnss-validityReport timer. At the end of the c-DRX ON period, the UE 102 starts 834 a c-DRX OFF period during which again does not monitor PDCCH. This procedure may repeat by returning to 818 during the start 834 of the c-DRX OFF period.

[0068] Fig. 9 is a messaging diagram 900 illustrating a scenario similar to the one in Fig. 6B, when the UE fails to conduct the GNSS position fix in a c-DRX OFF period, and hence transitions to the idle state at the beginning of the next c-DRX ON period, according to an embodiment. The message diagram in Fig. 9 is similar to that in Fig. 8, with the differences discussed below. After the gnss-validityDuration expires 820 on both the UE and BS sides, although the UE 102 still remains 822 in the connected state, the UE 102 is not able to conduct a GNSS position fix procedure successfully before the next c-DRX ON period. The failure to successfully conduct a GNSS position fix procedure could be that the signal from the GNSS satellite(s) is blocked by obstacles. As a result, at the beginning of the next c-DRX ON period, the UE 102 transitions 929 into the idle state due to the expiry of the gnss-validityDuration timer (similar to conventional UE behavior). On the other hand, the BS 104 still maintains 824 the connection with the UE 102 even after the expiry of the gnss-validityDuration timer while waiting for the UE 102 to report. The BS 104 starts 830 another timer, gnss- validityReport, at the beginning of UE’s next c-DRX ON period as described in Fig. 8. Upon the expiry of the gnss-validityReport timer, because the BS 104 has not received the GNSS validity duration report from the UE 102, the BS 104 transitions 931 the UE 102 into the idle state.

[0069] Fig. 10 is a messaging diagram 1000 which is similar to the one in Fig. 6C in which the UE fails to report the GNSS validity duration during the c-DRX ON period following the expiry of the GNSS validity duration, according to an embodiment. The message diagram in Fig. 10 is similar to that in Fig. 8, with the differences discussed below. After the gnss-validityDuration expires 820 on both the UE and BS sides, the UE 102 remains 822 in the connected state and successfully conducts 826 a GNSS position fix before the next c-DRX ON period. As the UE 102 has successfully conducted 826 the GNSS position fix procedure in the c-DRX OFF period, the UE 102 starts 828 another timer, gnss-validityReport, at the beginning of the next c-DRX ON period, and also starts monitoring the PDCCH. However, here the UE 102 is not able to report to the BS 104 its GNSS validity duration before the expiry of gnss-validityReport timer, and therefore the UE 102 transitions 1033 to the idle state at the expiry of the gnss-validityReport timer. The failure to report UE’s GNSS validity duration could be that the UE 102 is not able to obtain an UL grant (due to the lack of Scheduling Request resource, and/or random access congestion) before the gnss-validityReport timer expires. Similar to Fig. 9, the BS transitions 931 the UE 102 into the idle state upon the expiry of the gnss-validityReport timer when the BS 104 has not received the GNSS validity duration report from the UE 102.

[0070] Fig. 11 is a messaging diagram 1100 corresponding to the scenario in Fig. 7C. In this scenario, the GNSS validity lasts more than one c-DRX cycle, the UE conducts the GNSS position fix procedure one c-DRX cycle before the GNSS validity duration expires, based on a first value in an early GNSS position fix indication, according to an embodiment. This first value of an early GNSS position fix indication may be a flag, a first predetermined value of a field, or an implicit indication associated with the c-DRX mode. The message diagram in Fig. 11 bears similarities (e g., 802-814) to Fig. 8, with the differences discussed below. After determining 81 a c-DRX configuration for the UE 102, the BS transmits 1116 an RRC Reconfiguration message including the c-DRX configuration and a first value in an early GNSS position fix indication (early_GNSS_position_fix = 1 ) to the UE 102. The c-DRX configuration may include: (1 ) a duration of the ON period (for both the short and long c-DRX cycle), (2) a c-DRX inactivity timer determining how long the UE 102 should remain ON after the reception of a PDCCH, (3) a long c-DRX cycle value, and (4) a short c-DRX cycle value.

[0071] To comply with the c-DRX configuration, the UE 102 starts 1118A the 1^st c- DRX OFF period after the expiry of the c-DRX inactivity timer, and then begins its first c- DRX cycle by starting 1118B the 1^st c-DRX ON period followed by the 2^nd c-DRX OFF period at 1118C. During this 2^nd c-DRX OFF period, because the UE 102 knows that its GNSS validity duration is going to expire in the next c-DRX cycle (i.e. , GNSS validity duration is going to expire in either the c-DRX ON period or the c-DRX OFF period of the 2^nd c-DRX cycle), the UE 102 determines 1119 to conduct a GNSS position fix procedure. In case the GNSS validity duration is going to expire in the c-DRX OFF period of the 2^nd c-DRX cycle (i.e., the 3^rd c-DRX OFF period), the value T or ‘TRUE’ indicated by ‘early_GNSS_position_fix’ also contributes to the determination 1119 that the UE 102 makes. In another implementation, the presence of the indication ‘early_GNSS_position_fix’ implies a first (i.e., ‘1 ’ or ‘TRUE’) value for the indication.

[0072] In response to the determination 1119, the UE 102 conducts 826 another GNSS position fix procedure, and then restarts the gnss-validityDuration timer (since the original gnss-validityDuration timer has not expired yet) upon successfully conducting the GNSS position fix. After that, after the 2^nd c-DRX cycle starts with the 2^nd c-DRX ON period, the UE 102 starts 1128 monitoring PDCCH, and also starts a gnss- validityReport timer simultaneously. The BS 104 also starts 830 a similar gnss- validityReport timer for the UE 102, since the UE 102 is likely to report the GNSS validity duration in view of the early GNSS position fix indication transmitted 1116. Later but before the gnss-validityReport timer expires, the UE 102 obtains an UL transmission opportunity and transmits 832 the remaining gnss-validityDuration to the BS 104 through an UL DCCH message (e.g., UEAssistancelnformation). Upon successfully transmitting the gnss-validityDuration to the BS 104, the UE 102 stops 840 the gnss- validityReport timer. Similarly, upon successful reception of the gnss-validityReport timer, the BS 104 stops 842 its gnss-validityReport timer. At the end of the 2^nd c-DRX ON period, the UE 102 stops monitoring PDCCH during the 3^rd c-DRX OFF period 834. For the sake of brevity, this Fig. 11 shows a GNSS validity duration that covers two c- DRX cycles. This teaching can easily be extended to a larger number of cycles by implementing additional c-DRX ON/OFF periods 1118.

[0073] Fig. 12 is a messaging diagram 1200 corresponding to the scenario in Figure 7A in which, when the GNSS validity lasts more than one c-DRX cycle, the UE conducts the GNSS position fix procedure after the GNSS validity duration expires in a c-DRX OFF period, based on a second value in an early GNSS position fix indication. This second value of an early GNSS position fix indication may be the absence of a flag, a second predetermined value of a field, or an implicit indication associated with the c- DRX mode. The message diagram in Fig. 12 is similar to that in Fig. 11 , with the differences discussed below. After the BS 104 determines 814 a c-DRX configuration for the UE 102, the BS 104 transmits 1216 an RRC Reconfiguration message including the determined c-DRX configuration and a second early GNSS position fix indication to the UE 102 (e.g., early_GNSS_position_fix - 0). The c-DRX configuration may include a duration of the ON period (for both the short and long c-DRX cycle), a c-DRX inactivity timer determining how long the UE 102 should remain ON after the reception of a PDCCH, a long c-DRX cycle value, and a short c-DRX cycle value.

[0074] To comply with the c-DRX configuration, the UE 102 starts 1118A the 1^st c- DRX OFF period after the expiry of the c-DRX inactivity timer. While being in the 1^st c- DRX OFF period, the UE 102 knows that the GNSS validity duration is going to expire in the next c-DRX OFF period (i.e., the 2^nd c-DRX OFF period), but the UE 102 still determines NOT to conduct a GNSS in the 1^st c-DRX OFF period, according to the second early GNSS position fix indication the UE 102 received 1216. In another implementation, the absence of the indication ‘early_GNSS_position_fix’ implies a second (i.e., ‘0’ or ‘FALSE’) value for the indication. [0075] To further comply with the c-DRX configuration, the UE 102 goes into the first c-DRX cycle by starting 1118B the 1^st c-DRX ON period followed by 1118C the 2^nd c- DRX OFF period. At a later time, when the UE 102 is still within the 2^nd c-DRX OFF period, the gnss-validityDuration timer expires 820 on both the UE and BS sides. In response to the expiry of the gnss-validityDuration timer, the UE 102 conducts 826 a GNSS position fix while the UE 102 is still within the 2^nd c-DRX OFF period and starts the gnss-validityDuration timer upon successfully conducting the GNSS position fix procedure. As mentioned earlier, the UE may implement a mechanism that starts the GNSS position fix procedure 826 before the gnss-validityDuration timer expires 820 when there is not enough time to complete the GNSS position fix procedure prior to the start 1128 of the next c-DRX ON period.

[0076] At the end of the 2^nd c-DRX OFF period, the UE 102 starts 1128 a c-DRX ON period, starts a gnss-validityReport timer, and starts monitoring PDCCH. The BS 104 also starts 830 the same gnss-validityReport for the UE 102 (triggered by both the expiry of UE’s gnss-validityDuration, and the starting of a c-DRX ON period). At a later time (before the gnss-validityReport timer expires), the UE 102 obtains an UL transmission opportunity and transmits 832 the remaining gnss-validityDuration to the BS 104 through an UL DCCH message (e.g., UEAssistancelnformation). Upon successfully transmitting the gnss-validityDuration to the BS 104, the UE 102 stops 840 the gnss-validityReport timer. Similarly, upon successful reception of the gnss- validityReport tmer, the BS 104 stops 842 the gnss-validityReport timer. At the end of the current c-DRX ON period, the UE 102 starts 834 a c-DRX OFF period and then does not monitor PDCCH. As previously mentioned, a subsequent c-DRX OFF period 834 may cause a procedure to essentially repeat (e.g., by returning to 1118A).

[0077] Fig. 13 is a flow diagram of a UE method 1300 in which a UE (e.g., UE 102) conducts a GNSS position fix procedure after the GNSS validity duration expires without transitioning to the idle state, by relying on the c-DRX mechanism according to an embodiment. The UE conducts 1304 a GNSS position fix procedure before its connection with the network is established the procedure being triggered by the demand (from upper layers) for establishing the connection. Step 1304 corresponds to 804 in Figs. 8-12. Upon successfully completing the GNSS position fix procedure the UE starts, a GNSS validity duration timer.

[0078] The UE performs 1311 an RRC Connection Establishment procedure with a BS, and transmits, to the BS, the remaining GNSS validity duration. Step 1311 corresponds to 811 in Figs. 8-12. The UE then receives1316 a c-DRX configuration from the BS. Step 1316 corresponds to 816 in Figs. 8-10. The c-DRX configuration may include (1 ) a duration of a c-DRX ON period (for both the short and long c-DRX cycle), (2) a c-DRX inactivity timer determining how long the UE should remain connected after the reception of a PDCCH, (3) a long c-DRX cycle value, and (4) a short c-DRX cycle value.

[0079] The UE starts 1318 a c-DRX OFF period and stops monitoring the PDCCH, upon the expiry of a c-DRX inactivity timer. Step 1318 corresponds to 818 in Figs. 8-10 as well as 1118A/B/C in Figs. 11 and 12. The UE then determines 1319 whether the GNSS validity duration is going to expire before the next c-DRX OFF period. If the GNSS validity duration is not going to expire before the next c-DRX OFF period (i.e. , the ‘NO’ branch of 1319), that is, the GNSS validity duration does not expire in the current c-DRX OFF period nor in a next c-DRX ON period, then the UE complies with c-DRX configuration and starts 1317 the next c-DRX ON period.

[0080] On the other hand, if the GNSS validity duration is going to expire before the next c-DRX OFF period (i.e., ‘YES’ branch of 1319), that is, the GNSS validity duration expires during the current c-DRX OFF period, or in the next c-DRX ON period), the UE remains 1322 in the connected state upon the expiry of the GNSS validity duration timer. Step 1322 corresponds to 822 in Figs. 8-10. Note that if the GNSS validity duration is going to expire in the next c-DRX ON period step 1322 is superfluous, the UE conducting 1326 another GNSS position fix procedure by the end of the current c- DRX OFF period. Step 1326 corresponds to 826 in Figs. 8-12.

[0081] The UE determines 1325 if the GNSS position fix procedure was completed successfully. If the GNSS position fix was NOT conducted successfully (‘NO’ branch of 1325), the UE transitions 1329 into the idle state at the beginning of the next c-DRX ON period. Step 1329 corresponds to 929 in Fig. 9. Otherwise (i.e., ‘YES’ branch of 1325 the GNSS was conducted successfully), the UE starts or restarts 1327 the GNSS validity duration timer.

[0082] The UE then starts 1328 a gnss-validityReport timer, upon entering a c-DRX ON period. Step 1328 corresponds to 828 in Figs. 8 and 10 and is partially similar to 1128 in Figs. 11 and 12. The UE determines 1335 if there is any UL resource available for reporting the GNSS validity duration before the gnss-validityReport timer expires. If there is no UL resource available or granted (‘NO’ branch of 1335), the UE transitions 1333 into the idle state, upon the expiry of the gnss-validityReport timer. Step 1333 corresponds to 1033 in Fig. 10.

[0083] On the other hand, if the UE determines that there is an UL resource available (‘YES’ branch of 1335) the UE transmits 1332, to the BS, a remaining GNSS validity duration via an UL DCCH message. Step 1332 corresponds to 832 in Figs. 8, 11 , and 12. The UE stops 1340 the gnss-validityReport timer. Step 1340 corresponds to 840 in Figs. 8, 11 , and 12.

[0084] Fig. 14 is a flow diagram a UE method 1400 in which a UE (e.g., UE 102) conducts a GNSS position fix procedure in a c-DRX OFF period, based on an early GNSS position fix indication according to an embodiment. The above descriptions of steps 1304 and 1311 are not reiterated.

[0085] After obtaining a valid GNSS position (i.e. , successfully conducting the GNSS position fix procedure), connecting with the BS, and transmitting the remaining GNSS validity duration to the BS, the UE receives 1416, from the BS, a c-DRX configuration and an early GNSS position fix indication (e.g., named ‘early_GNSS_position_fix’). The c-DRX configuration may include (1 ) a duration of the c-DRX ON period (for both the short and long c-DRX cycle), (2) a c-DRX inactivity timer determining how long the UE should remain ON after the reception of a PDCCH, (3) a long c-DRX cycle value, and (4) a short c-DRX cycle value.

[0086] The UE determines 1417 whether the GNSS validity duration is going to expire before the next c-DRX ON period. When the UE determines that the GNSS validity duration is not going to expire before the next c-DRX ON period (i.e., ‘NO’ branch of 1417), the UE conducts 1419 a GNSS position fix procedure before the start of the c-DRX ON portion. When the UE determines that indeed the GNSS validity duration is going to expire before the next c-DRX ON period (i.e., ‘YES’ branch of 1417), the UE determines 1421 whether the early GNSS position fix indication indicates to conduct a GNSS position fix procedure before the start of the c-DRX ON period (early_GNSS_position_fix = 1 ?). If the position fix indication does indicate to conduct a GNSS position fix procedure before the start of the c-DRX ON period (i.e., ‘YES’ branch of 1421 , early_GNSS_position_fix = 1 ) then the UE conducts 1423 the GNSS position fix procedure during the c-DRX OFF period before the DRX cycle where the GNSS validity duration timer is going to expire. If, however, the position fix indication does not indicate to conduct a GNSS position fix procedure before the start of the c-DRX ON period (i.e., ‘NO’ branch of 1421 , early_GNSS_position_fix + 1 ) then the UE conducts

1425 the GNSS position fix procedure during the c-DRX OFF period when or immediately after the GNSS validity duration timer expires. The UE starts or restarts

1426 the GNSS validity duration timer, upon successfully conducting the GNSS position fix procedure. Step 1426 corresponds to 826 in Figs. 8 and 10-12.

[0087] Fig. 15 is a flow diagram a UE method 1500 in which the UE (e.g., UE 102) conducts a GNSS position fix procedure during a c-DRX OFF period when the next c- DRX ON period extends beyond the GNSS validity duration according to an embodiment. The flow diagram in Fig. 15 is similar to the ones in Figs. 13 and 14, with the differences discussed below. After steps 1304, 1311 , and 1316 already described above, the UE determines 1517 whether the GNSS validity duration is going to expire during a c-DRX ON period. When the UE determines that indeed the GNSS validity duration is going to expire during a c-DRX ON period (i.e., ‘YES’ branch of 1517), the UE conducts 1419 a GNSS position fix before the start of the c-DRX ON period. Otherwise (i.e., the UE determines that the GNSS validity duration is not going to expire during a c-DRX ON period, that is, ‘NO’ branch of 1517), the UE conducts 1425 a GNSS position fix procedure during the c-DRX OFF period before the DRX cycle where the GNSS validity duration timer is going to expire. No matter which action (1419 or 1425) the UE performs, the UE restarts 1426 the GNSS validity duration timer, upon successfully conducting the GNSS position fix procedure. [0088] Fig. 16 is a flow diagram of a UE method in which the UE conducts a GNSS position fix procedure during a c-DRX OFF period when the next c-DRX ON period extends beyond the GNSS validity duration according to an embodiment. The flow diagram in Fig. 16 is similar to that in Figs. 13-15, with the differences discussed below. After steps 1304, 1311 , and 1316 already described above, the UE determines 1617 whether the GNSS validity duration is going to expire in a c-DRX ON period. When the GNSS validity duration is going to expire in a c-DRX ON period (i.e. , ‘YES’ branch of 1617), the UE conducts a GNSS position fix procedure before the start of the c-DRX ON period. Otherwise (i.e., ‘NO’ branch of 1617), the UE conducts 1625 a GNSS position fix procedure during the c-DRX OFF period where the GNSS validity duration timer is going to expire. No matter which action (1419 or 1465) the UE performs, the UE restarts 1426 the GNSS validity duration timer, upon successfully conducting the GNSS position fix procedure.

[0089] Fig. 17 is a flow diagram of an NE method 1700 for determining the RRC state for the UE configured with a c-DRX configuration, upon the expiry of UE’s GNSS validity duration according to an embodiment. The BS receives 1710 an RRC Connection Setup Complete message from a UE. Step 1710 corresponds to 810 in Fig. 8. The message includes a remaining GNSS validity duration. The BS then starts a GNSS validity duration timer for the UE. The BS then transmits 1716 a c-DRX configuration to the UE. Step 1716 corresponds to 816 in Figs. 8-10. Optionally, the BS also includes an early GNSS position fix indication ‘early_GNSS_position_fix’ . Step 1716 then corresponds to 1116 and 1216 in Figs. 11 and 12.

[0090] After determining 1720 that the GNSS validity duration timer has expired during a c-DRX OFF period, the BS starts 1730, for the UE, a gnss-validityReport timer, at the beginning of the c-DRX ON period after the c-DRX OFF period where the GNSS validity duration timer expired. Step 1720 corresponds to 820 in Figs. 8-10 and 12, and step 1730 corresponds to 830 in Figs. 8-12. The BS then determines 1732 whether the BS has received from the UE, a GNSS validity duration before gnss-validityReport expires. When the BS has received the GNSS validity duration (‘YES’ branch of 1732), the BS stops 1742 the gnss-validityReport timer, maintains the connection with the UE the UE in the connected state, and starts the GNSS validity duration timer for the UE based on the received GNSS validity duration. On the other hand, when the BS has not received the GNSS validity duration before gnss-validityReport expired (‘NO’ branch of 1732), the BS releases 1731 the UE context, and transitions the UE into the idle state. [0091] The following description may be applied to the description above.

[0092] Generally speaking, description for one of the above figures can apply to another of the above figures. Any event or block described above can be optional. For example, an event or block with dashed lines can be optional.

[0093] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may be software modules (e.g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0094] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.

[0095] Reference throughout this section to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

[0096] Numerical adjectives “first”, “second”, and “third” do not imply any order (are not ordinals) but are markers to distinguish separate instances of similar elements. References to the singular (e.g., “a” or “an”, “the”) should include the plural unless clearly indicated otherwise. As used herein, a phrase referring to “at least one of’ or “one or more of” a list of items refers to any combination of those items, including single members. For example, “at least one of: a, b, or c” is intended to cover the possibilities of: a-only, b-only, c-only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0097] Although the features and elements of the present embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flowcharts may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a specifically programmed computer or processor.

Claims

WHAT IS CLAIMED IS:

1 . A wireless communication method (1300) performed by a user equipment, UE (102), connected to a network entity, NE, (104) via a non-terrestrial network, the method comprising: while operating in a connected mode, receiving (1316), from the NE, a connected mode discontinuous reception, c-DRX, configuration; maintaining (1322) a connected state when a Global Navigation Satellite System, GNSS, validity duration of a GNSS position fix procedure ends during a c-DRX OFF period of a c-DRX cycle; and conducting (1326) another GNSS position fix during the c-DRX OFF period of a c-DRX cycle.

2. The wireless communication method of claim 1 , further comprising: when the other GNSS position fix procedure is successfully completed, starting a GNSS validity timer to track the GNSS validity duration, and transmitting, to the NE, a timer value of the GNSS validity timer.

3. The wireless communication method of claim 2, further comprising: requesting, from the UE, an uplink grant for the transmitting of the timer value.

4. The wireless communication method of any of claims 2 or 3, wherein the UE performs the transmitting of the timer value at a beginning of a c-DRX ON period of the c-DRX cycle.

5. The wireless communication method of claim 4, further comprising: when the UE does not complete the transmitting of the timer value before a

GNSS validity report interval starting the c-DRX ON period, switching to an idle state.

6. The wireless communication method of any of claims 1 to 5, further comprising: when the GNSS position fix is not successfully completed, switching to an idle state after the c-DRX OFF period of the c-DRX cycle ends.

7. The wireless communication method of any of claims 1 to 6, further comprising: starting a GNSS validity timer.

8. The wireless communication method of any of claims 1 to 7, wherein, when the GNSS validity duration is longer than a c-DRX cycle, the c-DRX OFF period is an ultimate c-DRX OFF period starting prior to the GNSS validity duration ending.

9. The wireless communication method of any of claims 1 to 7, wherein, when the GNSS validity duration is longer than a c-DRX cycle, the c-DRX OFF period is a penultimate c-DRX portion starting prior to the GNSS validity duration ending.

10. The wireless communication method of any of claims 1 and 7, further comprising: receiving, from the NE, an indication as to whether, when the GNSS validity duration is longer than one c-DRX cycle, the c-DRX OFF period is an ultimate or is a penultimate c-DRX OFF period that starts prior to the GNSS validity duration end.

11 . The wireless communication method of any of claims 1 to 10, further comprising:

Starting a GNSS validity timer to track the validity duration.

12. A wireless communication method (1700) performed by a network entity, NE (104), the method comprising: transmitting (1716), to a user equipment, UE, (102) connected to the NE via a non-terrestrial network, a connected mode discontinuous reception, c-DRX, configuration; maintaining (1720) a connection with the UE when a Global Navigation Satellite System, GNSS, validity duration ends during a c-DRX OFF period of a DRX cycle; and starting (1742) a GNSS validity timer configured to expire when an updated GNSS validity duration is not received from the UE.

13. The wireless communication method of claim 12, further comprising: releasing a UE context absent receiving the updated GNSS validity value from the UE within a GNSS validity report time interval immediately following the c-DRX OFF period.

14. The wireless communication method of any of claims 12 or 13, further comprising: transmitting, to the UE, an indication as to whether, when the GNSS validity duration is longer than one c-DRX cycle, the c-DRX OFF period is an ultimate or is a penultimate c-DRX portion that starts prior to the GNSS validity duration ends.

15. A wireless communication device (102, 104) comprising a transceiver (121 , 122, 127, 128), a processor (123, 129), and computer-readable storage media (120, 130) storing executable instructions for the processor to perform any one of methods recited in claims 1 -14, using the transceiver.