IoT store-and-forward revisit time with a polar constellation

Store-and-forward IoT inverts the usual question. There is no call to drop and no session to maintain. A terminal wakes, waits for a satellite, hands over a few hundred bytes and sleeps again. The product is not continuous coverage, it is message latency, and the metric that matters is the worst wait rather than the average one, because that is what sets the freshness guarantee you can print in a datasheet.

This configuration is a sun-synchronous shell at 550 km and 97.5° with a 10° mask, which is realistic for a patch antenna with time to wait. A near-polar inclination puts the service band edge at 90°, so unlike a mid-inclination shell it serves every latitude, including the high-latitude sites where a lot of remote assets actually sit.

Latency against fleet size

At 550 km, 97.5° inclination, minimum elevation 10°, latitude 60°.

Six satellites give a worst wait of 2.8 h, which supports a few reports a day from an asset that does not move much. Twelve brings the worst case to 26.3 min, which is the point where hourly telemetry stops being a promise you have to hedge. Forty-eight brings it to 1.7 min, at which point the terminal battery, not the constellation, decides how often you hear from the asset.

More satellites is not automatically less latency

The twenty-two satellite row is worse than the twelve satellite row: 33.7 min against 26.3 min, despite carrying ten more spacecraft. The automatic plane rule spreads twenty-two satellites as 11 planes of 2, and thin planes leave seams that a smaller, better packed shell does not have. Change the orbital planes control on this page and the number moves without a single satellite being added.

This is the most useful habit the tool can teach: when a fleet size looks disappointing, try the other plane arrangements before buying more satellites.

Why polar, and what it costs

A near-polar shell covers everything, but it does not cover everything equally. Orbits converge at the poles, so passes cluster there and thin out at the equator. The same 22 satellite fleet gives 33.7 min at latitude 60°, 19.3 min at 78° and 40.0 min at the equator. If your assets sit in the tropics, the same 22 satellites flown at 53° instead would give 23.7 min at the equator. Inclination is a decision about which customers you serve well, not a detail of the orbit.

Sun-synchronous adds a second property that has nothing to do with geometry and everything to do with operations: passes happen at roughly the same local solar time each day. That is predictable for power budgeting and awkward if your traffic is bursty at a time of day the orbit does not visit.

Turning a gap into a datasheet number

Worst outage is the honest input to a latency guarantee, and average wait is the number your users will actually experience most of the time. Quote the first, design the product around the second, and remember that this model counts a satellite as available the moment it clears the mask. A real terminal needs enough of a pass to acquire, negotiate and transfer, so subtract the short windows before believing a small number.

Other scenarios

• Why continuous coverage is not a threshold
  Continuity depends on the elevation mask, altitude, latitude and plane arrangement, not on a satellite count. The explanation behind the sizing tool.
• Direct-to-phone coverage at 5, 25, 45 and 90 satellites
  What a direct-to-device constellation can promise at each stage of a buildout, from a first block of five satellites to a 90-satellite shell.
• Why single-plane deployments have long outages
  The same satellite count can mean a 15 hour outage or a 25 minute one. Deployment order and plane spread decide which.
• Coverage vs latitude, and why 53 degrees stops at 61
  Inclination plus the coverage half-angle sets a hard latitude ceiling. Above it, no fleet size produces a single second of service.