Large-Scale Dataset for Radio Frequency-Based Device-Free Crowd Estimation

: Organisers of events attracting many people have the important task to ensure the safety of the crowd on their venue premises. Measuring the size of the crowd is a critical ﬁrst step, but often challenging because of occlusions, noise and the dynamics of the crowd. We have been working on a passive Radio Frequency (RF) sensing technique for crowd size estimation, and we now present three datasets of measurements collected at the Tomorrowland music festival in environments containing thousands of people. All datasets have reference data, either based on payment transactions or an access control system, and we provide an example analysis script. We hope that future analyses can lead to an added value for crowd safety experts.


Summary
Organisers of mass gatherings are tasked with the difficult job of ensuring the safety of crowds on their venue premises. To achieve that goal, control rooms often rely on safety experts during such events. Crowd safety experts are not only involved in risk analysis prior to an event, but are also responsible for crucial decision-making during an ongoing event, while unexpected crowd risks can occur. Real-time monitoring of crowds introduces the challenging task of evaluating the crowd size and its evolution.
We investigate a relatively young approach to crowd counting: crowd estimations using Radio Frequency (RF) signal features. It is a method that belongs to the broader field of device-free localisation [1]. In general terms, the use of RF signal features is based on the physical effects of a crowd on RF signals. The most common feature collected is the signal attenuation in the form of the Received Signal Strength Indicator (RSSI). RSSI across the communication links in the environment are evaluated to form an understanding of the number of people in the environment.
Note that no personal data is collected from the people in the environment, and that they do not have to carry a specific device or specific software on their personal equipment. This is unlike typical localisation approaches [2,3] or communication statistic collection [4].
Here, we introduce three datasets that contain a time-series of the RSSI between every node in sub-GHz sensor networks deployed at specific environments fitting thousands of people at the Tomorrowland festival in 2017 and 2018. The datasets are accompanied with complementary reference files and software to reproduce the example provided in Section 4. The measurements are collected at Table 1 lists the eighteen dataset files that we provide. They are collected at the Tomorrowland music festival in 2017 and 2018. There are three environments: "Freedom Stage 2017", "Freedom Stage 2018" and "Main Comfort 2018". Each environment has both 433 MHz and 868 MHz data. They all have data over three festival days. The dataset files are formatted as Comma-Separated Values (CSV).
We provide the datasets and complementary files at Zenodo [12]. This includes the following.

1.
Dataset files: Each line corresponds to a single network node's message, see Figure 1, and has six fields: ts String timestamp created upon receiving the message in serial form at the computing unit, so post radio reception and prior to further processing.
node Number of the node ID of the transmitting node. IDs. This is shown in Figure 1. The input at the transmitting node's index is always zero. Other zero entries are nodes from which the transmitting node has not received a message in the past cycle.

2.
Position files: Each line is a node in the network. If an ID is skipped, it was not deployed during the measurement campaign. If a node turned out to be faulty after deployment, it is still in the positions file. The devices are placed at approximately 1 m height.
node Number of the node ID.
x Number for horizontal coordinate. y Number for vertical coordinate.

3.
Reference files: Transactions per minute for the Freedom Stage environment and people count in the exclusive zone as estimated by the access control system for the Main Comfort environment. Each line has two fields: time String timestamp. count Number that is the reference data value (transactions or people count).

4.
Line-up files: These files contain the start and stop times of performances, according to the planning. Slight deviations of true start and stop times are possible, but only in the order of minutes. Table 1. To help investigate crowd sensing, we shared these eighteen dataset files. Where possible, we added a reference file with either transactions per minute at the bars in the environment, or people count in the exclusive zone as estimated by the access control system. We also provide position files for the nodes in each environment and line-up files for each day at each environment; we did not list them here. . Each line in the dataset files corresponds to a message received by the Controller, such as the one sent by Node 33 in the example above. There are N nodes and a controller in the network. A zero entry in the rssi_values vector means that the listening node (Node 33 in the example) did not receive a message from the node ID with the corresponding vector index in the past cycle. Table 2 lists the amount of data for each environment at each measurement day. Note that on Fridays, as already indicated in Table 1, no reference data is provided by the event's organisers.

Methods
We will first describe how we collected the RSSI values in the dataset files, then how we positioned the nodes, and finally, what reference data we acquired. This order is the same as the listing of the file types above, except that we do not discuss the line-up of the artists.
We collect the RSSI values on custom hardware and an application specific network set-up using the DASH7 Alliance Protocol (D7AP) [13,14]. From a DASH7 perspective, all our network devices are gateways because they are always listening when not transmitting. Here, we focus on the hardware and the network set-up.

Hardware & Network Setup
From the application perspective we make the distinction between three types of devices: the "nodes", the controller and the configurator. First, what we call the 'nodes', which are the generic transceivers in the set-up, see Figure 2. They broadcast messages in a cyclic fashion, receiving while other nodes are transmitting; Second, the controller, which is a transceiver that coordinates the cycles when the nodes can send messages and at the same time receives and stores the node's messages for further processing. Finally, the configurator, which is a transceiver that sends configuration data to a node upon request. All nodes, controllers and configurators include a dedicated printed circuit board (PCB) for the 433 MHz and 868 MHz networks. Most nodes have both networks; only in the Main Comfort environment we use a few nodes with only the 868 MHz network. Each PCB is equipped with an ARM Cortex-M3 microcontroller from the EZR32LG family and a Si4460 sub-GHz transceiver. The complete unit is powered by a 6600 mA h LiPo battery and protected from the elements by an encapsulation. Figure 2a shows the first encapsulation and PCB iteration of the nodes. The antennas are fitted on the outside and the encapsulation itself is not water resistant. We use this first type in the Freedom Stage environment, because it is a sheltered environment. Figure 2b shows the second iteration of the nodes. The antennas are fitted on the inside and the encapsulation is waterproof. We use this second type in the Main Comfort environment, because part of that environment is open air.
The controller periodically broadcasts a message to indicate that a cycle starts. Upon receiving this message, the nodes schedule their transmission one after the other. In turn, every node broadcasts a message to the controller and the other nodes. While the payload is only meant for the controller, other nodes use this message to measure and store the RSSI. Each node stores the RSSI values in a vector at the index of the transmitting node's ID. This RSSI vector is the payload that the node sends to the controller. Figure 1 illustrates the formation of a single node's RSSI vector. Note that the vector appears to hold positive integers, but in reality, they are negative values expressed in dBm.
Iterating through cycles in an orderly manner is enabled by a preconfigured wait time T w . According to T w , nodes schedule their transmission within the current cycle and the controller schedules the next cycle. In our set-up, T w = 50 ticks, with one tick equal to 2 −10 s or approximately 0.977 ms. Figure 3 visualises the communication cycles. As soon as the controller signals the start of a new cycle at t 0 , a network node with ID n schedules its transmission at t 0 + (n + 1)T w . The network nodes do not schedule a second transmission, but rather await the next start signal at t 0 + (N + 1)T w by the controller.
The configurator is responsible for setting the network specific parameters and the nodes' IDs, based on their hardware ID. The parameters are network size N and wait time T w . As explained above, T w is used in combination with the node ID to define how long a node has to wait before it can send its measurements. Table 3 Figure 4 displays the node positions of the three environments. The nodes are indicated by their node ID. Some node IDs, such as 29 and 32 in Figure 4b, are skipped because they were not deployed. The placement of the devices is such that the direct line of sight paths between nodes cover as much of the environment as possible. Although the heights at which the nodes were placed are not provided in the datasets, we aimed to place the nodes at approximately 1 m from the ground.

Reference Data
For the Freedom Stage environments of both 2017 and 2018 we do not have crowd count references. As an alternative, which has an indirect correlation with the crowd count, we have the real-time data on cashless payment transactions per minute at the two bars of the environment.
In order to be admitted to the Main Comfort area, attendees are required to scan their bracelets. Bracelets are also scanned upon exit, which makes it so that crowd counts can be tracked over time. This is the available crowd count reference data for this environment.
However, there are two caveats: Attendees who pass through the Main Comfort to reach the more exclusive upper floors (B2B and Skyboxes) are also contributing to the scan-based crowd counts, without affecting our measurement set-up. We did not have nodes deployed in the B2B and Skyboxes in 2018, so we cannot account for the ratio of crowd size between the ground floor (Main Comfort) and the upper two floors. Another side note is that only attendees are scanned, meaning that the staff on the premises affect our measurements, but are not accounted for in the scan system.

Reference Data
For the Freedom Stage environments of both 2017 and 2018 we do not have crowd count references. As an alternative, which has an indirect correlation with the crowd count, we have the real-time data on cashless payment transactions per minute at the two bars of the environment.
In order to be admitted to the Main Comfort area, attendees are required to scan their bracelets. Bracelets are also scanned upon exit, which makes it so that crowd counts can be tracked over time. This is the available crowd count reference data for this environment.
There are however two caveats. Attendees who pass through the Main Comfort to reach the more exclusive upper floors (B2B and Skyboxes) are also contributing to the scan-based crowd counts, without affecting our measurement setup. We did not have nodes deployed in the B2B and Skyboxes

Usage Notes
Along with the data files, we provide a script that loads a dataset, executes an example calibration and creates RSS attenuation graphs, overlaid with the corresponding reference data. Figures 5 and 6 shows the resulting graphs. This RSS attenuation is the foundation for the crowd density estimation in [11].
The purpose of recording a calibration is to have a stable state of the communication links to which we can compare future RSS across links. The magnitude of RSS attenuation across the collection of communication links is then indicative of the surplus of people affecting these links. The surplus of people is ideally estimated with respect to a stable empty environment. There are two things we need for a good calibration: having a reference of the number of people in the environment and a sufficiently long time frame in which the count changes as little as possible.
We know that in the first hour of the measurements, there are a minimal amount of people in the environments. The reason for this is that during this time the artists' sets have not yet started. The mean RSS across links are at their highest, because there are not many people to attenuate the signals. We narrow this one hour down to a calibration duration of ten minutes, while trying to select the range in which both the average RSS and standard deviation are as low as possible. Resulting calibration ranges are indicated by a green vertical band, with a width of ten minutes.  We can now use the RSSI vectors within the calibration interval to create a calibration vector of length N (number of nodes) for each node. For any given node, the vector contains the average RSS values for each link between itself and the other N − 1 nodes, with a 0 entry for its own node ID index within that vector. These calibration vectors are now representative of an empty environment. The calibration vectors are then subtracted from subsequent time-averaged RSSI vectors. Moreover, if we time-average those subsequent RSSI vectors, we get the mean RSS attenuations, which are plotted in Figure 5 for the 433 MHz networks and Figure 6  The data interpretation and calibration described in this section is implemented in the shared script and serves as an example to use the provided data. By changing the unique year, environment, band and day parameters, the eighteen datasets can be used to generate graphs like the ones in Figures 5 and 6.
Interestingly, the cashless transactions per minute in Figures 5a-d and 6a-d follow the same global trend as the mean RSS attenuations (or relative crowd size), but the ratio of transactions per minute to mean RSS attenuations is consistently higher during an increasing crowd size, while being lower during decreasing RSS attenuations. Although a direct translation between crowd size and cashless payment rates is of little use, the reference data can still be used as a parameter in forecasting crowd sizes.
In Figures 5e,f and 6e,f, we see two significant discrepancies between our mean RSS attenuations and the reported access control counts. Both on Saturday and Sunday, starting at 5 p.m., we see that the reported reference crowd counts are lower than our mean RSS attenuations. This first inconsistency is likely due to the serving of appetisers at the Main Comfort, resulting in attendees from the upper floors to visit the ground floor. The last most notable difference is at the end of the festival on Sunday. As attendees left the environment, access control gates were no longer used, resulting in a significantly higher crowd count reported than what is more truthfully indicated by our mean RSS attenuations. Our impressions and findings were communicated to and confirmed by the event organisers.