Fixing up a WLAN for voice

[James.Longman]

Hi All,

A little help if I may? I've inherited a small wireless network (6 autonomous APs, no WLC) that's being used for voice and data. There's two SSIDs configured on the APs (imaginatively named "voice" and "data") which are trunked back to the wired switches. The problem is we're dropping a lot of calls on the wireless phones (7925) - wired phones are fine, so I think this is a wireless problem. Moving around with the phones aggravates the problem, but you don't have to roam to get a dropped call.

Setup looks good, good coverage, sensible frequency selection, etc. However, the config looks very simple but appears to have had no modifications to actively support wireless:

dot11 ssid data
vlan 100
authentication open
authentication key-management wpa version 2
guest-mode
mbssid guest-mode
wpa-psk ascii 7 <key1>
!
dot11 ssid voice
vlan 200
authentication open
authentication key-management wpa version 2
mbssid guest-mode
wpa-psk ascii 7 <key2>

interface Dot11Radio0
no ip address
no ip route-cache
encryption mode ciphers aes-ccm
encryption vlan 100 mode ciphers aes-ccm
encryption vlan 200 mode ciphers aes-ccm
!
ssid data
!
ssid voice
!
antenna gain 0
mbssid
speed  basic-1.0 basic-2.0 basic-5.5 basic-11.0 basic-6.0 basic-9.0 basic-12.0 basic-18.0 basic-24.0 basic-36.0 basic-48.0 basic-54.0 m8. m9. m10. m11. m12. m13. m14. m15.
channel 2462
station-role root
!
interface Dot11Radio0.100
encapsulation dot1Q 100
no ip route-cache
bridge-group 100
bridge-group 100 subscriber-loop-control
bridge-group 100 block-unknown-source
no bridge-group 100 source-learning
no bridge-group 100 unicast-flooding
bridge-group 100 spanning-disabled
!
interface Dot11Radio0.200
encapsulation dot1Q 200
no ip route-cache
bridge-group 200
bridge-group 200 subscriber-loop-control
bridge-group 200 block-unknown-source
no bridge-group 200 source-learning
no bridge-group 200 unicast-flooding
bridge-group 200 spanning-disabled
!
interface GigabitEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
no keepalive
!
interface GigabitEthernet0.100
encapsulation dot1Q 100
no ip route-cache
bridge-group 100
no bridge-group 100 source-learning
bridge-group 100 spanning-disabled
!
interface GigabitEthernet0.200
encapsulation dot1Q 200
no ip route-cache
bridge-group 200
no bridge-group 200 source-learning
bridge-group 200 spanning-disabled

So, I'm thinking of adding the following (lifted from here http://timrousset.blogspot.co.uk/2011/05/autonomous-ap-voice-qos.html primarily):

dot11 ssid voice
admit traffic
!
dot11 arp-cache optional
dot11 priority-map avvid
dot11 phone dot11e
!
interface Dot11Radio0
speed basic-12.0 18.0 24.0
dot11 qos class voice local
admission-control
admit-traffic narrowband max-channel 70 roam-channel 6
!
dot11 qos class voice cell
admission-control
!
!
class-map voice
match ip dscp ef
class-map video
match ip dscp cs4
class-map voicecontrol
match ip dscp cs3
!
policy-map QoS
class voice
set cos 6
class video
set cos 5
class voicecontrol
set cos 4
!
int d0.200
service-policy input QoS
servicy-policy output QoS
!
int f0.200
service-policy input QoS
service-policy output QoS
!

Reading all that back looks good to me, makes sense, mostly. And obviously I'll need to arrange QoS trust on the wired switches behind.

A few questions:

1) What's "dot11 phone dot11e" do?
2) Why limit the speeds to "basic-12.0 18.0 24.0" and is that still recommended when a data SSID exists?
3) And, most importantly, is this really enough to help resolve dropped calls? (Or, is the lack of this config enough to drop calls?) Is there more I should be thinking of?

Any feedback greatly appreciated,

James

Hi All,A little help if I may? I've inheritted a small wireless network (6 autonomous APs, no WLC) that's being used for voice and data. There's two SSIDs configured on the APs (imaginiatively named "voice" and "data") which are trunked back to the wired switches. The problem is we're dropping a lot of calls on the wireless phones (7925) - wired phones are fine, so I think this is a wireless problem. Moving around with the phones agrivates the problem, but you don't have to roam to get a dropped call.The config looks very simple but appears to have had no modifications to actively support wireless:dot11 ssid data
   vlan 100
   authentication open
   authentication key-management wpa version 2
   guest-mode
   mbssid guest-mode
   wpa-psk ascii 7 <key1>
!
dot11 ssid voice
   vlan 200
   authentication open
   authentication key-management wpa version 2
   mbssid guest-mode
   wpa-psk ascii 7 <key2>interface Dot11Radio0
no ip address
no ip route-cache
encryption mode ciphers aes-ccm
encryption vlan 100 mode ciphers aes-ccm
encryption vlan 200 mode ciphers aes-ccm
!
ssid data
!
ssid voice
!
antenna gain 0
mbssid
speed  basic-1.0 basic-2.0 basic-5.5 basic-11.0 basic-6.0 basic-9.0 basic-12.0 basic-18.0 basic-24.0 basic-36.0 basic-48.0 basic-54.0 m8. m9. m10. m11. m12. m13. m14. m15.
channel 2462
station-role root
!
interface Dot11Radio0.100
encapsulation dot1Q 100
no ip route-cache
bridge-group 100
bridge-group 100 subscriber-loop-control
bridge-group 100 block-unknown-source
no bridge-group 100 source-learning
no bridge-group 100 unicast-flooding
bridge-group 100 spanning-disabled
!
interface Dot11Radio0.200
encapsulation dot1Q 200
no ip route-cache
bridge-group 200
bridge-group 200 subscriber-loop-control
bridge-group 200 block-unknown-source
no bridge-group 200 source-learning
no bridge-group 200 unicast-flooding
bridge-group 200 spanning-disabled
!
interface GigabitEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
no keepalive
!
interface GigabitEthernet0.100
encapsulation dot1Q 100
no ip route-cache
bridge-group 100
no bridge-group 100 source-learning
bridge-group 100 spanning-disabled
!
interface GigabitEthernet0.200
encapsulation dot1Q 200
no ip route-cache
bridge-group 200
no bridge-group 200 source-learning
bridge-group 200 spanning-disabled
!
So, I'm think of adding the following (lifted from here http://timrousset.blogspot.co.uk/2011/05/autonomous-ap-voice-qos.html primarily):dot11 ssid voice
  admit traffic
!
dot11 arp-cache optional
dot11 priority-map avvid
dot11 phone dot11e
!
interface Dot11Radio0
  speed basic-12.0 18.0 24.0
  dot11 qos class voice local
    admission-control
    admit-traffic narrowband max-channel 70 roam-channel 6
!
  dot11 qos class voice cell
    admission-control
!
!
class-map voice
  match ip dscp ef
class-map video
  match ip dscp cs4
class-map voicecontrol
  match ip dscp cs3
!
policy-map QoS
  class voice
   set cos 6
  class video
   set cos 5
  class voicecontrol
   set cos 4
!
int d0.20
  service-policy input QoS
  servicy-policy output QoS
!
int f0.20
  service-policy input QoS
  service-policy output QoS
!
Reading all that back looks good to me, makes sense, mostly. And obviously I'll need to arrange QoS trust on the wired switches behind.A few questions:1) What's "dot11 phone dot11e" do?
2) Why limit the speeds to "basic-12.0 18.0 24.0" and is that still recomended when a data SSID exists?
3) Is this really enough to help resolve dropped calls? Is there more I should be thinking of?Any feedback greatly appreciated,James

[Tony Rosolek]

i think you have a real bad base for an good voice-deployment. you need a sitesurvey for right cell overlap 15-20% for roaming and an controller or wds for good roaming-handover.

what APs do you use? are they single b/g radio?

separating voice (.a) and data (.g), would help alot.

in 802.11a you have more channels and usually lower interference.

1) What's "dot11 phone dot11e" do?

2) Why limit the speeds to "basic-12.0 18.0 24.0" and is that still recommended when a data SSID exists?

1) this enables new qbss ie in beacon-frames.

this shows channel utilization and the phone can decide wich AP to use, if there are multiple APs in range

the default is an legacy ie in beacons, this can only show the AP-load without CCA

the qbss ie adds "better load" because it checks the channel. (interference, other 802.11 transmissions on his channel)

i think this wouldnt help you, because you have only six APs, there will be seldom an tough decission for the phone wich AP to use.

2) limit basic data rates to 12.0 and higher, will be good. because of faster transmissions from the stations there will be "more free channel-time".

the AP sends his beacons at the lowest speed eg 1.0 this needs much longer as if he sends it with 12.0

but you should enable all data rates 12 18 24 36 54, because you want that your stations transmit at full speed if possible.

i think the recommendation from your link only goes to 24.0 because many phones only use 24.0, but your mixed mode should use the highest rates possible.

if you disable the lower data rates you improve performance, but it is possible that some far away clients cannot connect anymore.

Sent from Cisco Technical Support iPad App

[James.Longman]

Tony,

Thanks for getting back to me - and sorry it's taken a while to respond, I've been off! I did get a chance to look into your first point about a site survey though. As I understand it, a survey was performed and APs installed with overlap for roaming and without interfering frequencies. I don't have an AirMagent or similar to check, but a walk around with NetStumbler seems to confirm this is the case.

You are quite right about the WLC, there is talk of expanding with wireless and I'll make a strong push for the WLC then. Of course, we need to solve the voice issue before we spend more money on wireless...so there's a chicken and egg problem there...

The APs are all A/G/N capable 1040s and at present broadcast both the data and voice SSID on both frequencies, I've only included the G interface in the configuration above, the A radio interface is identical with on exception. The G radio includes:

speed  basic-1.0 basic-2.0 basic-5.5 basic-11.0 basic-6.0 basic-9.0 basic-12.0 basic-18.0 basic-24.0 basic-36.0 basic-48.0 basic-54.0 m8. m9. m10. m11. m12. m13. m14. m15.

But there is no speed setting for the A radio. That seems a little odd?

Anyway, I think my plan is to as per your recomendation:

1. Move the voice SSID to only the A radios
2. Move the data SSID to only the G radios
3. Probably skip dot11 phone dot11e (or include it as it does no harm?)
4. Limit the A radio to 12 18 24 36 54
5. No limits on the G radio
6. Possibly resurvey
7. Push for a WLC down the line

Finally, does the rest of my QoS marking planned for the A radio interface make sense and seem wise?

Thanks again!