TW202325081A - Systems and methods to facilitate long uplink transmission in internet of things non-terresterial networks - Google Patents

Abstract

A method (700) by a user equipment, UE, (112, 200) for facilitating long uplink transmission in an Internet of Things, IoT, Non-Terrestrial Network, NTN, includes transmitting (702), to a network node (110, 300), information for determining whether the UE is to insert at least one gap between adjacent transmission segments in at least one uplink transmission. The UE receives (704), from the network node, configuration information configuring the UE to insert the at least one gap when the information transmitted to the network node indicates that at least one symbol, slot, and/or subframe is to be dropped and/or punctured to implement segmented pre-compensation or not insert the at least one gap when the information transmitted to the network node indicates that at least one sample is to be dropped and/or punctured to implement segmented pre-compensation.

Description

Systems and methods for facilitating long uplink transmissions in IoT non-terrestrial networks

The present invention relates generally to wireless communications, and more particularly to systems and methods that facilitate long uplink transmissions in Internet of Things (IoT) non-terrestrial networks (NTN).

In Release 8 of the 3rd Generation Partnership Project (3GPP), the Evolved Encapsulation System (EPS) was specified. EPS is based on the Long Term Evolution (LTE) radio network and the Evolved Packet Core (EPC). It was originally intended to provide voice and Mobile Broadband (MBB) services but has evolved to expand its functionality. Narrowband Internet of Things (NB-IoT) and LTE Machine Type Communication (LTE-M) are part of the LTE specification since 3GPP Release 13 and provide connectivity to massive Machine Type Communication (mMTC).

In 3GPP Release 15, the first release of the 5G system (5GS) is specified. This is a new generation radio access technology intended to serve use cases such as enhanced mobile broadband (eMBB), ultra-reliable and low-latency communications (URLLC) and mMTC. 5G includes the new radio (NR) access layer interface and the 5G core network (5GC). NR entities and higher layers are reusing parts of the LTE specification and adding required components when motivated by new use cases. One such component is to introduce a complex framework for beamforming and beam management to extend the support of 3GPP technology to a frequency range beyond 6 GHz.

Satellite communications and non-terrestrial networks Satellite communications are making a comeback. Over the past few years, several satellite network projects have been announced. Targeted services vary from Backhaul and Fixed Wireless to Transportation, Outdoor Mobility and IoT. Satellite networks can complement terrestrial mobile networks by providing connectivity to underserved areas and multicast/broadcast services.

To benefit from a strong mobile ecosystem and economies of scale, there is great interest in applying terrestrial radio access technologies including LTE and NR to satellite networks, which is reflected in the 3GPP standardization work.

In 3GPP Release 15, 3GPP started work on preparing NR for operation in an NTN. Work was performed in the research project "NR Support for Non-Terrestrial Networks" and resulted in 3GPP TR 38.811 v.15.4.0. See TR 38.111 v.15.4.0 study on New Radio (NR) to support non-terrestrial networks. In 3GPP Release 16, work on preparing NR for operation in an NTN network of the study item "Supporting NR solution scenarios for non-terrestrial networks" already captured in 3GPP TR 38.821 v.16.1.0 was continued. Refer to NR's TR 38.821 v.16.1.0 solution scenario to support non-terrestrial networks in June 2021, 3GPP, 16.1.0. At the same time, there is growing interest in adapting Narrowband IoT (NB-IoT) and LTE Machine-Type Communications (LTE-M) to operate in the NTN. Therefore, 3GPP Release 17 contains a work item on NR NTN. Refer to RP-193234 for NR supporting non-terrestrial networks (NTN), 3GPP RAN#86.3GPP Release 17 also includes a research project on NB-IoT and LTE-M support for NTN. See Study RP-193235 on NB-Io/eMTC support in 3GPP RAN #86 for non-terrestrial networks.

A satellite radio access network typically includes the following components: • A satellite, which means a space vehicle platform. • An earth-based gateway that connects the satellite to a base station or a core network, depending on the choice of architecture. • Feeder link, which refers to the link between a gateway and a satellite. • Access link or service link, which refers to the link between a satellite and a user equipment (UE).

Depending on the altitude of the orbit, a satellite can be classified as a Low Earth Orbit (LEO), Medium Earth Orbit (MEO) or Geosynchronous Orbit (GEO) satellite: · LEO: Typical altitudes range from 250 km to 1,500 km, with orbital periods ranging from 90 minutes to 120 minutes. • MEO: Typical altitudes range from 5,000 km to 25,000 km with orbital periods ranging from 3 hours to 15 hours. • GEO: Altitude is about 35,786 km, which has an orbital period of 24 hours.

Depending on the functionality of the satellites in the system, two basic architectures of satellite communication networks can be distinguished: ·Transparent payload (also referred to as bent pipe architecture): The satellite forwards the received signal between the terminal and the network equipment on the ground only amplified and shifted from the uplink frequency to the downlink frequency. When applied to the general 3GPP architecture and terminology, the transparent payload architecture means that the gNodeB (gNB) is located on the ground and the satellite relays signals/data between the gNB and the UE. • Regeneration Payload: Satellites contain onboard processing to demodulate and decode received signals and regenerate them before sending them back to Earth. When applied to the general 3GPP architecture and terminology, the regenerative payload architecture means that the gNB is located in the satellite.

In the work item of NR NTN in 3GPP Release 17, only the transparent payload architecture is considered.

FIG. 1 illustrates an example architecture (ie, transparent payload architecture) of a satellite network with bent pipe transponders. The gNB can be integrated in the gateway or connected to the gateway via a ground connection (wired, fiber optic, wireless link).

A communications satellite typically produces several beams over a given area. The occupied area of a beam is generally in the shape of an ellipse, which is traditionally regarded as a cell, but a cell composed of covered occupied areas of multiple beams is not excluded in 3GPP work. The occupied area of a beam is usually also referred to as a spot beam. The footprint of a beam can move over the Earth's surface as the satellite moves or the Earth can be fixed using a beam pointing mechanism used by the satellite to compensate for the satellite's motion. The size of a spot beam depends on the system design, which can range from tens of kilometers to thousands of kilometers.

Consequences of long propagation delay/RTT and high satellite speed Propagation delay is an important aspect of satellite communications that differs from the delay expected in a terrestrial mobile system. For a bent-pipe satellite network, depending on the orbital altitude, the round-trip delay can range from tens of ms in the case of LEO satellites to hundreds of ms for GEO satellites. For comparison, round-trip latency in terrestrial cellular networks is typically below 1 ms.

The distance between a UE and a satellite can vary significantly depending on the position of the satellite and thus the elevation angle ε seen by the UE. Assuming a circular orbit, the minimum range is achieved when the satellite is directly above the UE (ε = 90°), and the maximum range is achieved when the satellite is at the minimum possible elevation angle. Table 1 shows the distance between the satellite and the UE at different orbital heights and elevation angles, as well as the one-way propagation delay and the maximum propagation delay difference (difference from the propagation delay when ε = 90°). It should be noted that this table assumes a regenerative payload architecture. For the transparent payload case, the propagation delay between the gateway and the satellite also needs to be considered, unless corrected for by the base station. Table 1: Propagation delay for different orbital heights and elevation angles. track height elevation angle Distance UE <-> Satellites one-way propagation delay Propagation delay difference 600km 90° 600km 2.0ms --- 30° 1075km 3.6ms 1.6ms 10° 1932km 6.4ms 4.4ms 1200km 90° 1200km 4.0ms --- 30° 1999km 6.7ms 2.7ms 10° 3131km 10.4ms 6.4ms 35786km 90° 35786km 119.4ms --- 30° 38609km 128.8ms 9.4ms 10° 40581km 135.4ms 16.0ms

Due to the high speeds of LEO and MEO satellites, propagation delays can also be highly variable depending on orbital altitude and satellite speed and can vary from about 10 µs to about 100 µs per second.

For NTN using 3GPP technologies, specifically 5G/NR, the long propagation delay means that the timing advance (TA) of the UE for its uplink transmission is necessary and has to be much larger than in terrestrial networks to make the uplink And the downlink is time aligned at the gNB, as is the case in NR and LTE. One of the purposes of the random access (RA) procedure is to provide the UE with an effective TA that the network can later adjust based on the timing of reception of uplink transmissions from the UE. However, even the RA prefix (i.e. the initial message from the UE in the RA procedure) has to be transmitted with a TA to allow a reasonable size of the RA prefix reception window in the gNB (and to ensure that the cyclic shift of the Zadoff-Chu sequence of the prefix is not is too large to make the Zadoff-Chu sequence and thus the prefix appear to be another Zadoff-Chu sequence and thus another prefix based on the same Zadoff-Chu root sequence). However, this TA need not be as accurate as the TA that the UE subsequently uses for other uplink transmissions. The TA used by UE for RA prefix transmission in NTN is called "precompensated TA". Various proposals on how to determine the precompensated TA have been considered, all of which involve information from both the gNB and the UE. In short, the alternative scenarios discussed include: • The network broadcasts a "common TA" valid at a specific reference point, such as, for example, a central point in a cell. Then, the UE will calculate how its own precompensated TA deviates from the common TA based on the difference between the UE's own position and the reference point and the position of the satellites. According to this method, the UE obtains its own position using Global Navigation Satellite System (GNSS) measurements and obtains satellite positions using satellite orbit data (including satellite positions at a particular time) broadcast by the network. • The UE autonomously calculates the propagation delay between the UE and the satellite based on the respective positions of the UE and the satellite, and the network/gNB broadcasts the propagation delay on the feeder link (ie, the propagation delay between the gNB and the satellite). According to this method, the UE obtains its own position using GNSS measurements and obtains satellite positions using satellite orbit data (including satellite positions at a particular time) broadcast by the network. The precompensated TA is then calculated as twice the sum of the propagation delay on the feeder link and the propagation delay between the satellite and the UE. • The gNB broadcasts a timestamp (in System Information Block 9 (SIB9)) that the UE compares with a reference timestamp obtained from the GNSS. Based on the difference between these two timestamps, UE can calculate the propagation delay between gNB and UE, and the precompensation TA is twice this propagation delay.

In conjunction with the RA procedure, the gNB provides the UE with an accurate (ie, fine-tuned) TA in the Random Access Response message (in 4-step RA) or MsgB (in 2-step RA) based on the reception time of the RA prefix. The gNB may then use a Timing Advance Command MAC CE (or an Absolute Timing Advance Command MAC CE) to adjust the TA of the UE based on the timing of receiving uplink transmissions from the UE. One goal of this network control of the UE's TA is typically to keep the timing error of the UE's uplink transmissions at the gNB's receiver within the cyclic prefix (as necessary for correct decoding of the uplink transmissions). The TA control frame also includes a time alignment timer configured by the gNB for the UE. The time alignment timer is restarted every time the gNB adjusts the UE's TA and if the time alignment timer expires, the UE is not allowed to transmit in the uplink without a previous RA procedure, which is used to provide the UE 1. The effective timing advances. For NTN, 3GPP also agrees that, in addition to the gNB's control of the UE's TA, the UE is allowed to use knowledge of its position (e.g. obtained from GNSS measurements) and ephemeris data of the serving satellites and feeder link delay information from the gNB, Its TA is updated autonomously based on the estimation of changes in UE-gNB round trip time (RTT).

A second correlation pattern is that not only the propagation delay between a UE and a satellite or between a UE and a gNB is very long in NTN, but also due to the large distance, the propagation delay between two different satellites or two different gNBs The difference in latency can be more pronounced at timescales associated with cellular communications involving signaling procedures, even when satellites/gNBs serve neighboring cells. This has implications for all procedures involving reception or transmission in two cells served by different satellites and/or different gNBs.

A third important aspect related to long propagation delay/RTT in non-terrestrial networks is to introduce an additional parameter to compensate for long propagation delay/RTT. In terrestrial cellular networks, the UE-gNB RTT can range from close to zero to tens of microseconds in a cell. Aside from the absolute magnitude of the propagation delay/RTT, one major difference in non-terrestrial networks is that even at locations in the cell where the propagation delay/RTT is smallest, the propagation delay/RTT will be large and not close to zero. In fact, the variation of propagation delay/RTT within an NTN cell is small compared to propagation delay/RTT. This facilitates the introduction of an offset that basically takes care of the RTT between the footprint of the cell on the ground and the satellite, while other mechanisms including signaling and control loops vary in RTT within the cell on top of the offset Take care of RTT dependence in a small range. To this end, 3GPP has agreed to introduce such a parameter, designated _Koffset (or sometimes K_offset).

The K _offset parameter can potentially be used in various timing related mechanisms, but the relevant application herein uses this parameter in the scheduling of uplink transmissions on the Physical Uplink Shared Channel (PUSCH). K _offset is used to indicate an additional delay between the uplink grant (UL grant) and the PUSCH transmission resources allocated by the UL grant to be added to the slot offset parameter in the downlink control information (DCI) containing the UL grant K ₂ . Therefore, the offset between the UL grant and the time slot in which PUSCH transmission resources are allocated is K _offset + K ₂ . When used in this way in uplink scheduling, K _offset can purportedly be used to ensure that the UE is not scheduled to be one before the point in time when the UE receives the UL grant due to the larger TA that the UE has to apply point-in-time transmission. In 3GPP, it has also been discussed to make the K _offset configuration of the network take into account the TA that the UE can already use for the sending UE.

A fourth important aspect closely related to timing is a Doppler shift induced by the motion of the satellite. In the sub-6 GHz band, the access link may be exposed to a Doppler shift of about 10 kHz to about 100 kHz and proportionally higher in the higher frequency bands. Additionally, the Doppler shift varies at a rate of up to a few hundred Hz per second in the S-band and at a rate of several thousand kHz per second in the Ka-band.

ephemeris data In 3GPP TR 38.821 v.16.1.0, ephemeris data that should be provided to the UE is acquired to, for example, assist in pointing a directional antenna (or an antenna beam) at a satellite and calculating a correct TA and Doppler shift. The procedure for how to provide and update ephemeris data has not been studied in detail, but broadcasting ephemeris data in system information is an option.

A satellite orbit can be fully described using six parameters. Exactly which set of parameters to choose is up to the user, and many different representations are possible. For example, one of the choices of parameters often used in astronomy is the set of orbits (a, ε, i, Ω, ω, t), as shown in FIG. 2 . As depicted in the figure, the semi-major axis a and eccentricity ε describe the shape and size of the orbital ellipse; the inclination i, the right ascension of the ascending node Ω, and the argument of the pericentric point ω determine its position in space, and the epoch t determines a reference time (for example, the time when the satellite moves through the periapsis).

As an example of a different parameterization, a two-line element (TLE) uses mean motion n and mean anomaly M instead of a and t. A completely different set of parameters is the position and velocity vectors (x, y, z, v _x , v _y , v _z ) of a satellite. These are sometimes called orbital state vectors. They can be derived from track elements and vice versa, since the information they contain is equivalent. All of these formulas (and many others) are possible choices for the format of the ephemeris data in NTN. To achieve further progress, the format of the information should be agreed upon.

It is important that a UE can determine the position of a satellite with an accuracy of at least a few meters. However, some studies have shown that this can be difficult to achieve when using the de facto standard of TLE. On the other hand, LEO satellites usually have GNSS receivers and can determine their position with some meter accuracy.

Another aspect discussed during the research project and captured in 3GPP TR 38.821 v.16.1.0 is the validity time of ephemeris data. In general, predictions of satellite positions degrade with the age of the ephemeris data used. This is due to atmospheric drag, steering of the satellite, imperfections in the orbital model used, etc. Thus, for example, public TLE data are frequently updated. The update frequency depends on the satellite and its orbit and ranges from weekly to multiple times a day for satellites in very low orbits that are exposed to strong atmospheric drag and need to frequently perform corrective maneuvers.

Therefore, while it may seem possible to provide satellite positions with the required accuracy, care needs to be taken to meet these requirements. For example, care needs to be taken when selecting the ephemeris data format or orbit model for orbit propagation.

Some results of 3GPP research projects on NTN The results of the research items in 3GPP lay the foundation for the specification work of NTN in 3GPP. The following contains some relevant information on the research project discussed above and the resulting technical report: The coverage pattern of NTN is described in Section 4.6 of 3GPP TR 38.811 v.15.4.0 as follows: Satellites or aircraft usually generate several beams over a given area. The footprint of the beam is usually elliptical. The beam footprint can move across the earth as the satellite or vehicle moves in its orbit. Alternatively, the beam footprint could be fixed on Earth, in which case some beam pointing mechanism (mechanical or electronic steering features) would compensate for satellite or vehicle motion.

Typical beam footprint sizes are listed in Table 2, which corresponds to Table 4.5.1 in Section 4.6 of 3GPP TR 38.811 v.15.4.0. Table 2: Typical Beam Occupancy Area Size [1] Attributes GEOs Non -GEO Sky The area occupied by the beam in units of diameter 200 km to 1000 km 100km to 500km 5 km to 200 km

Figure 3 shows typical beam patterns for various NTN access networks as discussed in 3GPP TR 38.811 v.15.4.0.

The TR of the second research project 3GPP TR 38.821 v.16.1.0 describes the working scenario of NTN as follows: Non-terrestrial networks are often characterized by the following elements: - Connecting non-terrestrial networks to one or several satellite gateways of a public data network - A GEO satellite is fed by one or several satellite gateways deployed across satellite target coverage (eg regional or even continental coverage). We assume that UEs in a cell are served by only one satellite gateway - A non-GEO satellite is continuously served by one satellite gateway at a time. The system ensures continuity of service and feeder links between continuous service satellite gateways with sufficient duration for mobility anchoring and handover

As depicted in Table 3, four scenarios are considered and detailed in Table 4, which correspond to Table 4.2-1 and Table 4.2-2 of 3GPP TR 38.821 v.16.1.0, respectively. Table 3: Reference Scenarios transparent satellite Representative satellite Non-terrestrial access network based on GEO Scenario A Scenario B Non-terrestrial access network based on LEO Scenario C Scenario D Table 4: Reference scene parameters Scenes GEO-based non-terrestrial access network (scenario A and B) Non-terrestrial access network based on LEO (Scenario C & D) track type Equivalent to the elevation/azimuth of a given earth point, the concept station remains fixed. circular orbit around the earth high 35,786 km 600 km 1,200 km Spectrum (Service Link) <6 GHz (eg 2 GHz) >6 GHz (eg DL 20 GHz, UL 30 GHz) Maximum channel bandwidth (service link) For frequency bands < 6 GHz, 30 MHz For frequency bands > 6 GHz, 400 MHz payload Scenario A: Transparent (includes radio frequency functions only) Scenario B: Regeneration (includes all or part of RAN functions) Scenario C: Transparent (includes radio frequency functions only) Scenario D: Regeneration (includes all or part of RAN functions) inter-satellite link no Scenario C: No Scenario D: Yes Earth Fixed Beam yes Scenario C: No (beam moves with satellite) Scenario D, option 1: Yes (steering beam), see note 1 Scenario D, option 2: No (beam moves with satellite) The diameter of the largest beam occupied area at the nadir 500km 200km Minimum elevation angle of both satellite gateway and user equipment 10° 10° Maximum distance between satellite and user equipment at minimum elevation angle 40,586km 1,932 km (600 km altitude) 3,131 km (1,200 km altitude) Maximum round trip delay (propagation delay only) Scenario A: 562ms (service and feeder link) Scenario B: 281ms Scenario C: 25.76 ms (transparent payload: service and feeder link) Scenario D: 12.88 ms (regenerating payload only: service link only) Maximum delay variation within a beam (Earth fixed user equipment) 16ms 4.44ms (600km) 6.44ms (1200km) Maximum differential delay within a beam 1.6ms 0.65 ms (*) Maximum Doppler shift (Earth fixed user equipment) 0.93ppm 24 ppm (*) Maximum Doppler Shift Variation (Earth Fixed User Equipment) 0.000 045 ppm/s 0.27ppm/s (*) User Equipment Movement on Earth 1000 km/h (eg aircraft) 500 km/h (eg high-speed train) possibly 1000 km/h (eg aircraft) User Equipment Antenna Type Omnidirectional antenna (linear polarization), assuming 0 dBi Directional antenna (up to 60 cm equivalent aperture diameter in circular plan) User equipment Tx power Omnidirectional Antenna: Up to 200 mV UE Power Category 3 Directional Antenna: Up to 4 W UE Noise Index Omni-directional antenna: 7 dB Directional antenna: 1.2 dB service link New Wireless defined by 3GPP feeder link 3GPP or non-3GPP defined radio interface 3GPP or non-3GPP defined radio interface

It should be noted that each satellite has the ability to steer beams towards fixed points on Earth using beamforming techniques. This may apply for a period of time corresponding to the satellite's visibility time. Based on the minimum elevation angle of both the gateway and the UE, the maximum delay variation within a beam (Earth-fixed UE) is calculated. The maximum differential delay within a beam is calculated based on the maximum beam footprint diameter at nadir.

For Scenario D, which is a LEO with a regenerative payload, both Earth-fixed and Earth-mobile beams are listed. Therefore, there is also an additional scenario when we consider fixed/non-stationary beams. The complete list of the 5 scenarios in 3GPP TR 38.821 v.16.1.0 is as follows: Scenario A - GEO, Transparent Satellite, Earth Fixed Beam; Scenario B - GEO, regenerative satellites, Earth fixed beams; Scenario C - LEO, Transparent Satellite, Earth Mobile Beam; Scenario D1 - LEO, regenerative satellite, Earth fixed beam; • Scenario D2 - LEO, regenerative satellite, Earth mobile beam.

Segment precompensation for long uplink transmissions In the Rel-17 IoT NTN work item (WI), it has been agreed to introduce segment pre-compensation for uplink transmissions for long uplink transmissions. Previously, the UE would adjust its uplink timing at the start of the transmission. For IoT NTN, the network can configure a transmission segment of a specific duration for the UE, and the UE can adjust its timing and frequency at the beginning of each such transmission segment. This feature has been introduced to compensate for large timing and frequency shifts in NTN scenarios such as LEO.

·對於eMTC，重複單元係用於子實體資源區塊(子PRB)分配之

，其中T _slot= 0.5 ms。對於全實體資源區塊(全PRB)分配，重複單元係一個子訊框。 ·注釋1：在TS 36.211 10.1.2.3及10.1.3.6中針對NB-IoT界定

、

、

。 ·注釋2：在TS 36.211、5.2.3A中針對eMTC界定M_^UL_slot。 ·FFS：RAN1進一步討論有效及無效子訊框 ·FFS：組態細節 協議：對於NB-IoT，若至N _slots時隙之一映射或針對窄頻PUSCH (NPUSCH)傳輸之UE預補償之一UL傳輸片段中之映射之一重複含有與任何經組態之窄頻實體隨機存取通道(NPRACH)資源重疊之一資源元件，則在重疊N _slots時隙中之NPUSCH傳輸延遲直至下一個N _slots時隙不與任何經組態之NPRACH資源重疊。 注釋：N _slots界定於TS 36.211、10.1.3.6中 協議：UL傳輸片段持續時間由網路組態 ·FFS：組態發訊之細節。 協議： ·對於NB-IoT NTN，網路在一k位元欄中為各PRACH前置碼格式之UL傳輸片段持續時間組態K個值之一者，其中k位元欄之大小及K個候選值之數目取決於前置碼格式。 ○格式0及格式1：3位元欄，K = 6個候選值2.4.(T _CP+ T _SEQ)、4.4.(T _CP+ T _SEQ)、8.4.(T _CP+ T _SEQ), 16.4.(T _CP+ T _SEQ)、32.4.(T _CP+ T _SEQ)、64.4.(T _CP+ T _SEQ) ○格式2：2位元欄，K = 4個候選值2.6.(T _CP+ T _SEQ)、4.6.(T _CP+ T _SEQ)、8.6.(T _CP+ S _TEQ)、16.6 (T _CP/T _SEQ) ·FFS：K個候選值之向下範疇，k位元欄之大小 ·FFS：相同片段持續時間是否可用於一前置碼格式內之所有前置碼 協議： ·對於eMTC，網路在一k位元欄中為PRACH之UL傳輸片段持續時間組態K個值之一者 ·FFS：K個候選值，k位元欄之大小 協議： ·對於NB-IoT/eMTC NTN，網路在一k位元欄中為NPUSCH/PUSCH之UL傳輸片段持續時間組態K個候選值之一者。 ○對於NB-IoT，具有一最大數目K = 8個候選值2 ms、4 ms、8 ms、16 ms、32 ms、64 ms、128 ms、256 ms之最大3位元欄 ·FFS：K個候選值之向下範疇，k位元欄之大小 協議： ·UL傳輸片段持續時間由UE特定無線電資源控制(RRC)發訊或藉由在系統資訊區塊(SIB)中發訊來提供。 ·注釋：NB-IoT之UL傳輸片段持續時間之值可不同於eMTC之值。 In the 3GPP RAN1#106-e meeting, the following agreement was reached on segment pre-compensation for long UL transmissions: Protocol: Segmentation of uplink (UL) transmission segments for UE pre-compensation for physical random access channel (PRACH) transmission The duration is a number of Random Access Channel (RACH) repeating units configured by the network. For NB-IoT, the repeating unit is P groups of symbols. • For Enhanced Machine Type Communication (eMTC), the repeat unit contains a preamble of the guard period. For future studies (FFS): Configuration details Protocol: The duration of the UL transmission segment for UE precompensation for PUSCH transmission is a number of PUSCH repetition units configured by the network: For NB-IoT, the repetition unit is

For eMTC, repeating units are used for sub-Physical Resource Block (sub-PRB) allocation

, where T _slot = 0.5 ms. For a full physical resource block (full PRB) allocation, the repetition unit is a subframe. Note 1: Defined for NB-IoT in TS 36.211 10.1.2.3 and 10.1.3.6

,

,

. • Note 2: M_^UL_slot is defined for eMTC in TS 36.211, 5.2.3A. FFS: RAN1 further discusses valid and invalid subframes FFS: Configuration details protocol: For NB-IoT, if one of N _slots is mapped or one of UE precompensation for narrowband PUSCH (NPUSCH) transmission UL If one of the repetitions of the mapping in the transmission segment contains a resource element that overlaps with any configured narrowband physical random access channel (NPRACH) resource, then the NPUSCH transmission in the overlapping N _{slots slots} is delayed until the next N _slots The slot does not overlap with any configured NPRACH resources. Note: N _slots are defined in TS 36.211, 10.1.3.6 Protocol: UL transmission segment duration is configured by the network · FFS: Details of configuration signaling. Protocol: For NB-IoT NTN, the network configures one of K values for the UL transmission segment duration of each PRACH preamble format in a k-bit column, where the size of the k-bit column and K The number of candidate values depends on the preamble format. ○ Format 0 and Format 1: 3-bit column, K = 6 candidate values 2.4.(T _CP + T _SEQ ), 4.4.(T _CP + T _SEQ ), 8.4.(T _CP + T _SEQ ), 16.4. (T _CP + T _SEQ ), 32.4. (T _CP + T _SEQ ), 64.4. (T _CP + T _SEQ ) o Format 2: 2-bit column, K = 4 candidate values 2.6. (T _CP + T _SEQ ), 4.6. (T _CP + T _SEQ ), 8.6. (T _CP + S _TEQ ), 16.6 (T _CP /T _SEQ ) FFS: the downward category of K candidate values, the size of the k-bit column FFS : Whether the same segment duration can be used for all preamble protocols within a preamble format: For eMTC, the network configures one of K values for the UL transmission segment duration of PRACH in a k-bit column FFS: K candidate values, size of k-bit field Protocol: For NB-IoT/eMTC NTN, the network configures K candidate values for NPUSCH/PUSCH UL transmission segment duration in a k-bit field one of them. ○ For NB-IoT, there is a maximum number of K = 8 candidate values 2 ms, 4 ms, 8 ms, 16 ms, 32 ms, 64 ms, 128 ms, 256 ms maximum 3-bit field FFS: K Down range of candidate values, size of k-bit field Protocol: • UL transmission segment duration is provided by UE-specific Radio Resource Control (RRC) signaling or by signaling in System Information Block (SIB). Note: The value of UL transmission segment duration for NB-IoT may be different from that of eMTC.

In the 3GPP RAN1#106-bis-e meeting, the following agreement was reached for segment pre-compensation for long UL transmissions: Protocol: Configuration of UL transmission segments is at least indicated on the system information block (SIB) for initial access· FFS via UE-specific RRC signaling in RRC_CONNECTED. Protocol: For eMTC PUSCH, K = one of 8 values for indicating uplink transmission segment duration 3-bit column: · Full PRB allocation (unit: subframe): 2 4 8 16 32 64 128 256 · Sub-PRB allocation (unit: resource unit): 1 2 4 8 16 32 64 128 Protocol: For eMTC, a 3-bit column is defined in the SIB to indicate the following K = 8 values of the UL transmission segment duration of the PRACH: (T _CP + T _SEQ + T _GP ), 2 * (T _CP + T _SEQ + T _GP ), 4 * (T _CP + T _SEQ + T _GP ), 8 * (T _CP + T _SEQ + T _GP ), 16 * (T _CP + T _SEQ + T _GP ), 32 * (T _CP + T _SEQ + T _GP ), 64 * (T _CP + T _SEQ + T _GP ), 128 * (T _CP + T _SEQ + T _GP ) Protocol: For eMTC, the same value is used for the segment duration of all PRACH preambles Protocol: For NB-IOT, for a specific NPRACH format, the same value is used for the segment duration of all NPRACH preambles

However, there are currently some challenges. For example, in non-geosynchronous orbit (NGSO) satellites, especially LEO scenarios, TA and frequency errors due to large timing and frequency shifts can be very high. In Rel-17 IoT NTN WI, segment precompensation will be introduced for this equal-length UL transmission. For example, a UE may adjust its UL transmission timing and frequency at the beginning of each transmission segment during a UL transmission duration. Therefore, methods and signaling are needed to facilitate segment pre-compensation while taking into account different UE capabilities.

Certain aspects of the invention and embodiments thereof may provide solutions to these and other challenges. For example, methods and systems are provided to support different types of UE capabilities with respect to segment pre-compensation for IoT NTN. Additionally or alternatively, certain methods and system mappings provide for TA-dependent gap configurations to minimize the need to insert uplink gaps for segment pre-compensation.

According to some embodiments, a method by a UE for facilitating long uplink transmissions in an IoT NTN comprises sending the transmissions to a network node for determining whether the UE is in at least one uplink transmission. Information of at least one gap is inserted between adjacent transmission segments. The processing circuitry is configured to receive from the network node the information configuring the UE to when transmitted to the network node indicates that at least one symbol, slot and/or subframe is to be discarded and/or punctured to The configuration information of the at least one gap is inserted when performing segment pre-compensation. Alternatively, the configuration information configures the UE not to insert the at least one gap when the information transmitted to the network node indicates that at least one sample is to be discarded and/or punctured for segment precompensation.

According to certain embodiments, a UE for facilitating long uplink transmissions in an IoT NTN comprises a UE configured to pass the transmission to a network node for determining whether the UE is in at least one uplink transmission Information processing circuitry for inserting at least one gap between adjacent transmission segments. The processing circuitry is configured with configuration information received from the network node to configure the UE to when the information transmitted to the network node indicates at least one symbol, slot and/or to be discarded and/or punctured or sub-frame to insert the at least one gap when implementing segment pre-compensation. Optionally, the configuration information configures the UE not to insert at least one gap when the information sent to the network node indicates that at least one sample is to be discarded and/or punctured for segment pre-compensation.

According to some embodiments, a method by a network node for facilitating long uplink transmissions in an IoT NTN comprises receiving from a UE a neighbor for determining whether the UE is staying in at least one uplink transmission Information for inserting at least one gap between transmission segments. Based on the information, the network node configures the UE to insert the at least one gap when the information indicates that at least one symbol, slot and/or subframe is to be dropped and/or punctured for segment precompensation. Alternatively, the network node configures the UE not to insert the at least one gap when the information indicates that at least one sample is to be discarded and/or punctured for segment pre-compensation.

According to some embodiments, a network node comprises processing circuitry configured to receive from a UE information for determining whether the UE is to insert at least one gap between adjacent transmission segments in at least one uplink transmission . Based on the information, the processing circuitry is configured to configure the UE to insert the at least one a gap. Alternatively, the network node configures the UE not to insert the at least one gap when the information indicates that at least one sample is to be discarded and/or punctured for fragmentation pre-compensation.

Certain embodiments may provide one or more of the following technical advantages. For example, certain embodiments may provide a technical advantage of supporting different types of UE capabilities with respect to segment pre-compensation for IoT NTN. As another example, certain embodiments may provide a technical advantage of minimizing the need to insert uplink gaps for segment pre-compensation.

Other advantages will be readily apparent to those skilled in the art. Certain embodiments may have none, some, or all of the described advantages.

Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. The embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

As described above, in Rel-17 IoT NTN WI, it has been agreed to introduce UL precompensated transmission segments. The UE may autonomously adjust its TA (and/or frequency) for UL transmission at the beginning of each transmission segment. The network will at least use the SIB to indicate the transport segment configuration.

The following definitions are used to explain the embodiments disclosed herein: • Type A UE: A gap needs to be inserted between adjacent transmission segments to implement segmented uplink precompensation. • Type B UE: No need to insert a gap between adjacent transmission segments to implement segmented uplink precompensation. It can be implemented, for example, by dropping/inserting samples or breaking down symbols, etc.

In a particular embodiment, for type B UEs, the number of samples or symbols or slots or subframes or resource units to be discarded for segment precompensation is fixed in the standard specification.

In another particular embodiment, multiple values for the number of samples or symbols or slots or subframes or resource units (to be discarded or punctured) may be defined in the specification. The network may use System Information (SI) or UE-specific RRC signaling to indicate supported values or a subset of values (from values defined in the specification). It should be noted that the network does not need to insert a gap between transmission segments for Type B UEs.

If UL gaps are introduced for segment pre-compensation, it will complicate scheduling, especially if the need for gaps depends on UE capabilities (ie, Type A or Type B UEs). Also, if the gaps are short (eg, 1 ms) and spread out, the gaps will be difficult to use to schedule UL transmissions from other UEs.

An alternative method that can reduce the impact on the scheduler if, for example, UL gaps are required for Type B UEs is by UEs by blanking the UL at regular intervals (which can be fixed in the specification or configurable by the network) Subframes are used to create gaps, thereby reducing the number of repetitions rather than spreading them in time. Then, the scheduler can allocate the same UL resources no matter whether the UE needs gaps or not.

The concepts described herein can be applied to LTE-M NTN and NB-IoT NTN uplink channels such as, for example, Narrowband Physical Uplink Shared Channel ((N)PUSCH), Narrowband Physical Random Access Channel ((N)PUSCH) N PRACH) and physical uplink control channel (PUCCH) but can also be applied to other UL channels.

Transmission segment duration or segment duration refers to the duration of a transmission segment configured by the network for segmented uplink pre-compensation.

UE capability signaling In one embodiment, the UE signals to the network whether it is a Type A UE or a Type B UE.

In a further specific embodiment, a Type A UE signals the duration of gaps it needs to insert between adjacent segments to perform segmented uplink precompensation. A range of values for possible gap durations may be specified in the specification and/or indicated by the network in the SI.

In a further specific embodiment, a Type B UE signals to the network the number of samples or symbols or slots or subframes or resource units that it needs to discard/puncture to perform segment precompensation.

In a further specific embodiment, UE capability signaling depends on the type of physical channel. For example, an NB-IoT UE may signal that it needs a gap in NPUSCH transmission but does not need a gap in NPRACH transmission. Similarly, an eMTC UE can signal that it needs a gap in PUSCH/PUCCH transmission but not a gap in PRACH transmission.

In another specific embodiment, UE capability signaling depends on the duration of the transmission of the physical channel. For example, a UE may report: No need for a gap between adjacent transmission segments • It does not require a gap between adjacent transmission segments for a certain duration of eg 256 ms, but it needs to use a gap after each transmission of 256 ms. In addition, it can signal that the required gap is a conventional UL backoff gap of 40 ms or a gap with a duration other than 40 ms. • A gap is required between adjacent transmission segments within a certain duration of eg 256 ms.

In another specific embodiment, UE capability signaling depends on NTN type or satellite orbit. For example, a UE may report • There is no need for a gap between adjacent transmission segments of the GEO satellite network. • A gap is required between adjacent transmission segments of LEO/MEO satellite networks.

TA dependent gap configuration According to some embodiments, the UE may need to insert gaps between adjacent transmission segments to implement timing/frequency pre-compensation. In a particular embodiment, the network may schedule and/or instruct the UE where to insert gaps. In another embodiment, the UE can choose where to insert the gap (ie, between the adjacent segments that the UE likes). The UE may then inform the network where the gaps have been placed by the UE. Making the information available online avoids blind testing and simplifies scheduling.

In a particular embodiment, the UE inserts a gap between adjacent transmission segments depending on TA increase or decrease. If TA is not increased, it will not insert gaps between segments; if TA is increased, it will insert gaps between adjacent segments. For example, based on the satellite ephemeris and GNSS position information, the UE may determine whether the satellite is moving towards the UE and/or whether the satellite-UE elevation angle is increasing. In other words, the satellite-UE TA will decrease over time during uplink transmission. The UE will not insert extra gaps between adjacent segments.

In a particular embodiment, depending on TA increase or decrease, the UE indicates to the network whether it will insert gaps between adjacent transmission segments of the persistent UL transmission.

In another particular embodiment, the UE provides information to the UE so that the network can determine whether the UE will use gaps and then detect accordingly. For example, in a particular embodiment, the UE reports its location to the network, and the network determines TA increase or decrease based on the satellite ephemeris and the received UE location. The network deduces that if the TA is not increased, the UE does not insert the gap. Otherwise, if TA increases, the network deduces that the UE inserts the gap.

In another specific embodiment, the UE reports its TA to the network, and the network decides to increase or decrease the TA based on the received TA value. The network deduces that if the TA is not increased, the UE does not insert the gap. Otherwise, if TA increases, UE inserts a gap. Thus, in a particular embodiment, the network may signal to the UE that the UE is to be inserted into a gap, eg, based on the network determining (for example) that the TA has increased.

MSG3 (N)PUSCH and PUCCH to Msg4/NPUSCH format 2 to Msg4 The following examples relate to network configuration for MSG3 transmission on PUSCH/NPUSCH or hybrid automatic repeat request acknowledgment (HARQ-ACK) transmission on PUCCH to Msg4 reception/HARQ-ACK transmission on NPUSCH format 2 to MSG3 reception The situation of time.

In one embodiment, the UE is specified in the standard specification to insert gaps between adjacent transmission segments for MSG3 transmission on PUSCH/NPUCCH or HARQ-ACK transmission on PUCCH to Msg4 reception/NPUSCH Format 2 to MSG3 reception HARQ-ACK. The duration of the gap is fixed in the specification. Alternatively, it can be configured by the network from a set of values defined in the specification, and the configured gap duration can be indicated by the network in SI.

For example, if transmission segments are configured in a cell, all UEs insert gaps between adjacent segments for the indicated duration of MSG3 transmission on PUSCH, regardless of UE capabilities.

In another embodiment, the standard specification specifies that for MSG3 transmission on PUSCH/NPUCCH or HARQ-ACK transmission on PUCCH to Msg4 reception/HARQ-ACK transmission on NPUSCH format 2 to MSG3 reception, the UE should not be in the adjacent Inserts gaps between transmitted segments. - If the network configures the UE with N repetitions for MSG3 or PUCCH/NPUSCH format 2 to Msg4 reception, the UE behavior for Type A UEs is to use minimum (N, M) repetitions to transmit MSG3 or PUCCH/NPUSCH Format 2 to Msg4 reception, where M is the maximum number of repetitions it can transmit before requiring uplink precompensation. M can be indicated by the network in system information (SI) or specified in the specification or M can be equal to the duration of a segment. Therefore, in a particular embodiment, the UE transmits only M repetitions. However, in another embodiment, where M is less than N, the UE may not transmit all N repetitions. In yet another embodiment, the UE may insert a gap and then transmit the remaining N-M repetitions. In yet another embodiment, the UE may use one repetition as a gap after the initial M repetitions and then continue to transmit N-M-1 repetitions. - If the network configures the UE to use N repetitions for MSG3, or PUCCH/NPUSCH format 2 to Msg4 reception, then the UE behavior for Type B UEs is to use N repetitions to transmit MSG3 or PUCCH/NPUSCH format 2 to Msg4 reception. Thus, in an example embodiment, Type B UEs drop samples or puncture symbols as necessary (as described above) to be able to transmit all N repetitions.

In another embodiment, type A UEs insert specified or indicated gaps between transmission segments of MSG3 transmissions on PUSCH/NPUSH (or PUCCH/NPUSCH format 2 to Msg4 reception) and type B UEs do not on PUSCH/PPUUSCH Gap is inserted between transport segments of MSG3 transmission (or PUSCH/NSUCH format 2 to Msg4 reception). If the network does not yet know the UE capabilities, the network receives UE transmissions by blind testing. For example, the network may perform multiple attempts to receive UE transmissions to cover all possible options. In other words, the network can blindly test UE transmissions assuming that the UE is using a gap and that it is not using a gap.

In a sub-embodiment, PRACH resources (time/frequency/code domain) are allocated for Type A and Type B UEs (i.e. they use different PRACHs so that the network knows UE capabilities and can schedule MSG3 accordingly and can decide MSG3 Whether the transmission will contain gaps. As used herein, PRACH resources may include resources for the random access preamble (Msg1).

Figure 4 shows an example of a communication system 100 according to some embodiments. In an example, the communication system 100 includes: a telecommunications network 102 including an access network 104 such as a radio access network (RAN); and a core network 106 including one or more cores Network node 108 . Access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may generally be referred to as network node 110), or any other similar 3GPP ( 3GPP) access node or non-3GPP access point. Network node 110 facilitates direct or indirect connections of user equipment (UEs), such as by connecting UEs 112a, 112b, 112c, and 112d (one or more of which may be generally referred to as UE 112) via one or more wireless connections to core network 106 .

Example wireless communication via a wireless connection includes transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for communicating information without the use of wires, cables, or other material conductors. Note that in various embodiments, 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, regardless of Via wired or wireless connection. The communication system 100 may include and/or interface with any type of communication, telecommunications, data, cellular, wireless network, and/or other similar types of systems.

UE 112 may be any of a variety of communication devices, including wireless devices configured, configured, and/or operable to communicate wirelessly with network node 110 and other communication devices. Similarly, network node 110 is configured, capable, configured and/or operable to communicate directly or indirectly with UE 112 and/or with other network nodes or devices in telecommunications network 102 to enable and/or provide network access (such as wireless network access) and/or perform other functions (such as management of the telecommunications network 102).

In the example depicted in the figure, core network 106 connects network node 110 to one or more hosts, such as host 116 . These connections may be direct or indirect through one or more intervening networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 106 includes one or more core network nodes (eg, core network node 108 ) structured using hardware and software components. Features of these components may be substantially similar to those described with respect to UEs, network nodes and/or hosts, such that their descriptions may generally apply to corresponding components of core network node 108 . Suitable core network nodes include a Mobile Switching Center (MSC), Mobile Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Server Function (AUSF), Subscriber Identifier Uncloaking Function (SIDF), Unified Data Management (UDM), Secure Edge Protection Proxy (SEPP), Network Exposure Function (NEF) and/or a User Plane Function (UPF) one or more functions.

Host 116 may be under the ownership or control of a service provider other than the operator or provider of access network 104 and/or telecommunications network 102 and may be operated by or on behalf of the service provider. Host 116 may host various applications to provide one or more services. Examples of such applications include live and pre-recorded audio/video content, data collection services (such as capturing and compiling data on various environmental conditions detected by a plurality of UEs), analytics functionality, social media, for control or otherwise interact with remote devices, for an alarm and monitoring center, or any other such function performed by a server.

As a whole, the communication system 100 of FIG. 4 implements connectivity among UEs, network nodes, and hosts. In this sense, a communication system may be configured to operate according to predefined rules or programs, such as specific standards including (but 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 standards (such as 6G); wireless area network (WLAN) standards (such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and/or any other appropriate wireless communication standard (such as 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)).

In some examples, the telecommunications network 102 is a cellular network implementing one of the 3GPP standardized features. Accordingly, the telecommunications network 102 can support network slicing to provide different logical networks to different devices connected to the telecommunications 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 are provided to further UEs.

In some examples, UE 112 is configured to transmit and/or receive information without direct human interaction. For example, a UE may be programmed to transmit information to the access network 104 on a predetermined schedule when triggered by an internal or external event or in response to a request from the access network 104 . Additionally, a UE can be configured to operate in single or multi-RAT or multi-standard modes. For example, a UE may operate with any or a combination of Wi-Fi, NR (New Radio) and LTE (i.e., configured for Multi-Radio Dual Connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC)).

In an example, hub 114 communicates with access network 104 to facilitate indirect communication between one or more UEs (eg, UE 112c and/or 112d ) and a network node (eg, network node 110b ). In some examples, hub 114 may be a controller, router, content source and analysis, or any other communication device described herein with respect to UEs. For example, the hub 114 can be a broadband router that enables UEs to access the core network 106 . As another example, the hub 114 may be a controller that sends commands or instructions to one or more actuators in the UE. Commands or instructions may be received from the UE, network node 110 , or by executable code, scripts, programs, or other instructions in the hub 114 . As another example, hub 114 may be a data collector that acts as a temporary store for UE data, and in some embodiments, may perform analysis or other processing of the data. As another example, hub 114 may be a source of content. For example, for a UE (which is a VR headset, display, speaker, or other media delivery device), the hub 114 may retrieve VR assets, video, audio, or other media related to sensory information via a network node or data, then the hub 114 provides them to the UE directly, after performing local processing and/or after adding additional local content. In yet another example, the hub 114 acts as a proxy or coordinator for a UE, particularly if the UE is one or more low energy IoT devices.

Hub 114 may have a constant/continuous or intermittent connection to network node 110b. Hub 114 may also allow for different communication schemes and/or scheduling between hub 114 and UEs (eg, UE 112c and/or 112d ) and between hub 114 and core network 106 . In other examples, hub 114 is connected to core network 106 and/or one or more UEs via a wired connection. Furthermore, the hub 114 can be configured to connect to an M2M service provider via the access network 104 and/or to another UE via a direct connection. In some scenarios, the UE may establish a wireless connection with the network node 110 while still being connected via a wired or wireless connection via the hub 114 . In some embodiments, hub 114 may be a dedicated hub—ie, a hub whose primary function is to route communications to/from UEs to network node 110b. In other embodiments, the hub 114 may be a non-dedicated hub - i.e., a device operable to route communications between the UE and the network node 110b, but additionally operable as a communication origin for certain data channels and / or endpoint.

Figure 5 shows a UE 200 according to one of some embodiments. As used herein, a UE refers to a device capable of, configured, configured and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smartphone, cellular phone, cellular phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless camera, Game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded equipment (LEE), lap mounted equipment (LME), Smart devices, wireless customer owned equipment (CPE), in-vehicle or in-vehicle embedded/integrated wireless devices, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a Narrowband Internet of Things (NB-IoT) UE, a Machine Type Communication (MTC) UE, and/or an Enhanced MTC (eMTC) UE.

A UE may support device-to-device (D2D) communication, e.g., by implementing a device for side-link communication, dedicated short-range communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) or vehicle-to-everything (V2X) ) One of the 3GPP standards. In other examples, the UE does not necessarily have a user in the sense of a human user who owns and/or operates the associated device. Conversely, a UE may represent a device intended to be sold to or operated by a human user, but which may not or may not be originally associated with a particular human user (e.g., a smart sprinkler controller) . Alternatively, a UE may represent a device (such as a smart power meter) that is not intended to be sold to or operated by an end user but may be associated with or operated for the benefit of a user .

UE 200 includes processing circuitry 202 operably coupled via a bus 204 to an input/output interface 206, a power source 208, a memory 210, a communication interface 212, and/or any other components or any combination thereof . Certain UEs may utilize all of the components or a subset of elements shown in FIG. 5 . The level of integration between components can vary from one UE to another. Furthermore, some UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, and so on.

Processing circuitry 202 is configured to process instructions and data and may be configured to implement any sequential state machine operating to execute as a machine-readable computer program in memory 210 . Processing circuitry 202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), etc.); programmable logic and together with appropriate firmware; one or more stored computer programs, a general purpose processor (such as a microprocessor or digital signal processor (DSP)) together with appropriate software; or any combination of the foregoing). For example, processing circuitry 202 may include multiple central processing units (CPUs).

In examples, input/output interface 206 may be configured to provide one or more 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, a transmitter, a smart card, another output device, or any combination thereof combination. An input device may allow a user to capture information into UE 200 . Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (eg, a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, A directional pad, a touch pad, a scroll wheel, a smart card and the like. Presence sensitive displays may include a capacitive or resistive touch sensor to sense input from a user. A sensor can be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor Measuring devices, etc. or any combination thereof. An output device can use the same type of port as an input device. For example, a Universal Serial Bus (USB) port can be used to provide an input device and an output device.

In some embodiments, the power source 208 is configured as a battery or battery pack. Other types of power sources may be used, such as an external power source (eg, an electrical outlet), photovoltaic devices or power units. The power supply 208 may further include power circuitry for delivering power from the power supply 208 itself and/or an external power source to various parts of the UE 200 via input circuitry or an interface such as a power cable. The delivered power may be used, for example, to charge power source 208 . The power circuitry may perform any formatting, conversion, or other modification of the power from the power supply 208 to make the power suitable for the respective components of the UE 200 to which power is supplied.

Memory 210 may be or be configured to include memory such as random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable Read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, hard disk, removable cartridge, flash drive, etc. In one example, memory 210 includes one or more applications 214 , such as an operating system, web browser application, an interface toolkit, widget engine, or other applications, and corresponding data 216 . Memory 210 may store any of a variety of operating systems or combinations of operating systems for use by UE 200 .

Memory 210 can be configured to include several physical drive units, such as Redundant Array of Independent Disks (RAID), flash memory, USB flash drives, external hard drives, pen drives, pen drives, key drives , High Density Digital Versatile Disc (HD-DVD) Optical Drive, Internal Hard Disk Drive, Blu-ray Disc Drive, Holographic Digital Data Storage (HDDS) Optical Drive, External Mini Dual Inline Memory Module (DIMM), Synchronous Dynamic Random Access Memory (SDRAM), external micro-DIMM SDRAM, smart card memory such as a tamper-resistant module in the form of a Universal Integrated Circuit Card (UICC), containing one or more Subscriber Identity Modules (SIMs) ), such as a USIM and/or ISIM, other memory or any combination thereof. The UICC can be, for example, an embedded UICC (eUICC), integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card." Memory 210 may allow UE 200 to access commands, applications, and the like stored on temporary or non-transitory storage media to offload data or upload data. An article of manufacture, such as utilizing a communication system, may be tangibly embodied as or in memory 210, which may be or include a device-readable storage medium.

Processing circuitry 202 may be configured to communicate with an access network or other network using communication interface 212 . Communication interface 212 may include one or more communication subsystems and may include or be communicatively coupled to an antenna 222 . Communication interface 212 may include, such as by communicating with another device capable of wireless communication, such as another UE in an access network or a network node, by one or more remote transceivers. Each transceiver may include a transmitter 218 and/or a receiver 220 suitable for providing network communications (eg, optical, electrical, frequency distribution, etc.). Furthermore, transmitter 218 and receiver 220 may be coupled to one or more antennas (eg, antenna 222 ) and may share circuit components, software or firmware, or alternatively may be implemented separately.

In the embodiment shown in the figure, the communication function of the communication interface 212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication (such as Bluetooth), near field communication , location-based communication (such as using the Global Positioning System (GPS) to determine a location), another similar communication function, or any combination thereof. Communications may be implemented according to one or more communication protocols and/or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax , Ethernet, Transmission Control Protocol/Internet Protocol (TCP/IP), Synchronous Optical Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

Regardless of the type of sensor, a UE may, through its communication interface 212, provide an output of the data captured by its sensor via a wireless connection to a network node. Data captured by a UE's sensors can be communicated to a network node via another UE over a wireless connection. The output can be periodic (e.g. every 15 minutes if it reports the sensed temperature), random (e.g. to load balance reports from several sensors), respond to a trigger event (e.g. when moisture is detected , sending an alert), in response to a request (eg, a user-initiated request), or a continuous stream (eg, a real-time video feed of a patient).

As another example, a UE includes an actuator, a motor, or a switch associated with a communication interface configured to receive wireless input from a network node via a wireless connection. In response to wireless input received, the state of an actuator, motor or switch may change. For example, a UE may include adjusting control surfaces or rotors of a drone in flight based on received input or adjusting a motor of a robotic arm performing a medical procedure based on received input.

When in the form of an Internet of Things (IoT) device, a UE may be a device for one or more application areas including, but not limited to, urban wearable technology, extended industrial applications, and healthcare. A non-limiting example of such an IoT device is a device that is or is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, a power gauge, a robotic vacuum cleaner, a voice-controlled A smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/humidity sensor, an electric door lock, a connected doorbell, and an air conditioner system (such as a heat pump), an autonomous vehicle, a monitoring system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a ) or virtual reality (VR), a wearable device for tactile enhancement or sensory enhancement, a sprinkler, an animal or object tracking device, a sensory device for monitoring a plant or animal sensors, an industrial robot, an unmanned aerial vehicle (UAV) and any type of medical device, such as a heart rate monitor or a remotely controlled surgical robot. In addition to other components described with respect to UE 200 shown in FIG. 5 , a UE in the form of an IoT device includes circuitry and/or software depending on the intended application of the IoT device.

As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and/or measurement, and transmits the results of such monitoring and/or measurement to another UE and/or A network node. In this case, the UE may be an M2M device, which may be referred to as an MTC device in the context of 3GPP. As a specific example, a UE may implement the 3GPP NB-IoT standard. In other contexts, a UE may represent a vehicle, such as an automobile, an automobile, a truck, a boat, and an airplane, or other equipment capable of monitoring and/or reporting its operating status or other functions associated with its operation.

In practice, any number of UEs can be used together for a single use case. For example, a first UE may be or be integrated in a drone and provide the speed information of the drone (obtained by a speed sensor) to a second UE which is a remote controller operating the drone. When the user changes from the remote controller, the first UE can adjust the throttle on the drone (eg, by controlling an actuator) to increase or decrease the speed of the drone. The first and/or second UE may also include more than one of the above-mentioned functionalities. For example, a UE may include sensors and actuators and handle the communication of data from both the speed sensors and actuators.

FIG. 6 illustrates a network node 300 according to some embodiments. As used herein, a network node refers to a device capable, configured, configured and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, access points (APs) such as radio access points, base stations (BSs) such as radio base stations, Node Bs, evolved Node Bs (eNBs), and NR NodeBs (gNBs) .

Base stations may be classified based on the amount of coverage they provide (or, in other words, their transmission power levels) and thus, may be referred to as femto, pico, micro or macro base stations depending on the coverage provided. A base station may be a relay node controlling a relay or a relay donor node. 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 (RRU), sometimes referred to as remote radio heads (RRH) . These 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).

Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BS, network controllers such as radio network controllers (RNC) or base station control (BSC)), base transceiver station (BTS), transmission point, transmission node, multi-cell/multicast coordination entity (MCE), operation and maintenance (O&M) node, operation support system (OSS) node, ad hoc network On-road (SON) nodes, positioning nodes such as Evolved Services Mobile Location Center (E-SMLC) and/or Minimization of Drive Test (MDT)).

The network node 300 includes a processing circuitry 302 , a memory 304 , a communication interface 306 and a power supply 308 . The network node 300 may consist of multiple physically separate components (eg NodeB component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own respective components. In some scenarios where network node 300 includes multiple individual components (eg, BTS and BSC components), one or both of the individual components may be shared among several network nodes. For example, a single RNC can control multiple NodeBs. In this scenario, in some instances, each unique NodeB and RNC pair can be considered a single separate network node. In some embodiments, the network node 300 can be configured to support multiple radio access technologies (RATs). In these embodiments, some components can be duplicated (eg, separate memory 304 for different RATs) and some components can be reused (eg, a same antenna 310 can be shared by different RATs). The network node 300 may also include different wireless technologies for integration into the network node 300 (for example, GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID) or Bluetooth wireless technology ) of multiple sets of components shown in various figures. These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 300 .

Processing circuitry 302 may include a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or hardware One or more of a combination of, software, and/or coded logic, alone or in combination with other network node 300 components, such as memory 304, to provide network node 300 functionality.

In some embodiments, processing circuitry 302 includes a system on chip (SOC). In some embodiments, processing circuitry 302 includes one or more of radio frequency (RF) transceiver circuitry 312 and baseband processing circuitry 314 . In some embodiments, radio frequency (RF) transceiver circuitry 312 and baseband processing circuitry 314 may be located on separate chips (or chipsets), boards, or units such as a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuitry 312 and baseband processing circuitry 314 may be located on the same die or chipset, board or unit.

Memory 304 may comprise any form of volatile or non-volatile computer readable memory, including (but not limited to) persistent storage, solid state memory, remote mount memory, magnetic media, optical media, random access memory memory (RAM), read-only memory (ROM), mass storage media (e.g., a hard disk), removable storage media (e.g., a flash drive, a compact disc (CD) or a digital disc (DVD) ) and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory device that stores information, data, and/or instructions that may be used by the processing circuitry 302. Memory 304 may store any suitable instructions, data, or information, including one of a computer program, software, including logic, rules, codes, tables, and/or other instructions executable by processing circuitry 302 and utilized by network node 300 or one of more applications. Memory 304 may be used to store any calculations performed by processing circuitry 302 and/or any data received via communication interface 306 . In some embodiments, processing circuitry 302 is integrated with memory 304 .

The communication interface 306 is used for wired or wireless communication of signaling and/or data between a network node, an access network and/or a UE. As shown, communication interface 306 includes port(s)/terminal(s) 316 to send and receive data to and from a network, eg, via a wired connection. Communication interface 306 also includes radio front-end circuitry 318 that may be coupled to antenna 310 or, in some embodiments, a portion of antenna 310 . Radio front-end circuitry 318 includes filter 320 and amplifier 322 . Radio front-end circuitry 318 may be connected to an antenna 310 and processing circuitry 302 . Radio front-end circuitry may be configured to condition signals communicated between antenna 310 and processing circuitry 302 . RFE circuitry 318 may receive digital data to be sent to other network nodes or UEs via a wireless connection. Radio front-end circuitry 318 may use a combination of filter 320 and/or amplifier 322 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. Then, a radio signal may be transmitted via the antenna 310 . Similarly, when receiving data, antenna 310 may collect radio signals that are then converted to digital data by radio front-end circuitry 318 . The digital data may be passed to processing circuitry 302 . In other embodiments, the communication interface may include different components and/or different combinations of components.

In some alternative embodiments, network node 300 does not include separate radio front-end circuitry 318 , instead processing circuitry 302 includes radio front-end circuitry and is connected to antenna 310 . Similarly, all or some of the RF transceiver circuitry 312 is part of the communication interface 306 in some embodiments. In other embodiments, communication interface 306 includes one or more ports or terminals 316, radio front-end circuitry 318, and RF transceiver circuitry 312 as part of a radio unit (not shown), and communication interface 306 communicates with the base The video processing circuit 314 (which is part of a digital bit cell (not shown)) communicates.

Antenna 310 may include one or more antennas or antenna arrays configured to transmit and/or receive wireless signals. Antenna 310 may be coupled to radio front-end circuitry 318 and may be any type of antenna capable of wirelessly transmitting and receiving data and/or signals. In some embodiments, the antenna 310 is separate from the network node 300 and can be connected to the network node 300 through an interface or port.

Antenna 310, communication interface 306, and/or processing circuitry 302 may be configured to perform any receive operations and/or certain obtain operations described herein as being performed by a network node. Any information, data and/or signals may be received from a UE, another network node and/or any other network device. Similarly, antenna 310, communication interface 306, and/or processing circuitry 302 may be configured to perform any of the transmission operations described herein as being performed by a network node. Any information, data and/or signals may be transmitted to a UE, another network node and/or any other network device.

The power supply 308 provides power to the various components of the network node 300 in a form suitable for the respective components, eg, at a voltage and current level required by each respective component. Power supply 308 may further include or be coupled to power management circuitry to supply power to components of network node 300 for performing the functionality described herein. For example, network node 300 may be connected to an external power source (eg, grid, an electrical outlet) via an input circuitry or interface (such as a cable), whereby the external power source supplies power to the power circuitry of power source 308 . As a further example, power source 308 may include a source of electrical power in the form of a battery or battery pack connected to or integrated in the power circuitry. Batteries provide backup power in the event of external power failure.

Embodiments of the network node 300 may include additional components beyond those shown in FIG. 6 for providing certain aspects of the functionality of the network node, including any of the functionality described herein and/or Any functionality necessary to support the objectives described herein. For example, the network node 300 may include user interface equipment to allow information to be input into the network node 300 and to allow information to be output from the network node 300 . This may allow a user to perform diagnostics, maintenance, repair and other management functions on the network node 300 .

FIG. 7 is a block diagram of a host 400 , which may be an embodiment of the host 116 of FIG. 4 , according to various aspects described herein. As used herein, host 400 can be or include various combinations of hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container Or processing resources in a server farm. The host 400 can provide one or more services to one or more UEs.

Host 400 includes processing circuitry 402 operably coupled to an input/output interface 406 , a network interface 408 , a power source 410 , and a memory 412 via a bus bar 404 . Other components may be included in other embodiments. The features of these components may be substantially similar to those described with respect to the devices of previous figures, such as FIGS. 2 and 3 , such that their descriptions may generally apply to corresponding components of host 400 .

Memory 412 may include one or more host applications 414 and data 416 (which may include user data such as data generated by a UE for a host 400 or data generated by a host 400 for a UE) a computer program. Embodiments of host 400 may utilize only a subset or all of the components shown in the figure. Host application 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 (such as FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including multiple implementations of different types, types or UEs (such as mobile phones, desktop computers, wearable display systems , head-up display system) transcoding. Host application 414 can also provide user authentication and authorization checks and can periodically report health, routing and content availability to a central node (such as a device in a core network or on the edge). Therefore, the host 400 may select and/or indicate a different host for a UE's cloud service. The host application 414 can support various protocols, such as HTTP Real Time Streaming (HLS) protocol, Real Time Messaging Protocol (RTMP), Real Time Streaming Protocol (RTSP), HTTP Dynamic Adaptive Streaming (MPEG-DASH) and so on.

FIG. 8 is a block diagram illustrating a virtualization environment 500 in which functions implemented by some embodiments may be virtualized. In this context, virtualization means creating a virtual version of a device or device, which may include virtualizing hardware platforms, storage devices, and network resources. As used herein, virtualization may apply to any device or component thereof described herein, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as one of the functions carried by one or more of a hardware node, such as a hardware computing device operating as a network node, UE, core network node, or host. One or more virtual machines (VMs) execute virtual components implemented in one or more virtual environments 500 . Furthermore, in embodiments where the virtual node does not require radio connectivity (eg, a core network node or host), then the node can be fully virtualized.

Applications 502 (alternatively referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some features, functions of some embodiments disclosed herein and/or benefits.

Hardware 504 includes processing circuitry, memory storing software and/or instructions executable by the hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, etc. . software executable by the processing circuitry to instantiate one or more virtualization layers 506 (also referred to as a hypervisor or virtual machine monitor (VMM)), provide VMs 508a and 508b (one or more of which are commonly referred to as VM 508), and and/or perform any of the functions, features and/or benefits described in connection with some of the embodiments described herein. The virtualization layer 506 can present to the VM 508 a virtual operating platform that looks like network hardware.

VM 508 includes virtual processing, virtual memory, virtual network or interface, and virtual storage, and can be run by a corresponding virtualization layer 506 . Different embodiments of an instance of virtual appliance 502 may be implemented on one or more of VMs 508, and implementations may be implemented in different ways. Virtualization of hardware is referred to in some contexts as Network Functions Virtualization (NFV). NFV can 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 premises equipment).

In the context of NFV, VM 508 may be a software implementation of a physical machine as if it were running programs on a physical, non-virtualized machine. Each of VM 508 and the portion of hardware 504 executing that VM (whether dedicated hardware dedicated to that VM and/or hardware shared by that VM with other VMs) form a separate virtual network element. Still in the context of NFV, a virtual network function is responsible for handling specific network functions running in one or more VMs 508 on top of hardware 504 and corresponding to applications 502 .

Hardware 504 may be implemented in a separate network node with generic or specific components. Hardware 504 may implement some functions via virtualization. Alternatively, hardware 504 may be part of a larger hardware cluster (eg, such as in a data center or CPE), where many hardware nodes work together and are managed via management and orchestration 510, which (among other things) Monitor the life cycle management of the application 502 . In one embodiment, hardware 504 is coupled to one or more radios each including one or more transmitters and one or more receivers that may be coupled to one or more antennas. The radio unit can communicate directly with other hardware nodes via one or more suitable network interfaces and can be used in combination with virtual components to provide radio capabilities to a virtual node, such as a radio access node or a base station. In some embodiments, some signaling may be provided using a control system 512 that is alternatively used for communication between hardware nodes and radio units.

FIG. 9 shows a communication diagram of a host 602 communicating with a UE 606 via a network node 604 via a portion of a wireless connection, according to some embodiments.

The UE (such as the UE 112a of FIG. 4 and/or the UE 200 of FIG. 5 ), the network node (such as the network node 110a of FIG. 4 and/or the UE 200 of FIG. 4 ) discussed in the preceding paragraphs according to various embodiments will now be described with reference to FIG. or network node 300 of FIG. 6) and a host (such as host 116 of FIG. 4 and/or host 400 of FIG. 7).

Like host 400, embodiments of host 602 include hardware, such as a communications interface, processing circuitry, and memory. Host 602 also includes software stored in or accessible by host 602 and executable by processing circuitry. The software includes a host application operable to provide a service to a remote user, such as UE 606 connected via an over-the-cloud (OTT) connection 650 extending between UE 606 and host 602 . In providing services to remote users, a host application may provide user data transmitted using the OTT connection 650 .

Network node 604 includes hardware that enables it to communicate with host 602 and UE 606 . Connection 660 may be direct or through a core network (such as core network 106 of FIG. 4 ) and/or one or more other intermediate networks, such as one or more public, private, or host networks. For example, an intermediate network can be a backbone network or the Internet.

UE 606 includes hardware and software stored in or accessible by UE 606 and executable by the UE's processing circuitry. The software includes a client application, such as a web browser or an operator-specific "application" operable with the support of host 602 to provide a service to a human or non-human user via UE 606. In the host 602 , an executing host application can communicate with an executing client application via the OTT connection 650 terminating at the UE 606 and the host 602 . In providing services to a user, a client application of the UE may receive request data from a host application of the host and provide user data in response to the request data. OTT connection 650 can transmit both request data and user data. The client application of the UE can interact with the user to generate user data that it provides to the host application through the OTT connection 650 .

The OTT connection 650 may extend via a connection 660 between the host 602 and the network node 604 and via a wireless connection 670 between the network node 604 and the UE 606 . Connection 660 and wireless connection 670 over which OTT connection 650 may be provided have been drawn abstractly to illustrate communication between host 602 and UE 606 via network node 604 without explicit reference to any intermediary devices and messages via such devices the precise route.

As an example of transferring data over the OTT connection 650, in step 608 the host 602 provides user data, which may be performed by executing a host application. In some embodiments, the user profile is associated with a particular human user interacting with the UE 606 . In other embodiments, user profile is associated with one UE 606 that shares profile with host 602 without explicit human interaction. In step 610, the host 602 initiates a transmission towards the UE 606 carrying user data. Host 602 may initiate a transmission in response to a request transmitted by UE 606 . The request may result from human interaction with the UE 606 or from the operation of a client application executing on the UE 606 . Transmissions may pass through network node 604 in accordance with the teachings of embodiments described throughout this disclosure. Thus, in step 612 , network node 604 transmits to UE 606 the user data carried in the transmission initiated by host 602 in accordance with the teachings throughout embodiments of the present invention. In step 614 , the UE 606 receives the user data carried in the transmission, which may be executed by a client application executing on the UE 606 associated with the host application executed by the host 602 .

In some examples, UE 606 executes a client application that provides user data to host 602 . User data may be provided in response to data received from host 602 . Accordingly, in step 616, UE 606 may provide user data, which may be performed by executing a client application. When providing user information, the client application may further consider user input received from the user via an input/output interface of the UE 606 . Regardless of the particular manner in which the user data is provided, UE 606 initiates transmission of user data towards host 602 via network node 604 in step 618 . In step 620 , network node 604 receives user data from UE 606 and initiates transmission of the received user data toward host 602 in accordance with the teachings of embodiments described throughout this disclosure. In step 622, the host 602 receives the user data carried in the transmission initiated by the UE 606.

One or more of the various embodiments improve the performance of OTT services provided to UE 606 using OTT connection 650, with wireless connection 670 forming the final segment. More precisely, the teachings of these embodiments may modify, for example, one or more of data rate, latency, and/or power consumption, and thereby provide benefits such as, for example, reduced user latency, relaxed file Size limitations, improved content resolution, better responsiveness and/or improved battery life.

In an example scenario, plant status information may be collected and analyzed by host 602 . As another example, the host 602 can process audio and video data retrieved from a UE for generating maps. As another example, the host 602 can collect and analyze real-time data to assist in controlling vehicle congestion (eg, controlling traffic lights). As another example, the host 602 may store surveillance video uploaded by a UE. As another example, host 602 may store or control access to media content, such as video, audio, VR or AR, which may be broadcast, multicast or unicast to UEs. As other examples, the host 602 can be used for energy pricing, remote control of non-time-critical electrical loads to balance generation needs, location services, rendering services (such as compiling maps from data collected from remote devices, etc.), or for collecting, retrieving Any other functions for acquiring, storing, analyzing and/or transmitting data.

In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors for one or more implementation improvements. There may further be an optional network functionality for reconfiguring the OTT connection 650 between the host 602 and the UE 606 in response to changes in the measurement results. Measurement procedures and/or network functionality for reconfiguring OTT connections may be implemented in the software and hardware of the host 602 and/or UE 606 . In some embodiments, sensors (not shown) may be deployed in or associated with other devices through which the OTT connection 650 passes; The software can calculate or estimate the value of other physical quantities of the monitored quantity to participate in the measurement process. Reconfiguration of OTT connection 650 may include message format, retransmission settings, better routing, etc.; reconfiguration does not require direct changes to network node 604 operations. Such procedures and functionality are known and practiced in the art. In some embodiments, the measurements may involve dedicated UE signaling that facilitates measurements by the host 602 of throughput, propagation time, latency, and the like. Measurements can be implemented in software using the OTT connection 650 to cause message transmissions (specifically empty or "false" messages) while monitoring propagation time, errors, etc.

Although computing devices (eg, UEs, network nodes, hosts) described herein may include combinations of hardware components as depicted in the figures, other embodiments may include computing devices having different combinations of components. It should be understood that such computing devices may include any suitable combination of hardware and/or software required to perform the tasks, features, functions and methods disclosed herein. Determinations, calculations, obtaining or similar operations herein may be performed by, for example, converting obtained information into other information, comparing obtained or transformed information with information stored in network nodes and/or based on Processing circuitry that performs one or more operations on the obtained or transformed information is performed, and as a result of the processing, a decision is made. Furthermore, although components are depicted as a single box within a larger box or nested within multiple boxes, in practice a computing device may include multiple distinct physical components that make up the depicted components in a single figure , and functionality can be divided between separate components. For example, a communications interface can be configured to include any of the components described herein, and/or the functionality of the components can be divided between processing circuitry and the communications interface. In another example, the non-computationally intensive functions of any of these components may be implemented in software or firmware and the computationally intensive functions may be implemented in hardware.

In some embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored in memory, which in some embodiments may be in the form of a non-transitory computer-readable storage medium One of the forms is a computer program product. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry rather than executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of these particular embodiments, the processing circuitry can be configured to perform the described functionality whether or not executing instructions stored on a non-transitory computer-readable storage medium. The benefits provided by this functionality are not limited to the processing circuitry or other components of the computing device, but are shared by the computing device as a whole and/or by the end user and a wireless network.

Figure 10 illustrates an example method 700 for facilitating long UL transmissions in IoT NTN by a UE 112, 200, according to certain embodiments. The method starts at step 702, wherein the UE transmits to a network node 110, 300 information for determining whether the UE is to insert at least one gap between adjacent transmission segments in at least one UL transmission. At step 704, the UE 112, 200 receives from the network node 110, 300 information configuring the UE 112, 300 to when transmitted to the network node 110, 300 indicates to discard and/or puncture at least one symbol, slot and / or sub-frame to insert configuration information of at least one gap when performing segment pre-compensation. Alternatively, the configuration information configures the UE 112, 200 to not insert at least one gap when the information transmitted to the network node 110, 300 indicates that at least one sample is to be discarded and/or punctured for segment precompensation.

In a specific embodiment, when the UE is to be inserted into the at least one gap, the information indicates that the UE is a type A UE or when the UE is not to be inserted into the at least one gap, the information indicates that the UE is a type B UE .

In a particular embodiment, when the UE is to insert the at least one gap, the information indicates a gap duration or a range of gap durations that can be inserted between the adjacent transmission segments.

In a particular embodiment, when the UE is to be inserted into the at least one gap, the information indicates a number of symbols, slots and/or subframes to be discarded and/or punctured for segment precompensation.

In a particular embodiment, the information includes capability information associated with the UE.

In a specific embodiment, the UE is to be inserted into the at least one gap, and the information indicates that the at least one gap will be inserted for a specific type of transmission and/or a specific type of physical channel.

In a specific embodiment, the specific type of physical channel is a PUSCH, PUCCH or (N)PUSCH.

In a particular embodiment, when the UE is to insert the at least one gap, the information indicates that for each transmission having a duration higher than a threshold duration, the adjacent transmission segments are to be inserted between the adjacent transmission segments. At least one gap, or for each transmission of a certain duration, will be inserted between the adjacent transmission segments.

In a particular embodiment, the information indicates a particular type of NTN and the configuration information configures the UE to insert the at least one between adjacent transmission segments for each transmission associated with the particular type of NTN gap.

In a particular embodiment, the NTN of the particular type is low earth orbit or medium earth orbit.

In a particular embodiment, the information indicates a timing advance, and when the timing advance is increased, the UE inserts the at least one gap between adjacent transmission segments in at least one uplink transmission, or when the timing advances When decreasing, the UE decides not to insert the at least one gap between adjacent transmission segments in the at least one uplink transmission.

In a specific embodiment, the information indicates a location of the UE.

Figure 11 illustrates an example method 800 used by a network node 110, 300 to facilitate long UL transmissions in the IoT NTN, according to certain embodiments. The method package also takes the network node 110, 300 at step 802 and receives from a UE (112, 200) a method for determining whether the UE is to insert at least one gap between adjacent transmission segments in at least one uplink transmission Information. At step 804, based on the information, the network node 110, 300 configures the UE to Insert at least one gap. Alternatively, the network node 110, 300 configures the UE to not insert at least one gap when the information indicates that at least one sample is to be discarded and/or punctured for segment precompensation.

In a particular embodiment, the network node 110, 300 determines that the UE is a Type A UE when the information indicates that the UE is to be inserted into at least one gap, or the network node determines that the UE is a Type A UE when the information indicates that the UE is not to be inserted into at least one gap. A Type B UE.

In a particular embodiment, when the UE is to insert the at least one gap, the information indicates a gap duration or a range of gap durations to be inserted between the adjacent transmission segments.

In a particular embodiment, when the UE is to be inserted into the at least one gap, the information indicates a number of symbols, slots and/or subframes to be discarded and/or punctured for segment precompensation.

In a particular embodiment, the information includes capability information associated with the UE.

In a specific embodiment, the information indicates a specific type of transmission and/or a specific type of physical path, and the network node determines that the at least one gap will be based on the specific type of transmission and/or the specific type of physical channels are inserted between the adjacent transport segments.

In a specific embodiment, the specific type of physical channel is a PUSCH, PUCCH or (N)PUSCH.

In a particular embodiment, the information includes a duration and the network node determines that for each transmission having a duration higher than a threshold duration, the at least one gap is to be inserted between the adjacent transmission segments , or for each transmission of the specified duration, the network node determines that the at least one gap is to be inserted between the adjacent transmission segments.

In a particular embodiment, the information indicates a particular type of NTN, and the network node determines that for each transmission associated with the particular type of NTN, the at least one gap is to be inserted between the adjacent transmission segments.

In a particular embodiment, the NTN of the particular type is low earth orbit or medium earth orbit.

In a particular embodiment, the information indicates a timing advance, and when the timing advance increases, the network node decides to insert the at least one gap between adjacent transmission segments in at least one uplink transmission, or When the timing advance decreases, the network node determines not to insert the at least one gap between adjacent transmission segments in the at least one uplink transmission.

In a specific embodiment, the information indicates a location of the UE.

Example embodiment A group example embodiment Example Embodiment Al. A method for facilitating long uplink transmissions in an IoT NTN by a user equipment, the method comprising: any of the user equipment steps, features or functions described above, alone or in combination with other steps, features or functions described above combination. Example Embodiment A2. As in the method of the previous embodiment, it further includes the above-mentioned one or more additional user equipment steps, features or functions. Example Embodiment A3. The method of any one of the previous embodiments, further comprising: providing user data; and forwarding the user data to a host computer via the transmission to the network node.

Group B example embodiment Example Embodiment B1. A method performed by a network node for facilitating long uplink transmissions in an IoT NTN, the method comprising: any of the above-mentioned network node steps, features or functions, alone or in combination with the above-mentioned other steps, features or a combination of functions. Example Embodiment B2. The method according to any one of the previous embodiments, further comprising one or more additional network node steps, features or functions described above. Example Embodiment B3. The method according to any one of the previous embodiments, further comprising: obtaining user data; and forwarding the user data to a host or a user device.

Group C example embodiment Example Embodiment C1. A method by a user equipment (UE) for facilitating long uplink transmissions in IoT NTN, the method comprising: communicating with a network node information for determining whether the UE is in at least one uplink transmission Information of at least one gap is inserted between adjacent transmission segments. Example embodiment C2a. The method of example embodiment C1, wherein communicating the information includes transmitting the information to the network node. Example Embodiment C2b. The method as in any one of example embodiments C1 to C2a, wherein the information indicates that the UE is a type A UE or a type B UE. Example embodiment C3. The method of example embodiment C1, wherein communicating the information includes receiving the information from the network node. Example embodiment C4. The method as in any one of example embodiments C1 to C3, wherein the information indicates a gap duration or a range of gap durations to be inserted between the adjacent transmission segments. Example embodiment C5. The method as in any one of example embodiments C1 to C4, wherein the information indicates a number of samples, symbols, slots, subframes and/or resource units to be discarded and/or punctured for segment precompensation. Example embodiment C6. The method as in any one of example embodiments C1 to C5, wherein the information includes capability information associated with the UE. Example Embodiment C7. The method of any of example embodiments C1 to C6, wherein the information indicates the at least one gap to be inserted for a particular type of transmission and/or a particular type of physical channel. Example embodiment C8. The method of any one of example embodiments C1 to C7, wherein the information indicates that for each transmission having a duration higher than a threshold duration, the at least one gap will be inserted between the adjacent transmission segments . Example embodiment C9. The method as in any one of example embodiments C1 to C8, wherein the information indicates that for each transmission having a particular duration, the at least one gap is to be inserted between the adjacent transmission segments. Example embodiment C10. The method as in any one of example embodiments C1 to C9, wherein the information indicates that for each transmission having a particular duration, the at least one gap is to be inserted between the adjacent transmission segments. Example Example C11. The method of any one of example embodiments C1 to C10, wherein the information indicates a particular type of NTN, and the UE is configured to, for each transmission associated with the particular type of NTN, between the adjacent transmissions The at least one gap is inserted between the segments. Example embodiment C12. The method of any of example embodiments C1-C11, wherein the information indicates a timing advance. Example embodiment C13. The method of example embodiment C12, wherein the UE is configured to insert the at least one gap between adjacent transmission segments in at least one uplink transmission based on the timing advance increase or decrease. Example embodiment C14. The method as in any one of example embodiments C1 to C13, wherein the information indicates a location of the UE. Example embodiment C15. The method of example embodiment C14, further comprising: determining a timing advance increase or decrease associated with the UE based on the location of the UE, and wherein the UE is configured to increase or decrease in timing advance based on the timing advance increase or decrease The at least one gap is inserted between adjacent transmission segments in at least one uplink transmission. Example embodiment C16. The method as in any one of example embodiments C12 to C15, wherein the UE is configured to insert the at least one between adjacent transmission segments in the at least one uplink transmission when the timing advance increases gaps, and wherein the UE is configured not to insert the at least one gap between the adjacent transmission segments in the at least one uplink transmission when the timing advance is not increased or decreased. Example embodiment C17. The method of example embodiments C1 to C16, further comprising: providing user data; and forwarding the user data to a host via the transmission to the network node. Example embodiment C18. A user equipment comprising processing circuitry configured to perform any of the methods of example embodiments C1-C17. Example embodiment C19. A wireless device comprising processing circuitry configured to perform any of the methods of example embodiments C1-C17. Example embodiment C20. A computer program comprising instructions for performing any of the methods of example embodiments C1 to C17 when executed on a computer. Example embodiment C21. A computer program product comprising a computer program comprising instructions for performing any of the methods of example embodiments C1 to C17 when executed on a computer. Example embodiment C22. A non-transitory computer-readable medium storing instructions that, when executed by a computer, perform any of the methods of example embodiments C1-C17.

Group D example embodiment Example Embodiment D1. A method by a network node for facilitating long uplink transmissions in IoT NTN, the method comprising: communicating with a user equipment (UE) information for determining whether the UE is in at least one uplink transmission Information of at least one gap is inserted between adjacent transmission segments. Example Embodiment D2a. The method of example embodiment D1, wherein communicating the information includes receiving the information from the UE. Example Embodiment D2b. The method as in any one of example embodiments D1 to D2a, wherein the information indicates that the UE is a type A UE or a type B UE. Example Embodiment D3. The method of example embodiment D1, wherein communicating the information includes transmitting the information to the UE. Example Embodiment D4. The method as in any one of example embodiments D1 to D3, wherein the information indicates a gap duration or a range of gap durations to be inserted between the adjacent transmission segments. Example Embodiment D5. The method as in any one of example embodiments D1 to D4, wherein the information indicates a number of samples, symbols, slots, subframes and/or resource units to be discarded and/or punctured for segment precompensation. Example Embodiment D6. The method as in any one of example embodiments D1 to D5, wherein the information comprises capability information associated with the UE. Example Embodiment D7. The method of any one of example embodiments D1 to D6, wherein the information indicates a specific type of transmission and/or a specific type of physical channel, and the method further comprises based on the specific type of transmission and/or the specific type The at least one gap is to be inserted between the adjacent transmission segments according to the physical channel. Example Embodiment D8. The method of any one of example embodiments D1 to D7, wherein the information includes a duration, and the method further comprises determining that for each transmission having a duration higher than a threshold duration, the The at least one gap is inserted between adjacent transmission segments. Example Embodiment D9. The method of any one of example embodiments D1 to D7, wherein the information includes a duration, and the method further comprises determining that for each transmission having the particular duration, the at least one gap. Example Embodiment D10. The method as in any one of example embodiments D1 to D9, wherein the information indicates that the UE will insert the at least one gap between the adjacent transmission segments for each transmission having a specific duration. Example Embodiment D11. The method of any one of example embodiments D1 to D10, wherein the information indicates a particular type of NTN, and the method further comprises determining that, for each transmission associated with the particular type of NTN, the adjacent transmissions will be The at least one gap is inserted between the segments. Example Embodiment D12. The method of any one of example embodiments D1 to D11, wherein the information indicates a timing advance. Example Embodiment D13. The method of example embodiment D12, further comprising: determining the timing advance increase or decrease, and based on the timing advance increase or decrease, determining to insert the at least one gap. Example Embodiment D14. The method as in any one of example embodiments D1 to D13, wherein the information indicates a location of the UE. Example Embodiment D15. The method of example embodiment D14, further comprising: determining a timing advance increase or decrease associated with the UE based on the location of the UE, and determining whether the at least one gap is to be inserted based on the timing advance increase or decrease Between adjacent transmission segments in at least one uplink transmission. Example Embodiment D16. The method of any one of example embodiments D12 to D15, wherein the UE is configured to insert the at least one gap between the adjacent transmission segments in the at least one uplink transmission when the timing advance is increased , and wherein the UE is configured not to insert the at least one gap between the adjacent transmission segments in the at least one uplink transmission when the timing advance is not increasing or decreasing. Example Embodiment D17. The method of any one of example embodiments D1 to D16, wherein the network node comprises a gNodeB (gNB). Example Embodiment D18. The method according to any one of the previous example embodiments, further comprising: obtaining user data; and forwarding the user data to a host or a user device. Example Example D19. A network node comprising processing circuitry configured to perform any of the methods of example embodiments Dl-D18. Example Embodiment D20. A computer program comprising instructions for performing any of the methods of example embodiments D1 to D18 when executed on a computer. Example Embodiment D21. A computer program product comprising a computer program comprising instructions for performing any of the methods of example embodiments D1 to D18 when executed on a computer. Example Embodiment D22. A non-transitory computer readable medium storing instructions that, when executed by a computer, perform any of the methods of example embodiments D1 to D18.

Group E example embodiment Example Embodiment El. A user equipment for facilitating long uplink transmissions in an IoT NTN, the user equipment comprising: processing circuitry configured to perform any of the steps of any of sets A and C of example embodiments ; and power supply circuitry configured to supply power to the processing circuitry. Example Embodiment E2. A network node for facilitating long uplink transmissions in an IoT NTN, the network node comprising: processing circuitry configured to perform the steps of any one of sets B and D of example embodiments; a power supply A controller circuit configured to supply power to the processing circuitry. Example embodiment E3. A user equipment (UE) for facilitating long uplink transmissions in an IoT NTN, the UE comprising: an antenna configured to transmit and receive wireless signals; radio front-end circuitry connected to the antenna and processing circuitry configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry configured to perform any of the steps of any of Groups A and C of example embodiments or; an input interface connected to the processing circuitry and configured to allow information to be input into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output from the UE information that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE. Example Embodiment E4. A host configured to operate in a communication system to provide an over-the-cloud (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured To initiate transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and processing circuitry, the communication interface and processing circuitry of the UE are assembled state to perform any of the steps of any of sets A and C of example embodiments to receive the user data from the host. Example Embodiment E5. The host as in the previous example embodiment, wherein the cellular network further comprises a network node configured to communicate with the UE to transmit the user data from the host to the UE. Example Embodiment E6. The host as in the previous two example embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to communicate with the UE executed A client application interacts, the client application being associated with the host application. Example Embodiment E7. A method implemented by a host operating in a communication system further comprising a network node and a user equipment (UE), the method comprising: providing user data to the UE; and via a network node comprising the network node A cellular network initiates a transmission carrying the user data to the UE, wherein the UE performs any of the operations of any of group A embodiments to receive the user data from the host. Example Embodiment E8. The method as in the previous example embodiment, further comprising: at the host, executing a host application associated with a client application executed on the UE to receive the user profile from the UE. Example Embodiment E9. The method of the previous example embodiment, further comprising: at the host, transmitting input data to the client application executing on the UE, providing the input data by executing the host application, wherein a response from the host The user data is provided by the client application for the input data of the application. Example Embodiment E10. A host configured to operate in a communication system to provide an over-the-cloud (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured To initiate transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and processing circuitry, the communication interface and processing circuitry of the UE are assembled state to perform any of the steps of any of Groups A and C of example embodiments to transmit the user data to the host. Example Embodiment E11. The host as in the previous example embodiment, wherein the cellular network further comprises a network node configured to communicate with the UE to transmit the user data from the UE to the host. Example Embodiment E12. The host as in the previous two example embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to execute with the UE interact with a client application associated with the host application. Example Embodiment E13. A method implemented by a host configured to operate in a communication system further comprising a network node and a user equipment (UE), the method comprising: at the host, receiving A road node transmits user data to the host, wherein the UE performs any of the steps of any of sets A and C of example embodiments to transmit the user data to the host. Example Embodiment E14. The method as in the previous example embodiment, further comprising: at the host, executing a host application associated with a client application executed on the UE to receive the user data from the UE. Example Embodiment E15. The method of the previous example embodiment, further comprising: at the host, transmitting input data to the client application executing on the UE, providing the input data by executing the host application, wherein a response from the host For the input data of the application, the user data is provided by the client application. Example Embodiment E16. A host configured to operate in a communication system to provide an over-the-cloud (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured To initiate transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and processing circuitry, the network node having the Processing circuitry is configured to perform any of the operations of any of Groups B and D of example embodiments to transmit the user data from the host to the UE. Example Embodiment E17. The host as in the previous example embodiment, wherein: the processing circuitry of the host is configured to execute a host application providing the user data; and the UE includes a user configured to execute a user associated with the host application The processing circuitry used by the end application to receive transmissions of user data from the host. Example Embodiment E18. A method implemented in a host configured to operate in a communication system further comprising a network node and a user equipment (UE), the method comprising: providing user data to the UE; A cellular network of the network node initiates a transmission carrying the user data write to the UE, wherein the network node performs any of the operations of any of sets B and D of example embodiments to transmit the user data from the host to the UE. Example Embodiment E19. The method as in the previous example embodiment, further comprising, at the network node, transmitting the user data provided by the host for the UE. Example Embodiment E20. The method of any one of the previous 2 example embodiments, wherein the user profile is provided at the host by executing a host application that interacts with a client application executing on the UE, the client application interacting with the UE The host application is associated. Example Embodiment E21. A communication system configured to provide a service on the cloud, the communication system includes: a host, including: processing circuitry configured to provide user data for a user equipment (UE), the user data and the cloud service is associated; and a network interface configured to initiate transmission of the user data towards a cellular network node for transmission to the UE, the network node having a communication interface and processing circuitry, The processing circuitry of the network node is configured to perform any of the operations of any of sets B and D of example embodiments to transmit the user data from the host to the UE. Example Embodiment E22. According to the communication system of the previous example embodiment, it further includes: the network node; and/or the user equipment. Example Embodiment E23. A host configured to operate in a communication system to provide an over-the-cloud (OTT) service, the host comprising: processing circuitry configured to initiate receipt of user data; and a network interface that configured to receive the user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node being configured to perform B Any of the operations of any of Groups and Groups D example embodiments to receive the user data from a user equipment (UE) of the host. Example Embodiment E24. The host as in the previous two example embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to communicate with the UE executed A client application interacts, the client application being associated with the host application. Example Embodiment E25. The host as in any one of the preceding two example embodiments, wherein initiating receipt of the user data includes requesting the user data. Example embodiment E26. A method implemented by a host configured to operate in a communication system further comprising a network node and a user equipment (UE), wherein the network node executes any of Groups B and D of example embodiments or any of the steps to receive the user data of the host from the UE. Example Embodiment E27. As in the method of the previous example embodiment, it further includes, at the network node, transmitting the received user data to the host.

Group F example embodiment Example Embodiment F1. A method by a user equipment (UE) for facilitating long uplink transmissions in eMTC NTN, the method comprising: receiving information indicative of a transmission segment duration from a network node. Example Embodiment F2. The method of example embodiment F1, wherein the transmission segment duration includes a maximum number of repetitions of at least one transmission segment. Example Embodiment F3. The method as in any one of example embodiments F1 to F2, wherein the at least one transmission segment is for transmission on a physical uplink control channel (PUCCH). Example Embodiment F4. The method of example embodiment F1, wherein the PUCCH includes an eMTC PUCCH. Example Embodiment F5. The method of any of example embodiments F1 to F4, wherein the information indicates at least one K value of the transmission segment duration using a k-bit field, wherein the value differs depending on the CE mode: CE Mode A: 1-bit field for indicating K = 2 candidate values: {2, 4} (unit: subframe), and/or CE mode B: 3-bit field for indicating K = 5 candidate values: {4 , 8, 16, 32, 64} (unit: subframe). Example Embodiment F6. The method as in any one of example embodiments F1 to F5, wherein the information does not indicate a value of the transmission segment duration of a PUCCH. Example Embodiment F7. The method of example embodiment F6, further comprising determining not to perform segment precompensation for the at least one transmission segment based on the information not indicating a value for the transmission segment duration of the PUCCH. Example Embodiment F8. The method as in any one of example embodiments F1 to F5, wherein the information indicates a value of the transmission segment duration of a PUCCH. Example Embodiment F9. The method of example embodiment F8, further comprising performing segment precompensation on the at least one transmission segment based on the information indicative of the value of the transmission segment duration of the PUCCH. Example Embodiment F10. The method of any one of example embodiments F1 to F9, further comprising determining not to perform segment precompensation for the at least one transmission segment of the PUCCH based on the information. Example Embodiment F11. The method of example embodiment F10, wherein the information indicates at least one K value of the transmission segment duration using a k-bit field, wherein the value differs depending on the CE mode: CE Mode A: 2-bit field for Indicate K = 3 candidate values: {2, 4, 8} (unit: subframe); or CE mode B: 3-bit column is used to indicate K = 6 candidate values: {4, 8, 16, 32 , 64, 128} (unit: subframe). Example Embodiment F12. The method according to any one of example embodiments F1 to F11, further comprising: determining that a frequency hopping time interval is less than the transmission segment duration, and adjusting an uplink transmission timing of the at least one transmission segment and/or an uplink The link frequency is simultaneously retuned from a first narrow frequency to a second narrow frequency. Example Embodiment F13. The method of example embodiment F12, further comprising determining not to insert a gap between adjacent transmission segments based on the frequency hopping time interval being less than the transmission segment duration. Example Embodiment F14. The method of any one of example embodiments F1 to F11, further comprising: receiving configuration information from the network node, determining whether to adjust a transmission timing and/or at each frequency hopping instance based on the configuration information frequency, and determine whether to insert a gap between adjacent transmission segments based on the configuration information. Example Embodiment F15. The method of example embodiment F14, wherein the configuration information is received via RRC signaling. Example Embodiment F16. The method of any one of example embodiments F12 to F15, wherein the transmission segment(s) are used in a Physical Uplink Control Channel (PUCCH), a Physical Uplink Shared Channel (PUSCH) or a Physical Random Access Channel Transmission on access channel (PRACH). Example Embodiment F17. The method of example embodiments F1 to F16, further comprising: providing user data; and forwarding the user data to a host via the transmission to the network node. Example Embodiment F18. A user equipment comprising processing circuitry configured to perform any of the methods of example embodiments F1-F17. Example Embodiment F19. A wireless device comprising processing circuitry configured to perform any of the methods of example embodiments F1-F17. Example Embodiment F20. A computer program comprising instructions for performing any of the methods of example embodiments F1 to F17 when executed on a computer. Example Embodiment F21. A computer program product comprising a computer program comprising instructions for performing any of the methods of example embodiments F1 to F17 when executed on a computer. Example Embodiment F22. A non-transitory computer-readable medium storing instructions that, when executed by a computer, perform any of the methods of example embodiments F1 to F17.

Group G example embodiment Example Embodiment G1. A method by a network node for facilitating long uplink transmissions in an eMTC NTN, the method comprising: transmitting information indicative of a transmission segment duration to a user equipment (UE). Example Embodiment G2. The method of example embodiment G1, wherein the transmission segment duration includes a maximum number of repetitions of at least one transmission segment. Example Embodiment G3. The method of any one of example embodiments G1 to G2, wherein the at least one transmission segment is for transmission on a physical uplink control channel (PUCCH). Example Embodiment G4. The method of example embodiment G1, wherein the PUCCH includes an eMTC PUCCH. Example Embodiment G5. The method of any one of example embodiments G1 to G4, wherein the information indicates at least one K value of the at least one transmission segment duration using a k-bit field, wherein the value differs depending on the CE mode: CE mode A: 1-bit field for indicating K = 2 candidate values: {2, 4} (unit: subframe), and/or CE mode B: 3-bit field for indicating K = 5 candidate values: {4, 8, 16, 32, 64} (unit: subframe). Example Embodiment G6. The method as in any one of example embodiments G1 to G5, wherein the information does not indicate a value of the at least one transmission segment duration of a PUCCH. Example Embodiment G7. The method of example embodiment G6, further comprising configuring the UE to not perform segment precompensation for the at least one transmission segment based on the information not indicating a value for the transmission segment duration of the PUCCH. Example Embodiment G8. The method as in any one of example embodiments G1 to G5, wherein the information indicates a value of the transmission segment duration of a PUCCH. Example Embodiment G9. The method of example embodiment G8, further comprising configuring the UE to perform segment precompensation on the at least one transmission segment based on the information indicating the value of the transmission segment duration of the PUCCH. Example Embodiment G10. The method of any one of example embodiments G1 to G9, further comprising configuring the UE to determine not to perform segment precompensation for an uplink transmission of the PUCCH based on the information. Example Embodiment G11. The method of example embodiment G10, wherein the information indicates at least one K value of the at least one transmission segment duration using a k-bit field, wherein the value differs depending on the CE mode: CE Mode A: 2-bit field Used to indicate K = 3 candidate values: {2, 4, 8} (unit: subframe); and/or CE mode B: 3-bit field is used to indicate K = 6 candidate values: {4, 8 , 16, 32, 64, 128} (unit: subframe). Example Embodiment G12. The method according to any one of example embodiments G1 to G11, wherein a frequency hopping time interval is less than the transmission segment duration, and the method further comprises configuring the UE to adjust an uplink transmission timing and/or an uplink The link frequency is simultaneously retuned from a first narrow frequency to a second narrow frequency. Example Embodiment G13. The method of example embodiment G12, further comprising configuring the UE to not insert a gap between the adjacent transmission segments based on the hopping time interval less than the transmission segment duration. Example Embodiment G14. The method of any one of example embodiments G1 to G11, further comprising: transmitting configuration information to the UE, and wherein the UE is configured to determine whether to be at each frequency hopping instance based on the configuration information A transmission timing and/or frequency is adjusted, and wherein the UE is configured to determine whether to insert a gap between adjacent transmission segments based on the configuration information. Example Embodiment G15. The method of example embodiment G14, wherein the configuration information is transmitted via RRC signaling. Example Embodiment G16. The method of any one of example embodiments G12 to G15, wherein the transmission segment(s) are used in a Physical Uplink Control Channel (PUCCH), a Physical Uplink Shared Channel (PUSCH) or a Physical Random Access Channel Transmission on access channel (PRACH). Example Embodiment G17. The method of any one of example embodiments G1 to G16, wherein the network node comprises a gNodeB (gNB). Example Embodiment G18. The method according to any one of the previous example embodiments, further comprising: obtaining user data; and forwarding the user data to a host or a user device. Example Embodiment G19. A network node comprising processing circuitry configured to perform any of the methods of example embodiments G1-G18. Example Embodiment G20. A computer program comprising instructions for performing any of the methods of example embodiments G1 to G18 when executed on a computer. Example Embodiment G21. A computer program product comprising a computer program comprising instructions for performing any of the methods of example embodiments G1 to G18 when executed on a computer. Example Embodiment G22. A non-transitory computer-readable medium storing instructions that, when executed by a computer, perform any of the methods of example embodiments G1-G18.

Additional information The transmission segment duration of eMTC PUCCH is similar to that of eMTC PUSCH/PRACH, the network should be able to configure the transmission segment duration of PUCCH such that in the worst case scenario assuming their TA drift is ~100 μs/s and the elevation angle is small , support a timing accuracy of at least 12 * T _S = 0.39 μs (Table 7.26.2-1 in TS 36.133). It may be noted that a longer transmission segment duration is sufficient for a more favorable TA drift or elevation etc.

Transmission segment durations for eMTC PUCCH are provided in Table 5 below. It should be noted that the maximum transmission duration of PUCCH is 8 ms for CE mode A and 128 ms for CE mode B, both of which are less than 256 ms. Therefore, unlike eMTC PUSCH, we do not need to support a transmission segment duration up to 256 ms. The lower limit is chosen to meet the timing error requirement of 0.39 μs. For the upper limit, enough to support the maximum possible segment duration. For example, for CE mode A with 8 repetitions configured for PUCCH, the maximum transmission segment may consist of 4 repetitions. Table 5: Transmission segment duration of eMTC PUCCH. CE mode basic repeating unit duration repeat number Transmission segment duration (unit: repeated signal) A 1ms 1, 2, 4, 8 twenty four B 1ms 4, 8, 16, 32, 64, 128 4, 8, 16, 32, 64

In a particular embodiment, for eMTC PUCCH, the network uses a k-bit field to configure one of K values for the uplink transmission segment duration, where the value differs depending on the CE mode: - CE mode A: 1 bit field is used to indicate K = 2 candidate values: {2, 4} (unit: subframe) - CE mode B: 3-bit column is used to indicate K = 5 candidate values: {4, 8, 16, 32, 64} (unit: subframe)

In another specific embodiment, if the network does not intend to configure segment pre-compensation for PUCCH, it does not indicate any value of SI or transmission segment duration in UE-specific RRC signaling.

In another particular embodiment, the UE does not need to perform segment precompensation for uplink transmissions on PUCCH if the network has not indicated any value for the transmission segment duration in SI or UE-specific RRC signaling.

In the previous embodiments, when the network does not wish to configure fragmentation pre-compensation for the uplink, it implicitly indicates this information to the UE. Alternatively, the network can explicitly indicate this to the UE by adding another value to the transmission segment duration.

In a particular embodiment, for eMTC PUCCH, the network uses a k-bit field to configure one of K values for the uplink transmission segment duration, where the value differs depending on the CE mode: - CE mode A: 2-bit field is used to indicate K = 3 candidate values: {2, 4, 8} (unit: subframe) - CE mode B: 3-bit field is used to indicate K = 6 candidate values: {4, 8, 16, 32, 64, 128} (unit: subframe)

In a further specific embodiment, if the transmission segment duration of PUCCH is set to 8 subframes for CE mode A (or 128 subframes for CE mode B), the UE does not need to perform segment pre-segmentation for PUCCH compensate.

eMTC frequency hopping and precompensation gap In eMTC, frequency hopping is always enabled for PUCCH and can also be configured by the network for PUSCH/PRACH. If the frequency hopping time interval is less than the configured transmission segment duration, the UE may adjust uplink transmission timing and frequency while retuning to a different narrow frequency. To facilitate frequency hopping, eMTC allows a frequency retuning gap of up to one of 2 SC-FDMA uplink symbols between adjacent narrow frequencies.

In one embodiment, if frequency hopping is enabled for an uplink channel and the frequency hopping time interval is set by the network to be smaller than the transmission segment duration, the UE is allowed to adjust its transmission timing and frequency at each frequency hopping instance and The UE is not allowed to insert a gap between transmission segments. This is because the UE can use the existing narrowband retuning time period of up to 2 SC-FDMA uplink symbols between adjacent narrowbands to adjust its timing.

Example: Frequency hopping is always enabled for LTE-M PUCCH. The network configures a frequency hopping time interval from [1, 2, 4, 8] (ms) for CE mode A or [2, 4, 8, 16] (ms) for CE mode B. If the configured frequency modulation interval of PUCCH is less than the configured transmission segment duration of PUCCH, a type A or type B UE can use the retuning gap for frequency hopping to adjust its time to hop to a different narrow frequency timing/frequency without inserting additional gaps between transmission segments.

In another embodiment, the network router RRC configures the following UE behavior for frequency hopping: • If configured, the UE adjusts its transmission timing and frequency at each frequency hopping instance and the UE does not insert a gap between adjacent transmission segments. • If configured, the UE adjusts its transmission timing and frequency at each frequency hopping instance and the UE inserts a gap between adjacent transmission segments and the UE does not adjust its transmission timing and frequency at each frequency hopping instance. • Otherwise, the UE inserts a gap between adjacent transmission segments and the UE does not adjust its transmission timing and frequency at each frequency hopping instance.

100: Communication system 102: Telecommunication network 104: access network 106: Core network 108: Core network node 110a: network node 110b: network node 112a: User Equipment (UE) 112b: user equipment (UE) 112c: User Equipment (UE) 112d: user equipment (UE) 114: hub 116: Host 200: User Equipment (UE) 202: Processing circuit system 204: busbar 206: input/output interface 208: Power 210: Memory 212: communication interface 214: application 216: Information 218: Transmitter 220: Receiver 222: Antenna 300: network node 302: Processing circuit system 304: memory 306: communication interface 308: Power 310: Antenna 312: Radio Frequency (RF) Transceiver Circuit 314: Baseband processing circuit system 316: port/terminal 318: Radio front-end circuit system 320: filter 322: Amplifier 400: Host 402: Processing circuit system 404: Bus 406: Input/Output Interface 408: Network interface 410: power supply 412: memory 414:Host application 416: data 500: Virtualization environment 502: Application/Virtual Application 504: hardware 506: virtualization layer 508a: Virtual Machine (VM) 508b: Virtual Machine (VM) 510: Management and Chords 512: Control system 602: Host 604: Network node 606: User Equipment (UE) 608: Step 610: Step 612: Step 614:Step 616: Step 618:Step 620: Step 622: Step 660: connector 670: Wireless Connector 700: method 702: Step 704: Step 800: method 802: step 804: step

For a more complete understanding of the disclosed embodiments, together with features and advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings, in which: Figure 1 illustrates an example architecture of a satellite network with bent pipe transponders; Figure 2 depicts an example orbital set; Figure 3 shows typical beam patterns for various NTN access networks as discussed in 3GPP TR 38.811 v.15.4.0; Figure 4 illustrates an example communication system according to certain embodiments; Figure 5 illustrates an example UE according to some embodiments; Figure 6 illustrates an example network node according to some embodiments; Figure 7 illustrates a block diagram of a host according to some embodiments; Figure 8 illustrates a virtualization environment in which functions implemented by some embodiments may be virtualized, according to some embodiments; Figure 9 illustrates a host communicating with a UE via a network node over a portion of a wireless connection according to some embodiments; Figure 10 illustrates an example method used by a UE to facilitate long UL transmissions in an IoT NTN, according to certain embodiments; and Figure 11 illustrates an example method used by a network node to facilitate long UL transmissions in an IoT NTN, according to certain embodiments.

700: method

702: Step

704: Step

Claims (28)

A method (700) by a user equipment UE (112, 200) for facilitating long uplink transmission in an Internet of Things (IoT) non-terrestrial network (NTN), the method comprising: transmitting (702) to a network node (110, 300) information for determining whether the UE is to insert at least one gap between adjacent transmission segments in at least one uplink transmission, and Configuration information is received (704) from the network node to configure the UE for: inserting the at least one gap when the information transmitted to the network node indicates that at least one symbol, slot and/or subframe is to be discarded and/or punctured for segment precompensation, and The at least one gap is not inserted when the information transmitted to the network node indicates that at least one sample is to be discarded and/or punctured for segment precompensation. The method of claim 1, wherein when the UE is to be inserted into the at least one gap, the information indicates that the UE is a type A UE or when the UE is not inserted into the at least one gap, the information indicates that the UE is a type B UE. The method according to any one of claims 1 to 2, wherein when the UE is to insert the at least one gap, the information indicates a gap duration or a range of gap durations that can be inserted between the adjacent transmission segments . The method according to any one of claims 1 to 3, wherein when the UE is to be inserted into the at least one gap, the information indicates a number of symbols, time slots and/or to be discarded and/or punctured to implement segment pre-compensation subframe. The method of any one of claims 1 to 4, wherein the information includes capability information associated with the UE. The method according to any one of claims 1 to 5, wherein when the UE is to insert the at least one gap, the information indicates that the at least one gap is to be inserted for a specific type of transmission and/or a specific type of physical channel. The method according to claim 6, wherein the specific type of physical channel is a physical uplink shared channel, a physical uplink control channel or a narrowband physical uplink shared channel. The method of claim 7, wherein when the UE is to be inserted into the at least one gap, the information indicates: for each transmission having a duration higher than a threshold duration, the at least one gap will be inserted between the adjacent transmission segments, or For each transmission of a certain duration, the at least one gap will be inserted between the adjacent transmission segments. The method as in any one of claims 1 to 8, wherein the information indicates a specific type of NTN and the configuration information configures the UE to transmit in adjacent transmissions for each transmission associated with the specific type of NTN The at least one gap is inserted between the segments. The method of claim 9, wherein the NTN of the specific type is low earth orbit or medium earth orbit. The method as claimed in any one of claims 1 to 10, wherein the information indicates a timing advance and the method comprises: inserting the at least one gap between adjacent transmission segments in at least one uplink transmission when the timing advance is increased; or When the timing advance decreases, it is determined not to insert the at least one gap between adjacent transmission segments in the at least one uplink transmission. The method as in any one of claims 1 to 10, wherein the information indicates a location of the UE. A method (800) by a network node (110, 300) for facilitating long uplink transmissions in an Internet of Things (IoT) non-terrestrial network (NTN), the method comprising: receiving (802) from a user equipment (UE) (112, 200) information for determining whether the UE is to insert at least one gap between adjacent transmission segments in at least one uplink transmission, and Based on this information, configure (804) the UE to: inserting at least one gap when the information indicates that at least one symbol, slot and/or subframe is to be discarded and/or punctured for segment precompensation, and The at least one gap is not inserted when the information indicates that at least one sample is to be discarded and/or punctured for segment precompensation. The method as claimed in item 13, comprising: When the information indicates that the UE is to be inserted into the at least one gap, determining that the UE is a type A UE, or When the information indicates that the UE does not insert the at least one gap, it is determined that the UE is a type B UE. The method according to any one of claims 13 to 14, wherein when the UE is to insert the at least one gap, the information indicates a gap duration or one of the gap durations to be inserted between the adjacent transmission segments scope. The method according to any one of claims 13 to 15, wherein when the UE is to be inserted into the at least one gap, the information indicates a number of symbols, time slots and/or to be discarded and/or punctured to implement segment pre-compensation subframe. The method of any one of claims 13 to 16, wherein the information includes capability information associated with the UE. The method according to any one of claims 13 to 17, wherein the information indicates a specific type of transmission and/or a specific type of physical channel, and the method further comprises based on the specific type of transmission and/or the specific type of The physical channel determines to insert the at least one gap between the adjacent transmission segments. The method of claim 18, wherein the specific type of physical channel is a physical uplink shared channel, a physical uplink control channel or a narrowband physical uplink shared channel. The method of claim 19, wherein the information includes a duration, and the method further comprises: determining that for each transmission having a duration higher than a threshold duration, the at least one gap is to be inserted between the adjacent transmission segments, or It is determined that for each transmission of the particular duration, the at least one gap is to be inserted between the adjacent transmission segments. The method of any one of claims 13 to 20, wherein the information is indicative of a particular type of NTN, and the method further comprises determining, for each transmission associated with the particular type of NTN, which segment of the adjacent transmission will be insert the at least one gap therebetween. The method of claim 21, wherein the specific type of NTN is low earth orbit or medium earth orbit. The method of any one of claims 13 to 22, wherein the information indicates a time advance, and the method comprises: When the timing advance is increased, determining that the at least one gap is to be inserted between adjacent transmission segments in the at least one uplink transmission; or When the timing advance is decreased, it is determined that the at least one gap will not be inserted between adjacent transmission segments in the at least one uplink transmission. The method of any one of claims 13 to 23, wherein the information indicates a location of the UE. A user equipment (UE) (200, 112) for facilitating long uplink transmissions in an Internet of Things (IoT) non-terrestrial network (NTN), the UE comprising processing circuitry configured to: (202): transmitting (702) to a network node (300, 110) information for determining whether the UE is to insert at least one gap between adjacent transmission segments in at least one uplink transmission, and Configuration information is received (704) from the network node to configure the UE for: inserting the at least one gap when the information transmitted to the network node indicates that at least one symbol, slot and/or subframe is to be discarded and/or punctured for segment precompensation, and At least one gap is not inserted when the information transmitted to the network node indicates that at least one sample is to be discarded and/or punctured for segment precompensation. The UE of claim 25, wherein the processing circuitry is configured to perform any of the methods of claims 2-12. A network node (110, 300) for facilitating long uplink transmissions in an Internet of Things (IoT) non-terrestrial network (NTN), the network node comprising processing circuitry configured to: 302): receiving from a user equipment (UE) (112, 200) information for determining whether the UE is to insert at least one gap between adjacent transmission segments in at least one uplink transmission, and Based on this information, configure the UE to: inserting at least one gap when the information indicates that at least one symbol, slot and/or subframe is to be discarded and/or punctured for segment precompensation, and The at least one gap is not inserted when the information indicates that at least one sample is to be discarded and/or punctured for segment precompensation. The network node of claim 24, wherein the processing circuitry is configured to perform any of the methods of claims 14-24.

Images