Systems and methods for ntn measurement gap and position fix validity notification

Abstract

A user equipment (UE) receives, in a non-terrestrial network (NTN) cell and while the UE operates in connected state of a protocol for controlling radio resources, a medium access control (MAC) protocol data unit (PDU) indicating (i) a duration of a measurement gap and (ii) a start time of the measurement gap. The UE performs, during the measurement gap and while the UE is in the connected state, a position fix procedure.

Description

SYSTEMS AND METHODS FOR NTN MEASUREMENT GAP AND POSITION FIX VALIDITY NOTIFICATIONCROSS-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 / 540,720, entitled “Systems and Methods for NTN Measurement GAP and Position Fix Validity Notification,” filed on September 27, 2024. 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 non-terrestrial network (NTN) communications (e.g., satellite communications) that enable a user equipment (UE) in the connected state to conduct a position fix (e.g., global navigation satellite system (GNSS) position fix) and report the duration for which the position fix is valid.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 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] 5G technology relies primarily on legacy terrestrial networks. However, 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 systems (UAS) also called drone, balloon, plane,or another suitable apparatus. For simplicity, the discussion below refers to all such apparatus as satellites. In addition to satellites, an NTN can include the sat-gateways that connect the NonTerrestrial Network 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 filtering, 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 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 technologiesrequires 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 NB-IoT device is not able to communicate with the base station and acquire its global navigation satellite system (GNSS) position from the GNSS module at the same time. Therefore, to keep a NB-IoT UE in the connected state, the network needs to provide to the UE, occasionally or periodically, a so- called GNSS measurement gap to the UE, or simply a “measurement gap.” During the GNSS measurement gap, the UE can acquire and / or maintain valid (i.e., not outdated) UE positioning information, which is the prerequisite for staying in the connected state and communicating with the base station.

[0011] In order to provide the UE with a GNSS measurement gap dynamically and quickly, 3GPP has agreed to use a downlink MAC Control Element (CE) to inform the UE of an upcoming aperiodic GNSS measurement gap. However, the details of the MAC CE, as well as the action of the UE upon receiving the MAC CE, are not yet known. Because a configuration MAC CE may use many bits, it is generally desirable to design the format of the MAC CE in a compact manner. Moreover, it is generally desirable for the UE to report the GNSS validity duration (i.e., the duration for which the previous GNSS position fix is valid) in a reliable and efficient manner.SUMMARY

[0012] An example embodiment of the techniques of this disclosure is a position fix method implemented a user equipment (UE). The method comprises receiving, in a non-terrestrial network (NTN) cell and while the UE operates in connected state of a protocol for controlling radio resources, a medium access control (MAC) protocol data unit (PDU) indicating (i) a duration of a measurement gap and (ii) a start time of the measurement gap; and performing, during the measurement gap and while the UE is in the connected state, a position fix procedure.

[0013] Another example embodiment of these techniques is a method implemented in a node of an NTN. The method comprises determining, for a UE operating in a connected state of a protocol for controlling radio resources, a measurement gap; and transmitting, while the UEoperates in the connected state, a medium access control (MAC) protocol data unit (PDU) indicating (i) a duration of a measurement gap and (ii) a start time of the measurement gap.

[0014] Yet another example embodiment of these techniques is a method, performed by a UE, for managing measurement gap timing for the UE while operating in an NTN. The method includes performing an RRC connection establishment procedure with the NTN; receiving, from the NTN while the UE is in a connected state with the NTN, a MAC PDU indicating a duration of a measurement gap; and determining, during the measurement gap and while the UE is in the connected state with the NTN, a position of the UE by performing a position fix procedure. In another implementation, a UE includes one or more processors and is configured to perform the method.

[0015] Still another example embodiment of these techniques is a method implemented in a node of an NTN, for managing measurement gap timing for a UE operating in the NTN. The method includes performing an RRC connection establishment procedure with the UE; and transmitting, to the UE while the UE is in a connected state with the NTN, a MAC PDU indicating a duration of a measurement gap in which the UE, while in the connected state with the NTN, is to determine a position of the UE by performing a position fix procedure. In another implementation, a node of the NTN includes one or more processors and is configured to perform the method.

[0016] Another example embodiment of these techniques is a method, performed by UE, for reporting position fix information to an NTN. The method includes receiving, from the NTN while the UE is in a connected state with the NTN, an indication of an uplink resource that the UE is to use for reporting position fix validity duration; determining, during a measurement gap and while the UE is in the connected state with the NTN, a position of the UE by performing a position fix procedure; and transmitting, to the NTN while the UE is in the connected state with the NTN and using the uplink resource, an indication of a duration for which the determined position is valid. In another implementation, a UE includes one or more processors and is configured to perform the method.

[0017] Yet another example embodiment of these techniques is a method, implemented in a node of an NTN, for facilitating reporting of position fix information by a UE. The method includes transmitting, to the UE while the UE is in a connected state with the NTN, an indicationof an uplink resource that the UE is to use for reporting position fix validity duration; transmitting, to the UE while the UE is in the connected state with the NTN, an indication of a measurement gap in which the UE, while in the connected state with the NTN, is to determine a position of the UE by performing a position fix procedure; and receiving, from the UE using the uplink resource, and while the UE is in the connected state with the NTN, an indication of a duration for which the determined position is valid. In another implementation, a node of the NTN includes one or more processors and is configured to perform the method.

[0018] Another example embodiment of these techniques is wireless communication device comprising a transceiver; and processing hardware configured to implement one of the methods above.BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Fig. 1 A is a block diagram of an example wireless communication system in which a UE and a base station of this disclosure can implement techniques of this disclosure;

[0020] Fig. IB is a block diagram of an example base station, having a centralized unit (CU) and one or more distributed units (DUs), that can operate in the wireless communication system of Fig. 1A;

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

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

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

[0024] 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;

[0025] Fig. 4A depicts an example user plane protocol stack for use with the architecture of Fig. 3A;

[0026] Fig. 4B depicts an example control plane protocol stack for use with the architecture of Fig. 3A;

[0027] Fig. 5A depicts an example timeline demonstrating how a certainUE switches between the connected state and the idle state in accordance with the GNSS validity status;

[0028] Fig. 5B depicts an example timeline in which a base station provides another UE with a measurement gap at a time when the UE needs to conduct a GNSS position fix;

[0029] Fig. 6A is a table including an example set of LCID values that can indicate the format with which downlink MAC CEs notify or inform UEs of upcoming GNSS measurement gaps;

[0030] Fig. 6B depicts an example mapping between a MAC subheader with a specific LCID value and a downlink MAC CE containing either one gap duration or no gap duration for a GNSS measurement gap;

[0031] Fig. 7A depicts an example mapping between a MAC subheader with a specific LCID value and a downlink MAC CE containing a start time of a GNSS measurement gap, a RACH indication, an SR indication, and a gap duration indication;

[0032] Fig. 7B depicts an example downlink MAC CE containing a PRACH configuration and a gap duration for a GNSS measurement gap;

[0033] Fig. 7C depicts an example downlink MAC CE containing a PRACH configuration but no gap duration for the GNSS measurement gap;

[0034] Fig. 7D depicts an example downlink MAC CE containing a gap duration for the GNSS measurement gap but no PRACH configuration;

[0035] Fig. 8A depicts an example mapping between a MAC subheader with a specific LCID value and a downlink MAC CE containing a RACH indication, an SR indication, and a gap duration of a GNSS measurement gap;

[0036] Fig. 8B depicts an example downlink MAC CE containing a PRACH configuration;

[0037] Fig. 9 is a messaging diagram of an example scenario in which a UE receives a downlink MAC CE indicating a gap duration and a start time of a GNSS measurement gap;

[0038] Fig. 10 is a messaging diagram of an example scenario in which a UE receives a downlink signal notifying the UE of an upcoming GNSS measurement gap without indicating the duration of the GNSS measurement gap;

[0039] Fig. 11 is a messaging diagram of an example scenario in which a UE receives a downlink MAC CE notifying the UE of an upcoming GNSS measurement gap and indicating whether the UE can trigger the SR mechanism for reporting a GNSS validity duration;

[0040] Fig. 12 is a messaging diagram of an example scenario in which a UE receives a downlink MAC CE that notifies the UE of an upcoming GNSS measurement gap and includes a dedicated PRACH configuration;

[0041] Fig. 13 is a flow diagram of an example method that can be implemented by a UE to determine the duration of a GNSS measurement gap;

[0042] Fig. 14 is a flow diagram of an example method that can be implemented by a UE to determine the start time of a GNSS measurement gap;

[0043] Fig. 15A is a flow diagram of an example method that can be implemented by a UE to determine whether to use the PUCCH resource to trigger the reporting of the GNSS validity duration;

[0044] Fig. 15B is a flow diagram of an example method that can be implemented by a UE to determine whether to use the common PRACH resource to trigger the reporting of the GNSS validity duration; and

[0045] Fig. 16 is a flow diagram of an example method that can be implemented by a base station to determine whether to use the dedicated PRACH resource to trigger the reporting of the GNSS validity duration.DETAILED DESCRIPTION OF THE DRAWINGS

[0046] Generally, techniques of this disclosure enable a UE to determine an inactive period within which the UE is able to conduct a GNSS position fix without leaving the connected state, and also provide a mechanism for the UE to report the duration of GNSS validity for the UE.

[0047] As used throughout this disclosure, a “GNSS position fix” or “GNSS position fix procedure” generally refers to a procedure that a device (e.g., UE) performs to determine its position based on signals received from GNSS satellites, with the procedure being “successful” if the device obtains a position fix. More generally, a “position fix” or “position fix procedure” refers to a procedure that a device performs to determine its position based on signals receivedfrom any sort of network / nodes, with the procedure being “successful” if the device obtains a position fix. As used throughout this disclosure, “GNSS validity” refers to validity of the GNSS position fix (e.g., “GNSS validity duration” refers to the duration for which the GNSS position fix is valid). While specific examples are provided herein referencing satellite networks and GNSS position fixing (e.g., with the same satellites forming the NTN and supporting GNSS position fix capability), it is understood that these techniques can instead be applied to measurement gaps for GNSS position fixing while the UE is operating in a non-satellite NTN (e.g., drones, balloons, etc.), or to measurement gaps for non-GNSS position fixing (e.g., position fixing based on signals the UE receives from non-satellite NTN nodes or terrestrial nodes) while the UE is operating in a non-satellite NTN. Thus, for example, the techniques disclosed herein for UE reporting of GNSS validity duration may instead be applied for UE reporting of other (non-satellite based) types of position fix validity duration.

[0048] In one implementation, the techniques disclosed here feature a user equipment comprising the following. The user equipment conducts a GNSS position fix upon being triggered by the demand from upper layers for establishing the connection with a base station. The user equipment starts monitoring a GNSS validity duration upon successfully conducting the GNSS position fix, determining when the duration (time period) has elapsed, such as by starting a timer of the duration and determining when the timer expires. The user equipment performs a radio resource control (RRC) Connection Establishment procedure with the base station, and transmits, to the base station, a GNSS validity duration and a GNSS position fix duration. The user equipment receives, from the base station, a MAC PDU including a MAC subheader with the LCID used to indicate or inform an upcoming GNSS measurement gap. The user equipment starts a GNSS measurement gap XI milliseconds after receiving the MAC PDU containing the MAC subheader, where XI is a pre-defined constant integer known to the UE without explicit signaling. The user equipment determines whether the MAC subheader has a corresponding downlink MAC CE included in the MAC PDU, and the downlink MAC CE indicates a gap duration. The user equipment stops or exits the GNSS measurement gap once the GNSS position fix duration reported in the RRC Connection Establishment procedure has elapsed since the start of the GNSS measurement gap.

[0049] In another implementation, the techniques disclosed here feature a user equipment comprising the following. The user equipment conducts a GNSS position fix upon being triggered by the demand from upper layers for establishing the connection with a base station. The user equipment starts monitoring a GNSS validity duration, potentially until the GNSS validity duration elapses, upon successfully conducting the GNSS position fix. The user equipment performs an RRC Connection Establishment procedure with the base station, and transmits, to the base station, a GNSS validity duration and a GNSS position fix duration. The user equipment receives, from the base station, an RRC Connection Reconfiguration message including a SR or a PUCCH configuration, where the SR or the PUCCH configuration provides the UE with the PUCCH resources that the UE can use to request uplink transmission opportunities. The user equipment receives, from the base station, a MAC PDU including a downlink MAC CE that is used to notify or inform an upcoming GNSS measurement gap. The user equipment starts a GNSS measurement gap and conducts a GNSS position fix before the end of the GNSS measurement gap. The user equipment determines whether the downlink MAC CE contains an SR indication indicating the UE can (e.g., is allowed to) use / trigger the SR mechanism for reporting its remaining GNSS validity duration. The user equipment transmits to the BS, an SR signal using the PUCCH resource configured to the UE after the GNSS measurement gap ends. The user equipment receives, from the BS, a PDCCH including an uplink grant that the UE can use to transmit an uplink MAC CE including a remaining GNSS validity duration.

[0050] 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. In this example configuration, the base stations 104 and 106 are associated with satellites, and accordingly operate as NTN RAN nodes. 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.

[0051] 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 thebase 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 5GNR (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., S I 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. The cells 124 and 126 in this example system are NTN cells.

[0052] 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) 1 16.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.

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

[0054] 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 forcontrolling 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.

[0055] 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 transmitter 136 configured to transmit data in the downlink direction. The processing hardware further can include a receiver 134 configured to receive data in the uplink direction.

[0056] A measurement gap manager 138, which can be implemented as a set of instructions stored in the memory of the base station 104 and executable by the processor(s) 132, can implement at least some of the techniques discussed below to perform such operations as determine the duration of a measurement gap, the start time of the measurement gap, and other parameters related to GNSS measurements using GNSS satellites 180. The base station 106 can include generally similar components.

[0057] 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, or process data received by UE 102 in the downlink direction. The processing hardware 150 can also include a transmitter 156 configured to transmit data in the downlink direction. The processing hardware further can include a receiver 154 configured to receive data in the uplink direction. A measurement gap manager 158, which can be implemented as a set of instructions stored in the memory of the UE 102and executable by the processor(s) 152, can implement at least some of the techniques discussed below to process a message indicating the duration of a measurement gap, determine the start time of the measurement gap, determine other parameters related to GNSS measurements using the GNSS satellites 180, etc.

[0058] 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 (e.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.

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

[0060] In some implementations, 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 implementations, the RAN 105 supports Non-Terrestrial Network (NTN) functionality.

[0061] 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).

[0062] 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 172 A 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.

[0063] 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).

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

[0065] 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 206A 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.”

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

[0067] 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 RLC 206B, 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.

[0068] 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).

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

[0070] 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, the NTN control plane protocol stack illustrated in Fig. 4B is also similar to that of the terrestrial network.

[0071] 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).

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

[0073] 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 theUE may become invalid after a certainperiod 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 Rel-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.

[0074] Fig. 5A illustrates an example timeline 500A demonstrating how a certain UE (e.g., a Rel-17 UE) switches between the connected and the idle states in accordance with the GNSS validity status. In this example, the UE attempts to communicate with a BS and therefore conducts a GNSS position fix and obtains its GNSS position together with a GNSS validity duration from the GNSS module, where the GNSS validity duration indicates how long (from to to ti in this example) the obtained GNSS position remains valid. After obtaining the GNSS position, the UE performs 510 an RRC Connection Establishment procedure with the BS and reports, to the BS, the remaining GNSS validity duration and, in some cases, also the GNSS position fix duration during the RRC Connection Establishment procedure. Then the UE remains in the connected state until the GNSS validity duration expires (0 in this example). Upon the expiry of the GNSS validity duration, the UE may transit 530 to the idle state autonomously or upon receiving a RRC Connection Release message transmitted by the BS. In other words, the Connection Release can be network-triggered or UE-triggered. Later, upon another attempt to communicate with the BS, the UE conducts again the GNSS position fix and obtains its GNSS position before establishing the connection with the BS.

[0075] The behavior illustrated in Fig. 5A requires the UE to constantly switch between the idle and connected states, if the data exchange between the UE and the BS would take a long time to complete. As constantly switching between RRC states would result in considerable signaling overheads and UE power consumption, another approach can eliminate the need to which RRC state while conducting the GNSS position fix.

[0076] Fig. 5B illustrates, on a timeline 500B, one such technique, which allows another UE (e.g., a Rel-18 UE) to conduct the GNSS position fix within a gap period referred to as the GNSS measurement gap. The network will not schedule any downlink activity during the gap period,and thus the UE can focus on the GNSS position fix task by temporarily refraing from the cellular communication tasks with the BS. This approach reduces the overhead and the power consumption associated with frequently switching RRC states. In Fig. 5B, the UE receives 520 a downlink MAC CE (GNSS GAP MAC CE), which informs the UE of an upcoming (aperiodic) GNSS measurement gap starting from ti and ending by C. The UE then conducts a GNSS position fix during the GNSS measurement gap and successfully obtains its GNSS position and the associated GNSS validity duration. After the GNSS measurement gap has ended and the UE has resumed it cellular communication tasks, the UE transmits 540 an uplink MAC CE including the remaining GNSS validity duration to the network.

[0077] Further to agreeing that the network should send a downlink MAC CE (denoted as, for example, GNSS GAP MAC CE) to inform the UE of an upcoming aperiodic GNSS measurement gap, it is necessary to define the detailed format and contents of the GNSS GAP MAC CE message. One solution is to indicate the GNSS GAP MAC CE the start time (e.g., ti in Fig. 5B) and the end time (e.g., C in Fig. 5B) of the upcoming GNSS measurement gap.However, as the UE may have already reported / recommended in MSG5 (e.g., the RRCConnectionSetupComplete message) a gap duration that is required to conduct a GNSS position fix, and the network (i.e., BS) would be most likely to provide the GNSS measurement gap having the same gap duration as reported / recommended by the UE, signaling the end time (or the gap duration) in the GNSS GAP MAC CE may produce redundant signaling for most cases. The network may even omit the start time of a GNSS measurement gap in the GNSS GAP MAC CE, if the distance (i.e., the time interval) between the GNSS GAP MAC CE and the beginning of the GNSS measurement gap is a fixed value known to both the UE and the network.

[0078] In addition, as the UE may need to timely report the remaining GNSS validity duration after each GNSS position fix, the available uplink resources in a cell could become insufficient and uplink traffic congestion may occur if a tremendous amount of UEs report the GNSS validity duration simultaneously. If the same downlink MAC CE used to indicate the upcoming GNSS measurement gap can also indicate different options or different uplink resources that the UE can use to report the GNSS validity duration, it would facilitate the network to manage the uplink resources and distribute the uplink traffic loading in a more flexible and dynamic way.

[0079] When the HARQ feedback for the downlink traffic is disabled, the network basically assumes that the reception of the GNSS GAP MAC CE indicating an upcoming GNSS measurement gap is successful after repeating several times the transmissions of the GNSS GAP MAC CE. Therefore, if it is always guaranteed that the GNSS measurement gap will start after a fixed interval upon the last repetition of the GNSS GAP MAC CE transmission, there is no need to signal the start time (e.g., ti in Fig. 5B) of the GNSS measurement gap in the GNSS GAP MAC CE. Moreover, if the network determines to use the GNSS position fix duration reported / recommended by the UE as the duration of a GNSS measurement gap, there is also no need to signal the end time or the gap duration of the GNSS measurement gap in the GNSS GAP MAC CE. Therefore, it is possible that the GNSS GAP MAC CE contains no payload (i.e., is an empty MAC CE), as the start time and duration of the upcoming GNSS measurement gap can be known to the UE already upon receiving the MAC CE.

[0080] Regardless of whether the GNSS GAP MAC CE needs to indicate the start time of an upcoming GNSS measurement gap, the MAC subheader associated with the GNSS GAP MAC CE can be designed in a way that it can refer to two different formats of the GNSS GAP MAC CE: one with gap duration and one without gap duration, as shown in Fig. 6A. In Fig. 6A, although two Logic Channel Identity (LCID) values ‘01101’ and ‘01110’ are used to refer to the two different formats of the GNSS GAP MAC CE, it is also possible that any two LCID values ranging from 01011 to 01110 (the LCID values reserved in 3GPP TS 36.321, vl7.5.0) are used to refer to the two different formats of the GNSS GAP MAC CE. In some implementations, instead of using two different LCID values to refer to the two different formats of the GNSS GAP MAC CE, the MAC subheader uses two different eLCID (extended LCID) values to refer to the two different formats of the GNSS GAP MAC CE, where the eLCID values are indicated by a 6-bit field. Yet in some implementations, the MAC subheader only uses one eLCID value to refer to the only one format of the GNSS GAP MAC CE.

[0081] Assuming that the GNSS GAP MAC CE only needs to indicate the duration / length of a GNSS measurement gap, the format of the MAC subheader associated with GNSS GAP MAC CE is illustrated in Fig. 6B. The MAC subheader in Fig. 6B is a one-octet (i.e., 8-bit) subheader containing one bit for reserved (‘R’), one bit for indicating the size of the Length field (‘F2’), one bit for indicating if more fields are present in the MAC header (‘E’), and 5 bits for indicatingthe type of the corresponding MAC CE (‘LCID’). As there is no Length field present in the MAC subheader, the F2 is always 0 in Fig. 6B. In Fig. 6B, a specific LCID value (e.g., ‘01101’) of the MAC subheader corresponds to an empty GNSS GAP MAC CE (i.e., the GNSS GAP MAC CE contains no payload) while another specific LCID value (e.g., ‘01110’) of the MAC subheader corresponds to an one-octet GNSS GAP MAC CE having 4 bits used to indicate the Gap Duration (‘GD’) and 4 reserved bits, where the actual gap duration (in seconds) corresponding to each GD index value can be found at the bottom of Fig. 6B.

[0082] On the other hand, if the GNSS GAP MAC CE needs to indicate the start time of a GNSS measurement gap, in addition to the other information including the gap duration of the GNSS measurement gap, the format of the MAC subheader associated with the GNSS GAP MAC CE can be a two-octet (i.e., 16-bit) subheader with an additional 1 -bit field ‘F’ used to indicate the size of the Length field and an additional ‘Length’ field, as illustrated in Fig. 7A. As in this example the Length field occupies 7 bits, the F field is equal to 0 according to TS 38.321 (V17.5.0).

[0083] Similar to Fig. 6B, the MAC subheader in Fig. 7A uses a specific LCID value (e.g., 01110) to refer to the GNSS GAP MAC CE, where the GNSS GAP MAC CE may contain one reserved bit ‘R’, 4 bits for indicating the start time of a GNSS measurement gap (‘X2’), one bit for indicating whether the MAC CE includes the dedicated Physical Random Access Channel (PRACH) resource configuration (‘RI’), one bit for indicating whether the UE can (e.g., is allowed to) trigger the Scheduling Request (SR) mechanism for reporting the remaining GNSS validity duration (‘SI’), and one bit for indicating whether the gap duration of the GNSS measurement gap is equivalent to the GNSS position fix duration reported / recommended by the UE in MSG5 (‘GI’).

[0084] If the network enables the HARQ feedback for the UE to acknowledge the downlink transmission including the GNSS GAP MAC CE transmission, the X2 field of the GNSS GAP MAC CE may indicate the wait time period (e.g., in milliseconds) that the UE needs to wait before starting the GNSS measurement gap, which may be counted after the subframe / slot in which the UE has transmitted the HARQ feedback for the GNSS GAP MAC CE. Otherwise, the X2 field may indicate the wait time period (in milliseconds) that the UE needs to wait before starting the GNSS measurement gap, which may be counted after the subframe / slot in which UEhas received the GNSS GAP MAC CE or has received the final copy of the GNSS GAP MAC CE if it is repeatedly transmitted. In one implementation, if the X’ field indicates a value k (ranging from 0 to 15), indicating that the UE needs to wait k + 1 milliseconds before starting the GNSS measurement gap, which may be counted either after the subframe / slot UE has transmitted the HARQ feedback for the GNSS GAP MAC CE, or after the subframe / slot UE has received the final copy of the GNSS GAP MAC CE.

[0085] If both the RI field and GI field are equivalent to ‘ 1 ’, the GNSS GAP MAC CE can become a 3-octet MAC CE as illustrated in Fig. 7B, where a 10-bit ‘PRACEF field and a 4-bit GD field are appended after the first octet. The PRACH field is used to indicate the dedicated PRACH resource that the UE can use to initiate the uplink transmission for reporting the remaining GNSS validity duration, which further contains a 6-bit preamble index and a 4-bit PRACH mask index. The preamble index is used to point to one of the up to 64 PRACH preamble sequences that the UE can use, and the PRACH mask index is used to indicate the resource in time and frequency domain that can be used by the UE to transmit the PRACH preamble. The GD filed appended after the first octet is the same GD field illustrated in Fig. 6B. Fig. 7C illustrates another example of the GNSS GAP MAC CE, where the RI field is equivalent to 1 and the GI field is equivalent to 0, and hence a PRACH field is appended in the 2ndand 3rdoctet. Fig. 7D illustrates another example of the GNSS GAP MAC CE, where the RI field is equivalent to 0 and the GI field is equivalent to 1, and hence a GD field is appended in the 2ndoctet.

[0086] Fig. 8A illustrates another alternative in which the GNSS GAP MAC CE does not indicate the start time of the GNSS measurement gap, but indicates the GD, RI, and SI fields. In case the RI field is equivalent to 1, a PRACH field will be appended in the 2ndand 3rdoctet, as illustrated in Fig. 8B.

[0087] In some implementations, the GNSS GAP MAC CE contains an extra field used to indicate the time UE needs to wait before reporting the remaining GNSS validity duration to the BS, after the UE has exited the GNSS measurement gap and resumed the cellular communication tasks. The extra field could indicate a value range ranging from a minimum value to a maximum value, and the UE picks randomly a value from the value range. The value picked by the UE indicates the number of time units (e.g., slots, subframes, milliseconds, seconds, etc.) that the UEneeds to wait before the UE can report the remaining GNSS validity duration to the BS, after the end of the GNSS measurement gap.

[0088] Next, several example scenarios in which a UE and / or a RAN perform the techniques of this disclosure for supporting GNSS measurement in the connected state are discussed with reference to Figs. 9-12. Generally speaking, similar events in Figs. 9-12, as well as the subsequent flow diagrams of Figs. 13-16 are labeled with the similar reference numbers (more particularly, sharing two least significant digits), with differences discussed below where appropriate. For example, event 904 is similar to events 1004, 1104, and 1204 as well as blocks 1304, 1404, 1504, and 1604; event 916 is similar to event 1016, 1116, and 1216; event 1040 is similar to event 1040; event 948 is similar to event 1048, event 980 is similar to events 1080, 1180, and 1280; etc.

[0089] Fig. 9 is a messaging diagram of an example scenario 900 in which a UE receives a downlink MAC CE indicating a gap duration and a start time of a GNSS measurement gap. A UE 102 initially operates 902 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 then performs 904 a GNSS position fix operation by measuring / receiving the signal emitted by GNSS satellites (e g., GNSS satellite 308, which can operate as one of the GNSS satellites 180 of Fig. 1A), triggered by the demand from upper layer(s) for establishing the connection with the BS 104. Upon conducting the GNSS position fix successfully, the UE obtains its GNSS position and an associated GNSS validity duration (i.e., gnss-validity Duration), and then starts monitoring the GNSS validity duration, potentially until the GNSS validity duration elapses. In particular, the UE determines when the duration (time period) has elapsed, for example by starting a timer for the duration and determining when the timer expires. After obtaining its GNSS position, the UE 102 transmits 906 a 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 908 a 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 910 a RRC Connection Setup Complete message to the BS, and then transitions 914 to the connected state. The RRC Connection Setup Complete message transmitted in 910 includes a remaining GNSS validity duration and a GNSS position fixduration, where the GNSS position fix duration is a duration requested by the UE 102 for conducting a GNSS position fix successfully. The events 906, 908, and 910 are collectively referred to in Fig. 9 as a procedure for “RRC Connection Establishment, GNSS validity duration reporting, and GNSS position fix duration reporting” 912. In one implementation, the procedure 912 can be referred to as a procedure for “RRC Connection Resume, GNSS validity duration reporting, and GNSS position fix duration reporting”, if the RRC Connection Request message in 906 is replaced by the RRC Connection Resume Request message, the RRC Connection Setup message in 908 is replaced by the RRC Connection Resume message, and the RRC Connection Setup Complete message in 910 is replaced by the RRC Connection Resume Complete message. In another implementation, the procedure 912 can be referred to as a procedure for “RRC Connection Re-establishment, GNSS validity duration reporting, and GNSS position fix duration reporting”, if the RRC Connection Request message in 906 is replaced by the RRC Connection Reestablishment Request message, the RRC Connection Setup message in 908 is replaced by the RRC Connection Reestablishment message, and the RRC Connection Setup Complete message in 910 is replaced by the RRC Connection Reestablishment Complete message.

[0090] After receiving the RRC Connection Setup Complete message, the BS 104 determines 916 a GNSS measurement gap for the UE 102, based on the remaining GNSS validity duration and the GNSS position fix duration reported by the UE 102 in the RRC Connection Setup Complete message. The BS 104 then transmits 920 a downlink MAC CE named GNSS GAP MAC CE to the UE 102, where the GNSS GAP MAC CE includes at least a Gap Duration (i.e., GD) of an upcoming GNSS measurement gap and a wait time period / time length (i.e., X2) that the UE 102 needs to wait before starting the GNSS measurement gap. In response to the GNSS GAP MAC CE, the UE 102 transmits 930 a positive HARQ feedback to the BS 104, and then starts counting the time the UE 102 has waited since transmitting the HARQ feedback. Once the time the UE 102 has waited reaches or exceeds the amount of time indicated by X2, the UE 102 starts 940 a GNSS measurement gap and suspends its cellular communication tasks. In another implementation, in response to the GNSS GAP MAC CE, the UE 102 starts counting the time the UE 102 has waited since receiving the last copy of the GNSS GAP MAC CE, but does not transmit the HARQ feedback to the BS 104.

[0091] The UE 102 determines the end time of the GNSS measurement gap based on the start time of the gap and the gap duration indicated by GD value, and then conducts 946 a GNSS position fix while the UE 102 is still within the GNSS measurement gap. While determining when to conduct the GNSS position fix in measurement gap, UE 102 needs to make sure the GNSS position fix can be conducted completely before the end time of the GNSS measurement gap-10092] After conducting the GNSS position fix, the UE 102 resumes (after event 946 and / or 948) its cellular communication tasks at the end of the GNSS measurement gap. As the UE 102 has obtained a new GNSS position and a new GNSS validity duration associated to the new GNSS position, the UE 102 transmits 980 an uplink MAC CE (e.g., GNSS validity duration MAC CE) including the remaining GNSS validity duration to the BS 104.

[0093] Fig. 10 is a messaging diagram 1000 of an example scenario in which a UE receives a downlink signal notifying an upcoming GNSS measurement gap without indicating the duration of the GNSS measurement gap. The message diagram in Fig. 10 is similar to that in Fig. 9. In particular, events 1002, 1004, 1012, 1014, 1016, 1040, 1046, 1048, and 1080 are similar to events 902, 904, 912, 914, 916, 940, 946, 948, and 980, respectively. The differences are discussed below.

[0094] After the BS 104 has determined a GNSS measurement gap for the UE 102, it transmits 1021 to the UE 102, a MAC PDU including a MAC subheader with a specific LCID used to notifying an upcoming GNSS measurement gap. The MAC PDU including the MAC subheader is transmitted to the UE 102 a short moment before the start of the GNSS measurement gap, where the short moment can a fixed / constant value (e.g., 6 ms or 12 ms) known to both the UE 102 and BS 104. In another implementation, the BS 104 transmits 1021 to the UE 102, a GNSS GAP MAC CE including a one-bit indication ‘GF, which indicates the gap duration of the GNSS measurement gap is equivalent to the GNSS position fix duration reported / recommended by the UE 102 in the procedure 1012. In another implementation, the BS 104 transmits 1021, to the UE 102, a GNSS GAP MAC CE including no gap duration value.

[0095] A short moment (e.g., 6 ms or 12 ms) after receiving the MAC subheader or the GNSS GAP MAC CE in 1021, the UE 102 starts / enters 1024 the GNSS measurement gap and suspends its cellular communication tasks. In another implementation, the UE 102 starts / enters 1024 theGNSS measurement gap and suspends its cellular communication tasks, a short moment (e.g., 6 ms or 12 ms) after transmitting the HARQ feedback acknowledging the received MAC subheader or acknowledging the received GNSS GAP MAC CE. The UE 102 also determines the end time of the GNSS measurement gap based on the start time of the gap and the GNSS position fix duration reported by the UE 102 in during procedure 1212 (see event 910 of Fig. 9), and conducts 1046 a GNSS position fix while the UE 102 is still within the GNSS measurement gap-

[0096] Fig. 11 is a messaging diagram 1100 of an example scenario in which a UE receives a downlink MAC CE notifying an upcoming GNSS measurement gap and indicating whether the UE can use / trigger the SR mechanism for reporting a GNSS validity duration. The message diagram in Fig. 11 is similar to that in Fig. 9. In particular, events 1102, 1104, 1112, 1 1 14, 1116, 1140, 1146, 1148, and 1180 are similar to events 902, 904, 912, 914, 916, 940, 946, 948, and 980, respectively. The differences are discussed below.

[0097] After the BS 104 has determined a GNSS measurement gap for the UE 102, the BS 104 may transmit 1118 to the UE 102, an RRC Connection Reconfiguration message including a SR or a Physical Uplink Control Channel (PUCCH) configuration, where the SR / PUCCH configuration indicates the PUCCH resource(s) that the UE 102 can use to request for being scheduled with uplink resources. The BS 104 also transmits 1122 a GNSS GAP MAC CE including a gap duration (i.e., GD) of the upcoming GNSS measurement gap and an indication (i.e., SI) indicating the UE 102 can (e g., is allowed to) use / trigger the SR mechanism for reporting the GNSS validity duration. The GNSS GAP MAC CE is transmitted to the UE 102 a short moment before the start of the GNSS measurement gap, where the short moment can a fixed / constant value (e.g., 6 ms or 12 ms) known to both the UE 102 and BS 104.

[0098] A short moment (e.g., 6 ms or 12 ms) after receiving the GNSS GAP MAC CE in 1122, the UE 102 starts / enters 1024 the GNSS measurement gap and suspends its cellular communication tasks. In another implementation, the UE 102 starts / enters 1140 the GNSS measurement gap and suspends its cellular communication tasks, a short moment (e.g., 6 ms or 12 ms) after transmitting the HARQ feedback acknowledging the received GNSS GAP MAC CE. The UE 102 also determines the end time of the GNSS measurement gap based on the starttime of the gap and the gap duration indicated in the GNSS GAP MAC CE, and conducts 1146 a GNSS position fix while the UE 102 is still within the GNSS measurement gap.

[0099] After the UE 102 has exited 1148 the GNSS measurement gap, the UE 102 can transmit an uplink signal to the BS 104 for requesting uplink resources. If the UE 102 has received an RRC Connection Reconfiguration message including a SR / PUCCH configuration in 1118, the UE 102 can utilize the allocated PUCCH resource to transmit 1170A the uplink signal. In response to the PUCCH transmission, the BS 104 transmits 1172A a response including an uplink grant to the UE 102 via the Physical Downlink Control Channel (PDCCH). On the other hand, if the UE 102 has never received an RRC Connection Reconfiguration message including a SR / PUCCH configuration, the UE 102 can utilize the common PRACH resources to transmit 1170B the uplink signal. In response to the common PRACH preamble, the BS 104 transmits 1172B a Random Access Response (RAR) message including an uplink grant to the UE 102.After receiving the uplink grant via either 1172A or 1172B, the UE 102 transmits 1180 an uplink MAC CE including a remaining GNSS validity duration to the BS 104, through the uplink grant provided by the BS 104.

[0100] Fig. 12 is a messaging diagram 1200 of an example scenario in which a UE receives a downlink MAC CE notifying an upcoming GNSS measurement gap and including a dedicated PRACH configuration. The message diagram in Fig. 12 is similar to that in Fig. 9. In particular, events 1202, 1204, 1212, 1214, 1216, 1240, 1246, 1248, and 1280 are similar to events 902, 904, 912, 914, 916, 940, 946, 948, and 980, respectively. The differences are discussed below.

[0101] After the BS 104 has determined a GNSS measurement gap for the UE 102, the BS 104 transmits 1223 a GNSS GAP MAC CE including a gap duration (i.e., GD) of the upcoming GNSS measurement gap and a dedicated PRACH resource that the UE 102 can use to trigger the reporting of the GNSS validity duration. The GNSS GAP MAC CE is transmitted to the UE 102 a short moment before the start of the GNSS measurement gap, where the short moment can a fixed / constant value (e.g., 6 ms, 12 ms, or other predetermined amount of time) known to both the UE 102 and BS 104.

[0102] A short moment (e.g., 6 ms or 12 ms) after receiving the GNSS GAP MAC CE in 1122, the UE 102 starts / enters 1024 the GNSS measurement gap and suspends its cellular communication tasks. In another implementation, the UE 102 starts / enters 1240 the GNSSmeasurement gap and suspends its cellular communication tasks, a short moment (e.g., 6 ms, 12 ms, or other predetermined amount of time) after transmitting the HARQ feedback acknowledging the received GNSS GAP MAC CE. The UE 102 also determines the end time of the GNSS measurement gap based on the start time of the gap and the gap duration indicated in the GNSS GAP MAC CE, and conducts 1246 a GNSS position fix while the UE 102 is still within the GNSS measurement gap.

[0103] After the UE 102 has exited 1248 the GNSS measurement gap, the UE 102 transmits 1274 a dedicated PRACH preamble to the BS 104 for requesting uplink resources. In response to the dedicated PRACH preamble, the BS 104 transmits 1276 a Random Access Response (RAR) message including an uplink grant to the UE 102. In another implementation, in response to the dedicated PRACH preamble, the BS 104 transmits 1276 a PDCCH including an uplink grant to the UE 102. After receiving the uplink grant, the UE 102 transmits 1280 an uplink MAC CE including a remaining GNSS validity duration to the BS 104, through the uplink grant provided by the BS 104.

[0104] Fig. 13 is a flow diagram 1300 of an example method that can be implemented by an UE (e.g., UE 102 in this disclosure), for determining the duration of a GNSS measurement gap. Initially, at block 1304, 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 1304, the UE also obtains a GNSS validity duration and starts monitoring the GNSS validity duration, potentially until the GNSS validity duration elapses, upon successfully conducting the GNSS position fix.

[0105] After obtaining a valid GNSS position, the UE performs, at block 1312, a 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 RRC Connection Establishment procedure performed at block 1312 can be replaced by the RRC Connection Reestablishment procedure or by the RRC Connection Resume procedure. After that, the flow proceeds to block 1320, where the UE receives, from the BS, a MAC PDU including a MAC subheader with the LCID used to indicate or inform an upcoming GNSS measurement gap-

[0106] In response to the MAC subheader containing the LCID used to indicate or inform of an upcoming GNSS measurement gap, the UE starts, at block 1340, a GNSS measurement gap XI milliseconds after receiving the MAC PDU containing the MAC subheader, where XI is a wait time period (e.g., a pre-defined constant integer such as 6 or 12) known to the UE without explicit signaling. After that, the flow proceeds to the decision block 1351, where the UE determines whether the MAC subheader has a corresponding downlink MAC CE included in the MAC PDU, and the downlink MAC CE indicates a gap duration.

[0107] If the determination at the decision block 1351 is positive (i.e., the MAC subheader has a corresponding downlink MAC CE included in the MAC PDU, and the downlink MAC CE indicates a gap duration), the flow proceeds to the block 1348A, where the UE stops or exits the GNSS measurement gap once the gap duration indicated in the downlink MAC CE has elapsed since the start of the GNSS measurement gap. On the other hand, if the determination at the decision block 1351 is negative (i.e., the MAC subheader does not have a corresponding downlink MAC CE, or the MAC subheader has a corresponding downlink MAC CE but the downlink MAC CE does not indicate a gap duration), the flow proceeds to the block 1348B, where the UE stops or exits the GNSS measurement gap once the GNSS position fix duration reported at block 1312 has elapsed since the start of the GNSS measurement gap.

[0108] Fig. 14 is a flow diagram 1400 of an example method that can be implemented by an UE (e.g., UE 102 in this disclosure), for determining the start time of a GNSS measurement gap. Initially, at block 1404, 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 1404, the UE also obtains a GNSS validity duration and starts monitoring the GNSS validity duration, potentially until the GNSS validity duration elapses, upon successfully conducting the GNSS position fix.

[0109] After obtaining a valid GNSS position, the UE performs, at block 1412, a 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 RRC Connection Establishment procedure performed at block 1412 can be replaced by the RRC Connection Reestablishment procedure or by the RRC Connection Resume procedure. After that, the flow proceeds to block 1420, where the UE receives, from the BS, a MAC PDU including adownlink MAC CE (denoted as, for example, GNSS GAP MAC CE) that is used to notify or inform an upcoming GNSS measurement gap, where the downlink MAC CE corresponds to a MAC subheader with a specific LCID included in the MAC PDU.

[0110] After that, the flow proceeds to the decision block 1452, where the UE determines whether the downlink MAC CE contains an X2 value that is used to indicate the wait time period that the UE needs to wait before starting the GNSS measurement gap. If the determination at the decision block 1452 is positive (i.e., the downlink MAC CE contains an X2 value), the flow proceeds to the block 1430, where the UE transmits to the BS, a HARQ feedback acknowledging the reception of the MAC PDU. Later, the UE starts, at block 1440A, a GNSS measurement gap X2 milliseconds after transmitting the HARQ feedback. In some implementations, when the determination at the decision block 1452 is positive, the UE skips the actions in the block 1430 and starts, at block 1440A, a GNSS measurement gap X2 milliseconds after receiving the MAC PDU containing the downlink MAC CE used to indicate or inform an upcoming GNSS measurement gap.[0U1] On the other hand, if the determination at the decision block 1452 is negative (i.e., the downlink MAC CE does not contain a X2 value), the flow proceeds to the block 1340, where the UE starts a GNSS measurement gap XI milliseconds after receiving the MAC PDU containing the downlink MAC CE, where XI is a predetermined amount of time (e.g., pre-defined constant integer such as 6 or 12) known to the UE without explicit signaling.

[0112] Fig. 15A is a flow diagram 1500A of an example method that can be implemented by an UE (e.g., UE 102 in this disclosure), for determining whether to use the PUCCH resource to trigger the reporting of the GNSS validity duration. Initially, at block 1504, 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 1504, the UE also obtains a GNSS validity duration and starts monitoring the GNSS validity duration, potentially until the GNSS validity duration elapses, upon successfully conducting the GNSS position fix.

[0113] After obtaining a valid GNSS position, the UE performs, at block 1512, a 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 RRC Connection Establishment procedure performed at block 1512 can be replaced by the RRCConnection Reestablishment procedure or by the RRC Connection Resume procedure. After transiting to the connected state, the UE receives from the BS, at block 1518, an RRC Connection Reconfiguration message including a SR or a PUCCH configuration, where the SR or the PUCCH configuration provides the UE with the PUCCH resources that the UE can use to request uplink transmission opportunities.

[0114] The flow then proceeds to block 1520, where the UE receives, from the BS, a MAC PDU including a downlink MAC CE (denoted as, for example, GNSS GAP MAC CE) that is used to notify or inform an upcoming GNSS measurement gap, where the downlink MAC CE corresponds to a MAC subheader with a specific LCID included in the MAC PDU. In response to the reception of the downlink MAC CE, the UE starts, at block 1540, a GNSS measurement gap and conducts a GNSS position fix before the end of the GNSS measurement gap. Upon successfully conducting the GNSS position fix, the UE obtains a valid GNSS position associated with a GNSS validity duration, and starts monitoring the GNSS validity duration, potentially until the GNSS validity duration elapses.

[0115] After that, the flow proceeds to the decision block 1553, where the UE determines whether the downlink MAC CE contains an SR indication (i.e., SI) indicating the UE can (e.g., is allowed to) use / trigger the SR mechanism for reporting its remaining GNSS validity duration. If the determination at the decision block 1553 is positive (i.e., UE can use / trigger the SR mechanism for reporting its remaining GNSS validity duration), the flow proceeds to the block 1570A, where the UE transmits to the BS, an SR signal using the PUCCH resource configured to the UE at block 1518, after the GNSS measurement gap ends. At a later time, the UE receives from the BS, at block 1572A, a PDCCH including an uplink grant that the UE can use to transmit, at block 1580A, an uplink MAC CE including a remaining GNSS validity duration.

[0116] On the other hand, if the determination at the decision block 1553 is negative (i.e., UE cannot (e g., is not allowed to) use / trigger the SR mechanism for reporting its remaining GNSS validity duration), the flow proceeds to the block 1572A directly, where the UE waits for a PDCCH (transmitted by the BS) including an uplink grant that the UE can use to transmit an uplink MAC CE including a remaining GNSS validity duration.

[0117] Fig. 15B is a flow diagram 1500B of an example method that can be implemented by an UE (e.g., UE 102 in this disclosure), for determining whether to use the common PRACHresource to trigger the reporting of the GNSS validity duration. The flow diagram in Fig. 15B is similar to that in Fig. 15A, with the differences discussed below. After performing a RRC Connection Establishment procedure with a BS at block 1512, the UE does not receive an RRC Connection Reconfiguration message including a SR or a PUCCH configuration before receiving, at block 1520, a MAC PDU including a downlink MAC CE that is used to notify or inform an upcoming GNSS measurement gap.

[0118] After the UE has conducted successfully a GNSS position fix in the GNSS measurement gap and obtained a GNSS validity duration, the flow proceeds to the decision block 1553, where the UE determines whether the downlink MAC CE contains an SR indication (i.e., SI) indicating the UE can (e.g., is allowed to) use / trigger the SR mechanism for reporting its remaining GNSS validity duration. If the determination at the decision block 1553 is positive (i.e., UE can (e.g., is allowed to) use / trigger the SR mechanism for reporting its remaining GNSS validity duration), the flow proceeds to the block 1570B, where the UE transmits to the BS, a common PRACH preamble after the GNSS measurement gap ends. At a later time, the UE receives from the BS, at block 1572B, a RAR message including an uplink grant that the UE can use to transmit, at block 1580B, a C-RNTI MAC CE and an uplink MAC CE including a remaining GNSS validity duration.

[0119] On the other hand, if the determination at the decision block 1553 is negative (i.e., UE cannot (e.g., is not allowed to) use / trigger the SR mechanism for reporting its remaining GNSS validity duration), the flow proceeds to the block 1572A, where the UE waits for a PDCCH (transmitted by the BS) including an uplink grant that the UE can use to transmit an uplink MAC CE including a remaining GNSS validity duration.

[0120] Fig. 16 is a flow diagram 1600 of an example method that can be implemented by an UE (e.g., UE 102 in this disclosure), for determining whether to use the dedicated PRACH resource to trigger the reporting of the GNSS validity duration. Initially, at block 1604, 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 1604, the UE also obtains a GNSS validity duration and starts monitoring the GNSS validity duration, potentially until the GNSS validity duration elapses, upon successfully conducting the GNSS position fix.

[0121] After obtaining a valid GNSS position, the UE performs, at block 1612, a 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 RRC Connection Establishment procedure performed at block 1612 can be replaced by the RRC Connection Reestablishment procedure or by the RRC Connection Resume procedure. At a later time after being in the connected state, the UE receives from the BS, at block 1620, a MAC PDU including a downlink MAC CE (denoted as, for example, GNSS GAP MAC CE) that is used to notify or inform an upcoming GNSS measurement gap, where the downlink MAC CE corresponds to a MAC subheader with a specific LCID included in the MAC PDU.

[0122] In response to the reception of the downlink MAC CE, the UE starts, at block 1640, a GNSS measurement gap and conducts a GNSS position fix before the end of the GNSS measurement gap. Upon successfully conducting the GNSS position fix, the UE obtains a valid GNSS position associated with a GNSS validity duration, and starts monitoring the GNSS validity duration, potentially until the GNSS validity duration elapses.

[0123] After that, the flow proceeds to the decision block 1655, where the UE determines whether the downlink MAC CE contains a dedicated PRACH configuration providing the UE with the dedicated PRACH resource(s) for reporting its remaining GNSS validity duration. If the determination at the decision block 1655 is positive (i.e., UE is provided with the dedicated PRACH resource(s)), the flow proceeds to the block 1632, where the UE transmits to the BS, the dedicated PRACH preamble configured to the UE, after the GNSS measurement gap ends. At a later time, the UE receives from the BS, at block 1634, an RAR message or a PDCCH including an uplink grant that the UE can use to transmit, at block 1680A, an uplink MAC CE including a remaining GNSS validity duration.

[0124] On the other hand, if the determination at the decision block 1655 is negative (i.e., UE is not provided with the dedicated PRACH resource(s)), the flow proceeds to the block 1672A directly, where the UE waits for a PDCCH (transmitted by the BS) including an uplink grant that the UE can use to transmit an uplink MAC CE including a remaining GNSS validity duration.

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

[0126] Example 1. A method, performed by a user equipment (UE), for managing measurement gap timing for the UE while operating in a non-terrestrial network (NTN), the method comprising: performing a radio resource control (RRC) connection establishment procedure with the NTN; receiving, from the NTN while the UE is in a connected state with the NTN, a medium access control (MAC) protocol data unit (PDU) indicating a duration of a measurement gap; and determining, during the measurement gap and while the UE is in the connected state with the NTN, a position of the UE by performing a position fix procedure.

[0127] Example 2. The method of example 1, wherein the MAC PDU further indicates a start time of the measurement gap.

[0128] Example 3. The method of example 2, wherein the MAC PDU indicates the start time by including a control element (CE) that indicates a wait time period.

[0129] Example 4. The method of example 3, wherein the measurement gap starts (i) the wait time period after the UE receives the MAC PDU, or (ii) the wait time period after the UE transmits hybrid automatic repeat request (HARQ) feedback to the NTN in response to receiving the MAC PDU.

[0130] Example 5. The method of example 1, wherein the MAC PDU does not indicate a start time of the measurement gap, and wherein the measurement gap starts (i) a predetermined amount of time after the UE receives the MAC PDU, or (ii) the predetermined amount of time after the UE transmits hybrid automatic repeat request (HARQ) feedback to the NTN in response to receiving the MAC PDU.

[0131] Example 6. The method of any one of examples 1-5, wherein the MAC PDU indicates the duration by including a control element (CE) indicating the duration.

[0132] Example 7. The method of any one of examples 1-5, wherein the MAC PDU indicates the duration by including a control element (CE) indicating that the UE is to use a duration reported by the UE.

[0133] Example 8. The method of example 7, wherein performing the RRC connection establishment procedure with the NTN includes transmitting, to the NTN, an RRC message including the duration reported by the UE.

[0134] Example 9. The method of example 8, wherein the RRC message is an RRC connection setup complete message.

[0135] Example 10. The method of any one of examples 1-7, further comprising: before performing the RRC connection establishment procedure with the NTN and while the UE is in an idle state, (i) determining an earlier position of the UE by performing an earlier position fix procedure, and (ii) obtaining a validity duration for the earlier position of the UE, wherein performing the RRC connection establishment procedure includes transmitting, to the NTN, an RRC message indicating the validity duration for the earlier position of the UE.

[0136] Example 11. The method of any one of examples 1-10, wherein: the MAC PDU includes a MAC subheader; and the MAC subheader indicates whether a MAC control element (CE) of the MAC PDU indicates the duration of the measurement gap.

[0137] Example 12. The method of example 11, wherein a logical channel identifier (LCID) or an extended LCID (eLCID) of the MAC subheader indicates whether a MAC CE of the MAC PDU indicates the duration of the measurement gap.

[0138] Example 13. The method of any one of examples 1-12, wherein the MAC PDU indicates an uplink resource the UE can use to report position fix validity duration; and the method further comprises transmitting, to the NTN and via the uplink resource, a validity duration for the position of the UE.

[0139] Example 14. The method of example 13, wherein the MAC PDU indicates the uplink resource the UE can use to report position fix validity duration by (i) indicating that the UE can use a scheduling request (SR) mechanism to report position fix validity duration, or (ii) indicating a physical random access channel (PRACH) in a MAC control element (CE) of the MAC PDU.

[0140] Example 15. The method of any one of examples 1-12, wherein: the MAC PDU indicates a time period the UE is to wait before reporting position fix validity duration; and the method further comprises transmitting, to the NTN and after waiting for the time period, a validity duration for the position of the UE.

[0141] Example 16. The method of any one of examples 1-15, wherein: the NTN is a satellite network; and performing the position fix procedure includes performing a global navigationsatellite system (GNSS) position fix procedure based on signals the UE receives from satellites of the NTN.

[0142] Example 17. A user equipment (UE) comprising one or more processors and configured to perform the method of any one of examples 1-16.

[0143] Example 18. A method, performed by a node of a non-terrestrial network (NTN), for managing measurement gap timing for a user equipment (UE) operating in the NTN, the method comprising: performing a radio resource control (RRC) connection establishment procedure with the UE; and transmitting, to the UE while the UE is in a connected state with the NTN, a medium access control (MAC) protocol data unit (PDU) indicating a duration of a measurement gap in which the UE, while in the connected state with the NTN, is to determine a position of the UE by performing a position fix procedure.

[0144] Example 19. The method of example 18, wherein the MAC PDU further indicates a start time of the measurement gap.

[0145] Example 20. The method of example 19, wherein the MAC PDU indicates the start time by including a control element (CE) that indicates a wait time period.

[0146] Example 21. The method of example 20, wherein the measurement gap starts (i) the wait time period after the UE receives the MAC PDU, or (ii) the wait time period after the UE transmits hybrid automatic repeat request (HARQ) feedback to the NTN in response to receiving the MAC PDU.

[0147] Example 22. The method of example 18, wherein the MAC PDU does not indicate a start time of the measurement gap, and wherein the measurement gap starts (i) a predetermined amount of time after the UE receives the MAC PDU, or (ii) the predetermined amount of time after the UE transmits hybrid automatic repeat request (HARQ) feedback to the NTN in response to receiving the MAC PDU.

[0148] Example 23. The method of any one of examples 18-22, wherein the MAC PDU indicates the duration by including a control element (CE) indicating the duration.

[0149] Example 24. The method of any one of examples 18-22, wherein the MAC PDU indicates the duration by including a control element (CE) indicating that the UE is to use a duration reported by the UE.

[0150] Example 25. The method of example 24, wherein: performing the RRC connection establishment procedure with the UE includes receiving, from the UE, an RRC message including the duration reported by the UE.

[0151] Example 26. The method of example 25, wherein the RRC message is an RRC connection setup complete message.

[0152] Example 27. The method of any one of examples 18-24, wherein performing the RRC connection establishment procedure includes receiving, from the UE, an RRC message indicating a validity duration for an earlier position of the UE, and wherein the method further comprises: before transmitting the MAC PDU to the UE, determining the measurement gap based on the validity duration for the earlier position of the UE.

[0153] Example 28. The method of any one of examples 18-27, wherein: the MAC PDU includes a MAC subheader; and the MAC subheader indicates whether a MAC control element (CE) of the MAC PDU indicates the duration of the measurement gap.

[0154] Example 29. The method of example 28, wherein a logical channel identifier (LCID) or an extended LCID (eLCID) of the MAC subheader indicates whether a MAC CE of the MAC PDU indicates the duration of the measurement gap.

[0155] Example 30. The method of any one of examples 18-29, wherein: the MAC PDU indicates an uplink resource the UE can use to report position fix validity duration; and the method further comprises receiving, from the UE and via the uplink resource, a validity duration for the position of the UE.

[0156] Example 31. The method of example 30, wherein the MAC PDU indicates the uplink resource the UE can use to report position fix validity duration by (i) indicating that the UE can use a scheduling request (SR) mechanism to report position fix validity duration, or (ii) indicating a physical random access channel (PRACH) in a MAC control element (CE) of the MAC PDU.

[0157] Example 32. The method of any one of examples 18-29, wherein: the MAC PDU indicates a time period the UE is to wait before reporting position fix validity duration; and the method further comprises receiving, from the UE after the UE waits for the time period, a validity duration for the position of the UE.

[0158] Example 33. The method of any one of examples 18-32, wherein: the NTN is a satellite network; and the position fix procedure is a global navigation satellite system (GNSS) position fix procedure based on signals the UE receives from satellites of the NTN.

[0159] Example 34. A node of an NTN, the node comprising one or more processors and configured to perform the method of any one of examples 18-33.

[0160] Example 35. A method, performed by a user equipment (UE), for reporting position fix information to a non -terrestrial network (NTN), the method comprising: receiving, from the NTN while the UE is in a connected state with the NTN, an indication of an uplink resource that the UE is to use for reporting position fix validity duration; determining, during a measurement gap and while the UE is in the connected state with the NTN, a position of the UE by performing a position fix procedure; and transmitting, to the NTN while the UE is in the connected state with the NTN and using the uplink resource, an indication of a duration for which the determined position is valid.

[0161] Example 36. The method of example 35, wherein the receiving includes receiving a radio resource control (RRC) message that indicates the uplink resource.

[0162] Example 37. The method of example 36, wherein the RRC message is an RRC connection reconfiguration message.

[0163] Example 38. The method of example 36 or 37, wherein the uplink resource is a scheduling request (SR) configuration or a physical uplink control channel (PUCCH) configuration.

[0164] Example 39. The method of any one of examples 36-38, further comprising: receiving, from the NTN while the UE is in the connected state with the NTN, a medium access control (MAC) protocol data unit (PDU) indicating a duration of the measurement gap.

[0165] Example 40. The method of example 39, wherein the MAC PDU indicates that the UE can use a scheduling request (SR) mechanism to report the duration for which the determined position is valid.

[0166] Example 41. The method of example 35, wherein the receiving includes receiving a medium access control (MAC) protocol data unit (PDU) indicating the uplink resource and a duration of the measurement gap.

[0167] Example 42. The method of example 41, wherein the uplink resource is a physical random access channel (PRACH) configuration.

[0168] Example 43. The method of example 42, wherein: the uplink resource is a dedicated PRACH preamble; and the transmitting the indication of the duration for which the determined position is valid using the uplink resource includes (i) transmitting the dedicated PRACH preamble to the NTN, (ii) receiving from the NTN a response that includes an uplink grant, and (iii) transmitting, to the NTN and using the uplink grant, the indication of the duration for which the determined position is valid.

[0169] Example 44. The method of any one of examples 35-43, wherein the duration for which the determined position is valid is a remaining duration for which the determined position is valid.

[0170] Example 45. The method of any one of examples 35-44, wherein: the NTN is a satellite network; and performing the position fix procedure includes performing a global navigation satellite system (GNSS) position fix procedure based on signals the UE receives from satellites of the NTN.

[0171] Example 46. A user equipment (UE) comprising one or more processors and configured to perform the method of any one of examples 35-45.

[0172] Example 47. A method, performed by a node of a non-terrestrial network (NTN), for facilitating reporting of position fix information by a user equipment (UE), the method comprising: transmitting, to the UE while the UE is in a connected state with the NTN, an indication of an uplink resource that the UE is to use for reporting position fix validity duration; transmitting, to the UE while the UE is in the connected state with the NTN, an indication of a measurement gap in which the UE, while in the connected state with the NTN, is to determine a position of the UE by performing a position fix procedure; and receiving, from the UE using the uplink resource, and while the UE is in the connected state with the NTN, an indication of a duration for which the determined position is valid.

[0173] Example 48. The method of example 47, wherein the transmitting the indication of the uplink resource includes transmitting a radio resource control (RRC) message that indicates the uplink resource.

[0174] Example 49. The method of example 48, wherein the RRC message is an RRC connection reconfiguration message.

[0175] Example 50. The method of example 48 or 49, wherein the uplink resource is a scheduling request (SR) configuration or a physical uplink control channel (PUCCH) configuration.

[0176] Example 51. The method of any one of examples 48-50, wherein: the transmitting the indication of the measurement gap includes transmitting a medium access control (MAC) protocol data unit (PDU) that indicates the measurement gap.

[0177] Example 52. The method of example 51, wherein the MAC PDU indicates that the UE can use a scheduling request (SR) mechanism to report the duration for which the determined position is valid.

[0178] Example 53. The method of example 47, wherein the transmitting the indication of the uplink resource and the transmitting the indication of the measurement gap collectively include transmitting a medium access control (MAC) protocol data unit (PDU) indicating the uplink resource and the measurement gap.

[0179] Example 54. The method of example 53, wherein the uplink resource is a physical random access channel (PRACH) configuration.

[0180] Example 55. The method of example 54, wherein: the uplink resource is a dedicated PRACH preamble; and the receiving the indication of the duration for which the determined position is valid using the uplink resource includes (i) receiving the dedicated PRACH preamble from the UE, (ii) transmiting to the UE a response that includes an uplink grant, and (iii) receiving, from the UE using the uplink grant, the indication of the duration for which the determined position is valid.

[0181] Example 56. The method of any one of examples 47-55, wherein the duration for which the determined position is valid is a remaining duration for which the determined position is valid.

[0182] Example 57. The method of any one of examples 47-56, further comprising: determining an additional measurement gap based on the duration for which the determined position is valid.

[0183] Example 58. The method of any one of examples 47-57, wherein the transmitting the indication of the measurement gap includes transmitting an indication of a duration of the measurement gap.

[0184] Example 59. The method of any one of examples 47-58, wherein: the NTN is a satellite network; and the position fix procedure is a global navigation satellite system (GNSS) position fix procedure based on signals the UE receives from satellites of the NTN.

[0185] Example 60. A node of an NTN, the node comprising one or more processors and configured to perform the method of any one of examples 47-59.

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

[0187] 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 be replaced 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”.

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

[0189] Certain implementations 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 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.

[0190] 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 specialpurpose processors.

Claims

What is claimed is:a1. A position fix method implemented a user equipment (UE), the method comprising: receiving, in a non -terrestrial network (NTN) cell and while the UE operates in connected state of a protocol for controlling radio resources, a medium access control (MAC) protocol data unit (PDU) indicating (i) a duration of a measurement gap and (ii) a start time of the measurement gap; and performing, during the measurement gap and while the UE is in the connected state, a position fix procedure.

2. The method of claim 1, wherein: the MAC PDU indicates the start time of the measurement gap by including an element that indicates a wait time period relative to the receiving of the MAC PDU.

3. The method of claim 1, wherein: the MAC PDU indicates the start time of the measurement gap by including an element that indicates a wait time period relative to transmitting, from the UE and in the NTN cell, an acknowledgement of the MAC PDU.

4. The method of claim 1, wherein: the MAC PDU indicates the start time of the measurement gap by arriving a predefined amount of time prior to the start of the time of the measurement gap.

5. The method of claim 1, wherein: the MAC PDU indicates the duration of the measurement gap by including an indication that the UE is to use a duration value previously reported by the UE.

6. The method of claim 5, further comprising:performing, prior to the receiving of the MAC PDU, a radio resource control (RRC) connection establishment procedure with the NTN cell, including transmitting, in the NTN cell, an RRC message including the duration value.

7. The method of any of the preceding claims, wherein: the MAC PDU includes a MAC subheader; and the MAC subheader indicates that a MAC control element (CE) of the MAC PDU indicates the duration of the measurement gap.

8. The method of claim 7, wherein: the MAC subheader includes a logical channel identifier (LCID) or an extended LCID (eLCID) that indicates that the MAC CE indicates the duration of the measurement gap.

9. The method of any of the preceding claims, wherein: the MAC PDU includes an indication that the UE is allowed to trigger a scheduling request (SR) mechanism for reporting remaining measurement validity duration.

10. The method of any of the preceding claims, wherein: the MAC PDU includes a dedicated Physical Random Access Channel (PRACH) resource configuration.

11. A method implemented in a node of a non-terrestrial network (NTN), the method comprising: determining, for a UE operating in a connected state of a protocol for controlling radio resources, a measurement gap; and transmitting, while the UE operates in the connected state, a medium access control (MAC) protocol data unit (PDU) indicating (i) a duration of a measurement gap and (ii) a start time of the measurement gap.

12. The method of claim 11, wherein:the MAC message indicates the start time of the measurement gap by including an element that indicates a wait time period relative to (i) the transmitting of the MAC PDU or (ii) receiving, from the UE, an acknowledgement of the MAC PDU.

13. The method of claim 11, wherein: the transmitting of the MAC PDU that indicates the start time of the measurement gap includes transmitting of the MAC PDU a predefined amount of time prior to the start of the time of the measurement gap.

14. The method of claim 11, wherein: the MAC PDU indicates the duration of the measurement gap by including an indication that the UE is to use a duration value previously reported by the UE.

15. A wireless communication device comprising: a transceiver; and processing hardware configured to implement a method of any of the preceding claims.

Images