Systems and methods for NTN measurement gap and location validity notification

Abstract

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

Description

[0001] Cross-reference to related applications

[0002] This application claims priority and benefit to Provisional U.S. Patent Application No. 63 / 540,720, filed September 27, 2024, entitled "Systems and Methods for NTN Measurement GAP and Position Fix Validity Notification". The entire contents of the provisional application are hereby expressly incorporated by reference. Technical Field

[0003] This disclosure generally relates to wireless communications, and more specifically, to non-terrestrial network (NTN) communications (e.g., satellite communications) that enable a connected user equipment (UE) to perform position fix (e.g., Global Navigation Satellite System (GNSS) positioning) and report the duration of the effective position. Background Technology

[0004] This background description is provided for the purpose of presenting the general context of this disclosure. The work of the currently attributed inventors (to the extent described in this background section) and aspects of the specification that might not have been considered prior art at the time of filing are neither expressly nor impliedly acknowledged as prior art relative to this disclosure.

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

[0006] 5G technology primarily relies on traditional terrestrial networks. However, the 3rd Generation Partnership Project (3GPP) has proposed extending 5G communications to non-terrestrial networks (NTNs) using either 5G New Radio (NR) technology or Long Term Evolution (LTE) technology tailored for narrowband Internet of Things (NB-IoT) or enhanced machine-type communications (eMTC) scenarios. In an NTN, RF transceivers are mounted on satellites, unmanned aerial vehicle systems (UAS) (also known as drones), balloons, aircraft, or other suitable equipment. For simplicity, the following discussion will refer to all such equipment as satellites. In addition to satellites, an NTN may also include satellite gateways connecting non-terrestrial networks to public data networks, feeder links between satellite gateways and satellites, service links between satellites, and inter-satellite links (ISLs) when satellites form a constellation.

[0007] Satellites can be classified into several types based on their altitude, orbit, and footprint size. These types include low Earth orbit (LEO) satellites, medium Earth orbit (LEO) satellites, geostationary orbit (GEO) satellites, UAS platform satellites (including High Altitude Platform Stations (HAPS), and highly elliptical orbit (HEO) satellites. GEO satellites are also known as geosynchronous orbit (GSO) satellites, and LEO / MEO satellites are also known as non-GSO (NGSO) satellites.

[0008] GSO satellites can communicate with one or more satellite gateways deployed over the satellite's target coverage area (e.g., a region or even a continent). Non-GSO satellites can communicate with one or more serving satellite gateways at different times. NTN is designed to ensure service and feeder link continuity between connected serving satellite gateways, while having sufficient duration for mobility anchoring and handover.

[0009] Satellites can support transparent or regenerative (with onboard processing) payloads and typically generate several beams for a given service area defined by a field of view. The coverage area of ​​the beams is usually elliptical in shape and depends on the onboard antenna configuration and elevation angle. For transparent payload implementations, satellites can apply RF filtering, frequency conversion, and amplification without altering the waveform signal. For regenerative payload implementations, satellites can apply RF filtering, frequency conversion and amplification, demodulation and decoding, routing, and encoding / modulation. This approach effectively implements most of the functions of a base station (e.g., a gNB).

[0010] NB-IoT and eMTC technologies are particularly well-suited for IoT devices operating in remote areas with limited or no terrestrial connectivity. Such IoT devices can be used across a variety of industries, including, for example: transportation (marine, road, rail, aviation) and logistics; solar, oil and gas extraction; utilities; agriculture; environmental monitoring; and mining. However, to ensure the required IoT connectivity, the deployment of these technologies necessitates satellite connectivity to provide coverage beyond terrestrial deployments. Satellite NB-IoT or eMTC is thus defined in a way that complements terrestrial deployments.

[0011] In these and other applications, due to hardware constraints, NB-IoT devices cannot simultaneously communicate with a base station and obtain their GNSS position from a Global Navigation Satellite System (GNSS) module. Therefore, to keep the NB-IoT UE connected, the network needs to periodically or periodically provide the UE with so-called GNSS measurement gaps, or simply "measurement gaps." During GNSS measurement gaps, the UE can acquire and / or maintain valid (i.e., non-timeout) UE positioning information, a prerequisite for remaining connected and communicating with the base station.

[0012] To dynamically and quickly inform UEs of GNSS measurement gaps, 3GPP has agreed to use a downlink MAC control element (CE) to inform UEs of upcoming aperiodic GNSS measurement gaps. However, the details of the MAC CE and the UE's actions upon receiving it are not yet known. Since configuring the MAC CE can use many bits, it is generally expected that the MAC CE format be designed in a compact manner. Furthermore, it is generally expected that UEs report the duration of GNSS validity (i.e., the duration of previous valid GNSS positioning) in a reliable and efficient manner. Summary of the Invention

[0013] An example embodiment of the technology disclosed herein is a user equipment (UE) implementing a positioning method. The method includes: receiving a Media Access Control (MAC) Protocol Data Unit (PDU) indicating (i) the duration of a measurement gap and (ii) the start time of the measurement gap in a non-terrestrial network (NTN) cell and while the UE is operating in a connected state of a protocol for controlling radio resources; and performing a positioning process during the measurement gap and while the UE is in the connected state.

[0014] Another example embodiment of these technologies is a method implemented in an NTN node. The method includes: determining a measurement gap for a UE operating in a connected state of a protocol for controlling radio resources; and transmitting a Media Access Control (MAC) Protocol Data Unit (PDU) indicating (i) the duration of the measurement gap and (ii) the start time of the measurement gap while the UE is operating in the connected state.

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

[0016] Another example embodiment of these technologies is a method implemented in a node of an NTN for managing measurement gap timing for a UE operating within the NTN. The method includes: performing an RRC connection establishment procedure with the UE; and sending a MAC PDU indicating the duration of a measurement gap to the UE while the UE is connected to the NTN, during which the UE will determine its location by performing a positioning procedure while connected to the NTN. In another implementation, the NTN node includes one or more processors configured to perform the method.

[0017] Another example embodiment of these technologies is a method performed by a UE for reporting location information to an NTN. The method includes: receiving from the NTN an indication of uplink resources that the UE will use to report the duration of location validity while the UE is connected to the NTN; determining the location of the UE by performing a location procedure during a measurement gap and while the UE is connected to the NTN; and sending an indication of the determined duration of location validity to the NTN while the UE is connected to the NTN and using the uplink resources. In another implementation, the UE includes one or more processors configured to perform the method.

[0018] Another example embodiment of these technologies is a method implemented in an NTN node for facilitating UE reporting of location information. The method includes: sending an indication to the UE, while the UE is connected to the NTN, of uplink resources that the UE will use to report the duration of location validity; sending an indication to the UE, while the UE is connected to the NTN, of a measurement gap in which the UE will determine its location by performing a location procedure while connected to the NTN; and using the uplink resources and receiving from the UE an indication of the duration of validity of the determined location while the UE is connected to the NTN. In another implementation, the NTN node includes one or more processors configured to perform the method.

[0019] Another example embodiment of these technologies is a wireless communication device, which includes a transceiver and processing hardware configured to implement one of the methods described above. Attached Figure Description

[0020] Figure 1A This is a block diagram of an example wireless communication system in which the UE and base station of this disclosure can implement the techniques of this disclosure;

[0021] Figure 1B It is possible Figure 1A A block diagram of an example base station operating in a wireless communication system, the base station having a centralized unit (CU) and one or more distributed units (DU);

[0022] Figure 2A This is a block diagram of an example protocol stack. Figure 1A The UE communicates with the base station according to the protocol stack;

[0023] Figure 2B This is a block diagram of an example protocol stack. Figure 1A The UE communicates with the CU and DU according to the protocol stack;

[0024] Figure 3A This is a block diagram of an example NTN node with a transparent payload implementation.

[0025] Figure 3B This is a block diagram of an example NTN node with a transparent payload implementation, where the base station is connected to multiple satellites via the same satellite gateway;

[0026] Figure 4A Describing the use of with Figure 3A An example user plane protocol stack used in conjunction with the architecture;

[0027] Figure 4B Describing the use of with Figure 3A An example control plane protocol stack used in conjunction with the architecture;

[0028] Figure 5A An example timeline is depicted, showing how a particular UE switches between a connected state and an idle state based on the GNSS availability status.

[0029] Figure 5B An example timeline is depicted, in which the base station provides a measurement gap to another UE when the UE needs to perform GNSS positioning;

[0030] Figure 6A It is a table containing an example set of LCID values, which can indicate the format used by the downlink MAC CE to notify or inform the UE of upcoming GNSS measurement gaps;

[0031] Figure 6B An example mapping is depicted between a MAC sub-header with a specific LCID value and a downlink MAC CE containing a gap duration of GNSS measurement gaps or not containing a gap duration;

[0032] Figure 7AAn example mapping is depicted between a MAC sub-header with a specific LCID value and a downlink MAC CE containing the start time of the GNSS measurement gap, RACH indication, SR indication, and gap duration indication;

[0033] Figure 7B An example downlink MAC CE, including PRACH configuration and gap duration for GNSS measurement gaps, is depicted;

[0034] Figure 7C An example downlink MAC CE depicting the gap duration including PRACH configuration but excluding GNSS measurement gaps;

[0035] Figure 7D An example downlink MAC CE is depicted, including the gap duration of GNSS measurement gaps but excluding PRACH configuration;

[0036] Figure 8A An example mapping is depicted between a MAC sub-header with a specific LCID value and a downlink MAC CE containing RACH indication, SR indication, and gap duration of GNSS measurement gap;

[0037] Figure 8B A sample downlink MAC CE with PRACH configuration is depicted;

[0038] Figure 9 This is a message passing diagram of an example scenario in which the UE receives a downlink MACCE indicating the gap duration and start time of the GNSS measurement gap;

[0039] Figure 10 This is a message passing diagram of an example scenario in which the UE receives a downlink signal that notifies the UE of an upcoming GNSS measurement gap without indicating the duration of the GNSS measurement gap;

[0040] Figure 11 This is a message passing diagram of an example scenario in which the UE receives a notification to the UE of an upcoming GNSS measurement gap and instructs the UE whether it can trigger the SR mechanism to report the duration of GNSS availability;

[0041] Figure 12 This is a message passing diagram of an example scenario in which the UE receives a downlink MAC CE that notifies the UE of an upcoming GNSS measurement gap and includes a dedicated PRACH configuration;

[0042] Figure 13 This is a flowchart of an example method that can be implemented by the UE to determine the duration of a GNSS measurement gap;

[0043] Figure 14 This is a flowchart of an example method that can be implemented by the UE to determine the start time of the GNSS measurement gap;

[0044] Figure 15A This is a flowchart of an example method that can be implemented by the UE to determine whether to use PUCCH resources to trigger a report on the duration of GNSS effectiveness;

[0045] Figure 15B This is a flowchart illustrating an example method that can be implemented by the UE to determine whether to use public PRACH resources to trigger a report on the duration of GNSS effectiveness; and

[0046] Figure 16 This is a flowchart of an example method that can be implemented by the base station to determine whether to use dedicated PRACH resources to trigger a report on the duration of GNSS validity. Detailed Implementation

[0047] Generally, the technology disclosed herein enables the UE to determine inactive periods during which the UE can perform GNSS positioning without leaving the connected state, and also provides the UE with a mechanism for reporting the duration of GNSS validity.

[0048] As used throughout this disclosure, "GNSS positioning" or "GNSS positioning process" generally refers to a device (e.g., a UE) performing a process to determine its location based on signals received from GNSS satellites, wherein the process is "successful" if the device achieves positioning. More generally, "positioning" or "positioning process" refers to a device performing a process to determine its location based on signals received from any kind of network / node, wherein the process is "successful" if the device achieves positioning. As used throughout this disclosure, "GNSS validity" refers to the validity of GNSS positioning (e.g., "GNSS validity duration" refers to the duration for which GNSS positioning is valid). While specific examples of reference satellite networks and GNSS positioning are provided herein (e.g., where the same satellites form an NTN and support GNSS positioning capabilities), it should be understood that these techniques can alternatively be applied to measurement gaps for GNSS positioning when the UE is operating in a non-satellite NTN (e.g., a drone, balloon, etc.), or to measurement gaps for non-GNSS positioning (e.g., positioning based on signals received by the UE from a non-satellite NTN node or a ground node) when the UE is operating in a non-satellite NTN. Therefore, for example, the techniques disclosed herein for UE reporting GNSS validity duration can be alternatively applied to UE reporting other (non-satellite-based) types of positioning validity duration.

[0049] In one implementation, the technology disclosed herein includes a user equipment (UE) comprising the following: The UE performs GNSS positioning triggered by a request from an upper layer to establish a connection with a base station. After successfully performing GNSS positioning, the UE begins monitoring the GNSS validity duration, thereby determining when the duration (time period) has elapsed, for example, by starting a timer for the duration and determining when the timer expires. The UE performs a Radio Resource Control (RRC) connection establishment procedure with the base station and sends the GNSS validity duration and GNSS positioning duration to the base station. The UE receives from the base station a MAC PDU including a MAC sub-header with an LCID indicating or informing of an upcoming GNSS measurement gap. The UE initiates a GNSS measurement gap X1 milliseconds after receiving the MAC PDU containing the MAC sub-header, where X1 is a predefined constant integer known to the UE without explicit signaling. The UE determines whether the MAC sub-header has a corresponding downlink MAC CE included in the MAC PDU, and the downlink MAC CE indicates the gap duration. When the GNSS positioning duration reported during the RRC connection establishment procedure has elapsed since the start of the GNSS measurement gap, the UE stops or exits the GNSS measurement gap.

[0050] In another implementation, the technology disclosed herein includes a user equipment (UE) comprising the following: The UE performs GNSS positioning triggered by a request from an upper layer to establish a connection with a base station. After successfully performing GNSS positioning, the UE begins monitoring the GNSS validity duration, possibly until the GNSS validity duration has elapsed. The UE performs an RRC connection establishment procedure with the base station and sends the GNSS validity duration and GNSS positioning duration to the base station. The UE receives from the base station an RRC connection reconfiguration message including an SR or PUCCH configuration, wherein the SR or PUCCH configuration provides the UE with PUCCH resources that the UE can use to request uplink transmission opportunities. The UE receives from the base station a MAC PDU including a downlink MAC CE for notifying or informing of an upcoming GNSS measurement gap. The UE begins the GNSS measurement gap and performs GNSS positioning before the GNSS measurement gap ends. The UE determines whether the downlink MAC CE contains an SR indication indicating that the UE can (e.g., is permitted) use / trigger an SR mechanism to report its remaining GNSS validity duration. After the GNSS measurement gap ends, the UE uses the PUCCH resources configured for the UE to send an SR signal to the BS. The user equipment receives a PDCCH from the BS, which includes uplink grants that the UE can use to send uplink MAC CEs, including the remaining GNSS validity duration.

[0051] First refer to Figure 1A Example wireless communication system 100 includes UE 102, base station (BS) 104, base station 106, and core network (CN) 110. Base stations 104 and 106 can operate in RAN 105 connected to core network (CN) 110. In this example configuration, base stations 104 and 106 are associated with satellites and therefore operate as NTN RAN nodes. For example, CN 110 can be implemented as an evolved packet core (EPC) 111 or a fifth-generation (5G) core (5GC) 160. In another example, CN 110 can also be implemented as a sixth-generation (6G) core.

[0052] Base station 104 covers cell 124, and base station 106 covers cell 126. If base station 104 is a gNB, then cell 124 is an NR cell. If base station 104 is an ng-eNB or eNB, then cell 124 is an Evolved Universal Terrestrial Radio Access (E-UTRA) cell. Similarly, if base station 106 is a gNB, then cell 126 is an NR cell, and if base station 106 is an ng-eNB or eNB, then cell 126 is an E-UTRA cell. Cells 124 and 126 may be located in the same Radio Access Network Notification Area (RNA) or different RNAs. Generally, RAN 105 may include any number of base stations, and each of the base stations may cover one, two, three, or any other suitable number of cells. UE 102 may support at least 5G NR (or simply "NR") or E-UTRA air interface to communicate with base stations 104 and 106. Each of base stations 104 and 106 can be connected to CN 110 via an interface (e.g., an S1 or NG interface). Base stations 104 and 106 can also be interconnected via an interface used to interconnect NG RAN nodes (e.g., an X2 or Xn interface). In this example system, cells 124 and 126 are NTN cells.

[0053] Among other components, EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. SGW 112 is generally configured to deliver user plane packets related to audio calls, video calls, Internet services, etc., and MME 114 is configured to manage authentication, registration, paging, and other related functions. PGW 116 provides connectivity from the UE to one or more external packet data networks (e.g., Internet networks and / or Internet Protocol (IP) Multimedia Subsystem (IMS) networks). 5GC 160 includes User Plane Functions (UPF) 162, Access and Mobility Management Functions (AMF) 164, and / or Session Management Functions (SMF) 166. Generally speaking, UPF 162 is configured to transmit user plane packets related to audio calls, video calls, Internet services, etc., AMF 164 is configured to manage authentication, registration, paging and other related functions, and SMF 166 is configured to manage PDU sessions.

[0054] like Figure 1A As shown, base station 104 supports cell 124, and base station 106 supports cell 126. Cells 124 and 126 may partially overlap, allowing UE 102 to select, reselect, or switch from one cell to another. For direct message or information exchange, base stations 104 and 106 may support X2 or Xn interfaces. Generally, CN 110 can connect to any suitable number of base stations supporting NR cells and / or EUTRA cells.

[0055] As discussed in detail below, when the radio connection between UE 102 and RAN 105 is suspended, for example, when UE 102 is operating in an inactive or idle state of the protocol used to control the radio resources between UE 102 and RAN 105, UE 102 and / or RAN 105 can utilize the techniques of this disclosure. For clarity, the examples below refer to the RRC_INACTIVE or RRC_IDLE states of the RRC protocol.

[0056] Base station 104 is equipped with processing hardware 130, which may include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable storage medium storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, processing hardware 130 may include dedicated processing units. In an example implementation, processing hardware 130 includes a processor 132 to process data that base station 104 will transmit in the downlink direction or to process data received by base station 104 in the uplink direction. Processing hardware 130 may also include a transmitter 136 configured to transmit data in the downlink direction. Processing hardware may also include a receiver 134 configured to receive data in the uplink direction.

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

[0058] UE 102 is equipped with processing hardware 150, which may include one or more general-purpose processors (such as a CPU) and a non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or dedicated processing units. In an example implementation, processing hardware 150 includes a processor 152 to process data that UE 102 will transmit in the uplink direction or to process data that UE 102 will receive in the downlink direction. Processing hardware 150 may also include a transmitter 156 configured to transmit data in the downlink direction. Processing hardware may also include a receiver 154 configured to receive data in the uplink direction. Measurement gap manager 158, which may be implemented as a set of instructions stored in the memory of UE 102 and executable by processor 152, may implement at least some of the techniques discussed below to process messages indicating the duration of measurement gaps, determine the start time of measurement gaps, determine other parameters related to GNSS measurements using GNSS satellite 180, etc.

[0059] Figure 1BExample distributed or decomposed implementations of any one or more of base stations 104, 106 are depicted. In this implementation, base stations 104, 106 include a central unit (CU) 172 and one or more distributed units (DUs) 174. CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the general-purpose processor, and / or dedicated processing units. For example, CU 172 may include a PDCP controller, an RRC controller, and / or an RRC inactivity controller. In some implementations, CU 172 may include a radio link control (RLC) controller configured to manage or control one or more RLC operations or processes. In other implementations, CU 172 does not include an RLC controller.

[0060] Each of DU 174 also includes processing hardware, which may 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 dedicated processing units. For example, the processing hardware may include: a MAC controller configured to manage or control one or more MAC operations or procedures (e.g., random access procedures); and / or an RLC controller configured to manage or control one or more RLC operations or procedures. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

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

[0062] In some implementations, CU 172 may include a logical node CU-CP 172A that hosts the control plane portion of the PDCP protocol for CU 172. CU 172 may also include a logical node CU-UP 172B that hosts the user plane portion of the PDCP protocol and / or the Service Data Adaptation Protocol (SDAP) protocol for CU 172. CU-CP 172A may send control information (e.g., RRC messages, F1 application protocol messages), and CU-UP 172B may send data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0063] CU-CP 172A can connect to multiple CU-UP 172Bs via the E1 interface. CU-CP 172A selects the appropriate CU-UP 172B for the service requested by UE 102. In some implementations, a single CU-UP 172B can connect to multiple CU-CP 172As via the E1 interface. CU-CP 172A can connect to one or more DU 174s via the F1-C interface. CU-UP 172Bs can connect to one or more DU 174s via the F1-U interface under the control of the same CU-CP 172A. In some implementations, a DU 174 can connect to multiple CU-UP 172Bs under the control of the same CU-CP 172A. In such implementations, the connectivity between CU-UP 172Bs and DU 174s is established by CU-CP 172A using bearer context management functions.

[0064] Figure 2A An example protocol stack 200 is shown in a simplified manner, which UE 102 can use to communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106).

[0065] In example stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NRPHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data delivery services to the Serving Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer. Figure 2A (Not shown in the image) provides data transfer services. In some implementations, UE 102 supports both EUTRA and NR stacks, such as... Figure 2A As shown, this supports handover between EUTRA and NR base stations and / or supports DCs via EUTRA and NR interfaces. Additionally, as... Figure 2A As shown, UE 102 can support NR PDCP 210 layering on EUTRA RLC 206A, and SDAP sublayer 212 layering on NR PDCP sublayer 210.

[0066] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 (e.g., from an Internet Protocol (IP) layer layered directly or indirectly on PDCP layers 208 or 210) receive packets that can be referred to as Service Data Units (SDUs), and (e.g., to RLC layers 206A or 206B) output packets that can be referred to as Protocol Data Units (PDUs). For simplicity, except where the difference between SDU and PDU is relevant, this disclosure refers to both SDU and PDU as "packets".

[0067] On the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide signaling radio bearer (SRB) or RRC sublayer ( Figure 2A (Not shown) to exchange, for example, RRC messages or Non-Access Stratum (NAS) messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide data radio bearers (DRBs) to support data exchange. The data exchanged on NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0068] Figure 2B An example protocol stack 250 is shown in a simplified manner, illustrating how UE 102 can communicate with DU (e.g., DU 174) and CU (e.g., CU 172). The radio protocol stack 200 is functionally split, as described by... Figure 2B The radio protocol stack 250 is shown in the diagram. At either base station 104 or 106, the CU can maintain all control and upper-layer functionality (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower-layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connectivity to the 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0069] Figure 3AA type of NTN deployment, known as a transparent payload architecture, is illustrated, involving a satellite gateway 302 and a “transparent” satellite 304 for extending the range of the Uu interface. Satellite 304 implements frequency conversion and radio frequency (RF) amplifiers in both the uplink and downlink directions. The satellite functions similarly to an analog RF repeater. Therefore, satellite 304 relays the Uu radio interface from the feeder link (between the NTN gateway and the satellite) to the serving 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 Uu, and NTN gateway 302 supports all necessary functions for forwarding signals from the Uu interface. NTN gateway 302 can operate at the same location as base station (e.g., eNB, gNB) 104, or at a distance connected to base station 104 via a wired link. More than one NTN gateway can also be connected to the base station. Different transparent satellites can be connected to the same base station on the ground via the same NTN gateway or via different NTN gateways. Figure 3B This illustrates a scenario 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 using two different Physical Cell IDs (PCIs) to cover the Earth's surface.

[0070] although Figures 3A to 3B The transparent payload architecture shown has been a recent focus of 3GPP development, but the eNB function, based on its regenerative payload architecture operating on a satellite, also represents a possible future NTN deployment. In this architecture, the Uu exists only between the satellite and the UE. Generally, the techniques disclosed herein can be applied to both transparent and regenerative payload architectures.

[0071] Figure 4A The diagram illustrates the NTN user plane protocol stack (transparent payload architecture) involving UE 102, satellite 304, NTN gateway 302, eNB or gNB 104 / 106, and S-GW 114 or UPF 162. The NTN user plane protocol stack diagram is similar to that of a terrestrial network (TN), with two new nodes added in the middle of the Uu interface: satellite 304 and NTN gateway 302. Similarly, Figure 4B The NTN control plane protocol stack shown is similar to the protocol stack of a terrestrial network.

[0072] Regarding satellite mobility modes, NTN supports three types of service links: (i) Earth-fixed: configured by a beam that continuously covers the same geographic area (e.g., in the case of GEO / GSO satellites); (ii) Quasi-Earth-fixed: configured by a beam that covers one geographic area for a limited time period and a different geographic area for another time period (e.g., in the case of LEO / MEO satellites that can use controllable beams); or (iii) Earth-mobile: configured by a beam that slides across the Earth's surface (e.g., in the case of LEO / MEO satellites using fixed or uncontrollable beams).

[0073] Using LEO / MEO satellites, eNBs or gNBs can provide quasi-fixed cell coverage or mobile cell coverage. Using GEO satellites, eNBs or gNBs can provide fixed cell coverage.

[0074] When transmitting any signal / data to the BS in the uplink direction, each UE must apply a UE-specific timing advance (TA) calculated based on the distance between the UE and connected satellites, ensuring that all uplink transmissions arrive precisely at the expected timing scheduled by the BS. Therefore, each UE must track its own location and the locations of its connected satellites. To avoid interfering with other UEs or the BS, a UE is not allowed to perform any uplink transmissions if it does not currently have a valid UE location or valid satellite location information. Since a UE's location may become invalid after a certain period (depending on the UE's mobility), the UE may need to periodically obtain its GNSS location from the GNSS module to continue performing uplink transmissions with the BS. In fact, the Rel-17 specification (e.g., TS 36.300 v17.5.0) stipulates that a UE should obtain its valid GNSS location before connecting to an NTN cell and should transition to an idle state after a GNSS location timeout is detected. This is because NB-IoT devices (UEs) cannot perform mobile communication tasks with the BS while accessing the GNSS module.

[0075] Figure 5AExample timeline 500A is shown, illustrating how a particular UE (e.g., a Rel-17 UE) switches between a connected state and an idle state based on GNSS validity status. In this example, the UE attempts to communicate with the BS and thus performs GNSS positioning, obtaining its GNSS position and GNSS validity duration from the GNSS module, where the GNSS validity duration indicates how long the obtained GNSS position remains valid (from t0 to t1 in this example). After obtaining the GNSS position, the UE performs the 510 RRC connection establishment procedure with the BS, reporting the remaining GNSS validity duration to the BS during the RRC connection establishment procedure, and in some cases, also reporting the GNSS positioning duration. The UE then remains in the connected state until the GNSS validity duration expires (t1 in this example). Upon the GNSS validity duration expiring, the UE can transition to the idle state 530 autonomously or upon receiving an RRC connection release message from the BS. In other words, the connection release can be network-triggered or UE-triggered. Later, in another attempt to communicate with the BS, the UE performs GNSS positioning again and obtains its GNSS position before establishing a connection with the BS.

[0076] If the data exchange between the UE and the BS will take a long time to complete, then Figure 5A The behavior shown requires the UE to constantly switch between idle and connected states. Since constantly switching between RRC states results in considerable signaling overhead and UE power consumption, an alternative approach can eliminate the need for that RRC state during GNSS positioning.

[0077] Figure 5B Timeline 500B illustrates a technique that allows another UE (e.g., a Rel-18 UE) to perform GNSS positioning during a gap period known as a GNSS measurement gap. During this gap period, the network schedules no downlink activity, and thus the UE can focus on the GNSS positioning task by temporarily avoiding cellular communication tasks with the BS. This approach reduces the overhead and power consumption associated with frequent switching of RRC states. Figure 5BIn the process, the UE receives a downlink MAC CE (GNSS GAP MAC CE) from 520, informing it of an upcoming (non-periodic) GNSS measurement gap starting at t1 and ending at t2. The UE then performs GNSS positioning 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 its cellular communication tasks, the UE sends an uplink MAC CE to the network from 540, including the remaining GNSS validity duration.

[0078] In addition to agreeing that the network should send a downlink MAC CE (identified as, for example, GNSS GAP MAC CE) to inform the UE of the upcoming aperiodic GNSS measurement gap, it is necessary to define the detailed format and content of the GNSS GAP MAC CE message. One solution is to indicate the start time of the upcoming GNSS measurement gap to the GNSS GAP MAC CE (e.g., Figure 5B t1) and end time (e.g., Figure 5B (t2 in the original text). However, since the UE may have already reported / recommended the gap duration required for GNSS positioning in MSG5 (e.g., RRCConnectionSetupComplete message), and the network (i.e., BS) is highly likely to provide a GNSS measurement gap with the same gap duration reported / recommended by the UE, signaling the end time (or gap duration) in the GNSS GAP MAC CE may generate redundant signaling in most cases. If the distance (i.e., time interval) between the GNSS GAP MAC CE and the start of the GNSS measurement gap is a fixed value known to both the UE and the network, the network may even omit the start time of the GNSS measurement gap in the GNSS GAP MAC CE.

[0079] Furthermore, since UEs may need to report the remaining GNSS validity duration promptly after each GNSS positioning, a large number of UEs simultaneously reporting GNSS validity duration could lead to insufficient available uplink resources in the cell and potential uplink traffic congestion. If the same downlink MAC CE used to indicate upcoming GNSS measurement gaps could also indicate different options or different uplink resources that UEs could use to report GNSS validity durations, this would allow the network to manage uplink resources and allocate uplink traffic load in a more flexible and dynamic manner.

[0080] When HARQ feedback for downlink traffic is disabled, the network essentially assumes that reception of the GNSS GAP MAC CE indicating an upcoming GNSS measurement gap is successful after several repetitions of the GNSS GAP MAC CE transmission. Therefore, if it is always guaranteed that the GNSS measurement gap will begin after a fixed interval following the last repetition of the GNSS GAP MAC CE transmission, it is not necessary to signal the start time of the GNSS measurement gap in the GNSS GAP MAC CE (e.g., Figure 5B (t1 in the original text). Furthermore, if the network determines to use the GNSS positioning duration reported / recommended by the UE as the duration of the GNSS measurement gap, there is no need to signal the end time or duration of the GNSS measurement gap in the GNSS GAP MAC CE. Therefore, the GNSS GAP MAC CE may not contain a payload (i.e., it is an empty MAC CE) because the start time and duration of the upcoming GNSS measurement gap may be known to the UE when the MAC CE is received.

[0081] Regardless of whether the GNSS GAP MAC CE needs to indicate the start time of the upcoming GNSS measurement gap, the MAC subheader associated with the GNSS GAP MAC CE can be designed to refer to two different formats of the GNSS GAP MAC CE: one with the gap duration and one without, such as... Figure 6A As shown. In Figure 6A In this implementation, although the two Logical Channel Identifier (LCID) values ​​'01101' and '01110' are used to refer to two different formats of GNSS GAP MAC CE, any two LCID values ​​in the range of 01011 to 01110 (LCID values ​​reserved in 3GPP TS 36.321, v17.5.0) may also be used to refer to two different formats of GNSS GAP MAC CE. In some implementations, instead of using two different LCID values ​​to refer to two different formats of GNSS GAP MAC CE, the MAC subheading uses two different eLCID (extended LCID) values ​​to refer to two different formats of GNSS GAP MAC CE, where the eLCID value is indicated by a 6-bit field. In still other implementations, the MAC subheading uses only one eLCID value to refer to only one format of GNSS GAP MAC CE.

[0082] Assuming the GNSS GAP MAC CE only needs to indicate the duration / length of the GNSS measurement gap, Figure 6BThe format of the MAC subheader associated with GNSS GAP MAC CE is shown in the figure. Figure 6B The MAC subheader in the MAC header is an 8-byte (i.e., 8-bit) subheader that includes a one-bit reserved ('R'), a one-bit indicating the size of the length field ('F2'), a one-bit indicating whether there are additional fields in the MAC header ('E'), and a 5-bit indicating the type of the corresponding MAC CE ('LCID'). Since there is no length field in the MAC subheader, F2 is used to indicate the type of the MAC CE. Figure 6B The value in the middle is always 0. Figure 6B In the MAC subheading, a specific LCID value (e.g., '01101') corresponds to an empty GNSS GAP MAC CE (i.e., a GNSS GAP MAC CE that does not contain a payload), while another specific LCID value (e.g., '01110') corresponds to an octet of the GNSS GAP MAC CE with 4 bits ('GD') for indicating the gap duration and 4 reserved bits, where... Figure 6B At the bottom, you can find the actual gap duration (in seconds) corresponding to each GD index value.

[0083] On the other hand, if the GNSS GAP MAC CE needs to indicate the start time of the GNSS measurement gap, then, in addition to other information including the gap duration, the format of the MAC subheader associated with the GNSS GAP MAC CE can be a subheader with an additional 1-bit field 'F' for indicating the size of the length field and two octet (i.e., 16 bits) of an additional 'length' field, such as... Figure 7A As shown. As in this example, the length field occupies 7 bits, and according to TS 38.321 (v17.5.0), the F field is equal to 0.

[0084] Similar to Figure 6B , Figure 7AThe MAC subheader uses a specific LCID value (e.g., 01110) to refer to the GNSS GAPMAC CE, which may include a reserved bit 'R', 4 bits ('X2') indicating the start time of the GNSS measurement gap, a bit ('RI') indicating whether the MAC CE includes a dedicated physical random access channel (PRACH) resource configuration, a bit ('SI') indicating whether the UE can (e.g., is allowed) trigger the scheduling request (SR) mechanism to report the remaining GNSS validity duration, and a bit ('GI') indicating whether the gap duration of the GNSS measurement gap is equivalent to the GNSS positioning duration reported / recommended by the UE in MSG5.

[0085] If the network enables HARQ feedback for the UE to acknowledge downlink transmissions including GNSS GAP MAC CE transmissions, the X2 field of the GNSS GAP MAC CE can indicate the waiting period (e.g., in milliseconds) the UE needs to wait before initiating a GNSS measurement gap. This waiting period can be counted after the UE has already sent HARQ feedback for the GNSS GAP MAC CE in a subframe / slot. Otherwise, the X2 field can indicate the waiting period (in milliseconds) the UE needs to wait before initiating a GNSS measurement gap. This waiting period can be counted after the UE has received the GNSS GAP MAC CE or, if the GNSS GAP MAC CE has been repeatedly transmitted, received a final copy of the GNSS GAP MAC CE in a subframe / slot. In one implementation, if the X' field indicates a value k (in the range of 0 to 15), it indicates that the UE needs to wait k+1 milliseconds before starting a GNSS measurement gap. This can be counted after the UE has sent a HARQ feedback for the GNSS GAP MAC CE in a subframe / slot or after the UE has received the final copy of the GNSS GAP MAC CE in a subframe / slot.

[0086] If both the RI and GI fields are equal to '1', then GNSS GAP MAC CE can be as follows: Figure 7BThe 3-byte MAC CE shown includes a 10-bit 'PRACH' field and a 4-bit GD field appended after the first octet. The PRACH field indicates a dedicated PRACH resource that the UE can use to initiate uplink transmissions for reporting the remaining GNSS validity duration. The PRACH field also contains a 6-bit preamble index and a 4-bit PRACH mask index. The preamble index points to one of up to 64 PRACH preamble sequences that the UE can use, and the PRACH mask index indicates resources in the time and frequency domains that the UE can use to transmit PRACH preambles. The GD field appended after the first octet is... Figure 6B The same GD field shown. Figure 7C Another example of GNSS GAP MAC CE is shown, where the RI field is equal to 1 and the GI field is equal to 0, and therefore the PRACH field is appended to the second and third octets. Figure 7D Another example of GNSS GAP MAC CE is shown, where the RI field is equivalent to 0 and the GI field is equivalent to 1, and therefore the GD field is appended to the second octet.

[0087] Figure 8A This illustrates an alternative where the GNSS GAP MAC CE does not indicate the start time of the GNSS measurement gap but does indicate the GD, RI, and SI fields. If the RI field is equal to 1, the PRACH field will be appended to the second and third octets, as shown below. Figure 8B As shown.

[0088] In some implementations, the GNSS GAP MAC CE includes an additional field indicating the time the 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 cellular communication. This additional field may indicate a range of values ​​from a minimum to a maximum, from which the UE randomly selects a value. The value selected by the UE indicates the number of time units (e.g., time slots, subframes, milliseconds, seconds, etc.) the UE needs to wait before it can report the remaining GNSS validity duration to the BS after the GNSS measurement gap ends.

[0089] Next, refer to Figures 9 to 12 Several example scenarios are discussed in which the UE and / or RAN implement the techniques disclosed herein for supporting GNSS measurements in a connected state. Generally speaking, Figures 9 to 12 China and Figures 13 to 16Similar events in subsequent flowcharts are labeled with similar reference numerals (more specifically, sharing two least significant digits), where differences are discussed below where appropriate. For example, event 904 is similar to events 1004, 1104, and 1204, and boxes 1304, 1404, 1504, and 1604; event 916 is similar to events 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; and so on.

[0090] Figure 9 This is a message passing diagram of example scenario 900 where the UE receives a downlink MACCE indicating the duration and start time of a GNSS measurement gap. UE 102 initially operates in idle state 902 and camps on NTN cell 124 managed by BS 104 via a service link provided by satellite 304. Then, UE 102 measures / receives data from GNSS satellites (e.g., GNSS satellite 308, which can act as...). Figure 1A The UE performs a GNSS positioning operation (904) by transmitting a signal from one of the GNSS satellites (180), triggered by a request from the upper layer to establish a connection with BS 104. After successfully performing GNSS positioning, the UE obtains its GNSS position and the associated GNSS validity duration (i.e., gnss-validityDuration), and then begins monitoring the GNSS validity duration, possibly until it has elapsed. Specifically, 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 sends a 906 RRC Connection Request message to BS 104 to establish a connection with BS 104. In response to the RRC Connection Request message, BS 104 sends a 908 RRC Connection Setup message to the UE 102 to establish SRB1 (signaling radio bearer: 1). In response to receiving the RRC Connection Setup message, the UE 102 sends a 910 RRC Connection Setup Complete message to the BS, and then transitions to the connected state (914). The RRC connection setup completion message sent in event 910 includes the remaining GNSS validity duration and the GNSS positioning duration, where the GNSS positioning duration is the duration requested by UE 102 for successful GNSS positioning. Events 906, 908, and 910... Figure 9The process 912 is collectively referred to as the process for "RRC connection establishment, GNSS validity duration reporting, and GNSS positioning duration reporting." In one implementation, if an RRC connection restoration request message replaces the RRC connection request message in 906, an RRC connection restoration message replaces the RRC connection setup message in 908, and an RRC connection restoration completion message replaces the RRC connection setup completion message in 910, then process 912 can be referred to as the process for "RRC connection restoration, GNSS validity duration reporting, and GNSS positioning duration reporting." In another implementation, if an RRC connection reconstruction request message replaces the RRC connection request message in 906, an RRC connection reconstruction message replaces the RRC connection setup message in 908, and an RRC connection reconstruction completion message replaces the RRC connection setup completion message in 910, then process 912 can be referred to as the process for "RRC connection reconstruction, GNSS validity duration reporting, and GNSS positioning duration reporting."

[0091] Upon receiving the RRC connection setup complete message, BS 104 determines a 916 GNSS measurement gap for UE 102 based on the remaining GNSS validity duration and GNSS positioning duration reported by UE 102 in the RRC connection setup complete message. Then, BS 104 sends a 920 downlink MAC CE named GNSS GAP MAC CE to UE 102, where the GNSS GAP MAC CE includes at least the gap duration of the upcoming GNSS measurement gap (i.e., GD) and the waiting period / length that UE 102 needs to wait before starting the GNSS measurement gap (i.e., X2). In response to the GNSS GAP MAC CE, UE 102 sends a 930 positive HARQ feedback to BS 104 and then begins counting the time UE 102 has waited since sending the HARQ feedback. When the time UE 102 has waited reaches or exceeds the amount of time indicated by X2, UE 102 starts a 940 GNSS measurement gap and suspends its cellular communication tasks. In another implementation, in response to a GNSS GAP MACCE, UE 102 begins to count the time that UE 102 has been waiting since receiving the last copy of the GNSS GAP MACCE, but does not send HARQ feedback to BS 104.

[0092] UE 102 determines the end time of the GNSS measurement gap based on the gap start time and the gap duration indicated by the GD value, and then performs 946 GNSS positioning while UE 102 is still within the GNSS measurement gap. In determining when to perform GNSS positioning within the measurement gap, UE 102 needs to ensure that GNSS positioning can be completed before the end time of the GNSS measurement gap.

[0093] After performing GNSS positioning, UE 102 resumes its cellular communication tasks at the end of the GNSS measurement gap (after events 946 and / or 948). Since UE 102 has obtained the new GNSS location and the new GNSS validity duration associated with the new GNSS location, UE 102 sends 980 to BS 104 including the uplink MAC CE (e.g., GNSS validity duration MAC CE).

[0094] Figure 10 Figure 1000 shows an example scenario in which the UE receives a downlink signal that notifies of an upcoming GNSS measurement gap without indicating the duration of the GNSS measurement gap. Figure 10 The message graph in the middle is similar to Figure 9 The message graph in the image. Specifically, 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.

[0095] After BS 104 has determined the GNSS measurement gap for UE 102, BS sends 1021 a MAC PDU to UE 102 including a MAC subheader with a specific LCID for notifying the upcoming GNSS measurement gap. The MAC PDU including the MAC subheader is sent to UE 102 shortly before the start of the GNSS measurement gap, where the short time can be a fixed / constant value known to both UE 102 and BS 104 (e.g., 6 ms or 12 ms). In another implementation, BS 104 sends 1021 a GNSS GAP MAC CE including a one-bit indication 'GI', where the one-bit indication 'GI' indicates that the gap duration of the GNSS measurement gap is equivalent to the GNSS positioning duration reported / recommended by UE 102 in procedure 1012. In another implementation, BS 104 sends 1021 a GNSS GAP MAC CE to UE 102 that does not include the gap duration value.

[0096] Shortly after receiving the MAC subheader or GNSS GAP MAC CE in 1021 (e.g., 6 ms or 12 ms), UE 102 initiates / enters the 1024 GNSS measurement gap and suspends its cellular communication task. In another implementation, UE 102 initiates / enters the 1024 GNSS measurement gap and suspends its cellular communication task shortly after sending a HARQ feedback acknowledging the received MAC subheader or GNSS GAP MAC CE. UE 102 also initiates / enters the 1024 GNSS measurement gap and suspends its cellular communication task based on the gap start time reported by UE 102 during procedure 1212 and the GNSS positioning duration (see...). Figure 9 Event 910) determines the end time of the GNSS measurement gap, and 1046 GNSS positioning is performed while UE 102 is still within the GNSS measurement gap.

[0097] Figure 11 Figure 1100 shows an example scenario in which the UE receives notification of an upcoming GNSS measurement gap and indicates whether the UE can use / trigger the SR mechanism to report the duration of GNSS validity. Figure 11 The message graph in the middle is similar to Figure 9 The message graph in the image. In particular, events 1102, 1104, 1112, 1114, 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.

[0098] After BS 104 has determined the GNSS measurement gap for UE 102, BS 104 may send an RRC connection reconfiguration message (1118) to UE 102, including the SR or Physical Uplink Control Channel (PUCCH) configuration, where the SR / PUCCH configuration indicates that UE 102 can use it to request PUCCH resources that are scheduled uplink resources. BS 104 also sends a GNSS GAP MAC CE (1122) including the gap duration (i.e., GD) of the upcoming GNSS measurement gap and an indication (i.e., SI) of the duration during which UE 102 can (e.g., is permitted) use / trigger the SR mechanism to report GNSS availability. The GNSS GAP MAC CE is sent to UE 102 shortly before the start of the GNSS measurement gap, where the short period can be a fixed / constant value known to both UE 102 and BS 104 (e.g., 6 ms or 12 ms).

[0099] Shortly after receiving the GNSS GAP MAC CE in 1122 (e.g., 6 ms or 12 ms), UE 102 begins / enters the 1024 GNSS measurement gap and suspends its cellular communication tasks. In another implementation, UE 102 begins / enters the 1140 GNSS measurement gap and suspends its cellular communication tasks shortly after sending a HARQ feedback acknowledging the received GNSS GAP MAC CE (e.g., 6 ms or 12 ms). UE 102 also determines the end time of the GNSS measurement gap based on the gap start time indicated in the GNSS GAP MAC CE and the gap duration, and performs 1146 GNSS positioning while UE 102 is still within the GNSS measurement gap.

[0100] After UE 102 has exited the 1148 GNSS measurement gap, UE 102 can send an uplink signal to BS 104 to request uplink resources. If UE 102 has already received an RRC connection reconfiguration message including SR / PUCCH configuration in 1118, UE 102 can use the allocated PUCCH resources to send an 1170A uplink signal. In response to the PUCCH transmission, BS 104 sends a 1172A response including uplink grant to UE 102 via the Physical Downlink Control Channel (PDCCH). On the other hand, if UE 102 has never received an RRC connection reconfiguration message including SR / PUCCH configuration, UE 102 can use common PRACH resources to send an 1170B uplink signal. In response to the common PRACH preamble, BS 104 sends a 1172B Random Access Response (RAR) message including uplink grant to UE 102. After receiving the uplink grant via 1172A or 1172B, UE 102 sends an uplink MAC CE (1180) to BS 104, including the remaining GNSS validity duration, via the uplink grant provided by BS 104.

[0101] Figure 12 Figure 1200 shows an example scenario in which the UE receives notification of an upcoming GNSS measurement gap and includes a downlink MAC CE with a dedicated PRACH configuration. Figure 12 The message graph in the middle is similar to Figure 9 The message graph in the image. Specifically, 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.

[0102] After BS 104 has determined the GNSS measurement gap for UE 102, BS 104 sends 1223 a GNSS GAP MAC CE, which includes the gap duration (i.e., GD) of the upcoming GNSS measurement gap and a dedicated PRACH resource that UE 102 can use to trigger a report on the duration of GNSS effectiveness. The GNSS GAP MAC CE is sent to UE 102 shortly before the start of the GNSS measurement gap, and said short period can be a fixed / constant value known to both UE 102 and BS 104 (e.g., 6 ms, 12 ms, or other predetermined time amounts).

[0103] Shortly after receiving the GNSS GAP MAC CE in 1122 (e.g., 6 ms or 12 ms), UE 102 begins / enters the 1024 GNSS measurement gap and suspends its cellular communication tasks. In another implementation, UE 102 begins / enters the 1240 GNSS measurement gap and suspends its cellular communication tasks shortly after sending a HARQ feedback acknowledging the received GNSS GAP MAC CE (e.g., 6 ms, 12 ms, or other predetermined time amount). UE 102 also determines the end time of the GNSS measurement gap based on the gap start time indicated in the GNSS GAP MAC CE and the gap duration, and performs 1246 GNSS positioning while UE 102 is still within the GNSS measurement gap.

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

[0105] Figure 13Flowchart 1300 is an example method that can be implemented by a UE (e.g., UE 102 in this disclosure) to determine the duration of a GNSS measurement gap. Initially, at block 1304, the UE performs GNSS positioning when triggered by a need (from an upper layer) to establish a connection with the BS. At block 1304, after successfully performing GNSS positioning, the UE also obtains the GNSS validity duration and begins monitoring the GNSS validity duration, possibly until the GNSS validity duration has elapsed.

[0106] After obtaining a valid GNSS position, at box 1312, the UE performs an RRC connection establishment procedure with the BS and sends the remaining GNSS validity duration and GNSS positioning duration to the BS. In other implementations, the RRC connection establishment procedure performed at box 1312 can be replaced by an RRC connection reconstruction procedure or an RRC connection recovery procedure. After that, the process proceeds to box 1320, where the UE receives a MAC PDU from the BS, including a MAC sub-header with an LCID used to indicate or inform of upcoming GNSS measurement gaps.

[0107] In response to a MAC subheader containing an LCID indicating or informing of an upcoming GNSS measurement gap, at block 1340, the UE initiates a GNSS measurement gap X1 milliseconds after receiving a MAC PDU containing the MAC subheader, where X1 is a waiting period known to the UE without explicit signaling (e.g., a predefined constant integer, such as 6 or 12). After that, the process proceeds to decision block 1351, where the UE determines whether the MAC subheader has a corresponding downlink MAC CE included in the MAC PDU, and whether the downlink MAC CE indicates the gap duration.

[0108] If the determination at decision box 1351 is positive (i.e., the MAC sub-header has a corresponding downlink MAC CE included in the MAC PDU, and the downlink MAC CE indicates the gap duration), the procedure proceeds to box 1348A, whereby the UE stops or exits the GNSS measurement gap when 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 decision box 1351 is negative (i.e., the MAC sub-header does not have a corresponding downlink MAC CE, or the MAC sub-header has a corresponding downlink MAC CE, but the downlink MAC CE does not indicate the gap duration), the procedure proceeds to box 1348B, whereby the UE stops or exits the GNSS measurement gap when the GNSS positioning duration reported at box 1312 has elapsed since the start of the GNSS measurement gap.

[0109] Figure 14 Flowchart 1400 is an example method that can be implemented by a UE (e.g., UE 102 in this disclosure) to determine the start time of a GNSS measurement gap. Initially, at block 1404, the UE performs GNSS positioning when triggered by a demand (from an upper layer) to establish a connection with the BS. At block 1404, after successfully performing GNSS positioning, the UE also obtains the GNSS validity duration and begins monitoring the GNSS validity duration, possibly until the GNSS validity duration has elapsed.

[0110] After obtaining a valid GNSS position, at box 1412, the UE performs an RRC connection establishment procedure with the BS and sends the remaining GNSS validity duration and GNSS positioning duration to the BS. In other implementations, an RRC connection reconstruction procedure or an RRC connection recovery procedure can be used instead of the RRC connection establishment procedure performed at box 1412. After that, the process proceeds to box 1420, where the UE receives from the BS a MAC PDU including a downlink MAC CE (identified as, for example, GNSS GAP MAC CE) for notifying or informing of an upcoming GNSS measurement gap, wherein the downlink MAC CE corresponds to a MAC subheader with a specific LCID included in the MAC PDU.

[0111] Following that, the process proceeds to decision box 1452, where the UE determines whether the downlink MAC CE contains an X2 value indicating the waiting period the UE needs to wait before initiating the GNSS measurement gap. If the determination at decision box 1452 is affirmative (i.e., the downlink MAC CE contains an X2 value), the process proceeds to box 1430, where the UE sends a HARQ feedback to the BS confirming receipt of the MAC PDU. Later, at box 1440A, the UE initiates the GNSS measurement gap X2 milliseconds after sending the HARQ feedback. In some implementations, when the determination at decision box 1452 is affirmative, the UE skips the action in box 1430 and, at box 1440A, initiates the GNSS measurement gap X2 milliseconds after receiving the MAC PDU containing the downlink MAC CE indicating or informing of the upcoming GNSS measurement gap.

[0112] On the other hand, if the determination at decision box 1452 is negative (i.e., the downlink MAC CE does not contain the X2 value), the process proceeds to box 1340, where the UE starts the GNSS measurement gap X1 milliseconds after receiving the MAC PDU containing the downlink MAC CE, where X1 is a predetermined time amount known to the UE without explicit signaling (e.g., a predefined constant integer, such as 6 or 12).

[0113] Figure 15A Flowchart 1500A is an example method that can be implemented by a UE (e.g., UE 102 in this disclosure) to determine whether to use PUCCH resources to trigger a report on the GNSS validity duration. Initially, at block 1504, the UE performs GNSS positioning when triggered by a demand (from an upper layer) to establish a connection with the BS. At block 1504, after successfully performing GNSS positioning, the UE also obtains the GNSS validity duration and begins monitoring the GNSS validity duration, possibly until the GNSS validity duration has elapsed.

[0114] After obtaining a valid GNSS location, at box 1512, the UE performs an RRC connection establishment procedure with the BS and sends the remaining GNSS validity duration and GNSS positioning duration to the BS. In other implementations, the RRC connection establishment procedure performed at box 1512 can be replaced by an RRC connection reconstruction procedure or an RRC connection recovery procedure. After transitioning to the connected state, at box 1518, the UE receives an RRC connection reconfiguration message from the BS, including SR or PUCCH configuration, where the SR or PUCCH configuration provides the UE with PUCCH resources that the UE can use to request uplink transmission opportunities.

[0115] The process then proceeds to block 1520, where the UE receives from the BS a MAC PDU including a downlink MAC CE (identified as, for example, GNSS GAP MAC CE) for notifying or informing of an upcoming GNSS measurement gap, wherein 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, at block 1540, the UE initiates the GNSS measurement gap and performs GNSS positioning before the gap ends. After successfully performing GNSS positioning, the UE obtains a valid GNSS position associated with the GNSS validity duration and begins monitoring the GNSS validity duration, possibly until the GNSS validity duration has elapsed.

[0116] Following that, the process proceeds to decision box 1553, where the UE determines whether the downlink MAC CE contains an SR indication (i.e., SI) indicating that the UE can (e.g., is permitted) use / trigger the SR mechanism to report its remaining GNSS validity duration. If the determination at decision box 1553 is affirmative (i.e., the UE can use / trigger the SR mechanism to report its remaining GNSS validity duration), the process proceeds to box 1570A, where the UE uses the PUCCH resources configured for the UE at box 1518 to send an SR signal to the BS after the GNSS measurement gap ends. At a later time, at box 1572A, the UE receives from the BS an uplink grant that the UE can use to send an uplink MAC CE including the remaining GNSS validity duration at box 1580A.

[0117] On the other hand, if the determination at decision box 1553 is negative (i.e., the UE is unable (e.g., not allowed) to use / trigger the SR mechanism to report its remaining GNSS validity duration), the process proceeds directly to box 1572A, where the UE waits for a PDCCH (sent by the BS) that includes an uplink grant that the UE can use to send an uplink MAC CE including the remaining GNSS validity duration.

[0118] Figure 15B Flowchart 1500B is an example method that can be implemented by a UE (e.g., UE 102 in this disclosure) for determining whether to use public PRACH resources to trigger a report on the duration of GNSS validity. Figure 15B The flowchart in the middle is similar to Figure 15A The flowchart in the diagram discusses the differences below. After the RRC connection establishment procedure with the BS is performed at box 1512, the UE does not receive an RRC connection reconfiguration message including SR or PUCCH configuration before receiving the MAC PDU including the downlink MAC CE for notifying or informing of the upcoming GNSS measurement gap at box 1520.

[0119] After the UE has successfully performed GNSS positioning and obtained the GNSS validity duration during the GNSS measurement gap, the procedure proceeds to decision box 1553, where the UE determines whether the downlink MAC CE contains an SR indication (i.e., SI) indicating that the UE can (e.g., is permitted) use / trigger the SR mechanism to report its remaining GNSS validity duration. If the determination at decision box 1553 is affirmative (i.e., the UE can (e.g., is permitted) use / trigger the SR mechanism to report its remaining GNSS validity duration), the procedure proceeds to box 1570B, where the UE sends a common PRACH preamble to the BS after the GNSS measurement gap ends. At a later time, at box 1572B, the UE receives from the BS a RAR message containing an uplink grant that the UE can use to send a C-RNTI MAC CE at box 1580B, as well as an uplink MAC CE including the remaining GNSS validity duration.

[0120] On the other hand, if the determination at decision box 1553 is negative (i.e., the UE is unable (e.g., not allowed) to use / trigger the SR mechanism to report its remaining GNSS validity duration), the process proceeds to box 1572A, where the UE waits for a PDCCH (sent by the BS) that includes an uplink grant that the UE can use to send an uplink MAC CE including the remaining GNSS validity duration.

[0121] Figure 16 This is a flowchart 1600 of an example method that can be implemented by a UE (e.g., UE 102 in this disclosure) to determine whether to use dedicated PRACH resources to trigger a report on the GNSS validity duration. Initially, at block 1604, the UE performs GNSS positioning when triggered by a need (from an upper layer) to establish a connection with the BS. At block 1604, after successfully performing GNSS positioning, the UE also obtains the GNSS validity duration and begins monitoring the GNSS validity duration, possibly until the GNSS validity duration has elapsed.

[0122] After obtaining a valid GNSS position, at box 1612, the UE performs an RRC connection establishment procedure with the BS and sends the remaining GNSS validity duration and GNSS positioning duration to the BS. In other implementations, the RRC connection establishment procedure performed at box 1612 can be replaced by an RRC connection reconstruction procedure or an RRC connection recovery procedure. Later after being in a connected state, at box 1620, the UE receives from the BS a MAC PDU including a downlink MAC CE (identified as, for example, GNSS GAP MAC CE) for notifying or informing of an upcoming GNSS measurement gap, wherein the downlink MAC CE corresponds to a MAC subheader with a specific LCID included in the MAC PDU.

[0123] In response to the reception of a downlink MAC CE, at box 1640, the UE initiates a GNSS measurement gap and performs GNSS positioning before the end of the GNSS measurement gap. After successfully performing GNSS positioning, the UE obtains a valid GNSS position associated with the GNSS validity duration and begins monitoring the GNSS validity duration, possibly until the GNSS validity duration has elapsed.

[0124] Following that, the process proceeds to decision box 1655, where the UE determines whether the downlink MAC CE contains a dedicated PRACH configuration that provides the UE with dedicated PRACH resources for reporting its remaining GNSS validity duration. If the determination at decision box 1655 is affirmative (i.e., dedicated PRACH resources are provided to the UE), the process proceeds to box 1632, where the UE sends the dedicated PRACH preamble configured for the UE to the BS after the GNSS measurement gap ends. At a later time, at box 1634, the UE receives from the BS a RAR message or PDCCH containing uplink grants that the UE can use to send the uplink MAC CE containing the remaining GNSS validity duration at box 1680A.

[0125] On the other hand, if the determination at decision box 1655 is negative (i.e., no dedicated PRACH resource is provided to the UE), the process proceeds directly to box 1672A, where the UE waits for a PDCCH (sent by the BS) that includes uplink grants that the UE can use to send uplink MAC CEs including the remaining GNSS validity duration.

[0126] The following list of examples reflects various embodiments explicitly contemplated in this disclosure.

[0127] 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 a media access control (MAC) protocol data unit (PDU) indicating the duration of the measurement gap from the NTN while the UE is in a connected state with the NTN; and determining the location of the UE during the measurement gap and while the UE is in the connected state with the NTN by performing a positioning procedure.

[0128] Example 2. The method as described in Example 1, wherein the MAC PDU further indicates the start time of the measurement gap.

[0129] Example 3. The method as described in Example 2, wherein the MAC PDU indicates the start time by including a control element (CE) indicating a waiting period.

[0130] Example 4. The method as described in Example 3, wherein the measurement gap (i) begins during the waiting period after the UE receives the MAC PDU, or (ii) begins during the waiting period after the UE sends a Hybrid Automatic Repeat Request (HARQ) feedback to the NTN in response to receiving the MAC PDU.

[0131] Example 5. The method as described in Example 1, wherein the MAC PDU does not indicate the start time of the measurement gap, and wherein the measurement gap (i) begins after the UE receives the MAC PDU, or (ii) begins after the UE sends a Hybrid Automatic Repeat Request (HARQ) feedback to the NTN in response to receiving the MAC PDU, the predetermined time amount.

[0132] Example 6. The method of any one of Examples 1 to 5, wherein the MAC PDU indicates the duration by including a control element (CE) that indicates the duration.

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

[0134] Example 8. The method as described in Example 7, wherein performing the RRC connection establishment procedure with the NTN includes sending an RRC message to the NTN including the duration reported by the UE.

[0135] Example 9. The method as described in Example 8, wherein the RRC message is an RRC connection setup complete message.

[0136] Example 10. The method of any one of Examples 1 to 7 further includes: before performing the RRC connection establishment procedure with the NTN and while the UE is in an idle state, (i) determining the early location of the UE by performing an early location procedure, and (ii) obtaining the validity duration of the early location of the UE, wherein performing the RRC connection establishment procedure includes sending an RRC message to the NTN indicating the validity duration of the early location of the UE.

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

[0138] Example 12. The method as described in Example 11, wherein the Logical Channel Identifier (LCID) or Extended LCID (eLCID) of the MAC sub-header indicates whether the MAC CE of the MAC PDU indicates the duration of the measurement gap.

[0139] Example 13. The method of any one of Examples 1 to 12, wherein the MAC PDU indicates uplink resources that the UE can use to report the location validity duration; and the method further includes sending the location validity duration of the UE to the NTN and via the uplink resources.

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

[0141] Example 15. The method of any one of Examples 1 to 12, wherein: the MAC PDU indicates a period of time the UE will wait before reporting the location validity duration; and the method further includes sending the location validity duration of the UE to the NTN and after waiting for the period of time.

[0142] Example 16. The method of any one of Examples 1 to 15, wherein: the NTN is a satellite network; and performing the positioning process includes performing a Global Navigation Satellite System (GNSS) positioning process based on signals received by the UE from satellites of the NTN.

[0143] Example 17. A user equipment (UE) includes one or more processors and is configured to perform the method as described in any one of Examples 1 to 16.

[0144] 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, while the UE is in a connected state with the NTN, sending to the UE a media access control (MAC) protocol data unit (PDU) indicating the duration of the measurement gap, during which the UE, while in the connected state with the NTN, will determine the location of the UE by performing a positioning procedure.

[0145] Example 19. The method as described in Example 18, wherein the MAC PDU further indicates the start time of the measurement gap.

[0146] Example 20. The method as described in Example 19, wherein the MAC PDU indicates the start time by including a control element (CE) indicating a waiting period.

[0147] Example 21. The method as described in Example 20, wherein the measurement gap (i) begins during the waiting period after the UE receives the MAC PDU, or (ii) begins during the waiting period after the UE sends a Hybrid Automatic Repeat Request (HARQ) feedback to the NTN in response to receiving the MAC PDU.

[0148] Example 22. The method as described in Example 18, wherein the MAC PDU does not indicate the start time of the measurement gap, and wherein the measurement gap (i) begins after the UE receives the MAC PDU, or (ii) begins after the UE sends a Hybrid Automatic Repeat Request (HARQ) feedback to the NTN in response to receiving the MAC PDU, the predetermined time amount.

[0149] Example 23. The method of any one of Examples 18 to 22, wherein the MAC PDU indicates the duration by including a control element (CE) that indicates the duration.

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

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

[0152] Example 26. The method described in Example 25, wherein the RRC message is an RRC connection setup complete message.

[0153] Example 27. A method as described in any one of Examples 18 to 24, wherein performing the RRC connection establishment procedure includes receiving an RRC message from the UE indicating the validity duration of the UE's early location, and wherein the method further includes: determining the measurement gap based on the validity duration of the UE's early location before sending the MAC PDU to the UE.

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

[0155] Example 29. The method as described in Example 28, wherein the Logical Channel Identifier (LCID) or Extended LCID (eLCID) of the MAC sub-header indicates whether the MAC CE of the MAC PDU indicates the duration of the measurement gap.

[0156] Example 30. The method of any one of Examples 18 to 29, wherein: the MAC PDU indicates uplink resources that the UE can use to report the location validity duration; and the method further includes receiving the location validity duration of the UE from the UE and via the uplink resources.

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

[0158] Example 32. The method of any one of Examples 18 to 29, wherein: the MAC PDU indicates a period of time the UE will wait before reporting the location validity duration; and the method further includes receiving the location validity duration of the UE from the UE after the UE waits for the period of time.

[0159] Example 33. The method as described in any one of Examples 18 to 32, wherein: the NTN is a satellite network; and the positioning process is a Global Navigation Satellite System (GNSS) positioning process based on signals received by the UE from the satellites of the NTN.

[0160] Example 34. An NTN node, the node including one or more processors and configured to perform the method as described in any one of Examples 18 to 33.

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

[0162] Example 36. The method as described in Example 35, wherein receiving includes receiving a Radio Resource Control (RRC) message indicating the uplink resources.

[0163] Example 37. The method as described in Example 36, wherein the RRC message is an RRC connection reconfiguration message.

[0164] Example 38. The method as described in Example 36 or 37, wherein the uplink resource is a scheduling request (SR) configuration or a physical uplink control channel (PUCCH) configuration.

[0165] Example 39. The method of any one of Examples 36 to 38, further comprising: receiving from the NTN a Media Access Control (MAC) Protocol Data Unit (PDU) indicating the duration of the measurement gap when the UE and the NTN are in the connected state.

[0166] Example 40. The method as described in Example 39, wherein the MAC PDU instructs the UE to use a scheduling request (SR) mechanism to report the duration for which the determined location is valid.

[0167] Example 41. The method as described in Example 35, wherein the receiving includes receiving a Media Access Control (MAC) Protocol Data Unit (PDU) indicating the uplink resource and the duration of the measurement gap.

[0168] Example 42. The method as described in Example 41, wherein the uplink resource is a Physical Random Access Channel (PRACH) configuration.

[0169] Example 43. The method as described in Example 42, wherein: the uplink resource is a dedicated PRACH preamble; and the indication of the duration valid at the determined location is sent using the uplink resource includes (i) sending the dedicated PRACH preamble to the NTN, (ii) receiving a response including an uplink grant from the NTN, and (iii) sending the indication of the duration valid at the determined location to the NTN and using the uplink grant.

[0170] Example 44. The method of any one of Examples 35 to 43, wherein the duration for which the determined location is valid is the remaining duration for which the determined location is valid.

[0171] Example 45. The method of any one of Examples 35 to 44, wherein: the NTN is a satellite network; and performing the positioning process includes performing a Global Navigation Satellite System (GNSS) positioning process based on signals received by the UE from satellites of the NTN.

[0172] Example 46. A user equipment (UE) includes one or more processors and is configured to perform a method as described in any one of Examples 35 to 45.

[0173] Example 47. A method for facilitating reporting of location information by a node of a non-terrestrial network (NTN), the method comprising: sending to the UE an indication of uplink resources that the UE will use to report the duration of location validity while the UE is in a connected state with the NTN; sending to the UE an indication of a measurement gap while the UE is in the connected state with the NTN, in which the UE will determine its location by performing a location procedure while in the connected state with the NTN; and using the uplink resources and receiving from the UE an indication of the duration of validity of the determined location while the UE is in the connected state with the NTN.

[0174] Example 48. The method as described in Example 47, wherein sending the indication of the uplink resource includes sending a radio resource control (RRC) message indicating the uplink resource.

[0175] Example 49. The method as described in Example 48, wherein the RRC message is an RRC connection reconfiguration message.

[0176] Example 50. The method as described in Example 48 or 49, wherein the uplink resource is a scheduling request (SR) configuration or a physical uplink control channel (PUCCH) configuration.

[0177] Example 51. The method of any one of Examples 48 to 50, wherein: sending the indication of the measurement gap includes sending a Media Access Control (MAC) Protocol Data Unit (PDU) indicating the measurement gap.

[0178] Example 52. The method as described in Example 51, wherein the MAC PDU instructs the UE to use a scheduling request (SR) mechanism to report the duration for which the determined location is valid.

[0179] Example 53. The method as described in Example 47, wherein the indication of sending the uplink resource and the indication of sending the measurement gap jointly include sending a Media Access Control (MAC) Protocol Data Unit (PDU) indicating the uplink resource and the measurement gap.

[0180] Example 54. The method as described in Example 53, wherein the uplink resource is a Physical Random Access Channel (PRACH) configuration.

[0181] Example 55. The method as described in Example 54, wherein: the uplink resource is a dedicated PRACH preamble; and the indication of the duration valid for the determined location is received using the uplink resource includes (i) receiving the dedicated PRACH preamble from the UE, (ii) sending a response including an uplink grant to the UE, and (iii) receiving the indication of the duration valid for the determined location from the UE using the uplink grant.

[0182] Example 56. The method of any one of Examples 47 to 55, wherein the duration for which the determined location is valid is the remaining duration for which the determined location is valid.

[0183] Example 57. The method of any one of Examples 47 to 56 further includes: determining an additional measurement gap based on the duration of validity of the determined location.

[0184] Example 58. The method of any one of Examples 47 to 57, wherein the indication of sending the measurement gap includes an indication of the duration of sending the measurement gap.

[0185] Example 59. The method of any one of Examples 47 to 58, wherein: the NTN is a satellite network; and the positioning process is a Global Navigation Satellite System (GNSS) positioning process based on signals received by the UE from the satellites of the NTN.

[0186] Example 60. An NTN node, the node including one or more processors and configured to perform the method as described in any one of Examples 47 to 59.

[0187] The following descriptions can be applied to the descriptions above.

[0188] Generally, a description of one of the above figures can be applied to another. Any event or box described above may be optional. For example, an event or box with a dashed line may be optional. In some implementations, "message" is used and "information element (IE)" can be used instead of "message," and vice versa. In some implementations, "IE" is used and "field" can be used instead of "IE," and vice versa. In some implementations, "configurations" or "configuration parameters" can be used instead of "configuration," and vice versa. "Base station," "gNB," "6G base station," "evolved gNB," or 6G gNB can be used instead of "eNB." "AMF," or evolved AMF, or 6G AMF can be used instead of "MME." "RRC setup request message" can be used instead of "RRC connection request message." "RRC setup message" can be used instead of "RRC connection setup message." "RRC setup complete message" can be used instead of "RRC connection setup complete message." "RRC reconfiguration message" can be used instead of "RRC connection reconfiguration message." The "RRC Reconstruction Request Message" can be used instead of the "RRC Connection Reconstruction Request Message". The "RRC Reconstruction Message" can be used instead of the "RRC Connection Reconstruction Message". The "RRC Reconstruction Complete Message" can be used instead of the "RRC Connection Reconstruction Complete Message". The "RRC Recovery Request Message" can be used instead of the "RRC Connection Recovery Request Message". The "RRC Recovery Message" can be used instead of the "RRC Connection Recovery Message". The "RRC Recovery Complete Message" can be used instead of the "RRC Connection Recovery Complete Message".

[0189] User devices (e.g., UE 102) that can implement the technologies disclosed herein can be any suitable device capable of wireless communication, such as smartphones, tablets, laptops, mobile game consoles, point-of-sale (POS) terminals, health monitoring devices, drones, cameras, media streaming dongles or other personal media devices, wearable devices (such as smartwatches), Wi-Fi hotspots, femtocells, or broadband routers. Additionally, in some cases, the user device can be embedded in electronic systems (such as the main unit of a vehicle or an advanced driver assistance system (ADAS)). Furthermore, the user device can operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

[0190] Some implementations described in this disclosure include logic or multiple components or modules. A module can be a software module (e.g., code or machine-readable instructions stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing certain operations and can be configured or arranged in a certain way. A hardware module may include a dedicated circuit system or logic that is persistently configured (e.g., as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC), digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also include programmable logic or circuit systems that are temporarily configured by software to perform certain operations (e.g., as encompassed within a general-purpose processor or other programmable processor). The decision to implement a hardware module in a dedicated and persistently configured circuit system or in a temporarily configured circuit system (e.g., by software configuration) may be driven by cost and time considerations.

[0191] When implemented in software, the technology can be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software can be executed by one or more general-purpose processors or one or more dedicated processors.

Claims

1. A user equipment (UE) implemented using a positioning method, the method comprising: In a non-terrestrial network (NTN) cell and when the UE is operating in a connected state of a protocol for controlling radio resources, a Media Access Control (MAC) Protocol Data Unit (PDU) indicating (i) the duration of the measurement gap and (ii) the start time of the measurement gap is received; as well as The positioning process is performed during the measurement interval and while the UE is in the connected state.

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 waiting period relative to the reception 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 indicating a waiting period relative to the acknowledgment of the MAC PDU sent from the UE and in the NTN cell.

4. The method of claim 1, wherein: The MAC PDU indicates the start time of the measurement gap by the arrival of a predefined amount of time prior to the start 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 will use a duration value previously reported by the UE.

6. The method of claim 5, further comprising: Prior to receiving the MAC PDU, a Radio Resource Control (RRC) connection establishment procedure is performed with the NTN cell, including sending an RRC message in the NTN cell that includes the duration value.

7. The method as described in any of the preceding claims, wherein: The MAC PDU includes a MAC subheader; and The MAC subheader indicates that the 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), which indicates the duration of the measurement gap as indicated by the MAC CE.

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

10. The method as claimed in 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: For UEs operating in a connected state under protocols used to control radio resources, determine the measurement gap; as well as When the UE operates in the connected state, it sends a Media Access Control (MAC) Protocol Data Unit (PDU) indicating (i) the duration of the measurement gap and (ii) the 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 indicating a waiting period relative to (i) the transmission of the MAC PDU or (ii) the receipt of an acknowledgment of the MAC PDU from the UE.

13. The method of claim 11, wherein: The transmission of the MAC PDU indicating the start time of the measurement gap includes a predefined amount of time prior to the start 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 will use a duration value previously reported by the UE.

15. A wireless communication device, comprising: transceiver; as well as Processing hardware, the processing hardware being configured to implement the method as described in any one of the preceding claims.

Images