Emergency Ham Netwok

A Starting Point for Discussion

What do I mean by a Digital Network?

I purposely wanted to avoid trying to design the system because this should be a collective task for a group of interested people each with their own skills and perspective. However, it seems that some form of design is needed to better communicate what this is all about. So, here goes:

Digital Communications NetworkFormally a Digital Network is defined as a network incorporating both digital switching and digital transmission. It is easy to get bogged down in the various definitions which change depending on the use case. In the more common seven-layer OSI model of computer networking, the network layer is layer 3. This network layer is responsible for packet forwarding including routing through intermediate routers.

In my case I use the term loosely to represent the transmission of data using digits across many different link layers in such a way multiple services can use it to communicate. ARDEN acts like a network layer with the capability to support IP, a protocol. Services like APRS use other protocols, I believe APRS uses x.25 which is perfectly capable of being transported over a digital network. Many of the HF systems use a modem to provide the network like communications, allowing the services like WinLink to communicate.

So, when I say a digital network across America operating 24/7 I am suggesting the interconnection of thousands of locations using a variety of links but with sufficient abstraction to allow routing to each location of a variety of services. In urban areas, like where I live, UHF links supporting IP would be fine, but in rural areas some form of HF link would be used and that may not support IP. Add to this mix, satellite links, LoRa spread spectrum and you begin to see that such a network rapidly becomes complicated so requires coordination and standards. I do not believe this is available today although I do believe there are some strong candidates that could be expanded. Most likely the network will have multiple parts connected together with gateways.  

My expectation is that such a network will allow many of the services we use today, I am slowly covering some of them in my blogs. Such a network could be used for sending data to places not currently well served and to be able to do this 24/7 without operator intervention.

If we get this right, we will specify various components that can be connected together to suit a specific location. These would, as seamlessly as practicable, expand and bridge the network for that location.

The specific hardware could be a small server running on a PI4, an antenna mounted UHF TX/RX on the roof, perhaps more than one TX/RX including a HF link. For those better located, a dedicated link to ARDEN. For those unable to do anything outside, perhaps a LoRa link.

Running 24/7 and presumably most having a MESH style of connectivity, these nodes would receive, store and forward packets. Although most of the packets might have no value to any given location, each location will play its part in providing the network. Collectively the network would be capable of sending and receiving messages to anywhere there was a active node. A given operator would have the satisfaction of knowing their node was part of a bigger picture, be able to see how it was performing and be able to connect to their server for any services they require.

Now, bandwidth is an issue. In my lifetime I do not think we will see speech being supported. I suspect we would be averaging Kb/s for most nodes. But this is enough since it operates 24/7.  

Sample Diagrams of EHN Nodes

Many people like to see a diagram. Since this project is at such an early stage, not even a proof of concept – more a cry for existence, there is no design to draw.  

But it is reasonable to expect some generic diagrams that help explain the functionality. Here I detail two components, a basic end node and a bridge node. These would likely be the most popular components and illustrate much of the basic operation. Unfortunately, the more complex and interesting components: the switching, location, registration and database design are not so easy to represent as generic diagrams, these will have to wait for hard requirements to be created first.

Basic End Node

The end node would only connect to the EHN, it would only connect to the network through one connection. The network would see this as a single address representing its location/owner. It would likely connect through a simplex radio link as a slave to a master station, most likely a time division multiplexed single frequency. A good example on UHF would be the NPR-H Packet Radio system. This allows a master to support several end points, deals with the timeslot management and allows new stations to join on the fly. Overall, a good fit for this application. 

basic end node

The Basic End Node could be a portable system, separate or in a car so that it could serve a remote area or special need. A scouting weekend or similar might be an appropriate use.

Data from the network would be passed to the server, most likely a Raspberry pi 4 or similar. This would allow interfaces to the required service applications. Perhaps supporting APRS, Winlink or DAPNET but also a general interface for the Internet of Things (IoT).  There may well be a low data rate EHN webserver providing registration and status support for the network, I believe passwords are not considered encryption so such an admin style would be practicable.

Optional, but shown on the diagram, is the firewalled link to items using Part 15 communications. WiFi and LoRa are the items illustrated, but other systems like GoTenna could also be supported. The firewall would be responsible for removing any encryption from messages into the EHN and adding it for use under Part 15. Such a system would allow messages to be sent over the EHN perhaps by using APRS, Winlink or DAPNET.  When used at the edge of National parks or wilderness areas, this link between Part 15 devices particularly MESH networks is attractive and offers real value. The Basic End Node could include a web server for the WiFi and this could relay messages and important information to the Part 15 users.

Basic Bridge Node

For locations capable of linking to a more capable node a bridge node is proposed. This has the added capability of lining to several end points and bridge their traffic into the EHN.

basic bridge node

The link to the EHN could be another UHF simplex link, useful when there is a need to link two small islands perhaps to get around terrain issues but will be more effective if a duplex higher data rate link can be used. Equally in rural areas with small populations the link could be a HF link.

There is more processing and admin associated with a bridge. Most likely a database will be needed to store logs and to register the end point users, how the registration and geographical switching will be achieved is still up for discussion, but a store for local users seems like a good bet and would be capable of routing at the local level.

After these two nodes it should be easier to imagine combinations and additional links to form bigger nodes. There should be the possibility of links into ARDEN and Satellite uplinks.