Timing and frequency pre-compensation for non-terrestrial wireless networks

Abstract

One or more processors configured to perform operations comprising: interfacing with a transceiver to receive an uplink (UL) transmission extension command from a non-terrestrial network (NTN); in response to receiving the UL transmission extension command, determining at least one UL transmission extension pre-compensation offset; and interfacing with the transceiver for reporting a capability of the UL transmission for a transmission extension validity duration, the capability based on the pre-compensation offset.

Description

TIMING AND FREQUENCY PRE-COMPENSATION FOR NON-TERRESTRIAL WIRELESS NETWORKSCLAIM OF PRIORITY

[0001] This application claims priority to U.S. Patent Application Serial No. 63 / 554,720, filed on February 16, 2024, the entire contents of which are hereby incorporated by reference.BACKGROUND

[0002] Wireless communication networks provide integrated communication platforms and telecommunication services to wireless user devices. Example telecommunication services include telephony, data (e.g., voice, audio, and / or video data), messaging, and / or other services. The wireless communication networks have wireless access nodes that exchange wireless signals with the wireless user devices using wireless network protocols, such as protocols described in various telecommunication standards promulgated by the Third Generation Partnership Project (3GPP). Example wireless communication networks include time division multiple access (TDMA) networks, frequency-division multiple access (FDMA) networks, orthogonal frequency-division multiple access (OFDMA) networks, Long Term Evolution (LTE), and Fifth Generation New Radio (5G NR). The wireless communication networks facilitate mobile broadband service using technologies such as OFDM, multiple input multiple output (MIMO), advanced channel coding, massive MIMO, beamforming, and / or other features.

[0003] More recently, to increase network coverage and support use cases that are beyond the capabilities of ground-based (e.g., terrestrial) infrastructure, 3 GPP has released standards that introduce a non -terrestrial network (NTN) that uses airborne or space-borne platforms (e.g., non-geo- stationary satellites) to serve as access nodes or base stations. A non-terrestrial network can be integrated with terrestrial infrastructure, e.g., 5G NR infrastructure, to supplement the network coverage of the terrestrial infrastructure. A non-terrestrial network can also be used to independently provide network coverage to devices, e.g., Internet of Things (loT) devices, that are located in areas without terrestrial network coverage.SUMMARY

[0004] In an aspect, one or more processors configured to perform operations comprising: interfacing with a transceiver to receive an uplink (UL) transmission extension command from a non-terrestrial network (NTN); in response to receiving the UL transmission extension command, determining an UL transmission extension pre-compensation timing offset, an UL transmission extension pre-compensation frequency offset, or both the pre-compensation timing offset and the pre-compensation frequency offset; and interfacing with the transceiver for reporting a capability of the UL transmission for a transmission extension validity duration, the capability based on the pre-compensation timing offset, the pre-compensation frequency offset, or both the pre-compensation timing offset and the pre-compensation frequency offset.

[0005] In some implementations, determining the pre-compensation timing offset, the precompensation frequency offset, or both the pre-compensation timing offset and the precompensation frequency offset occurs during an extended UL transmission duration. In some implementations including one or more of the previous implementations, the pre-compensation timing offset is determined based on a last valid GNSS position. In some implementations including one or more of the previous implementations, the pre-compensation timing offset is determined by: interfacing with the transceiver to send, to a base station, a signal for a physical random access channel (PRACH); and interfacing with a transceiver to receive, responsive to the signal for PRACH, a timing advance command from the base station specifying a timing advance value.

[0006] In some implementations including one or more of the previous implementations, a different GNSS is available, and wherein the pre-compensation timing offset is determined by: switching from the GNSS to the different GNSS; acquiring, from the different GNSS, position data; and determining, from the position data, a timing advance value.

[0007] In some implementations including one or more of the previous implementations, the operations include increasing a timing advance command granularity; and based on the increased timing advance command granularity, determining a timing advance value. In some implementations, the timing advance command granularity is increased based on a timing correction factor having a value selected from a set of candidate values.

[0008] In some implementations including one or more of the previous implementations, the64 operations include updating a timing advance command based on NTA= K * TA* 16 * —where k is a correction factor. In some implementations including one or more of the previous implementations, the operations include updating a timing advance command based on correction factor.

[0009] In some implementations including one or more of the previous implementations, the pre-compensation frequency offset is determined for a static user equipment (UE), the precompensation frequency offset being determined based on an open loop frequency correction determined from a downlink (DL) frequency.

[0010] In some implementations including one or more of the previous implementations, the pre-compensation frequency offset is determined for an in-motion user equipment (UE), the pre-compensation frequency offset being determined based on a closed loop frequency correction value.

[0011] In some implementations including one or more of the previous implementations, the operations include interfacing with the transceiver to receive a medium access control (MAC) control element (CE) from a base station, the MAC CE specifying an absolute frequency offset.

[0012] In some implementations including one or more of the previous implementations, the operations include interfacing with the transceiver to receive a medium access control (MAC) control element (CE) from a base station, the MAC CE specifying a relative frequency offset.

[0013] In some implementations including one or more of the previous implementations, the absolute frequency offset is reported in kilohertz per bit or another granularity according to a pre-configuration.

[0014] In some implementations including one or more of the previous implementations, a timing advance command MAC CE comprises a Timing Advance Group Identifier (TAG Id) field including at least one bit, and wherein the at least one bit indicates that a timing advance command field includes the pre-compensation timing offset or the pre-compensation frequency offset.

[0015] In some implementations including one or more of the previous implementations, reporting the capability of the UL transmission extension validity duration includes reporting per frequency band.

[0016] In some implementations including one or more of the previous implementations, the operations include reporting the capability of the UL transmission extension validity duration comprises reporting per user equipment.

[0017] In some implementations including one or more of the previous implementations, reporting the capability of the UL transmission extension validity duration is differentiated based on a type of a global navigation satellite system (GNSS) satellite.

[0018] In an aspect, a method includes interfacing with a transceiver to receive an uplink (UL) transmission extension command from a non-terrestrial network (NTN); in response to receiving the UL transmission extension command, determining an UL transmission extension pre-compensation timing offset, an UL transmission extension pre-compensation frequency offset, or both the pre-compensation timing offset and the pre-compensation frequency offset; and interfacing with the transceiver for reporting a capability of the UL transmission for a transmission extension validity duration, the capability based on the pre-compensation timing offset, the pre-compensation frequency offset, or both the pre-compensation timing offset and the pre-compensation frequency offset.

[0019] In some implementations, determining the pre-compensation timing offset, the precompensation frequency offset, or both the pre-compensation timing offset and the precompensation frequency offset occurs during an extended UL transmission duration. In some implementations including one or more of the previous implementations, the pre-compensation timing offset is determined based on a last valid GNSS position. In some implementations including one or more of the previous implementations, the pre-compensation timing offset is determined by: interfacing with the transceiver to send, to a base station, a signal for a physical random access channel (PRACH); and interfacing with a transceiver to receive, responsive to the signal for PRACH, a timing advance command from the base station specifying a timing advance value.

[0020] In some implementations including one or more of the previous implementations, a different GNSS is available, and wherein the pre-compensation timing offset is determined by: switching from the GNSS to the different GNSS; acquiring, from the different GNSS, position data; and determining, from the position data, a timing advance value.

[0021] In some implementations including one or more of the previous implementations, the method includes increasing a timing advance command granularity; and based on the increased timing advance command granularity, determining a timing advance value. In someimplementations, the timing advance command granularity is increased based on a timing correction factor having a value selected from a set of candidate values.

[0022] In some implementations including one or more of the previous implementations, the 64 method includes updating a timing advance command based on NTA= K * TA* 16 * — wherek is a correction factor. In some implementations including one or more of the previous implementations, the operations include updating a timing advance command based on correction factor.

[0023] In some implementations including one or more of the previous implementations, the pre-compensation frequency offset is determined for a static user equipment (UE), the precompensation frequency offset being determined based on an open loop frequency correction determined from a downlink (DL) frequency.

[0024] In some implementations including one or more of the previous implementations, the pre-compensation frequency offset is determined for an in-motion user equipment (UE), the pre-compensation frequency offset being determined based on a closed loop frequency correction value.

[0025] In some implementations including one or more of the previous implementations, the method includes interfacing with the transceiver to receive a medium access control (MAC) control element (CE) from a base station, the MAC CE specifying an absolute frequency offset.

[0026] In some implementations including one or more of the previous implementations, the method includes interfacing with the transceiver to receive a medium access control (MAC) control element (CE) from a base station, the MAC CE specifying a relative frequency offset.

[0027] In some implementations including one or more of the previous implementations, the absolute frequency offset is reported in kilohertz per bit or another granularity according to a pre-configuration.

[0028] In some implementations including one or more of the previous implementations, a timing advance command MAC CE comprises a Timing Advance Group Identifier (TAG Id) field including at least one bit, and wherein the at least one bit indicates that a timing advance command field includes the pre-compensation timing offset or the pre-compensation frequency offset.

[0029] In some implementations including one or more of the previous implementations, reporting the capability of the UL transmission extension validity duration includes reporting per frequency band.

[0030] In some implementations including one or more of the previous implementations, the operations include reporting the capability of the UL transmission extension validity duration comprises reporting per user equipment.

[0031] In some implementations including one or more of the previous implementations, reporting the capability of the UL transmission extension validity duration is differentiated based on a type of a global navigation satellite system (GNSS) satellite.

[0032] In an aspect, a user equipment (UE) includes the one or more processors previously described.

[0033] In an aspect, a user equipment (UE) is configured to perform the operations or methods previously described.

[0034] In an aspect, one or more processors configured to perform operations comprising: interfacing with a transceiver to send an uplink (UL) transmission extension command to a user equipment (UE); and interfacing with the transceiver to receive a capability of the UL transmission for a transmission extension validity duration from the UE, the capability based on a pre-compensation timing offset, a pre-compensation frequency offset, or both the precompensation timing offset and the pre-compensation frequency offset.

[0035] In some implementations, the pre-compensation timing offset, the pre-compensation frequency offset, or both the pre-compensation timing offset and the pre-compensation frequency offset are determined during an extended UL transmission duration.

[0036] In some implementations including one or more of the previous implementations, the pre-compensation timing offset is determined based on a last valid GNSS position.

[0037] In some implementations including one or more of the previous implementations, the pre-compensation timing offset is determined based on: decoding, from the UE, a signal for a physical random access channel (PRACH); and encoding, responsive to the signal for PRACH, a timing advance command specifying a timing advance value for sending to the UE.

[0038] In some implementations including one or more of the previous implementations, a different GNSS is available, and wherein the pre-compensation timing offset is determined by:switching from the GNSS to the different GNSS; acquiring, from the different GNSS, position data; and determining, from the position data, a timing advance value.

[0039] In some implementations including one or more of the previous implementations, the operations further comprise: increasing a timing advance command granularity; and based on the increased timing advance command granularity, determining a timing advance value.

[0040] In some implementations including one or more of the previous implementations, the timing advance command granularity is increased based on a timing correction factor having a value selected from a set of candidate values.

[0041] In some implementations including one or more of the previous implementations, the operations further include updating a timing advance command based on NTA= K * TA* 16 * 64— , where k is a correction factor.2U

[0042] In some implementations including one or more of the previous implementations, the operations further include updating a timing advance command based on NTAnew= NTAO1C1+ correction factor.

[0043] In some implementations including one or more of the previous implementations, the pre-compensation frequency offset is determined for a static user equipment (UE), the precompensation frequency offset being determined based on an open loop frequency correction determined from a downlink (DL) frequency.

[0044] In some implementations including one or more of the previous implementations, the pre-compensation frequency offset is determined for an in-motion user equipment (UE), the pre-compensation frequency offset being determined based on a closed loop frequency correction value.

[0045] In some implementations including one or more of the previous implementations, the operations further include encoding, for transmission to the UE, a medium access control (MAC) control element (CE) from a base station, the MAC CE specifying an absolute frequency offset.

[0046] In some implementations including one or more of the previous implementations, the operations further include encoding, for transmission to the UE, a medium access control (MAC) control element (CE) from a base station, the MAC CE specifying a relative frequency offset.

[0047] In some implementations including one or more of the previous implementations, the absolute frequency offset being reported in kilohertz per bit or another granularity according to a pre-configuration.

[0048] In some implementations including one or more of the previous implementations, a timing advance command MAC CE comprises a Timing Advance Group Identifier (TAG Id) field including at least one bit, and wherein the at least one bit indicates that a timing advance command field includes the pre-compensation timing offset or the pre-compensation frequency offset.

[0049] In some implementations including one or more of the previous implementations, decoding the capability report of the UL transmission extension validity duration comprises reporting per frequency band.

[0050] In some implementations including one or more of the previous implementations, decoding the capability report of the UL transmission extension validity duration comprises reporting per user equipment.

[0051] In some implementations including one or more of the previous implementations, decoding the capability report of the UL transmission extension validity duration is differentiated based on a type of a global navigation satellite system (GNSS) satellite.

[0052] In an aspect, a base station or access node includes the one or more processors previously described.

[0053] In an aspect, base station or access node is configured to perform the operations previously described.

[0054] In an aspect, a non-transitory computer storage medium is encoded with instructions that, when executed by one or more processors, cause the one or more processors to perform the operations or method previously described.

[0055] The details of one or more embodiments of these systems and methods are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of these systems and methods will be apparent from the description and drawings, and from the claims.BRIEF DESCRIPTION OF THE FIGURES

[0056] FIG. 1 illustrates an example non-terrestrial network (NTN), according to some implementations.

[0057] FIG. 2 illustrates a timing advance command Medium Access Control (MAC) Control Element (CE), according to some implementations.

[0058] FIG. 3 illustrates a new extension command MAC CE, according to some implementations.

[0059] FIG. 4A and FIG. 4B illustrate example extension duration start time options, according to some implementations.

[0060] FIG. 5 illustrates a global navigation satellite systems (GNSS) Measurement Command MAC CE, according to some implementations.

[0061] FIG. 6 illustrates an example uplink (UL) transmission extension, according to some implementations.

[0062] FIG. 7 illustrates an example process, according to some implementations.

[0063] FIG. 8 illustrates an example user equipment (UE), according to some implementations.

[0064] FIG. 9 illustrates an example access node, according to some implementations.DETAILED DESCRIPTION

[0065] A non-terrestrial network (NTN) is a network that includes non-terrestrial flying equipment that serve as access nodes to user equipment (UEs). An NTN can include satellites, high-altitude platform systems (HAPS), an air-to-ground network, low-altitude unmanned aerial vehicles (UAVs), among other equipment. Due to the relative movements of a UE and / or a satellite serving the UE, the UE can suffer from a Doppler frequency shift and lose synchronization with the satellite (and by extension the NTN).

[0066] To overcome the Doppler frequency shift, a UE can take actions based on a global navigation satellite system (GNSS) location of the UE. Specifically, a UE with GNSS capabilities communicates with a GNSS to determine the UE’s position. The UE then calculates, based on its position, the relative speed between the UE and the NTN satellite, as well as the round-trip time (RTT) between the UE and the satellite. From the relative speed, the UE calculates and applies a pre-compensation for the Doppler frequency shift to ensure that the UE’s service link or uplink (UL) signal is received at the NTN satellite on the desired frequency. The UE’s position is considered valid for a duration called a GNSS validity duration. Once this duration expires, the UE must reacquire its GNSS position by communicating with the GNSS before the UE can perform UL communications with the NTN.

[0067] One of the objectives of Release 18 of the 3GPP work items is to enhance GNSS operations, e.g., for Narrowband-Internet of Things / enhanced Machine Type Communication (NB-IoT / eMTC) devices. Specifically, the objective is to improve GNSS operations for a new position fix for UE pre-compensation during long connection times and for reduced power consumption. One limitation, however, is that UEs, e.g., NB-IoT / eMTC devices, are assumed to not be able to perform simultaneous GNSS and NTN operations (for power saving purposes).

[0068] This disclosure describes systems and methods for enhancing GNSS and NTN operations. In some implementations, the systems and methods extend under certain conditions an UL transmission duration after a GNSS validity duration expires, thereby allowing a UE to perform UL transmissions to the NTN without first performing GNSS reacquisition. As described in more detail below, doing so saves power as the UE can continue to perform UL transmissions to the NTN without first reacquiring the UE’s location from the GNSS.

[0069] The UE is configured to perform a pre-compensation for UL time and frequency synchronization while in a connected mode. The UE can perform the pre-compensation during long connection times. The UE performs pre-compensation to prepare for a scenario in whichGNSS availability and / or accuracy is reduced such that the connection to the GNSS by the UE would otherwise no longer be valid and reacquisition would otherwise be performed.

[0070] This document describes actions by the UE to perform the pre-compensation when the GNSS is temporary unavailable. These actions include receiving an indication from the GNSS that there is an extension of the validity duration period for a dynamic grant for the physical uplink shared channel (PUSCH) and for the configured grant PUSCH. The UE is configured to update the uplink transmission timing and frequency offsets. The UE computes or updates a timing advance (TA) value for the extended validity duration period, such as when a TA command is received from the base station. The UE is further configured to perform a frequency adjustment or correction depending on whether the UE is moving or static. The UE computes an updated frequency offset. The UE reports the capability of the UL transmission during the duration extension period.

[0071] Generally, the base station (network) configures the GNSS validity duration extension period for the connected UE. The duration extension can be triggered by the base station. Within the duration extension period, the UE can perform UL transmissions. The GNSS validity duration can be extended single or multiple times. The base station (network) is configured to send a single or multiple triggering signals that trigger the extension by the UE. Within the GNSS duration extension period, the UE updates the UL transmission timing and frequency offset based on whether the UE is static or in-motion. The UE TA is updated after receiving a TA command from the base station. If the GNSS becomes available such that GNSS position is validated or accuracy satisfies a threshold and the accuracy can be reported to the network, the GNSS validity duration extension period ends.

[0072] The systems and methods described herein provide one or more of the following advantages. The UE can perform a pre-compensation for both a scenario in which the UE is static and a scenario in which the UE is in motion. The UE supports simultaneous GNSS and NR-NTN operation. The UL time and frequency synchronization processes can accommodate a UE GNSS position accuracy of at least 300 meters (e.g., 6 x 50 meters) for FR1. The UL time and frequency synchronization processes can accommodate a UE GNSS position accuracy of at least 90 meters (e.g., 6 x 15 meters) for FR2. The UE is configured to maintain UL time and frequency synchronization during long connection times in case GNSS availability and / or accuracy is reduced from nominal operation. The UE is configured to perform UL time and frequency synchronization during initial access in scenarios in which the GNSS availabilityand / or accuracy are reduced nominal operation. The UE can extend the validity duration period a single time or multiple times, as described herein, based on signaling from the GNSS (the network). This in turn is based on timing and frequency accuracy for the validity duration period.

[0073] FIG. 1 illustrates an example non -terrestrial network (NTN) 100, according to some implementations. Generally, the non-terrestrial network 100 can include any network that uses non-terrestrial components, such as satellites, airplanes, and UAVs, to provide network coverage to a UE. In the example of FIG. 1, the non -terrestrial network 100 includes a nongeo-stationary satellite 102 (“satellite 102”) that has a moving coverage area 104. The nonterrestrial network 100 also includes a core network 106, e.g., a 4G or 5G core network. Although FIG. 1 shows the satellite 102 directly coupled to the core network 106 via link 110, the satellite 102 may alternatively be indirectly coupled to the core network 106, perhaps via a terrestrial base station (not illustrated). In such examples, the link between the satellite 102 and the terrestrial base station is called a feeder link.

[0074] The non-terrestrial network 100 can serve UEs that are located in a coverage area of one of the non-terrestrial components of the network. For example, the non-terrestrial network 100 can serve a UE 108 when the UE is located within the coverage area 104. The UE 108 and any other UE in the system may be, for example, laptop computers, smartphones, tablet computers, machine-type devices, intelligent transportation systems, loT devices, NB- loT / eMTC devices, or any other wireless devices with or without a user interface. The nonterrestrial network 100 can provide the UE 108 with network connectivity to a broader network (not shown in FIG. 1), such as the Internet.

[0075] In some implementations, the satellite 102 provides network services to UEs via a service link. The satellite 102 can implement either a transparent payload or a regenerative payload. A transparent payload refers to an arrangement in which the satellite 102 receives a signal and transmits an amplified version of the signal. For example, the satellite 102 receives uplink communications from the UE 108 on service link frequencies and transmits an amplified version of the signal to the core network 106 on feeder link frequencies or may receive downlink communications from the core network 106 on the feeder link frequencies and transmit an amplified version of the signal to the UE 108 on the service link frequencies.

[0076] A regenerative payload refers to an arrangement in which the satellite 102 acts as a distributed unit (DU) or a base station (e.g., access node 800 in FIG. 8). In this arrangement,the satellite 102 regenerates received signals with signal-processing techniques (e.g., demodulation, decoding, switching, encoding, modulation, etc.) before being retransmitted. The satellite 102 generates one or more beams over a service area bounded by its field of view, which can depend on the antenna diagram and minimum elevation angle of the satellite. The coverage areas of the beams are typically elliptically-shaped, e.g., the coverage area 104.

[0077] The example shown in FIG. 1 is not intended to limit the exemplary embodiments in any way. The non-terrestrial network 100 may be integrated with a 5GNR radio access network (RAN) and / or other networks in any of a variety of manners. For example, the non-terrestrial network 100 may include a low earth orbit (LEO) constellation including an array of satellites and gateways with broad interconnectivity via ground-to-ground station (G2G) links, satellite- to-satellite (S2S) links, ground-to-satellite (G2S) links, and satellite-to-ground (S2G) links. Other types of satellite-based NTNs include geostationary-orbiting (GEO) satellites or medium-earth-orbiting (MEO) satellites. Additionally, the non-terrestrial network 100 may include more than one satellite that provides coverage to the UE 108 at overlapping or different times.

[0078] One aspect of GNSS operation enhancement is extending the duration over which a UE can communicate with the non-terrestrial network 100. Under this enhancement, the UL transmission to the NTN is allowed in an extension duration “X” after the original GNSS validity duration expires without the need for GNSS reacquisition. This UL transmission extension can be used when certain conditions are satisfied, for example, when a frequency error and a timing error are within predefined frequency and timing error requirements (with a closed loop time correction). This mechanism is especially useful for low power UEs, e.g., NB- loT / eMTC devices, since extending the GNSS validity duration without GNSS reacquisition saves device power.

[0079] This disclosure additionally describes extension commands that trigger the UL transmission extension. The GNSS validity duration extension can be signaled in a variety of signal types by the base station (network, e.g., an access node). The GNSS can signal the length of the validity duration extension by Radio Resource Control (RRC) signaling, in which the extension period value (in subframes) is selected by the GNSS from a candidate set, as subsequently described. The GNSS can signal the length of the validity duration extension by a Medium Access Control (MAC) Control Element (CE) that is newly defined. The extension duration command MAC CE can indicate the extension period value (in subframes) that isselected by the GNSS from a candidate set. Downlink control information (DCI) from the GNSS can be used to trigger the extension period for the UE. In another example, a timeAlignmentTimer value sets the extension period value (in subframes) by the GNSS from a candidate set. The timeAlignmentTimer value can be used if the validity duration extension is triggered by a Timing Advance Command (TAC), which indicates a change of the uplink timing relative to the current uplink timing in subframes. In this case, the UE restarts the TA timer, even if the GNSS accuracy is not satisfying a threshold.

[0080] In some implementations, the length of the extension duration X depends on an information element (IE) TimeAlignmentTimer sent from the non-terrestrial network 100 to the UE 108, perhaps via higher layer signaling, e.g., Radio Resource Control (RRC) signaling. The IE TimeAlignmentTimer carries one of the following values {sf500, sf75O, sfl280, sfl920, sf2560, sf5120, sfl0240, infinity}, where sf is subframe, and sets the value of a UE timer called timeAlignmentTimer. The TimeAlignmentTimer is specified in 3GPP TS 36.311 and the timeAlignmentTimer is specified in 3GPP TS 36.321.

[0081] In some implementations, the length of the extension duration X depends on whether the IE TimeAlignmentTimer is set to infinity or to a value not infinity (e.g., sf500, sf75O, sfl280, etc.). When TimeAlignmentTimer is not set to infinity, the UE is configured to set the duration X equal to the time remaining on the timeAlignmentTimer. And when the IE TimeAlignmentTimer is set to infinity, the UE is configured to set the duration X equal to a parameter Y that the non -terrestrial network 100 configures to the UE (e.g., via RRC signaling or an extension command, as described in more detail below). Specifically, the non-terrestrial network 100 configures the parameter Y using a 3 -bit field that can have the following values [sf500, sf75O, sfl280, sfl920, sf2560, sf5120, sfl0240], where “sf’ refers to sub-frames. Upon receiving the parameter Y from the non-terrestrial network 100, the UE sets a new timer called ULTransmissionExtensionTimer to the value of the parameter Y. Thus, when the IE TimeAlignmentTimer is infinity, the end of the duration X is at the point when the new timer ULTransmissionExtentionTimer expires. After receiving the parameter Y, the UE is configured to reset the ULTransmissionExtensionTimer using the parameter each time the UE receives an extension command from the non-terrestrial network 100.

[0082] In some implementations, the non-terrestrial network 100 uses an extension command to trigger the UE 108 to extend the UL transmission duration after the GNSS validity durationexpires. The UE 108, upon receiving the extension command, extends the UL transmission duration for the duration X.

[0083] In some implementations, the non-terrestrial network 100 is configured to reuse an existing timing advance command MAC CE as the UL transmission duration extension command. In one option, the non-terrestrial network 100 reuses an existing timing advance command MAC CE as the extension command. In another option, subsequently described, the non-terrestrial network 100 reinterprets certain bits, namely one or more of the Timing Advance Group Identifier (TAG Id) in the timing advance command MAC CE, as the extension command. Note that the TAG Id field is not otherwise used in the non-terrestrial network 100.

[0084] The GNSS validity duration extension can be triggered in one or more ways. The triggering causes extension of the validity duration for a UE. The validity duration extension can be triggered using DCI triggering, the MAC layer via a reused or new MAC CE, or through RRC signaling. While the DCI and MAC layer triggering enable a quick response relative to RRC signaling, for which the UE decodes the RRC signaling and responds.

[0085] The GNSS validity duration extension can be triggered for the UE by DCI signaling. To trigger the validity duration extension for a UE, the DCI signaling can include a value (e.g., a 1 -bit field) to enable or disable the validity duration extension. The base station can include the value in a downlink non-fallback DCI signal. The base station can include the value in an uplink non-fallback DCI signal. This is because the fallback DCI signal is two bits (0-0 or 0- 1), and an extra bit is be added to the non-fallback DCI instead. In an example, a start of the validity duration extension is at a point of an end of a slot that includes the triggering DCI.

[0086] The GNSS validity duration extension can be triggered for the UE by the MAC layer. In an example, an existing timing advance command (TAC) MAC CE is used to trigger the validity duration extension. If a TAC command is received, the UE determines that a duration extension command is being received. The TAC command is typically for the UL timing adjustment for the UE. Here, in some implementations, the UE determines that the duration period is a same duration as the timer in the TAC MAC CE. FIG. 5 illustrates an extension command MAC CE 500 using the existing timing advance command MAC CE. FIG. 5 is subsequently described in greater detail.

[0087] In some implementations, the GNSS validity duration extension can be triggered for the UE by a newly-defined MAC CE. FIG. 2 illustrates an extension command MAC CE 200, according to some implementations. In this option of defining a new MAC CE 200, the nonterrestrial network 100 uses one or more reserved bits “R” to indicate the UL transmission extension (e.g., “1” indicates that extending the UL transmission is allowed) and uses 5 bits of the MAC CE 200 to indicate the length of the duration X from the set of [sf500, sf75O, sfl280, sfl920, sf2560, sf5120, sfl0240 ...].

[0088] FIG. 3 illustrates an extension command MAC CE 300, according to some implementations. In this option of defining a new MAC CE 300, the non -terrestrial network 100 uses a bit “C” indicate the UL transmission extension (e.g., “1” indicates that extending the UL transmission is allowed) and uses 5 bits of the MAC CE 300 to indicate the length of the duration X from the set of [sf500, sf75O, sfl280, sfl920, sf2560, sf5120, sfl0240 ...]. As shown in FIG. 3, the MAC CE 300 also include reserved bits “R.”

[0089] The GNSS validity duration extension can be defined as now described. In some implementations, a start time of the validity duration extension period can be defined as a starting at the point of end of slot with triggering signaling (as shown in timing diagram 400 of FIG. 4A, further described below). This is more suitable with a timer based solution. After receiving the triggering signaling, a timer is (re)starting with the configured length. The timer can be a new timer or the timeAlignmentTimer . In some implementations, the starting point of the validity duration extension period is located at a point of an end of the GNSS validity duration or an end of a previous validity duration extension period, as shown in timing diagram 410 of FIG. 4B.

[0090] The end time of validity duration extension is configured as follows. In some implementations, the end time of validity duration extension occurs when no further triggering signaling is received, when a new GNSS validity duration is reported, or when the timeAlignmentTimer timer duration expires. In some implementations, the end time of validity duration extension occurs when the UE receives disabling signaling. The disabling signaling can include RRC signaling or signaling from the MAC layer, similar to the triggering signal as previously described.

[0091] The possible extension commands and timers described above are summarized in the following tables.

[0092] As described previously, the disclosed systems and methods support two cases for UL transmission extension. In the first case, the IE TimeAlignmentTimer is configured with a value other than infinity, and the timer length of the UL transmission extension is duration X. In the second case, the IE TimeAlignmentTimer is configured with infinity, and the timer length of the UL transmission extension is configured by parameter Y.

[0093] In some implementations, a unified approach is applied to both cases to simplify the UE and base station implementation. In the unified approach, the combination of extension commands (Extension Command Type 1, Extension Command Type 2) and timer (Timer Type 1, Timer Type 2) is the same for both cases. The different possible combinations include: (Extension Command Type 1, Timer Type 1), (Extension Command Type 2, Timer Type 2), (Extension Command Type 1, Timer Type 2), and (Extension Command Type 2, Timer Type 1).

[0094] In some implementations, different approaches are defined for the two cases depending on whether the IE TimeAlignmentTimer is set to infinity or not. If the TimeAlignmentTimer is configured with infinity, the combination of (Extension Command Type 2, Timer Type 2) is applied. And there are two options if the TimeAlignmentTimer is not configured with infinity. In a first option, the combination of (Extension Command Type 1, Timer Type 1) is applied. In a second option, the combination of (Extension Command Type 2, Timer Type 1) is applied.

[0095] In some implementations, there wireless network is configured with different options for the start time of transmission extension duration X. In a first option, Start Time Option 1, the start time of duration X is at the point where original GNSS validity duration expires or the timer (with duration X) expires (if a first extension command has already been received). The extension command is received before the GNSS validity duration expires or before k subframes of the timer expiring, where k subframes is the processing time for downlinksignaling handling. In a second option, Start Time Option 2, the start time of duration X is at the point where the end of subframe in which the extension command is received. In this option, the timer is reset after receiving the extension command.

[0096] FIG. 4A and FIG. 4B illustrate example extension duration start time options, according to some implementations. Specifically, FIG. 4A illustrates Start Time Option 1 and FIG. 4B illustrates Start Time Option 2. As shown in FIG. 4A, under Start Time Option 1, the extension duration starts after the GNSS validity duration expires or after the UL transmission extension timer expires. And as shown in FIG. 4B, under Start Time Option 2, the extension duration starts upon receipt of an extension command (or shortly thereafter).

[0097] In some implementations, the UE is configured to report the capability of supporting UL transmission extension for the two cases of UL transmission extension: TimeAlignmentTimer is configured with a value other than infinity, and TimeAlignmentTimer is configured with infinity. The capability is reported per UE with Geostationary Satellite Orbit (GSO) and Non-Geostationary Satellite Orbit (NGSO) differentiation. The capability is reported per UE with NGSO, GSO is supported by default. In some implementations, the UE can also report the capability of supporting configuration of duration X or Y or both.

[0098] FIG. 5 illustrates a timing advance command MAC CE 500, according to some implementations. In some implementations, the non-terrestrial network 100 is configured to reuse an existing timing advance command MAC CE 500 as the UL transmission duration extension command. In one option, the non -terrestrial network 100 directly reuses the timing advance command MAC CE 500 as the extension command. In this option, the UE 108 is configured to assume that an extension command has been received if the UE receives a timing advance command MAC CE from the non-terrestrial network 100. In another option, the nonterrestrial network 100 reinterprets the TAG Id bit(s) as the extension command. In this option, if one of the TAG Id bit(s) is set to “1,” the UE 108 assumes that an extension command has been received.

[0099] FIG. 6 illustrates an example UL transmission extension timeline 600, according to some implementations. In this example, the UE reports to the NTN the UE’s capability of supporting configuration of duration X or Y or both. The NTN enables UL transmission extension and configures duration X or Y. Then, the UE in RRC connected state could perform the GNSS measurement according to the received aperiodic trigging signaling. The UE reports the remaining GNSS validity duration to the network. In response, the network sends the ULtransmission extension command before the GNSS validity duration expires. After receiving the command, the UE assumes the UL transmission is allowed within the duration X. The starting point of X is end of subframe with extension command (Start Time Option 2 is assumed here). Before the duration X expires, the UE receives another extension command. Then, the UL transmission is extension again on top of previous extension period X, and the timer is reset. The starting point of duration X is end of subframe with the second extension command. If UE doesn’t receive the UL transmission extension command, duration X is ending at the point where timer expires. UE goes to idle mode or perform autonomous GNSS measurement according to network configuration.

[0100] The timing correct pre- compensation by the UE for the validity duration extension is now described. The UE is configured to calculate a timing advance (TA) value during the validity duration extension period. Timing Advance applied by an NR NTN UE in RRC IDLE / INACTIVE and RRC CONNECTED is calculated by Equation (1):where NTAis defined as 0 for PRACH and updated based on TA command field in msg2 / msgB and MAC CE TA command; N^A adj is the UE self-estimated TA to pre-compensate for the service link delay;is network-controlled common TA, and may include any timing offset considered necessary by the network; and NTA offsetis a fixed offset used to calculate the timing advance.

[0101] During the validity duration extension period, the UE calculates the TA according to Equation (2):where N^A adj can be derived based on one or more of the following. In some implementations, ^TA,adj is computed by the UE using a last valid GNSS position fix before the UE lost valid positioning with the GNSS or the GNSS validation signal. In this case, the TA value is fixed because the GNSS connection is not valid. The TA is based on the TAC command. The network side can adjust the TAC value (e.g., the UL transmission timing). In some implementations, ^TA,adj is computed by the UE using the physical random access channel (PRACH) to get the UE-specific value for TA. In this example, there is no compensation from the UE side for theGNSS link. After the UE transmits the PRACH, the network responds with the TAC command. The PRACH can be used to get larger NTA values for the UE. The next time the UE performs TA the UE can use the additional TAC command received by the UE. In some implementations, N^A adj is computed by the UE, when the UE supports dual GNSS systems. For example, if the UE supports multiple GNSS systems such as the Global Positioning System and the Galileo System, the UE can switch from a system in which there is no validation signal, the UE switches to another system. Based on switching from a first system to a second system, the UE can acquire a UE-specific TA. The UE determines the value of N^A^°nbased on common TA drift parameters. NTAis the transmit power control (TPC) command received by UE from the base station.

[0102] The TA error rate is larger for mobile UEs. The UE calculated TA is typically not as accurate as the network TAC command. When the UE has a valid position, the TAC overhead is relatively small because the UE can calculate a UE-specific TA. When the UE does not have a valid position from the GNSS, the TAC overhead can increase for calculating the UE-specific TA for the UE to reach timing error requirements. To reduce the TAC overhead, the base station can increase the TA command granularity for GNSS temporary unavailability for a longer time. For absolute timing correction, the TA command is updated as shown in Equation (3):where K is the timing correction factor, which is configured by the base station. K=l, 2, 3, 4, ... 8. For a relative timing correction, the TA command is updated as shown in Equation (4):where K is the timing correction factor, which is configured by the base station. K=l, 2, 3, 4, ... 8. NTAnew is the new network timing advance NTA. NTAOU is the old network timing advance NTA. The larger values mean that the new NTA value is up to 8 times the value of the existing TAC command NTA value.

[0103] The TA command calculation is defined in TS 38.213 as: a timing advance command [11, TS 38.321] in case of random access response or in an absolute timing advance command MAC CE, TA, for a TAG indicates NTA values by index values of TA = 0, 1, 2, ..., 3846, where an amount of the time alignment for the TAG with SCS of 2 -15gkHz is NTA = TA -16-64 / 2g•NTA is defined in [4, TS 38.211] and is relative to the SCS of the first uplink transmission fromthe UE after the reception of the random access response or absolute timing advance command MAC CE.In other cases, a timing advance command [11, TS 38.321], TA, for a TAG indicates adjustment of a current NTA value, NTA old, to the new NTA value, NTA new, by index values of TA = 0, 1, 2, . . . , 63, where for a SCS of 2 -15^ kHz, NTA_new = NTA_oid + (TA - 31) • 16-64 / 2^.

[0104] The frequency correction pre-compensation by the UE for the validity duration extension is now described. In legacy systems there is only timing domain correction using the TAC command to adjust the UL transmission timing, as previously described. The UE is configured to perform the frequency correction when the valid position for the GNSS is not being received by the UE (e.g., is not available or not accurate).

[0105] During the GNSS validity duration extension period, for a static UE, open loop frequency adjustment is applied based on the DL reception frequency. The open loop frequency adjustment is sufficient for frequency correction for adjusting the UL frequency. For a moving UE, a closed loop frequency correction is used which introduces an additional frequency offset. The network indicates the frequency offset correction value to UE. The UE can adjust the UL frequency based on the offset correction value to synchronize with the network.

[0106] Returning to FIG. 5, a timing advance command MAC CE 500, according to some implementations, can indicate the frequency offset from the network. In an example, a new MAC CE is used for the frequency offset correction. The frequency offset value can be an absolute offset value. In some implementations, the frequency offset value can be a relative frequency offset value. In some implementations, the frequency offset value can be per Hertz (Hz). In some implementations, the frequency offset value can be per kHz per bit. The granularity is based on the network choice (from 128 possible values). In another example, the MAC CE can be a re-interpretation of the timing advance command MAC CE 500. In some implementations, the bit in the TAG ID field (2 bits) is repurposed for the timing advance command. The TAG is for the UL C A case and can be repurposed for NR or LTE NTN because a single cell is supported. In some implementations, the bit in the TAG ID field is repurposed for the frequency offset indication, according to a reinterpreted TAG ID. For example, the left 6 bits can indicate a timing advance command or frequency offset. As previously described, the MAC CE 500 can also include the timing adjustment offset values.

[0107] The UE capability signaling is now described. The UE can report a UE capability of UL transmission in the duration extension period. In a first example, the report granularity isper band. In a second example, the report granularity is per UE. In a third example, the UE capability is configured to differentiate by Geosynchronous Earth Orbit (GEO) satellites or Non-Geostationary Earth Orbit (NGSO) satellites (e.g., medium Earth Orbit MEO, Low Earth Orbit LEO, etc.). This configuration enables the UE to perform pre-compensation for the frequency domain (and / or the time domain) for the validity duration extension for any satellite configuration and for any band.

[0108] An example scenario is now described. The UE reports the capability of supporting UL transmission validity duration extension. In the RRC-connected state, the UE performs the GNSS measurement, and UEs reports the remaining GNSS validity duration to the network. If the GNSS is not available or unstable, the UE reports the GNSS validity to the network. The network enables UL transmission extension and configures extension duration length. The UE prepares to receive the extension triggering signaling. If the network sends the UL transmission extension triggering signaling before the GNSS validity duration expires, then after the UE receives the signaling, the UE assumes the UL transmission is allowed within the extension duration period. The starting point of extension period is end of slot with extension triggering signaling (e.g., shown in FIG. 4A). Before the extension period is expired, if the UE receives another duration extension signal, then the UL transmission is extended again on top of previous extension period. The starting point of the duration period is the end of the slot with the second extension triggering signaling. If UE does not receive the UL transmission extension signaling, the duration period ends where the extension period expires. The UE then goes to an idle mode or an inactive mode. If UE GNSS is recovered, the UE reports the remaining GNSS validity duration to the network. The UL transmission extension is then ended.

[0109] FIG. 7 illustrates a flowchart of an example method 700, according to some implementations. For clarity of presentation, the description that follows generally describes method 700 in the context of the other figures in this description. For example, method 700 can be performed by UE 108 of FIG. 1. It will be understood that method 700 can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 700 can be run in parallel, in combination, in loops, or in any order.

[0110] The process 700 includes interfacing (702) with a transceiver to receive an uplink (UL) transmission extension command from a non-terrestrial network (NTN). The process 700 includes, in response to receiving the UL transmission extension command, determining (704)an UL transmission extension pre-compensation timing offset, an UL transmission extension pre-compensation frequency offset, or both the pre-compensation timing offset and the precompensation frequency offset. The process 700 includes interfacing (706) with the transceiver for reporting a capability of the UL transmission in the duration extension period, the capability based on the pre-compensation timing offset, the pre-compensation frequency offset, or both the pre-compensation timing offset and the pre-compensation frequency offset.[OHl] In some implementations, determining the pre-compensation timing offset, the precompensation frequency offset, or both the pre-compensation timing offset and the precompensation frequency offset occurs during an extended a global navigation satellite system (GNSS) validity duration.

[0112] In some implementations, the pre-compensation timing offset is determined based on a last valid GNSS position.

[0113] In some implementations, the pre-compensation timing offset is determined by interfacing with the transceiver to send, to a base station, a signal for a physical random access channel (PRACH); and interfacing with a transceiver to receive, responsive to the signal for PRACH, a timing advance command from the base station specifying a timing advance value.

[0114] In some implementations, a different GNSS is available, and wherein the precompensation timing offset is determined by switching from the GNSS to the different GNSS; acquiring, from the different GNSS, position data; and determining, from the position data, a timing advance value.

[0115] In some implementations, the process 700 includes increasing a timing advance command granularity; and based on the increased timing advance command granularity, determining a timing advance value.

[0116] In some implementations, the timing advance command granularity is increased based on a timing correction factor having a value selected from 1, 2, 3, ... , 8.

[0117] In some implementations, the process 700 includes updating a timing advance 64 command based on NTA= K * TA* 16 * — , where k is a correction factor.

[0118] In some implementations, the process 700 includes updating a timing advance command based on NT1"Anew = NT1-Aold + K * (vTA— 31)y* 16 * 2Uwhere k is a correction factor.

[0119] In some implementations, the pre-compensation frequency offset is determined for a static user equipment (UE), the pre-compensation frequency offset being determined based on an open loop frequency correction determined from a downlink (DL) frequency.

[0120] In some implementations, the pre-compensation frequency offset is determined for an in-motion user equipment (UE), the pre-compensation frequency offset being determined based on a closed loop frequency correction value.

[0121] In some implementations, the process 700 includes interfacing with the transceiver to receive a medium access control (MAC) control element (CE) from a base station, the MAC CE specifying an absolute frequency offset.

[0122] In some implementations, the process 700 includes interfacing with the transceiver to receive a medium access control (MAC) control element (CE) from a base station, the MAC CE specifying a relative frequency offset.

[0123] In some implementations, the absolute frequency offset is reported in kilohertz per bit.

[0124] In some implementations, a timing advance command MAC CE comprises a Timing Advance Group Identifier (TAG Id) field including at least one bit, and wherein the at least one bit indicates that the TAC field includes the pre-compensation timing offset or the precompensation frequency offset.

[0125] In some implementations, reporting the capability of the UL transmission in the duration extension period comprises reporting per frequency band.

[0126] In some implementations, reporting the capability of the UL transmission in the duration extension period comprises reporting per user equipment.

[0127] In some implementations, reporting the capability of the UL transmission in the duration extension period is differentiated based on a type of a global navigation satellite system (GNSS) satellite.

[0128] As described above, the IE TimeAlignmentTimer is specified in TS 36.331. More specifically, TS 36.331 specifies the IE TimeAlignmentTimer as follows:TimeAlignmentTimer-. The IE TimeAlignmentTimer is used to configure the time alignment timer as specified in TS 36.321. The values are in ms.• TimeAlignmentTimer. The IE TimeAlignmentTimer is used to control how long the UE considers the serving cells belonging to the associated TAG to be uplink time aligned. Corresponds to the Timer for time alignment in TS 36.321. Value in number of subframes. Value sf500 corresponds to 500 sub-frames, sf75O corresponds to 750 subframes and so on.TimeAlignmentTimer information element- ASN1 STARTTimeAlignmentTimer : := ENUMERATED { sf500, sf75O, sfl280, sfl920, sf2560, sf5120, sf 10240, infinity}- ASN1STOP

[0129] As also described above, the timer timeAlignmentTimer is specified in TS 36.321. More specifically, TS 36.321specifies the timer timeAlignmentTimer as follows:• timeAlignmentTimer in TS: The MAC entity has a configurable timer timeAlignmentTimer per TAG. The timeAlignmentTimer is used to control how long the MAC entity considers the Serving Cells belonging to the associated TAG to be uplink time aligned, as specified in TS 36.331.

[0130] FIG. 8 illustrates an example UE 800, according to some implementations. The UE 800 may be similar to and substantially interchangeable with UE 108 of FIG. 1.

[0131] The UE 800 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, pressure sensors, thermometers, motion sensors, accelerometers, inventory sensors, electric voltage / current meters, etc.), video devices (for example, cameras, video cameras, etc.), wearable devices (for example, a smart watch), relaxed-IoT devices.

[0132] The UE 800 may include processors 802, RF interface circuitry 804, memory / storage 806, user interface 808, sensors 810, driver circuitry 812, power management integrated circuit (PMIC) 814, one or more antenna(s) 816, and battery 818. The components of the UE 800 may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 8 is intended to show a high-level view of some of the components of the UE 800. However, some of the components shown may be omitted, additional components may bepresent, and different arrangement of the components shown may occur in other implementations.

[0133] The components of the UE 800 may be coupled with various other components over one or more interconnects 820, which may represent any type of interface, input / output, bus (local, system, or expansion), transmission line, trace, optical connection, etc., that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0134] The processors 802 may include processor circuitry such as, for example, baseband processor circuitry (BB) 822A, central processor unit circuitry (CPU) 822B, and graphics processor unit circuitry (GPU) 822C. The processors 802 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 806 to cause the UE 800 to perform operations as described herein.

[0135] In some implementations, the baseband processor circuitry 822A may access a communication protocol stack 824 in the memory / storage 806 to communicate over a 3 GPP compatible network. In general, the baseband processor circuitry 822A may access the communication protocol stack to perform user plane functions at a physical (PHY) layer, medium access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, service data adaptation protocol (SDAP) layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a non-access stratum layer. In some implementations, the PHY layer operations may additionally / altematively be performed by the components of the RF interface circuitry 804. The baseband processor circuitry 822A may generate or process baseband signals or waveforms that carry information in 3 GPP-compatible networks. In some implementations, the waveforms for NR may be based cyclic prefix orthogonal frequency division multiplexing (OFDM) “CP-OFDM” in the uplink or downlink, and discrete Fourier transform spread OFDM “DFT-S-OFDM” in the uplink.

[0136] The memory / storage 806 may include one or more non -transitory, computer-readable media that includes instructions (for example, communication protocol stack 824) that may be executed by one or more of the processors 802 to cause the UE 800 to perform various operations described herein. The memory / storage 806 include any type of volatile or nonvolatile memory that may be distributed throughout the UE 800. In some implementations,some of the memory / storage 806 may be located on the processors 802 themselves (for example, LI and L2 cache), while other memory / storage 806 is external to the processors 802 but accessible thereto via a memory interface. The memory / storage 806 may include any suitable volatile or non-volatile memory such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), Flash memory, solid-state memory, or any other type of memory device technology.

[0137] The RF interface circuitry 804 may include transceiver circuitry and radio frequency front module (RFEM) that allows the UE 800 to communicate with other devices over a radio access network. The RF interface circuitry 804 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0138] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna(s) 816 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that downconverts the RF signal into a baseband signal that is provided to the baseband processor of the processors 802.

[0139] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna(s) 816. In various implementations, the RF interface circuitry 804 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0140] The antenna(s) 816 may include one or more antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna(s) 816 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna(s) 816 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna(s) 816 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0141] The user interface 808 includes various input / output (I / O) devices designed to enable user interaction with the UE 800. The user interface 808 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button), a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position(s), or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes “LEDs” and multi -character visual outputs), or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays “LCDs,” LED displays, quantum dot displays, projectors, etc.), with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 800.

[0142] The sensors 810 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; temperature sensors (for example, thermistors); pressure sensors; image capture devices (for example, cameras or lensless apertures); light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like); depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other like audio capture devices; etc.

[0143] The driver circuitry 812 may include software and hardware elements that operate to control particular devices that are embedded in the UE 800, attached to the UE 800, or otherwise communicatively coupled with the UE 800. The driver circuitry 812 may include individual drivers allowing other components to interact with or control various input / output (I / O) devices that may be present within, or connected to, the UE 800. For example, driver circuitry 812 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 810 and control and allow access to sensors 810, drivers to obtain actuator positions of electro-mechanic components or control and allow access to theelectro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0144] The PMIC 814 may manage power provided to various components of the UE 800. In particular, with respect to the processors 802, the PMIC 814 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0145] In some implementations, the PMIC 814 may control, or otherwise be part of, various power saving mechanisms of the UE 800. A battery 818 may power the UE 800, although in some examples the UE 800 may be mounted deployed in a fixed location and may have a power supply coupled to an electrical grid. The battery 818 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 818 may be a typical lead-acid automotive battery.

[0146] FIG. 9 illustrates an example access node 900 (e.g., a base station or gNB), according to some implementations. The access node 900 may be similar to and substantially interchangeable with base station 102. The access node 900 may include processors 902, RF interface circuitry 904, core network (CN) interface circuitry 906, memory / storage circuitry 908, and one or more antenna(s) 910.

[0147] The components of the access node 900 may be coupled with various other components over one or more interconnects 912. The processors 902, RF interface circuitry 904, memory / storage circuitry 908 (including communication protocol stack 914), antenna(s) 910, and interconnects 912 may be similar to like-named elements shown and described with respect to FIG. 8. For example, the processors 902 may include processor circuitry such as, for example, baseband processor circuitry (BB) 916A, central processor unit circuitry (CPU) 916B, and graphics processor unit circuitry (GPU) 916C.

[0148] The CN interface circuitry 906 may provide connectivity to a core network, for example, a 5th Generation Core network (5GC) using a 5GC -compatible network interface protocol such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to / from the access node 900 via a fiber optic or wireless backhaul. The CN interface circuitry 906 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 906 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0149] As used herein, the terms “access node,” “access point,” or the like may describe equipment that provides the radio baseband functions for data and / or voice connectivity between a network and one or more users. These access nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs or TRPs, and so forth, and can include ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). As used herein, the term “NG RAN node” or the like may refer to an access node 900 that operates in an NR or 5G system (for example, a gNB), and the term “E-UTRAN node” or the like may refer to an access node 900 that operates in an LTE or 4G system (e.g., an eNB). According to various implementations, the access node 900 may be implemented as one or more of a dedicated physical device such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0150] In some implementations, all or parts of the access node 900 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP). In V2X scenarios, the access node 900 may be or act as a “Roadside Unit.” The term “Roadside Unit” or “RSU” may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a “UE-type RSU,” an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU,” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU,” and the like.

[0151] Various components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to.” Reciting a component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) interpretation for that component.

[0152] The foregoing description of one or more implementations provides illustration and description but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0153] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the abovedisclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

[0154] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

WHAT IS CLAIMED IS:

1. One or more processors configured to, when executing instructions stored in a memory, perform operations comprising: decoding an uplink (UL) transmission extension command from a non-terrestrial network (NTN); in response to receiving the UL transmission extension command, determining at least one UL transmission extension pre-compensation offset; and encoding, for transmission, a capability report of the UL transmission for a transmission extension validity duration, the capability based on the pre-compensation offset.

2. The one or more processors of claim 1, wherein determining the at least one pre-compensation offset comprises determining a pre-compensation timing offset, an UL transmission extension pre-compensation frequency offset, or both the pre-compensation timing offset and the pre-compensation frequency offset.

3. The one or more processors of claim 2, wherein determining the precompensation timing offset, the pre-compensation frequency offset, or both the precompensation timing offset and the pre-compensation frequency offset occurs during an extended UL transmission duration.

4. The one or more processors of claim 2, wherein the pre-compensation timing offset is determined based on a last valid GNSS position.

5. The one or more processors of claim 2, wherein the pre-compensation timing offset is determined by: interfacing with the transceiver to send, to a base station, a signal for a physical random access channel (PRACH); and interfacing with a transceiver to receive, responsive to the signal for PRACH, a timing advance command from the base station specifying a timing advance value.

6. The one or more processors of claim 2, wherein a different GNSS is available, and wherein the pre-compensation timing offset is determined by: switching from the GNSS to the different GNSS;acquiring, from the different GNSS, position data; and determining, from the position data, a timing advance value.

7. The one or more processors of claim 2, the operations further comprising: increasing a timing advance command granularity; and based on the increased timing advance command granularity, determining a timing advance value.

8. The one or more processors of claim 7, wherein the timing advance command granularity is increased based on a timing correction factor having a value selected from a set of candidate values.

9. The one or more processors of any of claims 1 through claim 7, the operations further comprising:64 updating a timing advance command based on NTA= K * TA* 16 * — where k is acorrection factor.

10. The one or more processors of any of claims 1 through claim 9, the operations further comprising: updating a timing advance command based on NTAnew= NTAO1C1+ K * (TA— 31) * correction factor.

11. The one or more processors of claim 2, wherein the pre-compensation frequency offset is determined for a static user equipment (UE), the pre-compensation frequency offset being determined based on an open loop frequency correction determined from a downlink (DL) frequency.

12. The one or more processors of claim 2, wherein the pre-compensation frequency offset is determined for an in-motion user equipment (UE), the pre-compensation frequency offset being determined based on a closed loop frequency correction value.

13. The one or more processors of claim 12, the operations further comprising:decoding a medium access control (MAC) control element (CE) received from a base station, the MAC CE specifying an absolute frequency offset.

14. The one or more processors of claim 12, the operations further comprising: decoding a medium access control (MAC) control element (CE) received from a base station, the MAC CE specifying a relative frequency offset.

15. The one or more processors of claim 14, the absolute frequency offset being reported in kilohertz per bit or another granularity according to a pre-configuration.

16. The one or more processors of any of claims 1 through claim 15, wherein a timing advance command MAC CE comprises a Timing Advance Group Identifier (TAG Id) field including at least one bit, and wherein the at least one bit indicates that a timing advance command field includes the pre-compensation timing offset or the pre-compensation frequency offset.

17. The one or more processors of any of claims 1 through claim 16, wherein encoding the capability report of the UL transmission extension validity duration comprises reporting per frequency band.

18. The one or more processors of any of claims 1 through claim 17, wherein encoding the capability report of the UL transmission extension validity duration comprises reporting per user equipment.

19. The one or more processors of any of claims 1 through claim 18, wherein encoding the capability report of the UL transmission extension validity duration is differentiated based on a type of a global navigation satellite system (GNSS) satellite.

20. A method of performing the operations of any of claims 1-19.

21. A user equipment (UE) comprising the one or more processors of any of claims 1-19.

22. A non-transitory computer storage medium encoded with instructions that, when executed by one or more processors, cause the one or more processors to perform the operations of claims 1-19.

23. One or more processors configured to perform operations comprising: interfacing with a transceiver to send an uplink (UL) transmission extension command to a user equipment (UE); and interfacing with the transceiver to receive a capability of the UL transmission for a transmission extension validity duration from the UE, the capability based on a precompensation offset.

24. The one or more processors of claim 23, wherein determining the at least one pre-compensation offset comprises determining a pre-compensation timing offset, an UL transmission extension pre-compensation frequency offset, or both the pre-compensation timing offset and the pre-compensation frequency offset.

25. The one or more processors of claim 24, wherein the pre-compensation timing offset, the pre-compensation frequency offset, or both the pre-compensation timing offset and the pre-compensation frequency offset are determined during an extended UL transmission duration.

26. The one or more processors of claim 25, wherein the pre-compensation timing offset is determined based on a last valid GNSS position.

27. The one or more processors of claim 25, wherein the pre-compensation timing offset is determined based on: decoding, from the UE, a signal for a physical random access channel (PRACH); and encoding, responsive to the signal for PRACH, a timing advance command specifying a timing advance value for sending to the UE.

28. The one or more processors of claim 25, wherein the pre-compensation frequency offset is determined for an in-motion user equipment (UE), the pre-compensation frequency offset being determined based on a closed loop frequency correction value.

29. The one or more processors of claim 28, the operations further comprising: encoding, for transmission to the UE, a medium access control (MAC) control element (CE) from a base station, the MAC CE specifying an absolute frequency offset or a relative frequency offset.

30. The one or more processors of any of claims 23 through claim 29, wherein a timing advance command MAC CE comprises a Timing Advance Group Identifier (TAG Id) field including at least one bit, and wherein the at least one bit indicates that a timing advance command field includes the pre-compensation timing offset or the pre-compensation frequency offset.

Images