Timing advance modification for non-terrestrial networks

Abstract

According to some embodiments, a method is performed by a wireless device for modifying a timing advance (TA) value represented by the formula TA, the method comprising: obtaining a first position estimate of the wireless device used for calculating the (a) term in the TA formula; receiving a first timing advance command from a network node, the first timing advance comprising a NTA value; obtaining a second position estimate of the wireless device used for calculating the (a) in the TA formula; adjusting the NTA value based on the second position estimate to remove the value corresponding to the eliminated timing error from NTA, NTA_new = NTA_old - Terror_UE_position; calculating a TA value for uplink transmission using the adjusted NTA value; and transmitting an uplink transmission using the calculated TA value.

Description

P110778WO02 PCT APPLICATION 1 of 74 Timing Advance Modification for Non-Terrestrial Networks TECHNICAL FIELD

[0001] The present disclosure generally relates to communication networks, and morespecifically to timing advance (TA) modification for a non-terrestrial network (NTN). BACKGROUND

[0002] Third Generation Partnership Project (3GPP) specifies the Evolved Packet System(EPS). EPS is based on the Long-Term Evolution (LTE) radio network and the Evolved Packet Core (EPC). EPS was originally intended to provide voice and mobile broadband (MBB) services but has continuously evolved to broaden its functionality. Since 3GPP release 13, narrowband Internet-of-things (NB-IoT) and LTE for machines (LTE-M) are part of the LTE specifications and provide connectivity to massive machine type communications (mMTC) services.

[0003] 3GPP Release 15 specified the first release of the 5G system (5GS). This is a newgeneration radio access technology intended to serve use cases such as enhanced mobile broadband (eMBB), ultra-reliable and low latency communication (URLLC) and mMTC services. 5G includes the New Radio (NR) access stratum interface and the 5G Core Network (5GC). The NR physical and higher layers reuse parts of the LTE specification, and additional components are introduced when motivated by new use cases. One such component is the introduction of a sophisticated framework for beam forming and beam management to extend the support of the 3GPP technologies to a frequency range going beyond 6 GHz.

[0004] In release 15, 3GPP also started work to prepare NR for operation in a non-terrestrialnetwork (NTN). The work was performed within the Study Item “NR to support Non-Terrestrial Networks” and resulted in 3GPP TR 38.811. In 3GPP release 16, the work to prepare NR for operation in a NTN continued with the Study Item “Solutions for NR to support Non-Terrestrial Network,” which resulted in 3GPP TR 38.821.

[0005] The Release 16 study item resulted in a Work Item for NR in Release 17, “Solutionsfor NR to support non-terrestrial networks (NTN)”, which is described in the Work Item Description RP-193234.

[0006] An objective of a Release 13 work item referred to as Narrowband IoT (NB-IoT) is tospecify a radio access for cellular Internet of things (IoT) that addresses improved indoor coverage,P110778WO02 PCT APPLICATION 2 of 74 support for massive number of low throughput devices, not sensitive to delay, ultra-low device cost, low device power consumption and (optimized) network architecture.

[0007] NB-IoT can be described as a narrowband version of LTE. Similar to eMTC, NB-IoTuses increased acquisition times and time repetitions to extend the system coverage. The repetitions may be seen as a third level of retransmissions added at the physical layer as a complement to those at medium access control (MAC) hybrid automatic repeat request (HARQ) and Radio Link Control (RLC) automatic repeat request (ARQ). A NB-IoT downlink carrier is defined by 12 orthogonal frequency division multiplexing (OFDM) sub-carriers, each of 15 kHz, giving a total baseband bandwidth of 180 kHz. When multiple carriers are configured, several 180 kHz carriers may be used, e.g., for increasing the system capacity, inter-cell interference coordination, load balancing, etc. This design gives NB-IoT a high deployment flexibility.

[0008] NB-IoT supports the different deployment scenarios or modes of operation.

[0009] ‘Stand-alone operation’ uses, for example, the spectrum currently being used by GSMEDGE radio access network (GERAN) systems as a replacement of one or more global system for mobile communication (GSM) carriers. In principle it operates on any carrier frequency which is neither within the carrier of another system nor within the guard band of another system’s operating carrier. The other system can be another NB-IoT operation or any other radio access technology (RAT), e.g. LTE.

[0010] ‘Guard band operation’ uses the unused resource blocks within an LTE carrier’s guardband. The term guard band may also interchangeably be referred to as guard bandwidth. As an example, for LTE bandwidth of 20 MHz (i.e. Bw1= 20 MHz or 100 RBs), the guard band operation of NB-IoT can place anywhere outside the central 18 MHz but within 20 MHz LTE bandwidth.

[0011] ‘In-band operation’ uses resource blocks within a normal LTE carrier. The in-bandoperation may also interchangeably be referred to as in-bandwidth operation. More generally, the operation of one RAT within the bandwidth of another RAT is also referred to as in-band operation. As an example, in a LTE bandwidth of 50 RBs (i.e. Bw1= 10 MHz or 50 RBs), NB-IoT operation over one resource block (RB) within the 50 RBs is referred to as in-band operation.

[0012] NB-IoT defines anchor and non-anchor carriers. On an anchor carrier the UE assumesthat anchor specific signals including NPSS / NSSS / NPBCH / SIB-NB are transmitted in the downlink. On a non-anchor carrier, the UE does not assume that NPSS / NSSS / NPBCH / SIB-NB are transmitted in downlink. The anchor carrier is transmitted on at least subframes #0, #4, #5 in every frame and subframe #9 in every other frame. Additional downlink subframes in a frame can also be configured on the anchor carrier by means of a downlink bit map. The anchor carriers transmitting NPBCH / SIB-NB contains also NRS. The non-anchor carrier contains NRS duringP110778WO02 PCT APPLICATION 3 of 74 certain occasions and UE specific signals such as NPDCCH and NPDSCH. NRS, NPDCCH and NPDSCH are also transmitted on the anchor carrier. The resources for a non-anchor carrier are configured by the network, i.e. the eNB. The non-anchor carrier can be transmitted in any subframe as indicated by a downlink bit map. For example, the eNB signals a downlink bit map of downlink subframes using a Radio Resource Control (RRC) message (DL-Bitmap-NB) which are configured as a non-anchor carrier. The anchor carrier and / or non-anchor carrier may typically be operated by the same network node (eNB), e.g., by the serving cell. But the anchor carrier and / or non-anchor carrier may also be operated by different network nodes (i.e., different eNBs).

[0013] There is an ongoing resurgence of satellite communications. Several plans for satellitenetworks have been announced in the past few years. The target services vary, from backhaul and fixed wireless, to transportation, to outdoor mobile, to IoT. Satellite networks could complement mobile networks on the ground by providing connectivity to underserved areas and multicast / broadcast services.

[0014] To benefit from the strong mobile ecosystem and economy of scale, adapting theterrestrial wireless access technologies including LTE and NR for satellite networks is drawing significant interest, which has been reflected in the 3GPP standardization work. In 3GPP release 15, 3GPP started the work to prepare NR for operation in a non-terrestrial network (NTN).

[0015] The work was performed within the study item “NR to support Non-TerrestrialNetworks” and resulted in 3GPP TR 38.811. In 3GPP release 16, the work to prepare NR for operation in an NTN continued with the study item “Solutions for NR to support Non-Terrestrial Network”, which has been captured in 3GPP TR 38.821. In parallel, the interest to adapt NB-IoT and LTE-M for operation in NTN is growing. As a consequence, 3GPP release 17 contains both a work item on NR NTN and a study item and work item on NB-IoT and LTE-M support for NTN (RP-193235, Study on NB-IoT / eMTC support for Non-Terrestrial Network; RP-211601, NB- IoT / eMTC support for Non-terrestrial Networks (NTN), RAN#92-e, Jun 2021).

[0016] A satellite radio access network usually includes the following components: a satellitethat refers to a space-borne platform; an Earth-based gateway that connects the satellite to a base station or a core network, depending on the choice of architecture; a feeder link that refers to the link between a gateway and a satellite; and an access link, or service link, that refers to the link between a satellite and a UE.

[0017] Depending on the orbit altitude, a satellite may be categorized as low Earth orbit(LEO), medium Earth orbit (MEO), or geostationary Earth orbit (GEO) satellite. LEO includes typical heights ranging from 250 – 1,500 km, with orbital periods ranging from 90 – 120 minutes. MEO includes typical heights ranging from 1,500 – 35,786 km, with orbital periods, PMEO, in theP110778WO02 PCT APPLICATION 4 of 74 range 2 hours < PMEO < 24 hours. MEO and LEO are also known as a non-geosynchronous orbit (NGSO) type of satellite. GEO includes a height at about 35,786 km, with an orbital period of 24 hours. Also known as a geosynchronous orbit (GSO) type of satellite.

[0018] Two basic architectures can be distinguished for satellite communication networks,depending on the functionality of the satellites in the system:

[0019] One architecture is transparent payload (also referred to as bent pipe architecture). Thesatellite forwards the received signal between the terminal and the network equipment on the ground with only amplification and a shift from uplink frequency to downlink frequency. When applied to general 3GPP architecture and terminology, the transparent payload architecture means that the gNB is located on the ground and the satellite forwards signals / data between the gNB and the UE

[0020] Another architecture is regenerative payload. The satellite includes on-boardprocessing to demodulate and decode the received signal and regenerate the signal before sending it back to the Earth. When applied to general 3GPP architecture and terminology, the regenerative payload architecture means that the gNB is located in the satellite.

[0021] In the work item for NR NTN in 3GPP release 17, only the transparent payloadarchitecture is considered.

[0022] FIGURE 1 shows an example architecture of a satellite network with bent pipetransponders (i.e., the transparent payload architecture). The gNB may be integrated in the gateway or connected to the gateway via a terrestrial connection (wire, optic fiber, wireless link).

[0023] The significant orbit height means that satellite systems are characterized by a pathloss that is significantly higher than what is expected in terrestrial networks. To overcome the pathloss, it is often required that the access and feeder links are operated in line-of-sight conditions, and that the UE is equipped with an antenna offering high beam directivity.

[0024] A communication satellite typically generates several beams over a given area. Thefootprint of a beam is usually in an elliptic shape, which has been traditionally considered as a cell (but a cell consisting of multiple beams is not precluded). The footprint of a beam is also often referred to as a spotbeam. The spotbeam may move over the Earth surface with the satellite movement (and the Earth’s rotation) or may be Earth fixed using beam pointing by the satellite to compensate for its motion. The size of a spotbeam depends on the system design and may range from tens of kilometers to a few thousands of kilometers.

[0025] The NTN beam may, in comparison to the beams observed in a terrestrial network,provide a very wide footprint and may cover an area outside of the area defined by the served cell. Beam covering adjacent cells will overlap and cause significant levels of intercell interferenceP110778WO02 PCT APPLICATION 5 of 74 resulting from the slow decrease of the signal strength in the outwards radial direction. This is due in part to the high elevation angle and long distance to the network-side (satellite-borne) transceiver, which, compared with terrestrial cells, results in a comparatively small relative difference between the distance from the cell center to the satellite and the distance from a point at the cell edge to the satellite. To overcome the large levels of interference, a typical approach in NTN is to configure different cells with different carrier frequencies and polarization modes.

[0026] NTN supports three types of beams or cells. Earth-fixed beams / cells are provisionedby beam(s) continuously covering the same geographical areas all the time (e.g., for GEO satellites). Quasi-Earth-fixed beams / cells are provisioned by beam(s) covering one geographic area for a limited period and a different geographic area during another period (e.g., for NGSO satellites generating steerable beams). Earth-moving beams / cells are provisioned by beam(s) whose coverage area slides over the Earth’s surface (e.g., in the case of NGSO satellites generating fixed or non-steerable beams).

[0027] The terms beam and cell are used interchangeably herein, unless explicitly notedotherwise.

[0028] Of the three above cell types, quasi-Earth-fixed cells and moving cells seem to be theones most promising for actual deployment. For moving cells, each cell (the footprint of its beam(s)) moves across the surface of the Earth as its serving satellite moves along its orbit. Thus, as seen from the ground, cells gradually replace each other over any given area. For quasi-Earth- fixed cells, the cell area remains fixed to the same geographical area, regardless of satellite movements. To enable this, a serving satellite dynamically directs its beam(s), so that the same area of the Earth is covered despite the satellite’s movement. However, because the satellites orbit around the Earth, it is inevitable that different satellites will have the task of covering a certain geographical cell area at different time periods. When this task is switched from one satellite to another, this in principle means that one cell is replaced by another, although covering the same area (often referred to as a cell switch).

[0029] As a consequence, all UEs connected in the old cell (i.e., UEs in RRC_CONNECTEDstate) are handed over (or otherwise moved, e.g., using Radio Resource Control (RRC) connection reestablishment) from the old to the new cell, and all UEs camping on the old cell (i.e., UEs in RRC_IDLE or RRC_INACTIVE state) perform cell reselection to the new cell. When the satellite serving the area is changed, so that an old cell disappears and a new cell appears, this is referred to as a satellite switch. A consequence of a satellite switch is that both the service link (i.e., the link between the UE and the satellite) and the feeder link (i.e., the link between the satellite and the GW / gNB) are switched.P110778WO02 PCT APPLICATION 6 of 74

[0030] A similar situation occurs in conjunction with feeder link switches, i.e. when theserving satellite remains the same, but its connection to the ground changes from one (old) GW / gNB to another (new) GW / gNB. Also in this case there is a switch between an old cell and a new cell (i.e. the old cell is replaced by a new cell).

[0031] Satellite switches and feeder link switches can both be referred to with the umbrellaterm “cell switch”.

[0032] Such cell switches include two alternative principles: 1) hard switch; and 2) softswitch. With hard switch, there is an instantaneous switch from the old to the new cell, i.e., the new cell appears at the same time as the old cell disappears. This makes completely seamless (i.e., interruption free) handover in practice impossible and creates a situation which may lead to overload of the access resources in the new cell, due to potential access attempt peaks when many UEs try to access the new cell right after the cell switch. With soft switch there is a time period during which the new and the old cell coexist (i.e., overlap), covering the same geographical area. The coexistence / overlap period allows some time for connected UEs to be handed over and for camping UEs to reselect to the new cell, which facilitates distribution of the access load in the new cell and thereby also provides better conditions for handovers with shorter interruption time. Soft switch is likely to be the most prevalent cell switch principle in quasi-Earth-fixed cell deployments.

[0033] Yet another possible deployment option is what is usually referred to as discontinuouscoverage. With discontinuous coverage, NGSO satellites orbit the Earth, providing coverage to moving or quasi-Earth-fixed cells. What characterizes a discontinuous coverage deployment is that when a satellite ceases to provide coverage in a certain location, another satellite does not immediately take over this task. Instead, the location is left without coverage for a certain time until another satellite (or possibly even the same satellite) starts to provide coverage in the location. Discontinuous coverage can thus be seen as a consequence of sparse satellite deployment. It may typically be used during an early phase where the satellite constellation is still being built up and the number of deployed satellites gradually increase. Alternatively, it can be a deployment alternative chosen to reduce the cost of the NTN, e.g., where the targeted customers and applications are insensitive to access delays. In terms of standard specification, special support for discontinuous coverage has so far mainly been taken into account in the specification of the LTE based IoT NTN.

[0034] The gNB and the GW may be separate entities which are spatially separate with a non-negligible propagation delay between them, or they can be integrated in a single entity, or separate entities but collocated in a way that the propagation delay between them is negligible. TheP110778WO02 PCT APPLICATION 7 of 74 embodiments presented herein are applicable in all cases if the (somewhat inappropriate) definition of the feeder link is the communication link between the satellite and the gNB.

[0035] Ephemeris data (sometimes referred to as “ephemeris information” or “ephemerisparameters” or just “ephemeris”) is data that enables a UE (or other entity) to determine a satellite’s position and velocity, i.e., the ephemeris data contains parameters related to the satellite’s orbit. There are several different formats defined for ephemeris data.

[0036] TR 38.821 specifies that ephemeris data should be provided to the UE, for example toassist with pointing a directional antenna (or an antenna beam) towards the satellite, and to calculate a correct timing advance (TA) and Doppler shift. In NR NTN and IoT NTN, ephemeris data will be broadcast in the system information (SI) in each cell, included in an NTN specific SIB, (labeled SIB19 in NR NTN and SIB31 IoT NTN).

[0037] A satellite orbit can be fully described using 6 parameters. Which set of parameters ischosen may be decided by the user; and many different representations are possible. For example, a choice of parameters used often in astronomy is the set (a, ε, i, Ω, ω, t). Here, the semi-major axis a and the eccentricity ε describe the shape and size of the orbit ellipse; the inclination i, the right ascension of the ascending node Ω, and the argument of periapsis ω determine its position in space, and the epoch time t determines a reference time (e.g., the time when the satellites moves through periapsis). This set of parameters is illustrated in Figure 3.

[0038] FIGURE 2 illustrates orbital elements – the parameters included in one ephemeris dataformat.

[0039] As an example of a different parametrization, the two-line elements (TLEs) use meanmotion n and mean anomaly M instead of a and t. A completely different set of parameters is the position and velocity vector (x, y, z, vx, vy, vz) of a satellite. These are sometimes referred to as orbital state vectors. They can be derived from the orbital elements and vice versa, because the information they contain is equivalent. All these formats (and many others) are possible choices for the format of ephemeris data to be used in NTN.

[0040] An aspect discussed during the 3GPP study item and captured in 3GPP TR 38.821 isthe validity time of ephemeris data. Predictions of satellite positions in general degrade with increasing age of the ephemeris data used, due to atmospheric drag, maneuvering of the satellite, imperfections in the orbital models used, etc. Therefore, the publicly available TLE data are updated quite frequently. For example, the update frequency depends on the satellite and its orbit and ranges from weekly to multiple times a day for satellites on very low orbits which are exposed to strong atmospheric drag and need to perform correctional maneuvers often. Even more frequent updates will be used in NR NTN (and IoT NTN) to enable the UE to determine / predict theP110778WO02 PCT APPLICATION 8 of 74 satellite’s position (and velocity) accurately enough to satisfy the requirements in NTN, e.g., to enable a UE to calculate an accurate enough UE-specific TA. In NR NTN, the ephemeris data and the validity time of the ephemeris data is provided to the UE in the ntn-Config IE in the NTN specific SIB, SIB19.

[0041] A global navigation satellite system (GNSS) comprises a set of satellites orbiting theEarth in orbits crossing each other, such that the orbits are distributed around the globe. The satellites transmit signals and data that allows a receiving device on Earth to accurately determine time and frequency references and, maybe most importantly, accurately determine its position, provided that signals are received from a sufficient number of satellites (e.g., four). The position accuracy may typically be in the range of a few meters, but using averaging over multiple measurements, a stationary device may achieve much better accuracy.

[0042] A well-known example of a GNSS is the American Global Positioning System (GPS).Other examples are the Russian Global Navigation Satellite System (GLONASS), the Chinese BeiDou Navigation Satellite System and the European Galileo.

[0043] The transmissions from GNSS satellites include signals that a receiving device uses todetermine the distance to the satellite. By receiving such signals from multiple satellites, the device can determine its position. However, this requires that the device also knows the positions of the satellites. To enable this, the GNSS satellites also transmit data about their own orbits (from which position at a certain time can be derived). In GPS, such information is referred to as ephemeris data and almanac data (or sometimes lumped together under the term navigation information).

[0044] The time required to perform a GNSS measurement, e.g. GPS measurement, may varywidely, depending on the circumstances, mainly depending on the status of the ephemeris and almanac data the measuring devices has previously acquired (if any). In the worst case, a GPS measurement can take several minutes. GPS is using a bit rate of 50 bps for transmitting its navigation information. The transmission of the GPS date, time and ephemeris information takes 90 seconds. Acquiring the GPS almanac containing orbital information for all satellites in the GPS constellation takes more than 10 minutes. If a UE already possesses this information, the synchronization to the GPS signal for acquiring the UE position and Coordinated Universal Time (UTC) is a significantly faster procedure. The state of a GNSS receiver with regards to the above, may be classified as cold, warm or hot state, where the time required to perform a GNSS measurement to determine a position is the longest in cold state, and the shortest in hot state.

[0045] A relevant note on terminology is that a position determined based on a GNSSmeasurement, or the act of determining a position based on a GNSS measurement, is also referred to as a “position fix”.P110778WO02 PCT APPLICATION 9 of 74

[0046] 3GPP relies on GNSS for NR NTN and IoT NTN. To handle the timing and frequencysynchronization in an NR or LTE based NTN, a promising technique is to equip each device with a GNSS receiver. The GNSS receiver enables a device to estimate its geographical position. In one example, an NTN gNB carried by a satellite, or communicating via a satellite, broadcasts its ephemeris data (i.e., data that informs the UE about the satellite’s position, velocity, and orbit) to a GNSS equipped UE. The UE can then determine the propagation delay, the delay variation rate, the Doppler shift, and its variation rate based on its own location (obtained through GNSS measurements) and the satellite location and movement (derived from the ephemeris data).

[0047] The UE may use this knowledge to compensate its uplink transmissions for thepropagation delay and Doppler effect.

[0048] This principle is used in both NR NTN and IoT NTN. However, an IoT NTN UE isnot expected to be able to perform a GNSS measurement while receiving transmissions from network at the same time.

[0049] The GNSS receiver also enables a device to determine a time reference (e.g., in termsof UTC) and frequency reference.

[0050] When using GNSS measurements for purposes related to the operation andperformance of an NR NTN or IoT NTN, the GNSS measurement must be fresh enough to be reliable. For this reason, the notion of a GNSS validity duration has been introduced, which governs the maximum age UE location information may have when used in such operations (e.g., for calculation of a timing advance). A suitable value for this maximum age may depend on the UE’s implementation, and therefore the GNSS validity duration is a UE implementation specific mechanism. However, the standard specifications for IoT NTN specify means by which the UE can inform the network (i.e., the serving eNB in IoT NTN) of the remaining validity time of the UE’s current (most recent) GNSS position measurement result.

[0051] The long propagation delay / round trip time (RTT) in an NTN impacts the timingadvance. Propagation delay is an important aspect of satellite communications and its expected impact in NTN is different from the impacts of propagation delay in a terrestrial mobile system. For a bent pipe satellite network, the UE-gNB round-trip delay may, depending on the orbit height, range from a few or tens of ms for LEO satellites to several hundreds of ms for GEO satellites. As a comparison, the round-trip delays in terrestrial cellular networks are typically below 1 ms.

[0052] The distance between the UE and a satellite can vary significantly, depending on theposition of the satellite and thus the elevation angle ε seen by the UE. Assuming circular orbits, the minimum distance is realized when the satellite is directly above the UE (ε = 90°), and the maximum distance when the satellite is at the smallest possible elevation angle. Table 1 shows theP110778WO02 PCT APPLICATION 10 of 74 distances between satellite and UE for different orbital heights and elevation angles together with the one-way propagation delay and the maximum propagation delay difference (the difference from the propagation delay at ε = 90°). Note that this table assumes regenerative payload architecture. For the transparent payload case, the propagation delay between gateway and satellite needs to be considered as well, unless the base station corrects for that. Table 1: Propagation delay for different orbital heights and elevation angles. Orbital Elevation Distance One-way Propagation delay height angle UE <-> satellite propagation delay difference 600 km 90° 600 km 2.0 ms ---30° 1075 km 3.6 ms 1.6 ms10° 1932 km 6.4 ms 4.4 ms1200 km 90° 1200 km 4.0 ms ---30° 1999 km 6.7 ms 2.7 ms10° 3131 km 10.4 ms 6.4 ms35786 km 90° 35786 km 119.4 ms ---30° 38609 km 128.8 ms 9.4 ms10° 40581 km 135.4 ms 16.0 ms

[0053] The distance between the UE and a satellite can vary significantly, depending on theposition of the satellite and thus the elevation angle seen by the UE. The propagation delay may also be highly variable due to the high velocity of the LEO and MEO satellites and change in the order of 10 – 100 µs every second, depending on the orbit altitude and satellite velocity.

[0054] The long propagation delays in NTN have many consequences, one of which beingthat large Timing Advance (TA) values have to be used, where a TA is the time a UE has to advance its UL transmission in relation to the corresponding frame, slot and symbol in the DL to achieve alignment between the UL and the DL frame / slot / symbol structure at an UL / DL alignment reference point (in 3GPP NTN terminology also known as the uplink time synchronization reference point), which typically is the gNB, but which the specifications also allow the network / operator to place between the gNB on the ground (in the transparent payload deployment case) and the satellite. The part of the TA that accounts for the RTT between the satellite and the uplink time synchronization reference point is common for all UEs in a cell, whereas the part of the TA that accounts for the RTT between the UE and the satellite depends on the UE’s location and is thus specific for each UE. In addition, due to the fast movement of the satellite (excluding GEO satellites), the TA will continuously change and will do so quite rapidly.

[0055] 3GPP has dealt with these circumstances through a combination of new parametersand introduction of the principle of UE autonomous adaptation of the TA.P110778WO02 PCT APPLICATION 11 of 74

[0056] To take care of the part of the TA that is common for all UEs in the cell, the satellitebroadcasts in the system information (SIB19 in NR NTN and SIB31 in IoT NTN) Common TA information, consisting of a Common TA value. The UE specific part of the TA, i.e., the UE- satellite RTT is left to the UE to autonomously calculate. To do this, the UE has to obtain its own location and the satellite position. The UE can obtain its own location e.g., using GNSS measurements, and the satellite’s position (as well as its velocity) can be derived from the ephemeris data broadcast by the gNB (in the same SIB as the Common TA parameters). The ephemeris data and the Common TA parameters are nominally valid at an epoch time, which is also indicated in the same SIB (or, if the epoch time indication is absent in the SIB, the epoch time is assumed to be the end of the SI window in which the SIB was received). Based on the ephemeris data, the UE can predict the satellite’s position a certain time into the future, and the first and second time derivatives (i.e., the drift and drift variation parameters) of the Common TA allows the UE to calculate how the Common TA value changes with time. Furthermore, the broadcast ephemeris data and Common TA parameters have a limited validity time, which is also indicated in the same SIB. The ephemeris data and Common TA parameters the UE uses when calculating the UE specific TA have to be valid, i.e. their validity time must not have expired. The same goes for the UE location information, typically based on a GNSS measurement, the UE uses in the TA calculation (in particular to calculate the UE-satellite RTT).

[0057] Based on the above, a UE calculates the transmit timing as defined in 3GPP TS 38.133version 18.4.0. The uplink frame transmission takes place (^^TA + ^^TA-offset + ^^TcAom,amdjon+ ^^UETA,adj ) × ^^c before the reception of the first detected path (in time) of the corresponding downlinkframe the reference cell.

[0058] That is, the timing advance (TA) is calculated as: ^^^^ = (^^TA + ^^TA-offset +^^commonTA,adj + ^^ UETA,adj ) × ^^c where ^^TA-offset is a configurable offset, ^^TUAE,adjis the common timingthe broadcast common TA parameters), ^^TUAE,adjis the UE specific TA part covering the RTT of the service link (i.e. the UE-satellite RTT) and ^^TAis the part that the network adjusts with the Timing Advance Commands (e.g. Timing Advance Command MAC CEs). ^^cis the basic time unit for NR defined in 3GPP TS 38.211 version 18.1.0 as: Tc ^ 1 ^^fmax ^ Nf ^ where Δ^^ 3 Nmax = 480 ∙ 10 Hz and f ^ 4096 , i.e. ^^^^ ≈ 0.509 ^^^^.the possibility to place theuplink time synchronization reference point some other place than in the gNB, i.e. somewhere between the gNB and the satellite in the transparent payload deployment architecture. This support comes in the form of a parameter denoted as Kmac. The Kmac parameter takes care of the RTTP110778WO02 PCT APPLICATION 12 of 74 between the gNB and the chosen UL / DL alignment reference point. Thus, Kmac = 0 means that the UL / DL alignment reference point is located in the gNB, while other Kmac values will place the UL / DL alignment reference point somewhere between the gNB and the satellite. Kmac is included in the same SIB as the other above mentioned NTN specific configuration parameters. Broadcast of Kmac is optional and absence of a Kmac parameter in the concerned SIB implicitly means that Kmac = 0 should be used.

[0060] When calculating the UE specific TA, the UE only uses the Common TA parameters,the ephemeris data and its own location, i.e. Kmac is not needed for this calculation. However, the UE needs to know Kmac for other purposes, so that it can adapt certain timers to the UE-gNB RTT.

[0061] For Non-Terrestrial Networks using 3GPP technology, in particular 5G / NR (and LTEin case of IoT NTN), the long propagation delay means that the timing advance (TA) the UE uses for its uplink transmissions is essential and has to be much greater than in terrestrial networks for the uplink and downlink to be time-aligned at the gNB or eNB (or at another point if Kmac > 0). One of the purposes of the random access (RA) procedure is to provide the UE with a valid TA. However, even the random access preamble (i.e. the initial message from the UE in the random access procedure) has to be transmitted with a timing advance to allow a reasonable size of the RA preamble reception window in the gNB (and to ensure that the cyclic shift of the preamble’s Zadoff-Chu sequence cannot be so large that it makes the Zadoff-Chu sequence, and thus the preamble, appear as another Zadoff Chu sequence, and thus as another preamble, based on the same Zadoff-Chu root sequence), but this TA does not have to be as accurate as the TA the UE subsequently uses for other uplink transmissions, where the TA has to be accurate enough to keep the timing error smaller than the cyclic prefix (CP) (or preferably smaller than a specified timing error limit which the UE is supposed to aim to stay below).

[0062] In conjunction with the random access procedure, the gNB provides the UE with anaccurate (i.e. fine-adjusted) TA in the Random Access Response (RAR) message (in 4-step RA) or MsgB (in 2-step RA), based on the time of reception of the random access preamble. In NR, the gNB can subsequently adjust the UE’s TA using a Timing Advance Command MAC CE (or an Absolute Timing Advance Command MAC CE), based on the timing of receptions of uplink transmissions from the UE. A goal with such network control of the UE’s timing advance is typically to keep the time error of the UE’s uplink transmissions at the gNB’s receiver within the cyclic prefix (which is required for correct decoding of the uplink transmissions, e.g., on the PUSCH and the PUCCH) (or preferably smaller than a specified timing error limit which the UE is supposed to aim to stay below). The timing advance control framework for NR and LTE alsoP110778WO02 PCT APPLICATION 13 of 74 includes a time alignment timer (TAT) that the gNB configures the UE with. TAT is used to control how long the UE considers the timing advance (TA) information provided by the network as valid. The value is configured per Timing Advance Group (TAG) via a dedicated RRC message or broadcast in System Information. The TAT for a Primary Timing Advance Group (PTAG) is (re)started when any of the following conditions are met: a Timing Advance Command MAC CE is received for the TAG; a Timing Advance Command is received in a Random Access Response (RAR) message or a MsgB for a Serving Cell belonging to a TAG; an Absolute Timing Advance Command is received in a MsgB in response to a MsgA transmission including the C-RNTI MAC CE and small data transmission using configured grant (CG) is not ongoing; an instruction from the upper layer has been received for starting the TAT associated with the PTAG, and the MAC entity is configured with rach-LessHO.

[0063] When a TAT expires, if the TAT is associated with the PTAG, then: flush all HARQbuffers for all Serving Cells; notify RRC to release PUCCH for all Serving Cells, if configured; notify RRC to release sounding reference signal (SRS) for all Serving Cells, if configured; clear any configured downlink assignments and configured uplink grants; clear any PUSCH resource for semi-persistent CSI reporting; and consider all running TATs as expired.

[0064] Otherwise, if the TAT is associated with an STAG, then for all Serving Cells belongingto this TAG: fush all HARQ buffers; notify RRC to release PUCCH, if configured; notify RRC to release SRS, if configured; clear any configured downlink assignments and configured uplink grants; and clear any PUSCH resource for semi-persistent CSI reporting.

[0065] Furthermore, the MAC entity shall not perform any uplink transmission on a servingcell except the Random Access Preamble and MsgA transmission when the TAT associated with the TAG to which this serving cell belongs is not running.

[0066] It should be further emphasized that a crucial extension of the TA framework in NTNis the concept of UE autonomous TA adjustments. These are performed by the UE based on the broadcast ephemeris and common TA parameters and the UE’s own location, as previously described. When this mechanism is used efficiently, the use of network instructed TA adjustments by means of Timing Advance Command MAC CEs can be much reduced.

[0067] The long propagation delays and the resulting large TA a UE has to use also impactsthe scheduling of uplink transmissions. Specifically, the network has to take the large TA into account when it determines the delay to be used between an UL grant (i.e. a DCI on the PDCCH allocating uplink transmission resources for the UE to transmit on) and the uplink transmission resources the UL grant allocates. For this purpose, a new parameter denoted as “Koffset” (or “Koffset” or “K_offset”) has been introduced, which is added to the legacy delay, e.g. added toP110778WO02 PCT APPLICATION 14 of 74 the legacy delay parameter K2 (or K2) contained in the UL grant in NR NTN. The Koffset parameter comes in two forms: the cell-specific Koffset, which is broadcast in the system information and which is common for all UEs in the cell, and the UE-specific Koffset, which the network optionally configures for a specific UE. Note that configuration of a UE-specific Koffset value is optional, and when it is absent, the cell-specific Koffsetvalue applies. To facilitate for the network to determine a suitable UE-specific Koffset value for a certain UE, a mechanism for TA reporting is introduced in NTN, whereby the UE can report its current TA to the network (where the granularity of the reported TA value is one slot).

[0068] The broadcast system information may include NTN-specific information. Due to thespecial operating conditions in a NTN, the system information broadcast in an NTN cell includes NTN-specific information. To serve this purpose, a new SIB (SIB19) is introduced in NR NTN that contains NTN-specific information. In IoT NTN, the new SIB31 more or less corresponds to SIB19 in NR NTN.

[0069] In 3GPP TS 38.331 version 18.0.0, SIB19 is defined as follows in ASN.1 code::-- ASN1START -- TAG-SIB19-START SIB19-r17 ::= SEQUENCE { ntn-Config-r17 NTN-Config-r17 OPTIONAL, -- Need R t-Service-r17 INTEGER (0..549755813887) OPTIONAL, -- Need R referenceLocation-r17 ReferenceLocation-r17 OPTIONAL, -- Need R distanceThresh-r17 INTEGER(0..65525) OPTIONAL, -- Need R ntn-NeighCellConfigList-r17 NTN-NeighCellConfigList-r17 OPTIONAL, -- Need R lateNonCriticalExtension OCTET STRING OPTIONAL, ..., [[ ntn-NeighCellConfigListExt-v1720 NTN-NeighCellConfigList-r17 OPTIONAL -- Need R ]], [[ movingReferenceLocation-r18 ReferenceLocation-r17 OPTIONAL, -- Need R satSwitchWithReSync-r18 SatSwitchWithReSync-r18 OPTIONAL -- Need R ]] } NTN-NeighCellConfigList-r17 ::= SEQUENCE (SIZE(1..maxCellNTN-r17)) OF NTN-NeighCellConfig- r17 NTN-NeighCellConfig-r17 ::= SEQUENCE { ntn-Config-r17 NTN-Config-r17 OPTIONAL, -- Need R carrierFreq-r17 ARFCN-ValueNR OPTIONAL, -- Need R physCellId-r17 PhysCellId OPTIONAL -- Need R }P110778WO02 PCT APPLICATION 15 of 74 SatSwitchWithReSync-r18 ::= SEQUENCE { ntn-Config-r18 NTN-Config-r17, t-ServiceStart-r18 INTEGER (0..549755813887) OPTIONAL, -- Need R ssb-TimeOffset-r18 INTEGER (0..159) OPTIONAL -- Need R } -- TAG-SIB19-STOP -- ASN1STOP SIB19 field descriptions distanceThresh Distance from the serving cell reference location and is used in location-based measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304. Each step represents 50m. This field is only present in an NTN cell. movingReferenceLocation Reference location of the serving cell of an NTN Earth moving system at a time reference. It is used in location-based measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304. The time reference of this field is indicated by epochTime in ntn-Config of the serving cell. This field is excluded when determining changes in system information, i.e., changes to movingReferenceLocation should neither result in system information change notifications nor in a modification of valueTag in SIB1. This field is only present in an NTN cell. ntn-Config Provides parameters needed for the UE to access NR via NTN access such as Ephemeris data, common TA parameters, k_offset, validity duration for UL sync information and epoch. In a TN cell, this field is only present in ntn- NeighCellConfigList and ntn-NeighCellConfigListExt. ntn-NeighCellConfigList, ntn-NeighCellConfigListExt Provides a list of NTN neighbour cells including their ntn-Config, carrier frequency and PhysCellId. This set includes all elements of ntn-NeighCellConfigList and all elements of ntn-NeighCellConfigListExt. If ntn-Config is absent for an entry in ntn- NeighCellConfigListExt, the ntn-Config provided in the entry at the same position in ntn-NeighCellConfigList applies. Network provides ntn-Config for the first entry of ntn-NeighCellConfigList. If the ntn-Config is absent for any other entry in ntn- NeighCellConfigList, the ntn-Config provided in the previous entry in ntn- NeighCellConfigList applies.P110778WO02 PCT APPLICATION 16 of 74 SIB19 field descriptions distanceThresh Distance from the serving cell reference location and measurement initiation in RRC_IDLE and38.304. Each step represents 50m. This field is only present in an NTN cell. movingReferenceLocationRRC_INACTIVE, as defined in TS 38.304. The time reference of this field is indicated by epochTime in ntn-Config of the serving cell. This field is excluded when determining changes in system information, i.e., changes to movingReferenceLocation should neither result in system information change notifications nor in a modification of valueTag in SIB1. This field is only present in an NTN cell. referenceLocation Reference location of the serving cell provided via NTN quasi-Earth fixed system and is used in location-based measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304. This field is only present in an NTN cell. satSwitchWithReSyncthat satellite switch without PCI change is supported in the cell. t-Service Indicates the time information on when a cell provided via NTN system is going to stop serving the area it is currently covering. This field applies for both service link switches in NTN quasi-Earth fixed system and feeder link switches for both NTN quasi-Earth fixed and Earth moving system. The field indicates a time in multiples of 10 ms after 00:00:00 on Gregorian calendar date 1 January, 1900 (midnight between Sunday, December 31, 1899 and Monday, January 1, 1900). The exact stop time is between the time indicated by the value of this field minus 1 and the time indicated by the value of this field. The reference point for t-Service is the uplink time synchronization reference point of the cell. This field is only present in an NTN cell.P110778WO02 PCT APPLICATION 17 of 74 satSwitchWithReSync field descriptionsssb-TimeOffset Indicates the time offset between the SSB from source and target satellite at the uplink time synchronization reference point. It is given in number of subframes. t-ServiceStart Indicates the time information on when the target area currently covered by the serving satellite. Theof 10 ms after 00:00:00 on Gregorian calendar date 1stJanuary 1900 (midnight between Sunday, December 31, 1899, and Monday, January 1, 1900). The exact start time is between the time indicated by the value of this field minus 1 and the time indicated by the value of this field.

[0070] Furthermore, the NTN-Config-r17 IE is defined as follows in ASN.1 code in the samespecification: -- ASN1START -- TAG-NTN-CONFIG-START NTN-Config-r17 ::= SEQUENCE { epochTime-r17 EpochTime-r17 OPTIONAL, -- Need R ntn-UlSyncValidityDuration-r17 ENUMERATED{s5, s10, s15, s20, s25, s30, s35, s40, s45, s50, s55, s60, s120, s180, s240, s900} OPTIONAL, -- Cond SIB19 cellSpecificKoffset-r17 INTEGER(1..1023) OPTIONAL, -- Need R kmac-r17 INTEGER(1..512) OPTIONAL, -- Need R ta-Info-r17 TAInfo-r17 OPTIONAL, -- Need R ntn-PolarizationDL-r17 ENUMERATED {rhcp,lhcp,linear} OPTIONAL, -- Need R ntn-PolarizationUL-r17 ENUMERATED {rhcp,lhcp,linear} OPTIONAL, -- Need R ephemerisInfo-r17 EphemerisInfo-r17 OPTIONAL, -- Need R ta-Report-r17 ENUMERATED {enabled} OPTIONAL, -- Need R ... } EpochTime-r17 ::= SEQUENCE { sfn-r17 INTEGER(0..1023), subFrameNR-r17 INTEGER(0..9) } TAInfo-r17 ::= SEQUENCE { ta-Common-r17 INTEGER(0..66485757), ta-CommonDrift-r17 INTEGER(-257303..257303) OPTIONAL, -- Need R ta-CommonDriftVariant-r17 INTEGER(0..28949) OPTIONAL -- Need R }P110778WO02 PCT APPLICATION 18 of 74 -- TAG-NTN-CONFIG-STOP -- ASN1STOP NTN-Config field descriptions EphemerisInfo This field provides satellite ephemeris either in format of position and velocity state vector or in format of orbital parameters. This field is excluded when determining changes in system information, i.e. changes to ephemerisInfo should neither result in system information change notifications nor in a modification of valueTag in SIB1. epochTime Indicate the epoch time for the NTN assistance information. When explicitly provided through SIB, or through dedicated signaling, EpochTime is the starting time of a DL sub- frame, indicated by a SFN and a sub-frame number signaled together with the assistance information. The reference point for epoch time of the serving satellite ephemeris and Common TA parameters is the uplink time synchronization reference point. If this field is absent, the epoch time is the end of SI window where this SIB19 is scheduled. This field is mandatory present when provided in dedicated configuration. If this field is absent in ntn- Config provided via NTN-NeighCellConfig the UE uses epoch time from the serving satellite ephemeris, otherwise the field is based on the timing of the serving cell, i.e. the SFN and sub- frame number indicated in this field refers to the SFN and sub-frame of the serving cell. In case of handover, this field is based on the timing of the target cell, i.e. the SFN and sub- frame number indicated in this field refers to the SFN and sub-frame of the target cell. This field is excluded when determining changes in system information, i.e. changes to epochTime should neither result in system information change notifications nor in a modification of valueTag in SIB1. cellSpecificKoffset Scheduling offset used for the timing relationships that are modified for NTN [see TS 38.211]. The unit of the field K_offset is number of slots for a given subcarrier spacing of 15 kHz. If the field is absent UE assumes value 0. kmac Scheduling offset provided by network if downlink and uplink frame timing are not aligned at gNB. It is needed for UE action and assumption on downlink configuration indicated by a MAC CE command in PDSCH [see TS 38.2xy]. If the field is absent UE assumes value 0. For the reference subcarrier spacing value for the unit of K_mac in FR1, a value of 15 kHz is used. The unit of K_mac is number of slots for a given subcarrier spacing.P110778WO02 PCT APPLICATION 19 of 74 ntn-PolarizationDL If present, this parameter indicates polarization information for downlink transmission on service link: including Right hand, Left hand circular polarizations (RHCP, LHCP) and Linear polarization. ntn-PolarizationUL If present, this parameter indicates Polarization information for Uplink service link. If not present and ntn-PolarizationDL is present, UE assumes the same polarization for UL and DL. ntn-UlSyncValidityDuration A validity duration configured by the network for assistance information (i.e. Serving and / or neighbour satellite ephemeris and Common TA parameters) which indicates the maximum time during which the UE can apply assistance information without having acquired new assistance information. The unit of ntn-UlSyncValidityDuration is second. Value s5 corresponds to 5 s, value s10 indicate 10 s and so on. This parameter applies to both connected and idle mode UEs. If this field is absent in ntn-Config provided via NTN-NeighCellConfig, the UE uses validity duration from the serving cell assistance information. This field is excluded when determining changes in system information, i.e. changes of ntn-UlSyncValidityDuration should neither result in system information change notifications nor in a modification of valueTag in SIB1. ntn-UlSyncValidityDuration is only updated when at least one of epochTime, ta-Info, ephemerisInfo is updated. ta-Common Network-controlled common timing advanced value and it may include any timing offset considered necessary by the network. ta-Common with value of 0 is supported. The granularity of ta-Common is 4.072 × 10^(-3) μs. Values are given in unit of corresponding granularity. This field is excluded when determining changes in system information, i.e. changes of ta-Common should neither result in system information change notifications nor in a modification of valueTag in SIB1. ta-CommonDrift Indicate drift rate of the common TA. The granularity of ta-CommonDrift is 0.2 × 10^(-3)μs⁄s Values are given in unit of corresponding granularity. This field is excluded whendetermining changes in system information, i.e. changes of ta-CommonDrift should neither result in system information change notifications nor in a modification of valueTag in SIB1.P110778WO02 PCT APPLICATION 20 of 74 ta-CommonDriftVariant Indicate drift rate variation of the common TA. The granularity of ta-CommonDriftVariation is 0.2×10^(-4) μs⁄s^2. Values are given in unit of corresponding granularity. This field is excluded when determining changes in system information, i.e. changes of ta- CommonDriftVariant should neither result in system information change notifications nor in a modification of valueTag in SIB1. ta-Report When this field is included in SIB19, it indicates reporting of timing advanced is enabled during Random Access due to RRC connection establishment or RRC connection resume, and during RRC connection reestablishment.. When this field is included in ServingCellConfigCommon within dedicated signaling, it indicates TA reporting is enabled during Random Access due to reconfiguration with sync (see TS 38.321, clause 5.4.8).

[0071] In LTE, SIB31 contains similar information for IoT NTN as SIB19 does for NR NTN.The following is the ASN.1 code for SIB31 in 3GPP TS 36.331 version 18.0.0. -- ASN1START SystemInformationBlockType31-r17 ::= SEQUENCE { servingSatelliteInfo-r17 ServingSatelliteInfo-r17, lateNonCriticalExtension OCTET STRING OPTIONAL, ... } ServingSatelliteInfo-r17 ::= SEQUENCE { ephemerisInfo-r17 CHOICE { stateVectors EphemerisStateVectors-r17, orbitalParameters EphemerisOrbitalParameters-r17 }, nta-CommonParameters-r17 SEQUENCE { nta-Common-r17 INTEGER (0..8316827) OPTIONAL, -- Need OP nta-CommonDrift-r17 INTEGER (-261935..261935) OPTIONAL, -- Need OP nta-CommonDriftVariation-r17 INTEGER (0..29479) OPTIONAL -- Need OP }, ul-SyncValidityDuration-r17 ENUMERATED {s5, s10, s15, s20, s25, s30, s35, s40, s45, s50, s55, s60, s120, s180, s240, s900}, epochTime-r17 SEQUENCE { startSFN-r17 INTEGER (0..1023), startSubFrame-r17 INTEGER (0..9) } OPTIONAL, -- Need OP k-Offset-r17 INTEGER (0..1023), k-Mac-r17 INTEGER (1..512) OPTIONAL, -- Need OP ..., [[ satelliteId-r18 SatelliteId-r18 OPTIONAL, -- Need ORP110778WO02 PCT APPLICATION 21 of 74 referenceLocation-r18 CHOICE { fixedCell-r18 ReferenceLocation-r18, movingCell-r18 ReferenceLocation-r18 ]] }-- ASN1STOP SystemInformationBlockType31 field descriptionsdistanceThreshP110778WO02 PCT APPLICATION 22 of 74 k-Mac Scheduling offset used when downlink and uplink frame timing are not aligned at the eNB, see TS 36.213. Unit in ms. If the field if absent, the UE uses the (default) value of 0. k-Offset Scheduling offset used in the timing relationships in NTN, see TS 36.213. Unit in ms. nta-Common Network-controlled common TA, see TS 36.213. Unit of μs. Step of 32.55208 ×10-3μs. Actual value = field value * 32.55208 ×10-3. If the field is absent, the UE uses the (default) value of 0. nta-CommonDrift Drift rate of the common TA, see TS 36.213orbitalParameters Instantaneous values of the satellite orbital parameters. Theat least for the duration as defined by ul-SyncValidityDuration and epochTime. referenceLocation Reference location of the NTN quasi-earth fixed cell or earth moving cell, used in location-based measurement initiation in RRC_IDLE (as specified in TS 36.304) and RRC_CONNECTED. If configured by an earth moving cell, the broadcast reference location corresponds to the epoch time, and the UE derives the real-time reference location based on the serving satellite ephemeris, see TS 36.304. stateVectors Instantaneous values of the satellite state vectors. The signalled values are valid at least for the duration as defined by ul-SyncValidityDuration and epochTime.P110778WO02 PCT APPLICATION 23 of 74 ul-SyncValidityDuration Validity duration of the satellite ephemeris data and common TA parameters, i.e. maximum time duration (from epochTime) during which the UE can apply the satellite ephemeris without acquiring new satellite ephemeris, see TS 36.213. Unit in second. Value s5 corresponds to 5 seconds, value s10 corresponds to 10 seconds and so on. The ul-SyncValidityDuration is only updated when at least one of epochTime, nta- CommonParameters, ephemerisInfo is updated.

[0072] SIB32, with ASN.1 code definition as follows in 3GPP TS 36.331 version 18.0.0, alsocontains IoT NTN specific information, which in this SIB is tailored for deployments with discontinuous coverage. -- ASN1START SystemInformationBlockType32-r17 ::= SEQUENCE { satelliteInfoList-r17 SatelliteInfoList-r17 OPTIONAL, -- Need OR lateNonCriticalExtension OCTET STRING OPTIONAL, ..., [[ satelliteInfoList-v1800 SatelliteInfoList-v1800 OPTIONAL -- Need OR ]] } SatelliteInfoList-r17 ::= SEQUENCE (SIZE (1..maxSat-r17)) OF SatelliteInfo-r17 SatelliteInfoList-v1800 ::= SEQUENCE (SIZE (1..maxSat-r17)) OF CarrierFreqList-v1800 SatelliteInfo-r17 ::= SEQUENCE { satelliteId-r17 INTEGER (0..255), serviceInfo-r17 SEQUENCE { tle-EphemerisParameters-r17 TLE-EphemerisParameters-r17 OPTIONAL, -- Need OR t-ServiceStart-r17 TimeOffsetUTC-r17 OPTIONAL -- Need OR }, footprintInfo-r17 SEQUENCE { referencePoint-r17 SEQUENCE { longitude-r17 INTEGER (-131072..131071), latitude-r17 INTEGER (-131072..131071) } OPTIONAL, -- Need OR elevationAngles-r17 SEQUENCE { elevationAngleRight-r17 INTEGER (-14..14), elevationAngleLeft-r17 INTEGER (-14..14) OPTIONAL -- Need OP } OPTIONAL, -- Need OR radius-r17 INTEGER (1..256) OPTIONAL -- Need OR } }P110778WO02 PCT APPLICATION 24 of 74 CarrierFreqList-v1800 ::= SEQUENCE (SIZE (1..maxSat-r17)) OF ARFCN-ValueEUTRA -- ASN1STOP SystemInformationBlockType32 field descriptionscarrierFreqList Includes a list of E-UTRA frequencies, see TS 36.304. Each entry identifies a list of carrier frequencies of a satellite, which corresponds to one SatelliteInfo entry in the SatelliteInfoList. elevationAngleLeft, elevationAngleRight Leftmost and rightmost (with reference to the satellite direction) elevation angle. Unit in degree. Step of 5 degree. Actual value = field value * 5. If the field elevationAngleLeft is absent, the leftmost elevation angle is equal to the value of field elevationAngleRight. footprintInfo Satellite footprint. E-UTRAN may configure elevationAngles and / or radius for earth moving cell. E-UTRAN may configure referencePoint and radius for quasi-earth fixed cell. latitude Latitude of the reference point. Unit in degree. Step of 360 / 262144 degree. Actual value = field value * (360 / 262144). longitude Longitude of the reference point. Unit in degree. Step of 360 / 262144 degree. Actual value = field value * (360 / 262144). radius Distance between the reference point and the edge of the satellite or beam coverage. Unit in km. Step of 10 km. Actual value = field value * 10. serviceInfo Information on when the satellite will provide coverage. E-UTRAN always configures tle-EphemerisParameters for a satellite with earth moving cell(s) and always configures t-ServiceStart for a quasi-earth fixed cell.P110778WO02 PCT APPLICATION 25 of 74 tle-EphemerisParameters Mean values of the satellite orbital parameters based on the TLE set format for estimating in-coverage and out-of-coverage periods for a satellite with earth cell(s), see TS 36.304.t-ServiceStart Time information on when the incoming satellite is going to start serving the area for quasi-earth fixed cell.

[0073] The NTN described above is based on 5G / NR technology adapted for communicationvia satellites. But an NTN standard for IoT, denoted as “IoT NTN”, is also being specified in release 17 of the 3GPP standards. IoT NTN is based on the LTE NB-IoT technology adapted for communication via satellites. To distinguish NTN based 5G / NR technology from IoT NTN, NTN based on 5G / NR technology is often referred to as “NR NTN”. In light of these distinctions, depending on the context, the term “NTN” is sometimes used to refer to either or both of NR NTN and IoT NTN, and sometimes the term “NTN” is used to refer only to NR NTN.

[0074] There currently exist certain challenges. For example, a problem with existingtechnology is related to updates of the UE’s position estimate and the TA formula described above,i.e.: ^^^^ = (^^TA + ^^TA-offset + ^^ commonTA,adj + ^^ UETA,adj ) × ^^c.TA formula that the network adjusts withits instructions, e.g., the Timing Advance Command MAC CEs. This is the term the network uses to keep the UE’s TA within bounds (or at a desired value) e.g. when the UE’s autonomous TA adjustments do not manage to do this well enough. As also mentioned above, the UE depends on the accuracy of its estimation of its own position, typically determined by a GNSS measurement, when calculating the ^^TUAE,adjterm in the TA formula. A UE thus typically performs repeated GNSS measurements to update its estimate of its own position (possibly complemented by other means, such as movement tracking based on internal sensor, such as accelerometers).

[0076] There are diverging views of what the UE should do with NTA in the TA formula whenit acquires a new (more accurate) position estimate (i.e. estimate of its own position), where one view is that the UE should set NTA= 0, while the other view is that the UE should leave NTAas it is. The argument for the former view (set NTA = 0) is that the update of the UE’s position estimate (and thus the update of ^^TUAE,adjand thus the update of the TA) changes the circumstances that have caused the network to adjust NTA to its current value. The argument for the latter view (leave NTA as it is) is that the network should remain in full control of NTAand thus the UE should leave it asP110778WO02 PCT APPLICATION 26 of 74 it is (e.g. because the UE does not have the full picture and cannot know for sure the network’s grounds for adjusting NTAto its current value).

[0077] A problem, which makes it difficult to arrive at converging views, is that none of theseapproaches is likely to produce an optimal NTAvalue. Updating the UE’s position estimate (and thus updating ^^TUAE,adj) changes the outcome when calculating the TA formula, and thus the current NTAvalue cannot be optimal anymore, and thus there is a rationale for resetting NTAto 0. On the other hand, when the network adjusts NTA based on the reception timing of the UE’s transmission, this may be affected by other aspects than the UE’s position, and setting NTA= 0 fails to take these other aspects into account. SUMMARY

[0078] As described above, certain challenges currently exist with timing advance (TA)modification for a non-terrestrial network (NTN). Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. For example, particular embodiments are based on two realizations. The first realization is that there are two main sources of UE transmission timing errors contributing to the total transmission timing error: (1) the UE’s movements between updates of the UE’s position information, and (2) the error in the estimation of the serving satellite’s position and the error in the common TA parameters, both caused mainly by the aging of the ephemeris and common TA parameter (i.e. the elapsed time since the associated epoch time). These are thus the errors the network can use NTA to compensate for.

[0079] The second realization is that the UE can calculate the error caused by the first of thetwo error sources above by comparing the values of ^^TUAE,adjbased on respectively an old UE position estimate and a new (accurate) UE position estimate, e.g. obtained through a GNSS measurement.

[0080] When the UE acquires a new accurate UE position estimate, e.g. through a GNSSmeasurement, the error caused by the UE movements is (temporarily) removed, and thus, a suitable treatment of NTA upon acquisition of a new accurate UE position estimate, e.g. through a GNSS measurement, is to remove the value corresponding to the eliminated timing error from NTA, i.e. NTA_new = NTA_old - Terror_UE_position.

[0081] Particular embodiments include various variations and additional options, e.g.configuration options, as well as a scheme for applying the same principle to the second of the two error sources listed above. In addition, there are a few alternative ways to treat NTAdescribed in more detail below.P110778WO02 PCT APPLICATION 27 of 74

[0082] In general, particular embodiments include the identification of the two main timingerror sources and the method for calculating the size of the one of them associated with the UE’s movements, and further using (by the UE) the result of the calculation to modify the NTA upon acquiring a new accurate UE position estimate such that NTA_new= NTA_old- Terror_UE_position.

[0083] Additional aspects, such as the various configuration options, the scheme for applyingthe solution principle to the timing error caused by the aging of the ephemeris and common TA parameters are also valuable.

[0084] According to some embodiments, a method is performed by a wireless device formodifying a TA value. The TA value is based at least in part on a position estimate of the wireless device and a timing adjustment value. The method comprises: obtaining a first wireless device position estimate used for calculating a TA value; receiving a timing advance command from a network node, the timing advance command comprising an indication of the timing adjustment value; obtaining a second wireless device position estimate used for calculating the TA value; updating the timing adjustment value based on the second wireless device position estimate to remove a value corresponding to a difference between the first wireless device position estimate and the second wireless device position estimate from the timing adjustment value; calculating a TA value for uplink transmission using the updated timing adjustment value; and transmitting an uplink transmission using the calculated TA value.

[0085] In particular embodiments, the method further comprises obtaining a satellite positionestimate used for calculating a TA value, and wherein updating the timing adjustment value is further based on the satellite position estimate.

[0086] In particular embodiments, the method further comprises transmitting an indication tothe network node of the updated timing adjustment value.

[0087] In particular embodiments, the TA value is represented by the formula ^^^^ =(^^ common UTA + ^^TA-offset + ^^TA,adj + ^^ ETA,adj ) × ^^c, wherein ^^TA-offset is a configurable offset, ^^TcAom,amdjonisdevice specific value covering the round trip time of a satellite service link, ^^TAis the timing adjustment value received from the network node; and ^^cis a basic time unit. The first wireless device position estimate and the second wireless device position estimate are used for calculating the ^^TUAE,adjterm in the TA formula. The difference between the first wireless device position estimate and the second wireless device position estimate is represented as Terror_UE_position. The updated timing adjustment value is represented as ^^TA_new= NTA_old - Terror_UE_position.P110778WO02 PCT APPLICATION 28 of 74

[0088] In particular embodiments, the wireless device is operating in a non-terrestrialnetwork.

[0089] According to some embodiments, another method is performed by a wireless devicefor modifying a TA value. The TA value is based at least in part on a position estimate of a satellite and a timing adjustment value. The method comprises: obtaining a first satellite position estimate used for calculating a TA value; receiving a timing advance command from a network node, the timing advance command comprising an indication of the timing adjustment value; obtaining a second satellite position estimate used for calculating the TA value; updating the timing adjustment value based on the second satellite position estimate to remove a value corresponding to a difference between the first satellite position estimate and the second satellite position estimate from the timing adjustment value; calculating a TA value for uplink transmission using the updated timing adjustment value; and transmitting an uplink transmission using the calculated TA value.

[0090] In particular embodiments, the method further comprises obtaining a wireless deviceposition estimate used for calculating a TA value, and wherein updating the timing adjustment value is further based on the wireless device position estimate.

[0091] In particular embodiments, the method further comprises transmitting an indication tothe network node of the updated timing adjustment value.

[0092] In particular embodiments, the TA value is represented by the formula ^^^^ =(^^TA + ^^TA-offset + ^^ commonTA,adj + ^^ UETA,adj ) × ^^c, wherein ^^TA-offset is a configurable offset, ^^TcAom,amdjonisa wireless device specific value covering thetime of a satellite service link, ^^TAis the timing adjustment value received from the network node; and ^^cis a basic time unit. The first satellite position estimate and the second satellite position estimate are used for calculating the ^^TcAom,amdjonterm in the TA formula. The difference between the first satellite position estimate and the second satellite position estimate is represented as Terror_UE_position_and_common_TA. The updated timing adjustment value is represented as ^^TA_new= NTA_old- Terror_UE_position_and_common_TA.

[0093] According to some embodiments, a wireless device comprises processing circuitryoperable to perform any of the wireless device methods described above.

[0094] Also disclosed is a computer program product comprising a non-transitory computerreadable medium storing computer readable program code, the computer readable program code operable, when executed by processing circuitry to perform any of the methods performed by the wireless devices described above.P110778WO02 PCT APPLICATION 29 of 74

[0095] Certain embodiments may provide one or more of the following technical advantages.For example, particular embodiments solve the problem of how a UE should appropriately treat NTA in the TA calculation formula upon acquisition of a new updated UE position estimate, e.g. obtained through a GNSS measurement. BRIEF DESCRIPTION OF THE DRAWINGS

[0096] The present disclosure may be best understood by way of example with reference tothe following description and accompanying drawings that are used to illustrate embodiments of the present disclosure. In the drawings: FIGURE 1 shows an example architecture of a satellite network with bent pipe transponders; FIGURE 2 illustrates orbital elements – the parameters included in one ephemeris data format; FIGURE 3 shows an example of a communication system, according to certain embodiments; FIGURE 4 shows a user equipment (UE), according to certain embodiments; FIGURE 5 shows a network node, according to certain embodiments; FIGURE 6 is a block diagram of a host, according to certain embodiments; FIGURE 7 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized; FIGURE 8 shows a communication diagram of a host communicating via a network node with a UE over a partially wireless connection in accordance with some embodiments. FIGURE 9 is a flowchart illustrating an example method in a wireless device, according to certain embodiments; FIGURE 10 is a flowchart illustrating another example method in a wireless device, according to certain embodiments; and FIGURE 11 is a flowchart illustrating an example method in a communication system, according to certain embodiments. DETAILED DESCRIPTION

[0097] As described above, certain challenges currently exist with timing advance (TA)modification for a non-terrestrial network (NTN). Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. For example, particular embodiments are based on two realizations. The first realization is that there are two main sourcesP110778WO02 PCT APPLICATION 30 of 74 of UE transmission timing errors contributing to the total transmission timing error: (1) the UE’s movements between updates of the UE’s position information, and (2) the error in the estimation of the serving satellite’s position and the error in the common TA parameters, both caused mainly by the aging of the ephemeris and common TA parameter (i.e. the elapsed time since the associated epoch time). These are thus the errors the network can use NTAto compensate for.

[0098] Particular embodiments are described more fully with reference to the accompanyingdrawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0099] As used herein, the term non-terrestrial network may, depending on the context, referto either or both of New Radio (NR) NTN and Internet-of-things (IoT) NTN, and sometimes the term is used to refer to only NR NTN.

[0100] The embodiments outlined below are described mainly in terms of NR based NTNs,but they are equally applicable in an NTN based on Long Term Evolution (LTE) technology (and in particular IoT NTN).

[0101] The term “network” is used herein to refer to a network node, which typically will bea gNB (e.g., in a NR based NTN) or an eNB (e.g., in an LTE based NTN, such as an IoT NTN), but which may also be a base station or an access point in another type of network based on communication via satellites or high-altitude platform systems (HAPS), or any other network node (in a network involving satellites or HAPS) with the ability to directly or indirectly communicate with a UE. Refinements with finer granularity are also conceivable. For example, a gNB may be an en-gNB, and if a split gNB architecture is applied (dividing the gNB into multiple separate entities or notes), the term “network” or “network node” or “node” may refer to a part of the gNB, such as a gNB-central unit (CU) (often referred to as just CU), a gNB-distributed unit (DU) (often referred to as just DU), a gNB-CU-control plane (CP) or a gNB-CU-user plane (UP). Similarly, an eNB may be an ng-eNB, and if a split eNB architecture is applied (dividing the gNB into multiple separate entities or notes), the term “network” (and the network node it implies) may refer to a part of the eNB, such as an eNB-CU, an eNB-DU, an eNB-CU-CP or an eNB-CU-UP. Furthermore, the term “network” (and the network node it implies) may also refer to an integrated access and backhaul (IAB)-donor, IAB-donor-CU, IAB-donor-DU, IAB-donor-CU-CP, or an IAB-donor-CU-UP.

[0102] Ephemeris data is associated with (and applies to) a satellite. However, forconvenience, ephemeris data may sometimes be described as associated with a cell, when the ephemeris data referred to actually is associated with the satellite serving the cell. This convenience practice may be seen e.g., in expressions like “a cell’s ephemeris data” or “theP110778WO02 PCT APPLICATION 31 of 74 ephemeris data of the cell”. Such expressions should be interpreted as short forms of more strictly correct expressions like “a cell’s serving satellite’s ephemeris data”, “the ephemeris data of the cell’s serving satellite” or “the ephemeris data of the satellite serving the cell”.

[0103] When referring to message names of a communication protocol, two equivalentprinciples are used in this document. The principle “<protocol name> <message name> message”, for example “XnAP HANDOVER REQUEST message”, and the principle “<message name> <protocol name> message”, for example “HANDOVER REQUEST XnAP message” are equivalent, both referring to a message (i.e., “<message name>”) of a communication protocol (i.e., “<protocol name>”), e.g., the HANDOVER REQEUST message of the communication protocol XnAP. The same format equivalence applies to other communication protocols, such as NGAP.

[0104] The terms information element (IE) and field are used more or less interchangeablyherein. Also the term parameter is sometimes used to denote the same concept.

[0105] Parameters / IEs / fields used in ASN.1 code as well as in procedural text in the 3GPPRRC specification for 5G / NR, i.e.3GPP TS 38.331 version 17.3.0, are often named with a suffix indicating the number of the release of the 3GPP standard the parameter / IE / field was introduced in (e.g. the suffix “-r17” for a parameter / IE / field introduced in release 17 of the 3GPP standard). Parameters / IEs / fields following this naming convention are typically referred to both with and without the suffix, where the name including the suffix is used in the ASN.1 code (and thus defines the formal name from the ASN.1 compiler’s perspective), while the name without the suffix is used in running text, e.g. in field descriptions and procedural text. Relevant examples in the context of this document include the parameters / IEs / fields t1-Threshold-r17 / t1-Threshold and t-Service- r17 / t-Service. Both name variants may occur herein for various parameters / IEs / fields.

[0106] The term “NTA” may also be written as “N_TA”.

[0107] Particular embodiments find their motivation in an analysis of the sources of timingerrors, or timing imperfections, that contribute to the total timing error the NTAhas been adjusted to compensate for.

[0108] The main source of the timing error, Terror, the NTA has been adjusted to compensatefor are the following.

[0109] The first source is the UE’s movements, in particular its movements between twoposition estimate updates, i.e. typically between two GNSS measurements. Such movements lead to an error in the UE’s estimation of its own position which in turn leads to an error in the UE’s calculation of ^^TUAE,adj, which hereafter is denoted as Terror_UE_position. The network can compensate for this by adjusting NTA accordingly.P110778WO02 PCT APPLICATION 32 of 74

[0110] The second source is that ephemeris and common TA parameters broadcast in SIB19(in NR NTN) or in SIB32 (in IoT NTN) are fully correct only at the epoch time. They can be used to extrapolate the satellite’s movement in its orbit and to calculate the common TA at a later (or earlier) time, but these calculations will inevitably result in an error in the estimation of the satellite’s position, and thus in turn an error in the distance and propagation delay between the UE and the satellite, as well as an error in the calculated common TA, and these errors typically grow the further away (i.e. the longer time) from the epoch time the UE uses the ephemeris parameters to calculate the satellite’s position and the common TA parameters to calculate the common TA. The sum of the timing error due to incorrect estimation of the satellite’s position and the error due to imperfect common TA is herein denoted as Terror_satellite_position_and_common_TA (where Terror_satellite_position_and_common_TA= Terror_satellite_position+ Terror_common_TA). The network can compensate for this too by adjusting NTA accordingly.

[0111] Combining the two above error contributions from the two main sources, the result is:Terror = Terror_UE_position + Terror_satellite_position_and_common_TA.

[0112] A more accurate representation may be Terror ^ Terror_UE_position +Terror_satellite_position_and_common_TA, because there may be other minor error sources contributing to the total timing error, Terror, e.g. clock drifts, radio wave propagation speed variations due to changes of the average refraction index in the atmosphere between the UE and the satellite. However, for simplicity, and for the purpose of the following description, it is assumed that Terror= Terror_UE_position+ Terror_satellite_position_and_common_TA, and this is assumed to be accurate enough in the context of this description. The network thus uses NTA adjustments to compensate for Terror, where Terror = Terror_UE_position+ Terror_satellite_position_and_common_TA.

[0113] Out of these two main contributions to the total timing error, the UE can retroactivelycalculate the size of Terror_UE_position. The reason is that the UE knows both the newly acquired UE position estimate (e.g. obtained through a GNSS measurement) and the UE position estimate it was using up until that (e.g. based on a previous GNSS measurement). Knowing the change of the UE position that the UE uses in its calculation of ^^TUAEUE ,adjthe UE can calculate the change in ^^TA,adjthat is caused by the UE position update. An easier way for the UE to do this is to calculate the new ^^TUAE,adjvalue using the new UE position estimate and compare this with the old value of ^^TUAE,adjcalculated using the old (previous) UE position estimate. The difference between the new and the old ^^TUAE,adjvalue represents the part of Terror (before the UE acquired its new position estimate) that was caused by UE movements, i.e. it represents Terror_UE_position. Because the network has adjusted NTAto compensate for Terror, this means that the difference between the new and theP110778WO02 PCT APPLICATION 33 of 74 old ^^TUAE,adjvalue (which represents Terror_UE_position) represents the part of NTA that compensates for the timing error caused by UE movements. Because the timing error caused by UE movements has been eliminated by the UE’s acquisition of a fresh (accurate) position estimate (e.g. based on a fresh GNSS measurement), it is appropriate to remove the corresponding part of NTA.

[0114] For the further discussion, a clear definition of how Terror relates to the ideal receptiontiming and the actual reception timing of a UE transmission at the uplink time synchronization reference point (which typically is located at the gNB). Terror may be defined either as: Terror = Tideal_reception – Tactual_reception (definition alternative I) or as: Terror = Tactual_reception – Tideal_reception (definition alternative II) where Tideal_receptionis the ideal reception time and Tactual_receptionis the actual reception time.

[0115] For the further discussion the latter definition (definition alternative II) is assumed.Note that either one of the definitions may be used and the embodiments will work equally well with both, but the calculations will look different for the two cases, because the definition alternatives result in different sign (plus or minus) of Terror.

[0116] With the chosen definition (definition alternative II), a too late reception time (i.e. laterthan ideal arrival time) results in a Terror> 0. And from the TA formula it can be concluded that a too late arrival (i.e. a too late reception time) is compensated for by a NTA > 0. Thus, ideally, NTA = Terror. This also means that the sign (i.e. plus or minus) of Terror_UE_position is defined such that a Terror_UE_position that makes the UE’s transmission arrive too late at the uplink time synchronization reference point can be compensated for by a positive NTA (i.e. an NTA > 0). The same goes for Terror_satellite_position_and_common_TA.

[0117] This means that when Terror_UE_position is removed from Terror, because the UErecalculates ^^TUAE,adjbased on the new (accurate) UE position estimate, it is appropriate to remove Terror_UE_position from NTA, i.e. NTA_new = NTA_old - Terror_UE_position, where NTA_old is the NTA the UE was using before the UE position update and NTA_newis the NTAthe UE should use after the UE position update, i.e. after acquiring a new (accurate) UE position estimate, e.g. based on a new GNSS measurement. This in essence means the UE keeps its overall TA unchanged when fixing TA error by itself.

[0118] Thus, in conclusion, a particular solution to the problem of how the UE should treatNTA upon acquiring updated UE position information based on a new GNSS measurement is that upon acquiring a new (accurate) UE position estimate, preferably based on a new GNSSP110778WO02 PCT APPLICATION 34 of 74 measurement, the UE sets the new NTA, i.e. NTA_new, to NTA_new = NTA_old - Terror_UE_position (assuming that definition alternative II is used for Terror).

[0119] Some embodiments include configuration options. In some embodiments, the UE’streatment of NTA upon acquiring a new accurate UE position estimate, e.g. upon a new GNSS measurement, may be configurable.

[0120] To this end, the standard specifications may be extended to specify support forenabling the network to configure the UE’s treatment of NTAupon acquiring a new accurate UE position estimate, e.g. upon a new GNSS measurement, e.g. such that the network may choose to indicate one NTAtreatment out of two or more of the following alternative NTAtreatments (all of which assume definition alternative II for Terror): ^Set NTA_new = NTA_old – Terror_UE_position.^ Set NTA_new = 0.^ Set NTA_new = NTA_old, i.e. leave NTA unchanged.^ Set NTA_new = NTA_old – K x Terror_UE_position. In this formula, K is a value in the range 0 ≤ K≤ 1. The value of K may be specified or may be included in the configuration, optionally with a specified default value to apply in case the K value is absent in the configuration. ^Notify the network of the acquisition of the new accurate UE position estimate and useNTA_new= NTA_old– Terror_UE_positionuntil the network provides a different configuration alternative (or a Timing Advance Command MAC CE or an Absolute Timing Advance Command MAC CE is received). The notification may be sent to the network using RRC signaling (e.g., a new RRC message or an existing RRC message, e.g. a UEAssistanceInformation RRC message, extended with the new notification), MAC signaling (e.g. a new MAC CE) or UCI signaling. ^Notify the network of the acquisition of the new accurate UE position estimate and useNTA_new= 0 until the network provides a different configuration alternative (or a Timing Advance Command MAC CE or an Absolute Timing Advance Command MAC CE is received). The notification may be sent to the network using RRC signaling (e.g., a new RRC message or an existing RRC message, e.g. a UEAssistanceInformation RRC message, extended with the new notification), MAC signaling (e.g., a new MAC CE) or UCI signaling. ^Notify the network of the acquisition of the new accurate UE position estimate and leaveNTAunchanged until the network provides a different configuration alternative (or a Timing Advance Command MAC CE or an Absolute Timing Advance Command MACP110778WO02 PCT APPLICATION 35 of 74 CE is received). The notification may be sent to the network using RRC signaling (e.g., a new RRC message or an existing RRC message, e.g. a UEAssistanceInformation RRC message, extended with the new notification), MAC signaling (e.g., a new MAC CE) or UCI signaling. ^Notify the network of the acquisition of the new accurate UE position estimate and useNTA_new = NTA_old – K x Terror_UE_position until the network provides a different configuration alternative (or a Timing Advance Command MAC CE or an Absolute Timing Advance Command MAC CE is received). In this formula, K is a value in the range 0 ≤ K ≤ 1. The value of K may be specified or may be included in the configuration, optionally with a specified default value to apply in case the K value is absent in the configuration. The notification may be sent to the network using RRC signaling (e.g., a new RRC message or an existing RRC message, e.g. a UEAssistanceInformation RRC message, extended with the new notification), MAC signaling (e.g., a new MAC CE) or UCI signaling.

[0121] Irrespective of the chosen configured alternative, the UE should follow subsequentlyreceived TA adjustment instructions from the network, e.g. Timing Advance Command MAC CEs or Absolute Timing Advance Command MAC CEs.

[0122] The configuration may be signaled to the UE using common signaling, e.g. in thebroadcast system information, or using dedicated signaling, e.g. dedicated RRC signaling or dedicated MAC signaling or dedicated DCI signaling on the PDCCH. A further signaling option may be that both common signaling and dedicated signaling may be used, wherein the configuration provided using dedicated signaling overrides the configuration provided using common signaling.

[0123] Particular embodiments include application of reductions of the satellite position errorand the common TA error based on obtained newer ephemeris and common TA parameters. With some adaptations to account for the circumstances being different than when the UE updates its own location, the same principle as described above may be applied when the UE obtains new ephemeris and common TA parameters (and consequently recalculates ^^TcAom,amdjon).

[0124] A complication when applying the solution principles in this case is that the ephemerisand common TA parameters are fully correct only at the epoch time. Thus, unless the UE luckily obtains the new ephemeris and common TA parameters right at (or very close to) their associated epoch time, both the old (previous) and the new ephemeris and common TA parameters will result in an imperfect calculation of ^^TcoAm,amdjon, i.e. a non-zero Terror_satellite_position_and_common_TA. The UE can thus not assume that the difference between the ^^TcoAm,amdjonvalue calculated using the new ephemerisP110778WO02 PCT APPLICATION 36 of 74 and common TA parameters and the ^^TcAom,amdjonvalue calculated using the old (previous) ephemeris and common TA parameters is equal to the Terror_satellite_position_and_common_TA before the UE obtained the new ephemeris and common TA parameters, and thus the UE cannot assume that subtracting the difference between the ^^TcAom,amdjonvalue calculated using the new ephemeris and common TA parameters and the ^^TcAom,amcalculated using the old (previous) ephemeris and common TAparameters from the old will result in a good new NTA value (i.e. the principle used for the case when the UE position estimate is updated).

[0125] To overcome this complication, the UE may complement the acquisition of the newephemeris and common TA parameters with an update of the UE position estimate, e.g. by performing a new GNSS measurement. Using the new UE position estimate, the UE can calculate the Terror_UE_positionvalue before the application of the updated UE position estimate and then calculate the Terror_satellite_position_and_common_TA before the UE obtained the new ephemeris and common TA parameters as Terror_satellite_position_and_common_TA= Terror- Terror_UE_position. Using the Terror_satellite_position_and_common_TA calculated in this way, the UE may modify the NTA accordingly, i.e. set NTA_new= NTA_old- Terror_satellite_position_and_common_TA.

[0126] If the UE, as described above, obtains new ephemeris and common TA parameters anda new (accurate) UE position estimate closely together in time, the UE may use both Terror_UE_position and Terror_satellite_position_and_common_TAin the calculation of the new NTA, e.g. NTA_new= NTA_old- Terror_UE_position – Terror_satellite_position_and_common_TA. Note that with perfect calculations of Terror_UE_positionand Terror_satellite_position_and_common_TA(and neglecting other minor contributions to the total timing error), this should result in a new NTA = 0, i.e., NTA_new = NTA_old - Terror_UE_position – Terror_satellite_position_and_common_TA= 0. More realistically, however, is to assume some error in the calculations of Terror_UE_position and Terror_satellite_position_and_common_TA, and also some minor contributions to the timing error from other sources, which implies that calculating the new NTAby subtracting Terror_UE_position and Terror_satellite_position_and_common_TA from the old NTA will result in a new NTA close to zero rather than exactly zero, e.g. NTA_new = NTA_old - Terror_UE_position – Terror_satellite_position_and_common_TA^ 0.

[0127] Optionally, if the new ephemeris and common TA parameters are acceptably fresh,e.g. if the difference between the current time and the epoch time associated with the new ephemeris and common TA parameters (e.g., the elapsed time since the epoch time associated with the new ephemeris and common TA parameters) is smaller than a certain threshold (wherein the threshold may be configured by the network, specified in a standard, or determined by the UE implementation), the UE may regard the new ephemeris and common TA parameters as correctP110778WO02 PCT APPLICATION 37 of 74 and thus assume that the Terror_satellite_position_and_common_TA before the new ephemeris and common TA parameters were obtained and applied is equal to the difference between the ^^TcoAm,amdjonvalue calculated using the new ephemeris and common TA parameters and the ^^TcoAm,amdjonvalue calculated using the old (previous) ephemeris and common TA parameters, and set NTA_new = NTA_old- Terror_satellite_position_and_common_TA.

[0128] As another optional extension or variation of the above method, if the newly obtainedephemeris and common TA parameters have an associated epoch time that is newer (i.e., later in time) than the epoch time associated with the old (previous) ephemeris and common TA parameters (and the difference between the current time and the new epoch time is smaller than the difference between the current time and the old epoch time), the UE assumes that the ^^ common TA,adjvalue calculated using the new ephemeris and common TA parameters is closer to the correct value (i.e., with a smaller error) than the ^^TcAom,amdjonvalue calculated using the old (previous) ephemeris and common TA parameters) and modifies NTAto compensate for the difference between the ^^commonvalue calculated using the new ephemeris and common TA p common TA,adjarameters and the ^^TA,adjvalue calculated using the old (previous) ephemeris and common TA parameters. That is, in essence, the UE regards the ^^TcoAm,amdjonvalue calculated using the new ephemeris and common TA parameters as and thus assumes that the difference commonbetween the ^^TA,adjvalue calculated using the new ephemeris and common TA parameters and the ^^Tccalculated using the old (previous) ephemeris and common TA parameters isequal to Terror_satellite_position_and_common_TA. Based on this assumption, the UE sets NTA_new = NTA_old – Terror_satellite_positoin_and_common_TA(in line with the principle to set NTA_new= NTA_old– Terror_UE_positionwhen the UE position is updated). As an option, a UE may be restricted to do this only if the elapsed time since the epoch time associated with the new ephemeris and common TA parameters is smaller than a certain threshold (where the threshold may be configured by the network, specified in a standard or determined by the UE implementation).

[0129] As yet another option, if the newly obtained ephemeris and common TA parametershave an associated epoch time that is newer (i.e. later in time) than the epoch time associated with the old (previous) ephemeris and common TA parameters (and the difference between the current time and the new epoch time is smaller than the difference between the current time and the old epoch time), the UE may assume that a Terror_satellite_position_and_common_TA value calculated using the difference between the ^^TcAom,amdjonvalue calculated using the new ephemeris and common TA parameters and the ^^Tccalculated using the old (previous) ephemeris and common TAP110778WO02 PCT APPLICATION 38 of 74 parameters represents a part of the actual Terror_satellite_position_and_common_TA value before the acquisition and application of the new ephemeris and common TA parameters, e.g. denoted as Terror_satellite_position_and_common_TA_partial., and the UE may further assume that Terror_satellite_position_and_common_TA_partial approximately satisfies the following equation: Terror_satellite_position_and_common_TA_partial= Terror_satellite_position_and_common_TA_actual× (Dcurrent_time_vs_old_epoch_time – Dcurrent_time_vs_new_epoch_time) / Dcurrent_time_vs_old_epoch_time, where Dcurrent_time_vs_old_epoch_timeis the difference between the current time and the epoch time associated with the old ephemeris and common TA parameters, Dcurrent_time_vs_new_epoch_time is the difference between the current time and the epoch time associated with the new ephemeris and common TA parameters, and Terror_satellite_position_and_common_TA_actual is the Terror_satellite_position_and_common_TA_actualbefore acquisition and application of the new ephemeris and common TA parameters. From this it can be deduced that (approximately) Terror_satellite_position_and_common_TA_actual= Terror_satellite_position_and_common_TA_partial× Dcurrent_time_vs_old_epoch_time / (Dcurrent_time_vs_old_epoch_time – Dcurrent_time_vs_new_epoch_time).

[0130] Accordingly, the UE may modify the NTA so that NTA_new = NTA_old -Terror_satellite_position_and_common_TA_actual (where Terror_satellite_position_and_common_TA_actual is calculated in accordance with the above formula).

[0131] Some embodiments include alternative methods for calculating the new NTA. In oneembodiment, NTA_old is the NTA that the UE applied upon receiving the last Timing Advance Command MAC CE before the UE updates its GNSS location and / or obtains new ephemeris and common TA parameters broadcast in SIB19 (in NR NTN) or in SIB32 (in IoT NTN). When the UE updates ^^TUAE,adjand / or ^^TcAom,amdjon, it sets NTA_newsuch that the overall applied TAnewis the same as the TAold that the UE applied after receiving the said last Timing Advance Command MAC CE. When calculating TAold, the UE calculates ^^TUAE,adj,oldand / or ^^TcAom,amdjo,noldbased on the estimated UE position and the estimated position of thethe last Timing Advance Command MAC CE or at the time it sends the last UL transmission before receiving said last Timing Advance Command MAC CE.

[0132] In another embodiment, when the UE updates ^^TUAE,adjand / or ^^TcAom,amdjonupon updating its own location (i.e., the UE position estimate) based on a GNSS measurement and / or obtaining new ephemeris and common TA parameters broadcast in SIB19 (in NR NTN) or in SIB32 (in IoT NTN), it sets NTA_new such that the overall applied TAnew is the same as the TAold that the UE applied upon receiving a Timing Advance Command MAC CE since the last time the UE updated ^^TUAE,adjand / or ^^TcAom,amdjonupon updating its own location (i.e., the UE position estimate) based on aP110778WO02 PCT APPLICATION 39 of 74 GNSS measurement and / or obtaining new ephemeris and common TA parameters broadcast in SIB19 (in NR NTN) or in SIB32 (in IoT NTN). The UE calculates TAold similar as described in the above embodiment. Upon which Timing Advance Command MAC CE the UE shall calculate TAold may be configured by the network or up to UE implementation.

[0133] In yet another embodiment, when the UE updates ^^TUAE,adjand / or ^^TcAom,amdjonupon updating its own location (i.e., the UE position estimate) based on a GNSS and / or obtaining new ephemeris and common TA parameters broadcast in SIB19or in SIB32 (in IoT NTN), it sets NTA_new such that the overall applied TAnew is the same as the TAold that the UE applied at any time (denoted Told) since the last time the UE updated ^^TUAE,adjand / or ^^TcoAm,amdjonupon updating its own location (i.e., the UE position estimate) based on a GNSS measurement and / or obtaining new ephemeris and common TA parameters broadcast in SIB19 (in NR NTN) or in SIB32 (in IoT NTN. When calculating TAold, the UE calculates ^^TUAE,adj,oldand / or ^^TcoAm,amdjo,noldbased on the estimated UE position and the estimated position of the satellite at Told.

[0134] In yet another embodiment, the UE relies on the network to do a close to perfect jobwhen the network adjusts the UE’s TA, e.g. using a Timing Advance Command MAC CE or an Absolute Timing Advance Command MAC CE. Based on this assumption, upon acquiring a new UE position estimate, e.g. based on a GNSS measurement, and the consequent recalculation of ^^TUAE,adj, the UE adapts NTA so that the TA remains unchanged (i.e., is the same as it was before the UE acquired its new UE position estimate, e.g. before the GNSS measurement).

[0135] Optionally, the same principle can be applied when the UE obtains new ephemeris andcommon TA parameters from the broadcast SIB19 (in NR NTN) or SIB32 (in IoT NTN). That is, upon acquiring new ephemeris and common TA parameters and the consequent recalculation of ^^TcoAm,amdjon, the UE adapts NTAso that the TA remains unchanged (i.e., is the same as it was before the UE obtained new ephemeris and common TA parameters).

[0136] As one option, the UE may selectively use this method only if the elapsed time sincethe UE received the latest TA adjustment instruction (e.g., a Timing Advance Command MAC CE or an Absolute Timing Advance Command MAC CE) from the network is shorter than a certain threshold, wherein the threshold may be configured by the network, specified in a standard, or determined by the UE implementation

[0137] Which of the above options the UE should use may be configured by the network usingcommon and / or dedicated control signaling or it may be predefined in the specification.

[0138] Some embodiments include assistance information for error determination. As statedearlier, the ephemeris and common TA parameters broadcast in SIB19 (in NR NTN) or in SIB32P110778WO02 PCT APPLICATION 40 of 74 (in IoT NTN) are only fully correct at the epoch time. This generates an error in the estimation / calculation of the distance and propagation delay between UE and satellite which progressively grows as the current time moves away from the epoch time. The nature of this error may to some extent be deterministic based on the satellite characteristic, atmospheric conditions, sun radiation, and other space dynamics related parameters, and may be general for all UEs in an NTN cell. Furthermore, the network is likely to have access to more precise ephemeris data than what is broadcast in the system information, meaning that the network can predict in advance some of the age-dependent error in the orbit extrapolation based the broadcast ephemeris parameters by comparing the orbit prediction based on the broadcast ephemeris parameters with the orbit prediction based on the network’s more precise ephemeris data. Thus, in deterministic (or semi- deterministic) conditions, the network may be able to estimate the error function, or error functions, corresponding to the components Terror_satellite_position and Terror_common_TA and how these error components change over time. The network may transmit this error function, or these error functions, to the UE to assist the UE in estimating the timing error denoted as Terror_satellite_position_and_common_TA in an accurate manner and secure a mutual understanding of the configuration of NTA after the acquisition of a new GNSS position fix or new satellite ephemeris and common TA parameters.

[0139] The error function configuration may be signaled to the UE using common signaling,e.g. in the broadcast system information, or using dedicated signaling, e.g. dedicated RRC signaling or dedicated MAC signaling or dedicated DCI signaling on the PDCCH. In an alternative, a series of configurations (e.g., error functions), associated with other space dynamic variables such as elapsed time since the epoch time or elevation angle, may be transmitted to the UE in a configuration message and may be individually activated through any of the previously mentioned dedicated signaling mechanisms.

[0140] The embodiments described have simplified the expression of the UE’s transmissiontiming error by combining the two major contribution factors. In this way, the timing error can be described as Terror^ Terror_UE_position+ Terror_satellite_position_and_common_TA. In addition to UE specific variables such as UE movement speed and direction, the timing error may be affected in a more systematic manner by inherent (design) inaccuracies in the selected positioning system. For example, GPS (Global Positioning System) has an uncertainty range between 3 and 10 meters for a typical smartphone implementation. This systematic timing drift, which is part of Terror_UE_position, may be a combination of system level and UE-specific factors. The former may be handled at an implementation level because both the network and the UE may be aware of the positioning system used by the UE in an NTN cell. Otherwise, and also in the latter case, this error may beP110778WO02 PCT APPLICATION 41 of 74 characterized by a Radio Access Capability that informs the network of the expected uncertainty range and facilitates the mutual understanding of the configuration of NTA after the acquisition of a new GNSS position fix or new satellite ephemeris and common TA parameters.

[0141] FIGURE 3 shows an example of a communication system 100 in accordance withsome embodiments. In the example, the communication system 100 includes a telecommunication network 102 that includes an access network 104, such as a radio access network (RAN), and a core network 106, which includes one or more core network nodes 108. The access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may be generally referred to as network nodes 110), or any other similar 3rdGeneration Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 112a, 112b, 112c, and 112d (one or more of which may be generally referred to as UEs 112) to the core network 106 over one or more wireless connections.

[0142] Example wireless communications over a wireless connection include transmittingand / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0143] The UEs 112 may be any of a wide variety of communication devices, includingwireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 110 and other communication devices. Similarly, the network nodes 110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 112 and / or with other network nodes or equipment in the telecommunication network 102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 102.

[0144] In the depicted example, the core network 106 connects the network nodes 110 to oneor more hosts, such as host 116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 106 includes one more core network nodes (e.g., core network node 108) that are structured with hardware and software components. Features of these components may beP110778WO02 PCT APPLICATION 42 of 74 substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0145] The host 116 may be under the ownership or control of a service provider other thanan operator or provider of the access network 104 and / or the telecommunication network 102, and may be operated by the service provider or on behalf of the service provider. The host 116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0146] As a whole, the communication system 100 of FIGURE 3 enables connectivitybetween the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0147] In some examples, the telecommunication network 102 is a cellular network thatimplements 3GPP standardized features. Accordingly, the telecommunications network 102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 102. For example, the telecommunications network 102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive IoT services to yet further UEs.P110778WO02 PCT APPLICATION 43 of 74

[0148] In some examples, the UEs 112 are configured to transmit and / or receive informationwithout direct human interaction. For instance, a UE may be designed to transmit information to the access network 104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 104. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio – Dual Connectivity (EN-DC).

[0149] In the example, the hub 114 communicates with the access network 104 to facilitateindirect communication between one or more UEs (e.g., UE 112c and / or 112d) and network nodes (e.g., network node 110b). In some examples, the hub 114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 114 may be a broadband router enabling access to the core network 106 for the UEs. As another example, the hub 114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 110, or by executable code, script, process, or other instructions in the hub 114. As another example, the hub 114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 114 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy IoT devices.

[0150] The hub 114 may have a constant / persistent or intermittent connection to the networknode 110b. The hub 114 may also allow for a different communication scheme and / or schedule between the hub 114 and UEs (e.g., UE 112c and / or 112d), and between the hub 114 and the core network 106. In other examples, the hub 114 is connected to the core network 106 and / or one or more UEs via a wired connection. Moreover, the hub 114 may be configured to connect to an M2M service provider over the access network 104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 110 while still connected via the hub 114 via a wired or wireless connection. In some embodiments, the hub 114 may be a dedicated hub – that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 110b. In other embodiments, the hub 114 may be a non-P110778WO02 PCT APPLICATION 44 of 74 dedicated hub – that is, a device which is capable of operating to route communications between the UEs and network node 110b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0151] FIGURE 4 shows a UE 200 in accordance with some embodiments. As used herein, aUE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0152] A UE may support device-to-device (D2D) communication, for example byimplementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to- everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0153] The UE 200 includes processing circuitry 202 that is operatively coupled via a bus 204to an input / output interface 206, a power source 208, a memory 210, a communication interface 212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIGURE 4. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0154] The processing circuitry 202 is configured to process instructions and data and may beconfigured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 210. The processing circuitry 202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field- programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.);P110778WO02 PCT APPLICATION 45 of 74 programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 202 may include multiple central processing units (CPUs).

[0155] In the example, the input / output interface 206 may be configured to provide aninterface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0156] In some embodiments, the power source 208 is structured as a battery or battery pack.Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 208 may further include power circuitry for delivering power from the power source 208 itself, and / or an external power source, to the various parts of the UE 200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 208 to make the power suitable for the respective components of the UE 200 to which power is supplied.

[0157] The memory 210 may be or be configured to include memory such as random accessmemory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 210 includes one or more application programs 214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 216. The memory 210 may store, for use by the UE 200, any of a variety of various operating systems or combinations of operating systems.P110778WO02 PCT APPLICATION 46 of 74

[0158] The memory 210 may be configured to include a number of physical drive units, suchas redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 210 may allow the UE 200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 210, which may be or comprise a device-readable storage medium.

[0159] The processing circuitry 202 may be configured to communicate with an accessnetwork or other network using the communication interface 212. The communication interface 212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 222. The communication interface 212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 218 and / or a receiver 220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 218 and receiver 220 may be coupled to one or more antennas (e.g., antenna 222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0160] In the illustrated embodiment, communication functions of the communicationinterface 212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short- range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission controlP110778WO02 PCT APPLICATION 47 of 74 protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0161] Regardless of the type of sensor, a UE may provide an output of data captured by itssensors, through its communication interface 212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0162] As another example, a UE comprises an actuator, a motor, or a switch, related to acommunication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0163] A UE, when in the form of an Internet of Things (IoT) device, may be a device for usein one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item- tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and / or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 200 shown in FIGURE 4.

[0164] As yet another specific example, in an IoT scenario, a UE may represent a machine orother device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this caseP110778WO02 PCT APPLICATION 48 of 74 be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0165] In practice, any number of UEs may be used together with respect to a single use case.For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0166] FIGURE 5 shows a network node 300 in accordance with some embodiments. As usedherein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)).

[0167] Base stations may be categorized based on the amount of coverage they provide (or,stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0168] Other examples of network nodes include multiple transmission point (multi-TRP) 5Gaccess nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes,P110778WO02 PCT APPLICATION 49 of 74 Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0169] The network node 300 includes a processing circuitry 302, a memory 304, acommunication interface 306, and a power source 308. The network node 300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 304 for different RATs) and some components may be reused (e.g., a same antenna 310 may be shared by different RATs). The network node 300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 300.

[0170] The processing circuitry 302 may comprise a combination of one or more of amicroprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 300 components, such as the memory 304, to provide network node 300 functionality.

[0171] In some embodiments, the processing circuitry 302 includes a system on a chip (SOC).In some embodiments, the processing circuitry 302 includes one or more of radio frequency (RF) transceiver circuitry 312 and baseband processing circuitry 314. In some embodiments, the radio frequency (RF) transceiver circuitry 312 and the baseband processing circuitry 314 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 312 and baseband processing circuitry 314 may be on the same chip or set of chips, boards, or units.

[0172] The memory 304 may comprise any form of volatile or non-volatile computer-readablememory including, without limitation, persistent storage, solid-state memory, remotely mountedP110778WO02 PCT APPLICATION 50 of 74 memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 302. The memory 304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 302 and utilized by the network node 300. The memory 304 may be used to store any calculations made by the processing circuitry 302 and / or any data received via the communication interface 306. In some embodiments, the processing circuitry 302 and memory 304 is integrated.

[0173] The communication interface 306 is used in wired or wireless communication ofsignaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 306 comprises port(s) / terminal(s) 316 to send and receive data, for example to and from a network over a wired connection. The communication interface 306 also includes radio front-end circuitry 318 that may be coupled to, or in certain embodiments a part of, the antenna 310. Radio front-end circuitry 318 comprises filters 320 and amplifiers 322. The radio front-end circuitry 318 may be connected to an antenna 310 and processing circuitry 302. The radio front-end circuitry may be configured to condition signals communicated between antenna 310 and processing circuitry 302. The radio front-end circuitry 318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 320 and / or amplifiers 322. The radio signal may then be transmitted via the antenna 310. Similarly, when receiving data, the antenna 310 may collect radio signals which are then converted into digital data by the radio front-end circuitry 318. The digital data may be passed to the processing circuitry 302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0174] In certain alternative embodiments, the network node 300 does not include separateradio front-end circuitry 318, instead, the processing circuitry 302 includes radio front-end circuitry and is connected to the antenna 310. Similarly, in some embodiments, all or some of the RF transceiver circuitry 312 is part of the communication interface 306. In still other embodiments, the communication interface 306 includes one or more ports or terminals 316, the radio front-end circuitry 318, and the RF transceiver circuitry 312, as part of a radio unit (not shown), and theP110778WO02 PCT APPLICATION 51 of 74 communication interface 306 communicates with the baseband processing circuitry 314, which is part of a digital unit (not shown).

[0175] The antenna 310 may include one or more antennas, or antenna arrays, configured tosend and / or receive wireless signals. The antenna 310 may be coupled to the radio front-end circuitry 318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 310 is separate from the network node 300 and connectable to the network node 300 through an interface or port.

[0176] The antenna 310, communication interface 306, and / or the processing circuitry 302may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 310, the communication interface 306, and / or the processing circuitry 302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0177] The power source 308 provides power to the various components of network node 300in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 300 with power for performing the functionality described herein. For example, the network node 300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 308. As a further example, the power source 308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0178] Embodiments of the network node 300 may include additional components beyondthose shown in FIGURE 5 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 300 may include user interface equipment to allow input of information into the network node 300 and to allow output of information from the network node 300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 300.P110778WO02 PCT APPLICATION 52 of 74

[0179] FIGURE 6 is a block diagram of a host 400, which may be an embodiment of the host116 of FIGURE 3, in accordance with various aspects described herein. As used herein, the host 400 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 400 may provide one or more services to one or more UEs.

[0180] The host 400 includes processing circuitry 402 that is operatively coupled via a bus404 to an input / output interface 406, a network interface 408, a power source 410, and a memory 412. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 10 and 3, such that the descriptions thereof are generally applicable to the corresponding components of host 400.

[0181] The memory 412 may include one or more computer programs including one or morehost application programs 414 and data 416, which may include user data, e.g., data generated by a UE for the host 400 or data generated by the host 400 for a UE. Embodiments of the host 400 may utilize only a subset or all of the components shown. The host application programs 414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 414 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 400 may select and / or indicate a different host for over-the-top services for a UE. The host application programs 414 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0182] FIGURE 7 is a block diagram illustrating a virtualization environment 500 in whichfunctions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or moreP110778WO02 PCT APPLICATION 53 of 74 virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized.

[0183] Applications 502 (which may alternatively be called software instances, virtualappliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0184] Hardware 504 includes processing circuitry, memory that stores software and / orinstructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 508a and 508b (one or more of which may be generally referred to as VMs 508), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 506 may present a virtual operating platform that appears like networking hardware to the VMs 508.

[0185] The VMs 508 comprise virtual processing, virtual memory, virtual networking orinterface and virtual storage, and may be run by a corresponding virtualization layer 506. Different embodiments of the instance of a virtual appliance 502 may be implemented on one or more of VMs 508, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0186] In the context of NFV, a VM 508 may be a software implementation of a physicalmachine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 508, and that part of hardware 504 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 508 on top of the hardware 504 and corresponds to the application 502.P110778WO02 PCT APPLICATION 54 of 74

[0187] Hardware 504 may be implemented in a standalone network node with generic orspecific components. Hardware 504 may implement some functions via virtualization. Alternatively, hardware 504 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 510, which, among others, oversees lifecycle management of applications 502. In some embodiments, hardware 504 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 512 which may alternatively be used for communication between hardware nodes and radio units.

[0188] FIGURE 8 shows a communication diagram of a host 602 communicating via anetwork node 604 with a UE 606 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 112a of FIGURE 3 and / or UE 200 of FIGURE 4), network node (such as network node 110a of FIGURE 3 and / or network node 300 of FIGURE 5), and host (such as host 116 of FIGURE 3 and / or host 400 of FIGURE 6) discussed in the preceding paragraphs will now be described with reference to FIGURE 8.

[0189] Like host 400, embodiments of host 602 include hardware, such as a communicationinterface, processing circuitry, and memory. The host 602 also includes software, which is stored in or accessible by the host 602 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 606 connecting via an over-the-top (OTT) connection 650 extending between the UE 606 and host 602. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 650.

[0190] The network node 604 includes hardware enabling it to communicate with the host602 and UE 606. The connection 660 may be direct or pass through a core network (like core network 106 of FIGURE 3) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0191] The UE 606 includes hardware and software, which is stored in or accessible by UE606 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to aP110778WO02 PCT APPLICATION 55 of 74 human or non-human user via UE 606 with the support of the host 602. In the host 602, an executing host application may communicate with the executing client application via the OTT connection 650 terminating at the UE 606 and host 602. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 650 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 650.

[0192] The OTT connection 650 may extend via a connection 660 between the host 602 andthe network node 604 and via a wireless connection 670 between the network node 604 and the UE 606 to provide the connection between the host 602 and the UE 606. The connection 660 and wireless connection 670, over which the OTT connection 650 may be provided, have been drawn abstractly to illustrate the communication between the host 602 and the UE 606 via the network node 604, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0193] As an example of transmitting data via the OTT connection 650, in step 608, the host602 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 606. In other embodiments, the user data is associated with a UE 606 that shares data with the host 602 without explicit human interaction. In step 610, the host 602 initiates a transmission carrying the user data towards the UE 606. The host 602 may initiate the transmission responsive to a request transmitted by the UE 606. The request may be caused by human interaction with the UE 606 or by operation of the client application executing on the UE 606. The transmission may pass via the network node 604, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 612, the network node 604 transmits to the UE 606 the user data that was carried in the transmission that the host 602 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 614, the UE 606 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 606 associated with the host application executed by the host 602.

[0194] In some examples, the UE 606 executes a client application which provides user datato the host 602. The user data may be provided in reaction or response to the data received from the host 602. Accordingly, in step 616, the UE 606 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE 606. Regardless of the specific manner in which the user data was provided, the UE 606 initiates, in step 618,P110778WO02 PCT APPLICATION 56 of 74 transmission of the user data towards the host 602 via the network node 604. In step 620, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 604 receives user data from the UE 606 and initiates transmission of the received user data towards the host 602. In step 622, the host 602 receives the user data carried in the transmission initiated by the UE 606.

[0195] One or more of the various embodiments improve the performance of OTT servicesprovided to the UE 606 using the OTT connection 650, in which the wireless connection 670 forms the last segment. More precisely, the teachings of these embodiments may improve the data rate and latency and thereby provide benefits such as reduced user waiting time, better responsiveness, and better QoE.

[0196] In an example scenario, factory status information may be collected and analyzed bythe host 602. As another example, the host 602 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 602 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 602 may store surveillance video uploaded by a UE. As another example, the host 602 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 602 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and / or transmitting data.

[0197] In some examples, a measurement procedure may be provided for the purpose ofmonitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 650 between the host 602 and UE 606, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 602 and / or UE 606. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 650 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 650 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 604. Such procedures and functionalities may be known and practiced in the art. In certainP110778WO02 PCT APPLICATION 57 of 74 embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 602. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 650 while monitoring propagation times, errors, etc.

[0198] FIGURE 9 is a flowchart illustrating an example method 900 in a wireless device,according to certain embodiments. In particular embodiments, one or more steps of FIGURE 9 may be performed by UE 200 described with respect to FIGURE 4. The wireless device is operable to modify a timing advance (TA) value. The TA value is based at least in part on a position estimate of the wireless device and a timing adjustment value. The wireless device is operating in a non- terrestrial network.

[0199] The method begins at step 912, where the wireless device (e.g., UE 200) obtains a firstwireless device position estimate used for calculating a TA value. For example, the wireless device may obtain global navigation satellite system (GNSS) position estimate. In particular embodiments, the wireless device obtains its position estimate according to any of the embodiments and examples described herein.

[0200] At step 914, the wireless device receives a timing advance command from a networknode. The timing advance command comprises an indication of the timing adjustment value (e.g., NTAdescribed above).

[0201] At step 916, the wireless device obtains a second wireless device position estimateused for calculating the TA value. For example, the wireless device may have changed positions since obtaining the first position estimate. Because the timing adjustment value is affected by the position of the wireless device, it is beneficial if the wireless device can correct for the change in position.

[0202] At step 918, the wireless device may obtain a satellite position estimate used forcalculating a TA value. For example, the wireless device may estimate a satellite position based on ephemeris data as described above. An error associated with the satellite position estimate may increase as the ephemeris data ages. By obtaining updated ephemeris data, the wireless device may update its estimate of the satellite position. Because the timing adjustment value is affected by the position of the satellite, it is beneficial if the wireless device can correct for the change in position.

[0203] At step 920, the wireless device updates the timing adjustment value based on thesecond wireless device position estimate to remove a value corresponding to a difference between the first wireless device position estimate and the second wireless device position estimate from the timing adjustment value. In some embodiments, the wireless device may also update the timing adjustment value further based on the satellite position estimate.P110778WO02 PCT APPLICATION 58 of 74

[0204] In particular embodiments, the wireless device may update the timing adjustment valueaccording to any of the embodiments and examples described herein.

[0001] At step 922, the wireless device calculates a TA value for uplink transmission usingthe updated timing adjustment value. In particular embodiments, the TA value is represented bythe formula ^^^^ = (^^TA + ^^TA-offset + ^^ commonTA,adj + ^^ UETA,adj ) × ^^c , wherein ^^TA−offset is aconfigurablec Uis a wireless device specificvalue a is the timing adjustment valuereceived from the node; and ^^cis a basic time first wireless device position estimate and the second wireless device position estimate are used for calculating the ^^TUAE,adjterm in the TA formula. The difference between the first wireless device position estimate and the second wireless device position estimate is represented as Terror_UE_position. The updated timing adjustment value is represented as ^^TA_new= NTA_old - Terror_UE_position.

[0002] At step 924, the wireless device transmits an uplink transmission using the calculatedTA value.

[0003] At step 926, the wireless device may transmit an indication to the network node of theupdated timing adjustment value.

[0004] Modifications, additions, or omissions may be made to method 900 of FIGURE 9.Additionally, one or more steps in the method of FIGURE 9 may be performed in parallel or in any suitable order. For example, optional step 926 may be performed at any time after updating the timing adjustment value.

[0005] FIGURE 10 is a flowchart illustrating another example method 1000 in a wirelessdevice, according to certain embodiments. In particular embodiments, one or more steps of FIGURE 10 may be performed by UE 200 described with respect to FIGURE 4. The wireless device is operable to modify a TA value. The TA value is based at least in part on a position estimate of the wireless device and a timing adjustment value. The wireless device is operating in a non-terrestrial network.

[0006] The method begins at step 1012, where the wireless device (e.g., UE 200) obtains afirst satellite position estimate used for calculating a TA value. For example, the wireless device may obtain the first satellite position estimate based on ephemeris data, as described above. In particular embodiments, the wireless device obtains the satellite position estimate according to any of the embodiments and examples described herein.P110778WO02 PCT APPLICATION 59 of 74

[0007] At step 1014, the wireless device receives a timing advance command from a networknode. The timing advance command comprises an indication of the timing adjustment value (e.g., NTA described above).

[0008] At step 1016, the wireless device obtains a second satellite position estimate used forcalculating the TA value. For example, the wireless device may estimate a satellite position based on ephemeris data as described above. An error associated with the satellite position estimate may increase as the ephemeris data ages. By obtaining updated ephemeris data, the wireless device may update its estimate of the satellite position. Because the timing adjustment value is affected by the position of the satellite, it is beneficial if the wireless device can correct for the change in position.

[0009] At step 1018, the wireless device may obtain a wireless device position estimate usedfor calculating a TA value. For example, the wireless device may obtain GNSS position estimate. Because the timing adjustment value is affected by the position of the wireless device, it is beneficial if the wireless device can correct for the change in position.

[0010] At step 1020, the wireless device updates the timing adjustment value based on thesecond satellite position estimate to remove a value corresponding to a difference between the first satellite position estimate and the second satellite position estimate from the timing adjustment value. In some embodiments, updating the timing adjustment value is further based on the wireless device position estimate.

[0011] In particular embodiments, the wireless device may update the timing adjustment valueaccording to any of the embodiments and examples described herein.

[0012] At step 1022, the wireless device calculates a TA value for uplink transmission usingthe updated timing adjustment value.

[0013] In particular embodiments, the TA value is represented by the formula ^^^^ =(^^TA + ^^TA-offset + ^^ commonTA,adj + ^^ UETA,adj ) × ^^c , wherein ^^TA−offset is a configurable offset,^^TcAom,admjonis a common timing advance, ^^TUAE,adjis a wireless device specific value covering thetime of a satellite service link, ^^TAis the timing adjustment value received from the network node; and ^^cis a basic time unit. The first satellite position estimate and the second satellite position estimate are used for calculating the ^^TcAom,admjonterm in the TA formula. The difference between the first satellite position estimatesatellite position estimate is represented as Terror_UE_position_and_common_TA. The updated timing adjustment value is represented as ^^TA_new= NTA_old - Terror_UE_position_and_common_TA.

[0014] At step 1024, the wireless device transmits an uplink transmission using the calculatedTA value.P110778WO02 PCT APPLICATION 60 of 74

[0015] At step 1026, the wireless device may transmit an indication to the network node ofthe updated timing adjustment value.

[0016] Modifications, additions, or omissions may be made to method 1000 of FIGURE 10.Additionally, one or more steps in the method of FIGURE 10 may be performed in parallel or in any suitable order. For example, optional step 1026 may be performed at any time after updating the timing adjustment value.

[0017] FIGURE 11 is a flowchart illustrating an example method 1100 in a wirelesscommunication system, according to certain embodiments. In particular embodiments, one or more steps of FIGURE 11 may be performed by UE 200 described with respect to FIGURE 4 and network node 300 described with respect to FIGURE 5. The UE and network node may be operating in a non-terrestrial network.

[0018] The method begins at step 1112, where the network node (e.g., network node 300)transmits, to the wireless device, a timing advance command comprising an indication of a timing adjustment value (e.g., NTA described above).

[0019] At step 1114, the wireless device updates the timing adjustment value received fromthe network node. Updating the timing adjustment value is based on the wireless device updating one or more of a wireless device position estimate or a satellite position estimate after receiving the timing adjustment value from the network node. In particular embodiments, the wireless device may update the timing adjustment value according to any of the embodiments and examples described herein.

[0020] At step 1116, the wireless device calculates a timing advance value for uplinktransmission using the updated timing adjustment value.

[0021] At step 118, the network node may receive, from the wireless device, an indicationthat the wireless device updated the timing adjustment value. The indication may indicate that the timing adjustment value changed and / or the indication may include the updated timing adjustment value.

[0022] At step 1120, the wireless device transmits, to the network node, an uplinktransmission using the calculated TA value.

[0023] At step 1122, the network node may transmit, to the wireless device, a timing advancecommand comprising an indication of an updated timing adjustment value. For example, based on the indication received in step 1118, the network node may determine to recalculate a timing adjustment value for the wireless device and send the updated timing adjustment value to the wireless device. The new timing adjustment value may override the value previously adjusted by the wireless device.P110778WO02 PCT APPLICATION 61 of 74

[0024] Modifications, additions, or omissions may be made to method 1100 of FIGURE 11.Additionally, one or more steps in the method of FIGURE 11 may be performed in parallel or in any suitable order.

[0025] Although the computing devices described herein (e.g., UEs, network nodes, hosts)may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0026] In certain embodiments, some or all of the functionality described herein may beprovided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.P110778WO02 PCT APPLICATION 62 of 74

[0027] The foregoing description sets forth numerous specific details. It is understood,however, that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

[0028] References in the specification to “one embodiment,” “an embodiment,” “an exampleembodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly described.

[0029] Although this disclosure has been described in terms of certain embodiments,alterations and permutations of the embodiments will be apparent to those skilled in the art. Accordingly, the above description of the embodiments does not constrain this disclosure. Other changes, substitutions, and alterations are possible without departing from the scope of this disclosure, as defined by the claims below.

[0030] Some example embodiments are described below.Group A Embodiments A method performed by a wireless device for modifying a timing advance (TA) valuerepresented by the formula ^^^^ = (^^ common UETA + ^^TA-offset + ^^TA,adj + ^^TA,adj ) × ^^c, the methodcomprising:− obtaining a first position estimate of the wireless device used for calculating the ^^TUAE,adjterm in the TA formula; − receiving a first timing advance command from a network node, the first timing advance comprising a NTA value; − obtaining a second position estimate of the wireless device used for calculating the ^^TUAE,adjterm in the TA formula; − adjusting the NTAvalue based on the second position estimate to remove the value corresponding to the eliminated timing error from NTA, NTA_new = NTA_old - Terror_UE_position; − calculating a TA value for uplink transmission using the adjusted NTA value; andP110778WO02 PCT APPLICATION 63 of 74 − transmitting an uplink transmission using the calculated TA value. The method of the previous embodiment, further comprising transmitting an indication to the network node of the adjusted NTA value. A method performed by a wireless device, the method comprising: any of the wireless device steps, features, or functions described above, either alone or in combination with other steps, features, or functions described above. The method of the previous embodiment, further comprising one or more additional wireless device steps, features or functions described above. The method of any of the previous embodiments, further comprising: providing user data; and forwarding the user data to a host computer via the transmission to the base station. Group B Embodiments A method performed by a base station, the method comprising: receiving an indication from a wireless device that the wireless device adjusted a NTA value. A method performed by a base station, the method comprising: any of the steps, features, or functions described above with respect to base station, either alone or in combination with other steps, features, or functions described above. The method of the previous embodiment, further comprising one or more additional base station steps, features or functions described above. The method of any of the previous embodiments, further comprising: obtaining user data; and forwarding the user data to a host computer or a wireless device. Group C EmbodimentsP110778WO02 PCT APPLICATION 64 of 74 A mobile terminal comprising: processing circuitry configured to perform any of the steps of any of the Group A embodiments; and power supply circuitry configured to supply power to the wireless device. A base station comprising: processing circuitry configured to perform any of the steps of any of the Group B embodiments; power supply circuitry configured to supply power to the wireless device. A user equipment (UE) comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of the Group A embodiments; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE. A communication system including a host computer comprising: processing circuitry configured to provide user data; and a communication interface configured to forward the user data to a cellular network for transmission to a user equipment (UE), wherein the cellular network comprises a base station having a radio interface and processing circuitry, the base station’s processing circuitry configured to perform any of the steps of any of the Group B embodiments. The communication system of the pervious embodiment further including the base station. The communication system of the previous 2 embodiments, further including the UE,P110778WO02 PCT APPLICATION 65 of 74 wherein the UE is configured to communicate with the base station. The communication system of the previous 3 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application, thereby providing the user data; and the UE comprises processing circuitry configured to execute a client application associated with the host application. A method implemented in a communication system including a host computer, a base station and a user equipment (UE), the method comprising: at the host computer, providing user data; and at the host computer, initiating a transmission carrying the user data to the UE via a cellular network comprising the base station, wherein the base station performs any of the steps of any of the Group B embodiments. The method of the previous embodiment, further comprising, at the base station, transmitting the user data. The method of the previous 2 embodiments, wherein the user data is provided at the host computer by executing a host application, the method further comprising, at the UE, executing a client application associated with the host application. A user equipment (UE) configured to communicate with a base station, the UE comprising a radio interface and processing circuitry configured to performs any of the previous 3 embodiments. A communication system including a host computer comprising: processing circuitry configured to provide user data; and a communication interface configured to forward user data to a cellular network for transmission to a user equipment (UE), wherein the UE comprises a radio interface and processing circuitry, the UE’s components configured to perform any of the steps of any of the Group A embodiments. The communication system of the previous embodiment, wherein the cellular networkP110778WO02 PCT APPLICATION 66 of 74 further includes a base station configured to communicate with the UE. The communication system of the previous 2 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application, thereby providing the user data; and the UE’s processing circuitry is configured to execute a client application associated with the host application. A method implemented in a communication system including a host computer, a base station and a user equipment (UE), the method comprising: at the host computer, providing user data; and at the host computer, initiating a transmission carrying the user data to the UE via a cellular network comprising the base station, wherein the UE performs any of the steps of any of the Group A embodiments. The method of the previous embodiment, further comprising at the UE, receiving the user data from the base station. A communication system including a host computer comprising: communication interface configured to receive user data originating from a transmission from a user equipment (UE) to a base station, wherein the UE comprises a radio interface and processing circuitry, the UE’s processing circuitry configured to perform any of the steps of any of the Group A embodiments. The communication system of the previous embodiment, further including the UE. The communication system of the previous 2 embodiments, further including the base station, wherein the base station comprises a radio interface configured to communicate with the UE and a communication interface configured to forward to the host computer the user data carried by a transmission from the UE to the base station. The communication system of the previous 3 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application; andP110778WO02 PCT APPLICATION 67 of 74 the UE’s processing circuitry is configured to execute a client application associated with the host application, thereby providing the user data. The communication system of the previous 4 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application, thereby providing request data; and the UE’s processing circuitry is configured to execute a client application associated with the host application, thereby providing the user data in response to the request data. A method implemented in a communication system including a host computer, a base station and a user equipment (UE), the method comprising: at the host computer, receiving user data transmitted to the base station from the UE, wherein the UE performs any of the steps of any of the Group A embodiments. The method of the previous embodiment, further comprising, at the UE, providing the user data to the base station. The method of the previous 2 embodiments, further comprising: at the UE, executing a client application, thereby providing the user data to be transmitted; and at the host computer, executing a host application associated with the client application. The method of the previous 3 embodiments, further comprising: at the UE, executing a client application; and at the UE, receiving input data to the client application, the input data being provided at the host computer by executing a host application associated with the client application, wherein the user data to be transmitted is provided by the client application in response to the input data. A communication system including a host computer comprising a communication interface configured to receive user data originating from a transmission from a user equipment (UE) to a base station, wherein the base station comprises a radio interface and processing circuitry, the base station’s processing circuitry configured to perform any of the steps of any of the Group B embodiments.P110778WO02 PCT APPLICATION 68 of 74 The communication system of the previous embodiment further including the base station. The communication system of the previous 2 embodiments, further including the UE, wherein the UE is configured to communicate with the base station. The communication system of the previous 3 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application; the UE is configured to execute a client application associated with the host application, thereby providing the user data to be received by the host computer. A method implemented in a communication system including a host computer, a base station and a user equipment (UE), the method comprising: at the host computer, receiving, from the base station, user data originating from a transmission which the base station has received from the UE, wherein the UE performs any of the steps of any of the Group A embodiments. The method of the previous embodiment, further comprising at the base station, receiving the user data from the UE. The method of the previous 2 embodiments, further comprising at the base station, initiating a transmission of the received user data to the host computer.

Claims

P110778WO02 PCT APPLICATION 69 of 74 CLAIMS:

1. A method performed by wireless device for modifying a timing advance (TA) value, wherein the TA value is based at least in part on a position estimate of the wireless device and a timing adjustment value, the method comprising: obtaining (912) a first wireless device position estimate used for calculating a TA value; receiving (914) a timing advance command from a network node, the timing advance command comprising an indication of the timing adjustment value; obtaining (916) a second wireless device position estimate used for calculating the TA value; updating (920) the timing adjustment value based on the second wireless device position estimate to remove a value corresponding to a difference between the first wireless device position estimate and the second wireless device position estimate from the timing adjustment value; calculating (922) a TA value for uplink transmission using the updated timing adjustment value; and transmitting (924) an uplink transmission using the calculated TA value.

2. The method of claim 1, further comprising obtaining (918) a satellite position estimate used for calculating a TA value, and wherein updating the timing adjustment value is further based on the satellite position estimate.

3. The method of any one of claims 1-2, further comprising transmitting (926) an indication to the network node of the updated timing adjustment value.

4. A method of any one or more of claims 1-3, wherein: the TA value is represented by the formula ^^^^ = (^^TA + ^^TA-offset + ^^TcoAm,admjon+ ^^UETA,adj ) × ^^c, wherein ^^TA-offset is a configurable offset,advance, is a wireless device specific value covering the round trip time of a satellite service link, ^^TAis the timing adjustment value received from the network node; and ^^cis a basic time unit; the first wireless device position estimate and the second wireless device position estimate are used for calculating the ^^TUAE,adjterm in the TA formula; the difference between the first wireless device position estimate and the second wirelessP110778WO02 PCT APPLICATION 70 of 74 device position estimate is represented as Terror_UE_position; and the updated timing adjustment value is represented as ^^TA_new= NTA_old- Terror_UE_position.

5. The method of any one of claims 1-4, wherein the wireless device is operating in a non-terrestrial network.

6. A wireless device (200) capable of modifying a timing advance (TA) value, the wireless device comprising processing circuitry (202) operable to: obtain a first wireless device position estimate used for calculating a TA value; receive a timing advance command from a network node, the timing advance command comprising an indication of a timing adjustment value; obtain a second wireless device position estimate used for calculating the TA value; update the timing adjustment value based on the second wireless device position estimate to remove a value corresponding to a difference between the first wireless device position estimate and the second wireless device position estimate from the timing adjustment value; calculate a TA value for uplink transmission using the updated timing adjustment value; and transmit an uplink transmission using the calculated TA value.

7. The wireless device of claim 6, the processing circuitry further operable to obtain a satellite position estimate used for calculating a TA value, and , and wherein the processing circuitry is operable to update the timing adjustment value further based on the satellite position estimate.

8. The wireless device of any one of claims 6-7, the processing circuitry further operable to transmit an indication to the network node of the updated timing adjustment value.

9. A wireless device of any one or more of claims 6-8, wherein: the TA value is represented by the formula ^^^^ = (^^TA + ^^TA-offset + ^^TcoAm,admjon+ ^^UETA,adj ) × ^^c, wherein ^^TA-offset is a configurableadvance, ^^TUAE,adjis a wireless device specific value covering the round trip time of a satellite service link, ^^TAis the timing adjustment value received from the network node; and ^^cis a basic time unit; the first wireless device position estimate and the second wireless device positionP110778WO02 PCT APPLICATION 71 of 74 estimate are used for calculating the ^^TUAE,adjterm in the TA formula; the difference between the device position estimate and the second wireless device position estimate is Terror_UE_position; and the updated timing adjustment value is represented as ^^TA_new= NTA_old- Terror_UE_position.

10. The wireless device of any one of claims 6-9, wherein the wireless device is operating in a non-terrestrial network.

11. A method performed by wireless device for modifying a timing advance (TA) value, wherein the TA value is based at least in part on a position estimate of a satellite and a timing adjustment value, the method comprising: obtaining (1012) a first satellite position estimate used for calculating a TA value; receiving (1014) a timing advance command from a network node, the timing advance command comprising an indication of the timing adjustment value; obtaining (1016) a second satellite position estimate used for calculating the TA value; updating (1020) the timing adjustment value based on the second satellite position estimate to remove a value corresponding to a difference between the first satellite position estimate and the second satellite position estimate from the timing adjustment value; calculating (1022) a TA value for uplink transmission using the updated timing adjustment value; and transmitting (1024) an uplink transmission using the calculated TA value.

12. The method of claim 11, further comprising obtaining (1018) a wireless device position estimate used for calculating a TA value, and wherein updating the timing adjustment value is further based on the wireless device position estimate.

13. The method of any one of claims 11-12, further comprising transmitting (1026) an indication to the network node of the updated timing adjustment value.

14. A method of any one or more of claims 11-13, wherein: the TA value is represented by the formula ^^^^ = (^^TA + ^^TA-offset + ^^TcoAm,admjon+ ^^UETA,adj ) × ^^c, wherein ^^TA-offset is a configurableadvance,device specific value covering the round trip time of a satellite service link,P110778WO02 PCT APPLICATION 72 of 74 ^^TAis the timing adjustment value received from the network node; and ^^cis a basic time unit; the first satellite position estimate and the second satellite position estimate are used for calculating the ^^TcAom,admjonterm in the TA formula; the difference between the first satellite position estimate and the second satellite position estimate is represented as Terror_UE_position_and_common_TA; and the updated timing adjustment value is represented as ^^TA_new= NTA_old - Terror_UE_position_and_common_TA.

15. The method of any one of claims 11-14, wherein the wireless device is operating in a non-terrestrial network.

16. A wireless device (200) capable of modifying a timing advance (TA) value, the obtain a first satellite position estimate used for calculating a TA value; receive a timing advance command from a network node, the timing advance command comprising an indication of the timing adjustment value; obtain a second satellite position estimate used for calculating the TA value; update the timing adjustment value based on the second satellite position estimate to remove a value corresponding to a difference between the first satellite position estimate and the second satellite position estimate from the timing adjustment value; calculate a TA value for uplink transmission using the updated timing adjustment value; and transmit an uplink transmission using the calculated TA value.

17. The wireless device of claim 16, the processing circuitry further operable to obtain a wireless device position estimate used for calculating a TA value, and wherein the processing circuitry is operable to update the timing adjustment value further based on the wireless device position estimate.

18. The wireless device of any one of claims 16-17, the processing circuitry further operable to transmit an indication to the network node of the updated timing adjustment value.

19. A wireless device of any one or more of claims 16-18, wherein: the TA value is represented by the formula ^^^^ = (^^TA + ^^TA-offset + ^^TcoAm,admjon+P110778WO02 PCT APPLICATION 73 of 74 ^^UETA,adj ) × ^^c, wherein ^^TA-offset is a configurable offset, ^^TcAom,amdjonis a common timing advance, ^^TUAE,adjis a wireless device specific value covering time of a satellite service link,^^TAis the timing adjustment value received from the node; and ^^cis a basic time unit; the first satellite position estimate and the second satellite position estimate are used for calculating the ^^TcAom,admjonterm in the TA formula; the difference between the first satellite position estimate and the second satellite position estimate is represented as Terror_UE_position_and_common_TA; and the updated timing adjustment value is represented as ^^TA_new= NTA_old- Terror_UE_position_and_common_TA.

20. The wireless device of any one of claims 16-19, wherein the wireless device is operating in a non-terrestrial network.

21. A method implemented in a non-terrestrial network communication system including a network node and a wireless device, the method comprising: transmitting (1112), by the network node to the wireless device, a timing advance command comprising an indication of a timing adjustment value; updating (1114), by the wireless device, the timing adjustment value received from the network node, wherein updating the timing adjustment value is based on the wireless device updating one or more of a wireless device position estimate or a satellite position estimate after receiving the timing adjustment value from the network node; calculating (1116), by the wireless device, a timing advance value for uplink transmission using the updated timing adjustment value; and transmitting (1120), by the wireless device to the network node, an uplink transmission using the calculated TA value.

22. The method of claim 21, further comprising receiving (1118), by the network node from the wireless device, an indication that the wireless device updated the timing adjustment value.

23. The method of claim 22, further comprising, based on the received indication at the network node, transmitting (1122), to the wireless device, a timing advance command comprising an indication of an updated timing adjustment value.

Images