MWI
Mobile and Wireless Internet Group
Virtual APs (vAPs) for eduroam
GN4 – JRA1-T2
Daniel Camps (i2CAT), Ilker Demirkol (UPC),
Raimundas Tuminauskas (KUT), Zbigniew Oltustyk (PSNC),
Silvia Surroca (UPC)
Prague, TNC’16, 15/06/2016
Copyright © i2CAT
Outline
1.
2.
3.
4.
Problem Statement
Proposed Solution
Performance Evaluation (with demo video)
Conclusions and next steps
Copyright © i2CAT
2
MWI
Mobile and Wireless Internet Group
1. Problem Statement (1/3)
•
•
eduroam is too successful …
Different entities offering eduroam services may operate in
close proximity
Eduroam providers around i2CAT’s office in Barcelona
Copyright © i2CAT
3
1. Problem Statement: Issue 1 - Mobility (2/3)
•
eduroam was not designed to have multiple providers
operating in the same area
•
802.11 was originally designed assuming that the SSID would
convey a service name … operated by a single provider
•
802.11 devices perform cell selection based on SSID and signal
strength  select the “eduroam” AP with the best signal
•
If the “eduroam” APs belong to different providers, IP address
changes  Some applications may be affected
Copyright © i2CAT
4
1. Problem Statement: Issue 2 - Policing (3/3)
•
eduroam providers compete against each other, and against
other Wi-Fi networks for ISM bandwidth
•
QoE is jeopardized as Wi-Fi usage increases
•
eduroam providers may want to have tools to police
bandwidth usage upon congestion
• e.g. police bandwidth according to eduroam realm
• Note: fairness is not at stake
Copyright © i2CAT
5
2. Proposed Solution
•
Instantiate “per-realm” vAPs in physical APs.
•
•
vAP (multi-SSID) has wide cross-vendor support
Not quite … vAPs introduce OTA overhead:
•
•
Instantiate vAPs representing providers in a geographical area
A default vAP for users of other realms
default_vap
vap_upc
vap_ub
vap_i2cat
ssid = eduroam
Copyright © i2CAT
6
2. Proposed Solution – Solving Mobility
•
Tunnel each vAP back to its home eduroam domain
•
Note: We are talking about providers in close proximity  added delay
is small
EoGRE
default_vap
vap_upc
vap_ub
EoGRE
vap_i2cat
ssid = eduroam
Copyright © i2CAT
7
2. Proposed Solution – Solving Mobility
•
Tunnel management does not scale with many overlapping
providers, 𝑂(𝑁 2 ),  Open Mobility Exchange (OMX)
Copyright © i2CAT
8
2. Proposed Solution – Solving policying
•
Police bandwidth at the wireless and vAP levels
•
vAPs broadcast a WMM Parameter Element containing Wi-Fi
access priorities for each realm
vAP1
ssid=eduroam
WMM_QoS = Set_1
Beacon vAP1: {QoS_1}
vAP2
ssid=eduroam
WMM_QoS = Set_2
Beacon vAP2: {QoS_2}
Copyright © i2CAT
9
2. Proposed Solution – Balancing STAs
•
Main problem: How can we force STAs to associate to the vAP
representing its eduroam realm?
•
•
•
STAs only see SSID=„eduroam“ and a BSSID
vAPs cannot be pre-provisioned with STA MACs
Strategy:
1.
2.
3.
4.
A STA associates to a vAP, and we initiate authentication
We discover the STA’s realm
• Realm contained in the EAP response message
We move the STA to the proper vAP representing the realm … but
how?
We proactively configure surrounding APs
Copyright © i2CAT
10
2. Proposed Solution – Balancing STAs
•
What we would have liked ...
vAP1
vAP2
BSS Transistion Management Req (vap2)
BSS Transistion Management Resp
Assoc & Auth
BSS Transistion Management defined in 802.11v
•
Problem is the amost no adoption of this feature on the client
side  We tried the hard way (Deauth)
Copyright © i2CAT
11
2. Proposed Solution – Balancing STAs
•
•
•
•
•
•
•
default_vap uses blacklist
Other vaps use whitelist
New STAs associate to default_vap
Realm is discovered
White/Black lists are configured
Deauth is sent
STA reassociates through proper
vAP
Copyright © i2CAT
12
3. Performance Evaluation
•
Testbed
Copyright © i2CAT
13
3. Performance Evaluation
•
Question 1: Assume white/black lists properly configured ...
•
•
•
do STAs connect to the proper vAP?
how long does it take them?
Observed behavior
Always vAP with lowest BSSID
Jiayu - G4
Jiayu - S3
BQ - Aquaris A4.5
Select a Random vAP
Apple - MC603Y/A (Iphone 4)
Jiayu - G3
One Plus – ONE A2003
Motorola - Moto G
BQ – Aquaris E5
LG – Nexus 5
Samsung - GT-S5570I (Galaxy Mini)
Samsung – SM-G7105 (Galaxy Grand 2)
Samsung – SM-T705 (Galaxy Tab S)
SM-G920F (Galaxy S6)
MG482QL/A (Iphone 6)
Copyright © i2CAT
14
3. Performance Evaluation
Observed access times
•
After receiving denied
authentication from a vAP
STAs behave differently
•
Diverse client behavior:
1.
Quickly try all vAPs in RR
fashion (iphone)
2.
Try with higher probability
first vAP (Jiajyu G3)
3.
Introduce timeout after
Auth. Failed (Galaxy Mini)
Copyright © i2CAT
15
3. Performance Evaluation
•
Question 2: What happens the first time, i.e. black/white lists
not setup?
•
•
how do STAs behave after receiving a Deauth?
Reconnect after timeout
Observed behavior
Do not try to reconnect (unless
user does it manually)
One Plus – ONE A2003
Samsung – SM-T705 (Galaxy Tab S)
MG482QL/A (Iphone 6)
Jiayu - G4
TIMEOUT (s)
Apple - MC603Y/A (Iphone 4)
Jiayu - G3
Motorola - Moto G
BQ – Aquaris E5
LG – Nexus 5
Samsung - GT-S5570I (Galaxy Mini)
Samsung – SM-G7105 (Galaxy
Grand 2)
SM-G920F (Galaxy S6)
Copyright © i2CAT
2
12
7
10
13
2
12
15
16
3. Performance Evaluation
Observed access times (TOTAL)
•
In the worst case the user
needs to tap twice
•
Diverse client behavior due to
different timeouts and random
selection of correct vAP
•
Note:
•
•
This is only needed the first
time
Some connection managers
often connect without user
intervention
Copyright © i2CAT
17
3. Performance Evaluation
•
Question 3: What is the impact of the EoGRE tunneling on the
eduroam connection setup?
•
100ms interdomain delay assumed
Tunneling to home domain
IP acquisition time (s)
IP acquisition time (s)
eduroam (IP through visited domain)
Time until EAP success (s)
Average
Time until EAP success (s)
Average
Copyright © i2CAT
18
3. Performance Evaluation
•
Question 4: What about handover?
Short video here
Copyright © i2CAT
19
4. Conclusions and next steps
•
Introducing vAPs is feasible ... but the main problem is steering
STAs to the proper vAP
•
•
•
•
Client ecosystem is very complex ... but we should monitor adoption of
features like BSS Transition Mngmt
Advanced implementations could check the MAC OUI to infer
capabilities of the devices ... but maintenance is complex
Proactive white/black list population is essential ... requires
interdomain interfaces
Roaming models based on Hotspot 2.0 should also be studied
•
•
Different vAPs could have different roaming agreement. Assume a
custom SSID per realm, e.g. „eduroam-REALM“
STA connection manager would be configured to connect to „eduroamREALM“ or default „eduroam“
Copyright © i2CAT
20
MWI
Mobile and Wireless Internet Group
Mobile Wireless Internet Group
Copyright © i2CAT