WLAN Broadcast/Multicast Troubleshooting

Often, it makes sense to use Broadcast or Multicast for distribution of streaming audio over a network. The big advantage of using Broadcast/Multicast vs. directed (unicast) addressing is that one stream, one network load, is sufficient to reach an unlimited amount of devices connected to the same (sub)net.

Now, you would think - this is also ideal in case of a wireless network - one stream (let's say, 200kbps as an example) should pose no problem at all to a WLAN. You may even think that you could run 50 streams at 200kbps without much impact on the wireless network - because it is a 54Mbps WLAN ...

Well - i can almost guarantee you that the WLAN will be completely unusable, overloaded, no stream will make it if you try it. The same number of streams over a hardwired (ethernet) network work without any problems. If you try powerline ... same problems as with WLAN. So, why ?

The reason is quite simple: reliability of a WLAN is generally very low. Depending on the orientation of a device to the antenna, distance, noise etc, data blocks sent from and to the access point easily get corrupted. To make a wireless system workable and useable, it uses low level protocols, which ensure delivery by acknowledging and retrying - the 802.11 protocols (to simplify here ..). If you use "ping" on a WLAN, you will see that the ping times may vary quite a bit compared to a wired LAN, even if the network otherwise is not used. This is a direct result of eventual retries on the "lower" level.

Because a broadcast or multicast can generally not be acknowledged or retried (because a theoretically unlimited number of receivers want to receive it), an Access point will generally use a lower bitrate for the broadcast/multicast distribution (the lower the bitrate the higher the "readability" by the receiver). The reduction may go as far as using 1MBPS or 2MBPS speed for the broadcast blocks - despite being a 54MBbps (or even "more") network ! Of course, transmission time for such blocks is also much longer "on air" than if these would be sent with a much higher frequency, so if you have noise happening statistical, but quite frequently, it may be that those blocks then get more or less "hit" by noise (and thus not received correctly) in many cases. The result may be that just one audio stream at 200kbps, if sent via broadcast on a WLAN infrastructure, will "load" the WLAN network already with 20-30% (with overhead), try 5 streams, "just" 1Mbps - and the network is at 100% capacity. If you try to stream unicast (addressing the different devices separately), despite this needing n times the bandwidth, it may actually work much better for smaller n's (let's assume a stream is sent to 20 devices, 20x200kbps -> 4Mbps, this will be working ok on most 54mbps WLANs because the blocks are sent to the individual receivers at full speed (assuming they have reasonable reception), even with "some" retries, the full network capacity will not be used.

So - despite Broadcast/Multicast "saving" bandwidth by using only 1x network capacity, in a WLAN environment, the system will typically work much more stable and the WLAN will be less loaded if distribution is done using unicast, unless a really large number of devices needs to be streamed to.

Barix devices can help on this. You can use the RTP Replicator application, typically on a Barionet, to "resend" an RTP stream to more than 100 devices concurrently (64kbps audio stream), and even the Instreamer can support up to about 30 "stream pullers" using BRTP.

Barix staff will be happy to consult you on individual system designs.