This section page describes the key architectural components and the measurement workflow of the WiFiMon system:.
WiFiMon Architectural Components
Mobile User Device and Monitoring Probes
A mobile user device is any Mobile client: A mobile client is user's device connected to the WiFi network . WiFiMon can be used in any WiFi network, but is optimised 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 client will be authenticated at the home organisation (IdP) and authorised at the end-user's location (SP) on an IEEE 802.1X based WiFi network.
Data sources: The data sources (see Figure 1) include:
- Collected raw data generated by network performance tools (Boomerang, NetTest and HTML5 SpeedTest) with the use of JavaScript code embedded on chosen web pages; tests are run by hardware probes and performance data are retrieved when the hardware probes visit the web sources with the embedded code, and
- Exported raw data from data sources (collectors) like Syslog, Server Log, RADIUS Accounting, L2/L3 address binding. Wireless controllers and Access Point identifiers (AP-IDs) may provide the minimum amount of information in a smaller implementation, at the most basic level for performance verification and monitoring on a wireless network. Therefore, the data sources will vary, depending on the vendor specific tools integrated in the network
(laptop, phone, tablet,...). Crowdsourced measurements are gathered from the user devices when the user visits some chosen webpage which contains WiFiMon script tags that invoke JavaScript-based measurements. This is a WiFiMon Software Probe (WSP).
In addition, WiFiMon offers hardware probes (WiFiMon Hardware Probes, WHP) which are installed on small form factor hardware devices (e.g. Raspberry Pi's) and placed in fixed positions within the monitored WiFi network.
WiFiMon Admin
The WiFiMon admin is the network administrator managing the WiFi network and the WiFiMon system. Using the WiFiMon UI, they can perform queries to the Elastic ELK Cluster and get information about the performance of the wireless network.
Figure 1: WiFiMon Architectural Components
Elastic ELK Cluster
The WiFiMon Analysis Station (WAS) uses an ELK cluster for performance measurement data processing and visualisation. Elasticsearch is Elastic cluster: The raw data is automatically collected and fed into the WiFiMon agent, which uses Elasticsearch, a full-text, distributed NoSQL search engine . Elasticsearch uses documents rather than schema or tables (that SQL databases use), thus allowing leveraging and accessing data at very high speeds and making it appropriate for WiFiMon. In addition, the Elastic cluster uses tools such as logstash and filebeat to pipeline the raw data from the data sources simultaneously, transform these data and send it to Elasticsearch.
Data Analysis: Within the Elastic cluster, raw data is processed to data objects relevant to performance measurements. These raw data are then correlated with information from collected RADIUS logs to provide insight on the wireless network performance per client or AP. The correlated measurements are also stored in Elasticsearch.
...
which enables storing of raw measurement data, high-speed access and processing. Raw measurement data received from multiple measurement data sources are filtered and correlated in the Logstash and stored in the cluster. The WiFiMon Admin uses Kibana as a web user interface and for cluster management. Another component of ELK Stack is Filebeat, which is installed as an agent on the servers and is used to stream the log data. Filebeat monitors log files for new content, collects log events and forwards them to Logstash.
Data Sources
- Collected Raw Measurement Data
Measurement data are gathered from measurements made by mobile user devices (WiFiMon Software Probes - WSP's) and WiFiMon Hardware Probes (WHP's). Measurement data from the WSP are generated when the user visits a dedicated web page (e.g. captive portal, frequently visited university web page, etc.) which contains WiFiMon script tags pointing to JavaScript code. The JavaScript code initiates different measurement tests (Akamai Boomerang, NetTest and LibreSpeed Speedtest) between the mobile device and the test server (WTS). End devices calculate performance results and send data towards the WiFiMon Analysis Server (WAS). The data gathered from the WSP/WHP measurements include: upload and download throughput, HTTP ping round trip times, and information related to the Operating System (OS) and/or browser used by the WSP/WHP. In addition to these measurements, WHP's stream additional data to the WAS. These data include metrics pertaining to the wireless network interfaces of the WHP's as well as system statistics. Specifically, WiFiMon collects the signal level, the link quality, the bit rate and the transmission power of the wireless connections along with CPU, memory and storage statistics. - Additional (Exported) Raw Data
WiFiMon can be deployed within any WiFi network, but may provide additional benefits if used in an eduroam environment, where through very detailed performance assessments can be obtained through analysing the eduroam logs. If eduroam is used, the mobile user will be authenticated at the home organisation (IdP) and authorised 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) it is necessary to gather additional data from services including eduroam and DHCP which reveal the IP addresses particular users have, 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.
WiFiMon Agent / UI
WiFiMon Agent
Processes collected raw and exported measurement data to provide 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 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 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 their premises. Therefore all the data remains in the user's 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 user 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)
The WiFiMon test server includes configured templates from NetTest, Boomerang and SpeedTests (HTML5), which provide information about RTTs and ping (ICMP) network relevant data like WiFiMon uses active probing in order to obtain WiFi network performance metrics. Active probe packets are exchanged between the WSP and WHP on one side and the WiFiMon Test Server on the other. WTS uses NetTest, Akamai Boomerang and LibreSpeed Speedtest measurement software which can provide information about the packet round trip times and network performance data including bandwidth and latency (represented in Figure 2B 2 as lines marked as 2.1, 2.2, and 2.5). A standard image size is downloaded for NetTest, and for Boomerang it can be customisable to a maximum of 5 MByte size
One of the methodologies that WiFiMon tests use is to measure the upload and download time for a file that the WiFiMon administrator chooses. By choosing a larger file, more accurate measurements can be obtained, because of the ramp-up time of TCP congestion control/windowing mechanisms and slow start. However there is a trade-off because larger transfer sizes mean introducing a larger traffic overhead and this way a potential negative impact to the WiFi network. 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 such a page as the 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 the user's experience with the WiFi network 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.
Figure 2: WiFiMon Measurement Workflow
WiFiMon Software Probe (WSP)
The WiFiMon Software Probe takes the form of JavaScript integrated in often visited web pages, Figure 3. It includes the domain of the WiFiMon agent (WSP) is the JavaScript code integrated into some chosen often-visited web page(s) (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 servercaptive portal, university web page or similar). Whenever a user visits the page, the monitoring tests are invoked. It is possible that a user repetitively visits that same web page or frequently refreshes the browser on the page. Such behaviour could result in excessive probe traffic being injected into the network, overloading WiFiMon components and creating an additional unwanted traffic over the WiFi network. To alleviate this problem, WSPs include a cookie with a customisable blocking time parameter (e.g. 5 minutes). New measurements by the same WiFi network user (same browser) are only then possible after the blocking time in the cookie expires.
WiFiMon Hardware Probe (WHP)
The WiFiMon hardware probes Hardware Probes (WHP's) are set up on small form factor devices - , such as the Raspberry Pi. The HW 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. Moreover, probes collect system metrics and perform TWAMP measurements towards the WiFiMon Test Server. The WiFiMon team recommends to set setting up a WHP on a Raspberry Pi’s Pi v3 Model B+ or on a v4 Pi.
WiFiMon Analysis Server (WAS)
The WiFiMon Analysis Server includes (WAS) processes the performance results of crowdsourced and hardware probe measurements received from WSP's and WHP's respectively. The WAS consists of the WiFiMon agent, Elasticsearch, Logstash and the WiFiMon UI with that leverages on Kibana for customising reports and their visualisation.
Websites monitored by WiFiMon are not only visited by end users residing in the monitored subnets, but also from end users external to them. Therefore, it is important to prevent the WAS from processing excessive traffic and measurements which are not related to the WiFi network that is being monitored. To that end, WiFiMon maintains a list of registered subnets. Upon accepting a connection from an end user, the WiFiMon Test Server checks whether this end user is within a monitored subnet by obtaining the list of registered subnets from the WAS (2.3, 2.4). For WSP's/WHP's residing within the registered subnets, network The WiFiMon agent checks the subnet (2.3, 2.4) of a monitored device visiting the website that includes the JavaScript lines (see Fig. B) and downloads available images from the WiFiMon Test server (2.5). Network performance metrics are calculated and streamed from the end user devices to the WiFiMon Analysis Server (2.6) to be processed. FurthermoreAfterwards, the WAS correlates performance data with client IPs and AP-IDs (2.7/2.8).
Filebeat and RADIUS Server
By monitoring the log files defined in advance, Filebeat collects the logs that satisfy specific requirements and sends them to Elasticsearch or Logstash for further indexing. In WiFiMon, it is installed as an agent on the RADIUS server and forwards RADIUS logs. For details about Filebeat see footnote 7.
Logstash and Elasticsearch
In WiFiMon, Logstash is used to take data from the RADIUS server, transform it and send it to the predefined database for further processing. For details about Logstash see footnote 6Results are stored in the ELK stack.