So, I’ll admit to looking at AX.25 with the typical modems available (the classical 1200-baud AFSK and the more modern G3RUH modem which runs at a blistering 9600 baud… look out 5G!) years ago and wondering “what’s the point”?
It was Brisbane Area WICEN’s involvement in the International Rally of Queensland that changed my view somewhat. This was an event that, until CAMS knocked it on the head, ran annually in the Imbil State Forest up in the Sunshine Coast hinterland.
There, WICEN used it for forwarding the scores of drivers as they passed through each stage of the rally. A checkpoint would be at the start and finish of each stage, and a packet network would be set up with digipeaters in strategic locations and a base station, often located at the Imbil school.
The organisers of IRoQ did experiment with other ways of getting scores through, including hiring bandwidth on satellites, flying planes around in circles over the area, and other shenanigans. Although these systems had faster throughput speeds, one thing they had which we did not have, was latency. The score would arrive back at base long before the car had left the check point.
This freed up the analogue FM network for reporting other more serious matters.
In addition to this kind of work, WICEN also help out with horse endurance rides. Traditionally we’ve just relied on good ol’e analogue FM radio, but in events such as the Tom Quilty, there has been a desire to use packet as a mechanism for reporting when horses arrive at given checkpoints and to perhaps enable autonomous stations that can detect horses via RFID and report those “back to base” to deter riders from cheating.
The challenge of AX.25 is two-fold:
- With the exception of Linux, no other OS has any kind of baked-in support for it, so writing applications that can interact with it means either implementing your own AX.25 stack or interfacing to some third-party stack such as BPQ.
- Due to the specialised stack, applications often have to run as privileged applications, can have problems with firewalling, etc.
The AX.25 protocol does do static routing. It offers connected-mode links (like TCP) and a connectionless-mode (like UDP), and there are at least two routing protocols I know of that allow for dynamic routing (ROSE, Net/ROM). There is a standard for doing IPv4 over AX.25, but you still need to manage the allocation of addresses and other details, it isn’t plug-and-play.
Net/ROM would make an ideal way to forward 6LoWPAN traffic, except it only does connected mode, and doing IP over a “TCP-like” link is really a bad idea. (Anything that does automatic repeat requests really messes with TCP/IP.)
I have no idea whether ROSE does the connectionless mode, but the idea of needing to come up with a 10-digit numeric “address” is a real turn-off.
If the address used can be derived off the call-sign of the operator, that makes life a lot easier.
The IPv6 address format has enough bits to do that. To me the most obvious way would be to derive a MAC address from a call-sign and an arbitrarily chosen digit (0-7). It would be reversible of course, and since the MAC address is used in SLAAC, you would see the station’s call-sign in the IPv6 address.
The thinking is that there’s a lot of problems that have been solved in 6LoWPAN. Discovery of services for example is handled using mechanisms like mDNS and CoRE RD. We don’t need to forward Internet traffic, although being able to pull up the Mt. Kanigan and Mt. Stapylton radars over such a network would be real handy at times (yes, I know it’ll be slow).
The OS will view the packet network like a VPN, and so writing applications that can talk over packet will be no different to writing any other kind of network software. Any consumer desktop OS written in the last 16 years has the necessary infrastructure to support it (even Windows 2000, there was a downloadable add-on for it).
Linking two separate “mesh” networks via point-to-point links is also trivial. Each mesh will of course see the other as “external” but participants on both can nonetheless communicate.
The guts of 6LoWPAN is in RFC-4944. This specifies details about how the IPv6 datagram is encoded as a IEEE 802.15.4 payload, and how the infrastructure within 802.15.4 is used to route IPv6. Gnarly details like how fragmentation of a 1280-byte IPv6 datagram into something that will fit the 128-byte maximum 802.15.4 frames is handled here. For what it’s worth, AX.25 allows 255 bytes (or was it 256?), so we’re ahead there.
Crucially, it is assumed that the 802.15.4 layer can figure out how to get from node A to node Z via B… C…, etc. 802.15.4 networks are managed by a PAN coordinator, which provides various services to the network.
AX.25 makes this “our problem”. Yes the sender of a frame can direct which digipeaters a frame should be passed to, but they have to figure that out. It’s like sending an email by UUCP, you need a map of the Internet to figure out what someone’s address is relative to your site.
Plain AX.25 digipeaters will of course be part of the mix, so having the ability for a node stuck on one side of such a digipeater would be worth having, but ultimately, the aim here will be to provide a route discovery mechanism in place that, knowing a few static digipeater routes, can figure out who is able to hear whom, and route traffic accordingly.
Recent Comments