Andrea G. Forte Sangho Shin Henning Schulzrinne VoIP in IEEE 802.11 Andrea G. Forte Sangho Shin Henning Schulzrinne

Handoff - Overview L2 handoff L3 handoff Connectivity (Scanning, Auth., Assoc.) Fast MAC Layer Handoff Authentication (802.1x, 802.11i) Work in progress (!) L3 handoff Subnet detection IP address acquisition (DAD) Fast L3 handoff Passive DAD Multimedia Session update (SIP)

Fast MAC Layer Handoff (1/2) Overview Selective scanning We do not need to scan all the channels. Some heuristics can be used to improve the scanning procedure. Cache The APs information is saved on the client in a cache so to avoid unnecessary scans in the future handoffs. Changes in the client ONLY.

Fast MAC Layer Handoff (2/2)

DHCP - Overview DHCP Server Assigns IP addresses to clients that request them via the DHCP protocol. It directly serve clients in its subnet while it needs the Relay Agent in order to server clients in a different subnet than its own. Relay Agent (RA) We usually have one RA per subnet and usually the RA is located on the router/gateway of that subnet. The RA needs to relay DHCP packets between its network and the DHCP server. The server will know to which subnet a client belongs to (and which IP address to assign) according to which RA the packets came from.

Fast Layer 3 Handoff (1/4) Spatial locality  Cache We use an extension of the L2 cache: Current AP (KEY) Best AP Second best AP MAC A MAC B MAC C Channel 1 Channel 11 Channel 6 Gateway D Gateway E Gateway F + LEASE FILE

Fast Layer 3 Handoff (2/4) Subnet detection Send a bogus DHCP REQUEST packet so to acquire the gateway/router IP address. We then compare the new gateway IP address with the one contained in our L2 cache. If they match the subnet is the same and no other action is needed; if they do not match, we have a subnet change and a L3 handoff has to be performed.

Fast Layer 3 Handoff (3/4) 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 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 now any disruption regardless of how long the DHCP procedure will take. We can use the TEMP_IP as a valid IP for that subnet until the DHCP procedure completes.

Fast Layer 3 Handoff (4/4) Multimedia session update (SIP) After a change in IP address, we have to inform the Correspondent Node (CN) about it. This is usually done with a re-Invite. The data stream will be resumed right after the 200 OK has been received. MN SIP Re-INVITE RTP Data SIP ACK New IP CN SIP OK

Fast Layer 3 - Implementation SIP client (mca) Wireless card driver (HostAP driver) DHCP client User Space Kernel Space kernel 2.4.20 Red Hat 9.0 MCA: SIP client for PDAs by SIPquest Inc. DHCP client by Internet System Consortium (ISC) HostAP wireless driver

Fast Layer 3 Handoff - Results 22 138 8 29 20 40 60 80 100 120 140 160 180 200 L3 handoff time (ms) Scenario 1 Scenario 2 Scenario 3 SIP Signaling Client processing IP acquisition Detection of subnet change

Passive DAD Duplicate Address Detection (DAD) Before the DHCP server decides to assign an IP address, it has to be sure that such address is not already in use. In order to do this, the DHCP server sends ICMP Echo requests and waits for ICMP Echo replies. The delay introduced by DAD is on the order of seconds! Passive DAD (p-DAD) We introduce a new agent, namely Address Usage Collector (AUC), which collects information about the IP addresses in use in its subnet. The AUC will then inform the DHCP server about IP addresses already in use in a particular subnet.

Thank You! For more information: Web: E-mail: http://www.cs.columbia.edu/~andreaf http://www.cs.columbia.edu/IRT E-mail: andreaf@cs.columbia.edu

Related Work Requirements IEEE 802.11k IEEE 802.11f (Dead) IEEE 802.11r SyncScan. Requirements Change in the protocol. Change in the infrastructure.

Handoff delay Mobile station All APs Probe delay New AP Probe request (broadcast) Probe response New AP Authentication request Authentication response Association request Association response Probe delay Authentication delay Association delay

Handoff Delay

Experiment Result – Packet Delay

Experiment Result – Packet Loss

WEP – Shared Secret Auth +Ass ~ 7msec Cache: Handoff Delay ~7msec

IEEE 802.11 MAC Protocols Distributed Coordination Function (DCF) No QoS supported The de-facto standard MAC protocol Point Coordination Function (PCF) Suitable for real-time media Optional and generally not adopted

Dynamic PCF (1/2) Classification of traffic Real-time traffic (VoIP)  Pollable Uses CFP and CP Best effort traffic  Not Pollable Uses CP only Give higher priority to real-time traffic also in CP Dynamic Polling List Store active nodes only

Dynamic PCF (2/2) Dynamic CFP Interval and More data field Nodes set more data field when they have more than two packets to send. Solution to the various packetization interval problem The AP uses the biggest packetization interval as a CFP interval. Solution to the synchronization problem We send in CP only if there is more than one packet in queue.

Dynamic PCF - Model Speech model (ITU-T P.59) Parameter Duration (s) Rate (%) Talk-spurt 1.004 38.53 Pause 1.587 61.47 Double-Talk 0.228 6.59 Mutual Silence 0.508 22.48 Ethernet-to-Wireless Topology AP MN1 MN2 MN3 MN4 Router CN1 CN2 CN3 CN4

Dynamic PCF - Results Capacity for VoIP in IEEE 802.11b 32% 37 Transmission Rate (M b/s) 5 10 15 20 25 30 35 40 45 1 2 3 4 6 7 8 9 11 12 Number of VoIP Flows DCF PCF DPCF 13 23 28 24 14 37 Capacity for VoIP in IEEE 802.11b 32%