VoIP in IEEE 802.

11 Networks

Henning Schulzrinne
Andrea G. Forte, Sangho Shin
Department of Computer Science
Columbia University
December 1, 2006

VoIP and IEEE 802.11

Architecture

Internet
Internet

Router

Router

PBX
160.38.x.x

128.59.x.x

AP

AP

Mobile Node

VoIP and IEEE 802.11

Problems

Support for real-time multimedia

Handoff

L2 handoff

Authentication

SIP re-INVITE

Low capacity

Subnet change detection

IP address acquisition time

SIP session update

802.11i, WPA, WEP

L3 handoff

Scanning delay

Large overhead
Limited bandwidth

Quality of Service (QoS)

Inefficient support at MAC layer

3

VoIP and IEEE 802.11

Solutions

Support for real-time multimedia

Handoff

Low capacity

Fast L2 handoff
Fast L3 handoff
Passive DAD (pDAD)
Cooperative Roaming (CR)
Dynamic PCF (DPCF)

Quality of Service (QoS)

Adaptive Priority Control (APC)

4

Reducing MAC Layer Handoff

in IEEE 802.11 Networks

Fast Layer 2 Handoff

Layer 2 Handoff delay

APs available
on all channels

Mobile Node
Probe Request (broadcast)
Probe Response(s)

Discovery Phase
Probe Delay

New AP
Authentication Request
Open Authentication Delay

Authentication Response
Association Request

Open Association Delay

Authentication Phase

Association Response

Fast Layer 2 Handoff

Overview

Problems

Handoff latency is too big for VoIP

Seamless VoIP requires less than 90ms latency

Handoff delay is from 200ms to 400ms

The biggest component of handoff latency

is probing (over 90%)

Solutions

Selective scanning
Caching
7

Fast Layer 2 Handoff

Selective Scanning

In most of the environments (802.11b & 802.11g),

only channel 1, 6, 11 are used for APs
Two APs that have the same channel are not
adjacent (Co-Channel interference)
Scan 1, 6, 11 first and give lower priority to other
channels that are currently used
8

Fast Layer 2 Handoff

Caching

Background

Spatial locality (Office, school, campus)

Algorithm

After scanning, store the candidate AP info

into cache (key=current AP).
Use the AP info in cache for association
without scanning when handoff happens.
1

Key

AP1

AP2

Current AP

Next best AP

Second best AP

N
9

Fast Layer 2 Handoff

Measurement Results Handoff time

Original Handoff
Selective Scanning
Caching

Handoff Time
600
500

msec

400
300
200
100
0
1

10

Experiments

10

Fast Layer 2 Handoff

Conclusions

Fast MAC layer handoff using selective

scanning and caching
Selective scanning : 100~130 msec
Caching : 3~5 msec
Low power consumption (PDAs)
Dont need to modify AP, infrastructure,
or standard. Just need to modify the
wireless card driver!
11

Layer 3 Handoff

12

L3 Handoff
Motivation

Problem

When performing a L3 handoff, acquiring a

new IP address using DHCP takes on the
order of one second
The L3 handoff delay too big for real-time
multimedia sessions

Solution

Fast L3 handoff
Passive Duplicate Address Detection (pDAD)
13

Fast L3 Handoff
Overview

DHCP Server

MN
L2 Handoff
Complete
DHCP DISCOVER

DAD
DHCP OFFER
DHCP REQUEST
DHCP ACK

We optimize the layer 3 handoff time as

follows:

Subnet discover
IP address acquisition

14

Fast Layer 3 Handoff

Subnet Discovery (1/2)

Current solutions

Router advertisements

Usually with a frequency on the order of

several minutes

DNA working group (IETF)

Detecting network attachments in IPv6

networks only

No solution in IPv4 networks for detecting a

subnet change in a timely manner
15

Fast Layer 3 Handoff

Subnet Discovery (2/2)

Our approach

After performing a L2 handoff, send a bogus

DHCP_REQUEST (using loopback address)
DHCP server responds with a DHCP_NAK which is
relayed by the relay agent
From the NAK we can extract subnet information
such as default router IP address (IP address of
the relay agent)
The client saves the default router IP address in
cache
If old AP and new AP have different default router,
the subnet has changed
16

Fast Layer 3 Handoff

Fast Address Acquisition

IP address acquisition

This is the most time consuming part of the L3 handoff

process DAD takes most of the time
We optimize the IP address acquisition time as follows:
Checking DHCP client lease file for a valid IP
Temporary IP (Lease miss) The client picks a candidate IP
using particular heuristics
SIP re-INVITE The CN will update its session with the TEMP_IP
Normal DHCP procedure to acquire the final IP
SIP re-INVITE The CN will update its session with the final IP
While acquiring a new IP address via DHCP, we do not have any
disruption regardless of how long the DHCP procedure will be.
We can use the TEMP_IP as a valid IP for that subnet until the DHCP
procedure ends.

17

Fast Layer 3 Handoff

TEMP_IP Selection

Roaming to a new subnet

Roaming to a known subnet (expired lease)

MN starts to send ARP requests to 10 IP addresses in

parallel, starting from the IP it last used in that subnet.

Critical factor: time to wait for an ARP response.

Select random IP address starting from the routers IP

address (first in the pool). MN sends 10 ARP requests in
parallel starting from the random IP selected before.

Too small higher probability for a duplicate IP

Too big increases total handoff time

TEMP_IP: for ongoing sessions only

Only MN and CN are aware of the TEMP_IP
18

Fast Layer 3 Handoff

Measurement Results (1/2)
MN

DHCPd

Router

CN

L2 handoff
complete
DHCP Req.
ARP Req.

22 ms

NAK

Detecting
subnet change

138 ms

Waiting time

IP acquisition

ARP Req.
4 ms

ARP Resp.

4 ms

Processing
overhead

29 ms

SIP signaling

SIP INVITE
SIP OK
RTP packets (TEMP_IP)
SIP ACK

19

Fast Layer 3 Handoff

Measurement Results (2/2)
SIP Signaling

600

Client processing
IP acquisition
Detection of subnet change

29
8
500

400

Scenario 1

Scenario 2

ms

300

518

200

29
8

29
8

138
22
0

Current
approach

29
8

22
Scenario 1

Scenario 2

Scenario 3

The MN enters in a
new subnet it has
been before and it
has an expired lease
for that subnet

Scenario 3

138

100

The MN enters in a
new subnet for the
first time ever

The MN enters in a
new subnet it has
been before and still
has a valid lease for
that subnet
20

Fast Layer 3 Handoff

Conclusions

Modifications in client side only (requirement)

Forced us to introduce some limitations in our approach

Works today, in any network

Much faster than DHCP although not always fast

enough for real-time media (scenarios 1 and 2)

Scenario 3 obvious but Windows XP

ARP timeout critical factor SIP presence

SIP presence approach (Network support)

Other stations in the new subnet can send ARP requests on

behalf of the MN and see if an IP address is used or not. The
MN can wait for an ARP response as long as needed since it
is still in the old subnet.
21

Passive DAD

Overview
DHCP server

Address Usage Collector (AUC)

TCP Connection
Flag

IP

Client ID

IP
IP1
IP2
IP3

MAC Expire
MAC1
MAC2
MAC3

570
580
590

Client ID MAC
DUID1
DUID2
DUID3

MAC1
MAC2
MAC3

Broadcast-ARP-DHCP
Router/Relay Agent

SUBNET

AUC builds DUID:MAC pair table (DHCP traffic only)

AUC builds IP:MAC pair table (broadcast and ARP traffic)
The AUC sends a packet to the DHCP server when:

a new pair IP:MAC is added to the table

a potential duplicate address has been detected
a potential unauthorized IP has been detected

DHCP server checks if the pair is correct or not and it records the IP
address as in use. (DHCP has the final decision!)
22

Passive DAD

Traffic load AUC and DHCP

23

Passive DAD

Packets/sec received by DHCP

24

Passive DAD

Conclusions

pDAD is not performed during IP address acquisition

Low delay for mobile devices

Much more reliable than current DAD

Current DAD is based on ICMP echo request/response

not adequate for real-time traffic (seconds - too slow!)

most firewalls today block incoming echo requests by default

A duplicate address can be discovered in real-time and not

only if a station requests that particular IP address
A duplicate address can be resolved (i.e. FORCE_RENEW)

Intrusion detection

Unauthorized IPs are easily detected

25

Cooperation Between Stations

in Wireless Networks
Internet

26

Cooperative Roaming

Goals and Solution

Fast handoff for real-time multimedia in any network

Different administrative domains

Various authentication mechanisms
No changes to protocol and infrastructure
Fast handoff at all the layers relevant to mobility

Link layer
Network layer
Application layer

New protocol Cooperative Roaming

Complete solution to mobility for real-time traffic in wireless

networks
Working implementation available
27

Cooperative Roaming

Why Cooperation ?

Same tasks

Layer 2 handoff
Same information
Layer 3 handoff
Topology (failover)
Authentication
Same goals
DNS
Multimedia
Low latency
session update
Geo-Location
QoS
Services
Load balancing

Admission and
congestion control
Service discovery

28

Cooperative Roaming
Overview
9

Stations can cooperate and share information

about the network (topology, services)

Stations can cooperate and help each other in

common tasks such as IP address acquisition

Stations can help each other during the

authentication process without sharing
sensitive information, maintaining privacy and
security
Stations can also cooperate for applicationlayer mobility and load balancing
29

Cooperative Roaming
Layer 2 Cooperation
R-MN

Stations

NET_INFO_REQ
NET_INFO_RESP

Random waiting time

Stations will not send the same information and will not send all at
the same time

The information exchanged in the NET_INFO multicast frames

is:
APs {BSSID, Channel}
SUBNET IDs

30

Cooperative Roaming
Layer 3 Cooperation

Subnet detection

Information exchanged in NET_INFO

frames (Subnet ID)

IP address acquisition time

Other stations (STAs) can cooperate with

us and acquire a new IP address for the
new subnet on our behalf while we are still
in the OLD subnet
Not delay sensitive!
31

Cooperative Roaming
Cooperative Authentication (1/2)

Cooperation in the authentication process itself is not

possible as sensitive information such as certificates
and keys are exchanged.
STAs can still cooperate in a mobile scenario to
achieve a seamless L2 and L3 handoff regardless of
the particular authentication mechanism used.

In IEEE 802.11 networks the medium is shared.

Each STA can hear the traffic of other STAs if on the same
channel.

Packets sent by the non-authenticated STA will be dropped

by the infrastructure but will be heard by the other STAs on
the same channel/AP.

32

Cooperative Roaming
Cooperative Authentication (2/2)
AP

RN data
packets
+
relayed data
packets

802.11i
authentication
packets

Relayed Data Packets

RN

R-MN

One selected STA (RN) can relay packets to and

from the R-MN for the amount of time required by
the R-MN to complete the authentication process.
33

Cooperative Roaming
Measurement Results (1/2)

Handoff without authentication

1400

1210.0
1200

1000
867.0
800
ms

L2
L3
Total

600

400

343.0

200

4.2

11.4

15.6

0
CR

IEEE 802.11 Handoff

34

Cooperative Roaming
Measurement Results (2/2)

Handoff with authentication (IEEE 802.11i)

1800
1669.5
1579.8

1600

1531.6

1400

1200
967

1000

L2

ms

897

867

L3
Total

772.4

800

664.6
612.8
600

400

200
10 11.4 21.4
0
EAP-TLS (1024)

EAP-TLS (2048)

PEAP/MSCHAPv2
(1024)

CR

35

Cooperative Roaming
Other Applications

In a multi-domain environment Cooperative Roaming

(CR) can help with choosing AP/domain according to
roaming agreements, billing, etc.
CR can help for admission control and load balancing,
by redirecting MNs to different APs and/or different
networks. (Based on real throughput)
CR can help in discovering services (encryption,
authentication, bit-rate, Bluetooth, UWB, 3G)
CR can provide adaptation to changes in the network
topology (common with IEEE 802.11h equipment)
CR can help in the interaction between nodes in
infrastructure and ad-hoc/mesh networks
36

Cooperative Roaming
Conclusions

Cooperation among stations allows seamless L2 and

L3 handoffs for real-time applications (10-15 ms HO)
Completely independent from the authentication
mechanism used
It does not require any changes in either the
infrastructure or the protocol
It does require many STAs supporting the protocol
and a sufficient degree of mobility
Suitable for indoor and outdoor environments
Sharing information Power efficient
37

Improving Capacity of VoIP in

IEEE 802.11 Networks using
Dynamic PCF (DPCF)

38

Dynamic PCF (DPCF)

MAC Protocol in IEEE 802.11

Distributed Coordination Function (DCF)

Default MAC protocol

Contention Window

CSMA/CA
DIFS

DIFS

Defer Access

Next frame

Backoff

Busy Medium
Slot

Point Coordination Function (PCF)

Supports rudimentary QoS, not implemented

Contention Free Repetition Interval (Super Frame)
Contention Free Period (CFP)

PIFS

SIFS

SIFS

SIFS

SIFS

SIFS SIFS

D2+Ack
+poll

Beacon D1+poll
U1+ACK

Contention Period (CP)

poll
U2+ACK

DCF
CF-End

Null

39

Dynamic PCF (DPCF)

Problems of PCF

Waste of polls

VoIP traffic with silence suppression

Talking Period
poll

poll

Mutual Silence Period

poll

poll

poll

Listening Period

poll

1
1

Data

Data

ACK

Data

ACK

ACK

Wasted polls

Synchronization between polls and VoIP packets

App
CFP

poll

CP

poll

poll

poll

poll

MAC
Null

Null

failed

40

Dynamic PCF (DPCF)

Overview

Classification of traffic

Dynamic polling list

Store only active nodes

Dynamic CFP interval and More data field

Real-time traffic (VoIP) uses CFP, also CP

Best effort traffic uses only CP
Give higher priority to real-time traffic

Use the biggest packetization interval as a CFP interval

STAs set more data field (a control field in MAC header) of
uplink VoIP packets when there are more than two packets
to send AP polls the STA again
Solution to the various packetization intervals problem

Solution to the synchronization problem

Allow VoIP packets to be sent in CP only when there are

more than two VoIP packets in queue
41

Dynamic PCF (DPCF)

Simulation Results (1/2)

Capacity for VoIP in IEEE 802.11b

45

40

Number of VoIP Flows

37
DPCF

35

28

30

24
23

25

32%

PCF
30
28
DCF

20

14

15

13
10

77

DCF
PCF
DPCF

0
0

Transmission Rate (M b/s)

10

11

12

42

Dynamic PCF (DPCF)

Simulation Results (2/2)

Delay and throughput of 28 VoIP traffic and data traffic

3000
487.4
500

400.0
2000

400
311.5

1500

300

182.5
1000

200

67.4

500
24.8 17.8
10.6
0

DCF PCF DPCF

0

End-to-End Delay (ms)

Throughput (kb/s)

2500

600
544.8

FTP Throughput
VoIP Throughput
VoIP Delay (90%)

100
21.9

DCF PCF DPCF

1

26.1

29.2

DCF PCF DPCF

2

DCF PCF DPCF

3

Number of Data Sessions

43

Balancing Uplink and Downlink Delay

of VoIP Traffic in 802.11 WLANs
using Adaptive Priority Control (APC)

44

Adaptive Priority Control (APC)

Motivation
Uplink (90th%tile)
Downlink (90th%tile)
Uplink (AVG)
Downlink (AVG)

500
End-to-end delay (ms)

Big difference between

uplink and downlink
delay when channel is
congested
AP has more data, but
the same chance to
transmit them than
nodes
Solution?
AP needs have higher
priority than nodes
What is the optimal
priority and how the
priority is applied to the
packet scheduling? 45

600

400

Downlink Downlink

300
200

100

Uplink
0
26

27

28

29

30

31

32

33

34

Number of VoIP sources

20 ms packetization interval (64kb/s)

Adaptive Priority Control (APC)

Overview
Number of packets in queue of AP

Optimal priority (P) = QAP/QSTA

Simple
Average number of packets in queue of STAs
Adaptive to change of number of active STAs
Adaptive to change of uplink/downlink traffic
volume

Contention free transmission

Transmit P packets contention free

Precise priority control

P Priority
Transmitting three frames contention free three times
higher priority than other STAs.

No overhead
Can be implemented with 802.11e CFB feature
46

Adaptive Priority Control (APC)

Simulation Results
450
Uplink (90th%tile)
Downlink (90th%tile)
Uplink (AVG)
Downlink (AVG)

400
500

Uplink (90th%tile)
Downlink (90th%tile)
Uplink (AVG)
Downlink (AVG)

End-to-end delay (ms)

End-to-end delay (ms)

600

400
300

Downlink

200
100

Uplink

26 27 28 29 30 31 32 33 34
Number of VoIP sources

Capacity

350
300
250
200
150
100
50
0
30

25% Improvement

31

32

33

34

35

36

37

Capacity

Number of VoIP sources

20 ms packetization interval (64kb/s)

47

Experimental Capacity
Measurement in the ORBIT
Testbed

48

Capacity Measurement
ORBIT test-bed

Open access research test-bed for next

generation wireless networks
WINLab in Rutgers University in NJ

49

Capacity Measurement

Experimental Results - Capacity of CBR VoIP traffic

64 kb/s, 20 ms packetization interval

50

Capacity Measurement

Experimental Results - Capacity of VBR VoIP traffic

0.39 Activity ratio

51

Capacity Measurement
Factors that affects the capacity
Auto Rate Fallback (ARF)
algorithms

Preamble size

13 calls (ARF) 15 calls (No

ARF)
Because reducing Tx rate
does not help in alleviating
congestion
12 calls (long) 15 calls
(short)
Short one is used in wireless
cards

Packet generation intervals

among VoIP sources

14 calls 15 calls
In simulation, random
intervals needs to be used

1200
600

With
ARF
Long
Preamble
W/O ARF
Short Preamble

1000
500
End-to-end delay
delay (ms)
(ms)
End-to-end

800
400
600
300
400
200
200
100

00
12 10

13
16
11
12 14 13 1514
15
Number
of of
CBR
VoIP
sources
Number
VoIP
sources

16 17

52

Capacity Measurement
Other factors

Scanning APs

Retry limit

Nodes start to scan APs when experienced many

frame loss
Probe request and response frames could make
channels congested
Retry limit is not standardized and vendors and
simulation tools use different values
It can affect retry rate and delay

Network buffer size in the AP

Bigger buffer less packet loss, but long delay

53

IEEE 802.11 in the Large:

Observations at the IETF Meeting

54

Observations at the IETF Meeting

Introduction

65th IETF meeting

Data collection

21st ~ 23rd for three days

25GB data, 80 millions frames

Wireless network environment

Dallas, TX March, 2006

Hilton Anatole hotel
1,200 attendees

Many hotel 802.11b APs, 91 additional APs in 802.11a/b by

IETF
The largest indoor wireless network measured so far

What we have observed :

Bad load balancing

Too many useless handoffs
Overhead of having too many APs
55

Observations at the IETF Meeting

Load balancing

Throughput per client

160

140
120
Throughput (B/s )

100
Ch 1
Ch 6
Ch 11
802.11a

80
60
40

20
0
Session 1 (AM)

Lunch
Session 1 (PM)
IETF Sessions

Plenary

No load balancing
feature was used
Client distribution is
decided by the relative
proximity from the APs
Big difference in
throughput among
channels

Average throughput per client

in 802.11a/b
56

Observations at the IETF Meeting

Load balancing

Number of clients vs. Throughput

50000

180

Number of frames
Throughput

45000
40000

160
140

35000
Number of Frames

120

30000

20000
15000
10000
5000

Capacity in the channel

0
30

40

50

60

70

80

90

Clear correlation
between the number of
clients and throughput

The number of clients

can be used for load
80
balancing with low
60
Capacity in complexity
the channel of
40
implementation, in
20
large scale wireless
0
networks
100

25000

Throughput (KB/s)

100

Number of clients

57

Observations at the IETF Meeting

Handoff behavior

Too many handoffs are

performed due to
congestion

Distribution of session
time : time (x) between
handoffs

0< x < 1 min : 23%

1< x < 5 min : 33%

Handoff related frames

took 10% of total frames.

Too many inefficient

handoffs

Handoff to the same

channel : 72%
Handoff to the same
AP : 55%

700

600

162

84

500
Number of handoffs

131
222

400

227
C11
C6
C1

183
300
36
200
306

112
262
218

100
111
0
S1

Lunch
S1
IETF Sessions

The number of handoff per hour

in each IETF session

58

Observations at the IETF Meeting

Overhead of having multiple APs

Overhead from replicated multicast and

broadcast frames

All broadcast and multicast frames are

replicated by all APs Increase traffic
DHCP request (broadcast) frames are
replicated and sent back to each channel
Router
Router
Multicast and broadcast frames : 10%
A channel
A channel
59

Conclusions

What we have addressed

Fast handoff

Fairness between AP and STAs

A 32% improvement of the overall capacity

802.11 networks in congested environments

Fully balanced uplink and downlink delay

Capacity improvement for VoIP traffic

Handoffs transparent to real-time traffic

Inefficient algorithms in wireless card drivers

Other problems

Call Admission Control

Handoff between heterogeneous networks
60

Thank you.
Questions?
For more information:
http://www.cs.columbia.edu/IRT/wireless
http://www.cs.columiba.edu/~ss2020
http://www.cs.columbia.edu/~andreaf

61