Hi all,

Last week I showed that an ordinary 5G phone cannot talk to a satellite. The timing advance a real Starlink pass demanded was fourteen times beyond what the 5G standard can even express, and across the entire pass, none of it fitted inside standard 5G timing.

That's a fair thing to prove, but it's only half an engineer's job. The obvious next question is: so what's the fix? 3GPP has one. This week I built it.

The elegant thing about Release-17's answer is what it refuses to do. It doesn't try to have the network measure and correct each user's delay and Doppler individually — with thousands of handsets under a moving satellite, that would never scale. Instead it pushes the work to the handset. The satellite broadcasts its own ephemeris — position and velocity — in a System Information Block. Every NTN handset is required to have GNSS, so it knows where it is. Given both, the phone works out its own distance and relative velocity, pre-computes exactly the timing advance and frequency shift it needs, and applies them before it transmits. The signal arrives at the satellite already corrected, and to the base station it looks like an ordinary terrestrial cell.

I ran this against a live pass of STARLINK-1008 over Aberdeen at S-band. Uncompensated: 9,860 microseconds of timing advance, 39,756 hertz of Doppler. After pre-compensation: both zero.

I want to be precise about that zero, because it would be easy to oversell. With perfect knowledge and no delay the correction is exact by construction, not by discovery. The geometry is known, the maths is exact, of course the residual vanishes. That's the design, not a clever result. So the interesting question was never whether it works — it's what breaks it.

What breaks it is that a LEO satellite moves several kilometres every second. The correction is stale the instant it's computed. So I swept the age of the applied correction and asked how old it can get before what's left over breaks the tolerances.

The tolerances aren't mine. For frequency, TS 38.101-5 requires the handset's carrier to be within ±0.1 ppm of the ideally pre-compensated reference frequency — literally a limit on residual Doppler, which at 2 GHz is a budget of ±200 Hz. For timing I used the cyclic prefix, 4.69 microseconds, since uplink symbols must land inside that window or they smear into the next one.

The answer: timing must be refreshed every 100 milliseconds. Frequency every 400.

Residual timing error (top) breaks the cyclic prefix after ~100 ms; residual frequency error (bottom) survives to ~400 ms. STARLINK-1008 over Aberdeen, S-band.

Here's the part I didn't expect. Doppler is the impairment everyone talks about in satellite 5G — the headline number, the dramatic S-curve. But timing is the binding constraint, roughly four times stricter. It breaks first, and it breaks hard: a correction one second old overshoots the cyclic prefix by about eight and a half times. That only shows up if you actually measure both against their real limits rather than eyeballing which number looks bigger. 39,756 Hz sounds far more alarming than 9,860 microseconds. It isn't. What matters isn't how big an impairment is, but how big relative to the budget it has to fit inside — and how fast it moves.

One thing I've tried to hold to in this series is not trusting a single number from a single method. Residual timing error grows at twice the range rate over the speed of light, per second of staleness — so the refresh limit should be roughly the cyclic prefix times c, over twice the max range rate. That closed form gives 118 milliseconds. The swept simulation gave 100, the last grid point below it. Two completely independent routes agreeing is the reason to trust either. Both are locked into the tests.

And a non-result worth reporting: I expected GNSS accuracy to matter. It doesn't. A realistic five-to-ten metre position error costs about three to six percent of the timing budget. You'd need to be wrong about your own location by roughly 180 metres before GNSS alone broke anything — while staleness breaks it in under a tenth of a second. The engineering effort in a Rel-17 handset isn't in knowing where you are precisely. It's in keeping the correction fresh.

Week 5 asked what breaks. Week 6 built the fix and found its real limit — not a flaw in the design, but a hard operating requirement falling straight out of orbital physics: refresh about ten times a second, or the correction is worse than useless.

Which sets up an obvious question for later. If the correction goes stale because the satellite has moved by the time you apply it — could you predict where it's going to be, and correct for that instead?

Until next time,
Shaif

Keep Reading