The technical requirements for Non-Terrestrial Networks (NTNs) are critical to ensuring their seamless integration and efficient operation alongside terrestrial communication systems. One of the foremost challenges is managing latency, particularly for satellites in higher orbits like Geostationary Orbit (GEO). To address this, systems need advanced techniques for reducing transmission delays, such as optimizing signal routing and using Low Earth Orbit (LEO) satellites for time-sensitive applications. Another essential requirement is spectrum coordination, as NTNs share frequencies with terrestrial networks, making efficient spectrum allocation and interference management vital to prevent signal degradation.

Interoperability between NTNs and terrestrial systems is also crucial, demanding sophisticated network architecture and protocols that enable seamless handovers and consistent service quality. This includes designing ground stations and user terminals equipped to handle dual connectivity, switching between satellite and terrestrial networks without service disruption. Power efficiency is another significant consideration, particularly for user devices relying on NTN links, as satellite communication can require higher transmission power. Advanced modulation and coding schemes, such as those defined in 3GPP standards for 5G NTNs, are essential to maximize spectral efficiency while minimizing power consumption.

Additionally, NTNs must be robust against environmental and atmospheric disruptions, such as signal attenuation caused by rain, clouds, or other atmospheric conditions. To address this, technologies like adaptive beamforming and error correction mechanisms are essential to maintain link reliability. Scalability is another key technical requirement, as NTNs often serve millions of users simultaneously in diverse and dynamic environments. This necessitates the use of dynamic resource allocation and advanced traffic management algorithms to optimize network performance.

Security is also a critical concern, requiring encrypted communication, secure satellite control systems, and mechanisms to prevent unauthorized access or jamming. Finally, the ground infrastructure supporting NTNs, including gateways and user terminals, must be designed to handle the unique characteristics of non-terrestrial communication, ensuring high reliability and low operational costs. These technical requirements collectively shape the development of NTNs, enabling them to provide resilient and expansive connectivity in harmony with terrestrial networks.

• Delay Requirements
• Reading the Two Delay Tables Together
• Performance Requirements
• What Those Numbers Actually Imply
• How 3GPP is updated to meet these requirements
• The Open Questions, Answered

Delay Requirements

When we talk about requirements in a terrestrial network, we usually mean something we can design towards. If the requirement says the latency should be under a few milliseconds, an engineer can go and shorten a queue, move a function closer to the edge, or schedule more aggressively. Delay requirements in NTN are a different kind of statement, and it is worth being clear about that before looking at the numbers.

The reason is simple. Most of the delay in a satellite link is not caused by anything the network does. It is caused by distance. The signal has to travel to the satellite and back, and nothing in the protocol can make that faster because the speed of light is not negotiable. So when a specification writes down a delay requirement for NTN, it is not really asking the system to be quick. It is doing something more modest and more honest : it is writing down how much delay the geometry already costs, and then saying how much more the network is allowed to add on top.

That is why the two tables below look the way they do. The first one tells you what the distance costs. The second one tells you what that turns into for each deployment scenario, including the parts that vary from one user to another. Read together, they define the budget that every other mechanism on this site is trying to live within.

The total Delay Requirement specified in TS 22.261 is roughly the following value + 5 ms (delay caused by 5G protocol)

< 22.261 (Rel 18) - Table 7.4.1-1: UE to satellite propagation delay >

NOTE :  Even the smallest propagation is greater than the max delay that can be covered by TA field of RAR.(Around 2 ms is covered by RAR TA in SCS 15Khz, 1 ms in SCS 30Khz).

< TR 38.821 - Table 7.1-1: NTN scenarios versus delay constraints >

Reading the Two Delay Tables Together

At first glance the two tables above look like they are saying the same thing twice. Both are about delay, both list GEO, MEO or LEO, and both are full of milliseconds. It is easy to look at them, conclude that satellites are slow, and move on.

They are actually answering two quite different questions, and the difference matters. The first table comes from a service requirements specification, so it is written from the user's point of view : if you are on a satellite link, this is roughly how long you should expect to wait. The second table comes from a study on how to build the thing, so it is written from the designer's point of view : if you have to make NR work over this link, these are the numbers your protocol has to survive.

A user only ever experiences one number, which is the total. A designer has to worry about a great deal more than the total - the shortest delay as well as the longest, whether the payload is transparent or regenerative, and how fast the delay is changing while the connection is open. That extra detail is exactly what turns a delay figure into engineering work, which is why the second table is the one most of this site is built around.

The two tables above come from different documents and answer different questions, and it is worth being explicit about how they relate - because the second one is where the design work actually comes from.

Where the 285 / 95 / 35 ms figures come from

The end-to-end latency targets listed under Performance Requirements below are not independent numbers. They are simply the one-way propagation figures from the TS 22.261 table plus the 5 ms of assumed 5G network latency mentioned above :

Notice what that arithmetic implies : the requirement is essentially the physics plus a small allowance. TS 22.261 is not asking the system to be fast; it is asking it not to add much on top of what the orbit already costs. That is a very different kind of requirement from a terrestrial latency target, and it is the honest way to write a requirement for something you cannot make faster.

Why the TR 38.821 table is the one that drives the design

The TS 22.261 table gives a service-level answer - what the user experiences. The TR 38.821 table beneath it gives the engineering answer, and it contains three things the first one does not : the minimum delay as well as the maximum, the difference between transparent and regenerative payloads, and the rate at which the delay changes. Those three are what actually generate work in the specification :

• The gap between the minimum and maximum columns is the differential delay across the cell. It is what makes a single RACH configuration insufficient and forces per-UE pre-compensation - see NTN RACH.
• The transparent column is exactly twice the regenerative one, because a bent-pipe payload puts the feeder link inside the UE's radio round trip. The payload choice therefore changes the delay budget before any protocol work starts - see NTN Architecture.
• The delay variation row (up to +/- 93 us/s for LEO) is why the timing advance is broadcast as a polynomial with drift terms rather than as a single value - see NTN Timing Advance.

Confirming the note about the RAR timing advance field

The note above - that even the smallest propagation delay exceeds what the RAR timing advance field can express - is worth showing, because it is the cleanest single justification for the whole NTN timing design. The timing advance command in the Random Access Response is 12 bits, giving T_A in the range 0 to 3846, and it maps to

N_TA = T_A x 16 x 64 / 2^μ x T_c

with T_c the basic time unit of about 0.509 ns. Evaluating it at the maximum :

• 15 kHz subcarrier spacing : 3846 x 1024 x T_c = 2.003 ms
• 30 kHz subcarrier spacing : half of that, 1.002 ms

Against a LEO minimum of 3 ms one way, and 120 ms for GEO, the field is short by a factor of anywhere from 1.5 to more than a hundred. There was never any prospect of widening it - a field big enough for GEO would be absurd for terrestrial use. This is precisely why NTN moved the bulk of the timing correction out of the closed loop and into open-loop pre-compensation computed by the UE, leaving the RAR field to correct only the small residual. Every other timing mechanism on this site follows from that single decision.

Performance Requirements

Delay tells you how long you wait. It says nothing about how much you actually get, and for most users that is the more interesting question. This section is where the specification writes down what an NTN connection is supposed to deliver.

The first thing to notice is how modest the ambition is compared with terrestrial 5G. There is no talk of gigabits here. The numbers are in megabits, and in the narrowband case they are in kilobits. That is not the specification being pessimistic. It is the specification being realistic about a link where a satellite hundreds of kilometres away has to share one channel of spectrum across a beam that can cover a small country.

The second thing to notice, once you start reading across the rows, is that the requirement changes enormously depending on who is being served. A phone in someone's hand and an antenna bolted to the roof of an aircraft are asked for wildly different things. That is not an accident of drafting, and the reason behind it is worth drawing out - which is what the section after this one does.

High lights of Performance Requirements can be summarized as :

• GEO satellite access with up to 285 ms end-to-end latency, including a 5 ms assumed network latency.
• MEO satellite access with up to 95 ms end-to-end latency, plus a 5 ms network latency.
• LEO satellite access with up to 35 ms end-to-end latency, with an additional 5 ms network latency.
• Allow for quality of service negotiation to optimize user experience, considering the latency.
• Provide high uplink and downlink data rates for satellite UEs.
• Ensure communication service availability of at least 99.99%.

More detailed requirement would vary depending on various scenario and UE type which is summarized in following table.

< 22.261 (Rel 18) - Table 7.4.2-1: Performance requirements for satellite access >

The table can be summarized as follows :

• Pedestrian: 1 Mbit/s DL, 100 kbit/s UL, with area traffic capacities of 1.5 Mbit/s/km² DL and 150 kbit/s/km² UL, at 100 users/km², and an activity factor of 1.5%.
• Public Safety: 3.5 Mbit/s for both DL and UL, other capacities TBD, users moving at 100 km/h.
• Vehicular Connectivity: 50 Mbit/s DL, 25 Mbit/s UL, details TBD, with 50% activity factor, speeds up to 250 km/h.
• Airplanes Connectivity: 360 Mbit/s per plane DL, 180 Mbit/s UL, with users traveling up to 1000 km/h.
• Stationary: 50 Mbit/s DL, 25 Mbit/s UL, activity factor not applicable, stationary users.
• Video Surveillance: 0.5 Mbit/s DL, 3 Mbit/s UL, users stationary or moving up to 120 km/h.
• Narrowband IoT Connectivity: 2 kbit/s DL, 10 kbit/s UL, with area traffic capacities of 8 kbit/s/km² DL and 40 kbit/s/km² UL, at 400 users/km², activity factor of 1%, at speeds up to 100 km/h.

What Those Numbers Actually Imply

A requirement table is a strange thing to read. Every row looks equally important, nothing tells you which numbers were hard-won compromises and which were obvious, and it is very easy to come away having absorbed nothing except an impression that satellites are slower than fibre.

It is much more rewarding to treat the table as evidence rather than as instruction. Somebody had to argue for each of these figures, and the pattern they form tells you what the real constraints were. If you sort the rows and look for what the high numbers have in common, and then do the same for the low ones, the underlying physics becomes visible through the requirements.

Three patterns are worth pulling out. The first explains why the data rates differ by a factor of a hundred between rows. The second explains why the least eye-catching column in the table is actually the most honest one. And the third is a single number - the availability target - that quietly turns out to be one of the most demanding requirements on the whole page.

The performance table is easy to skim past as a wall of figures. Three things in it are worth pulling out, because each one explains a design decision that shows up elsewhere.

1. Terminal type decides everything

Sort the rows by data rate and a pattern appears immediately. The high-rate rows - 360 Mbit/s per plane, 50 Mbit/s vehicular and stationary - are all rows where the terminal is a mounted, directive antenna. The low-rate rows - 1 Mbit/s pedestrian, 2 kbit/s narrowband IoT - are the rows where the terminal is a handheld or a sensor with an omnidirectional antenna. The requirement is not really being set by the application. It is being set by the antenna, and by the link budget that follows from it.

This is the same split that runs through the deployment scenarios, where Ka band is always paired with a VSAT-type relay terminal and S band always with a handset. See NTN Spectrum and NTN Architecture.

2. The area capacity figures are the honest ones

The per-user data rates look generous, but the columns that matter for planning are the area traffic capacity figures - and those are strikingly small. The pedestrian row asks for 1.5 Mbit/s per km² in the downlink; the narrowband IoT row asks for 8 kbit/s per km². Multiply those by a beam footprint and it becomes clear how little total throughput is on offer relative to the area covered.

That is not a shortcoming of the requirement - it is the requirement being realistic. A single beam spreads one channel of spectrum across up to a million square kilometres, so capacity per unit area is inevitably four orders of magnitude below a terrestrial network. The activity factors in the same table (1.5 % for pedestrian, 1 % for IoT) are doing the same job : they quietly acknowledge that these users cannot all be active at once. See the coverage arithmetic on Why NTN ?.

3. What 99.99 % availability actually costs

Availability requirements are easier to judge once converted into downtime :

Roughly nine seconds of outage a day is a demanding target for a system where the serving cell is replaced every few minutes. In a LEO constellation a satellite sets and another has to take over continuously, so every one of those switches has to complete without a visible break. That is why NTN mobility is built on predictable, scheduled switching driven by ephemeris, t-Service and neighbour assistance rather than on measurement-triggered handover - a measurement-based decision has to detect degradation first, and detecting it already costs part of the budget. See NTN RRC (NR).

How 3GPP is updated to get around the problems and meet the requirements listed above ?

So far this page has been about the problem. This section is about the response, and it is the part that surprises people who expect a new radio technology for a new kind of link.

There is almost no new radio in NTN. The waveform is the same OFDM, the channel coding is the same LDPC and polar coding, the frame structure is the same, and the messages have the same names as they do on a terrestrial cell. Rel-17 did not design a satellite air interface. It took the existing NR air interface and worked out, item by item, what breaks when you stretch the distance from a few kilometres to tens of thousands, and then added the smallest thing that would fix each breakage.

That approach is deliberate and it follows directly from why NTN exists at all. The value of putting satellites inside 3GPP is that the result is recognisably the same network, using the same devices, the same core and the same subscriptions. Anything that made NTN into a genuinely different radio system would throw away the thing that made it worth doing. So what you find below is a list of offsets, timers, validity durations and extra fields rather than a list of new technologies - and the recurring idea behind almost all of them is the same one, which is worth watching for as you read.

To cope with the issues and to meet the requirement mentioned above, some new features are introduced in 3GPP release 17. In summary, those new features can be summarized as below.

• Handling Timing Offset for Long Delay :  Additional Timing Address Information elements (ta-Info-r17) are added in SIB 19.
• Handling the long delay for HARQ due to long distance between UE and gNB : a New Information Elements (DL-DataToUL-ACK-v1700 ) is added to specify long enough K1 value.

NOTE :  To cover all the possible distance between UE and Satellite, the number of HARQ should be very large, but in current extenstion, the max HARQ number is increased only up to 32. Waiting to see the feedback from industry

NOTE : Theoretically increasing K1 is not the only possible solution. We can remove HARQ completely and relay on higher layer for error checking and retransmission. I guess some would be trying this. But removing HARQ completely would be too much impact on protocol since it would impact on signaling message transmission and reception.

• Indicating the Position and Motion of the Satellite : For this purpose, a new Information Elements (ephemerisInfo-r17 ) is added and broadcast in SIB 19.

Those three are the headline changes. The full Rel-17 set is larger, and it is worth having in one place because the individual pieces only make sense against the requirement they serve.

NOTE : Read the middle column as a whole and one idea keeps recurring - move the large, predictable part of the problem out of the closed loop and compute it in advance. Rel-17 NTN adds almost no new radio capability. It is a set of adaptations whose purpose is to let the existing NR design survive at satellite distances, which is exactly what you would want if the value of NTN is that it is recognisably the same network.

Later releases continued rather than redirected this. Rel-18 extended NTN above 10 GHz into the FR2-NTN bands, improved coverage for handheld terminals, added network-verified UE location and improved NTN-to-TN and NTN-to-NTN mobility. Rel-19 added further NR-NTN and IoT-NTN enhancements. Throughout, the transparent payload has remained the normative baseline - the regenerative scenarios in TR 38.821 are described but not profiled.

The Open Questions, Answered

One of the more useful things about writing notes as a specification is being drafted is that you end up with a record of what was genuinely uncertain at the time. Later, when the answers arrive, you can go back and check your own reasoning against what actually happened - and that is a far better way to learn how a standard evolves than reading the finished document, which always looks inevitable in hindsight.

Two notes in the section above were left as open questions. One was a doubt about whether a particular fix went far enough. The other was a guess about a different approach that the author suspected somebody would try. Both can now be settled, and it is worth doing so properly rather than just asserting the outcome, because the reasoning behind each answer explains a design choice that is otherwise quite hard to motivate.

Two notes in the section above were written as open questions at the time. Both now have answers, and they are interesting ones because the second guess turned out to be right.

"the max HARQ number is increased only up to 32. Waiting to see the feedback from industry"

The concern was justified and the arithmetic confirms it. HARQ is stop-and-wait per process, so transmission stays continuous only while (number of processes) x (slot duration) is at least the round trip time. At 15 kHz a slot is 1 ms, so 32 processes buy about 32 ms of pipeline :

• LEO 600 km regenerative, 12.89 ms round trip - comfortably covered, even by the legacy 16 processes.
• LEO 600 km transparent, 25.77 ms - only just covered by 32, with no margin for processing time.
• LEO 1200 km transparent, 41.77 ms - not covered.
• GEO, 270.73 ms regenerative or 541.46 ms transparent - would need several hundred processes, each holding a soft buffer. Not implementable in a handset, and not useful if it were.

So raising the count to 32 rescues LEO and only LEO. It was never going to be the answer for GEO, and that is why it was paired with the second mechanism rather than pushed higher. Note also that the choice of 32 is not arbitrary : downlinkHARQ-FeedbackDisabled-r17 is a BIT STRING (SIZE (32)), one bit per process, so the two features were sized together. See Why HARQ Stalls in NTN.

"We can remove HARQ completely and relay on higher layer for error checking and retransmission. I guess some would be trying this."

That guess was correct, and it is close to what Rel-17 actually specified - though in a more surgical form than removing HARQ outright. The mechanism is downlinkHARQ-FeedbackDisabled-r17, which disables the uplink HARQ feedback per HARQ process rather than for the cell. A process with feedback disabled never waits, so it can be reused immediately and the pipeline never stalls; recovery for those transmissions falls to RLC AM exactly as anticipated.

Doing it per process rather than globally avoids the concern raised in the same note about the impact on signalling. The network can leave feedback enabled on the processes carrying signalling and disable it on bulk data, so control-plane reliability is unaffected. The cost is the one the note implies : reliability moves up to RLC AM, whose retransmission loop is longer still, so link adaptation has to be more conservative to avoid needing it. That trade is left to the network to make per process, which is why the specification provides a bitmap rather than a switch.

Related Pages on this Site

• NTN Timing Advance - how the delay requirement is actually met
• NTN Frequency Compensation - the Doppler side of the same problem
• NTN RACH - where the RAR timing advance limitation bites
• NTN RRC (NR) - the SIB19 and ntn-Config fields named in the table above
• NTN Architecture - why payload type doubles the delay budget
• NTN Challenges - the requirements seen as problems
• Why NTN ? - the coverage and capacity arithmetic behind the area traffic figures

3GPP Reference

• Non-Terrestrial Networks (NTN) - 3GPP Technology Article (2024)
• 3GPP TS 22.261 : Service requirements for the 5G system; Stage 1 - clause 7.4, the source of both requirement tables above
• 3GPP TR 38.821 : Solutions for NR to support non-terrestrial networks (NTN) - Table 7.1-1 and the scenario delay budget
• 3GPP TR 38.811 : Study on New Radio (NR) to support non-terrestrial networks
• 3GPP TS 38.213 : NR; Physical layer procedures for control - clause 4.2, the timing advance expression and the RAR TA range
• 3GPP TS 38.331 : NR; RRC protocol specification - SIB19, ntn-Config, ta-Info and the HARQ fields
• 3GPP TS 38.321 : NR; MAC protocol specification - response windows and the contention resolution timer
• 3GPP TR 36.763 : Study on NB-IoT / eMTC support for Non-Terrestrial Networks - the narrowband IoT row of the performance table

Other References

• Non-terrestrial networks (NTN) - R&S
• Non-Terrestrial Network Advantages, Challenges, and Applications - Keysight
• 5G & Non-Terrestrial Networks - 5G Americas White Paper (2022)
• 5G from Space: An Overview of 3GPP Non-Terrestrial Networks