Streaming ACN over WiFi

First of all, what is Streaming ACN? Streaming ACN is also known as sACN or it's official protocol number e1.31. It is a standard protocol developed by ESTA/Plasa ESTA/Plasa is the trade association for entertainment technology professionals. They cover all things related to staging, lighting, rigging and things related to theatrical and touring productions. ESTA/Plasa is recognized by the American National Standards Institute (ANSI) as the standards body governing these topics. sACN is the protocol that standardizes the transmission of DMX type data over Ethernet networks.

Using Streaming ACN 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.

If you want to skip all of this background info and get straight to the rules, jump to the Best Practices section at the bottom of this page.

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.

Unicast / Multicast / Broadcast:

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

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 Unicast should never be used for sACN over WiFi. 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

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

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.

Some of the better APs will allow you to set a multicast data rate. This will be the minimum rate used even if one or more clients momentarily falls below that threshold. This can be very helpful to make sure that one receiver with poor reception doesn't slow down the transmission entire show. Especially when it can be a brief reception/interference issue.

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. It supports multicast well and allows for other advanced features to further tweak the performance.

sACN Sequence Errors

Each sACN packet is numbered with a sequence number. This is done so that the receiving devices can ensure that the packets are received in order, and to detect gaps between sequences. If you're using unicast over WiFi, you should rarely ever see a sequence error because the packets get retried until they're successful. If you're using multicast, it's not unusual to see sequence errors. WiFi will always see transient interference from time to time and some packets will get lost. But it's more important that the right packet is used at the right time so that the lights are doing the right thing when you want them to. Sequence errors can be used as a gauge of the general health of the network. But they're not necessarily problematic in themselves. Don't worry too much if your sequence errors are less than 5% of your total packets received.

Best Practices

• Use a good access point. After all the work and money you put into your show, don't skimp on the access point and network equipment. The Ubiquiti Nanostation Loco M2 (NSLM2) comes highly recommended and is only around $50.

In general, DDWRT based routers are not recommended. There are too many versions out there and they all have different bugs and problems, and most of them do not handle multicast well.

• Use only Multicast for sACN over wifi.
• Keep all non multicast devices off of the show access point. This includes cell phones, tablets and laptops. While you might connect one of these for testing and configuration, you should disjoin it from the network before show time.
• Only view the configuration web pages of your controllers when you're actually troubleshooting and configuring. Close those browser windows during the regular show time. The browser communication to those devices uses unicast and can introduce lag.
• Pack your universes. Try to use the smallest number of universes as possible to transmit all of the channel data. Even though it may look cleaner to have different receivers use different universes, that's a lot of precious airtime that's wasted in sending partially full universes.

Additional Advanced Optimizations (Nanostation Specific)

As mentioned earlier, multicast traffic will be sent out at the highest common data rate of all receivers. So if you're still experiencing lag, you will want to see what that rate is. On the Nanostation, log into the web interface and go to the Main tab. Then in the Monitor section at the bottom, click on the "Stations" section. This lists all of the connected WiFi clients.

First of all, scan this list and make sure you know all of the devices that are connected. You shouldn't have any unknown devices here, no laptops or mobile phones. These should all be ESP devices, or other dedicated sACN over Wifi devices.

Next, look at the Tx/Rx Mbps column. This shows the data rates that the client has negotiated with the AP. These will change periodically as the WiFi conditions change. But you can use this column as a general indicator of how well the clients are connected for the purpose of multicast data reception. The lowest number in that column will be the data rate the AP is using for all multicast traffic.

• If you have low numbers here across the board, that's an indication that you have poor signal quality or that your AP is placed in a suboptimal location. Before going further, work on repositioning the AP and/or the clients to improve reception.

• Briefly communicating with a client will cause it to update it's rates with the AP. You can click on the IP address in the rightmost column to open up the web interface for a particular client device. This forces a communication to the client. Close that window and go back to the nanostation's page and hit the refresh button. It should now show good recent numbers for that client.

Once you have the physical locations of the equipment optimized, you may find that you still need to increase the performance a bit.

You can manually adjust the multicast data rate of the nanostation by using a command at the command prompt. To do this, you will need to open an SSH session to the nanostation. This will require the use of a SSH client such as PuTTY. The shell login credentials for the nanostation are the same as the web interface. Once you're at the prompt, type the following command:

iwpriv ath0 get_mcast_rate

If you're having problems, this will likely return a very low number such as 1.

Try to increase the rate. To do this type:

iwpriv ath0 mcast_rate 24000

This will set it to 24mbps. Note that you can only use valid data rates here such as 6000, 12000, 24000, 36000, 48000, 56000.

This setting is a balancing game. Setting it too high will increase the likelihood of ESPs missing data. Too low, and the AP can't get all of the data out in the alloted time. 24000 has been reported to be a good value by several users.

This setting is non-persistant. That is, it will go back to default after a reboot. The nanostations are security hardened devices that resist changes to their operating system files. So to make this change permanent, you must take additional steps. First, you need to install a version of the firmware that allows for custom scripts to be created and run. Then you need to create a special shell script called rc.poststart. This script will be automatially run after bootup. Configure this script to run this iwpriv command above. You then need to save and commit the changes to the flash memory. More details on this last part of the process can be found by searching online.