MWI Mobile and Wireless Internet Group Copyright © i2CAT Virtual APs (vAPs) for eduroam GN4 – JRA1-T2 Prague, TNC’16, 15/06/2016 Daniel Camps (i2CAT), Ilker Demirkol (UPC), Raimundas Tuminauskas (KUT), Zbigniew Oltustyk (PSNC), Silvia Surroca (UPC)

Copyright © i2CAT 2 1.Problem Statement 2.Proposed Solution 3.Performance Evaluation (with demo video) 4.Conclusions and next steps Outline

MWI Mobile and Wireless Internet Group Copyright © i2CAT 3 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 4 1. Problem Statement: Issue 1 - Mobility (2/3) eduroam was not designed to have multiple providers operating in the same area was originally designed assuming that the SSID would convey a service name … operated by a single provider 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 5 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 6 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_upcvap_ub vap_i2cat ssid = eduroam

Copyright © i2CAT 7 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 default_vap vap_upcvap_ub vap_i2cat ssid = eduroam EoGRE

Copyright © i2CAT 8 2. Proposed Solution – Solving Mobility

Copyright © i2CAT 9 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 vAP2 ssid=eduroam WMM_QoS = Set_2 Beacon vAP1: {QoS_1} Beacon vAP2: {QoS_2}

Copyright © i2CAT 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.A STA associates to a vAP, and we initiate authentication 2.We discover the STA’s realm Realm contained in the EAP response message 3.We move the STA to the proper vAP representing the realm … but how? 4.We proactively configure surrounding APs

Copyright © i2CAT Proposed Solution – Balancing STAs What we would have liked... Problem is the amost no adoption of this feature on the client side  We tried the hard way (Deauth) vAP1 vAP2 BSS Transistion Management Req (vap2) BSS Transistion Management Resp Assoc & Auth BSS Transistion Management defined in v

Copyright © i2CAT 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 Performance Evaluation Testbed

Copyright © i2CAT 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 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 Performance Evaluation Question 2: What happens the first time, i.e. black/white lists not setup? how do STAs behave after receiving a Deauth? 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 Reconnect after timeout TIMEOUT (s) Apple - MC603Y/A (Iphone 4)2 Jiayu - G312 Motorola - Moto G7 BQ – Aquaris E510 LG – Nexus 513 Samsung - GT-S5570I (Galaxy Mini)2 Samsung – SM-G7105 (Galaxy Grand 2) 12 SM-G920F (Galaxy S6)15

Copyright © i2CAT 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 Performance Evaluation Question 3: What is the impact of the EoGRE tunneling on the eduroam connection setup? 100ms interdomain delay assumed Time until EAP success (s) IP acquisition time (s) eduroam (IP through visited domain)Tunneling to home domain Average

Copyright © i2CAT Performance Evaluation Question 4: What about handover? Short video here

Copyright © i2CAT 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 „eduroam- REALM“ or default „eduroam“

MWI Mobile and Wireless Internet Group Copyright © i2CAT Mobile Wireless Internet Group