John, KE4TZN, and I were discussing the idea of replicating the Coastal Linking System in DMR. The difference being that the existing network uses audio linking where DMR, and other digital modes, use an IP-based network for routing the links.
IP networks, not to be confused with Internet-connected networks, switch data between networks without degrading the quality of the data. Switching audio, however, results in degrading audio quality and, thus, cannot be repeated indefinitely.
The existing network
Generally speaking, the existing network uses a core analog voice repeater and other analog voice repeaters use a separate radio, a link radio, to route the repeater’s audio to that core repeater. This allows users of a repeater to send their audio across their local repeater, across the link radio, to the core repeater. The core repeater then repeats that audio to any other link radio that is listening which would then direct the audio to its repeater. This is a traditional star network. This type of network has several advantages and disadvantages, including a big disadvantage of the core repeater being a single point of failure.
One benefit of the existing links, that will become apparent shortly, is using a frequency of 440MHz and a bandwidth of 15kHz.
Replicating the network
The network has connections from Columbia to:
- Ahoskie
- Bath
- Buxton
- Elizabeth City
- Englehard
- Greenville
- Hertford
- Williamston
All sites could be connected to Columbia except Buxton and Greenville. Buxton, being a high priority when hurricanes threaten, absolutely needs a good connection back to the mainland. Greenville is also a target city as there are resources there that would be good to link to, including the regional trauma center.
Because we don’t have to worry about degrading our audio (it’s all data after all), we can daisy-chain links together to create paths to more distant locations. Buxton, not reachable directly from Columbia, becomes connected via the Englehard site. Greenville also joins the network but through Williamston.
A bonus to using a routed network is we’re no longer required to stick with that star configuration. You’ll notice a lot of links (lines) on the map that don’t connect back to the Columbia site. These links not only relieve the stress on the Columbia site handling all of the traffic on the network but also provides alternate routes for the traffic to flow. In an IP network, these links are constantly being weighed to determine the lowest cost path for moving data from one point to another. If data is moving between Buxton and Bodie Island, two hops, there is no reason to send it via Columbia (three hops). However, if one of the links between Buxton and Bodie Island is congested or has failed, the data can flow through Englehard and Columbia to route around the issue. These changes in routing happen automatically.
Headaches with the design
The difference between amateur radio, and basically any other radio service, is that amateur radio systems (and networks are no different) are generally built where it can be built where commercial and public safety systems are built to satisfy a specific need. If you were to overlay the North Carolina Highway Patrol’s microwave network on top of what I have laid out you would see that we aren’t using half the sites they use. You’ll also see that they use multiple altitudes and frequencies at each site to make sure their statewide network stays up and operational. They have a slightly larger budget that I (we) do.
Another issue is that all of these links are currently setup with 5GHz in mind. There are other bands available to amateur radio operators including a nice, quiet piece of spectrum in the 3GHz area that could be used. Using other bands might improve bandwidth and throughput.
The Greenville site being used in this model is actually the NC Highway Patrol tower that we currently don’t have permission to use. Of course we don’t have permission to hang any of this new gear on any tower so why not shoot for the Moon and ask for it all, right?
The frequencies we’re talking about using attenuate significantly in air. Add moisture and we’re talking about the possibility of a link dropping. Hopefully any link degradation would likely mean a reduction in available bandwidth and not a complete link failure.
The last issue I had was trying to remove the star configuration, and somewhat failed to do. I ended up with two segments of the network that still need the Columbia site to connect to each other. The two segments generally break down to the “Beach” sites (Bodie Island, Buxton, Chicamacomico, Englehard, and Ocracoke) and the mainland sites.
So I have a network, now what am I supposed to do with it?
Well, the original idea was to have an independent network that would replicate the Coastal Linking System but for DMR. We can easily connect our DMR repeaters to this network and use it for backhaul to connect them to a regional c-Bridge-like device that would provide the connectivity to all repeaters on the network and also route traffic off the network to other DMR networks (Brandmeister, DMRVA, etc) to get access to outside networks. The required bandwidth for DMR is miniscule compared to the bandwidth that will be available on the links.
It would also be possible for DMR users that have their own hotspot devices to connect them directly to the c-Bridge-like device over the IP network and get access to the repeaters in the region.
There are also ways to connect analog repeaters together using this isolated IP-network. AllStar is one system that allows you to create your own network with their software, thus linking analog repeaters across the IP network.
APRS can also be used over the IP network. If all the IGates in the region were connected with an APRS server that was on the network, any messages and position reports could be routed to all other users that were also connected to the network (either on the IP network or in the area of the IGate that was).
Servers supporting email, webpages, keyboard and video chat, and file exchanges can also be put on the network much like packet radio BBSs used to be setup. Heck, if you wanted to stand up BBSs for users to connect to using traditional packet radio, the BBSs could connect to each other over the IP network and send and receive messages and bulletins using telnet.
The idea is, it’s all just data. The network doesn’t really care what the data is, it just wants to know where it’s going.
How do users connect?
So far we’ve only been talking about building the wide area network (WAN) that connects towns and cities together. This is not the network that users, or even servers and devices, interface with.
To do that, we’ll need to build out a local area network (LAN) or, maybe even a metropolitan area network (MAN) that will handle data going between users and between users and local resources.
In the image we see the city of Greenville with a light blue sector shaded in representing a LAN. We also see some example links established within that sector representing the Brody School of Medicine building, Pitt Community College, and a ham radio operator’s home. The idea of the LAN is that anywhere in that blue area you should be able to connect to the local network and use it to connect to whatever resources you may need whether that be a web server, a file server, or a chat room. And that server may be located in a server room at Brody, in someone’s home that is on the LAN, or on a server in Buxton.
LAN bandwidth can be much greater, supporting many more users, than that of the WAN so it would be best to have certain resources replicated locally wherever many users will be accessing the information. The WAN can be used to synchronize data between servers where speed isn’t a factor leaving a faster experience for the user.
