Everything we have built so far in this book operates within a radius that you could, in principle, walk across. Mesh networks span neighborhoods. LoRa links reach a few kilometers. Community WISPs cover a city. Even the longest ham radio VHF link — carefully engineered with tall towers and high-gain antennas — tops out at perhaps a hundred kilometers before the curvature of the earth makes the geometry impossible.
But the world is not organized in hundred-kilometer circles. The village that needs internet access is 300 kilometers from the nearest fiber landing point, separated by mountain ranges that block every line-of-sight path you could imagine. The remote research station sits on an island 2,000 kilometers from the mainland. The disaster zone has lost every piece of telecommunications infrastructure within a 500-kilometer radius, and relief coordinators need connectivity now, not in the months it takes to rebuild towers and splice fiber.
This is the long-range challenge, and it is where alternative network builders must look upward — literally — and embrace technologies that span hundreds or thousands of kilometers in a single hop. Satellite links. Long-range microwave bridges. Free-space optical systems. High-altitude platforms hovering in the stratosphere. These are the technologies that connect the disconnected, that bridge the gaps too wide for any terrestrial solution, and that provide the backhaul arteries feeding your local mesh networks.
This chapter is about all of them. We will start with the physics of why long-range communication is fundamentally hard, then work through every major technology for spanning large distances: satellite constellations from geostationary to low Earth orbit, DIY satellite ground stations you can build with cheap SDR hardware, point-to-point wireless bridges that reach 100+ kilometers, microwave backbone links, laser communication through the atmosphere, and the delightfully mad concept of using balloons and drones as floating cell towers.
By the end, you will understand the trade-offs well enough to choose the right long-range technology for your specific situation — and you will have built a Python tool for calculating link budgets that tells you whether your ambitious plan to bridge two mountaintops 80 kilometers apart is physically feasible before you spend a dollar on equipment.
Let us start with why this problem is so hard.
Radio waves, in free space, obey the inverse-square law: the power density of a signal decreases with the square of the distance from the transmitter. Double the distance, and you receive one-quarter the power. Ten times the distance, one-hundredth the power. This is not an engineering limitation you can work around with better equipment — it is a fundamental property of electromagnetic radiation spreading through three-dimensional space.
The free-space path loss (FSPL) in decibels is given by:
\[FSPL(dB) = 20 \log_{10}(d) + 20 \log_{10}(f) + 20 \log_{10}\left(\frac{4\pi}{c}\right)\]where $d$ is the distance in meters, $f$ is the frequency in hertz, and $c$ is the speed of light. For a 5 GHz signal traveling 100 kilometers, the path loss is approximately 143 dB. That means the received signal is $10^{14.3}$ times weaker than the transmitted signal — roughly twenty trillion times weaker. And that is in free space, with nothing between the transmitter and receiver but vacuum.
In reality, it is worse. The atmosphere absorbs and scatters radio energy, particularly at higher frequencies. Rain attenuates signals severely above 10 GHz — an effect called rain fade that can add 10–20 dB of additional loss during heavy storms. Foliage, buildings, and terrain features scatter and reflect signals, creating multipath interference. And the earth itself gets in the way.
The earth is round. This obvious fact creates a non-obvious problem for long-range terrestrial links: beyond a certain distance, the curvature of the earth blocks the line of sight between two antennas. The radio horizon — the maximum distance at which a direct line-of-sight path exists — depends on the height of the antennas:
\[d_{max} \approx 4.12 \times (\sqrt{h_1} + \sqrt{h_2}) \text{ km}\]where $h_1$ and $h_2$ are the antenna heights in meters, and the factor 4.12 accounts for the standard refraction of radio waves bending slightly around the earth’s curvature.
For two antennas mounted at 10 meters height — say, on the roof of a two-story building — the maximum line-of-sight distance is about 26 kilometers. To reach 100 kilometers, you need towers roughly 150 meters tall. To reach 200 kilometers, you need towers at 600 meters — which is taller than any communications tower ever built. The geometry is brutally unfavorable.
Mountains and tall ridgelines can substitute for towers — and many of the world’s best long-range wireless links exploit mountain-to-mountain line of sight — but this requires geography to cooperate, which it often does not.
You might ask: why not just lay fiber optic cable? Fiber solves the bandwidth problem definitively — a single strand of modern fiber can carry terabits per second over thousands of kilometers. And indeed, fiber is the backbone of the global internet. But fiber has a cost problem that makes it impractical for many alternative network scenarios.
Laying fiber in developed areas costs roughly $20,000–$60,000 per kilometer when you account for trenching, permits, right-of-way agreements, and labor. In rough terrain — mountains, forests, swamps — costs can exceed $100,000 per kilometer. Submarine fiber cables cost $30,000–$50,000 per kilometer, and a transatlantic cable costs upward of $300 million. For a rural community 200 kilometers from the nearest fiber point of presence, the cost of a fiber connection exceeds $4 million — money that simply does not exist.
This is the last-mile problem taken to its extreme. The backbone infrastructure exists — undersea cables, cross-continental fiber routes, metropolitan fiber rings — but extending it to every community, village, and homestead is economically impossible at current costs. And it is precisely these unconnected and underconnected communities that alternative networks aim to serve.
Wireless long-range links — whether satellite, microwave, or point-to-point Wi-Fi — exist precisely to fill this gap. They are not better than fiber. They have less bandwidth, higher latency, and greater susceptibility to weather. But they can be deployed in days rather than months, at costs measured in thousands of dollars rather than millions, to locations that fiber will never reach.
The oldest and most established satellite internet technology uses geostationary Earth orbit (GEO) satellites positioned approximately 35,786 kilometers above the equator. At this altitude, a satellite’s orbital period matches the earth’s rotation — the satellite appears to hang motionless in the sky, which means ground antennas can point at a fixed location without needing to track a moving target.
A single GEO satellite can see roughly one-third of the earth’s surface, and three satellites spaced 120 degrees apart can provide nearly global coverage (minus the polar regions). This is an enormously efficient architecture — three satellites, three sets of ground infrastructure, global reach. Companies like Hughes Network Systems (HughesNet), Viasat, and SES have operated GEO satellite internet services for decades.
The catch is physics. A signal traveling to a GEO satellite and back covers roughly 72,000 kilometers. Even at the speed of light, this round trip takes approximately 240 milliseconds — and that is just the propagation delay. Add in processing, queuing, and protocol overhead, and real-world GEO satellite latency is typically 550–700 milliseconds. For web browsing, this is tolerable but sluggish. For video conferencing, it is painful. For online gaming or real-time voice communication, it is essentially unusable.
VSAT (Very Small Aperture Terminal) is the standard technology for GEO satellite internet. A typical VSAT installation consists of a dish antenna (0.75–2.4 meters diameter), a block upconverter/low-noise block downconverter (BUC/LNB) mounted at the dish’s focal point, and an indoor modem. Ku-band (12–18 GHz) and Ka-band (26.5–40 GHz) are the most common frequency bands. Modern VSAT systems can deliver 25–100 Mbps download speeds to consumer terminals, with upload speeds of 3–10 Mbps.
For alternative networks in remote locations, GEO VSAT has been the default backhaul technology for twenty years. It is expensive — typically $100–$300 per month for consumer plans with restrictive data caps — and the latency makes many applications frustrating. But it works, virtually everywhere on the planet between roughly 70°N and 70°S latitude, and it has been the only option for countless remote communities.
Medium Earth orbit (MEO) satellites orbit at altitudes between 2,000 and 35,786 kilometers. They move relative to the ground, requiring tracking antennas or constellations large enough to ensure continuous coverage, but their lower altitude significantly reduces latency compared to GEO.
The most prominent MEO internet constellation is O3b (now part of SES), whose name stands for “Other 3 Billion” — a reference to the roughly three billion people without reliable internet access when the constellation was planned. O3b operates at approximately 8,000 kilometers altitude, resulting in round-trip latency of around 150 milliseconds — less than one-third of GEO latency.
O3b satellites provide high-throughput connectivity (multiple Gbps per satellite) to ground stations that serve as backhaul for cellular networks, ISPs, and enterprise customers in underserved regions. The service is not consumer-facing — you do not buy an O3b subscription for your house. Instead, telecom operators and large organizations purchase O3b capacity and distribute it to end users through terrestrial infrastructure.
The SES mPOWER constellation, launched starting in 2022, extends O3b’s capabilities with higher throughput and more flexible beam placement. For alternative network builders, MEO constellations like O3b are relevant primarily as a backhaul technology — you would connect your community network’s central hub to an O3b ground station, then distribute connectivity locally through your mesh or WISP infrastructure.
The single most disruptive development in satellite internet — and arguably in global telecommunications — is the emergence of Low Earth Orbit (LEO) satellite mega-constellations. Operating at altitudes of 340–1,200 kilometers, LEO satellites are close enough to the ground that radio signals make the round trip in 4–40 milliseconds, producing end-to-end latencies of 20–60 milliseconds. This is comparable to many terrestrial broadband connections and dramatically changes what satellite internet can do.
Starlink, operated by SpaceX, is the dominant LEO constellation. As of 2025, Starlink operates over 6,000 satellites in orbit, serving millions of subscribers in more than 70 countries. The service delivers typical download speeds of 50–200 Mbps (with bursts to 300+ Mbps in some areas) and upload speeds of 10–40 Mbps, at latencies of 20–50 milliseconds. The standard consumer terminal — a phased-array flat-panel antenna that electronically steers its beam to track satellites crossing the sky — costs approximately $499, with monthly service at $120 in the United States.
Starlink is transformative for alternative networks. Where previous satellite technologies offered megabits at hundreds of milliseconds of latency, Starlink delivers tens or hundreds of megabits at latencies indistinguishable from cable internet. For a remote community building a local mesh or WISP, a Starlink terminal can serve as a high-performance backhaul — the gateway connecting the local network to the global internet — at a cost that a community cooperative can realistically afford.
OneWeb operates a constellation of approximately 650 satellites at 1,200 kilometers altitude, targeting enterprise, government, maritime, and aviation markets. OneWeb does not offer direct-to-consumer service; instead, it sells capacity to distribution partners who provide last-mile connectivity. For alternative networks, OneWeb is relevant as a backhaul provider, particularly in high-latitude regions where its polar orbit inclination provides better coverage than Starlink’s initial shell.
Amazon Kuiper is Amazon’s planned LEO constellation of 3,236 satellites. Still in the deployment phase as of 2025, Kuiper aims to compete directly with Starlink in the consumer and enterprise broadband markets. Amazon’s vast logistics and cloud infrastructure give it potential advantages in distribution and integration with AWS services.
Telesat Lightspeed is a Canadian constellation focused on enterprise, government, and aeronautical connectivity, with fewer satellites but inter-satellite laser links for global low-latency routing.
| Parameter | GEO | MEO (O3b) | LEO (Starlink) |
|---|---|---|---|
| Altitude | ~35,786 km | ~8,000 km | 340–550 km |
| Round-trip latency | 550–700 ms | 120–150 ms | 20–50 ms |
| Coverage per satellite | ~1/3 of Earth | Regional beams | Small footprint |
| Satellites needed for global coverage | 3 | 20+ | 1,500–40,000+ |
| Typical consumer bandwidth | 25–100 Mbps | N/A (enterprise) | 50–200 Mbps |
| Terminal cost | $300–$2,000 | $10,000+ | $499 |
| Monthly service cost | $100–$300 | N/A | $120 |
| Works in rain | Degrades at Ka-band | Degrades at Ka-band | Degrades in heavy rain |
| Antenna tracking needed | No (fixed dish) | Yes (motorized) | Yes (phased array) |
| Best for | Backup connectivity, maritime, rural voice | Enterprise backhaul | Consumer broadband, community backhaul |
The trend is unmistakable: LEO constellations are making satellite internet competitive with terrestrial broadband for the first time. For alternative network builders, this is a paradigm shift. Satellite is no longer the technology of last resort, tolerated for its reach despite its limitations. LEO satellite is now a viable primary backhaul technology, and its performance will only improve as constellations grow and inter-satellite laser links enable truly global low-latency routing.
You do not need a $500 Starlink terminal or a $10,000 VSAT dish to interact with satellites. The radio spectrum is full of satellite signals that you can receive with inexpensive hardware — and building a satellite ground station is one of the most rewarding projects in the alternative networking space, combining radio engineering, orbital mechanics, and real-time signal processing.
The entry point is weather satellite imagery. Polar-orbiting weather satellites — NOAA-15, NOAA-18, NOAA-19, and the Russian Meteor-M series — continuously broadcast images of the earth’s surface as they orbit. These broadcasts use frequencies around 137 MHz (VHF) and are specifically designed to be received with simple equipment. The protocol used by NOAA satellites is called APT (Automatic Picture Transmission), and it has been in use since the 1960s. Meteor-M satellites use the more modern LRPT (Low Rate Picture Transmission) protocol, which provides higher-resolution digital imagery.
Here is what you need to receive weather satellite images:
An SDR receiver. A RTL-SDR dongle — a USB device based on the Realtek RTL2832U chip — costs $25–$35 and can receive signals from 24 MHz to 1.7 GHz. For weather satellite reception, it works perfectly.
A suitable antenna. The standard antenna for 137 MHz satellite reception is a turnstile antenna or a quadrifilar helix (QFH) antenna. Both are circularly polarized, matching the polarization of the satellite signals, and have a hemispherical radiation pattern that receives signals from the entire sky above. You can build a QFH antenna from PVC pipe and coaxial cable for under $20 in materials. Commercial QFH antennas designed for satellite reception cost $50–$100.
Software. On Linux, the standard stack is rtl_fm for SDR reception, combined with WXtoImg or SatDump for decoding and rendering the images. GPredict provides satellite tracking, showing you when each satellite will pass overhead so you know when to start recording.
# Calculate the next pass of NOAA-19 over your location
# using the skyfield library for orbital mechanics
from skyfield.api import load, EarthSatellite, wgs84
ts = load.timescale()
tle_line1 = "1 33591U 09005A 25084.51263889 .00000092 00000+0 73021-4 0 9993"
tle_line2 = "2 33591 99.1634 110.5464 0013587 225.6498 134.3441 14.12588827827810"
satellite = EarthSatellite(tle_line1, tle_line2, "NOAA 19", ts)
my_location = wgs84.latlon(48.8566, 2.3522) # Paris
t0 = ts.now()
t1 = ts.tt_jd(t0.tt + 1) # Search next 24 hours
times, events = satellite.find_events(my_location, t0, t1, altitude_degrees=10.0)
for ti, event in zip(times, events):
name = ("Rise", "Culmination", "Set")[event]
print(f"{ti.utc_strftime('%Y-%m-%d %H:%M:%S')} UTC — {name}")
A typical NOAA satellite pass lasts 10–15 minutes as the satellite crosses the sky. During this time, the APT signal encodes a continuous image strip at roughly 4 km/pixel resolution — enough to see cloud formations, weather fronts, sea surface temperature patterns, and large-scale terrain features. It is genuinely thrilling to watch an image of your region assembling line by line from a signal you are plucking out of the sky with twenty dollars of wire and pipe.
If a single ground station can receive satellite passes overhead, a network of ground stations can receive passes everywhere. This is the concept behind SatNOGS (Satellite Networked Open Ground Station), a project of the Libre Space Foundation that has built the world’s largest open-source satellite ground station network.
SatNOGS provides open-source hardware designs and software for building automated ground stations. A SatNOGS station consists of an SDR receiver, a motorized antenna rotator that tracks satellites across the sky, and a Raspberry Pi or similar computer running the SatNOGS client software. When a satellite passes overhead, the station automatically tunes to the correct frequency, tracks the satellite, records the signal, and uploads the recording and decoded data to the SatNOGS database — all without human intervention.
As of 2025, the SatNOGS network has over 400 active ground stations on six continents, collectively performing thousands of satellite observations per day. The data is freely available to anyone. For alternative network builders, SatNOGS represents two things: first, a practical template for building automated satellite ground stations using open-source tools; and second, a demonstration of how distributed volunteer infrastructure can provide global-scale capability without centralized resources.
Beyond receiving weather imagery, you can use SDR and tracking software to monitor a wide variety of satellite signals: AIS (ship tracking) signals retransmitted by satellites, ADS-B (aircraft tracking), amateur radio satellites, and even signals from the International Space Station. The ISS regularly transmits SSTV (Slow-Scan Television) images on 145.800 MHz that can be received with a handheld radio and decoded on a phone.
# Simple satellite footprint calculator
# Given orbital altitude, compute the ground coverage radius
import math
def satellite_footprint_km(altitude_km):
"""Calculate the ground footprint radius of a satellite."""
R_earth = 6371 # Earth's radius in km
# Half-angle from satellite to Earth's horizon
rho = math.acos(R_earth / (R_earth + altitude_km))
# Ground distance along Earth's surface
footprint_radius = R_earth * rho
return footprint_radius
for alt in [550, 1200, 8000, 35786]:
radius = satellite_footprint_km(alt)
print(f"Altitude {alt:>6} km → footprint radius {radius:,.0f} km")
For the alternative networking community, DIY satellite ground stations serve as both a learning platform and a practical capability. They teach radio engineering, orbital mechanics, and signal processing. And for communities planning to use LEO satellite services like Starlink as backhaul, understanding satellite geometry and coverage patterns is directly relevant to network planning.
When most people think of Wi-Fi, they think of the router in their living room covering a 30-meter radius. But the same radio technology — or more precisely, the same unlicensed spectrum at 2.4 GHz and 5 GHz — can be engineered to span distances of 10, 50, and even 100+ kilometers using high-gain directional antennas, carefully designed link geometry, and purpose-built outdoor equipment.
The world record for a Wi-Fi link, set in 2007 by the Venezuelan nonprofit Fundación Escuela Latinoamericana de Redes (EsLaRed), stands at 382 kilometers — a single hop between two mountaintops in the Andes, using modified 802.11b equipment and enormous parabolic dish antennas. While this was a research demonstration rather than a production link, it proved that the physics support extraordinary range when you have clear line of sight, high antenna gain, and enough patience with link alignment.
For practical alternative networks, point-to-point (PtP) wireless bridges in the 10–100 kilometer range are the workhorse technology for connecting distant sites. A typical deployment connects two locations — perhaps a hilltop tower with internet backhaul and a community center in a valley 30 kilometers away — using a pair of directional radios with integrated high-gain antennas.
Three manufacturers dominate the long-range wireless bridge market for community and small ISP networks, and choosing between them is one of the first practical decisions you will make.
Ubiquiti Networks produces the airMAX line of point-to-point and point-to-multipoint radios that have become the default choice for community networks worldwide. The PowerBeam and NanoBeam series operate in the 5 GHz band and can achieve 100–450 Mbps throughput at distances of 5–30+ kilometers, at price points of $80–$200 per radio. For higher-performance links, the airFiber line operates in 5 GHz, 24 GHz, and 60 GHz bands, delivering 500 Mbps to 2+ Gbps at distances up to 20+ kilometers, priced at $200–$500 per radio.
Ubiquiti’s great strength is price-to-performance ratio and ubiquity. The equipment is affordable, widely available, well-documented, and supported by a large community. Its weakness is reliability at the extremes — the equipment is consumer-grade, and Ubiquiti’s software (airOS) can be buggy. For mission-critical backbone links, some operators prefer the next option.
MikroTik produces a range of wireless products that are more flexible (and more complex) than Ubiquiti’s offerings. MikroTik’s RouterOS operating system is extraordinarily powerful, supporting advanced routing, firewall, VPN, and traffic management features that rival enterprise equipment at a fraction of the cost. For long-range wireless, the SXT, LHG, and Cube Lite60 products cover distances from a few kilometers to 40+ kilometers. MikroTik’s NetMetal series supports 802.11ac wave 2 with external antennas, allowing you to pair the radio with whatever antenna suits your link geometry.
MikroTik’s strength is flexibility and the depth of RouterOS. Its weakness is the learning curve — RouterOS configuration feels like programming, not like using a web GUI, and making mistakes can take your link offline or create security vulnerabilities. For alternative network builders with strong networking knowledge, MikroTik is an excellent choice.
Cambium Networks occupies the professional and carrier-grade end of the market. The ePMP series (elevated Performance Multi-Point) competes with Ubiquiti airMAX, while the PTP series provides high-reliability point-to-point links with features like adaptive modulation, GPS synchronization, and spectrum analysis. Cambium equipment is more expensive than Ubiquiti or MikroTik, but it is engineered for reliability in demanding environments and backed by professional support.
For a community network backbone, a reasonable approach is: Cambium or MikroTik for critical backbone links where uptime is paramount, Ubiquiti for access-layer links where cost matters more, and MikroTik routers at major nodes for traffic management.
You cannot simply point two radios at each other and hope for the best. A long-range wireless link requires careful planning to ensure that the radio path is not just theoretically clear but practically viable. The two critical concepts are Fresnel zones and earth curvature.
Fresnel zones are ellipsoidal regions surrounding the direct line-of-sight path between two antennas. The first Fresnel zone — the most important — is an ellipsoid whose radius at the midpoint is given by:
\[r_1 = 17.32 \sqrt{\frac{d}{4f}}\]where $r_1$ is the radius in meters, $d$ is the total link distance in kilometers, and $f$ is the frequency in GHz. For a 20 km link at 5 GHz, the first Fresnel zone radius at the midpoint is approximately 17.3 meters.
Why does this matter? Radio waves do not travel in a perfect ray — they spread out in a wave. If an obstacle penetrates the first Fresnel zone, even without blocking the direct line of sight, it causes signal loss through diffraction. The rule of thumb is that the first Fresnel zone should be at least 60% clear of obstacles for a reliable link.
Earth curvature causes the ground to “bulge” upward in the middle of a long link. The height of this bulge at the midpoint is approximately:
\[h_{bulge} = \frac{d^2}{8 \times k \times R_e}\]where $d$ is the link distance, $R_e$ is the earth’s radius (6,371 km), and $k$ is the effective earth radius factor, typically 4/3 (1.333) to account for atmospheric refraction. For a 30 km link, the earth bulge at the midpoint is about 13 meters — meaning you need your antennas high enough that this 13-meter hump does not obstruct the Fresnel zone.
# Calculate Fresnel zone clearance requirements
import math
def link_clearance(distance_km, freq_ghz, k=1.333):
"""Calculate required clearance for a wireless link."""
R_e = 6371 # Earth radius in km
# First Fresnel zone radius at midpoint (meters)
fresnel_r = 17.32 * math.sqrt(distance_km / (4 * freq_ghz))
# Earth bulge at midpoint (meters)
earth_bulge = (distance_km * 1000) ** 2 / (8 * k * R_e * 1000)
# Total clearance needed (60% Fresnel + earth bulge)
total_clearance = 0.6 * fresnel_r + earth_bulge
return fresnel_r, earth_bulge, total_clearance
for d in [5, 10, 20, 30, 50]:
fz, eb, tc = link_clearance(d, 5.0)
print(f"{d:>3} km: Fresnel={fz:.1f}m, "
f"Earth bulge={eb:.1f}m, Need {tc:.1f}m clearance")
These calculations tell you the minimum tower height required for a viable link. If the terrain between your sites is flat, you need towers at least as tall as the total clearance value. If there is a hill in the middle, you need to ensure the hill does not penetrate the 60% Fresnel zone after accounting for earth curvature.
Professional link planning uses tools like Ubiquiti’s airLink, MikroTik’s link planning tool, or the open-source Radio Mobile software, which combine terrain elevation data (from sources like SRTM — Shuttle Radar Topography Mission) with propagation models to produce detailed path profiles showing every obstacle along the link path.
While unlicensed Wi-Fi bands are excellent for access and distribution layers, the backbones of serious communication networks — telecom carriers, ISPs, government networks — often rely on licensed microwave links. These operate in frequency bands from 6 GHz to 80+ GHz, under licenses obtained from national spectrum regulators, and they deliver the kind of reliability and performance that critical infrastructure demands.
Licensed microwave has several advantages over unlicensed equipment:
No interference. Your licensed frequency is yours alone — no neighbor’s Wi-Fi router, no competing WISP, no rogue access point can interfere with your signal. This guarantees consistent performance regardless of what other radio equipment is operating in the area.
Higher power. Licensed microwave links can transmit at higher power levels than unlicensed equipment, improving link margin and reliability in adverse weather.
Larger channel widths. Licensed bands often permit channel widths of 56 MHz or more, enabling throughput of 1 Gbps or higher per link.
Regulatory protection. If someone does interfere with your licensed link, you have legal recourse. The spectrum regulator will act to resolve the interference.
The trade-off is cost and complexity. Licensed microwave equipment from manufacturers like Ericsson (formerly MINI-LINK), Nokia, Ceragon, DragonWave, and Aviat Networks costs $5,000–$50,000 per link. Spectrum licenses involve application fees, annual costs, and coordination studies. Installation requires professional antenna alignment with tolerances of fractions of a degree.
For alternative networks, licensed microwave is typically justified only for critical backbone links — the primary backhaul connecting a community network to an internet exchange or upstream provider. A common architecture uses a single licensed microwave link for the backbone (ensuring reliable, interference-free connectivity) and unlicensed equipment (Ubiquiti, MikroTik) for the distribution network.
| Band | Frequency Range | Typical Use | Max Distance | Rain Sensitivity |
|---|---|---|---|---|
| 6 GHz | 5.925–6.425 GHz | Long backbone links | 60+ km | Low |
| 11 GHz | 10.7–11.7 GHz | Medium backbone | 40 km | Moderate |
| 18 GHz | 17.7–19.7 GHz | Urban backbone | 20 km | High |
| 23 GHz | 21.2–23.6 GHz | Short backbone, access | 15 km | High |
| 60 GHz | 57–66 GHz | Short-range, unlicensed | 2 km | Very high |
| 70/80 GHz (E-band) | 71–76 / 81–86 GHz | High-capacity short links | 5 km | Very high |
The general pattern: lower frequencies travel farther and handle rain better, but require larger antennas and offer less bandwidth. Higher frequencies deliver enormous bandwidth but are limited in range and severely affected by rain. The 60 GHz band is particularly notable because it is unlicensed in most jurisdictions — oxygen molecules in the atmosphere absorb 60 GHz radiation strongly, which limits range to 1–2 kilometers but also means the signal does not propagate far enough to cause interference, making licensing unnecessary. Products like the Ubiquiti airFiber 60 and the MikroTik Cube 60G exploit this band for short-range gigabit links.
The E-band (71–76 GHz and 81–86 GHz) represents a particularly interesting opportunity for alternative networks. The enormous bandwidth available — 10 GHz total across the two sub-bands — enables multi-gigabit throughput. And in many countries, E-band licensing uses a light licensing regime: fees are minimal (sometimes just a registration), coordination requirements are simple, and licenses can be obtained in days rather than months.
E-band links can deliver 10+ Gbps at distances up to 5 kilometers in clear weather, making them suitable for backbone links within a community network or between adjacent communities. The equipment is still more expensive than unlicensed alternatives, but prices have dropped significantly — a full E-band link can now be deployed for $3,000–$8,000, which is within reach of a well-funded community network project.
Free-space optical (FSO) communication uses laser or LED beams to transmit data through the atmosphere without fiber. The concept is elegant: take the same optical communication technology used in fiber optics — laser transmitters, photodetectors, high-speed modulation — and point it through the air instead of through glass.
FSO links operate at wavelengths of 780–1,600 nanometers (near-infrared and infrared), which are invisible to the human eye. Because optical frequencies are enormously higher than radio frequencies, the available bandwidth is correspondingly enormous — FSO links can deliver 1–10+ Gbps over distances of a few hundred meters to several kilometers.
The advantages of FSO are compelling:
No spectrum licensing required. Optical frequencies are not regulated as radio spectrum, so FSO links can be deployed without licenses, coordination, or fees.
No radio interference. FSO links neither cause nor are affected by radio frequency interference.
Very high bandwidth. Multi-gigabit speeds are standard.
Physical security. The laser beam is extremely narrow — typically a few milliradians divergence — making it nearly impossible to intercept without physically placing a detector in the beam path.
The disadvantage is equally compelling: atmospheric sensitivity. Fog, heavy rain, snow, and even heat shimmer (scintillation) can severely attenuate or completely block an optical beam. Fog is the worst offender — dense fog can cause 100+ dB/km of attenuation at optical wavelengths, which is enough to kill any FSO link over any practical distance. Rain is less severe (typically 3–15 dB/km), and clear-air scintillation can cause signal fluctuations of 5–10 dB.
The practical upshot is that FSO is a fair-weather technology — or more precisely, a clear-air technology. In climates with frequent fog or persistent low clouds, FSO is unreliable. In dry, clear climates (deserts, high-altitude locations, Mediterranean regions), FSO can be remarkably effective. Many production FSO deployments use hybrid links that combine FSO with a radio backup: the FSO carries traffic in clear weather at multi-gigabit speeds, and when fog or heavy rain degrades the optical path, traffic fails over to a radio link at lower bandwidth but higher atmospheric tolerance.
Manufacturers of commercial FSO equipment include fSONA, LightPointe, CableFree, and KORUZA (an open-source FSO system from the Institute IRNAS in Slovenia). The KORUZA project is particularly interesting for alternative networks — it provides open-source hardware designs, firmware, and alignment tools for building FSO links at a fraction of the cost of commercial systems.
# Estimate FSO link margin under different weather conditions
def fso_link_margin(distance_km, tx_power_dbm, rx_sensitivity_dbm,
tx_aperture_m=0.1, rx_aperture_m=0.1,
attenuation_db_per_km=0.5):
"""Estimate FSO link feasibility under given atmospheric conditions."""
import math
wavelength_m = 1.55e-6 # 1550 nm
# Geometric loss (beam divergence)
divergence_rad = 1.22 * wavelength_m / tx_aperture_m
beam_radius = distance_km * 1000 * divergence_rad
geometric_loss_db = 20 * math.log10(rx_aperture_m / beam_radius)
# Atmospheric loss
atm_loss_db = attenuation_db_per_km * distance_km
# Total received power
rx_power = tx_power_dbm + geometric_loss_db - atm_loss_db
margin = rx_power - rx_sensitivity_dbm
return margin, rx_power
conditions = [("Clear air", 0.5), ("Light rain", 6),
("Heavy rain", 15), ("Light fog", 30), ("Dense fog", 120)]
for name, atten in conditions:
margin, rx = fso_link_margin(1.0, 10, -40, attenuation_db_per_km=atten)
status = "✓ OK" if margin > 0 else "✗ FAIL"
print(f"{name:<12}: margin={margin:+.1f} dB {status}")
Sometimes the challenge is not raw distance but elevation. A wireless link needs line of sight, and when terrain features block every possible ground-level path, the solution is to put the radio in the sky. Not in orbit — that is satellite territory — but in the atmosphere, at altitudes of 10–25 kilometers, in the region between aircraft cruising altitude and the edge of space. These are High-Altitude Platform Stations (HAPS), and they represent a middle ground between terrestrial and satellite infrastructure.
The most ambitious HAPS project was Google Loon (later Loon LLC), which from 2011 to 2021 developed a system of stratospheric balloons at approximately 20 kilometers altitude that provided LTE cellular coverage to areas below. Each balloon was essentially a floating cell tower, with solar panels for power, LTE base station equipment as payload, and altitude control via pumping air between an inner ballonet and the outer balloon envelope to catch wind currents moving in different directions at different altitudes.
Loon demonstrated genuinely impressive technology. The balloons navigated using machine learning models that predicted stratospheric wind patterns and adjusted altitude to “sail” to target locations. In 2017, Loon provided emergency connectivity to Puerto Rico after Hurricane Maria, serving over 200,000 people. In 2020, Loon launched commercial service in Kenya through a partnership with Telkom Kenya.
Loon shut down in January 2021. The economics never worked — the cost of manufacturing, launching, and managing thousands of balloons to maintain continuous coverage was too high relative to the revenue from the sparse populations the balloons were designed to serve. But Loon proved several concepts that remain relevant: stratospheric platforms can provide useful coverage over enormous areas (a single balloon covered approximately 5,000 square kilometers), the technology works, and the need for connectivity in unserved areas is real.
Several HAPS concepts remain active:
Tethered aerostats (essentially, large blimps on cables) are used by military and border security organizations to provide persistent surveillance and communication coverage from altitudes of 3,000–5,000 meters. The US military’s JLENS and TARS programs deployed aerostats along the southern US border. For civilian alternative networks, smaller tethered aerostats could provide elevated relay points for wireless links — lifting an antenna to 500–1,000 meters dramatically extends line-of-sight coverage. Companies like Altaeros have developed tethered aerostat platforms specifically for telecommunications.
Solar-powered drones can maintain station at high altitudes for days or weeks, carrying telecommunications payloads. Airbus Zephyr has demonstrated flights of over 60 days at 20+ kilometers altitude. SoftBank’s HAPSMobile (now part of SpaceCOMPASS) is developing the Sunglider, a solar-powered HAPS drone for telecommunications. These platforms could provide connectivity equivalent to satellite coverage but with lower latency and higher bandwidth, since the platform is 20 kilometers up rather than 550.
Drone relay stations at lower altitudes (100–500 meters) are a more accessible technology for alternative network builders. A commercial quadcopter or fixed-wing drone carrying a lightweight radio can serve as a temporary elevated relay point — useful for disaster response, event coverage, or testing link geometry before committing to tower construction. Flight time is limited (20–60 minutes for battery-powered multicopters, several hours for fixed-wing drones, potentially much longer for tethered drones with ground power), but for temporary connectivity, it can be invaluable.
# Compare coverage radius at different platform altitudes
import math
def coverage_radius_km(altitude_m, min_elevation_deg=5):
"""Estimate ground coverage radius for a platform at given altitude."""
R = 6371e3 # Earth radius in meters
# For low altitudes, simplified calculation
# At minimum elevation angle
theta = math.radians(min_elevation_deg)
# Slant range to horizon at min elevation
r_ground = altitude_m / math.tan(theta)
return r_ground / 1000
platforms = [
("Cell tower (30m)", 30), ("Tethered aerostat (1km)", 1000),
("Drone relay (300m)", 300), ("HAPS (20km)", 20000),
("LEO satellite (550km)", 550000),
]
for name, alt in platforms:
r = coverage_radius_km(alt)
area = math.pi * r ** 2
print(f"{name:<28} → radius {r:>8,.1f} km, "
f"area {area:>12,.0f} km²")
Every networking technology we have discussed in this book assumes, at some level, that communication is instantaneous — or close enough. TCP expects acknowledgments within seconds. HTTP expects responses within milliseconds. Even our LoRa mesh networks assume that a message sent now will arrive within minutes.
But some long-range scenarios break this assumption entirely. A satellite in a polar orbit may only be visible from your ground station for 10 minutes per orbit, with 90-minute gaps between passes. A data mule — a vehicle physically carrying data between disconnected locations — might make the trip once a day. A deep-space probe is light-minutes or light-hours from Earth. In these scenarios, conventional networking protocols collapse. TCP’s three-way handshake cannot complete when the round-trip time is 40 minutes. HTTP cannot function when the server is unreachable 90% of the time.
Delay-Tolerant Networking (DTN) is a family of protocols and architectures designed for exactly these conditions. Originally developed for interplanetary communication by the Interplanetary Networking Special Interest Group (IPNSIG), largely driven by Vint Cerf (yes, that Vint Cerf — co-creator of TCP/IP), DTN has found applications far beyond deep space: in remote sensor networks, disaster communication, wildlife tracking, rural connectivity in developing countries, and anywhere that connectivity is intermittent, disrupted, or delayed.
The core of DTN is the Bundle Protocol, defined in RFC 9171. Instead of establishing end-to-end connections (like TCP) or sending unreliable datagrams (like UDP), the Bundle Protocol operates on a store-and-forward principle at the application layer. Data is packaged into bundles — self-contained messages that include the destination address, quality-of-service flags, and the payload. Each node in the network stores the bundle until it can forward it to the next node closer to the destination.
This is conceptually similar to the postal system: you hand a letter to your local post office, which stores it until a mail truck arrives, which carries it to a regional sorting facility, which stores it until a truck heading to the right city departs, and so on until the letter reaches its destination. At no point does the entire path from sender to recipient need to be simultaneously available. Each hop is independent.
For alternative networks, DTN is relevant in several scenarios:
Satellite store-and-forward. A LEO satellite in polar orbit passes over a remote village for 10 minutes every 90 minutes. During each pass, the village’s ground station uploads outbound bundles and downloads inbound bundles. Between passes, the satellite carries the data to the next ground station in its orbit. No continuous connectivity is required — the satellite acts as a data mule in space.
Vehicular data mules. In areas with no connectivity between villages, a bus or delivery vehicle can carry a DTN node. As the vehicle passes through each village, it automatically exchanges bundles with the village’s DTN node via a short-range wireless link. This provides asynchronous connectivity — email, web page requests (which are fetched and returned on the next visit), and data transfer — at the cost of hours or days of latency.
Intermittent radio links. HF radio links that are usable only during certain propagation conditions, or microwave links that fail during heavy rain, can be modeled as DTN links. The Bundle Protocol handles the intermittency gracefully, queuing data when the link is down and transmitting when it becomes available.
# Simple store-and-forward bundle simulator
import time
from collections import deque
class DTNNode:
def __init__(self, name):
self.name = name
self.store = deque() # Stored bundles awaiting forwarding
self.delivered = []
def create_bundle(self, destination, payload):
bundle = {"src": self.name, "dst": destination,
"payload": payload, "created": time.time()}
self.store.append(bundle)
print(f"[{self.name}] Created bundle → {destination}: {payload}")
def transfer(self, other_node):
"""Contact event: transfer applicable bundles to neighbor."""
transferred = []
for bundle in list(self.store):
if bundle["dst"] == other_node.name:
other_node.delivered.append(bundle)
transferred.append(bundle)
else:
other_node.store.append(bundle)
transferred.append(bundle)
for b in transferred:
self.store.remove(b)
print(f"[{self.name}] → [{other_node.name}]: "
f"transferred {len(transferred)} bundles")
Several DTN implementations exist for practical use. ION (Interplanetary Overlay Network), developed by NASA’s Jet Propulsion Laboratory, is the reference implementation used for actual deep-space communication. IBR-DTN is a lightweight implementation designed for embedded systems and sensor networks. Serval Mesh implements DTN concepts for smartphone-based mesh networking. For alternative network builders, DTN is a valuable tool in the architecture when you need to bridge gaps in connectivity — whether those gaps are spatial (between locations with no direct link) or temporal (between periods when a link is available).
If you have been reading this chapter hoping for a clear answer — “use this technology for long-range links” — I am going to disappoint you. The reality is that every long-range technology has constraints that make it unsuitable for some scenario you will inevitably encounter. Satellite has latency and data caps. Point-to-point wireless requires line of sight. Microwave requires licenses. FSO fails in fog. HAPS is experimental and expensive. DTN sacrifices real-time communication.
The solution, as with most engineering problems, is to use multiple technologies together — each covering the weaknesses of the others. This is the hybrid architecture approach, and it is how most successful alternative networks actually work in practice.
The most common hybrid architecture for alternative networks combines satellite backhaul with local mesh distribution. A single satellite terminal (Starlink, VSAT, or similar) provides the connection to the global internet. This terminal feeds a local network — a mesh network, a community Wi-Fi system, or a WISP distribution layer — that distributes connectivity to individual users.
This architecture has several advantages. The satellite cost is shared among all users, making per-user costs reasonable. The local mesh provides low-latency, high-bandwidth connectivity between local users — traffic that stays local never touches the satellite link. And if the satellite link fails, local communication continues.
A typical deployment might look like this:
[Starlink Terminal]
|
[Gateway Router] — bandwidth management, NAT, firewall
|
[Core Switch / AP]
/ \
[PtP Link] [Mesh AP cluster]
| | \
[Remote AP] [User] [User]
|
[User]
The gateway router is critical in this architecture. It must manage bandwidth fairly among users (to prevent a single user from consuming the entire satellite link), provide caching for frequently accessed content, and potentially implement content filtering or traffic prioritization. MikroTik RouterOS and OpenWrt both support sophisticated bandwidth management using HTB (Hierarchical Token Bucket) queuing.
For alternative networks focused on sensor data and IoT rather than human internet access, the combination of satellite uplink with LoRa local collection is powerful. LoRa sensors deployed across a wide area — monitoring water levels, soil moisture, weather conditions, livestock tracking — transmit their data to a LoRa gateway. The gateway aggregates sensor data and periodically uploads it via satellite.
This is a natural fit for DTN principles: sensor data is inherently tolerant of delay (knowing the soil moisture 30 minutes ago is almost as useful as knowing it right now), and LoRa’s low bandwidth matches well with the satellite link’s data caps. A LoRa gateway collecting data from 100 sensors, each reporting once per hour, generates perhaps 50 KB per hour — trivially small even for a heavily data-capped satellite connection.
More sophisticated alternative networks use multiple backhaul technologies simultaneously, with automatic failover:
Primary: Point-to-point wireless link to a fiber POP (fastest, cheapest per bit, but dependent on equipment and path conditions).
Secondary: Starlink terminal (fast, moderate cost, independent of local infrastructure).
Tertiary: GEO VSAT (slower, more expensive, but extremely reliable and available virtually everywhere).
Emergency: HF radio with Winlink for email (very low bandwidth, but works when everything else fails).
With appropriate routing configuration — using tools like OSPF or BGP for dynamic route selection — the network automatically shifts traffic to the best available path. If the primary wireless link fails (equipment failure, severe weather), traffic flows through Starlink. If Starlink is also down (perhaps the terminal is damaged), the VSAT takes over. And if all else fails, essential email communication continues over HF radio.
This is not theoretical architecture — it is how organizations like Telecoms Sans Frontières and the Internet Society deploy connectivity in crisis zones and remote communities. Resilience comes from diversity.
Before you spend money on equipment, climb towers, or drill mounting holes, you need to know whether your planned link is physically feasible. The link budget is a systematic accounting of every gain and loss in a radio communication path, from the transmitter’s output to the receiver’s input. If the math says your received signal will be stronger than the receiver’s sensitivity (with adequate margin), the link should work. If the math says otherwise, no amount of careful installation will save you.
A link budget in decibels is straightforward:
\[P_{rx} = P_{tx} + G_{tx} - L_{cable,tx} - FSPL - L_{misc} + G_{rx} - L_{cable,rx}\]where:
The link margin is the difference between received power and receiver sensitivity:
\[M = P_{rx} - S_{rx}\]A margin of 10–20 dB is typical for reliable links. Less than 10 dB, and the link will be marginal — working in clear weather but failing in rain or when equipment ages. More than 20 dB is comfortable. Less than 0 dB means the link is infeasible.
import math
def link_budget(distance_km, freq_ghz, tx_power_dbm, tx_gain_dbi,
rx_gain_dbi, rx_sensitivity_dbm, cable_loss_db=1.0,
misc_loss_db=2.0, rain_margin_db=5.0):
"""Calculate a complete radio link budget."""
# Free-space path loss
fspl = (20 * math.log10(distance_km * 1000)
+ 20 * math.log10(freq_ghz * 1e9)
+ 20 * math.log10(4 * math.pi / 3e8))
# Total received power
rx_power = (tx_power_dbm + tx_gain_dbi + rx_gain_dbi
- fspl - 2 * cable_loss_db - misc_loss_db
- rain_margin_db)
margin = rx_power - rx_sensitivity_dbm
print(f"Distance: {distance_km} km")
print(f"Frequency: {freq_ghz} GHz")
print(f"FSPL: {fspl:.1f} dB")
print(f"Tx Power: {tx_power_dbm} dBm + {tx_gain_dbi} dBi gain")
print(f"Rx Gain: {rx_gain_dbi} dBi")
print(f"Losses: cable={2*cable_loss_db}dB, "
f"misc={misc_loss_db}dB, rain={rain_margin_db}dB")
print(f"Rx Power: {rx_power:.1f} dBm")
print(f"Rx Sensitivity:{rx_sensitivity_dbm} dBm")
print(f"Link Margin: {margin:.1f} dB — "
f"{'FEASIBLE ✓' if margin > 0 else 'NOT FEASIBLE ✗'}")
return margin
# Example: 30 km link with Ubiquiti PowerBeam 5AC Gen2
print("=== Ubiquiti PowerBeam 5AC Gen2 — 30 km link ===")
link_budget(distance_km=30, freq_ghz=5.5, tx_power_dbm=25,
tx_gain_dbi=25, rx_gain_dbi=25, rx_sensitivity_dbm=-72)
Link budgets are necessary but not sufficient. A link budget tells you whether the signal strength will be adequate — it does not account for:
A good practice is to calculate the link budget, then add 10 dB of margin on top of whatever you think you need. If the numbers still work with that extra margin, the link is a good bet. If you are relying on every last decibel, you are designing a link that will fail on its worst day.
Let us tie everything together with a practical project: planning and deploying a point-to-point wireless link connecting two sites 25 kilometers apart — perhaps a hilltop community center with fiber internet and a rural school in a valley. This is one of the most common and impactful alternative network deployments, and the process illustrates every concept in this chapter.
Before anything else, you need to verify line of sight. Start with a desktop survey using topographic data:
If the desktop survey shows a clear path, verify with a physical site survey. Visit both locations. Verify that the proposed antenna mounting points exist and are structurally sound. Check for obstacles not visible on topographic maps — trees grow, buildings get built, and satellite terrain data has limited resolution. Bring binoculars and try to spot the other site from each end.
# Quick site survey calculator: given coordinates, compute
# distance, bearing, and required tower heights
import math
def haversine_km(lat1, lon1, lat2, lon2):
"""Great-circle distance between two points."""
R = 6371
dlat = math.radians(lat2 - lat1)
dlon = math.radians(lon2 - lon1)
a = (math.sin(dlat/2)**2 +
math.cos(math.radians(lat1)) *
math.cos(math.radians(lat2)) * math.sin(dlon/2)**2)
return R * 2 * math.asin(math.sqrt(a))
def bearing_deg(lat1, lon1, lat2, lon2):
"""Initial bearing from point 1 to point 2."""
dlon = math.radians(lon2 - lon1)
lat1, lat2 = math.radians(lat1), math.radians(lat2)
x = math.sin(dlon) * math.cos(lat2)
y = (math.cos(lat1) * math.sin(lat2) -
math.sin(lat1) * math.cos(lat2) * math.cos(dlon))
return (math.degrees(math.atan2(x, y)) + 360) % 360
# Example: Community Center to Rural School
site_a = (45.234, 5.876) # lat, lon
site_b = (45.012, 6.134) # lat, lon
dist = haversine_km(*site_a, *site_b)
brg = bearing_deg(*site_a, *site_b)
print(f"Distance: {dist:.2f} km | Bearing: {brg:.1f}°")
For a 25 km link in the 5 GHz band, you need equipment with high antenna gain and good receiver sensitivity. Running the link budget:
Ubiquiti PowerBeam 5AC Gen2: 25 dBi gain, 25 dBm transmit power, -72 dBm sensitivity at MCS0. At 25 km and 5.5 GHz, FSPL is approximately 140.6 dB. With 2 dB cable loss per end, 2 dB miscellaneous loss, and 5 dB rain margin, received power is approximately -71.6 dBm — essentially at the sensitivity limit. The margin is 0.4 dB, which is dangerously thin.
Ubiquiti airFiber 5XHD: 23 dBi integrated gain (with an external dish, up to 34 dBi), higher transmit power, better sensitivity. With a 34 dBi external dish, the same link has a margin of approximately 18 dB — comfortable.
MikroTik SXT SA5 ac with an external 30 dBi dish: another viable option, with the added flexibility of RouterOS for traffic management.
For this project, we will choose the Ubiquiti airFiber 5XHD with external 34 dBi dishes — a proven combination for links in this distance range.
Physical installation is where many long-range link deployments fail — not because the radio equipment is inadequate, but because the mechanical installation is poor.
Mounting. The antenna must be rigidly mounted to a structure that does not sway in wind. A guyed tower or a heavy wall mount is essential. A mast that moves even 0.5 degrees in wind can cause signal fluctuations of 10+ dB on a link with a 3-degree beamwidth antenna.
Alignment. Coarse alignment is done with a compass and inclinometer, pointing the antenna at the calculated bearing and elevation angle. Fine alignment is done using the radio’s built-in signal strength meter — one person watches the signal reading while another makes tiny adjustments to azimuth and elevation, searching for the signal peak.
Grounding and lightning protection. Any outdoor antenna installation must be properly grounded, with a lightning arrestor on the cable between the antenna and the indoor equipment. A direct lightning strike will destroy any radio, but proper grounding prevents the far more common induced surges from nearby strikes.
Once the link is aligned and passing traffic, test it systematically:
Throughput test. Use iperf3 to measure actual throughput in both directions. Compare with the equipment’s rated throughput at the signal level you are achieving.
Latency test. Ping the remote end. Over a single wireless hop, latency should be 1–5 milliseconds. If it is significantly higher, you may have retransmission issues caused by interference or poor signal quality.
Signal quality monitoring. Record signal strength (RSSI), signal-to-noise ratio (SNR), and error rates over 24–48 hours. Look for patterns — signal degradation at certain times of day may indicate thermal ducting (atmospheric effects) or interference from other equipment that is only active at certain times.
Rain test. Wait for the first heavy rain and monitor the link. If you sized your rain margin correctly, the link should stay up, albeit at a lower modulation rate and reduced throughput.
A long-range link is infrastructure. Like all infrastructure, it needs ongoing monitoring to detect problems before they become outages. The standard approach is SNMP monitoring using tools like LibreNMS, Zabbix, or Prometheus with SNMP exporters. Configure alerts for:
For alternative networks, monitoring is particularly important because the equipment is often in remote locations where a site visit takes hours or days. You want to know about a developing problem while it is still manageable — before the link goes down entirely and users start calling.
# Simple link monitor: ping remote end, log signal stats
# (conceptual — actual implementation depends on equipment API)
import subprocess
import datetime
def check_link(remote_ip, expected_rtt_ms=5.0, rtt_threshold_ms=20.0):
"""Ping remote end and assess link health."""
result = subprocess.run(
["ping", "-c", "5", "-W", "2", remote_ip],
capture_output=True, text=True
)
timestamp = datetime.datetime.now().isoformat()
if result.returncode != 0:
return {"time": timestamp, "status": "DOWN",
"detail": "Ping failed — link is unreachable"}
# Parse average RTT from ping output
for line in result.stdout.splitlines():
if "avg" in line:
avg_rtt = float(line.split("/")[4])
status = "OK" if avg_rtt < rtt_threshold_ms else "DEGRADED"
return {"time": timestamp, "status": status,
"avg_rtt_ms": avg_rtt}
return {"time": timestamp, "status": "UNKNOWN"}
After covering this much ground — from geostationary orbits to laser beams to stratospheric balloons — it helps to have a practical framework for choosing the right technology for your situation.
| Scenario | Recommended Technology | Rationale |
|---|---|---|
| Remote community, no line of sight to anything, needs internet | Starlink / LEO satellite | Only option; good performance |
| Two sites 5–30 km apart with line of sight | Ubiquiti/MikroTik PtP bridge | Low cost, high bandwidth, proven |
| Two sites 30–80 km apart with mountaintop relay possible | Multi-hop PtP wireless | Cost-effective if terrain cooperates |
| Critical backbone link needing 99.99% uptime | Licensed microwave | Interference-free, reliable |
| Ultra-high bandwidth short link (< 2 km) | 60 GHz unlicensed or FSO | Multi-gigabit, no licensing |
| Sensor data from remote area with no connectivity | LoRa + satellite backhaul | Minimal bandwidth needed, tolerant of delay |
| Disaster response, temporary connectivity | Starlink + portable mesh | Deployable in hours |
| Maritime or mobile platform | LEO satellite (Starlink Maritime) | Only viable option for moving platforms |
| Intermittent connectivity acceptable | DTN over satellite or data mules | Works with what is available |
The key insight is that these technologies are not competitors — they are layers in a resilient architecture. The best alternative networks use multiple technologies, each chosen for the specific link it serves, combined into a system that is more resilient and capable than any single technology could provide.
Cost is often the deciding factor for alternative networks operating on community funding. Here is a rough guide to deployment costs (per link, both ends, 2025 prices):
| Technology | Equipment Cost | Monthly/Recurring | Data Limits |
|---|---|---|---|
| Ubiquiti PtP 5 GHz | $200–$500 | None (you own it) | Unlimited |
| MikroTik PtP 5 GHz | $150–$400 | None | Unlimited |
| Ubiquiti airFiber 60 GHz | $400–$1,000 | None | Unlimited |
| Starlink Standard | $499 | $120/month | Soft cap (1 TB) |
| Starlink Business | $2,500 | $250–$500/month | Priority data |
| GEO VSAT (Ku-band) | $1,500–$5,000 | $100–$300/month | 10–100 GB |
| Licensed microwave | $5,000–$30,000 | License fees | Unlimited |
| E-band (70/80 GHz) | $3,000–$8,000 | License fees (minimal) | Unlimited |
| FSO (commercial) | $5,000–$20,000 | None | Unlimited |
| SatNOGS ground station | $300–$800 (DIY) | None | N/A (receive only) |
The point-to-point wireless bridge is almost always the lowest-cost option when line of sight exists. When it does not, Starlink has dramatically reduced the cost of satellite connectivity. And combining a single Starlink terminal with a local distribution network sharing the cost among 20–50 users brings the per-user monthly cost to $2–$6 — within reach of communities in even the poorest regions.
Long-range connectivity is the hardest problem in alternative networking, but it is no longer unsolved. The combination of LEO satellite constellations (bringing affordable, low-latency connectivity to any point on Earth), mature point-to-point wireless bridge technology (providing high-bandwidth terrestrial links at low cost), and creative hybrid architectures means that no community is truly beyond reach.
The key takeaways from this chapter:
The next chapter turns to a critical concern for any network: keeping it secure. When you build your own infrastructure, you are also responsible for your own security — and the threats facing alternative networks are different from those facing centralized services.
| ← Previous: Packet Radio and Ham Networks | Table of Contents | Next: Security and Privacy → |