Cooperation in Wireless
Networks
Andrea G. Forte
Henning Schulzrinne
November 14, 2005
Why Cooperation ? (1/3)

Same tasks




Layer 2 Handoff
Layer 3 Handoff
Authentication
Multimedia Session Update
Why Cooperation ? (2/3)

Same Information




Topology (failover)
DNS
Geo-Location
Services (Other networks)
Why Cooperation ? (3/3)

Same goals





Low Latency
QoS
Load Balancing
Admission/Congestion Control
Service Discovery
Problems

Support for real-time multimedia

Fast L2 Handoff


Authentication


802.11i, WPA, 802.1x
Fast L3 Handoff



Scanning delay
Subnet change detection
IP address acquisition time
Fast Session Update

SIP re-INVITE
Cooperative Roaming

Multicast



Security
Reachability
TTL (scopes in IPv6)
Multicast Group
Layer 2 Handoff - Overview
Mobile station
All APs
Probe request (broadcast)
Probe response
Scanning delay
Authentication request
Authentication delay
Authentication response
Association request
Association delay
Association response
New AP
Layer 2 Handoff - Delays

Scanning



Introduces more than 90% of the total
handoff delay (open system).
It is the most power consuming part of the
handoff process.
Authentication


WEP (broken)
802.11i, WPA
Mobile Node’s Cache

L2 + L3 information
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
Layer 2 Cooperation (1/3)
R-MN
Stations
NET_INFO_REQ
NET_INFO_RESP


Random waiting time
The information exchanged in the NET_INFO
multicast frames is:
APs {BSSID, Channel}
SUBNET IDs
Layer 2 Cooperation (2/3)


A MN sends a NET_INFO_RESP frame if it has
at least one AP in common with the R-MN’s
cache.
If the MN does not have at least one AP in
common, it can:



Discard the INFO_REQ frame without any further
action
Send an INFO_RESP frame but only if no one else
has already sent the same information
Send an INFO_RESP frame but with a lower
priority than the one sent by a MN which follows
the “one AP in common” rule.
Layer 2 Cooperation (3/3)

When a MN either than R-MN receives a
NET_INFO_RESP it will perform two
tasks:


Check if someone is lying
(fix it!)
Populate a temporary cache structure
(cache “chunks” – Bit Torrent)
Layer 3 Handoff

Subnet detection


Information exchanged in NET_INFO
frames
IP address acquisition time

Other 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!)
Cooperative IP Acquisition (1/2)

R-MN has to discover the STAs that can
help in this task (A-STA)
R-MN
Stations
ASTA_DISCOV (m)
ASTA_RESP (u)

m: multicast
u: unicast
R-MN builds a list of A-STAs for each
possible next subnet
Cooperative IP Acquisition (2/2)

R-MN can cooperate with A-STAs to
acquire the L3 information it needs
R-MN
A-STA
IP_REQ
(Client ID)
DHCP_OFFER
(client ID)
DHCP
Server
.
.
DHCP_ACK
IP_RESP
(New IP)
R-MN builds a list of {Gateway, IP address} pairs, one
per each possible subnet it might move to next
Cooperative Authentication (1/4)


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 mid-call
mobility scenario to achieve a seamless
L2 and L3 handoff regardless of the
authentication model used.
Cooperative Authentication (2/4)


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.
Cooperative Authentication (3/4)


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.
The R-MN needs to:


Discover the available RNs for a given AP
(Similar procedure to the one used for
A-STAs)
Select an RN and start the relaying of
packets after the L2 handoff.
Cooperative Authentication (4/4)


In order to select an RN the R-MN
sends a RELAY_REQ multicast frame.
RELAY_REQ format:
AP_ID
(AD_ID)
R-MN
MAC address
CN
MAC and IP
RN
MAC and IP
RELAY_REQ frame is received by all the STAs
in the multicast group (or a subset), including
the CN and the RN
Security Issues (1/2)

A malicious MN might try to re-use the
relaying mechanism over and over
without ever authenticate.



Each RELAY_REQ allows an RN to relay
packets for a limited amount of time
RELAY_REQ frames are multicast. All STAs
can help in detecting a bad behavior
RNs can detect if the R-MN is performing
the normal authentication or not.
Authentication failure can also be detected
Security Issues (2/2)


Countermeasures work only if we can
be sure of the identity of a client
 MAC spoofing
A possible solution to MAC spoofing
attacks is to perform authentication and
encryption at the multicast group level
Other Applications





In a multi-domain environment Cooperative Roaming
(CR) can help in 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.
CR can help in discovering services (encryption,
authentication, bit-rate, Bluetooth, UWB, 3G)
CR can provide adaptation to changes in the network
topology (802.11h)
CR can help in the interaction between nodes in
infrastructure and ad-hoc/mesh networks.
Conclusions
Cooperation among stations allows seamless L2 and
L3 handoffs for real-time applications
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 high degree of mobility
Suitable for indoor and outdoor environments
Sharing information  Power efficient