How to: Get the Most from 802.11 Multicasting
by Jim Geier

Back to Tutorials

Some wireless LAN applications may use multicast delivery of packets to and from wireless clients. For example, an application may stream (via multicasting) the same T.V. video signal over a wireless LAN to multiple wireless monitors (clients) located throughout an airport or hospital. With multicasting, each data packet is sent to a group of wireless clients simultaneously. This avoids the need to send each packet to every client one at a time as is the case with the more common unicast packet delivery. As a result, multicasting is a much faster delivery mechanism when sending the same information to multiple clients. 

Do you have multicast traffic?

As an end user of 802.11/Wi-Fi applications, you’ll likely have no choice over whether to use multicast or unicast packet delivery. Often this level of implementation is fixed by the company offering the products and applications that you’re using. The way you configure the wireless LAN, however, will significantly impact the operation of multicast applications. 

Before getting to far with optimizing the configuration of your wireless LAN for multicast traffic, first check to see if you’re even running any applications that make use of multicasting. Sometimes the user manual or product specifications may identify the use of multicasting. Or, you can record a wireless packet trace while the applications are running, and look for clues on whether any packets are being sent via multicasting. For instance, none of the 802.11 data frames corresponding with the multicast applications will have acknowledgements, which can be clearly seen by observing a few minutes of a packet trace. 

If any of your applications use multicasting, then take a closer look at the configuration of the access points to maximize performance and battery life. 

DTIM interval makes a difference

When any single wireless client associated with an access point has 802.11 power-save mode enabled, the access point buffers all multicast frames and sends them only after the next DTIM (Delivery Traffic Indication Message) beacon, which may be every one, two, or three beacons (referred to as the “DTIM interval”). The DTIM interval can be set in the access point configuration. 802.11 power-save mode is optionally set by the user on the wireless client device, generally via the radio’s wireless configuration utility. 

The use of DTIM intervals was put in the 802.11 standard to allow sleeping stations implementing the power-save function to know when to wake up and receive multicast traffic (i.e., after every DTIM beacon) and to allow flexible configuration of the network (i.e., DTIM interval) that offers a trade off between battery life and performance. If none of the 802.11 radios associated with the access point has power-save mode enabled, then the access point will send multicast traffic immediately and not wait until after the next DTIM beacon. 

If you haven’t considered multicasting in the past, then the DTIM interval on your access points is probably set to the default value, which is likely one, two, or three. If set to one, the access point will deliver multicast frames after every beacon. Don’t forget, the significance of the DTIM interval only applies if at least one wireless client associated with the access point has 802.11 power-save mode enabled. A DTIM interval of one, two or three is good for performance, but it will likely hurt battery life. 

I’ve found through testing that some wireless clients with power-save enabled will receive the last multicast frame sent by the access point and then continue staying awake until after the next beacon. In other words, the client radio stays awake for the entire beacon interval. If the beacon interval is set to 100 milliseconds (the common default value) and multicast traffic is occurring within each 100 millisecond interval (typical for many multicast applications), then the flow of multicast frames will probably cause the client radios to stay awake indefinitely. This draws battery power as if power-save mode was not enabled. Even with DTIM intervals of two or three, battery life may still suffer. With DTIMs occurring every other frame (DTIM interval = 2), for example, the radio may be awake fifty percent of the time. 

Now, you might have changed the DTIM interval in the past, but it may be too high. For instance, I’ve seen some DTIM intervals set to thirty, which means that wireless clients with power-save mode enabled will not receive multicast traffic until after thirty beacon intervals. This might be great for battery life, but it only allows the delivery of multicast traffic every three seconds (assuming the default 100 millisecond beacon interval). The impact of this is highly application-specific, though. For example, the transmission of voice would likely have long and annoying skips/quite intervals, but the delivery of text messages may not have any impairment noticeable to humans. 

What DTIM interval is best?

Unfortunately, there’s no straightforward answer to this. In order to optimize the DTIM interval, you should gain a good understanding of how your multicast applications work. You’ll probably not find this in user manuals, and even the vendor may not want to tell you much about it to avoid disclosing company secrets. In these cases, you might need to do some testing. 

Most likely the best DTIM setting will be the one that provides maximum battery life while allowing delivery of multicast often enough to provide good performance. To do this, you should determine the highest DTIM interval that can be set and still allow the multicast applications to work properly. First, try setting the DTIM interval to one, and then use the application while monitoring quality of the transmission (such as voice quality). In terms of DTIM settings, this should offer the best quality. You can use this as a baseline for comparison purposes when setting the DTIM interval to higher values. Now, try increasing the DTIM interval to higher values while monitoring transmission quality. Keep increasing the DTIM interval until the quality is just above the minimum tolerable level. At this point, you’ll have the highest DTIM interval that you can use to maintain required performance, which also offers the best power savings. 

Concluding thoughts

Keep in mind that DTIM settings will not affect any of the unicast traffic. It also won’t impact the multicast traffic if none of the wireless clients associated with the access point have 802.11 power-save mode enabled. 

Also, as with other wireless LAN configuration settings, such as fragmentation and RTS/CTS, the optimum DTIM interval is generally a trial and error process. You might need to tinker around a bit to find the best configuration for your applications!

Questions? <<Contact the Author>>

Back to Tutorials