Marine Data Transports Re-visited

Last year I wrote a post in which I extolled the virtues of UDP multicast for transmission of sensor information within a boat network.  Whilst that conclusion still stands in theory, real world practice is somewhat different when it comes to 802.11 wireless networks.

In my post on transmission of RADAR data over wireless networks, I mentioned that at layer 2 (the "datalink layer" in the OSI network model) "wifi" multicast packets (of which broadcast are a special case) are not acknowledged by the receiving end whereas unicast packets (those explicitly sent to one receiving station) are, so the sending station knows when it must retransmit a dropped packet.  Some may say "but isn't UDP always unreliable and unacknowledged?".  At the transport layer yes but the 802.11 ("wifi") frames that these packets are transported in don't care about the transport layer.   "Wifi" is far more "lossy" than transmission over copper cable, so 802.11 addresses this where it can by acknowledgements and retransmissions.  This is not possible for multicast (/broadcast) packets, but is for unicast.

In using my homebrew Raspberry Pi 2-based access point/data server I was noticing the GPS fix regularly dropping out in OpenCPN and AIS targets taking a long time to appear.  Some testing showed appallingly bad reliability of transmission using UDP broadcast.

The test was simple.  A MacBook Pro (the receiving station) was a wireless client of the Pi access point and located 2 metres from it in the saloon of my GRP boat.  The Pi was running kplex and, at that point, transmitting only GPS information from a directly attached Adafruit Ultimate GPS at a rate of 6 sentences per second.  The access point was not connected to the Internet and thus other traffic was minimal.  There are few access points visible on the Mac, and only the Pi transmitting on its chosen channel.

tcpdump was run simultaneously on the Pi and the Mac to record the number of "NMEA-0183" packets transmitted and received respectively over UDP broadcast during a 10 minute period.  Packet loss was then calculated: 96%!

The test was then repeated but with kplex transmitting packets via UDP unicast.  This time packet loss was, as expected, 0%.

It should be remembered that this was a home-brew access point solution using a low cost USB dongle and I'd be interested to hear of other people's experiences with commercial access points, especially expensive "marine" units like Navico's Wifi-1.  I note that Brookhouse Online, manufacturers of the "iMux" commercial multiplexer, state that "UDP is unsuitable for transmission of navigation data" (although I'll argue that actually they mean "UDP broadcast over wifi").

Meantime though, 96% packet loss clearly makes broadcast/multicast over wifi non-viable.  The alternatives?

• Use TCP.  Easy. Well supported
• Use UDP unicast.  Client addresses must be known in advance or some (currently non-existent) subscribe/publish protocol needs to be developed for marine data
• Use an access point which implements UDP multicast over 802.11 unicast (as discussed in the RADAR post).  Support for this is rare, as is support for NMEA-0183 data over multicast.

For most people the solution for now would seem to be to use TCP for delivering marine data over wireless networks.