Recovering the RRC connection after the positioning data is outdated

Abstract

A user equipment (UE) initiates, in a connected state of a protocol for controlling radio resources between the UE and a radio access network (RAN), when a position information is outdated and at a time outside an inactive period for conducting position measurement, a procedure for obtaining a new position information; and determines whether to transition to another state of the protocol based at least in part on whether the UE obtains the new position information within a threshold amount of time from the initiating.

Description

RECOVERING THE RRC CONNECTION AFTER THE POSITIONING DATA IS OUTDATEDCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 595,744 entitled “Methods for Recovering an RRC Connection upon an Outdated GNSS Indication,” filed on November 2, 2023. The entire content of the provisional application is hereby expressly incorporated herein by reference.FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communications and, more particularly, to enabling satellite communication, i.e., non-terrestrial network (NTN) communication, for a user equipment (UE) in the connected state to recover the RRC connection when the GNSS position of the UE becomes outdated.BACKGROUND

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

[0004] The objectives behind developing the fifth generation (5G) technology include providing a unified framework for such types of communication as enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine type communication (mMTC).

[0005] Although the 5G technology relies primarily on legacy terrestrial networks,, the 3rd Generation Partnership Project (3GPP) organization has proposed to extend 5G 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-IoT) or the enhanced Machine Type Communication (eMTC) scenarios. In an NTN, an RF transceiver is mounted on a satellite, an unmanned aircraft system (UAS) also referred to as a drone, a balloon, a airplane, or another suitable apparatus. For simplicity, the discussion below refers toall such apparatus as satellites. In addition to satellites, an NTN can include 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 (ISL) when satellites form constellations.

[0006] 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 (LEO) 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.

[0007] 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 time duration to proceed with mobility anchoring and hand-over.

[0008] A satellite can support a transparent or a regenerative (with on-board processing) payload, and typically generates several beams for a given service area bounded by the field of view. The footprints of the beams typically have an elliptic shape and depend on the on-board antenna configuration and the elevation angle. For a transparent payload implementation, a satellite can apply RF filtering and frequency conversion and amplification, and not change the waveform signal. For a regenerative payload implementation, a satellite can apply RF fdtering, frequency conversion and amplification, demodulation and decoding, routing, and coding / modulation. This approach is effectively equivalent to implementing most of the functions of a base station, e.g., a Next Generation Node B (gNB).

[0009] NB-IoT 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. However, to ensure the required loT connectivity, deployment of these technologies requires satellite connectivity to provide coverage beyond terrestrial deployments. Satellite NB- loT or eMTC is defined in a complementary manner to terrestrial deployments.

[0010] In these and other applications, due to hardware constraints, a certain type of a user equipment (UE) such as an NB-IoT device cannot communicate with a base station and acquire its Global Navigation Satellite System (GNSS) position from the GNSS module at the same time. Therefore, if the GNSS position becomes outdated, and the network does not provide the UE with inactive periods for conducting the GNSS measurement, the UE must transition to the idle state even if the UE still has pending downlink or uplink data to receive or transmit.Because transitioning between the connected and idle states takes a relatively long time to complete and consumes a significant amount of UE power, it is desirable to have a mechanism that allows the UE to autonomously (i.e., independently of the network) recover the RRC connection without transitioning to the idle state, in scenarios when the network does not provide the UE with inactive periods for conducting the GNSS measurement.SUMMARY

[0011] Generally speaking, the techniques of this disclosure allow a user equipment to autonomously (independent of the network) recover the RRC connection with the base station after the user equipment has detected an outdated GNSS position, possibly by initiating an RRC Connection Reestablishment procedure with the base station.

[0012] One example embodiment of these techniques is a method implemented in a user equipment (UE), the method comprising: initiating, in a connected state of a protocol for controlling radio resources between the UE and a radio access network (RAN), when a position information is outdated and at a time outside an inactive period for conducting position measurement, a procedure for obtaining a new position information; and determining whether to transition to another state of the protocol based at least in part on whether the UE obtains the new position information within a threshold amount of time from the initiating.

[0013] One example embodiment of these techniques is a method implemented UE. The method comprises determining, when operating in a connected state of a protocol for controlling radio resources between the UE and a radio access network (RAN), and independent of a validity duration of position information of the UE (e.g., when the network does not provide the UE with inactive periods for conducting the GNSS measurement), that the position information is outdated; in response to the determining, initiating a procedure for obtaining a new position information; and determining whether to transition to another state of the protocol based at leastin part on whether the UE obtains the new position information within a threshold amount of time.

[0014] Another embodiment of these techniques is a method implemented in a UE and comprising: determining, when operating in a connected state of a protocol for controlling radio resources between the UE and a RAN, that a position information of the UE is outdated; in response to the determining, starting a timer and initiating a procedure for obtaining a new position information; and transitioning to another state of the protocol in response at least to the timer expiring prior to the UE obtaining the new position information.

[0015] Yet another embodiment of these techniques is a method implemented in UE and comprising: determining, when operating in a connected state of a protocol for controlling radio resources between the UE and a RAN, that a position information of the UE is outdated; in response to the determining and when (i) uplink (UL) traffic is pending for transmission to the RAN and / or (ii) an amount of time required to complete a procedure for obtaining a new position information is less than a threshold value: remaining in the connected state; and performing at least one of: (i) initiating a connection reestablishment procedure with the RAN, or (ii) performing a procedure for obtaining a new position information.

[0016] Another embodiment of these techniques is a method implemented in a UE comprising: transmitting, to a RAN and when operating in a connected state, a timing advance (TA) value the UE applies in a UL transmission; receiving, from the RAN, a differential Koffset value for determining an actual delay associated with an uplink transmission; in response to a trigger event: initiating a connection reestablishment procedure with the RAN; and discarding the differential Koffset value.

[0017] Still another example embodiment of these techniques is a user equipment comprising a transceiver and one or more processors and configured to implement one of the methods above.BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Fig. 1A is a block diagram of an example wireless communication system in which a user device and a base station of this disclosure can implement the positioning techniques of this disclosure;

[0019] Fig. IB is a block diagram of an example base station in which a centralized unit (CU) and a distributed unit (DU) that can operate in the system of Fig. 1 A;

[0020] Fig. 2A is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with base stations;

[0021] Fig. 2B is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with a CU and a DU;

[0022] Fig. 3A is a block diagram of an example NTN node with transparent payload implementation ;

[0023] Fig. 3B is a block diagram of an example NTN node with transparent payload implementation, in which a base station connects to multiple satellites via the same sat-gateway;

[0024] Fig. 4A illustrates an exemplary user plane protocol stack for use with the architecture of Fig. 3A;

[0025] Fig. 4B illustrates an exemplary control plane protocol stack for use with the architecture of Fig. 3A;

[0026] Fig. 5A illustrates how a known UE an switches between the connected and idle states in accordance with the GNSS validity status;

[0027] Fig. 5B is the timeline of a scenario in which a UE reacquires a valid GNSS position after an indication that the GNSS position is outdated, and remains in the connected state;

[0028] Fig. 5C is the timeline of a scenario in which a UE reacquires a valid GNSS position and performs an RRC connection reestablishment procedure after an indication that the GNSS position is outdated, and remains in the connected state;

[0029] Fig. 5D is the timeline of a scenario in which a UE transitions to the idle state after an indication that the GNSS position is outdated if the UE cannot require a valid GNSS position within a certain interval of time;

[0030] Fig. 6A is a messaging diagram of an example scenario in which a UE quickly (with a certain short time interval) regains a valid GNSS position and remains in the connected state, after the GNSS position has become outdated;

[0031] Fig. 6B is a messaging diagram of an example scenario in which a UE transitions to the idle state after failing to obtain a valid GNSS position within a certain time period after the GNSS position has become outdated;

[0032] Fig. 6C is a messaging diagram of an example scenario in which a UE regains a valid GNSS position and performs a RRC connection reestablishment procedure in order to remain in the connected state, after the GNSS position has become outdated;

[0033] Fig. 6D is a messaging diagram of an example scenario in which a UE regains a valid GNSS position but fails to perform a RRC connection reestablishment procedure, after the GNSS position has become outdated;

[0034] Fig. 7 illustrates a messaging diagram of an example scenario in which a UE clears or discards the differential Koffset value before or upon initiating the RRC Connection Reestablishment procedure;

[0035] Fig. 8A is a flow diagram of an example method a UE can implement to determine whether to remain in the connected state upon receiving an outdated GNSS indication;

[0036] Fig. 8B is a flow diagram of an example method a UE can implement to determine whether to conduct an RRC connection reestablishment procedure upon receiving an outdated GNSS indication;

[0037] Fig. 8C is a flow diagram of an example method a UE can implement to process an outdated GNSS indication and determine the next RRC stateusing two timers;

[0038] Fig. 9 is a flow diagram of an example method a UE can implement to determine the RRC state based on a timer and the GNSS validity status, after initiating an RRC Connection Reestablishment procedure;

[0039] Fig. 10 is a flow diagram of an example method a UE can implement to determine whether to perform the RRC Connection Reestablishment procedure upon receiving an outdated GNSS indication, based on the uplink traffic status;

[0040] Fig. 11 A is a flow diagram of an example method a UE can implement to determine whether to perform the RRC Connection Reestablishment procedure upon receiving an outdated GNSS indication, based on the time required to complete a GNSS position fix;

[0041] Fig. 1 IB is a flow diagram of an example method a UE can implement to determine whether to remain in the connected state upon receiving an outdated GNSS indication, based on the time required to complete a GNSS position fix;

[0042] Fig. 12A is a flow diagram of an example method a UE can implement to release / discard the differential Koffset value upon triggering a RRC Connection Reestablishment procedure due to outdated GNSS position; and

[0043] Fig. 12B is a flow diagram of an example method for a UE can implement to release / discard the differential Koffset value upon triggering a RRC Connection Reestablishment procedure due to the detection of radio link failure.DETAILED DESCRIPTION OF THE DRAWINGS

[0044] As discussed in more detail below, a user equipment (UE) and / or a network node of a radio access network (RAN) can use the techniques of this disclosure for managing early data communication and transitioning a UE between states of a protocol for controlling radio resources between the UE and the RAN.

[0045] According to some implementations, a UE conducts a GNSS position fix, in response to a demand from upper layers for establishing a connection with a base station. The UE obtains a valid GNSS position and, upon successfully conducting the GNSS position fi, starts monitoring whether a period of GNSS validity has elapsed. The UE performs an RRC Connection Establishment procedure with the base station and transmits to the base station an indication of GNSS validity duration and a GNSS position fix duration. The UE receives, from a lower layer or from the GNSS module, an indication that the GNSS position of the UE has become outdated. The UE determines whether the time required to complete a GNSS position fix is smaller than a threshold value. The user equipment determines to remain (continue operating) in RRC_CONNECTED and to initiate / trigger an RRC Connection Reestablishment procedure with the BS, if the time required to complete a GNSS position fix is smaller than the threshold value. The UE performs a GNSS position fix and obtains a valid GNSS position prior to transmitting the RRC Connection Reestablishment Request message to the base station.

[0046] According to another implementation, the UE performs an RRC Connection Establishment procedure with a base station. The UE transmits, to the base station, a TimingAdvance Report Medium Access Control (MAC) control element (CE) including the full timing advance value that the user equipment is to apply in the uplink transmission, in response to a timing advance reporting configuration the UE received from the base station. The UE, receives from the base station, a Differential Koffset MAC CE including a differential Koffset value, and stores the received differential Koffset value. The UE detects a radio link failure event and determines to initiate an RRC Connection Reestablishment procedure with the base station. The UE clears the differential Koffset value stored by the user equipment and resets the MAC layer. The UE transmits to the BS an RRC Connection Reestablishment Request message after the differential Koffset value has been cleared and the MAC layer has been reset.

[0047] These are other techniques are discussed in more detail with reference to Figs. 1A-12B.

[0048] Referring first to Fig. 1A, an example wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106, and a core network (CN) 110. The base stations 104 and 106 can operate in a RAN 105 connected to the core network (CN) 110. The CN 110 can be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160, for example. The CN 110 can also be implemented as a sixth generation (6G) core in another example.

[0049] The base station 104 covers a cell 124, and the base station 106 covers a cell 126. If the base station 104 is a gNB, the cell 124 is an NR cell. If the base station 104 is an ng-eNB or eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if the base station 106 is a gNB, the cell 126 is an NR cell, and if the base station 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. In general, the RAN 105 can include any number of base stations, and each of the base stations can cover one, two, three, or any other suitable number of cells. The UE 102 can support at least a 5G NR (or simply, “NR”) or E- UTRA air interface to communicate with the base stations 104 and 106. Each of the base stations 104, 106 can connect to the CN 110 via an interface (e.g., SI or NG interface). The base stations 104 and 106 also can be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0050] Among other components, the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116.The SGW 112 in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the 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 160 includes a User Plane Function (UPF) 162 and an Access and Mobility Management Function (AMF) 164, and / or Session Management Function (SMF) 166. Generally speaking, the UPF 162 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

[0051] As illustrated in Fig. 1 A, 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.

[0052] As discussed in detail below, the UE 102 and / or the RAN 105 may utilize the techniques of this disclosure 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 RRC_INACTIVE or RRC_IDLE state of the RRC protocol.

[0053] The base station 104 is equipped with processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 in an example implementation includes a processor 132 to process data that the base station 104 will transmit in the downlink direction, or process data received by the base station 104 in the uplink direction. The processing hardware 130 can also include a transceiver 134 configured to transmit data in the downlink direction (to the UE 102 and other devices) and receive data the UE 102 and other devices transmit in the uplink direction. Thebase station 106 can include generally similar components. In particular, components 140, 142, 144, and 146 of the base station 106 can be similar to the components 130, 132, 134, and 136, respectively.

[0054] The UE 102 is equipped with processing hardware 150 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 150 in an example implementation includes a processor 152 to process data that the UE 102 will transmit in the uplink direction (to the RAN 105) , or process data the UE 102 receives in the downlink direction (from the RAN 105). The processing hardware 150 can also include a transceiver 154 configured to transmit data in the uplink direction and receive data transmitted in the uplink direction.

[0055] A positioning manager 155, which can be implemented as a set of instructions stored in the memory of the UE 102 and executable by the processor(s) 152, can implement at least some of the techniques discussed below to process indications that a GNSS position has become outdated, control one or more timers for re-acquiring a GNSS position, reestablishing an RRC connection, etc., and determine other parameters related to GNSS measurements. A GNSS module 156 can obtaining the positioning data for the UE 102 using GNSS satellites 180, and the positioning manager 155 can control the timing of the operation of the GNSS module 156.

[0056] Fig. IB depicts an example distributed or disaggregated implementation of any one or more of the base stations 104, 106. In this implementation, the base station 104, 106 includes a central unit (CU) 172 and one or more distributed units (DUs) 174. The CU 172 includes processing hardware, such as one or more general-purpose processors (c.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general- purpose processor(s), and / or special-purpose processing units. For example, the CU 172 can include a PDCP controller, an RRC controller and / or an RRC inactive controller. In some implementations, the CU 172 can include a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures. In further implementations, the CU 172 does not include an RLC controller.

[0057] Each of the DUs 174 also includes processing hardware that can include one or more general -purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or specialpurpose processing units. For example, the processing hardware can include a MAC controller configured to manage or control one or more MAC operations or procedures (e.g., a random access procedure), and / or an RLC controller configured to manage or control one or more RLC operations or procedures. The process hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0058] In some embodiments, the RAN 105 supports Integrated Access and Backhaul (IAB) functionality. In some implementations, the DU 174 operates as an lAB-node, and the CU 172 operates as an lAB-donor. In some embodiments, the RAN 105 supports Non-Terrestrial Network (NTN) functionality.

[0059] In some implementations, the CU 172 can include a logical node CU-CP 172A that hosts the control plane part of the PDCP protocol of the CU 172. The CU 172 can also include logical node(s) CU-UP 172B that hosts the user plane part of the PDCP protocol and / or Service Data Adaptation Protocol (SDAP) protocol of the CU 172. The CU-CP 172A can transmit control information (e.g., RRC messages, Fl application protocol messages), and the CU-UP 172B can transmit the data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0060] The CU-CP 172A can be connected to multiple CU-UP 172B through the El interface. The CU-CP 172A selects the appropriate CU-UP 172B for the requested services for the UE 102. In some implementations, a single CU-UP 172B can connect to multiple CU-CP 172A through the El interface. The CU-CP 172A can connect to one or more DU 174s through an Fl-C interface. The CU-UP 172B can connect to one or more DU 174 through the Fl-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 can connect to multiple CU-UP 172B under the control of the same CU-CP 172A. In such implementations, the connectivity between a CU-UP 172B and a DU 174 is established by the CU-CP 172A using Bearer Context Management functions.

[0061] Fig. 2A illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with an eNB / ng-eNB or a gNB (e.g., one or more of the base stations 104, 106).

[0062] In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to an EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2A). The UE 102, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2A, to support handover between EUTRA and NR base stations and / or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2A, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

[0063] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206 A or 206B) 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.”

[0064] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2A) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide Data Radio Bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.

[0065] Fig. 2B illustrates, in a simplified manner, an example protocol stack 250, which the UE 102 can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally split as shown by the radio protocol stack 250 in Fig. 2B. The CU at any of the base stations 104 or 106 can hold all the control and upper layer functionalities (e.g., RRC 214, SDAP 212, NR PDCP 210), while the lower layer operations (e.g., NR RLC206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connection to a 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0066] Fig. 3A illustrates a certain type of NTN deployment referred to as transparent payload architecture, which involves a satellite gateway 302 and a “transparent” satellite 304 for extending the range of the Uu interface. The satellite 304 implements a frequency conversion and a Radio Frequency (RF) amplifier in both the uplink and downlink directions. The satellite function is similar to that of an analogue RF repeater. As a result, the satellite 304 repeats the Uu radio interface from the feeder link (between the NTN gateway and the satellite) to the service link (between the satellite and the UE) in the downlink direction and vice versa in the uplink direction. The Satellite Radio Interface (SRI) on the feeder link is the Uu, and the NTN gateway 302 supports all necessary functions to forward the signal of the Uu interface. The NTN gateway 302 can operate at the same site as the base station (e.g., eNB, gNB) 104 is located, or be connected to the base station 104 at a distance via a wired link. It is also possible to connect more than one NTN gateway to a base station. Different transparent satellites may be connected to the same base station on the ground, via the same NTN gateway, or via different NTN gateways. Fig. 3B illustrates the case where two different satellites (304 and 306) are connected to the same base station 104 via the same NTN gateway 302, and these two satellites (304 and 306) are covering the Earth surface using two different Physical Cell IDs (PCIs).

[0067] Although the transparent payload architecture illustrated in Figs. 3A-3B has been the focus of the recent 3GPP development, the regenerative payload architecture according to which eNB functions operate on a satellite also represent a possible NTN deployment in the future. In such an architecture, the Uu only exists between the satellite and the UE. In general, the techniques of this disclosure can apply to the transparent payload architecture as well as the regenerative payload architecture.

[0068] The NTN user plane protocol stack (of the transparent payload architecture) involving the UE 102, the satellite 304, the NTN gateway 302, the eNB or gNB 104 / 106, and the S-GW 114 or the UPF 162 is illustrated in Fig. 4A. 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 304 and the NTN gateway 302, being placed in the middle of the Uu interface. Similarly, theNTN control plane protocol stack illustrated in Fig. 4B is also similar to that of the terrestrial network.

[0069] In terms of the satellite moving pattern, there are three types of service links that are supported in NTN (i) Earth-fixed: provisioned by beam(s) continuously covering the same geographical areas all the time (e.g., the case of GEO / GSO satellites); (ii) 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); or (iii) 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).

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

[0071] When transmitting any signal / data to a BS in the uplink 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 uplink transmissions can arrive precisely at desired timing scheduled by the BS. Thus, every UE must keep track of 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 uplink transmission if the UE currently does not have a valid UE position or valid satellite position information. As the position of the UE may become invalid after a certain period of time (depending on the mobility of the UE), a UE may need to periodically acquire its GNSS position from the GNSS module in order to continue performing the uplink transmission with the BS. In fact, the Rcl-17 specifications (e.g., TS 36.300 vl7.5.0) specify that a UE shall obtain its valid GNSS position before connecting to an NTN cell, and shall move to the idle state upon detecting that the GNSS position is outdated. This is because a NB-IoT device (UE) is unable to perform the mobile communication task with the BS while accessing the GNSS module.

[0072] Fig. 5A illustrates an example scenario 500A in which a UE, which can be a legacy UE lacking certain capabilities (e.g., a Rel-17 UE) or a more advanced UE lacking a certain configuration (e.g., a Rel-18 UE not configured with GNSS measurement gaps), switches between the connected and idle states in accordance with the GNSS validity status. In Fig. 5A aswell as Figs. 5B-D discussed below, time increases from left to right, and thus events on the lefthand side occur prior to the events on the right-hand side.

[0073] In the example of Fig. 5 A, the UE first operates in the connected state and then receives an indication (from the lower layer or from the GNSS module) that the GNSS position of the UE has become outdated. In response to the indication of the outdated GNSS position, the UE transitions to the idle state and performs a cell selection procedure to camp on a suitable cell. Further, the UE in this example still has uplink data to transmit (or the network pages the UE for pending downlink data), and therefore the UE attempts to establish the RRC connection with the cell in which the UE currently camps and conduct a GNSS position fix prior to initiating the RRC connection establishment procedure.

[0074] The approach illustrated in Fig. 5A requires the UE to switch between the connected and idle states two times per an outdated GNSS indication, when there is still downlink or uplink data pending for transmission. Because frequently switching between RRC states causes a considerable signaling overhead and delay, it is desirable to keep the UE in the connected state in this and similar scenarios. Although a certain UE in the connected state can conduct a GNSS position fix (i.e., to perform the GNSS measurement) within a gap period called “GNSS measurement gap,” the network must configure the GNSS measurement gap beforehand. When the network does not configure / provide the GNSS measurement gap, or the UE GNSS position becomes outdated suddenly (e.g., due to fast UE movement) before the network can configure / provide a GNSS measurement gap, the UE must transition to the idle state upon receiving an outdated GNSS indication. In particular, the UE must transition to the idle state because the UE will become unavailable / unreachable (from the network perspective) for the period of time when the UE is conducting a GNSS position fix, and that period of time can be relatively long (up to 31 seconds).

[0075] However, if the time required to conduct a GNSS position fix is not longer than the duration corresponding to timer T310 for the Radio Link Failure (RLF) detection, maintaining the UE in the connected state would not create a problem, because the UE is allowed to stay in the connected state even if the UE is temporarily out of network coverage (for the duration of timer T310). Therefore, the UE can operate as illustrated in Fig. 5B. In particular, the UE in a scenario 500B can continue operating in the connected state when the time required forconducting a GNSS position fix is not longer than the duration defined by Ti (which can be a new dedicated timer defined specifically for the purposes of controlling re-acquisition of GNSS) or T310.

[0076] On the other hand, if the time required to conduct a GNSS position fix is longer than Ti (or T310) but not longer than a second duration defined by T2, the UE still can be allowed to remain in the connected state, if the UE can reacquire a valid GNSS position and re-establish the RRC connection after reacquiring a valid GNSS position. This approach is illustrated as scenario 500C in Fig. 5C. According to this approach, the network in some implementations needs to properly configure the values for Ti or T311, so that T2 or T2+ T311 does not exceed the time interval after which the network may have already released the context of the UE.

[0077] In one implementation, the network configures the UE with a variant of T311 (e.g., T311’) with a smaller value. This smaller value can replace the original or standard T311 value. The UE can start a timer with this small value T311 ’ upon transmitting the RRC Connection Reestablishment Request message.

[0078] Further, if the time required to conduct a GNSS position fix is longer than a second duration T2, as illustrated in a scenario 500D of Fig. 5D, the UE can transition to the idle state and perform the cell selection procedure upon the expiry of T2. In one implementation, if the UE can determine early that it is not going to complete the GNSS position fix before T2 expires, the UE can transition to the idle state immediately upon detecting the GNSS position has become outdated.

[0079] Next, several example scenarios in which a UE and / or a RAN perform the techniques of this disclosure for supporting UE autonomous GNSS measurement (independent of a validity duration of position information) in the connected state are discussed with reference to Figs. 6A- 7. Generally speaking, similar events in Figs. 6A-7 are labeled with the similar reference numbers, with differences discussed below where appropriate. For example, event 618A is similar’ to event 618C, event 620A is similar to event 620B, 620C, and 720, and event 622 is similar to event 722.

[0080] Fig. 6 A is a messaging diagram 600A of an example scenario in which a UE quickly regains a valid GNSS position and remains in the connected state, after the GNSS position hasbecome outdated. A UE 102 initially operates 602 in the idle state and camps on the NTN cell 124 managed by the BS 104, via the service link provided by the satellite 304. The UE 102 conducts 604 a GNSS position fix operation by measuring / receiving the signal emitted by GNSS satellites (e.g., GNSS satellite 180), triggered by the demand from upper layer(s) for establishing the connection with the BS 104. After completing the GNSS position fix, the UE obtains its GNSS position and an associated GNSS validity duration (i.e., gnss-validityDuration) and then starts monitoring the GNSS validity duration, i.e., checking whether the GNSS validity duration has elapsed. After obtaining a valid GNSS position, the UE 102 transmits 606 an RRC Connection Request message to the BS 104 for establishing the connection with the BS 104. In response to the RRC Connection Request message, the BS 104 transmits 608 an RRC Connection Setup message to the UE 102, for establishing the SRB1 (Signaling Radio Bearer: 1). In response to the reception of the RRC Connection Setup message, the UE 102 transmits 610 an RRC Connection Setup Complete message to the BS, and then transitions 614 to the connected state. The RRC Connection Setup Complete message the UE transmits 610 includes a remaining GNSS validity duration and a GNSS position fix duration, where the GNSS position fix duration is a duration requested the UE 102 requested for conducting a GNSS position fix successfully. The events 606, 608, and 610 are collectively referred to in Fig. 6A as procedure 612 for RRC Connection Establishment, GNSS validity duration reporting, and GNSS position fix duration reporting. In one implementation, the procedure 612 can be understood as as a procedure for RRC Connection Resuming, GNSS validity duration reporting, and GNSS position fix duration reporting, if an RRC Connection Resume Request message replaces the RRC Connection Request message in the event 606, the RRC Connection Resume replaces the RRC Connection Setup message in the event 608, and an RRC Connection Resume Complete replaces the RRC Connection Setup Complete message in the event 610. In another implementation, the procedure 612 can be understood as a procedure for RRC Connection Re-establishment, GNSS validity duration reporting, and GNSS position fix duration reporting, if an RRC Connection Reestablishment Request message replaces the RRC Connection Request message in the event 606, an RRC Connection Reestablishment message replaces the RRC Connection Setup message in the event 608, and an RRC Connection Reestablishment Complete message replaces the RRC Connection Setup Complete message in the event 610.

[0081] After operating in the connected state for a certain period of time, the UE 102 receives 616 an internal notification indicating that the GNSS position of the UE 102 has become outdated (i.e., become invalid). The notification may arrive from a lower layer (e.g., the PHY layer) or from the GSNN module operating in the UE 102, and the notification may be triggered due to a sudden UE movement or due to the expiry of the GNSS validity duration. In response to the notification that the GNSS position of the UE 102 has become outdated, the UE 102 determines 618A to remain in the connected state and start a timer Ti, which can correspond to the timer Ti in Fig. 5B, and which the network can configure beforehand via a system information, via a DL MAC CE, or via an RRC message. Alternatively, Ti can be a fixed value hardcoded and stored in the UE 102.

[0082] The UE 102 then determines to conduct a GNSS position fix (i.e., conduct a GNSS measurement) while still operating in the connected state, and consequently obtains 620A a valid GNSS position before Ti expires. The UE 102 stops 620A the timer Ti upon obtaining a valid GNSS position to prevent the timer Ti from expiring. Because in this example the UE 102 successfully obtains a valid GNSS position before Ti expires, the UE 102 is allowed to remain (continue operating) in RRC_CONNECTED without triggering extra RRC message exchanges. In one implementation, after the UE 102 has obtained a valid GNSS position, the UE 102 transmits to the BS 104 an updated GNSS validity duration associated with the new GNSS position.

[0083] Fig. 6B is a messaging diagram 600B of an example scenario in which a UE transitions to the idle state upon failing to obtain a valid GNSS position within a given period after the GNSS position has become outdated. The message diagram in Fig. 6B is similar to that in Fig. 6A, with the differences discussed below. After the UE 102 determines to start Ti and conduct a GNSS position fix in response to an outdated GNSS notification, the UE 102 fails 620B to obtain a valid GNSS position before Ti expires. As a result, Ti expires and the UE 102 transitions 629 to the idle state upon the expiry of Ti .

[0084] Fig. 6C is a messaging diagram 600C of an example scenario in which a UE regains a valid GNSS position and performs an RRC connection reestablishment procedure in order to remain in the connected state, after the GNSS position has become outdated. The message diagram in Fig. 6C is similar to that in Fig. 6A, with the differences discussed below. After theUE 102 receives 616 an outdated GNSS notification, the UE determines 618C to remain in the connected state and start a timer T2, where the timer T2 corresponds to the timer T2 in Fig. 5C. The network can configure the UE with T2 beforehand via a system information, via a DL MAC CE, or via an RRC message beforehand, or the UE 102 can pre-store this value. The UE 102 then determines to conduct a GNSS position fix while still remaining in the connected state, and consequently obtains 620C a valid GNSS position before T2 expires. The UE 102 stops 620C the timer T2 upon obtaining a valid GNSS position to prevent the timer T2 from expiring.

[0085] Because in this example the UE 102 successfully obtains a valid GNSS position before T2 expires, the UE 102 transmits 622 an RRC Connection Reestablishment Request message including a Reestablishment Cause equal to ‘GNSS outdated’ to the BS 104 for reestablishing the connection with the BS 104 and informing the BS 104 of the outdated GNSS situation. The UE 102 also starts the timer T311 (defined in 3GPP TS 36.331) upon transmitting 622 the RRC Connection Reestablishment Request message. In response to the RRC Connection Reestablishment Request message, the BS 104 transmits 624 an RRC Connection Reestablishment message to the UE 102. Because in this example the UE 102 receives the RRC Connection Reestablishment message before T311 expires, the UE 102 considers the RRC Connection Reestablishment procedure to be completed successfully and accordingly transmits 626 an RRC Connection Reestablishment Complete message to the BS 104. The UE 102 then remains 628 in the connected state.

[0086] Fig. 6D is a messaging diagram 600D of an example scenario in which a UE regains a valid GNSS position but fails to perform an RRC connection reestablishment procedure, after the GNSS position has become outdated. The message diagram in Fig. 6D is similar to that in Fig. 6C, with the differences discussed below. After the UE 102 has transmitted the RRC Connection Reestablishment Request message to the BS 104 and has started the timer T2, the UE 102 does not receive an RRC Connection Reestablishment message from the BS 104 before T2 expires, or the UE 102 receives 630 an RRC Connection Reestablishment Reject message from the BS 104 before T2 expires. As a result, the UE 102 determines that the RRC Connection Reestablishment procedure did not succeed, and therefore the UE 102 transitions 632 to the idle state.

[0087] Fig. 7 is a messaging diagram 700 of an example scenario in which a UE clears or discards the differential Koffset value before or upon initiating the RRC ConnectionReestablishment procedure. The message diagram in Fig. 7 is similar to that in Fig. 6C, with the differences discussed below. After the UE 102 has completed the RRC Connection Establishment procedure with the BS 104 and transitions 714 to the connected state, the UE 102 reports its full Timing Advance (TA) value according to a configuration and / or an instruction from the BS 104. The full TA value includes a common TA value corresponding to the roundtrip-time (RTT) of the feeder-link or part of feeder-link, a UE-specific TA corresponding to the RTT of the service link, and a TA correction the BS 104 signaled. In response to the TA reporting configuration / instruction, the UE 102 transmits 734 a TA Report MAC CE including a full TA value to the BS 104. In response to the TA Report MAC CE, the BS 104 transmits a Differential Koffset MAC CE including a differential Koffset value to the UE 102, where the differential Koffset value is used to compensate a cell-specific Koffset value and form a UE- specific Koffset value corresponding to the actual delay the UE 102 needs to apply for every PUCCH or the PUSCH transmission. The UE 102 then can stores the differential Koffset value the BS 104 transmitted in the Differential Koffset MAC CE.

[0088] At a later time, the UE determines 738 to trigger or initiate an RRC Connection Reestablishment procedure with the BS 104, to recover from the RRC connection failure. The UE 102 may trigger or initiate an RRC Connection Reestablishment procedure upon detecting (i) a radio link failure, (ii) a handover failure, (iii) an RRC Connection Reconfiguration failure, (iv) an integrity check failure, or (v) that the GNSS position became outdated. In response to the determination of performing an RRC Connection Reestablishment procedure, the UE 102 may need to conduct 720 a GNSS position fix first to obtain a valid (or “fresh”) GNSS position before sending 722 the RRC Connection Reestablishment Request message to the BS 104.

[0089] After conducting 720 the GNSS position fix, the UE 102 clears, releases, or discards 740 the stored differential Koffset value prior to or upon initiating the RRC Connection Reestablishment procedure, and then transmits 722 the RRC Connection Reestablishment Request message to the BS 104 without applying the differential Koffset value (i.e., the UE- specific Koffset value). The rest of the procedure is the same as that in Fig. 6C.

[0090] Fig. 8A is a flow diagram 800A of an example method which a UE (e.g., the UE 102) can implement to determine whether to remain in the connected state upon receiving an outdated GNSS indication. Initially, at block 804, the UE conducts a GNSS position fix after receiving ademand (e.g., from upper layers) for establishing the connection with a BS. At block 804, the UE also obtains a GNSS validity duration and starts monitoring the GNSS validity duration, i.e., checking whether the GNSS validity duration has elapsed, upon successfully conducting the GNSS position fix.

[0091] After obtaining a valid GNSS position, the UE performs, at block 812, an RRC Connection Establishment procedure with a BS, and transmits to the BS the remaining GNSS validity duration and a GNSS position fix duration. In other implementations, the UE at block 812 can perform RRC Connection Reestablishment procedure or the RRC Connection Resume procedure instead of the RRC Connection Establishment procedure. At block 816, the UE receives, from a lower layer or from the GNSS module, an indication that the GNSS position of the UE has become outdated (no longer valid). At block 818, in response to the outdated GNSS indication, the UE determines to remain in RRC_CONNECTED and start a timer. The timer started at block 818 can be a timer the BS configures via a system information message, via a DL MAC CE, or via an RRC message beforehand. Alternatively, the UE can store this value as a fixed hardcoded value. At block 820, the UE may conduct a GNSS position fix procedure to obtain a valid GNSS position and a GNSS validity duration associated with the GNSS position.

[0092] The flow then proceeds to decision block 821, where the UE determines whether the UE has obtained a valid GNSS position before the timer expires. If the determination at decision block 821 is positive (i.e., the UE has obtained a valid GNSS position before the timer expires), the flow proceeds to the block 828, where the UE remains in the connected state. In one implementation, the UE also transmits the remaining GNSS validity duration associated with the updated GNSS position to the BS at block 828. On the other hand, if the determination at decision block 821 is negative (i.e., the UE does not obtain a valid GNSS position before the timer expires), the flow proceeds to the block 829, where the UE transitions to RRC_IDLE and starts the cell selection procedure to identify a suitable cell on which the UE can camp. In another implementation, the UE transitions to RRC_INACTIVE.

[0093] Fig. 8B is a flow diagram 800B of an example method which a UE (e.g., the UE 102) can implement to determine whether to conduct an RRC connection reestablishment procedure upon receiving an outdated GNSS indication. The flow diagram in Fig. 8B is similar to that in Fig. 8A, with the differences discussed below. If the determination at decision block 821 ispositive (i.e., the UE has obtained a valid GNSS position before the timer expires), the flow proceeds to block 822, where the UE transmits, to the BS, an RRC Connection Reestablishment Request message. The RRC Connection Reestablishment Request message can include an reestablishment cause indicating that the GNSS position of the UE has become outdated. In one implementation, the UE also transmits the remaining GNSS validity duration associated with the updated GNSS position to the BS via the RRC Connection Reestablishment Request message. On the other hand, if the determination at decision block 821 is negative (i.e., the UE does not obtain a valid GNSS position before the timer expires), the flow proceeds to the block 829, where the UE transitions to RRC_IDLE and stalls the cell selection procedure to identify a suitable cell on which the UE can camp.

[0094] Fig. 8C is a flow diagram 800C of an example method which a UE (e.g., the UE 102) can implement to determine the behavior of the UE in response to an outdated GNSS indication, based on two timers. The flow diagram in Fig. 8C is similar to that in Fig. 8A or Fig. 8B, with the differences discussed below. In response to the outdated GNSS indication received at block 816, the UE determines, at block 819, to stay in RRC_CONNECTED and starts a first timer and a second timer, where the second timer is not shorter than the first timer. The BS can configure the first and second timers started at block 818 via a system information message, via a DL MAC CE, or via an RRC message beforehand, or the UE can pre-store these values as fixed values.The UE may then conduct, at block 820, a GNSS position fix to obtain a valid GNSS position and a GNSS validity duration associated to the GNSS position.

[0095] The flow then proceeds to decision block 823, where the UE determines whether the UE obtained a valid GNSS position before the first timer expires. If the determination at decision block 823 is positive (i.e., the UE obtained a valid GNSS position before the first timer expires), the UE stays 828 in the connected state. The UE also may transmit the remaining GNSS validity duration associated with the obtained GNSS position to the BS. On the other hand, if the determination at decision block 823 is negative (i.e., the UE does not obtain a valid GNSS position before the first timer expires), the flow proceeds to another decision block 825, where the UE determines whether the UE has obtained a valid GNSS position before the second timer expires. If the determination at decision block 825 is positive (i.e., the UE has obtained a valid GNSS position before the second timer expires), the UE transmits 822, to the BS, an RRCConnection Reestablishment Request message, which can include a reestablishment cause indicating that the GNSS position of the UE has become outdated. In one implementation, at block 822, the UE also includes the remaining GNSS validity duration associated with the obtained GNSS position in the RRC Connection Reestablishment Request message. On the other hand, if the determination at decision block 825 is negative (i.e., the UE does not obtain a valid GNSS position before the second timer expires), the flow proceeds to the block 829, where the UE transitions to RRC_IDLE and starts the cell selection procedure to identify a suitable cell on which the UE can camp.

[0096] Fig. 9 is a flow diagram 900 of an example method which a UE (e.g., the UE 102) can implement to determine the RRC state to operate in, based on a timer and the GNSS validity status, after initiating an RRC Connection Reestablishment procedure. Initially, at block 904 (similar to block 804), the UE conducts a GNSS position fix after receiving a demand (e.g., from upper layers) for establishing the connection with a BS. At block 904, the UE also obtains a GNSS validity duration and starts monitoring the GNSS validity duration, i.e., checking whether the GNSS validity duration has elapsed, upon successfully conducting the GNSS position fix.

[0097] At block 912 (similar to block 812), after obtaining a valid GNSS position, the UE performs an RRC Connection Establishment procedure with a BS. The UE also transmits to the BS the remaining GNSS validity duration and a GNSS position fix duration. In other implementations, the UE at block 912 performs the RRC Connection Reestablishment procedure or the RRC Connection Resume procedure instead of the RRC Connection Establishment procedure.

[0098] At block 938, the UE then determines to initiate or trigger an RRC Connection Reestablishment procedure and then starts a timer. The BS can configure the timer stalled at block 938 via a system information message, via a DL MAC CE, or via an RRC message beforehand, or the UE can pre-store this value as a fixed value. At block 920 (similar to block 820), before initiating the RRC Connection Reestablishment procedure (i.e., before transmitting the RRC Connection Reestablishment Request message to the BS), the UE may perform a GNSS position fix to obtain a valid / fresh GNSS position and a GNSS validity duration associated to the GNSS position.

[0099] The flow proceeds to decision block 921 (similar to block 821), where the UE determines whether the UE has obtained a valid GNSS position before the timer expires. If the determination at decision block 821 is negative (i.e., the UE does not obtain a valid GNSS position before the timer expires), the flow proceeds to the block 829, where the UE goes to the RRC_IDLE state and starts the cell selection procedure. On the other hand, if the determination at decision block 821 is positive (i.e., the UE has obtained a valid GNSS position before the timer expires), the flow proceeds to the block 922, where the UE transmits, to the BS, an RRC Connection Reestablishment Request message and starts T311 upon transmitting the RRC Connection Reestablishment Request message. In one implementation, the UE includes the remaining GNSS validity duration in the RRC Connection Reestablishment Request message. The flow then proceeds to another decision block 931 , where the UE determines whether the UE has received an RRC Connection Reestablishment message before T311 expires. If the determination at decision block 931 is negative (i.e., UE does not receive the RRC Connection Reestablishment message before T311 expires), the flow proceeds to block 829, where the UE goes to the RRC_IDLE state and starts the cell selection procedure. On the other hand, if the determination at decision block 931 is positive (i.e., UE has received the RRC Connection Reestablishment message before T311 expires), the flow proceeds to the block 926, where the UE transmits, to the BS, an RRC Connection Reestablishment Complete message to end the RRC Connection Reestablishment procedure.

[0100] Fig. 10 is a flow diagram 1000 of an example method a UE (e.g., the UE 102) can implement to determine whether to perform the RRC Connection Reestablishment procedure upon receiving an outdated GNSS indication, based on the uplink traffic status. The flow diagram in Fig. f0 is similar to that in Fig. 8A or Fig. 8B (e.g., blocks 1004, 1012, 1022, and 1029 are similar to blocks 804, 812, 822, and 829 respectively), with the differences discussed below.

[0101] After the UE has received an outdated GNSS indication at block 1016 (similar to block 816), the flow proceeds to decision block 1048, where the UE determines whether the UE has any uplink traffic pending for transmission. To facilitate the determination at decision block 1048, in one implementation, the UE may check if there is any pending data left in the HARQ buffer, in the logic channel buffer, in the ARQ buffer, in the RLC buffer, or in the PDCP buffer.In case there is pending data left in one or more of the aforementioned buffers, the UE determines that the UE still has uplink traffic pending for transmission.

[0102] If the determination at decision block 1048 is negative (i.e., UE does not have any uplink traffic pending for transmission), the flow proceeds to the block 1029, where the UE transitions to RRC_IDLE state and stalls the cell selection procedure to identify for a suitable cell on which the UE can camp. On the other hand, if the determination at decision block 1048 is positive (i.e., UE still has some uplink traffic pending for transmission), the flow proceeds to the block 1018, where the UE determines to remain in RRC_CONNECTED and initiate / trigger an RRC Connection Reestablishment procedure with the BS. At block 1020, in response to the determination at block 1018, the UE performs a GNSS position fix and successfully obtains a valid GNSS position as well as a GNSS validity duration associated with the GNSS position. At block 1022, after obtaining the GNSS position, the UE transmits, to the BS, an RRC Connection Reestablishment Request message including a reestablishment cause indicating that the GNSS position of the UE has become outdated. In one implementation, the UE also includes the remaining GNSS validity duration in the RRC Connection Reestablishment Request message.

[0103] Fig. 11A is a flow diagram 1100A of an example method which a UE (e.g., the UE 102) can implement whether to perform the RRC Connection Reestablishment procedure upon receiving an outdated GNSS indication, based on the time required to complete a GNSS position fix. The flow diagram of Fig. 10 is similar to that in Fig. 8A or Fig. 8B (e.g., blocks 1104, 1112, and 1116, are similar to blocks 804, 812, and 816, respectively), and to Fig. 10 (e.g., blocks 1118, 1120, 1122, and 1129 are similar to blocks 1018, 1020, 1022, and 1029 respectively), with the differences discussed below.

[0104] After the UE has received an outdated GNSS indication at block 1116, the flow proceeds to decision block 1148, where the UE determines whether the time required to complete a GNSS position fix is smaller than a threshold value, where the BS can configure threshold value via a system information message, via a DL MAC CE, or via an RRC message beforehand. Similar to the examples above, the UE alternatively can pre-store the threshold value. If the determination at decision block 1148 is negative (i.e., the time required to complete a GNSS position fix is equal to or larger than a threshold value), the flow proceeds to the block 1129, where the UE transitions to RRC_IDLE state and starts the cell selection procedure toidentify a suitable cell on which the UE can camp. On the other hand, if the determination at decision block 1148 is positive (i.e., the time required to complete a GNSS position fix is smaller than a threshold value), the flow proceeds to the block 1118, where the UE operates as in Fig. 10 for the rest of the procedure.

[0105] Fig. 1 IB is a flow diagram 1100B of an example method which a UE (e.g., the UE 102) can implement to determine whether to remain in the connected state upon receiving an outdated GNSS indication, based on the time required to complete a GNSS position fix. The flow diagram in Fig. 1 IB is similar to that in Fig. 11 A, with the differences discussed below. After the UE has received an outdated GNSS indication at block 1116, if the determination at decision block 1148 is negative (i.e., the time required to complete a GNSS position fix is equal to or larger than a threshold value), the flow proceeds to the block 1 129, where the UE transitions to RRC_IDLE state and starts the cell selection procedure to identify a suitable cell on which the UE can camp. On the other hand, if the determination at decision block 1148 is positive (i.e., the time required to complete a GNSS position fix is smaller than a threshold value), the flow proceeds to the block 1118, where the UE determines to remain in the connected state. Following the determination at block 1118, the UE performs, at block 1120, a GNSS position fix and obtains a valid GNSS position. The UE may also obtain a GNSS validity duration associated with the obtained GNSS position at block 1120. In one implementation, the UE transmits the remaining GNSS validity duration to the BS after the UE has completed the operation at block 1120.

[0106] Further, in some implementations, the methods 8A-C discussed above can implement block 1018 or 1108 instead of block 818, and block 1020 or 1120 instead of block 820.

[0107] Fig. 12A is a flow diagram 1200A of an example method which a UE (e.g., UE 102) can implement to release or discard the differential Koffsct value upon triggering an RRC Connection Reestablishment procedure due to outdated GNSS position. Initially, at block 1204, the UE conducts a GNSS position fix upon being triggered by the demand (from upper layers) for establishing the connection with a BS. At block 1204, the UE also obtains a GNSS validity duration and starts monitoring the GNSS validity duration, i.e., checking whether the GNSS validity duration has elapsed, upon successfully conducting the GNSS position fix.

[0108] At block 1212, after obtaining a valid GNSS position, the UE performs an RRC Connection Establishment procedure with a BS, and transmits to the BS the remaining GNSS validity duration along with a GNSS position fix duration. In other implementations, the UE cat block 1212 an perform the RRC Connection Reestablishment procedure or the RRC Connection Resume procedure instead of the RRC Connection Establishment procedure. At block 1234, the UE then transmits, to the BS, a TA Report MAC CE including the full TA value that the UE will apply in the uplink transmission, in response to a TA reporting configuration or instruction from the BS.

[0109] At block 1236, the UE receives, from the BS, a Differential Koffset MAC CE including a differential Koffset value, where the differential Koffset value is used to compensate a cellspecific Koffset value and form a UE-specific Koffset value indicating the actual delay UE needs to apply for every PUCCH or the PUSCH transmission. The UE 102 also stores the differential Koffset value, at block 1236.

[0110] At a later time, the flow proceeds to the block 1216A, where the UE detects an RLF event or receives an indication that the GNSS position of the UE has become outdated. At block 1218, in response to the RLF event or the outdated GNSS indication, the UE determines to remain in the connected state and also determines to initiate / trigger an RRC Connection Reestablishment procedure. Upon or prior to initiating the RRC Connection Reestablishment procedure, at block 1240, the UE clears, discards, or releases the differential Koffset value. At block 1250, the UE resets the MAC layer according to the action list for the MAC reset procedure specified in 3GPP TS 36.321. In one implementation, the UE resets the MAC layer first and then clears, discards, or releases the differential Koffset value after the MAC layer has been reset (i.e., the UE can execute block 1250 than blockl240). After the UE has reset the MAC layer and has cleared, discarded, or released the differential Koffset value, at block 1222, the UE transmits an RRC Connection Reestablishment Request message to the BS. The UE may need to perform a random access procedure in order to obtain an uplink transmission opportunity for the transmission of the RRC Connection Reestablishment Request message at block 1222.

[0111] Fig. 12B is a flow diagram 1200B of an example method which a UE (e.g., UE 102) can implement to release or discard the differential Koffset value upon triggering or initiating a RRC Connection Reestablishment procedure due to the detection of radio link failure. The flowdiagram in Fig. 12B is similar to that in Fig. 12A, except that the GNSS related operations including the outdated GNSS indication are not included in Fig. 12B. More specifically, the UE no longer starts with conducting a GNSS position fix in Fig. 12B (i.e., the block 1204 is omitted), and block 1216B is a simplified version of block 1216A, to include only the detection of RLF.

[0112] The following list of examples reflects a variety of the embodiments explicitly contemplated by the present disclosure.

[0113] Example 1. A method implemented in a UE, the method comprising: determining, when operating in a connected state of a protocol for controlling radio resources between the UE and a RAN, that a position information of the UE is outdated; in response to the determining, starting a timer and initiating a procedure for obtaining a new position information; and transitioning to another state of the protocol in response at least to the timer expiring prior to the UE obtaining the new position information.

[0114] Example 2. The method of example 1 , wherein the transitioning to another state of the protocol includes transitioning to RRC_IDLE or RRC_INACTIVE.

[0115] Example 3. The method of example 1 or 2, further comprising, in response to the timer expiring prior to the UE obtaining the new position information: initiating a cell reselection procedure.

[0116] Example 4. The method of any of the preceding examples, wherein: the timer is a first timer; the method further comprises starting a second timer along with the first timer, the second timer longer than the first timer; and the transitioning to another state of the protocol is further in response to the second timer expiring prior to the UE obtaining the new position information.

[0117] Example 5. The method of any of the preceding examples, wherein: the timer expires prior to the UE obtaining the new position information in a first instance; and the UE obtains the new position information prior to the timer expiring in a second instance.

[0118] Example 6. The method of example 5, further comprising, in the second instance:

[0119] remaining in the connected state in response to the UE obtaining the new position information.

[0120] Example 7. The method of example 5 or 6, further comprising, in the second instance: transmitting, to the RAN, a connection reestablishment request message.

[0121] Example 8. The method of example 7, wherein the connection reestablishment request message includes a reestablishment clause indicating that the position information of the UE is outdated.

[0122] Example 9. The method of example 7 or 8, the method further comprising: starting a second timer along with the transmitting of the connection reestablishment request message; in response to receiving a connection reestablishment message prior to the second timer expiring, transmitting a connection reestablishment complete message to the RAN; and in response to the second timer expiring prior to the receiving of the connection reestablishment message, transitioning to another state of the protocol.

[0123] Example 10. The method of examples 9, wherein the second timer is a T311 timer.

[0124] Example 11. The method of any of the preceding examples, wherein: the determining that the position information of the UE is outdated includes receiving an indication that the position information of the UE is outdated from a lower layer.

[0125] Example 12. The method of any of the preceding examples, wherein: the determining that the position information of the UE is outdated includes receiving an indication that the position information of the UE is outdated from a Global Navigation Satellite System (GNSS) module.

[0126] Example 13. The method of any of the preceding examples, further comprising: obtaining a value of the timer from the RAN via one of (i) a system information, (ii) a downlink (DL) medium access control (MAC) control element (CE), or (iii) a radio resource control (RRC) message.

[0127] Example 14. A method implemented in a UE, the method comprising: determining, when operating in a connected state of a protocol for controlling radio resources between the UE and a radio access network (RAN), that a position information of the UE is outdated; in response to the determining and when (i) uplink (UL) traffic is pending for transmission to the RAN and / or (ii) an amount of time required to complete a procedure for obtaining a new position information is less than a threshold value: remaining in the connected state; and performing atleast one of: (i) initiating a connection reestablishment procedure with the RAN, or (ii) performing a procedure for obtaining a new position information.

[0128] Example 15. The method of example 14, further comprising, in a second instance when (i) no UL traffic is pending and (ii) the amount of time required to complete the procedure for obtaining the new position information is equal to or greater than the threshold value: transitioning to RRCJDLE or RRCJNACTIVE.

[0129] Example 16. The method of example 15, further comprising, in the second instance: initiating a cell reselection procedure.

[0130] Example 17. A method implemented in a UE, the method comprising: transmitting, to a RAN and when operating in a connected state, a timing advance (TA) value the UE applies in an uplink (UL) transmission; receiving, from the RAN, a differential Koffset value for determining an actual delay associated with an uplink transmission; in response to a trigger event: initiating a connection reestablishment procedure with the RAN; and discarding the differential Koffset value.

[0131] Example 18. The method of example 17, wherein the trigger event is radio link failure (RLF).

[0132] Example 19. The method of example 17, wherein the trigger event is a determination that a position information of the UE is outdated.

[0133] Example 20. The method of any of examples 17-19, further comprising: resetting a medium access control (MAC) entity in response to the trigger event.

[0134] Example 21. A UE comprising: a transceiver; and processing hardware configured to implement a method according to any of the preceding examples.

[0135] The following description may be applied to the description above.

[0136] 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. In some implementations, “message” is used and can be replaced by “information element (IE)”, and vice versa. In some implementations, “IE” is used and can be replaced by “field”, and vice versa. In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters”, and vice versa. The “eNB” can bereplaced by “base station”, “gNB”, “6G base station”, “evolved gNB” or 6G gNB. “MME” can be replaced by AMF or evolved AMF or 6G AMF. “RRC Connection Request message” can be replaced by “RRC Setup Request message”. “RRC Connection Setup message” can be replaced by “RRC Setup message”. “RRC Connection Setup Complete message” can be replaced by “RRC Setup Complete message”. “RRC Connection Reconfiguration message” can be replaced by “RRC Reconfiguration message”. “RRC Connection Reestablishment Request message” can be replaced by “RRC Reestablishment Request message”. “RRC Connection Reestablishment message” can be replaced by “RRC Reestablishment message”. “RRC Connection Reestablishment Complete message” can be replaced by “RRC Reestablishment Complete message”. “RRC Connection Resume Request message” can be replaced by “RRC Resume Request message”. “RRC Connection Resume message” can be replaced by “RRC Resume message”. “RRC Connection Resume Complete message” can be replaced by “RRC Resume Complete message”.

[0137] A user device in which the techniques of this disclosure can be implemented (e.g.. the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media- streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general -purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0138] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can 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 afield 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.

[0139] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

[0140] When implemented in software, the techniques can be provided as pail 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 specialpurpose processors.

Claims

What is claimed is:

1. A method implemented in a user equipment (UE), the method comprising: initiating, in a connected state of a protocol for controlling radio resources between theUE and a radio access network (RAN), when a position information is outdated and at a time outside an inactive period for conducting position measurement, a procedure for obtaining a new position information; and determining whether to transition to another state of the protocol based at least in part on whether the UE obtains the new position information within a threshold amount of time from the initiating.

2. The method of claim 1, further comprising: when the UE obtains the new position information within the threshold amount of time, remaining in the connected state.

3. The method of claim 2, wherein: the threshold amount of time is a second threshold amount of time that is longer than a first threshold amount of time; the method further comprising: when the UE does not obtain the new position information within the first threshold amount of time, transmitting, to the RAN, a connection reestablishment request message.

4. The method of claim 3, wherein: the connection reestablishment request message includes a reestablishment clause indicating that the position information of the UE is outdated.

5. The method of claim 3, further comprising: concurrently starting, in response to the initiating the procedure, (i) a first timer corresponding to the first threshold amount of time and (ii) a second timer corresponding to the second threshold amount of time of the protocol for controlling radio resources.

6. The method of claim 3, further comprising: starting, in response to the transmitting of the connection reestablishment request message, a reestablishment timer with a value smaller than T311.

7. The method of claim 1, further comprising: when the UE does not obtain the new position information within the threshold amount of time, transitioning to an idle state or inactive state.

8. The method of claim 1, further comprising: transitioning to the idle state or inactive state immediately upon determining that the procedure will not complete prior to the threshold amount of time elapsing since the initiating of the procedure.

9. The method of claim 7 or 8, further comprising: initiating a cell reselection procedure in the idle state.

10. The method of any of the preceding claims, further comprising: receiving an indication that the position information of the UE is outdated from a lower layer.

11. The method of claim 10, wherein the lower layer provides the indication based on a movement of the UE.

12. The method of any of claims 1-9, further comprising: receiving an indication that the position information of the UE is outdated from a Global Navigation Satellite System (GNSS) module of the UE.

13. The method of any of claims 10-12, wherein the RAN has not provided the UE with an inactive period for obtaining position information, prior to the indication that the position information is outdated.

14. The method of claim 13, wherein the inactive period is a Global Navigation Satellite System (GNSS) measurement gap.

15. A user equipment (UE) comprising: a transceiver; and processing hardware configured to implement a method according to any of the preceding claims.

Images