|
Multicast transmission of data may be right for your wireless LAN application. Learn the ins and outs of implementing multicast solutions in WLANs
Most wireless applications make use of unicast packets for transporting information directly from one point to another. For example, an interaction with the Internet makes use of unicast packets when you browse the Web or synchronize email.
Enter Multicasting
There are instances where the transmission of information using multicast packets, however, makes more sense. A multicast packet includes a group address that delivers the same packet to more than one destination. If the destination address refers to all nodes on the network, then the packet is a broadcast packet, which includes all ones as the address.
The use of multicasting, meaning delivery of information using multicast packets, conserves the bandwidth of a network because only the transmission of a single packet is necessary rather than sending packets individually addressed to each node. This is especially important with wireless networks having limited throughput available.
If a large group of wireless clients, for example, need to receive a particular video stream, then multicasting really pays off. The use of unicast packets to send the stream to each recipient individually would require many separate video streams, resulting in major performance impacts to the wireless network. With multicasting, only one stream is necessary. Of course this assumes that each client needs to receive the same video at the same time.
802.11 Multicast Support
The 802.11 (Wi-Fi) standards specify support for multicasting as part of asynchronous services. An 802.11 client station, such as a wireless laptop or PDA (not an access point), begins a multicast delivery by sending multicast packets in 802.11 unicast data frames directed to only the access point. The access point responds with an 802.11 acknowledgement frame sent to the source station if no errors are found in the data frame.
If the client sending the frame doesn’t receive an acknowledgement, then the client will retransmit the frame. With multicasting, the leg of the data path from the wireless client to the access point includes transmission error recovery. The 802.11 protocols ensure reliability between stations in both infrastructure and ad hoc configurations when using unicast data frame transmissions.
After receiving the unicast data frame from the client, the access point transmits the data (that the originating client wants to multicast) as a multicast frame, which contains a group address as the destination for the intended recipients. Each of the destination stations can receive the frame; however, they do not respond with acknowledgements. As a result, multicasting doesn’t ensure a complete, reliable flow of data.
The lack of acknowledgments with multicasting means that some of the data your application is sending may not make it to all of the destinations, and there’s no indication of a successful reception. This may be okay, though, for some applications, especially ones where it’s okay to have gaps in data. For instance, the continual streaming of telemetry from a control valve monitor can likely miss status updates from time-to-time.
Impacts on Throughput
Another issue with multicasting to consider is that multicast frames may experience lower quality of service. With 802.11 networks, lower throughput will definitely be the case when one or more of the wireless clients are using the 802.11 power save mode.
An access point buffers all multicast frames and sends them immediately following the next DTIM (delivery traffic indication message) if any one client associated with the access point enables power saving mode. When all stations have power saving off, then the access point transmits a multicast frame as soon as possible and doesn’t wait for the next DTIM.
The DTIM interval, which you configure in the access point, indicates when the DTIM occurs. A DTIM interval is a count of the number of beacon frames that must occur before the access point sends the buffered multicast frames. For example, a DTIM interval equal to one means that the multicast frames are sent after each beacon frame. A DTIM interval of two indicates that multicast frames are sent after every two beacon frames, and so on. Because each beacon frame includes a field that identifies the DTIM interval, all stations know when to wake up and receive multicast frames if they’re implementing power saving.
Because of the buffering of multicast frames, there can be substantial delays in the delivery of multicast frames. If you plan to use multicasting as part of a particular application, then be certain to test throughput with at least one wireless client using power save mode, even if you don’t plan to use power management with any of your client devices. Remember, all it takes is one wireless client using 802.11 power saving to cause the access point to buffer multicast frames for all clients, and you may not be able to control whether or not users switch on power save mode.
The default DTIM intervals of the various vendors vary, but they are usually one, two, or three. Of course you can set the DTIM interval to what ever you like. If possible, set the DTIM interval to one if implementing multicasting as an integral part of your application.
Battery Life Considerations
Keep in mind that the optimum DTIM interval setting is a tradeoff between throughput and power savings. A low DTIM interval will result in better throughput, but battery life will decrease for stations implementing power save mode.
The reason is that the sleeping stations wake up more often with lower DTIM intervals and stay awake longer to receive the multicast frames. For instance, broadcast frames impact all clients in this manner regardless of whether that the stations actually need the broadcasted information. In practice, I’ve seen battery life of power saving clients decrease by twenty percent when applications are using multicasting as the primary data delivery mechanism and the DTIM interval is set to one.
Concluding Thoughts
Regardless of the potential issues, don’t shy away from using multicasting. If your application is sending the same information to many clients, then multicasting should be right for you!
Jim Geier is an independent consultant and founder of Wireless-Nets, Ltd (www.wireless-nets.com ), a consulting firm assisting municipalities, enterprises, hospitals, airports, and equipment providers with the development and deployment of wireless networks.
Tags:
Click to add your tags...,
| 
This was just the right length. Good info.
