Over the last decade, amateur radio has experienced a renewed interest in digital communication networks. After years when packet radio felt largely historical, we can see a wide spectrum of new and revived projects: high-speed microwave IP networks, modern packet radio implementations, LoRa-based meshes, and hybrid services combining radio with public Internet infrastructure.
We have more bandwidth, more nodes, and more experimentation. Yet behind this progress sits a question that nobody seems to ask:
Are we building amateur radio networks on assumptions that fit the amateur radio environment?
1. Introduction
Much of today’s networks are shaped by Internet thinking: continuous connectivity, reasonable latency, stable topologies, and end-to-end paths that exist „most of the time“. These assumptions are not wrong for the Internet, they are the reason why it works so well. The problem is that amateur radio networks are not „another Internet, but slower“ or „Internet, but worse„.
It is a different operating environment. Run by volunteers in their free time, heterogeneous environments, power-constrained devices, and limited by propagations and regulations.
This article does not advocate for replacing any project/network, nor suggest to create one universal network. It is simply a reflection on whether the Internet model is the best when designing resilient networks over (ham) radio.
A resilient network is one that continues to deliver useful information even when assumptions about time, connectivity, and topology are violated.
2. A Landscape of Coexisting Networks
Today’s amateur radio ecosystem contains multiple approaches to data/packet networking. Depending on region and local community, operators may encounter IP-based microwave links, classic HF/VHF/UHF packet radio, modern high-speed packet systems, LoRa-based meshes, and store-and-forward services that resemble email or messaging.
Each of these networks solves a specific problem well. Together, however, they rarely interconnect. Most operate as self-contained islands, with limited interoperability. Bridging these networks is possible, but often ad-hoc, fragile, or application-specific.
This fragmentation is not caused by hostility or exclusivity among HAMs, but it is a consequence of how networks are built. Some projects implement an entire stack from RF details up to user applications, because it is the fastest way to ship something that works end-to-end. Others reuse the Internet stack largely unchanged, because it is mature, well understood, and available. Both approaches are rational, they just lead to different kinds of lock-in.
Before exploring why this further, it helps to name the main technologies people usually have in mind.
3. Common Amateur Data Networks
| Technology | Typical Bands | Licensed | Stack / Model | Notes (EU-ish constraints, simplified) |
|---|---|---|---|---|
| Hamnet | 5 GHz, 10 GHz+ | HAM | TCP/IP (backbone) | High throughput regional backbones. No encryption on amateur bands. Policies vary by country. |
| AREDN | 2.4/5 GHz | HAM | TCP/IP (mesh) | Similar to Hamnet. Emergency-oriented deployments. Local/regional variation. |
| Packet Radio (AX.25) | HF/VHF/UHF | HAM | Packet / BBS | Low bandwidth, long history, often store-and-forward applications. |
| NPR (New Packet Radio) | VHF/UHF | HAM | TCP/IP | Higher speeds than classic packet. Still tends to assume stable paths between nodes. |
| Winlink | HF/VHF/UHF | HAM | store-and-forward (email/forms) | Effective for its purpose. Relies on infrastructure and gateways. Not a general networking model, but specific application. |
| M17 (data mode) | VHF/UHF | HAM | Framed digital | Primarily voice, but includes data capabilities and room for experiments. |
| HAM LoRa meshes (various) | 433 MHz | HAM | Custom mesh | Region-specific, not strongly standardized. Attractive for low power + long range. |
| Meshtastic / MeshCore | ISM 433/868 MHz | Unlicensed | Custom mesh apps | Encrypted by default. Duty-cycle and EIRP limits. Great for ISM use, but not directly compatible with amateur rules. |
This list is intentionally pragmatic rather than exhaustive. The key point is not the details, but to show the heterogenity of available solutions: different frequency bands, different constraints, different stacks, and different assumptions about what “networking” should look like.
4. Internet vs. Amateur Radio
The Internet model assumes that end-to-end paths typically exist, that routing converges, and that latency stays within a reasonable limits, where timeouts and retransmissions make sense. On wired and cellular infrastructure, these assumptions are reasonable.
In amateur radio, connectivity is often intermittent by nature, not by accident. Links may depend on propagation, weather, interference, energy availability, operator activity, or regulatory constraints. Nodes disappear because a battery is empty, because someone powers down a station, or because a temporary installation ends.
In other words: what Internet treats as a rare failure mode is, in amateur radio, a normal operating condition.
If we describe connectivity as a function of time rather than a static property of the network, the problem becomes clearer. For many endpoints in the Internet, the probability that a path exists at any time is close to one. In amateur radio, it is often much lower (≪1) and highly variable. If we design protocols that interpret absence as failure, we force the network to fight its standard behaviour.
5. Why is End-to-End Reliability Expensive
The following observations are not protocol critiques, but consequences of applying end-to-end reliability assumptions in environments with intermittent paths.
Many modern protocols were designed around end-to-end reliability with fast delivery. The typical example is TCP: packets are delivered reliably because the sender receives acknowledgments from the receiver, adjusts its sending rate, and retransmits when acknowledgments do not arrive in time.
This works quite well when:
- the destination is reachable most of the time,
- round-trip time (RTT) is reasonable,
- and the path does not disappear mid-session.
In intermittent networks, those assumptions are false. If the receiver is temporarily unreachable, or if a multi-hop path exists only occasionally the sender cannot tell whether a missing acknowledgment means packet lost or receiver is absent. Retransmission then becomes a problem, because it injects more traffic into a network that may not currently be capable of delivering it.
This is not just inefficient, but actively wastes shared resources like:
- limited bandwidth on slow links,
- energy on battery-powered nodes,
- airtime on duty-cycle constrained channels,
- and attention of the operators trying to debug random failures.
A related issue is how chatty modern protocols are. Even before real payload starts flowing, many systems require several round trips just to establish and maintain a session. MQTT is a good example. It is often associated with constrained environments, but the common deployment model relies on TCP. A client connects (SYN, SYN+ACK, ACK), performs a handshake (CONNECT / CONNACK), negotiates session state (SUBSCRIBE, SUBACK, …), and then maintains the connection with periodic keep-alives (PINGREQ / PINGRESP). If the connection drops, the whole process repeats.
None of this is inherently bad. The problem is that these patterns assume the network is stable enough that such chatter is acceptable overhead. On intermittent links, this overhead becomes the dominant traffic
It could be tempting to look at older systems for inspiration. Early Internet culture had many offline-friendly patterns: BBS networks, IRC servers, mailbox systems, store-and-forward messaging. These designs tolerated disconnected clients and asynchronous interaction. However, many of them still assumed that the infrastructure (routers, backbone links, servers) remained mostly stable. Amateur radio can be uncertain everywhere, including the infrastructure.
Once the uncertainty moves from the edge into the middle of the network, end-to-end confirmation and session-heavy designs become fragile and expensive.
6. Heterogeneous Links and the Bottlenecks
Even if end-to-end connectivity exists, amateur radio paths often contain severe asymmetries. A single route could traverse links with orders-of-magnitude differences in bandwidth and latency: a fast microwave backbone (HAMNET) feeding into UHF (New Packet Radio), then perhaps a slow HF hop, or an ultra-low-rate LoRa segment. Even within LoRa itself, different spreading factors or bandwidth settings can create quite big rate mismatches.
This creates a classic bottleneck problem. Fast segments can sink data faster than slow segments can drain it. Congestions build at the boundaries of networks with different technology, packets starts to drop and retransmissions increase. From the application’s perspective, the network looks unstable, even when each link is behaving exactly as designed.
On the Internet, decades of engineering (buffering, provisioning, congestion control, overcapacity in the core) hide much of this. In amateur radio, the mismatch is often fundamental and unavoidable. To make matter worse, the bandwidth is not just lower, it is inconsistent and sometimes ephemeral.
This is one reason why „just run the Internet stack over RF“ can be both good and problematic. It often works well in the good cases (stable links, predictable topology), but it can be problematic when the environment becomes heterogeneous or intermittent.
7. The Cost of Recreating the Wheel
Fragmentation has a practical cost. When every new network technology means building a full vertical stack, from routing to transport to applications, experimentation becomes expensive. Not only in money, but in time, tooling, and human effort.
We can see both extremes today:
- Some ecosystems reinvent the stack repeatedly (new routing, new transport, new app layer), because it’s the fastest path to a working environment.
- Others reuse Internet protocols mostly unchanged (BGP/OSPF, DNS, MQTT, SIP/VoIP, etc.), because tooling is mature and familiar.
Both approaches can be valid. But growing number of incompatible islands, each requiring its own clients, gateways, infrastructure, and community momentum, kills inovations and motivation to try new ideas. Users in one island may become hostile to users from the other islands. Questions like „do we really need another digital mode/protocol?“ starts to appear, etc.
This creates a chicken-and-egg problems. New ideas struggle to gain adoption because they require a full deployment before they become useful. Conversely, established stacks resist change because too much depends on them.
If we want amateur radio to remain an experimental playground and not just a collection of finished products, we should ask whether there is a better way to allow new technologies to plug into existing communication stacks without rebuilding everything from scratch.
8. A Necessary Disclaimer
At this point, I’d like to mention few things about the intent of this text. This article is not a proposal to merge licensed and unlicensed networks, bypass regulations, or create a single global heterogeneous network across incompatible rule sets. Encryption rules, spectrum allocations, and licensing boundaries matter, and they are not optional.
The goal is also not to criticize specific projects or communities. Meshtastic, MeshCore, Hamnet, AREDN, packet radio, NPR, or Winlink. Each exists for good reasons and often works remarkably well within its intended scope.
My intent is to ask whether the Internet mental model of continuous, real-time, end-to-end networking is always the right abstraction for amateur radio, especially when we care about resilience, intermittency, and rapid experimentation. This article deliberately avoids proposing architectures or protocols. Its goal is to clarify the problem we are facing and to open a discussion.
9. Reframing the Question
If amateur radio networks are inherently intermittent, asymmetric, and volunteer-operated, then perhaps the problem is not how to make them behave more like the Internet, but whether we should expect them to do so at all.
I have been thinking about this for a while, partly because I keep seeing the same pattern repeat. Communities compare stacks as if one must replace the other. Meshtastic versus MeshCore, modern meshes versus old packet, links running over the Internet versus real radio.
What if we treated intermittency as normal rather than an error? What if networks could appear and disappear depending on events (HAM contests, expeditions, emergencies, short term experiments) and still contribute meaningfully without demanding a permanent always-on infrastructure? What if a temporary ad-hoc infrastructure in an emergency situation could opportunistically move messages over whatever is available (HF, VHF, microwave, LoRa, or public Internet) without forcing every participant into the same stack?
None of this is a concrete proposal yet. It is a direction of thought. But hopefully it suggests that the next step is not choosing a winner among existing technologies. The next step is to examine networking abstractions that can tolerate delay, discontinuity, and heterogenity, while making it easier for new protocols, modulations, and experiments to connect to something useful without rebuilding the whole stack each time.
If that sounds like it could matter for resilience and emergency communication too, it is because it probably does. The open question is how and what tradeoffs we would accept in exchange.
10. Conclusion
In the next article, Delay-Tolerant Networking for Amateur Radio, I want to move from questions to concepts: what networking models exist for intermittent environments, what „delay-tolerant network“ means and what it could bring to HAMs, and which parts of it might translate into the amateur radio world.
Further Reading and Context
Many of the ideas and questions raised in this article are not new. They primarily come from research in Delay- and Disruption-Tolerant Networking (DTN). A particularly accessible introduction to this topic is the NASA DTN tutorial, which provides a practical overview of DTN concepts and their original motivation in space communications:
Another great source of information is Kevin Fall’s paper:
This text is also influenced by practical experience and ongoing discussions within the amateur radio community. In recent months and years, my perspective has been influenced by conversations with other radio amateurs, participation in projects such as M17 and LinHT, hands-on experimentation with NPR, everyday use of LoRa-based mesh systems such as Meshtastic and MeshCore, and my initial (and still limited) exposure to Hamnet.
Note on AI Assistance
The ideas, arguments, and technical points presented in this article are my own. No ideas, conclusions, or technical claims were generated by the AI. AI tool (specifically ChatGPT model 5.2) was used for grammar checking and stylistic refinement. This proved to be an extremely helpful tool for a non-native English speaker, particularly when working with longer technical text.