Your Satellite Has a Blind Spot — Do You?
In this new edition, let's investigate the canyon effect.
In the literature, there is a mention of the “Canyon Effect” or “Field of View - FOV,” which does indeed affect LEO connectivity in mountainous areas.
It seems likely that LEO connectivity used to connect critical IoT devices such as automation systems running SCADA or the IEC 61850 protocol could suffer from this problem.
Here are the main points of analysis:
Use Case: IoT Connectivity on LEO in a Mountain area
The Topographical Challenge: “The Canyon Effect”
Remote plants present a unique connectivity challenge for low-Earth orbit (LEO) satellite communications such as Starlink / One Web / Amazon LEO. Located at the bottom of the Valley, the site plant is dominated to the north by a high massif, which rises steeply from 700m to over 2800m above sea level.
In France (latitude ~45°N), Starlink / One Web / Amazon LEO antennas must be oriented northward to capture the maximum density of satellites. The high massif acts as a natural “wall,” blocking a significant portion of the required field of view (FOV).
This does not create a total outage, but rather intermittent and cyclical connectivity. The satellites “set” prematurely behind the mountain ridges before they can smoothly hand over to the next satellite, creating regular micro-outages.
Phase 1: Stable Window (Satellite at Zenith)
Duration: 90 seconds.
Context: The satellite is high in the sky, in the narrow band of sky visible above the valley.
Characteristics: High throughput (80 Mbit/s), low latency (35 ms), and minimal jitter.
Test objective: Validate the nominal operation of SCADA data exchanges and telemetry.
Phase 2: Diffraction Degradation (Approaching the Ridge)
Duration: 20 seconds.
Context: The satellite descends toward the horizon, and its signal begins to “graze” the rocky ridges. This creates interference (Fresnel zone) and noise.
Characteristics: The throughput drops (40 Mbit/s), latency doubles (80 ms), and, most importantly, jitter increases (45 ms) with slight packet corruption (0.05%).
Test objective: Observe whether the control system begins to detect errors or slow down before the cut-off.
Phase 3: North obstruction (blind spot)
Duration: 15 seconds.
Context: This is the critical event. The satellite passes behind the high massif mountain range. The link is not completely cut off (reflections possible), but becomes extremely unstable.
Characteristics: Very high latency (150ms+), massive packet loss (25%) with a strong correlation (80%).
Technical note: Correlation means that losses occur in “packets.” The link works for 0.5 seconds, then cuts out for 2 seconds, then resumes.
Test objective: This is the “Crash Test.”
Will your TCP/MMS sessions expire (timeout)? Will your VPN disconnect? Will critical GOOSE messages be lost?
Phase 4: Aggressive Handover (Satellite Search)
Duration: 10 seconds.
Context: The antenna detects the obstruction and switches urgently to another visible satellite (probably lower on the opposite horizon or at the zenith).
Characteristics: Data flow returns, but packet duplication occurs (2%). LEO networks often send duplicate data when changing routes to ensure delivery.
Test objective: Verify that the application does not crash when receiving duplicate or out-of-order packets (reordering).
Phase 5: Return to Normal (Acquisition Confirmed)
Duration: 165 seconds.
Context: The connection is reestablished on the new satellite.
Test objective: Measure the recovery time objective (RTO). If the connection was lost in Phase 3, does the application automatically reconnect here? If so, how long does it take?
Using this profile allows you to simulate the use case and answer a major industrial safety question:
“If a mountainous obstruction cuts off communication for 15 seconds, will my remote monitoring system simply lose monitoring data (acceptable), or will it lose total control, requiring human intervention to restart the connection (unacceptable)?”
Run Sequential Simulation with Latencetech Elina-TC
Marc Soulacroup
Comments