Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
14
datasets available to search
ShareScore release 0.9.0
Dataset results
14 results for “802.11”
Supplementary Materials for "Exploration of User Privacy in 802.11 Probe Requests with MAC Address Randomization Using Temporal Pattern Analysis"
<p>Supplementary Materials for "Exploration of User Privacy in 802.11 Probe Requests with MAC Address Randomization Using Temporal Pattern Analysis"</p> <p>This package contains an anonymized packets of 802.11 probe requests captured in in December 2021 at Universitat Jaume I . The packet capture file is in the standardized *.pcap binary format and can be opened with any packet analysis tool such as Wireshark or scapy (Python packet analysis and manipulation package).</p>
[ITU AI/ML Challenge 2021] Dataset IEEE 802.11ax Spatial Reuse
<p>This dataset has been created for the problem statement ITU-ML5G-PS-004 of the ITU AI/ML Challenge (2021 edition). More information can be found here: <a href="https://challenge.aiforgood.itu.int/">https://challenge.aiforgood.itu.int/</a> and <a href="https://www.upf.edu/web/wnrg/2021-edition">https://www.upf.edu/web/wnrg/2021-edition</a>. </p> <p>The dataset contains the information of 3.000 IEEE 802.11ax deployments (divided into two different scenarios) at which the Basic Service Set (BSS) of interest applies different possible OBSS/PD thresholds in the context of the Spatial Reuse (SR) operation. In total, 21 OBSS/PD values are considered for each deployment, and some of the deployments include data from different STA locations. The provided files are expected to be used for training Machine Learning (ML) and Federated Learning (FL) algorithms.</p> <p>More specifically, the dataset is divided as follows:</p> <ul> <li><strong>Scenario 1:</strong> 1,000 different deployments with 2-6 APs and 1 STA per AP. A minimum distance limitation is applied, so that each AP different from AP_A is located at a minimum distance of 10 meters from that one. Each deployment is simulated for each of the 21 possible OBSS/PD thresholds in 11ax. Two files are considered: <ol> <li><a href="https://zenodo.org/api/files/a153e748-7ff5-419d-a7a0-ab7d962d9ccb/output_11ax_sr_simulations_sce1.txt">output_11ax_sr_simulations_sce1.txt</a>: contains the output generated by the simulator for the deployments in Scenario 1.</li> <li><a href="https://zenodo.org/api/files/a153e748-7ff5-419d-a7a0-ab7d962d9ccb/simulator_input_files_sce1.zip">simulator_input_files_sce1.zip</a>: contains the input files used by the simulator to simulate the deployments in Scenario 1.</li> </ol> </li> <li><strong>Scenario 2: </strong>1,000 different deployments with 2-6 APs and 1-4 STAs per AP. No distance limitation is applied. Each deployment is simulated for each of the 21 possible OBSS/PD thresholds in 11ax. Two files are considered: <ol> <li><a href="https://zenodo.org/api/files/a153e748-7ff5-419d-a7a0-ab7d962d9ccb/output_11ax_sr_simulations_sce2.txt">output_11ax_sr_simulations_sce2.txt</a>: contains the output generated by the simulator for the deployments in Scenario 2.</li> <li><a href="https://zenodo.org/api/files/a153e748-7ff5-419d-a7a0-ab7d962d9ccb/simulator_input_files_sce2.zip">simulator_input_files_sce2.zip</a>: contains the input files used by the simulator to simulate the deployments in Scenario 2.</li> </ol> </li> <li><strong>Scenario 3: </strong>1,000 different deployments with 2-6 APs and 1-4 STAs per AP. No distance limitation is applied. Each deployment is simulated for each of the 21 possible OBSS/PD thresholds in 11ax, and for up to 20 different locations of different STAs of the BSS of interest ("BSS_A"). Two files are considered: <ol> <li><a href="https://zenodo.org/api/files/8057ea42-dd8c-4a02-9fe2-0e3bde8b3db0/output_11ax_sr_simulations_sce3.txt">output_11ax_sr_simulations_sce3.txt</a>: contains the output generated by the simulator for the deployments in Scenario 3.</li> <li><a href="https://zenodo.org/api/files/8057ea42-dd8c-4a02-9fe2-0e3bde8b3db0/simulator_input_files_sce3.zip">simulator_input_files_sce3.zip</a>: contains the input files used by the simulator to simulate the deployments in Scenario 3.</li> </ol> </li> <li><strong>Test:</strong> 1,000 different deployments with 2-6 APs and 1-4 STAs per AP. No distance limitation is applied. A random OBSS/PD threshold is applied. Two files are considered: <ol> <li><a href="https://zenodo.org/api/files/22d1265c-0dea-4bf8-a223-e61c45deb076/output_11ax_sr_simulations_test.txt?versionId=91ccbe70-a821-4601-8db7-1763883dc984">output_11ax_sr_simulations_test.txt</a>: contains the output generated by the simulator for the evaluation deployments. The label (throughput) has been replaced with "0s".</li> <li><a href="https://zenodo.org/api/files/8057ea42-dd8c-4a02-9fe2-0e3bde8b3db0/simulator_input_files_test.zip?versionId=b1581c0b-419c-422b-bb2d-4dbf77f05dd2">simulator_input_files_test.zip</a>: contains the input files used by the simulator to simulate the evaluation deployments.</li> </ol> </li> </ul>
SMART - Self-adaptive Machine Learning Approach for Real-time Tuning of IEEE 802.11 PHY and MAC layers
<p><strong>Introduction</strong></p> <p>Worldwide the demand for wireless access networks providing very high throughputs has been increasing exponentially, namely due to bandwidth-hungry applications such as high definition video streaming and augmented reality. In order to fulfil these requirements, the Wi-Fi standard was enriched with new amendments, such as IEEE 802.11n, IEEE 802.11ac, and recently IEEE 802.11ax (Wi-Fi 6). New parameters have been proposed for both physical (PHY) and media access control (MAC) layers, including channel bonding, short guard interval (SGI), and advanced modulation and coding schemes (MCS).</p> <p>However, the high variability of the signal strength in the wireless radio channel, allied to the channel asymmetry, makes the selection of optimal configurations for these parameters a challenge. Typically, these parameters are configured with a default value. For runtime optimization, some algorithms have already been proposed. Still, they were designed considering legacy IEEE 802.11 releases and static scenarios. Besides, these parameters have their trade-offs that need to be properly managed. To help dealing with this, machine learning has been recently introduced in wireless networks, providing the intelligence that networks need in order to be smart and self-adaptive.</p> <p>SWOP (Smart Wireless Optimization) is a cross-layer optimization approach for Wi-Fi networks extending the current Rate Adaptation (RA) approach, for instance, followed by the well-known Minstrel algorithm widely used in practice. Our approach takes advantage of Deep Reinforcement Learning (DRL) in order to learn the optimal Wi-Fi link configuration. By considering the wireless channel as the environment, the transmitter node (the agent) chooses the best link parameters (the action) in order to maximize the throughput (the reward) based on the channel metrics captured from the environment (the state). In this work we propose a simple DRL-based Wi-Fi Rate Adaptation (RA) algorithm, named Data-driven Algorithm for Rate Adaptation (DARA), which is one of the modules of Smart Wireless Optimization (SWOP)</p> <p>SMART aimed to run a set of wireless experiments on top of w-iLab.t testbeds provided by the Fed4FIRE+ project to directly validate our DRL model and learn a policy from the wireless experiments executed in a controlled environment. However, after facing difficulties with the scenarios we could achieve on the real testbed, we decided to train and test DARA using a trace-based simulation approach. In simulation, we could train our model in scenarios that are more complex and diverse whilst easy to configure, when compared to real testbeds. The w-iLab.t testbeds were still used to capture data traces (e.g. Signal-to-Noise Ratio, position of nodes, transmission power and link distance) that were then injected in ns-3 for validating DARA.</p> <p>With this work, we concluded that DARA performance is impacted when operating in scenarios with asymmetric links, which is common in the highly dynamic and unpredictable wireless environments. Furthermore, the asymmetry offset varies between scenarios and it may also change for the same scenario, as time progresses. This randomness is not addressed when solely considering the SNR as the link metric, posing a challenge in the learning phase of DARA. Despite these limitations, the results obtained show that DARA still achieves up to 14.9% higher throughput higher than Minstrel [1] and slightly lower than Ideal [2] for most of the scenarios. The results obtained will serve as a basis to support our ongoing and future research.</p> <p> </p> <p><strong>Folder Organization</strong></p> <p>The following dataset presents the results of the SMART project, organized in different folders for each Rate Adaptation Algorithm, as well as the traces that were used to obtain such results:</p> <ul> <li><strong>DARA: </strong>Results obtained using our solution <strong>(Naming Convention #1, Folder Content #1)</strong></li> <li><strong>MIN: </strong>Results obtained using Minstrel-HT <strong>(Naming Convention #1, Folder Content #2)</strong></li> <li><strong>ID: </strong>Results obtained using Ideal <strong>(Naming Convention #1, Folder Content #2)</strong></li> <li><strong>TRACES: </strong>Trace files used to obtain the results present in this dataset <strong>(Naming Convention #2, Folder Content #3)</strong></li> </ul> <p><strong>Naming Convention #1 – RAA TID TP TO:</strong></p> <ul> <li>Rate Adaptation Algorithm<strong> (RAA) </strong> <ul> <li><strong>drl </strong>– Data Driven Algorithm for Rate Adaptation</li> <li><strong>min </strong>– MinstrelHTWifiManager</li> <li><strong>id </strong>– IdealWifiManager</li> </ul> </li> <li>Trace ID<strong> (TID)</strong> <ul> <li><strong>3 </strong>up to<strong> 8</strong></li> </ul> </li> <li>Transport Protocol<strong> (TP)</strong> <ul> <li><strong>udp </strong>– User Datagram Protocol</li> </ul> </li> <li>Traffic Orientation<strong> (TO)</strong> <ul> <li><strong>normal </strong>– A<strong>-></strong>B</li> <li><strong>reversed </strong>– B<strong>-></strong>A</li> </ul> </li> </ul> <p><strong>Naming Convention #2 – TID_TXP:</strong></p> <ul> <li>Trace ID<strong> (TID) </strong> <ul> <li><strong>3 </strong>up to<strong> 8</strong></li> </ul> </li> <li>Transmitting Power in dBm <strong>(TXP) </strong> <ul> <li><strong>3, 5, 7, 9, 12 dBm </strong></li> </ul> </li> </ul> <p><strong>Folder Content #1: </strong></p> <ul> <li><em>checkpoint_ RAA TID TP TO</em><strong> (Folder)</strong> <ul> <li><strong>Policy Checkpoint</strong> with which the results were obtained</li> </ul> </li> <li> <ul> <li><strong>Flowmonitor </strong>output for the configured scenario</li> </ul> </li> <li> <ul> <li>Column 1 – <strong>Step Counter</strong></li> <li>Column 2 – <strong>Reward Value</strong></li> <li>Column 3 – <strong>Observation Value</strong></li> <li>Column 4 – <strong>Action Value</strong></li> </ul> </li> <li> <ul> <li>Column 1 – <strong>Simulation Time </strong>(seconds)</li> <li>Column 2 – <strong>Throughput </strong>(Mbit/100ms)</li> </ul> </li> </ul> <p><strong>Folder Content #2: </strong></p> <ul> <li> <ul> <li><strong>Flowmonitor </strong>output for the configured scenario</li> </ul> </li> <li> <ul> <li>Column 1 – <strong>Simulation Time </strong>(seconds)</li> <li>Column 2 – <strong>Throughput </strong>(Mbit/100ms)</li> </ul> </li> </ul> <p><strong>Folder Content #3 - </strong>Source: <a href="https://zenodo.org/record/3713271#.YjjBVDXLdhE">https://zenodo.org/record/3713271#.YjjBVDXLdhE</a><strong>: </strong></p> <p>· <em>date_time</em><strong>.cfg </strong>configuration details of the experiment</p> <p>· <em>date_time_NodeID</em><a href="https://zenodo.org/record/3713271#_ftn1"><strong><em><sup>[1]</sup></em></strong></a><em>_SenderID</em><a href="https://zenodo.org/record/3713271#_ftn2"><strong><em><sup>[2]</sup></em></strong></a><em>_ReceiverID</em><a href="https://zenodo.org/record/3713271#_ftn3"><strong><em><sup>[3]</sup></em></strong></a><em>_FlowType</em><a href="https://zenodo.org/record/3713271#_ftn4"><strong><em><sup>[4]</sup></em></strong></a><em>_Params</em><a href="https://zenodo.org/record/3713271#_ftn5"><strong><em><sup>[5]</sup></em></strong></a><strong>.snr </strong>– logs of the Signal/Noise ratio (1 file per node/flow) </p> <p>· <em>date_time_NodeID_SenderID_ReceiverID_FlowType_Params</em><strong>.stats</strong> – logs of the packets received (1 file per node/flow) </p> <p><a href="https://zenodo.org/record/3713271#_ftnref1"><sub>[1]</sub></a><sub> ID of the node Logging node</sub></p> <p><a href="https://zenodo.org/record/3713271#_ftnref2"><sub>[2]</sub></a><sub> ID of the Sender node</sub></p> <p><a href="https://zenodo.org/record/3713271#_ftnref3"><sub>[3]</sub></a><sub> ID of the Receiver node</sub></p> <p><a href="https://zenodo.org/record/3713271#_ftnref4"><sub>[4]</sub></a><sub> Flow type: Unidirectional, Bidirectional or Unidirectional with Multiple Access</sub></p> <p><a href="https://zenodo.org/record/3713271#_ftnref5"><sub>[5]</sub></a><sub> Configurable parameters: Sender/Receiver Transmission Power and Data Rate (when applicable)</sub></p> <p> </p> <p><strong>References</strong></p> <p>1. F. FietKau, “Minstrel_HT: New rate control module for 802.11n [LWN.net]”. Mrt-2010.</p> <p>2. “ns-3: ns3::IdealWifiManager Class Reference,” Jan 2021, [Online; accessed 23. Jun. 2021]. Available: <a href="https://www.nsnam.org/docs/release/3.33/doxygen/classns3_1_1_ideal_wifi%20manager.html">https://www.nsnam.org/docs/release/3.33/doxygen/classns3_1_1_ideal_wifi manager.html</a></p>
Supplementary Materials for "What Your Wearable Devices Revealed About You and Possibilities of Non-Cooperative 802.11 Presence Detection During Your Last IPIN Visit"
<p>Supplementary Materials for "What Your Wearable Devices Revealed About You and Possibilities of Non-Cooperative 802.11 Presence Detection During Your Last IPIN Visit"</p> <p>This package contains an anonymized packet of 802.11 probe requests captured in Lloret de Mar during the Indoor Positioning and Indoor Navigation 2021 conference. The packet capture file is in the standardized *.pcap binary format and can be opened with any packet analysis tool such as Wireshark or scapy (Python packet analysis and manipulation package).</p>
Labeled dataset of IEEE 802.11 probe requests
<p><strong>Introduction</strong> <br> <br> The 802.11 standard includes several management features and corresponding frame types. One of them are probe requests (PR). They are sent by mobile devices in the unassociated state to search the nearby area for existing wireless networks. The frame part of PRs consists of variable length fields called information elements (IE). IE fields represent the capabilities of a mobile device, such as data rates. <br> The dataset includes PRs collected in a controlled rural environment and in a semi-controlled indoor environment under different measurement scenarios. <br> It can be used for various use cases, e.g., analysing MAC randomization, determining the number of people in a given location at a given time or in different time periods, analysing trends in population movement (streets, shopping malls, etc.) in different time periods, etc.</p> <p> <br> <strong>Measurement setup</strong> <br> <br> The system for collecting PRs consists of a Raspberry Pi 4 (RPi) with an additional WiFi dongle to capture Wi-Fi signal traffic in monitoring mode. Passive PR monitoring is performed by listening to 802.11 traffic and filtering out PR packets on a single WiFi channel.<br> The following information about each PR received is collected: MAC address, Supported data rates, extended supported rates, HT capabilities, extended capabilities, data under extended tag and vendor specific tag, interworking, VHT capabilities, RSSI, SSID and timestamp when PR was received.<br> The collected data was forwarded to a remote database via a secure VPN connection. A Python script was written using the Pyshark package for data collection, preprocessing and transmission.</p> <p><br> <strong>Data preprocessing</strong></p> <p>The gateway collects PRs for each consecutive predefined scan interval (10 seconds). During this time interval, the data are preprocessed before being transmitted to the database.<br> For each detected PR in the scan interval, IEs fields are saved in the following JSON structure:<br> PR_IE_data =<br> {<br> 'DATA_RTS': {'SUPP': DATA_supp , 'EXT': DATA_ext},<br> 'HT_CAP': DATA_htcap,<br> 'EXT_CAP': {'length': DATA_len, 'data': DATA_extcap},<br> 'VHT_CAP': DATA_vhtcap,<br> 'INTERWORKING': DATA_inter,<br> 'EXT_TAG': {'ID_1': DATA_1_ext, 'ID_2': DATA_2_ext ...},<br> 'VENDOR_SPEC': {VENDOR_1:{<br> 'ID_1': DATA_1_vendor1,<br> 'ID_2': DATA_2_vendor1<br> ...},<br> VENDOR_2:{<br> 'ID_1': DATA_1_vendor2,<br> 'ID_2': DATA_2_vendor2<br> ...}<br> ...}<br> }</p> <p> <br> Supported data rates and extended supported rates are represented as arrays of values that encode information about the rates supported by a mobile device. The rest of the IEs data is represented in hexadecimal format. Vendor Specific Tag is structured differently than the other IEs. This field can contain multiple vendor IDs with multiple data IDs with corresponding data. Similarly, the extended tag can contain multiple data IDs with corresponding data. <br> Missing IE fields in the captured PR are not included in <em>PR_IE_DATA</em>.</p> <p>When a new MAC address is detected in the current scan time interval, the data from PR is stored in the following structure:</p> <p>{'MAC': MAC_address, 'SSIDs': [ SSID ], 'PROBE_REQs': [PR_data] },</p> <p>where <em>PR_data</em> is structured as follows:<br> {<br> 'TIME': [ DATA_time ],<br> 'RSSI': [ DATA_rssi ],<br> 'DATA': PR_IE_data<br> }.</p> <p>This data structure allows storing only <em>TOA</em> and <em>RSSI</em> for all PRs originating from the same MAC address and containing the same <em>PR_IE_data</em>. All SSIDs from the same MAC address are also stored. <br> The data of the newly detected PR is compared with the already stored data of the same MAC in the current scan time interval. <br> If identical PR's IE data from the same MAC address is already stored, then only data for the keys <em>TIME</em> and <em>RSSI</em> are appended.<br> If no identical PR's IE data has yet been received from the same MAC address, then PR_data structure of the new PR for that MAC address is appended to <em>PROBE_REQs</em> key. <br> The preprocessing procedure is shown in Figure ./Figures/Preprocessing_procedure.png <br> At the end of each scan time interval, all processed data is sent to the database along with additional metadata about the collected data e.g. wireless gateway serial number and scan start and end timestamps. For an example of a single PR captured, see the ./Single_PR_capture_example.json file.</p> <p><br> <strong>Environments description</strong> <br> <br> We performed measurements in a controlled rural outdoor environment and in a semi-controlled indoor environment of the Jozef Stefan Institute.<br> See the Excel spreadsheet Measurement_informations.xlsx for a list of mobile devices tested. <br> <br> <strong>Indoor environment </strong><br> <br> We used 3 RPi's for the acquisition of PRs in the Jozef Stefan Institute. They were placed indoors in the hallways as shown in the ./Figures/RPi_locations_JSI.png. Measurements were performed on weekend to minimize additional uncontrolled traffic from users' mobile devices. While there is some overlap in WiFi coverage between the devices at the location 2 and 3, the device at location 1 has no overlap with the other two devices.</p> <p> <strong>Rural environment outdoors</strong> <br> <br> The three RPi's used to collect PRs were placed at three different locations with non-overlapping WiFi coverage, as shown in ./Figures/RPi_locations_rural_env.png. Before starting the measurement campaign, all measured devices were turned off and the environment was checked for active WiFi devices. We did not detect any unknown active devices sending WiFi packets in the RPi's coverage area, so the deployment can be considered fully controlled.<br> All known WiFi enabled devices that were used to collect and send data to the database used a global MAC address, so they can be easily excluded in the preprocessing phase. MAC addresses of these devices can be found in the ./Measurement_informations.xlsx spreadsheet.<br> Note: The Huawei P20 device with ID 4.3 was not included in the test in this environment.</p> <p><br> <strong>Scenarios description</strong> <br> <br> We performed three different scenarios of measurements. <br> <br> <strong>Individual device measurements</strong><br> <br> For each device, we collected PRs for one minute with the screen on, followed by PRs collected for one minute with the screen off. In the indoor environment the WiFi interfaces of the other devices not being tested were disabled. In rural environment other devices were turned off. Start and end timestamps of the recorded data for each device can be found in the ./Measurement_informations.xlsx spreadsheet under the <em>Indoor environment of Jozef Stefan Institute</em> sheet and the <em>Rural environment</em> sheet.</p> <p> <strong>Three groups test</strong></p> <p>In this measurement scenario, the devices were divided into three groups. The first group contained devices from different manufacturers. The second group contained devices from only one manufacturer (Samsung). Half of the third group consisted of devices from the same manufacturer (Huawei), and the other half of devices from different manufacturers. The distribution of devices among the groups can be found in the ./Measurement_informations.xlsx spreadsheet. <br> <br> The same data collection procedure was used for all three groups. Data for each group were collected in both environments at three different RPis locations, as shown in ./Figures/RPi_locations_JSI.png and ./Figures/RPi_locations_rural_env.png. <br> At each location, PRs were collected from each group for 10 minutes with the screen on. Then all three groups switched locations and the process was repeated. Thus, the dataset contains measurements from all three RPi locations of all three groups of devices in both measurement environments. The group movements and the timestamps for the start and end of the collection of PRs at each loacation can be found in spreadsheet ./Measurement_informations.xlsx.</p> <p> <strong>One group test</strong> <br> <br> In the last measurement scenario, all devices were grouped together. In rural evironement we first collected PRs for 10 minutes while the screen was on, and then for another 10 minutes while the screen was off. In indoor environment data were collected at first location with screens on for 10 minutes. Then all devices were moved to the location of the next RPi and PRs were collected for 5 minutes with the screen on and then for another 5 minutes with the screen off.</p> <p><strong>Folder structure</strong> <br> <br> The root directory contains two files in JSON format for each of the environments where the measurements took place (Data_indoor_environment.json and Data_rural_environment.json). Both files contain collected PRs for the entire day that the measurements were taken (12:00 AM to 12:00 PM) to get a sense of the behaviour of the unknown devices in each environment. The spreadsheet ./Measurement_informations.xlsx. contains three sheets. <em>Devices description</em> contains general information about the tested devices, RPis, and the assigned group for each device. The sheets <em>Indoor environment of Jozef Stefan Institute</em> and <em>Rural environment</em> contain the corresponding timestamps for the start and end of each measurement scenario. For the scenario where the devices were divided into groups, additional information about the movements between locations is included. The location names are based on the RPi gateway ID and may differ from those on the figures showing the locations of the RPIs for each environment.<br> The ./Figures folder contains the figures already mentioned above.</p>
Dataset of IEEE 802.11 probe requests from an uncontrolled urban environment
<p><strong>Introduction</strong></p> <p>The 802.11 standard includes several management features and corresponding frame types. One of them are Probe Requests (PR), which are sent by mobile devices in an unassociated state to scan the nearby area for existing wireless networks. The frame part of PRs consists of variable-length fields, called Information Elements (IE), which represent the capabilities of a mobile device, such as supported data rates.</p> <p>This dataset contains PRs collected over a seven-day period by four gateway devices in an uncontrolled urban environment in the city of Catania.</p> <p>It can be used for various use cases, e.g., analyzing MAC randomization, determining the number of people in a given location at a given time or in different time periods, analyzing trends in population movement (streets, shopping malls, etc.) in different time periods, etc.</p> <p><strong> Related dataset</strong></p> <p>Same authors also produced the <a href="https://zenodo.org/record/7503594">Labeled dataset of IEEE 802.11 probe requests</a> with same data layout and recording equipment.</p> <p><br> <strong>Measurement setup</strong> </p> <p>The system for collecting PRs consists of a Raspberry Pi 4 (RPi) with an additional WiFi dongle to capture WiFi signal traffic in monitoring mode (gateway device).<br> Passive PR monitoring is performed by listening to 802.11 traffic and filtering out PR packets on a single WiFi channel.</p> <p>The following information about each received PR is collected:<br> - MAC address<br> - Supported data rates<br> - extended supported rates<br> - HT capabilities<br> - extended capabilities<br> - data under extended tag and vendor specific tag<br> - interworking<br> - VHT capabilities<br> - RSSI<br> - SSID<br> - timestamp when PR was received.</p> <p>The collected data was forwarded to a remote database via a secure VPN connection.<br> A Python script was written using the Pyshark package to collect, preprocess, and transmit the data.</p> <p><br> <strong>Data preprocessing</strong></p> <p><br> The gateway collects PRs for each successive predefined scan interval (10 seconds). During this interval, the data is preprocessed before being transmitted to the database.<br> For each detected PR in the scan interval, the IEs fields are saved in the following JSON structure:</p> <pre><code class="language-json">PR_IE_data = { 'DATA_RTS': {'SUPP': DATA_supp , 'EXT': DATA_ext}, 'HT_CAP': DATA_htcap, 'EXT_CAP': {'length': DATA_len, 'data': DATA_extcap}, 'VHT_CAP': DATA_vhtcap, 'INTERWORKING': DATA_inter, 'EXT_TAG': {'ID_1': DATA_1_ext, 'ID_2': DATA_2_ext ...}, 'VENDOR_SPEC': {VENDOR_1:{ 'ID_1': DATA_1_vendor1, 'ID_2': DATA_2_vendor1 ...}, VENDOR_2:{ 'ID_1': DATA_1_vendor2, 'ID_2': DATA_2_vendor2 ...} ...} }</code></pre> <p><br> Supported data rates and extended supported rates are represented as arrays of values that encode information about the rates supported by a mobile device. The rest of the IEs data is represented in hexadecimal format. Vendor Specific Tag is structured differently than the other IEs. This field can contain multiple vendor IDs with multiple data IDs with corresponding data. Similarly, the extended tag can contain multiple data IDs with corresponding data. <br> Missing IE fields in the captured PR are not included in <em>PR_IE_DATA</em>.</p> <p>When a new MAC address is detected in the current scan time interval, the data from PR is stored in the following structure:</p> <pre><code class="language-json">{'MAC': MAC_address, 'SSIDs': [ SSID ], 'PROBE_REQs': [PR_data] },</code></pre> <p>where <em>PR_data</em> is structured as follows:</p> <pre><code class="language-json">{ 'TIME': [ DATA_time ], 'RSSI': [ DATA_rssi ], 'DATA': PR_IE_data }.</code></pre> <p> </p> <p>This data structure allows to store only 'TOA' and 'RSSI' for all PRs originating from the same MAC address and containing the same 'PR_IE_data'. All SSIDs from the same MAC address are also stored.<br> The data of the newly detected PR is compared with the already stored data of the same MAC in the current scan time interval.<br> If identical PR's IE data from the same MAC address is already stored, only data for the keys 'TIME' and 'RSSI' are appended.<br> If identical PR's IE data from the same MAC address has not yet been received, then the PR_data structure of the new PR for that MAC address is appended to the 'PROBE_REQs' key.<br> The preprocessing procedure is shown in Figure ./Figures/Preprocessing_procedure.png</p> <p>At the end of each scan time interval, all processed data is sent to the database along with additional metadata about the collected data, such as the serial number of the wireless gateway and the timestamps for the start and end of the scan. For an example of a single PR capture, see the <em>Single_PR_capture_example.json</em> file.</p> <p><br> <strong>Folder structure</strong></p> <p>For ease of processing of the data, the dataset is divided into 7 folders, each containing a 24-hour period.<br> Each folder contains four files, each containing samples from that device.</p> <p>The folders are named after the start and end time (in UTC).<br> For example, the folder [2022-09-22T22-00-00_2022-09-23T22-00-00](2022-09-22T22-00-00_2022-09-23T22-00-00) contains samples collected between <em>23th of September 2022 00:00 local time</em>, until <em>24th of September 2022 00:00</em> local time.</p> <p>Files representing their location via mapping:<br> - 1.json -> location 1<br> - 2.json -> location 2<br> - 3.json -> location 3<br> - 4.json -> location 4</p> <p><strong>Environments description</strong> </p> <p>The measurements were carried out in the city of Catania, in Piazza Università and Piazza del Duomo<br> The gateway devices (rPIs with WiFi dongle) were set up and gathering data before the start time of this dataset.<br> As of September 23, 2022, the devices were placed in their final configuration and personally checked for correctness of installation and data status of the entire data collection system.<br> Devices were connected either to a nearby Ethernet outlet or via WiFi to the access point provided.</p> <p>Four Raspbery Pi-s were used:<br> - location 1 -> Piazza del Duomo - Chierici building (balcony near Fontana dell’Amenano)<br> - location 2 -> southernmost window in the building of Via Etnea near Piazza del Duomo<br> - location 3 -> nothernmost window in the building of Via Etnea near Piazza Università<br> - location 4 -> first window top the right of the entrance of the University of Catania</p> <p>Locations were suggested by the authors and adjusted during deployment based on physical constraints (locations of electrical outlets or internet access)<br> Under ideal circumstances, the locations of the devices and their coverage area would cover both squares and the part of Via Etna between them, with a partial overlap of signal detection. The locations of the gateways are shown in Figure ./Figures/catania.png.</p> <p> <strong>Known dataset shortcomings</strong></p> <p>Due to technical and physical limitations, the dataset contains some identified deficiencies.</p> <p>PRs are collected and transmitted in 10-second chunks.<br> Due to the limited capabilites of the recording devices, some time (in the range of seconds) may not be accounted for between chunks if the transmission of the previous packet took too long or an unexpected error occurred.</p> <p>Every 20 minutes the service is restarted on the recording device.<br> This is a workaround for undefined behavior of the USB WiFi dongle, which can no longer respond.<br> For this reason, up to 20 seconds of data will not be recorded in each 20-minute period.</p> <p>The devices had a scheduled reboot at 4:00 each day which is shown as missing data of up to a few minutes.</p> <p> <strong> Location 1 - Piazza del Duomo - Chierici</strong></p> <p> The gateway device (rPi) is located on the second floor balcony and is hardwired to the Ethernet port. This device appears to function stably throughout the data collection period.<br> Its location is constant and is not disturbed, dataset seems to have complete coverage.</p> <p> <strong>Location 2 - Via Etnea - Piazza del Duomo</strong></p> <p> The device is located inside the building.<br> During working hours (approximately 9:00-17:00), the device was placed on the windowsill. However, the movement of the device cannot be confirmed.<br> As the device was moved back and forth, power outages and internet connection issues occurred.<br> The last three days in the record contain no PRs from this location.</p> <p> <strong> Location 3 - Via Etnea - Piazza Università</strong></p> <p> Similar to Location 2, the device is placed on the windowsill and moved around by people working in the building.<br> Similar behavior is also observed, e.g., it is placed on the windowsill and moved inside a thick wall when no people are present.<br> This device appears to have been collecting data throughout the whole dataset period.<br> <br> <strong> Location 4 - Piazza Università</strong></p> <p> This location is wirelessly connected to the access point.<br> The device was placed statically on a windowsill overlooking the square.<br> Due to physical limitations, the device had lost power several times during the deployment.<br> The internet connection was also interrupted sporadically.</p> <p><strong>Recognitions</strong></p> <p>The data was collected within the scope of <a href="https://www.resilocproject.eu/">Resiloc project</a> with the help of City of Catania and project partners.</p>
Graphs for indoor building scenarios for IEEE 802.11 Networks
<p>Graph files and the corresponding EPS figures for the IEEE 802.11 indoor building scenarios used in the experiments for the following publications:</p> <p>* Tejedor-Romero, M., Gimenez-Guzman, J. M., Cruz-Piris, L., Herranz-Oliveros, D., & Marsa-Maestre, I. (2024). Optimal channel assignment on dense Wi-Fi networks using Thermodynamic Threshold Accepting. <em>Engineering Science and Technology, an International Journal</em>, <em>57</em>, 101797, https://doi.org/10.1016/j.jestch.2024.101797</p> <p>* J.M. Gimenez-Guzman, I. Marsa-Maestre, L. Cruz-Piris, D. Orden, M. Tejedor-Romero, "IEEE 802.11 graph models", Alexandria Engineering Journal, https://doi.org/10.1016/j.aej.2022.12.016</p>
Non-cooperative 802.11 MAC layer fingerprinting and tracking of mobile devices
<p>This archive contains the datasets used for the experiments in the paper "Non-cooperative 802.11 MAC layer fingerprinting and tracking of mobile devices", namely:</p> <ul> <li><em>Glimps 2015 dataset (mac_info collection)</em>: A collection of 122,989 Probe Request frames captured by 8 monitoring stations at the Glimps music festival in Ghent, Belgium (10 - 12 December 2015). To minimize overhead, each monitoring station individually stored only one Probe Request per unique MAC. The dataset was used to show that the high entropy in Probe Requests can be used to deanonymize devices that use MAC address randomization. Only the source MAC and Information Elements (IEs) were captured for this purpose. </li> <li><em>Research center 2016 dataset (mac_research collection)</em>: A complete collection of all management and control frames (including Radiotap headers) observed at our research lab from 28 January to 8 Febuary 2016. This dataset was used to calculate the "stability" and "variability" of Probe Request IEs (see our paper for more details on these metrics).</li> <li><em>Transmission rate datasets (mac_research_0 - mac_research_4 collections)</em>: Observations of mobile devices when actively instigated for extra transmissions. These observations were used in the paper to calculate the effectiveness of the various stimulus frame techniques. This dataset should only be used to verify the results in the paper. The other datasets could be used for related experiments.</li> </ul> <p>All datasets were anonymized by applying the following rules:</p> <ul> <li>The 3 least significant bytes of each MAC address were uniquely and consistently mapped to a different value, with exception of "ff:ff:ff" and "00:00:00".</li> <li>The SSID IE has its SSID field replaced with the string "Hidden", with exception of the wildcard (empty) SSID.</li> <li>The Vendor Specific WPS IE was replaced with a hash of its payload given the amount of sensitive information (device serial / model number, UUID, etc.) contained within it, and the length of the IE was updated accordingly. Unfortunately, Wireshark stops parsing the remainder of Probes containing this anonymized IE, so it should be noted that further parsing beyond the WPS IE must be done manually (e.g. by using Scapy or by changing the Wireshark dissector).</li> </ul> <p>The datasets are provided as MongoDB collections with the following document format:</p> <ul> <li>_id: ObjectID of the document</li> <li>info_length: Length of the binary blob</li> <li>info: Binary blob of the Radiotap frame (mac_research) or only the Information Elements (mac_info)</li> <li>mac_addr: Transmitter of the frame</li> </ul> <p>To install the dataset, execute the command "mongorestore --gzip -d anonymized ./anonymized" after extracting the .tar.xz file.</p> <p>A .pcap format of the <em>mac_info </em>(wrapped in a dummy Radiotap frame) and <em>mac_research</em> datasets is additionally provided at crawdad.org.</p> <p>The <em>mac_info</em> dataset can be visually explored on https://wicability.net/datasets (Glimps 2015 dataset).</p>
Inputs and outputs of conference article "On the Performance of the Spatial Reuse Operation in IEEE 802.11ax WLANs"
<p>This dataset contains both the inputs and the outputs from the conference article "On the Performance of the Spatial Reuse Operation in IEEE 802.11ax WLANs", authored by Francesc Wilhelmi, Sergio Barrachina and Boris Bellalta. The article has been sent to CSCN 2019.</p> <p>Regarding the input, we provide both the "input_node" and "input_system" files used by the Komondor simulator. In particular, up to 50,400 different scenarios are provided, which stand for 3 maps sizes 50 different random deployments (i.e., nodes allocation), 21 OBSS/PD values, and 16 traffic loads. More details are provided in the article. </p> <p>The output files collect the results gathered for all the scenarios. In addition, we include the code files used to "post-process" all the results.</p> <p>Contact information: francisco.wilhelmi@upf.edu</p>
Vehicle-to-Infrastructure IEEE 802.11ad Wi-Fi dataset
<p><strong>1. Introduction</strong></p> <p>This dataset contains space and time-indexed data collected in a Vehicle-To-Infrastructure (V2I) communication scenario, where a moving vehicle downloaded data from a stationary Access Point (AP) using IEEE 802.11ad Wi-Fi.</p> <p>The dataset is comprised of both throughput data and detailed frame information captured with <code>tcpdump</code>. It can be used to study 802.11ad's behavior in vehicular environments, in particular in what pertains to antenna sector selection.</p> <p>This dataset is associated with the following article, which we recommend consulting for more information: <a href="https://www.cs.vassar.edu/~rpachecomeireles/research/papers/comcom-2022-preprint.pdf"><em>Geolocation-based Sector Selection for Vehicle-to-Infrastructure 802.11ad Communication</em></a>, Mateus Mattos, António Rodrigues, Rui Meireles, Ana Aguiar, in the Elsevier Journal of Computer Communications, Volume 193, ISSN 0140-3664, 2022, <a href="https://doi.org/10.1016/j.comcom.2022.07.005">doi:10.1016/j.comcom.2022.07.005</a>.</p> <p><strong>2. Experimental setup</strong></p> <p>The AP was placed at the corner of a residential-area intersection while a mobile client vehicle drove around it, downloading data from the AP.</p> <p>Commercial Off-The-Shelf (COTS) TP-Link Talon AD7200 were used for both the stationary AP and mobile client. A third AD7200 configured in promiscuous mode was placed next to the mobile client, in order to capture the control frames being exchanged.</p> <p><strong>2.1 Experimental nodes</strong></p> <table> <tbody><tr> <th>MAC address</th> <th>Role</th> <th>Position</th> <th>Orientation</th> </tr> </tbody><tbody> <tr> <td><code>70:4f:57:72:b2:52</code></td> <td>AP</td> <td>Static, latitude: 41.111879, longitude: -8.631146, mounted of top of a parked vehicle</td> <td>Perpendicular to road</td> </tr> <tr> <td><code>50:c7:bf:97:8a:ac</code></td> <td>Client</td> <td>Mobile, mounted on roof of client vehicle</td> <td>Towards front of vehicle</td> </tr> <tr> <td><code>50:c7:bf:3c:53:1c</code></td> <td>Monitor</td> <td>Mobile, mounted on roof of client vehicle</td> <td>Towards front of vehicle</td> </tr> </tbody> </table> <p><strong>3. Trace description</strong></p> <p>The data is divided into traces. Each trace represents an uninterrupted period of data collection. The experiments were ran twice, once in 2020, and again in 2021. Environmental conditions, such as weather and topography, were consistent between the two experiment sets.</p> <p><strong>3.1 2020 traces</strong></p> <table> <tbody><tr> <th>Trace #</th> <th>Start timestamp</th> <th>End timestamp</th> <th>Mobility pattern</th> </tr> </tbody><tbody> <tr> <td>235</td> <td>1593946456</td> <td>1593946593</td> <td>Vehicle moving eastwards from AP and back, straight line, low speed</td> </tr> <tr> <td>237</td> <td>1593946793</td> <td>1593946908</td> <td>Vehicle moving westwards from AP and back, straight line, low speed</td> </tr> <tr> <td>238</td> <td>1593946938</td> <td>1593947076</td> <td>Vehicle moving eastwards from AP and back, straight line, low speed</td> </tr> <tr> <td>240</td> <td>1593947181</td> <td>1593947332</td> <td>Vehicle moving westwards from AP and back, straight line, low speed</td> </tr> <tr> <td>241</td> <td>1593947360</td> <td>1593947499</td> <td>Vehicle moving eastwards from AP and back, straight line, low speed</td> </tr> <tr> <td>242</td> <td>1593947566</td> <td>1593947700</td> <td>Vehicle moving westwards from AP and back, straight line, low speed</td> </tr> <tr> <td>243</td> <td>1593947759</td> <td>1593947915</td> <td>Vehicle moving southwards from AP and back, straight line, low speed</td> </tr> <tr> <td>244</td> <td>1593947971</td> <td>1593948111</td> <td>Vehicle moving southwards from AP and back, straight line, low speed</td> </tr> <tr> <td>245</td> <td>1593948210</td> <td>1593948348</td> <td>Vehicle moving southwards from AP and back, straight line, low speed</td> </tr> <tr> <td>246</td> <td>1593948433</td> <td>1593948569</td> <td>Vehicle moving northwards from AP and back, straight line, low speed</td> </tr> <tr> <td>247</td> <td>1593948631</td> <td>1593948795</td> <td>Vehicle moving northwards from AP and back, straight line, low speed</td> </tr> <tr> <td>248</td> <td>1593948904</td> <td>1593949053</td> <td>Vehicle moving northwards from AP and back, straight line, low speed</td> </tr> <tr> <td>249</td> <td>1593949307</td> <td>1593950016</td> <td>Vehicle driving circuit around the intersection, medium speed (see file <code>driving-circuit.gif</code>)</td> </tr> <tr> <td>250</td> <td>1593950073</td> <td>1593950643</td> <td>Vehicle driving circuit around the intersection, medium speed (see file <code>driving-circuit.gif</code>)</td> </tr> <tr> <td>251</td> <td>1593950682</td> <td>1593951240</td> <td>Vehicle driving circuit around the intersection, medium speed (see file <code>driving-circuit.gif</code>)</td> </tr> </tbody> </table> <p><strong>3.2 2021 traces</strong></p> <table> <tbody><tr> <th>Trace #</th> <th>Start timestamp</th> <th>End timestamp</th> <th>Mobility pattern</th> </tr> </tbody><tbody> <tr> <td>201</td> <td>1632244398</td> <td>1632244548</td> <td>Vehicle moving eastwards from AP and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>202</td> <td>1632244563</td> <td>1632244663</td> <td>Vehicle moving westwards from AP and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>203</td> <td>1632244674</td> <td>1632244799</td> <td>Vehicle moving southwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>204</td> <td>1632244812</td> <td>1632244915</td> <td>Vehicle moving northwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>206</td> <td>1632245138</td> <td>1632245346</td> <td>Vehicle moving eastwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>207</td> <td>1632245355</td> <td>1632245463</td> <td>Vehicle moving southwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>208</td> <td>1632245472</td> <td>1632245581</td> <td>Vehicle moving northwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>209</td> <td>1632245592</td> <td>1632245790</td> <td>Vehicle moving southwards from AP and back, northwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>210</td> <td>1632245798</td> <td>1632245987</td> <td>Vehicle moving eastwards from AP and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>302</td> <td>1632335672</td> <td>1632336273</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>303</td> <td>1632336286</td> <td>1632336870</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>401</td> <td>1634983869</td> <td>1634984363</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>402</td> <td>1634984410</td> <td>1634984881</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>403</td> <td>1634984908</td> <td>1634985562</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>404</td> <td>1634985666</td> <td>1634986835</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>405</td> <td>1634986980</td> <td>1634988303</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>406</td> <td>1634988352</td> <td>1634989470</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>407</td> <td>1634989490</td> <td>1634990434</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> </tbody> </table> <p><strong>4. Data description</strong></p> <p><strong>4.1 File structure</strong></p> <p>The data from the 2020 and 2021 sets of experiments can be found in subfolders <code>2020</code> and <code>2021</code>, respectively.</p> <p>Each subfolder constains the following:</p> <ul> <li><code>gps.csv</code>: client vehicle mobility trace (individual NMEA sentences);</li> <li><code>gps-merged.csv</code>: client vehicle mobility trace (summarized);</li> <li><code>thrghpt.csv</code>: application throughput data;</li> <li><code>wifi.csv</code>: summarized 802.11ad frame data;</li> <li><code>pcap/</code>: contains raw <code>.pcap</code> files used to generate <code>wifi.csv</code>, separated by trace number;</li> <li><code>configs/</code>: includes JSON file with fields and filters used by <code>tshark</code> for the generation of <code>wifi.csv</code>.</li> </ul> <p><strong>4.2 GPS data: <code>gps.csv</code></strong> and <code>gps-merged.csv</code></p> <p>GPS data was captured by a high-accuracy GPS device: Trimble Pro Series 6H <a href="http://www.windenvironmental.com/Data-Sheets/Trimble-Pro%20Series-DS.pdf">[link]</a>, and consists of a combination of fields provided by multiple NMEA <code>GP*</code> sentence codes, namely: <code>GPRMC</code>, <code>GPGGA</code>, <code>GPGLL</code>, and <code>GNGSA</code> <a href="http://aprs.gids.nl/nmea/">[link]</a>.</p> <p>Column description</p> <p><code>gps.csv</code> is a table with the following columns:</p> <table> <tbody><tr> <th>Column</th> <th>Description</th> </tr> </tbody><tbody> <tr> <td><code>timestamp</code></td> <td>UNIX system timestamp at which GPS sentence was recorded, in seconds</td> </tr> <tr> <td><code>lat</code></td> <td>Latitude, in decimal degrees</td> </tr> <tr> <td><code>lon</code></td> <td>Longitude, in decimal degrees</td> </tr> <tr> <td><code>alt</code></td> <td>Altitude, in meters</td> </tr> <tr> <td><code>speed</code></td> <td>Ground speed, in knots</td> </tr> <tr> <td><code>HDOP</code></td> <td>Horizontal dilution of precision</td> </tr> <tr> <td><code>PDOP</code></td> <td>Position dilution of precision</td> </tr> <tr> <td><code>VDOP</code></td> <td>Vertical dilution of precision</td> </tr> <tr> <td><code>heading</code></td> <td>Direction of movement as provided by GPS device, in clockwise degrees from north</td> </tr> <tr> <td><code>identifier</code></td> <td>NMEA sentence code, e.g., <code>GPRMC</code></td> </tr> <tr> <td><code>gpstime</code></td> <td>Timestamp as provided by GPS device, in seconds</td> </tr> </tbody> </table> <p><strong>Note:</strong> Because each GPS sentence only contains a subset of the listed columns, any missing values are set to -1.0.</p> <p><code>gps-merged.csv</code> is a table containing all mobility information aggregated by GPS timestamp, for ease of use. It contains the following columns:</p> <table> <tbody><tr> <th>Column</th> <th>Description</th> </tr> </tbody><tbody> <tr> <td><code>gpstime</code></td> <td>Timestamp as provided by GPS device, in seconds</td> </tr> <tr> <td><code>timestamp</code></td> <td>Average UNIX system timestamp at which the GPS sentences from which this row was created were recorded, in seconds</td> </tr> <tr> <td><code>lat</code></td> <td>Latitude, in decimal degrees</td> </tr> <tr> <td><code>lon</code></td> <td>Longitude, in decimal degrees</td> </tr> <tr> <td><code>alt</code></td> <td>Altitude, in meters</td> </tr> <tr> <td><code>speed</code></td> <td>Ground speed, in knots</td> </tr> <tr> <td><code>HDOP</code></td> <td>Horizontal dilution of precision</td> </tr> <tr> <td><code>PDOP</code></td> <td>Position dilution of precision</td> </tr> <tr> <td><code>VDOP</code></td> <td>Vertical dilution of precision</td> </tr> <tr> <td><code>heading</code></td> <td>Direction of movement as provided by GPS device, in clockwise degrees from north</td> </tr> </tbody> </table> <p><strong>4.3 Application layer throughput : <code>thrghpt.csv</code></strong></p> <p>Data was sent from a custom sender application running on the AP, at the maximum possible rate. A custom receiver application on the client vehicle consumes the data. A time-indexed log of the amount of data sent and received was recorded.</p> <p>Column description</p> <p><code>thrghpt.csv</code> is a table with the following columns:</p> <table> <tbody><tr> <th>column</th> <th>description</th> </tr> </tbody><tbody> <tr> <td><code>timestamp</code></td> <td>UNIX system timestamp the throughput record pertains to</td> </tr> <tr> <td><code>pckt_cntr</code></td> <td>Number of packets received within the current record</td> </tr> <tr> <td><code>byte_cntr</code></td> <td>Number of bytes received within the current record</td> </tr> <tr> <td><code>elapsed_time</code></td> <td>Time elapsed since previous throughput record</td> </tr> <tr> <td><code>thrghpt</code></td> <td>Throughput for the current record, in in Megabit per second (Mbps)</td> </tr> <tr> <td><code>inter_arrival_avg </code></td> <td>Average inter-packet arrival time during the recording period, in seconds</td> </tr> <tr> <td><code>diff_local_avg </code></td> <td>Average delta between the timestamp recorded in the packet's payload (set by the sender) and the local timestamp in the receiver, in microseconds</td> </tr> <tr> <td><code>trace_nr</code></td> <td>Trace number the throughput data is associated with</td> </tr> </tbody> </table> <p><strong>4.4 802.11ad frame data: <code>wifi.csv</code></strong></p> <p>The <code>wifi.csv</code> file contains 802.11ad frame data, captured with <code>tcpdump</code>, on a Talon AD7200 router configured in promiscuous mode and colocated with the mobile client device.</p> <p>Data collection and processing</p> <p>The following <code>tcpdump</code> command was used to collect raw data frames:</p> <pre><code>tcpdump -B 100000 -s96 -i <ad-monitor-interface> -y IEEE802_11_RADIO -w <pcap-file> & </code></pre> <p>In order to create <code>wifi.csv</code>, the raw data frames were processed using <code>tshark</code> in order to filter out unnecessary information. More specifically, we ran the following command:</p> <pre><code>tshark -r <input-pcap> -2 -T fields <fields> -Y "<filter>" -E header=y -E separator=, -E quote=d -E occurrence=f </code></pre> <p>The raw input <code>.pcap</code> files for each trace are provided in the <code>pcap/</code> folder. The parameters <code><filter></code> and <code><fields></code> represent the filtering conditions and what fields we want to extract from each frame, respectively. The actual values used are provided in the <code>configs/tshark.json</code> file.</p> <p>Frames were filtered based on a single field: the WLAN frame type and subtype, or <code>wlan.fc.type_subtype</code>. Only the following types of frames were kept:</p> <table> <tbody><tr> <th>Frame type/subtype value</th> <th>Description</th> </tr> </tbody><tbody> <tr> <td>0x0000</td> <td>Association request</td> </tr> <tr> <td>0x0001</td> <td>Association response</td> </tr> <tr> <td>0x0002</td> <td>Re-association request</td> </tr> <tr> <td>0x0003</td> <td>Re-association response</td> </tr> <tr> <td>0x000a</td> <td>Disassociation</td> </tr> <tr> <td>0x000b</td> <td>Authentication</td> </tr> <tr> <td>0x000c</td> <td>De-authentication</td> </tr> <tr> <td>0x0019</td> <td>Block ACKs</td> </tr> <tr> <td>0x001d</td> <td>Clear-to-send</td> </tr> <tr> <td>0x0028</td> <td>QoS data</td> </tr> <tr> <td>0x0030</td> <td>DMG beacon</td> </tr> <tr> <td>0x0164</td> <td>Grant</td> </tr> <tr> <td>0x0167</td> <td>Grant ACK</td> </tr> <tr> <td>0x0168</td> <td>SLS</td> </tr> <tr> <td>0x0169</td> <td>SLS feedback</td> </tr> <tr> <td>0x016a</td> <td>SLS feedback ACK</td> </tr> </tbody> </table> <p>Column description</p> <p><code>wifi.csv</code> is a table with the following columns:</p> <table> <tbody><tr> <th>Column</th> <th>Description</th> </tr> </tbody><tbody> <tr> <td><code>frame.time_epoch</code></td> <td>UNIX timestamp of frame capture, in seconds (with microsecond resolution)</td> </tr> <tr> <td><code>frame.number</code></td> <td>Ordinal number attributed to captured frame</td> </tr> <tr> <td><code>frame.len</code></td> <td>Frame length, in bytes</td> </tr> <tr> <td><code>ip.src</code></td> <td>Source IP address</td> </tr> <tr> <td><code>ip.dst</code></td> <td>Destination IP address</td> </tr> <tr> <td><code>ip.flags</code></td> <td>IP flags</td> </tr> <tr> <td><code>ip.frag_offset</code></td> <td>IP fragmentation offset</td> </tr> <tr> <td><code>ip.hdr_len</code></td> <td>IP header length</td> </tr> <tr> <td><code>ip.id</code></td> <td>IP identification field</td> </tr> <tr> <td><code>ip.proto</code></td> <td>IP protocol field</td> </tr> <tr> <td><code>ip.reassembled_in</code></td> <td>Frame number in which IP packet is reassembled</td> </tr> <tr> <td><code>radiotap.channel.flags.2ghz</code></td> <td>1 if channel frequency is in 2.4 GHz range, 0 otherwise</td> </tr> <tr> <td><code>radiotap.channel.flags.5ghz</code></td> <td>1 if channel frequency is in 5 GHz range, 0 otherwise</td> </tr> <tr> <td><code>radiotap.channel.freq</code></td> <td>Channel frequency (60480 Hz in this case)</td> </tr> <tr> <td><code>radiotap.length</code></td> <td>IEEE 802.11 radiotap capture header length</td> </tr> <tr> <td><code>radiotap.mcs.index</code></td> <td>Modulation Coding Scheme index</td> </tr> <tr> <td><code>udp.srcport</code></td> <td>UDP source port</td> </tr> <tr> <td><code>udp.dstport</code></td> <td>UDP destination port</td> </tr> <tr> <td><code>wlan.ba.bm</code></td> <td>Block ACK bitmap</td> </tr> <tr> <td><code>wlan.bf</code></td> <td>Full beamforming field of WLAN frame</td> </tr> <tr> <td><code>wlan.bf.isInit</code></td> <td>Whether or not frame is SLS initiator</td> </tr> <tr> <td><code>wlan.bf.isResp</code></td> <td>Whether or not frame is SLS responder</td> </tr> <tr> <td><code>wlan.bf.num_dmg_ants</code></td> <td>Number of DMG antennas</td> </tr> <tr> <td><code>wlan.bf.num_sectors</code></td> <td>Number of SLS sectors</td> </tr> <tr> <td><code>wlan.bf.train</code></td> <td>Whether or not frame is part of SLS training</td> </tr> <tr> <td><code>wlan.fc.retry</code></td> <td>Whether WLAN frame is re-transmitted</td> </tr> <tr> <td><code>wlan.fc.type_subtype</code></td> <td>WLAN frame type and subtype</td> </tr> <tr> <td><code>wlan.fixed.ssc.sequence</code></td> <td>WLAN starting sequence number</td> </tr> <tr> <td><code>wlan.fixed.timestamp</code></td> <td>WLAN timestamp</td> </tr> <tr> <td><code>wlan.frag</code></td> <td>WLAN fragment number</td> </tr> <tr> <td><code>wlan.ta</code></td> <td>WLAN transmitter MAC address</td> </tr> <tr> <td><code>wlan.ra</code></td> <td>WLAN receiver MAC address</td> </tr> <tr> <td><code>wlan.seq</code></td> <td>WLAN frame sequence number</td> </tr> <tr> <td><code>wlan.ssw</code></td> <td>Full Sector-level Sweep (SLS) field of WLAN frame</td> </tr> <tr> <td><code>wlan.ssw.cdown</code></td> <td>SLS countdown (CDOWN) number</td> </tr> <tr> <td><code>wlan.ssw.direction</code></td> <td>SLS direction (0: frame sent by SLS initiator, 1: by SLS responder)</td> </tr> <tr> <td><code>wlan.ssw.sector_id</code></td> <td>ID of sector used for SLS frame</td> </tr> <tr> <td><code>wlan.sswf</code></td> <td>Full SLS feedback field of WLAN frame</td> </tr> <tr> <td><code>wlan.sswf.sector_select</code></td> <td>SLS Feedback Sector Select</td> </tr> <tr> <td><code>wlan.sswf.snr_report</code></td> <td>SLS Feedback SNR Report</td> </tr> <tr> <td><code>wlan_radio.11n.mcs_index</code></td> <td>WLAN MCS index</td> </tr> <tr> <td><code>wlan_radio.channel</code></td> <td>WLAN channel</td> </tr> <tr> <td><code>wlan_radio.data_rate</code></td> <td>WLAN data rate</td> </tr> <tr> <td><code>wlan_radio.duration</code></td> <td>WLAN frame duration</td> </tr> <tr> <td><code>wlan_radio.frequency</code></td> <td>WLAN channel frequency</td> </tr> <tr> <td><code>wlan_radio.noise_dbm</code></td> <td>WLAN noise level, in dBm</td> </tr> <tr> <td><code>wlan_radio.phy</code></td> <td>WLAN PHY type</td> </tr> <tr> <td><code>wlan_radio.preamble</code></td> <td>WLAN preamble</td> </tr> <tr> <td><code>wlan_radio.signal_dbm</code></td> <td>WLAN signal strength, in dBm</td> </tr> <tr> <td><code>wlan_radio.timestamp</code></td> <td>WLAN TSF timestamp</td> </tr> <tr> <td><code>data.text</code></td> <td>Data enclosed in WLAN data frame</td> </tr> <tr> <td><code>trace_nr</code></td> <td>Number of the trace the frame is associated with</td> </tr> </tbody> </table>
802.11 Managemement frames from a public location
<p><strong>About</strong></p> <p>The following datasets were captured at a busy Belgian train station between 9pm and 10pm, it contains all 802.11 management frames that were captured. both datasets were captured with approximately 20 minutes between then.</p> <p>Both datasets are represented by a pcap and CSV file. The CSV file contains the frame type, timestamps, signal strength, SSID and MAC addresses for every frame. In the pcap file, all generic 802.11 elements were removed for anonymization purposes.</p> <p> </p> <p><strong>Anonymization</strong></p> <p>All frames were anonymized by removing identifying information or renaming identifiers. Concretely, the following transformations were applied to both datasets:</p> <ul> <li>All MAC addresses were renamed (e.g. 00:00:00:00:00:01)</li> <li>All SSID's were renamed (e.g. NETWORK_1)</li> <li>All generec 802.11 elements were removed from the pcap</li> </ul> <p>In the pcap file, anonymization actions could lead to "corrupted" frames because length tags do not correspond with the actual data. However, the file and its frames are still readable in packet analyzing tools such as Wireshark or Scapy.</p> <p>The script which was used to anonymize is available in the dataset.</p> <p> </p> <p><strong>Data</strong></p> <table> <caption>Specifications for the datasets</caption> <thead> <tr> <th scope="col">N/o</th> <th scope="col">Dataset 1</th> <th scope="col">dataset 2</th> </tr> </thead> <tbody> <tr> <td>Frames</td> <td>36306</td> <td>60984</td> </tr> <tr> <td>Beacon frames</td> <td>19693</td> <td>27983</td> </tr> <tr> <td>Request frames</td> <td>798</td> <td>1580</td> </tr> <tr> <td>Response frames</td> <td>15815</td> <td>31421</td> </tr> <tr> <td>Identified Wi-Fi Networks</td> <td>54</td> <td>70</td> </tr> <tr> <td>Identified MAC addresses</td> <td>2092</td> <td>2705</td> </tr> <tr> <td>Identified Wireless devices</td> <td>128</td> <td>186</td> </tr> <tr> <td>Capturetime</td> <td>480s</td> <td>422s</td> </tr> </tbody> </table> <p> </p> <p><strong>Dataset contents</strong></p> <p>The two datasets are stored in the directories `1/` and `2/`. Each directory contains:</p> <ul> <li>`capture-X.pcap`: an anonymized version of the original capture</li> <li>`capture-X.csv`: content of each captured frame (timestamp, MAC address...) saved as a CSV file</li> </ul> <p>`anonymization.py` is the script which was used to remove identifiers.</p> <p>`README.md` contains the documentation about the datasets</p> <p> </p> <p><strong>License</strong></p> <p>Copyright 2022-2023 Benjamin Vermunicht, Beat Signer, Maxim Van de Wynckel, Vrije Universiteit Brussel</p> <p>Permission is hereby granted, free of charge, to any person obtaining a copy of this dataset and associated documentation files (the “Dataset”), to deal in the Dataset without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Dataset, and to permit persons to whom the Dataset is furnished to do so, subject to the following conditions:</p> <p>The above copyright notice and this permission notice shall be included in all copies or substantial portions that make use of the Dataset.</p> <p>THE DATASET IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE DATASET OR THE USE OR OTHER DEALINGS IN THE DATASET.</p>
Dataset for "An Accuracy Study of Emulation Daemons for IEEE 802.11 Networks"
<p>This is the dataset used in "An Accuracy Study of Emulation Daemons for IEEE 802.11 Networks" presented at the 48th IEEE Conference on Local Computer Networks (LCN), October 1-5, 2023, Daytona Beach, Florida, USA.</p> <p>`raw_results` contains all the raw results redacted from the experiment hosts, including log files.<br> The `tikz` files used to generate the figures presented in the paper can be found in `tex/figures`. Executing `make` in the `tex` directory generates the `pdf` plots in the `figures` folder.<br> The `figures` folder also contains pre-processed results from the raw data set.</p>
Dataset of the journal article "Spatial Reuse in IEEE 802.11ax WLANs"
<p>This dataset contains both the inputs and the outputs from the conference article "Spatial Reuse in IEEE 802.11ax WLANs", authored by Francesc Wilhelmi, Sergio Barrachina, Cristina Cano, Ioannis Selinis and Boris Bellalta. The article has been sent to IEEE Surveys & Tutorials.</p> <p>Regarding the Komondor's input, we provide the files used in the Komondor simulator, as well as the execution scripts, for generating the results presented in the paper. We find "toy" and "random" scenarios, which cover different parts of the paper. In the random case, we have 39,800 different scenarios, which correspond to 4 network densities, 3 strategies on applying SR, 3 traffic loads, 50 deployments, and 21 different OBSS/PD values. More details are provided in the article. </p> <p>Apart from the Komondor's input, we also provide other Matlab files used in the context of the SFCTMN analytical model (refer to <a href="https://github.com/sergiobarra/SFCTMN/releases/tag/v1.0_11ax_SR">https://github.com/sergiobarra/SFCTMN/releases/tag/v1.0_11ax_SR</a>). </p> <p>Contact information: francisco.wilhelmi@upf.edu</p>
[ITU-T AI Challenge] Input/Output of project "Improving the capacity of IEEE 802.11 WLANs through Machine Learning"
<p>This data set will be used by participants of the ITU-T AI Challenge. </p> <p>The data set contains:</p> <ul> <li>Input files: contain information such as nodes labels, nodes position, or channels used. These files have been used to simulate the behavior of random WLAN deployments under different channel bonding conditions. </li> <li>Output files: contain the output of the simulations - throughput per STA, RSSI that each STA receives from its AP, interference map from APs' point of view, average SINR experienced by each device during packet receptions.</li> </ul> <p>More details can be found on the official website of the challenge: <a href="https://www.upf.edu/web/wnrg/ai_challenge">https://www.upf.edu/web/wnrg/ai_challenge</a></p> <p><strong>[Update - 28 July 2020] </strong>A script (<a href="https://zenodo.org/api/files/88053224-d3a9-417e-b034-f08c763069ac/script_process_dataset.sh?versionId=2817eabd-ab9e-496a-a7d6-f67d227c51bf">script_process_dataset.sh</a>) has been added to process the output files. In particular, the results of each deployment are separated into different files. Besides, different files are created according to the type of label/feature (throughput, airtime, RSSI map, and interference list).</p> <p><strong>[Update - 22 September 2020] </strong>A new feature has been added to all the files in the data set. In particular, we have added the average Signal-to-Interference-plus-Noise Ration (SINR) experienced by each STA during packet receptions (including data and control packets). The SINR values in APs are marked as Inf because we focus on downlink transmissions only.</p> <p><strong>[Update - 30 September 2020] </strong>The test data set has been released, which corresponds to the simulations of a set of deployments with different characteristics. Input node files are contained in <a href="https://zenodo.org/api/files/88053224-d3a9-417e-b034-f08c763069ac/input_node_files_test.zip">input_node_files_test.zip</a>, while <a href="https://zenodo.org/api/files/88053224-d3a9-417e-b034-f08c763069ac/output_simulator_test.zip">output_simulator_test.zip</a> includes the output generated by the simulator. The label (i.e., the throughput) of the test data set will not be included in this repository until the next update (estimated date: 15 October 2020).</p> <p><strong>[Update - 19 October 2020] </strong>After participants have submitted their solutions, we provide the entire test data set, including the actual throughput obtained by each AP and STA in the test deployments.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.