RADAR over wifi: Not always a pretty picture

OpenCPN plugins support overlay of imaging from some Garmin and Navico RADAR units.  Unfortunately some users attempting to use these plugins over wireless networks on their boats have encountered issues. Not only does it not work very well, it can make the whole wireless network unusable.  Moreover where people bridge a wireless segment to their wired network (e.g. with a simple domestic access point/switch/router) the wireless network can become unusable when the radar is switched on even if nothing on the wireless side is using it.  What's going on and what can be done to resolve it?

Why RADAR imaging might not mix well with wireless

The problem is with the way images are transmitted by the types of RADAR which OpenCPN plugins support (and probably others).  These RADAR images are not transmitted using standard NMEA protocols: The data rate is too high even for NMEA 2000. Instead manufacturers transmit RADAR images using proprietary methods over Internet Protocol running on 100Mb/s copper ethernet. Crucially manufacturers tend to use UDP multicast, sending data to multiple receivers at once (as opposed to "unicast", or sending to a single receiver).  In a previous post I extolled the virtues of multicast for transmission of boat data.  It allows all computers who have subscribed to a given multicast group to see the same data without them being replicated to each client.  Sending RADAR data over multicast on an ethernet network as the manufacturer intends works well.  Sending it over wifi is another matter.

The issue is not simply that the data rates are too high to be handled by wireless networks.  Navico state that their RADAR transmits at "up to 8 Megabits per second" which seems to concur with what users have observed.  Surely this is within the capabilities of most modern wireless networks?

Unfortunately a wireless access point has a number of "known unknowns" to deal with when transmitting to associated stations on a wireless network including the distance of the station from the transmitter, objects in between and interference in the environment which makes the task more complex than it is with copper wires.  The IEEE 802.11 standards on which common wireless networks are based each define a number of data rates.  Transmissions at lower data rates tends to be more robust than those at higher rates. Typically an access point will dynamically adjust the rate at which it sends data to each associated station based on packet loss (where transmitted frames are unacknowledged by the receiver at the link layer).  The connection between a "150 Mb/s" access point and a "150 Mb/s" laptop may be considerably lower than 150 Mb/s if the laptop is far away from the access point with intervening obstacles and/or there is interference from other devices in the environment.

Multicast (and broadcast) data must be sent at a rate which all listeners can be assumed to reliably receive.  Standards dictate that multicast should generally be sent using a rate in the "basic rate set" (the set of rates which all clients are assumed to support). Although not universally the case,  many retail access points will use the lowest of these rates, often 1Mb/s.  This of course is the physical data rate.  Various overheads mean that the rate of transmission of useful information will be be even less than that.

On top of this, multicast over wireless is more prone to packet loss than unicast.  Unlike ethernet, unicast 802.11 frames are normally acknowledged by receivers allowing them to be re-sent if they are lost in what is an inherently less reliable medium than copper wires.  Multicast frames are not usually acknowledged so aren't retransmitted if a receiver loses them.  Another potential source of packet loss  with high data rate multicast is the buffering that occurs on an access point when some stations on the network are in power saving mode, although without information on the sizes of buffers involved in a given access point it is difficult to assess the likely impact of this.

Note that these issues don't mean that multicast is a bad choice for "normal" NMEA-0183-style data. In those cases data rates are far lower, should not significantly impact the wireless network, and by the repeated nature of transducer data, occasional dropped packets are not necessarily a problem.  Remember also that broadcast data suffers from the same problems on wireless as multicast.

Why does RADAR stuff up all your other wireless data too?

If it's only the multicast which is constrained to be transmitted at 1Mb/s, why is your other wireless traffic badly impacted?

When transmitting multicast data the access point is operating at the multicast rate (e.g. 1Mb/s). Not only is there likely much more RADAR data than is involved in the average browsing session, the rules of contention for the radio give the multicast data an unfair advantage.  The radio in the access point is likely spending most of its time at the lower data rate.

Why does wired RADAR stuff up your wireless data when only wired devices are listening to it?

Your boat network may use an access point with an integrated switch for wired devices or you may have a wireless access point connected to switch to which your wired devices are also connected.

A simple switch has no knowledge of what devices on the network need to receive multicast data, so it will send multicast (and broadcast) data out of all ports.  This will include an attached wireless network, even if there are no wireless devices interested in receiving the multicast data.

Preventing multicast getting onto your wireless segment

Some switches do offer a method of ensuring that they only send multicast data out of ports to which a device which wants to receive it is attached: "IGMP snooping".  Whenever a program tells a computer that it wants to receive a particular group of multicast data, the computer will send an Internet Group Management Protocol (IGMP) "report" message on the local network.  Such messages are intended for routers which forward Internet Protocol (IP) packets between networks (e.g. your local network and your Internet connection) but some switches (which are generally link layer devices so know little of the higher level protocols carried in their data link frames) can listen for these reports and use the information to decide which switch ports to send multicast data out of.

Many high-end switches will have this functionality. Many low-end devices won't.

Making RADAR work over wireless

Wireless networks are also a problem for those wanting to deliver IPTV (Television over Internet Protocol)  using multicast so the problem has received extensive attention.  A number of solutions have been proposed and implemented in various pieces of hardware.  Retail access points are less likely to offer a solution than "Enterprise Class" (i.e. unaffordable) devices.  Two relevant solutions which require only support from the access point are:

• Multicast-to-unicast translation.  Access points send multicast packets to clients requesting them via link layer unicast.  In other words, IP packets to multicast groups are delivered in unicast 802.11 frames to the stations interested in receiving them and as such these frames are delivered reliably and at maximum reliable speed.  This technique is variously implemented in some enterprise class access points using various methods.  It is one of the subjects in the (currently not commonly implemented) IEEE 802.11aa and related 802.11v standards where it is referred to as "Directed Multicast Service" (DMS).  Some implementations use IGMP snooping to determine which clients are interested in which multicast data.  With 802.11v the client can request multicast to be delivered over unicast with DMS: a cleaner solution as the OSI layers aren't so mixed up but I haven't been able to find any hint of an API for this.  DMS does not scale well which can be an issue for IPTV delivery, but on board where no more than two clients are likely to require RADAR data it is ideal.
• Setting the multicast rate. Some devices will allow you to explicitly set the "multicast rate".  Setting this to a high value might make using RADAR over wifi viable.  The downside is that as this is the minimum rate at which clients will be allowed to connect to the access point, the range at which the access point is usable will be reduced.  In the average GRP yacht this will be a non-issue. Once again, this is more likely to be a feature on higher end equipment but is more likely to feature in consumer units than multicast-to-unicast translation.  It may also be possible to implicitly alter the multicast rate by disabling certain modulation types.

Which access points will work?

Without a RADAR unit to test or a multiplicity of access points to test I can only report what might work based on Internet research and reader feedback.  Please do let me know if you have any relevant information.  This section will be updated as new information is received.

"Enterprise Class" products capable of multicast-to-unicast are not generally found on boats so high end devices from the likes of Ruckus and Cisco are not considered here.

OpenWRT

The popular open source alternative firmware for a number of routers implemented multicast-to-unicast in the recent "Barrier Breaker 14.07" release.

Apple Airport Extreme

This apparently allows the user to set the multicast rate.  I will endeavour to test the effectiveness of this using simulated data.

Navico wifi-1

The manual for Navico's wifi-1 module describes an option of interest:

Multicast-to-Unicast:
IGMP snooping. Convert Multicast data to Unicast one.The default setting is "Enable". 

I contacted Navico to clarify this.  It seems that the "Multicast to Unicast" statement is a mistake.  The wifi-1 does do IGMP snooping but only to keep unwanted multicast data off the wireless segment. According to Navico's product manager for the wifi-1 it does not do multicast to unicast translation at layer 2 and Navico do not support RADAR data over wireless.

The Curious World of Marine Data Networking

It's a rum do this marine networking business. For someone who has spent the past quarter century dealing with open Internet protocols the strangeness is not so much in the archaic technology of the standards themselves but the way in which they are defined and administered.  The IETF has a variety of funding sources but one of them isn't selling the standards which they define.   Their biggest potential cost, the time of those involved, is funded by the organisations which employ them.  Corporate altruism aside, it makes good business sense to fund a seat at the decision making table.

In the world of marine data networking, standards are controlled by the US-based National Marine Electronics Association (NMEA).  In data networking, these standards cover the entire stack in the OSI model, from physical to application layers.  The International Electrotechnical Commission (IEC) formalises standards for the transmission of marine data based on the NMEA protocols (IEC 61162).  These are aimed at commercial vessels legally bound to conform to IMO requirements.

Unlike Internet standards, marine networking standards are not publicly published.  Anyone wishing to understand or implement the protocols has to buy the standards documents.  Not only this but the NMEA keep strict control of their intellectual property.  The documents aren't redistributable in any form which reportedly includes software source code.  Consequently, NMEA protocols cannot in theory be implemented in open source software.

Open source evangelist Eric Raymond has frankly expressed his opinions about this method of standards control.  Not being familiar with US intellectual property laws and keen to not be blinkered by possible hyperbole from those with hard line views on software freedom, I emailed the NMEA in an attempt to clarify their position on the use of legitimately purchased copies of their standards in open source software.  I never received a reply.

The NMEA has other sources of revenue besides selling standards documents: membership fees, conferences, product certification, training etc.  Whether revenue from standards is a necessary cornerstone of their funding or whether standards remain closed because of entrenched and ideas about how the marine electronics industry does business is not something I wish to speculate on here.

State of the Ark

The NMEA's most up to date data communications protocol is NMEA 2000.  This is based on CAN bus, the vehicle networking protocol from the 1980s which has only recently started to gain widespread use in the leisure boating market.  Still to be found on most marine devices today is the ability to communicate via an older and more widely deployed protocol, NMEA-0183 (a version of which is formalised as IEC 61162-1).  NMEA-0183 encodes data from sensors at the application layer as lines of carriage-return-line-feed-terminated ascii characters and transports them over a serial line (EIA-422 in later standards).

Due to the need to support higher data rates for connections between devices such as radar, sonar, cameras and the multifunction displays they talk to, manufacturers have implemented proprietary protocols (not using NMEA standards) running over ethernet networks.

There also exists an IEC standard for the transport of IEC 61162-1 (NMEA-0183) data over IPv4 networks known as IEC 61162-450. However I have never seen an implementation of IEC 61162-450 in any software or device available in the marine leisure market.

The NMEA is currently working on a new standard for transport of marine data over IP-based ethernet networks.  "Onenet" is due for publication in late 2014.  At the 2013 Southampton boat show and again at the 2014 London boat show I asked on the stands of Raymarine, Garmin and (at Southampton) Navico (who own the B&G, Simrad and Lowrance brands) when we were likely to see OneNet enabled products.  Sadly none of the staff were even aware of OneNet, let alone possible products.

If you don't build it, they will come anyway

PC applications which take marine data from an Internet Protocol ("IP") network using proprietary protocols are not new: Raytech used data from Raymarine equipment and MaxSea could use Furuno data.  Some of the newer tablet and phone apps continue to use proprietary protocols:  The Navionics tablet app communicates with Raymarine plotters (or "Multifunction Displays" (MFDs) as they are increasingly being called) using an undisclosed method agreed between the two companies.  Most of the current crop of mobile and PC apps using marine data from a network are not tied to a particular manufacturer.  The most common method for the transport of marine data over IP (including wireless) networks surprisingly follows no defined standard. 

NMEA-0183 over IP: The Non-Standard

The majority of current apps sending or receiving data over IP do so using the application layer of NMEA-0183.  In other words, the data an application will send or receive will look like a string of ascii characters, starting with a "!" or "$" and ending with an ascii carriage return and line feed.  Very few implement the new features in NMEA-0183 version 4 (e.g. TAG blocks).

There is no standard transport layer but in practice the options are limited anyway.  Most software apps and hardware devices use either TCP, UDP or offer the user a choice of either.  There is no standardisation for maximum UDP datagram size or whether one or several sentences may be carried in a single datagram.  There is no common statement that Nagle algortihm should be disabled for tranmission of marine data over TCP.

There is no standardisation for data transfer at the network layer except a de facto standard that IPv4 is used.  My own multiplexer program kplex is the only marine data application I am aware of which supports data in NMEA-0183 format over IPv6.  TCP is inherently unicast.  UDP is most commonly used for broadcast.  Even there there is no standardisation: Some applications use the broadcast address of the zero network (255.255.255.255), others the network broadcast address.  Most applications don't care which broadcast or unicast address is used as they simply listen for any UDP packets the system receives (ie bind to INADDR_ANY).  Very few applications use UDP multicast.  The only ones I know of are the ones I have put the code in to support it myself: kplex and OpenCPN.

There is no common standard for device addressing and no standard for service discovery.  Navico have developed and released a service discovery protocol described in their "GoFree Tier 1" specification.  This is a combination of bonjour and service information announced using JSON strings send over UDP multicast.  Few of the major applications described as working with "GoFree" currently make use of the service announcements: instructions for iNavX and similar applications involve getting the (dynamic) IP address of the MFD via the MFD's menus then connecting the mobile device to that.  Service discovery in OneNet is rumoured to be similar to this.  Perhaps unsurprising given that Navico is one of the biggest players in the industry and none of their major competitors has proposed such a protocol.

So why use a 30 year old protocol instead of the "current" NMEA 2000 at the application layer?  I am open to suggestions but here is my speculation.

1. Prior to disassociating the application layer from the lower layers of the protocol stack, it was easier and cheaper to present NMEA-0183 to a PC over a serial port (or via a serial to USB converter) than it was to present NMEA-2000 (via hardware incorporating a CAN controller).  Many applications developed prior to the widespread use of IP networks on boats were written to take NMEA-0183 from a serial interface.  Simply using the application layer of the already-implemented data communications protocol involves the least implementation effort when network communication is added.
2. NMEA-0183 is the most common format for data generally available on a pleasure boat.  Although NMEA 2000 has become more common over the past 5 years the ubiquity of NMEA-0183 means that most MFDs will have an NMEA-0183 interface in addition to any NMEA 2000 interface.  Many boats have older equipment which don't support NMEA 2000.  NMEA 0183 interfaces are still more common on some types of new equipment (VHF radios, AIS receivers).
3. Many of the details of the application layer of NMEA 0183 are known.  The details of NMEA 2000 are considerably less widely known.

The latter point needs discussing further.

NMEA 0183: An Open and Shut case

As previously mentioned, the NMEA's protocols are "closed".  To legitimately use them they must be purchased and not re-distributed in any way, including by open sourcing code written to implement them.  However many of the details of NMEA-0183 up to and including version 3 have been widely publicised on the Internet.  The document I consulted in writing kplex and possibly the best known publicly available source of information on NMEA-0183 is the document assembled by Eric Raymond.  In this he states that none of the content was directly derived from NMEA standards but was taken from a variety of other publicly available sources.  It was written as part of the gpsd project, but also in part as a political protest against the NMEA's closed standards.

As a consequence of the details of NMEA-0183 being publicised it has been widely implemented in apps where the developers have not purchased or cannot use (because the application is open source) the official standard.  NMEA 2000 has not been publicly revealed in this way.  The features added to NMEA-0183 in version 4, although referred to in some publicly accessible presentations and errata are not publicly described in detail and remain largely unsupported by most apps using NMEA-0183 style data over a network.

Are we there yet?

So what are we left with? The leisure market at least has ignored IEC-61162-405.  Products implementing OneNet look to be 2 years away.  We are left with the application layer of an antiquated and arguably poorly defined protocol which is generally implemented based on non-primary unofficial sources transmitted over an unspecified transport layer in an IPv4 network with whatever method of addressing happens to exist.

The quite remarkable thing is that it mostly seems to work.