Diese Story ist aus der Kategorie Innovation 

WiFi-Performance-Optimierung dank End User Feedback

Wie kann man gegen WiFi-Performance-Probleme vorgehen? Wir zeigen einen Ansatz aus einem Forschungsprojekt.

Text: Kurt Baumann, publiziert am 02.03.2016

Viele Informatikdienste kennen diese Situation: Hochschulangehörige beklagen sich über die schwache Performance des WLAN: Die gewünschte Website benötige eine halbe Ewigkeit, bis sie geladen sei. Was aber genau ist dafür verantwortlich? Sind es falsch konfigurierte End-User-Geräte? Gibt es Kapazitätsengpässe aufgrund plötzlich auftretender geringerer Bandbreite? Oder sind es andere Gründe?

Es ist gar nicht so einfach, die Probleme zu finden und unmittelbare Lösungen dafür anzubieten. Denn für die Auswertung und Erfassung von WiFi-Performance-Problemen auf dem Campus stehen heute kaum Daten und Historys über längere Zeit zur Verfügung. Eine nachträgliche Problemrekonstruktion ist somit nur schwer möglich.

Aus diesem Grund hat GEANT unter Führung von SWITCH ein Wireless-Crowd- Source-Performance-Monitoring- und Verifikations-Konzept (WCSPMV) entwickelt, mit dem via End-User-Feedback die Performance und die Ursachen für Performanceprobleme erfasst werden können. Im Fokus stehen dabei noninvasive Bandbreitentests auf End-User-Geräten. Erste Erfahrungen haben wir an der TERENA Network Conference 2015 gesammelt, wo wir das Konzept live vorgestellt haben. Weitere Implementationen und Konzeptverbesserungen sind derzeit an verschiedenen Universitäten im Gang.

Die Komponenten für das Konzept:

Wichtige Indikatoren für ein WCSPMV sind die End User, also die Mobile Clients als Traffic Erzeuger sowie die definierten Datenkollektoren, welche Daten von WiFi-Kontrollern, DHCP-/Radius-Logfiles und die Access Point IDs sammeln. Die Erhebung von Netzwerkperformancedaten (Bandbreite, Latenz) erfolgt mittels JavaScripts, die auf den gewünschten Webseiten installiert werden und die Messdaten an die Analyse Engine (AE) zur Auswertung weiterleiten. Das untenstehende Architekturschema (siehe Bild) zeigt, welches die wichtigsten Komponenten und Mechanismen sind, die es braucht, um die netzwerkbezogenen Aussagen zu machen.

So funktioniert es

Ein Mobile Client (siehe Bild) verbindet sich mit dem naheliegenden Access Point (AP). Er authentifiziert und autorisiert sich und erhält vom DHCP-Server eine IP-Adresse. Dabei werden DHCP-, System- und/oder Radius-Logfiles erzeugt (siehe Data Sources), was einen Abgleich der Client-MAC-Adressen mit den Client-IP-Adressen, des Access Point-Identifiers (AP-ID) und des Zeitstempels der erfolgreichen Verbindungsaufnahme mit dem WLAN-Campusnetzwerk erlaubt. Nun werden diese Daten in eine Relationale Datenbank (RDB) gefüllt und mittels einer Analyse Engine (AE) analysiert resp. für die Visualisierung aufbereitet.

Im Browser des End Users werden JavaScripts ausgeführt, welche eine Reihe von Netzwerkperformancedaten liefern. Dabei handelt es sich um die relative Bandbreite (Upload-, Download Speed von definierten Images) und die Latenz (mittles Round Trip Time, RTT).

Nun haben wir alle Informationen, die wir benötigen, um die Korrelation zwischen der Data Source (den Logfiles), dem Zeitpunkt (Zeitstempel) und dem AP-Identifier (AP-ID) herzustellen und mit den angefallenen Netzwerk-Performancedaten durch die Java-Scripts zu verknüpfen.

Diese Daten können nun nach Bedarf via grafisches Userinterface (GUI) aus der RDB und der Analytic Engine (AE) abgefragt werden, und es können damit entsprechende Reports zuhanden des WLAN-Betreibers erstellt werden. Hier gilt es, den Datenschutz im Auge zu behalten (siehe Box). Es handelt sich immerhin um Personendaten, die auch Auskunft über das Verhalten der End Users geben.

Erste Tests und Resultate

Das oben beschriebene Konzept haben wir im Rahmen der TERENA Network Konferenz (TNC2015) in Porto, Portugal, zum ersten Mal vorgestellt und gleich live getestet. Unsere Wahl fiel bewusst auf eine grössere Konferenz, da die Messgenauigkeit von der Anzahl der WLAN-Benutzer abhängt (Crowd Sourcing).

Wir implementierten die JavaScripts auf der TNC2015-Haupt- und Subwebseiten. Der NetTest Server lief auf einer virtuellen Instanz in Athen (GR). Wir liessen nur Messungen von ausgewählten IP-Subnetzen zu, Performancemessungen ausserhalb dieser Subnetze wurden blockiert. Des Weiteren haben wir die Duplizierung von Messungen verhindert, indem wir die Lebensdauer von Cookies auf eine Stunde beschränkt haben.

Während der TNC2015 konnten wir die ersten groben Analysen der gesammelten Daten bezüglich Bandbreite sowie der Netzwerk-Latenz durchführen. Zudem konnten wir das "Crowding" aufzeichnen, also die Ansammlung von Konferenzteilnehmern. Während der TNC2015 haben wir über 1713 Performancemessungen durchgeführt, daraus die vollständigen Datensätze ausgelesen und deren Korrelationen erzeugt.

 

Die Grafik zeigt die Down-(/Upload)-Geschwindigkeit im grössten Konferenzsaal, wo die Plenary Sessions und Präsentationen stattfanden. Dieser Saal verfügte über mehrere APs. Das Resultat der Messungen ist auf den ersten Blick ernüchternd, da kein eindeutiges Muster erkennbar ist. Wir hatten erwartet, dass sichtbar wird, an welchem AP sich die meisten Geräte angemeldet hatten. Wir massen eine durchschnittliche Downloadgeschwindigkeit von 662.9KB/s, beim Upload betrug sie im Durchschnitt 406.5KB/s. Das deutet auf eine hohe Fluktuation hin. Wie erwartet stellten wir fest, dass die Distanz zum AP für die Qualität der Daten eine wichtige Rolle spielt. Zudem stellte sich heraus, dass die Imagegrösse von 1 Megabyte zu klein war. In der Folge werden wir die Imagegrösse künftig auf 2-3 Megabyte erhöhen.


Das Bild bei der Latenz hat etwas mehr Aussagekraft. Bezüglich unserer Versuchsanleitung können wir drei Charakteristiken erkennen:

  1. Latenz: Sie betrug um die 40 Millisekunden zwischen der Konferenzlocation in Porto und dem NetTest-Server in Athen.
  2. Clustering: Es bewegte sich in einem Range von 20 bis 30ms, was auf ein gut konzipiertes Netzwerk schliessen lässt.
  3. Ausreisser: Die Gründe dafür sind vielseitig. Falsch konfigurierte End User-Geräte, Wireless Network Konfiguration, das "Crowding" selbst oder die Distanz zum AP etc.

Fazit

Bereits unser erster Testlauf hat unsere Annahme bestätigt: Es ist möglich, Informationen zur WiFi-Performance mit Hilfe von noninvasiven Bandbreitentests auf End-User-Geräten zu sammeln. Die Tests lieferten relativ gute Informationen:

  • Wir konnten die Performancemessungen auf definierte IP-Subnetze beschränken.
  • Wir konnten die Duplizierung von Messungen mithilfe von Cookies vermeiden.
  • Wir konnten den User Agent der Browser aufzeichnen, sodass es uns möglich war, unsere Resultate den verwendeten Browsern, Plattformen und Mobile- bzw. der Desktop-Hardware zuzuordnen. Damit konnten wir aus dem Browser auch die "Geolokation" abfragen.
  • Wir konnten Performancemessungen von Hardware-Proben (Objective Measurements) mit den Resultaten der Performancemessungen auf den End- User-Geräten vergleichen.

Weitere Test-Implementierungen sind in Planung oder laufen bereits an verschiedenen Orten, zum Beispiel an der Dublin City Universität (DCU) und bei einem kleineren Internet Service Provider.

Verbesserungen und Innovationen des Konzeptes sind bezüglich der Messdatenverifizierung, der Automatisierung der Datensammlung und deren Aufbereitung, dem Bau eines geeigneten RDB/AE-Konzeptes mit entsprechender Software und dem GUI als Frontend für die Netzwerkadministratoren in Arbeit.

Die hier vorgestellte Arbeit wurde im Rahmen des GEANT Projektes, GN4-1 in Task GN4-1-SA3T3 unter dem Grant Agreement No. 691567 geleistet.
Über den Autor
Kurt   Baumann

Kurt Baumann

Im Jahr 2001 erhielt Kurt Baumann den Master in Mathematik von der Universität Zürich. Nach seiner Tätigkeit bei IBM stiess er im Jahr 2005 zu SWITCH. Er ist Mitglied des Network-Teams und vertritt die Interessen von SWITCH bei GÉANT.

E-Mail

Fragen betreffend den Schutz von Personendaten

Mittels der Geolokationsinformation können wir mit unserem Wireless-Crowdsourced-Performance-Monitoring-Ansatz das Verhalten der Mobile Clients sehr genau aufzeichnen. Ein Profiling des End Users ist möglich. Im Rahmen von eduPERT haben wir eine erste Diskussion über den Schutz der End-User-Daten geführt.

Testkandidaten gesucht

Ein erster Implementationguide ist verfügbar. Wir suchen Testteilnehmer für die Optimierung des Konzeptes und würden uns freuen über Testpartner aus der SWITCHCommunity.

Interessierte schreiben an Kurt Baumann.

Weitere Beiträge