You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »

This page describes the key components and the measurement workflow of the WiFiMon system.

WiFiMon Architectural Components

Mobile User Device and Monitoring probes

A mobile user device is any user's device connected to the WiFi network (laptop, phone, tablet,...). Crowdsourced measurements are gathered from the user devices when the user visits some chosen webpage which contains WiFiMon JavaScript code that invokes measurements. This is a WiFiMon Software Probe (WSP). In addition WiFiMon offers hardware probes (WHP) which are installed on a small for factor hardware (e.g. RaspberryPi) and placed in fixed positions.

WiFiMon Admin

WiFiMon admin is the network administrator managing the WiFi network and the WiFiMon system. Using the WiFiMon UI, he/she can perform queries to the Elastic ELK Cluster and get the performance of the wireless network.

Elastic ELK Cluster

WiFiMon Analysis Station (WAS) uses ELK cluster for performance measurement data processing and visualization. Elasticsearch is a full-text, distributed NoSQL search engine which enables storing raw measurement data, its  high speed access and processing. Raw measurement data received from multiple measurement data sources is filtered and correlated in the Logstash and stored in the cluster. WiFiMon Admin uses Kibana as a web user interface and for cluster management. Another component of Elastic Stack is the Filebeat, which is installed as an agent on the severs that are used to stream the Additional (Exported) Raw Data. Filebeat monitors log files for new content, collects log events, and forwards them to Logstash.

Data Sources

  • Collected Raw Measurement Data
    Measurement data is gathered from the measurements made by the mobile user devices (WiFiMon Software Probe - WSP) and WiFiMon Hardware Probes (WHP). Measurement data from the WSP is generated when the user visits a dedicated web page (e.g. captive portal, often visited university web page, etc.) which contains a prepared WiFiMon Javascript code. Javascript code initiates different measurement tests  (Boomerang, NetTest and HTML5 SpeedTest) between the mobile device and the test server (WTS). WTS sends the data towards the WiFiMon Analysis Server (WAS).  The data gathered from the WSP measurements includes: upload and download throughput, round trip times and... In addition to these measurements WHP sends additional measurements to the WAS: signal strength, signal quality, etc.
  • Additional (Exported) Raw Data

    WiFiMon can be deployed in any WiFi network, but is optimized to be used in the Eduroam environment, as through the analysis of the Eduroam logs very detailed performance assessments can be obtained.  If the Eduroam is used, the mobile user will be authenticated at the home organisation (IdP) and authorized at the end-user's location (SP) on an IEEE 802.1X based WiFi network.

    In order to make a thorough analysis of the WiFi network performance (e.g. per access point, per user, per operating system, etc.) it is necessary to gather the additional data from the services like Eduroam and DHCP which reveal the IP addresses particular users get, the access point they are associated to, etc. These logs are fetched from Filebeat agents and are then sent to Logstash pipelines for filtering and editing, before being stored in the WAS.
Figure 1: WiFiMon Architectural Components

WiFiMon Agent / UI

  • WiFiMon Agent
    Processes collected raw and exported measurement data to provide the insight on the wireless network performance per client or AP. The results of correlations are stored in the ELK Cluster.
  • WiFiMon UI
    Provides temporal graphs of all the performance metrics, allows queries to retrieve the information about the measurements initiated from the WSP or WHP associated to a specific access point and within a specific time period. Other queries could be to retrieve the information about the specific IP ranges, test tools, user browsers  etc.

Data Security

The main WiFiMon service delivery model assumes that the WiFiMon user installs all the WiFiMon components in his/her premises. Therefore all the data remains in the users possession all the time and the WiFiMon team does not have any access to it. All the traffic in transit between the WiFiMon components is TLS encrypted. Furthermore, sensitive and potentially personally identifiable information data such as mobile users IP or MAC address are hashed before being stored in the WAS. The correlation procedure mentioned in the WiFiMon Agent section is performed over the hashed data.




WiFiMon Building Blocks and Measurement Workflow

WiFiMon Test Server (WTS)

WiFiMon uses active probing in order to get the WiFi network performance metrics. Active probe packets are exchanged between the WSP and WHP on one side and WiFiMon Test Server on the other. WTS uses NetTest, Boomerang and SpeedTest measurement software which can provide the information about the packet round trip times and network performance data like bandwidth and latency (represented in Figure 2 as lines marked as 2.1, 2.2, and 2.5). One of the methodologies that WiFiMon tests use is to measure the upload and download time for a file that WiFiMon administrator chooses. By choosing a larger file, more accurate measurements can be obtained because of the TCP congestion control/windowing mechanisms and slow start. However there is a trade-of because larger transfer sizes mean introducing a larger traffic overhead and this way the negative impact to the WiFi network itself. Therefore it is recommended that the file size is comparable to the size of a typical web page (up to 5MB). This way one measurement would push to the network and user's device probe traffic comparable to one web site visit and the obtained measurements would show the throughput and the time to load the page as user sees it. The obtained throughput metrics should not be considered as the maximum achievable throughput of the WiFi network at the moment of measurement, but the WiFi network administrator should rather look at the relative differences between the measurements in order to get the insight into the quality of user's experience with the WiFi network he/she uses. The location of the WTS and its topological distance from the monitored WiFi network has a major impact on the crowdsourced measurement accuracy and reliability. You can read more about this here.

WiFiMon Software Probe (WSP)

The WiFiMon Software Probe is the JavaScript code integrated in some chosen often visited web page (e.g. captive portal, university web page or similar). It includes the domain of the WiFiMon agent (e.g., wifimon.switch.ch), the listening agent port (8443) and the image location/path (e.g. https://eipa19.eipa.ttu.ee/wifimon/images/) as well as the cookie expiration time. The default value of this cookie is 1.5 min (currently) if it is not explicitly set in the WiFiMon test server.



Figure 2: WiFiMon Measurement Workflow

WiFiMon Hardware Probe (WHP)

The WiFiMon hardware probes are set up on small form factor devices - such as the Raspberry Pi. The WHP probe may be viewed as an end user logged in to the eduroam wireless network, but monitoring continuously from a fixed point. It measures bandwidth, latency, the average values of bit rate, the signal level, the link quality and the transmission power. The WiFiMon team recommends to set up a WHP on Raspberry Pi’s v3 Model B+ or v4

WiFiMon Analysis Server (WAS)

The Analysis Server includes the WiFiMon agent, Elasticsearch, Logstash and the WiFiMon UI/Kibana for customizing reports and their visualization. The WiFiMon agent checks the subnet (2.3, 2.4) of a monitored device visiting the website that includes the JavaScript lines and downloads available images from the WiFiMon Test server (2.5). Network performance metrics are calculated and streamed from the end user to the WiFiMon Analysis Server (2.6). Furthermore, the WAS correlates performance data with client IPs and AP-IDs (2.7/2.8).


  • No labels