Streaming ACN over WiFi

Using Streaming ACN (sACN or e1.31) over WiFi networks offers enticing benefits, however it also give us several unique challenges. WiFi is a wireless networking standard that's designed to provide a reliable network transmission mechanism using a less than reliable transmission medium. Because of this, we need to employ special considerations to make Streaming ACN work successfully on WiFi.

In order to best understand, let's start with some detailed background information.

WiFi is ethernet networking technology that uses radio transmissions instead of a wire. Before considering how WiFi works, let's first think about how radio works. Without any coordination mechanism, any device can talk at any given time. It's much like a bunch of people in a room. Without some form of coordination, if multiple people are talking at once, it becomes impossible to hear any of the messages. To sort out this chaos, a mechanism can be put into place to maintain order and effective communication. Think of a chairman in a formal meeting. The chairman makes the decision on who speaks and when and for how long. He keeps track of who is in the room, acknowledges when people want to speak, and allocates them time, and tells them when to start and stop speaking. In a WiFi network, this job is done by the Access Point (AP). The AP keeps track of all devices on the network (clients) and controls who is talking and when.

Frame

A frame is a set of data that is transmitted at once.

Packet

A packet is a set of data that comprises one message. It may take more than one frame to transmit a packet. All sACN packets are designed to fit within one frame.

On a WiFi network, there are three types of frames. Management Frames, Control Frames, and Data Frames. Management frames contain data to manage the network. It handles tasks like associating clients, keeping time, and identifying the network. Control frames are small extra messages that control the progress of communication like Ready to Send, Clear to Send, Power Save and Acknowledgement. Data frames contain the actual data to be communicated.

Beacon:

A Beacon Frame is a management frame that serves two main purposes. 1) It announces the presence of the network and it's capabilities. And 2) it keeps time. A beacon frame will contain the SSID, available rates (speeds), authentication mechanisms, and a timestamp. Beacon frames are sent out by the AP at a regular interval called, you guessed it, the "Beacon Interval". On most APs, this is set by default to 100ms and should be left alone for sACN uses. On some networks, this is set to a higher number like 500, 1000, 1500ms to reduce overhead on the network at the expense of timekeeping and slower discovery. It should not be set higher than 100ms for sACN traffic. Furthermore, setting it lower than 100ms can also cause problems by overcongestion of beacon frames. We will further explore how beacon frames interact with traffic later in this article.

Data Rates:

A Data Rate is the speed at which the bits of data travel over the network. It's expressed in bits per second (not bytes). You may have heard mention of various WiFi speeds like 11Mbps, 54Mbps, 450Mbps, 1800Mbps, etc. When used in marketing literature, this generally refers to the maximum data rate of an AP or a given networking standard. For example "B" WiFi (802.11b) has a maximum data rate of 11Mbps, where "G" has a maximum data rate of 54Mbps. But within each standard, there are a number of other allowable rates. These are sometimes refered to by MCS index (Modulation Coding Scheme). In the real world, you're not likely to see your network get close to the maximum data rate it supports. When clients associate with a network, and periodically thereafter, each client and the access point will negotiate the fastest data rate that it thinks it can sustainably achieve. Things like signal strength and signal to noise ratio come into play when the rates are established. A good access point will show you a list of associated clients, and the MAC address and current data rates for each one.

Uni/Multi/Broad-casting:

There are three possible methods to send data on any given network. Unicast: one to one. One device sends data to one other devices. Multicast: one to many. One device sends data to many other devices simultaneously. Broadcast: one to all. One device sends data to all devices on the network simultaneously.

Before explaining the three of these in detail it's important to remember the earlier example with many people in a room trying to communicate. Assuming that the AP is doing it's job making sure that everyone waits their turn to talk, then every device can hear all messages if it wanted to. It's up to the firmware of the device (specifically the network stack) to make the decision whether each message should be used or discarded. Some devices, especially DIY types may not employ a network stack that is fully compliant with the protocol and may act on data not really intended for it. Conversely, it's sometimes useful to listen to all data on a network when doing troubleshooting and such as packet captures in promiscuous/monitor mode.

Unicast is the most common traffic for general purpose internet traffic. It's communication between one client device and a particular internet host (or any other single host, local or remote) Data transmitted via unicast is sent at the data rate negotiated between this particular client and the AP. Generally, of the 3 casting types, unicast uses the fastest speeds. However, here's where some of those assumptions mentioned earlier come into play. It's assumed that it's most important for the data to arrive accurately. And accuracy is given a higher priority than timliness. In order to guarantee successful delivery, after sending the data frame, the sending device will wait for an acknowledgement from the receiving device. This comes in the form of a control frame. If the sender doesn't get an ACK frame from the receiver, it will then retransmit and wait again. It'll try several times until it's either successful, or gives up from too many retries. Not only does this frame have to stop and retry, but everything else that's waiting to be sent is sitting there waiting until this process either succeeds or fails. This is what causes the surging lag that's often seen in unicast sACN applications. This is why [b]Unicast should never be used for sACN over WiFi.[/b] Not only should unicast not be used for sACN traffic, but it should also not be used for any other traffic on the same WiFi network where sACN is present. One common misconception is that since sACN is UDP, it does not use an ACK process. That's true at the TCP level, but not at the link layer level. The control frames of WiFi exist at a lower level in the OSI networking model and by design, are completely unaware of the higher level protocols. UDP packets will still go thru the ACK process on WiFi whenever they are transmitted as unicast.

Broadcast traffic is data that is sent out that's intended for all devices on the network. It's used in DHCP requests and a number of other network management tasks. It's also what's used by FPP MultiSync when the "all remotes" option is used. Broadcast traffic is always sent out at the lowest possible data rate of 1Mbps, and is only sent out immediately following the beacon frame.

Multicast traffic is sent from the AP to multiple clients at the same time. All clients that are interested in a given multicast stream will be able to use the data from it. Remember from earlier how each client can have a different negotiated data rate? Multicast data is sent out at the data rate that is the fastest rate that all interested receivers can handle. So if you have one client with 6Mbps, and three clients at 54Mbps, the multicast traffic will only be sent at 6Mbps. Another thing that comes into play with multicast is power save mode. Whenever any one device on the network (regardless if it's participating in multicast) goes into power save mode, all multicast traffic on the network is sent at the lowest possible data rate of 1Mbps and is only sent out right after the beacon. This means that not only do the packets take longer to send, but they are only sent every 100ms. If you have a sequence at a 50ms frame interval, that means two frames will be sent out in rapid succession every 100ms. Not a good thing for sACN show data. All devices that have a wifi power save mode should be forbidden from your show WiFi network during show times. This includes all cell phones, tablets, laptops, IoT devices and pretty much any battery powered WiFi device. Regardless if you have multiple clients receiving a given sACN universe or just one, it's always better to use multicast for sACN over WiFi simply because it bypasses the ACK process.

Note: Because multicast is far less common than the other two mechanisms you will often observe buggy or less than optimal performance on lower end WiFi equipment. This includes most home grade routers and APs.

One device that has been tested and comes highly recommended is the Ubiquiti Nanostation Loco M2. This is a very inexpensive professional grade access point that offers the features and reliability you need for a sACN light show. You can usually find them on Amazon for about $50, and it is a device designed for outdoor use right out of the box.