1. 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)

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

3. 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

4. Copyright © i2CAT 4 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

5. 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

6. 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

7. 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

8. Copyright © i2CAT 8 2. Proposed Solution – Solving Mobility

9. 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}

10. Copyright © i2CAT 10 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.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

11. Copyright © i2CAT 11 2. 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 802.11v

12. Copyright © i2CAT 12 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

13. Copyright © i2CAT 13 3. Performance Evaluation Testbed

14. Copyright © i2CAT 14 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)

15. Copyright © i2CAT 15 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)

16. Copyright © i2CAT 16 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? 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

17. Copyright © i2CAT 17 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

18. Copyright © i2CAT 18 3. 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

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

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

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