Satellite Communications in the New Space Era: A Survey and Future Challenges
Read full paper →- Authors
- Oltjon Kodheli, Eva Lagunas, Nicola Maturo, Shree Krishna Sharma, Bhavani Shankar, Jesús Fabián Mendoza Montoya, Juan Carlos Merlano Duncán, Danilo Spano, Symeon Chatzinotas, Steven Kisseleff, Jorge Querol, Lei Lei, Thang X. Vu, George Goussetis
- Journal
- IEEE Communications Surveys & Tutorials
- Year
- 2020
- Citations
- 1,291
TL;DR
This survey maps the current state and future trajectory of satellite communications, identifying that the shift from a few large geostationary satellites to massive low-Earth-orbit (LEO) constellations (e.g., Starlink, OneWeb) is the dominant technological shift, with implications for latency, coverage, and network integration that anyone running a personal experiment on connectivity or remote sensing should understand.
What they tested
This is a **survey paper** — it does not test a single intervention. Instead, it systematically reviews and synthesises the published academic and industry literature on satellite communications (SatComs) across five technical axes:
1. **System aspects** — constellation types (GEO, MEO, LEO), orbital mechanics, and satellite hardware evolution.
2. **Air interface** — waveforms, modulation, coding, and multiple access schemes.
3. **Medium access** — how satellites share spectrum and manage interference.
4. **Networking** — routing, handover, and integration with terrestrial networks (especially 5G).
5. **Testbeds & prototyping** — existing experimental platforms and their limitations.
The "outcome" is a structured map of the field, with identified gaps and open research challenges. The paper does not compare interventions head-to-head; it compares technological approaches (e.g., bent-pipe vs. regenerative satellites, LEO vs. GEO constellations) based on published performance metrics from other studies.
Who was studied
No human subjects were studied. The paper reviews approximately **300+ references** from academic journals, conference proceedings, industry white papers, and standards bodies (e.g., 3GPP, ITU). The "population" is the published literature on SatComs from roughly 2015–2020, with emphasis on works from IEEE, AIAA, and ESA.
How they measured it
The authors used a **structured literature review methodology** — not a meta-analysis with pooled statistics. They categorised papers by technical domain, extracted key performance indicators (KPIs) reported in those papers (e.g., data rate in Mbps, latency in ms, bit error rate, spectral efficiency in bps/Hz), and qualitatively compared findings. No formal effect-size calculation or statistical synthesis was performed.
Key metrics discussed across the reviewed literature include:
**Latency** (round-trip time, RTT, in ms)
**Data rate** (downlink/uplink in Mbps or Gbps)
**Spectral efficiency** (bps/Hz)
**Coverage** (percentage of Earth's surface or population)
**Number of satellites** in a constellation
**Orbital altitude** (km)
**Power consumption** (W per satellite)
**Cost per bit** (USD per Mbps)
Methodology
**Study design:** Narrative survey / systematic literature review. The authors searched for papers using keywords related to each of the five axes, filtered by relevance and publication venue quality, and then organised findings thematically.
**No randomisation, blinding, or washout** — this is not an experimental study. The design is descriptive and synthetic.
**Duration:** The review covers literature published primarily between 2015 and 2020, with some older foundational references.
**Statistical approach:** None. The paper uses descriptive statistics (counts of papers per topic, ranges of reported values) but no inferential statistics.
**What this design can prove:**
It can identify consensus and divergence in the literature.
It can map the landscape of active research areas.
It can highlight gaps where no or few studies exist.
It can summarise the range of reported performance for different technologies.
**What this design cannot prove:**
It cannot establish causal relationships (e.g., "LEO constellations cause lower latency than GEO" — that is a physical fact, not a causal claim tested here).
It cannot provide effect sizes with confidence intervals.
It cannot control for publication bias (papers reporting positive results are more likely to be published).
It cannot weigh studies by quality or sample size in a formal way.
**Major methodological weaknesses:**
No PRISMA-style systematic review protocol (no pre-registration, no explicit inclusion/exclusion criteria, no risk-of-bias assessment).
No quantitative synthesis (meta-analysis) — so claims like "LEO constellations achieve lower latency" are supported by citing individual papers, not by pooling data.
Industry-funded studies (e.g., from SpaceX, OneWeb, Airbus) are included without separate analysis of potential bias.
Rapidly evolving field — the survey was published in 2020, and major developments (e.g., Starlink's operational deployment, Amazon Kuiper's progress) have occurred since.
Key findings
The paper organises findings across five axes. Below are the most concrete, quantified takeaways:
**System aspects:**
LEO constellations (altitude ~500–1,500 km) achieve round-trip latencies of **20–50 ms**, compared to **250–600 ms** for GEO satellites (altitude ~35,786 km). This is a ~5–10× reduction.
Mega-constellations (e.g., Starlink planned ~12,000 satellites, OneWeb ~648) require **inter-satellite links (ISLs)** to route traffic without ground stations — a key technical challenge.
On-board processing (regenerative payloads) can reduce latency by **~20–30%** compared to bent-pipe architectures by avoiding double hops to ground.
**Air interface:**
Adaptive coding and modulation (ACM) can improve spectral efficiency by **30–50%** under clear-sky conditions compared to fixed schemes.
The DVB-S2X standard (used by many modern satellites) supports spectral efficiencies up to **~4.5 bps/Hz** in the forward link.
For LEO, Doppler shift can reach **±40 kHz** at Ku-band (12–18 GHz) and **±200 kHz** at Ka-band (26–40 GHz) — requiring advanced compensation algorithms.
**Medium access:**
Random access schemes (e.g., ALOHA variants) achieve throughput of only **~0.1–0.3 bps/Hz** under high load, while scheduled access (e.g., MF-TDMA) can reach **~0.8–0.9 bps/Hz**.
Cognitive radio techniques (dynamic spectrum sharing) are identified as a "promising but immature" approach, with only **~5–10 published testbed implementations** as of 2020.
**Networking:**
Integration with 5G requires handover latencies below **10 ms** for seamless user experience — current satellite handover times are reported in the **50–200 ms** range.
Software-defined networking (SDN) and network function virtualisation (NFV) are proposed to reduce network management overhead by **~40–60%** in simulation studies.
**Testbeds & prototyping:**
Only **~15–20 operational testbeds** exist worldwide as of 2020 (e.g., ESA's OPS-SAT, NASA's SCaN testbed).
Most testbeds are ground-based emulators, not in-orbit experiments — limiting validation of real-world effects like radiation, thermal cycling, and orbital dynamics.
Effect magnitude
Since this is a survey, "effect magnitude" applies to the differences between technological approaches reported in the reviewed literature:
**Latency reduction from GEO to LEO:** ~200–550 ms improvement. In practical terms, a video call via GEO satellite has a noticeable ~0.5–1 second delay (like talking over a bad international phone line), while LEO satellite latency is comparable to terrestrial broadband (~20–50 ms).
**Spectral efficiency gain from ACM:** ~30–50% improvement. This means a satellite can transmit ~1.3–1.5× more data per second using the same amount of spectrum — equivalent to upgrading from a 100 Mbps connection to 130–150 Mbps.
**Throughput loss from random to scheduled access:** ~3–9× worse. Random access (like Wi-Fi's CSMA/CA) works poorly when many users try to transmit simultaneously — scheduled access (like cellular) is far more efficient but requires coordination.
**Doppler shift magnitude:** ±40 kHz at Ku-band, ±200 kHz at Ka-band. For comparison, a typical FM radio station has a bandwidth of ~200 kHz — so Doppler shift alone could shift a signal by an entire channel width, requiring active compensation.
Limitations
**Acknowledged by authors:**
The field is evolving rapidly; the survey captures a snapshot as of early 2020.
The review is not exhaustive — some sub-topics (e.g., quantum communications via satellite, optical ISLs) are mentioned only briefly.
The paper focuses on technical aspects, not business models, regulatory frameworks, or space debris mitigation — all critical for real-world deployment.
**Critical reader observations:**
**No formal quality assessment:** Papers from top journals (e.g., IEEE JSAC) are treated similarly to conference papers and industry white papers. A study with n=1 simulation is given equal weight to a study with n=100.
**Publication bias:** The literature likely over-represents positive results (e.g., "our new algorithm improves throughput by 40%") and under-represents negative or null results (e.g., "our algorithm failed in real-world testing").
**Industry funding:** Many cited papers acknowledge funding from satellite operators (e.g., SES, Eutelsat, SpaceX). While not necessarily biasing results, this is not discussed.
**No replication analysis:** The survey does not identify which results have been independently replicated.
**Rapid obsolescence:** Since 2020, Starlink has launched >4,000 satellites and is operational in ~60 countries. Some claims about "future challenges" (e.g., "ISLs are not yet deployed") are now outdated.
**No human factors:** The survey does not address user experience, adoption barriers, or health/safety concerns (e.g., radiofrequency exposure from dense LEO constellations).
Practical takeaways
For someone running their own n=1 experiment related to satellite communications — whether testing a Starlink terminal, building a ground station, or evaluating satellite internet for remote work:
### What to test (specific intervention and dose)
**If testing satellite internet:** Compare a LEO satellite terminal (e.g., Starlink, OneWeb) vs. your current terrestrial connection (DSL, cable, 4G/5G). The "dose" is the service plan (e.g., Starlink Residential at ~$120/month).
**If testing a ground station:** Compare a low-cost software-defined radio (SDR) setup (e.g., RTL-SDR + LNA, ~$50) vs. a commercial receiver (e.g., Icom IC-9700, ~$1,500) for receiving LEO satellite signals (e.g., NOAA weather satellites at 137 MHz).
**If testing latency-sensitive applications:** Run a video call (Zoom, Teams) and a real-time game (e.g., Fortnite, CS:GO) over satellite vs. terrestrial, measuring ping, jitter, and packet loss.
### Minimum meaningful duration
**For satellite internet testing:** Run for at least **7–14 days** to capture daily and weekly usage patterns. Satellite performance varies with weather (rain fade at Ku/Ka bands), satellite position (for non-LEO), and network congestion.
**For ground station testing:** Run for **3–5 satellite passes** (each pass lasts ~10–15 minutes for LEO). Ensure passes occur at different times of day and different elevation angles.
**For latency testing:** Run **at least 20–30 test sessions** per condition (satellite vs. terrestrial) to get stable average and variance estimates.
### What to measure (specific metrics)
**Primary:** Round-trip latency (ping, ms) — use `ping -c 100 8.8.8.8` or a tool like `mtr`. Measure both average and 95th percentile.
**Secondary:** Download/upload speed (Mbps) — use `speedtest-cli` or `fast.com`. Run at least 5 tests per session.
**Tertiary:** Jitter (ms) — standard deviation of ping times. Packet loss (%) — count dropped packets over 100 pings.
**For ground station:** Signal-to-noise ratio (SNR, dB), Doppler shift (Hz), decoded image quality (for weather satellites — use a metric like SSIM or PSNR).
**For video calls:** Subjective quality rating (1–5 scale), number of freezes/dropouts per call, time to reconnect.
### Key confounds to control for
**Weather:** Rain, snow, and heavy clouds attenuate Ku/Ka-band signals. Log weather conditions daily (clear, cloudy, rain, snow). If possible, run tests only during clear weather for baseline comparison.
**Time of day:** Satellite internet can be congested during peak evening hours (7–10 PM local time). Run tests at the same time each day, or randomise test times across conditions.
**Satellite position:** For LEO constellations, the specific satellite serving you changes every few minutes. You cannot control this, but you can log which satellite is overhead (using tools like `gpredict` or Starlink's own app).
**Terrestrial backup:** Many satellite terminals fall back to terrestrial internet when signal is poor. Ensure you are actually testing the satellite link — disable Wi-Fi/cellular fallback if possible.
**Antenna placement:** For fixed satellite terminals, ensure the antenna has a clear view of the sky (no trees, buildings, or mountains in the line of sight). Log obstructions.
**Your own network:** Other devices on your home network can consume bandwidth. Run tests during low-usage periods (e.g., 2–4 AM) or disconnect other devices.
### What a positive result would look like
**For latency:** LEO satellite ping < 50 ms average, with < 10 ms jitter and < 1% packet loss. Compare to your terrestrial baseline — if terrestrial is already < 20 ms, the satellite may not be an improvement for gaming.
**For speed:** LEO satellite download > 100 Mbps (Starlink claims 50–200 Mbps). Upload > 10 Mbps. If you get < 20 Mbps consistently, something is wrong (congestion, obstruction, or equipment issue).
**For ground station:** Successful decoding of a NOAA APT weather image with visible cloud patterns and coastlines. SNR > 10 dB at peak elevation. Doppler shift within ±3 kHz of predicted value.
**For video calls:** No freezes or dropouts in a 30-minute call. Subjective quality rating of 4 or 5 out of 5. Time to reconnect after a dropout < 10 seconds.
**For your personal experiment:** A clear, reproducible difference between conditions (satellite vs. terrestrial) that is larger than the day-to-day variability within each condition. For example: "Satellite ping averaged 35 ms (SD = 8 ms) over 14 days, while terrestrial ping averaged 12 ms (SD = 3 ms) — a 23 ms difference that was consistent across weather conditions."