wirless experts chime in please - impossible scenario

[spidey07]

let's try this again...

The application is providing on-demand video based training to a few hundred clients. Wirelessly, all located in a large open area environment (think warehouse.) The video is served up via a web server and windows media files...*.wmv.

Here's the background on the infrastructure. It is a Cisco SWAN solution with a few hundred access points using fast secure layer 3 roaming via redundant WLSMs in 6500s.

Here's the problem:
1) Using 10-20 clients via a wired network work's great.
2) Testing with 1 or 2 clients via a single access point works great
3) Testing with 5-7 clienst via a single access point barely works...lots of stuttering and a complet loss of video. During these test analyzers show 4 Mbs traffic.
4) I have any and all means to make this feasible - provide broadcast quality video wirelessly to a few hundred clients.

I'm thinking it may not be a bandwidth problem, but more of a quality of service problem. Looking to possibly test/implment QoS on wireless.

Thoughts? Will wireless QoS help or am I barking up the wrong tree. In my gut I just simply don't believe 802.11 can offer what I'm looking for. we're even tossing around the idea of microcells of wireless using 802.11a and only having a few clients per AP, meaning blanket the whole floor with a few dozen 802.11a access points and 8 channels.

thanks in advance.

 

[Fardringle]

I like wind chimes. I have some really neat ones that are professionally tuned for sound quality and accuracy of tone.

I also work regularly with wireless networks.

Is that what you had in mind? With a blank post it's hard to tell for sure.

 

[Garion]

A couple more wee details might help...

B or G? If it's G, are you *sure* that everyone has G cards so it's not stepping down to B for everyone? If things are choking at 4Mb/s, I'm guessing B.

What bitrate video? If you get 4Mb/s for 4-7 clients, I assume you're pushing a minimum of 600Kb/s.

Unicast or multicast? I'm gussing unicast if you're seeing bandwidth aggregate like that.

What's your stream source for the clients? Windows streaming server or some kind of proxy to split it at the local site?

Now, onto some real suggestions:

1: Quit using unicast. Work on multicast, at least within your wireless. Multicast works very, very well for this kind of thing and should alleviate any kind of bandwidth issues you're seeing with unicast.

2: How important is broadcast-quality for the wireless users? You could easily create a multi-bitrate stream instead of a single bitrate stream and let their clients step down to the lower bitrate when they start to have problems pulling the larger bitrate streams. Just make sure that you've got some "fluff" content at the beginning of the event to make sure that they can step down and not lose any content.

3: If you're using a proxy to split the streaming, you might also be able to write a proxy re-write rule to send that particular subnet to a lower-quality stream instead of trying to do a MBR stream for everyone.

- G

 

[nweaver]

make sure you cisco AP's are channel scanning, to avoid stomp. Also, you are better off going with "A" if you can, as you could setup the AP's with hard coded channels that don't interfere. If you have it, try and use a WLSE server to do a client walkabout, import a map of the building and get all your AP's added. This will show you overlap and dead spots. Do some rm checks for noise. I think that reducing the number of AP's might help. If you have too many B/G ap's, they start to stomp on each other. A well planned placing of a few AP's, with channels setup to minimize noise and same channel stomping would be better then a whole bunch of AP's that are just randomly crusing channels. You may consider setting up different SSID's for different areas. Roaming would be more difficult, but then you could make sure clients are on specific bands/channels. Mixing A and G would help too, as A is soooo much less prone to noise and interference (but you may not find too many A band cards there).

What AP's are you using? What other wireless infrastructure do you have/can you get (like a WLSE server, other brands of AP's, etc). Do you have 2.0 or 3.0 CCX Certified clients? (they can do Radio measurments, or RM)

 

[spidey07]

Originally posted by: Garion
A couple more wee details might help...

B or G? If it's G, are you *sure* that everyone has G cards so it's not stepping down to B for everyone? If things are choking at 4Mb/s, I'm guessing B.

What bitrate video? If you get 4Mb/s for 4-7 clients, I assume you're pushing a minimum of 600Kb/s.

Unicast or multicast? I'm gussing unicast if you're seeing bandwidth aggregate like that.

What's your stream source for the clients? Windows streaming server or some kind of proxy to split it at the local site?

Now, onto some real suggestions:

1: Quit using unicast. Work on multicast, at least within your wireless. Multicast works very, very well for this kind of thing and should alleviate any kind of bandwidth issues you're seeing with unicast.

2: How important is broadcast-quality for the wireless users? You could easily create a multi-bitrate stream instead of a single bitrate stream and let their clients step down to the lower bitrate when they start to have problems pulling the larger bitrate streams. Just make sure that you've got some "fluff" content at the beginning of the event to make sure that they can step down and not lose any content.

3: If you're using a proxy to split the streaming, you might also be able to write a proxy re-write rule to send that particular subnet to a lower-quality stream instead of trying to do a MBR stream for everyone.

- G

Thanks for the input Garion.

The access points are Cisco 1231 802.11 b/g with a single radio. During the test all cards were b/g and the access point showed only G associations. I guess I could enforce only G associations during the next test just to make sure because there are wireless clients all over the place with a combination of different cards.

As far as bit rate there really isn't one. Unfortunately this isn't streaming video. It is nothing more than web pages with windows media encoded files on them. So the protocol is really HTTP. Unfortunately multicast really isn't an option politically even though I've pushed for it. (8th layer)

There is no proxy, just straig HTTP. Source is a server running IIS.

 

[spidey07]

Originally posted by: nweaver
make sure you cisco AP's are channel scanning, to avoid stomp. Also, you are better off going with "A" if you can, as you could setup the AP's with hard coded channels that don't interfere. If you have it, try and use a WLSE server to do a client walkabout, import a map of the building and get all your AP's added. This will show you overlap and dead spots. Do some rm checks for noise. I think that reducing the number of AP's might help. If you have too many B/G ap's, they start to stomp on each other. A well planned placing of a few AP's, with channels setup to minimize noise and same channel stomping would be better then a whole bunch of AP's that are just randomly crusing channels. You may consider setting up different SSID's for different areas. Roaming would be more difficult, but then you could make sure clients are on specific bands/channels. Mixing A and G would help too, as A is soooo much less prone to noise and interference (but you may not find too many A band cards there).

What AP's are you using? What other wireless infrastructure do you have/can you get (like a WLSE server, other brands of AP's, etc). Do you have 2.0 or 3.0 CCX Certified clients? (they can do Radio measurments, or RM)

Thanks NMweaver. The APs are 1231. The overall wireless design is complete - all channels are hard coded. We have WLSE in place and used it to help with site survey and map the access points.

The wireless LAN is a Cisco SWAN implementation meaning - cisco APs, redundant WLSM modules for layer 3 roaming, WLSE, Radius server.

I'm looking into quality of service and will be testing 802.11a.

As far as clients the newer laptops are using the intel 2200g internal card and probably what we'll stick with because it supports/integrates 802.1x and CCX well.

 

[Garion]

Ouch - Streaming via HTTP is bad, bad karma. HTTP is really not really suited to streaming, MMS is much, much more efficient. I'd strongly recommend you try MS Streaming Server. It's free and works quite well. You don't even have to do multicast, just set it up. It does take a bit more manual work for each new stream you want to send out but it's ultimately worth it. It'll probably only take you a couple hours to build the streaming server and setup your first stream.

- G

 

[spidey07]

Originally posted by: Garion
Ouch - Streaming via HTTP is bad, bad karma. HTTP is really not really suited to streaming, MMS is much, much more efficient. I'd strongly recommend you try MS Streaming Server. It's free and works quite well. You don't even have to do multicast, just set it up. It does take a bit more manual work for each new stream you want to send out but it's ultimately worth it. It'll probably only take you a couple hours to build the streaming server and setup your first stream.

- G

8th layer man. no way can I have the app changed. MMS is great and how I'm used to doing video. There are literally hundreds of videos.

 

[nweaver]

have you done manual channel load RM requests? I don't know if you know how, but you can always send the rm to ffff.ffff.ffff and alll clients associated to that AP will reply, I would build a multi rm request that ask for channel load and noise.

 

[spidey07]

Originally posted by: nweaver
have you done manual channel load RM requests? I don't know if you know how, but you can always send the rm to ffff.ffff.ffff and alll clients associated to that AP will reply, I would build a multi rm request that ask for channel load and noise.

manual channel load RM requests?

what dat?

 

[nweaver]

I normally do it from the console....you have to turn some debugging on (don't have all my docs here with me) deb wlccp ap rm packet (I think)
then you send an rm request to the client by putting hex into a text file, and typing a command into the ap console. You then get the reply in hex, and you can figure out how to decode it, so you can ask Client 1 on AP 1 what channel load is (on channel and off channel) and/or what noise it sees on a perticular channel.

 

[ktwebb]

Sure sounds like a bandwidth problem to me. It is shared bandwidth with AP's after all and the fact it works pretty well with only a couple of associations but starts to stutter when you put a bigger load on the AP would make me look at bandwidth constraints and overall architecture of 802.11 devices. Been a few years since I've been in the day to day wireless business so looks like nweaver probalby is better equipped to assist. Sorry.