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.

Cape Multicast: The Logical Route

UPDATE September 2015.  Practical layer 2 considerations have lead me to change my conclusion on the optimum practical data transmission method over wireless networks as described in this later post.

In my last post I touched on the lack of standardisation in the way NMEA-0183 data (strictly speaking, data in a format based on the application layer of NMEA-0183, but we'll use the shorter phrase for readability) is transported over IPv4 networks with current marine software and devices.

In this post I argue that the way in which most devices and software currently do this using TCP or broadcast UDP is not optimal, propose an alternative solution and discuss the viability of its implementation.

For the sake of this discussion, the network is assumed to be the de facto standard of IPv4.

For the sake of brevity I will assume some familiarity with TCP/IP and UDP/IP.  If anyone comments to request it I will elaborate on terms more extensively in a later post.

How things stand

Most devices and software which are designed to send or receive NMEA-0183 data over an IP network do so by one or both of unicast TCP or broadcast UDP.  Devices which are data sources on the network (e.g. NMEA-to-network converters) often implement a TCP server though in some cases programming is rudimentary and the server can only support a single client.  Data consumers (e.g. mobile apps) using TCP normally act as a client, initiating a connection to the server.  Consumers expecting UDP can normally receive unicast or broadcast data as programmers of these apps rarely bind sockets to a particular address.

Very few devices or programs explicitly designed to send or receive NMEA-0183 data do so using UDP multicast.  kplex will, and as of beta version 3.3.1303, so will OpenCPN.  Software and devices able to send to a configurable UDP address can normally send to a multicast address so long as the underlying network stack supports multicast, which it will in the case of a modern operating system (Linux/Windows/MacOS/*BSD).  Software and devices will not be able to receive NMEA-0183 over UDP multicast without explicit support in their code, although such support is normally trivial.

TCP

Why you want it

TCP has the following advantages in this application

• With no clients connected, a TCP server consumes no bandwidth.  If your server sends unsolicited UDP it neither knows nor cares if any clients are listening: it sends it anyway.  This increases power consumption on many types of network if no clients require this data.  If your network only intermittently has a client device wanting to receive NMEA-0183 data, TCP may be the most power-efficient solution.
• For Internet NMEA-0183 servers such as ones streaming AIS info for various ports, TCP is the most viable option.  Multicast over the Internet is rarely an option due to configuration required on intervening routers.  Broadcast or unicast UDP would require a separate protocol to request and terminate a datastream from the server and would generally encounter difficulties with firewalls.
• Reliably implemented in embedded stacks
• Currently supported by most applications

Why you don't

• That reliable delivery you thought was a good idea? In this application it probably isn't.  Reliable transmission is not a feature of native NMEA-0183 over serial lines or AIS over VHF and no application should break as a result of a lost sentence. A reliable transport mechanism is not required if reliability is provided by the application layer protocol.  In this case, transducers are constantly transmitting their status with the most recent data.  If a UDP packet is dropped the result is that an application will not be updated with the information it contained but will be updated with more recent information the next time that sentence is transmitted, possibly 1-5 seconds later.  If a TCP packet is dropped, no subsequent packets (sentences of any kind) will be delivered on that data stream to the application until the packet loss has been detected by TCP and the dropped packet has been successfully retransmitted. Instead, any data sent between the dropped packet and the retransmitted one will be queued on the receiver pending the ability to deliver data in the order it was sent: an unnecessary requirement here.  The duration of the delay will be influenced by many factors but if it exceeds the frequency of transmission of the data type in the lost packet, the result could be that a subsequent update is delayed waiting for TCP to retransmit the (now obsolete) dropped packet.  This will happen in the case where a network cable is disconnected for more than a second, interrupting the flow of data from a transducer outputting at 1Hz.  Another case where it should happen is if that 1Hz data is the only thing being sent over a data stream.  RFC 6298 gives a minimum retransmission timeout of 1s so in the absence of other packets being sent to trigger a fast retransmit, TCP will not time out waiting for the dropped packet to be ACKed until after the subsequent packet has been sent.  In practice, most OSes implement a lower minimum RTO and in any case, the average NMEA-0183 stream may carry more traffic, triggering fast retransmits.  It could be argued that in the case of AIS data where a dropped packet containing a report from a vessel may not be updated for minutes, TCP's retransmission may be a net benefit but in general, TCP's "reliability" is not beneficial in this application.  If a LAN is heavily congested for long periods, it is far better to randomly drop data leading to graceful degradation of performance of the end user application than to queue a backlog of stale data.
• Protocol overhead.  In addition to the actual NMEA data transmitted a TCP connection requires packet exchange in order to set up a connection, packet exchange to take it down and acknowledgements of data received to be sent. Loss of the latter may lead to unnecessary retransmission.  In practice protocol overhead is not excessive: data streams are long lived meaning that connection establishment and termination overhead are negligible and not every packet needs ack-ing.
• Data are prone to additional delays if programmers neglect to disable Nagle algorithm on sending sockets.  There is no need for this to be an issue, but marine electronics companies do not have a good track record of software excellence. UPDATE: In testing this with OpenCPN I realised that most modern operating systems seem to have delayed ACK timers of 200ms or less rather than the traditional 500ms, reducing any impact from this.
• Data replication.  Any unicast protocol (as TCP inherently is) requires each piece of data to be copied to each client.  Two clients necessitate double the data on the network as opposed to a single client. Three clients triple etc.  In practice the small number of network NMEA-0183 clients likely to be required on the average pleasure boat is unlikely to exceed the multiple by which network capacity exceeds the capacity of a 38.4k serial line, so whilst wasteful, should not present an obvious problem.
• If a server is ungracefully shut down (e.g. the power removed) and restarts, a receive-only TCP client may not realise for some time (or ever if keepalives are not enabled) and data will simply seem to stop, where a UDP-based solution would continue to function as soon as the server came back on line.
• Requires users to know the network address of a server in order to configure a client, which can be problematic on links with dynamically assigned addresses.  This might be overcome by use of a service discovery protocol (e.g. bonjour, ssdp or a custom protocol).

Broadcast UDP

Why you want it

• Doesn't suffer delays or protocol overheads associated with TCP
• No requirement to replicate data: Many clients read the same data packet
• Available on the types of network used in this application
• Reliably implemented in embedded stacks
• Currently supported by many applications

Why you don't

• Not a good solution when crossing network boundaries as will be dropped by routers unless they are configured to do otherwise. Not usually a problem since common applications use a single link.
• Inappropriate for Internet use
• Can be challenging to program correctly for bi-directional communication with standard APIs.  Applications need a method to avoid re-reading their own broadcasts and possibly creating broadcast storms. OpenCPN does this using interface priorities.
• Explanation of netmask/broadcast concept needed in documentation if UI  requires user to input destination address manually
• Requires some processing by all devices on a link regardless of whether any are interested in the data being sent.  This is the big problem with broadcast and why it is generally not considered a good solution in modern networking applications.

Unicast UDP

Why you want it

• For streaming data to a single, known, always-connected destination it is ideal.  None of the protocol overhead or timing issues of TCP yet easily traverses networks and is universally implemented in IP network stacks.  An example might be streaming data to Marine Traffic servers.

Why you don't

• Worst of all worlds in most other respects
• Data duplication required with multiple clients
• Server must know addresses of all clients
• Additional protocol required for clients to dynamically request a data stream
• Wasted traffic if server is pre-configured to stream data to fixed unicast addresses which may have no attached client

Multicast UDP

Why you want it

• Doesn’t suffer delays or  protocol overheads associated with TCP
• No requirement to replicate data: Many clients read the same data packet
• Available on the types of network used in this application
• Unlike broadcast, sending requires setting of no special flags (assuming a correctly functioning network stack)
• Easier to implement bi-directional many-to-many communication with standard networking APIs than with broadcast
• Can be efficiently routed across networks
• Unlike broadcast, doesn't (in theory) cause processing overhead on systems not interested in receiving those particular multicast data
• Reliably implemented in all modern operating systems (Linux/MacOS/Android/IoS/Windows)

Why you don't

• Not currently supported for receiving by many applications.  kplex and OpenCPN are two which do
• Multicast routing across networks requires support on routers which will likely be unavailable across the Internet or on a small home/boat network, limiting effectiveness to a single link (like broadcast) for many users.
• Not a required part of IPv4, although implemented for more than a decade in almost all operating systems
• May not be implemented in some basic embedded/microcontroller stacks

So what's the answer?

For the most part, TCP is the wrong protocol for delivery of NMEA-0183 data over a boat LAN.  The protocol's bandwidth throttling and reliability mechanisms are not required by the nature of the application level data and can have a negative impact on the timeliness of data delivery to client. The data required on the network is a linear function of the number of clients using those data as opposed to a fixed amount as with UDP broadcast and multicast.

TCP is undoubtedly the best choice for requesting data from a server on a remote network as UDP would require an additional protocol for initiation and termination requests.  Although the best choice for servers streaming port AIS information which in turn is often useful for debugging marine data applications without another source of live or simulated data, this facility should not normally be required for navigational purposes.

Unicast UDP only has utility when sending data to a known endpoint on a remote network.  For navigation data within a boat's network, it has little to recommend it over the alternatives.

Of the current widely implemented solutions, broadcast UDP is perhaps the most appropriate.  Clients don't need to know a source address (only a port) so it is useful where servers are dynamically configured. However, its only advantages over UDP multicast are:

• Current acceptance in the market
• Possible lack of multicast support in some embedded network stacks

Manufacturers will at some point need to address the latter point (if it even turns out to be a problem) with the 3rd party network stacks they currently use.  Service discovery protocols which are increasingly being used in marine applications (e.g. in GoFree, OneNet) require multicast to function correctly.  This leaves only the problem of acceptance in the market which will be addressed in a later section.

Multicast would be used for this application in any commercial computer networking solution and indeed is reportedly the choice for data delivery in formal marine data networking standards IEC-61162-450 and NMEA OneNet. It is possibly only unfamiliarity with IP networking concepts in the marine electronics world which has led to broadcast being adopted.  Multicast has the advantages of broadcast but without the unnecessary processing overhead imposed on devices attached to the network which are not interested in receiving data of this sort.  The receiving group is a simple address which the user does not need knowledge of netmasks to determine.  It could be argued that multicast does not always remove unnecessary processing overhead: The IP-multicast to ethernet-multicast address mappings are not one to one and coarseness of multicast filters on various network cards, particularly at the lower end, may lead to unnecessary CPU interrupts caused by irrelevant multicast traffic.  Processing load is, however, reduced by using multicast rather than broadcast.

Does any of this even matter?

Not much.  Boat networks are small with few attached devices, perhaps the majority of which will be interested in  NMEA-0183 data and the rest will be negligibly affected by using broadcast rather than multicast.  It is unlikely that users will notice a difference no matter which delivery method is used.  This doesn't mean that it's is a good reason to choose a theoretically inferior solution because in practice there is no observable difference.

Conclusion and Stratgey

Multicast UDP is the most technically correct of the transports considered here for NMEA-0183.  The main issue is acceptance in the market place.

From the  product development angle this is easily addressed for products currently supporting unicast or broadcast UDP: Supporting multicast, in addition to unicast and/or broadcast is simple. If the sending/receiving UDP address is not already configurable, the UI needs to be updated to make it so.  After this only trivial code changes are required if a user specified address is multicast: When the data connection is initialised if the user-supplied UDP address is a multicast address, the program simply doesn't set the broadcast option on the connection (SO_BROADCAST for the sockets API) if it needs to send data.  If it needs to receive data, it simply joins the relevant multicast group, a single function call in most APIs.

For multicast to be useful, all clients requiring NMEA-0183 data should support it.  There is no point in running multicast and broadcast together on the same network: this has no advantage over broadcast alone.

For new applications all it requires for developers to implement multicast as a transport is awareness as the additional development cost is negligible.  For modification of existing applications there is only justification if there is demand, and there will only be demand if other apps support it. We've started the ball rolling with openCPN, perhaps it's time to spread the word.

But obviously an open standard would be nice.