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.
31
datasets available to search
ShareScore release 0.9.0
Dataset results
31 results for “wireless networks”
Wireless Sensor Network Deployments (2013-2017)
<p><strong>Wireless Sensor Network Deployments (2013-2017)</strong></p> <p>This is an open data repositiory.</p> <p>It is concerned with systematically reviewing scientific publications containing actual Wireless Sensor Network deployments in five year span from 2013 to 2017.</p> <p><strong><em>Identification</em></strong></p> <p>Articles were first searched for in SCOPUS and Web of Science databases on 2018-06-12 using these queries/settings:</p> <p>SCOPUS</p> <p>Query: KEY({sensor network} OR {sensor networks}) AND TITLE-ABS-KEY(test* OR experiment* OR deploy*) AND NOT TITLE-ABS-KEY(review) AND NOT TITLE-ABS-KEY(simulat*) AND ( LIMIT-TO ( PUBYEAR,2017 ) OR LIMIT-TO ( PUBYEAR,2016 ) OR LIMIT-TO ( PUBYEAR,2015 ) OR LIMIT-TO ( PUBYEAR,2014 ) OR LIMIT-TO ( PUBYEAR,2013 ) )</p> <p>Raw results: 11536 articles</p> <p>De-duplicated results: 11374 articles</p> <p>Contained 4814 articles not found in Web of Science</p> <p>Web Of Science</p> <p>Querry: TS = ("sensor network" OR "sensor networks") AND TS = (test* OR experiment* OR deploy*) NOT TI="review" NOT TS=simulat*</p> <p>Additional query parameters: Indexes=SCI-EXPANDED, SSCI, A&HCI, CPCI-S, CPCI-SSH, BKCI-S, BKCI-SSH, ESCI, CCR-EXPANDED, IC Timespan=2013-2017</p> <p>Raw results: 10204 articles</p> <p>De-duplicated results: 10196</p> <p>Contained 3636 articles not found in SCOPUS</p> <p>Final results</p> <p>When article results were merged from both databases finally 15010 articles were identified as possible candiates. Of those 6560 were found in both databases.</p> <p><em><strong>Screening</strong></em></p> <p>Data was exported as bibtex files and imported in Mendeley software for screening.</p> <p>4910 articles were left after the screening phase</p> <p><em><strong>Eligibility check</strong></em></p> <p>Then all screened included articles were checked for eligibility and 3017 eligible articles were identified.</p> <p><em><strong>Data extraction</strong></em></p> <p>In these articles 3059 wireless sensor network deployments were identified and codified data extracted from them.</p> <p><em><strong>Timeline</strong></em></p> <p>This data analysis took total time (including validation and error checking) from 2018-06-12 till 2020-05-29, after which the data was prepared for publiching till 2020-07-02.</p>
MeshDapp: Blockchain-enabled Payment System for Wireless Mesh Networks - Dataset
<p>The MeshDapp dataset includes data from the MeshDapp project - Fed4Fire+ Open Call 9 winner:</p> <p>Data includes: Network Measurement from the CityLab - Antwerp testbed and IRIS (TCD) testbed. </p> <p>MeshDapp Paper:https://mvdsi.seeu.edu.mk/mselimi/papers/DAPPS20ms.pdf </p>
SIMBED - Offline Real-World Wireless Networking Experimentation using ns-3
<p>R&D in wireless networking typically depends on experimentation to make realistic evaluations, since simulation is inherently a simplification of the real-world. However, experimentation is limited in aspects where simulation excels, such as repeatability and reproducibility.</p> <p>Real wireless experiments are hardly repeatable. Given the same input they can produce very different output results, since wireless communications are influenced by external random phenomena such as noise, interference, and multipath. Real experiments are also difficult to reproduce: either the original community testbed is unavailable – offline or running other experiments – or the custom testbed used is inaccessible.</p> <p>Fed4FIRE+ wireless testbeds such as w-iLab.t and NITOS, although deployed in controlled environments, do not fully address the problem. The CONCRETE tool used in such testbeds assures the repeatability and reproducibility of experiments, but ignores executions whose results are also representative of the system operation and often reveal unpredicted behaviour that must be understood.</p> <p>What if we could make any wireless experiment repeatable and reproducible under the same exact conditions? What if we could share the same Fed4FIRE+ testbed execution conditions among an "infinite" number of users? What if we could run wireless experiments faster than in real time?</p> <p>INESC TEC has been developing the Offline Experimentation (OE) approach that combines the best of simulation and experimentation to achieve the above-mentioned goals. By relying on Network Simulator 3 (ns-3) and its good simulation capabilities from the MAC to the application layer, we have been exploring how ns-3 can be used to replicate real-world wireless experiments using real traces containing 1) position of nodes and 2) the quality of each radio link.</p> <p>The <strong>SIMBED </strong>project aimed at running a set of wireless experiments on top of the controlled environments of w-ilab.t and NITOS Fed4FIRE+ testbeds to further validate the OE approach. For that purpose, we configured different fixed and mobile experimental scenarios, representative of Wi-Fi range of operation, and measured the attained network performance using metrics such as throughput and Round-Trip Time (RTT). Then, we repeated each experiment using, both, Pure Simulation (PS) and OE approaches based on ns-3, also measuring the network performance for the same set of executions of experiments for all the different scenarios.</p> <p>By comparing the performance metrics of each real experiment with its PS and OE counterparts, we were able to measure the relative error of each simulation approach relatively to the real experiments, as well as the accuracy gains introduced by the OE approach when compared to the PS traditional alternative. The main results show that it is possible to repeat and reproduce real experiments in ns-3, using the OE approach, achieving closer to real performance than using the PS approach. For all the experiments performed in SIMBED, using the OE approach resulted in an average accuracy gain of 59% when comparing to the PS approach. </p> <p>These results were important for validating a PhD thesis contribution related to the OE approach, as well as for producing two conference papers and one journal paper. The SIMBED results increased our confidence on the accuracy of the OE approach and are envisioned to foster the adoption of the OE approach by the networking community, in complement to the use of real experimentation.</p> <p> </p> <p>The following dataset presents the results of the SIMBED project, organized in different folders, for each subset of experiments carried on:</p> <ul> <li><strong><em>SubExp#1: </em></strong><em>Static point-to-point Wi-Fi communications using auto-rate (Minstrel) </em> <ul> <li><strong><em>SubExp#1.1:</em></strong><em> Using w-iLab.2 (medium to high SNR scenarios)</em></li> <li><strong><em>SubExp#1.2:</em></strong><em> Using w-iLab.2 (low SNR scenarios)</em></li> <li><strong><em>SubExp#1.3:</em></strong><em> Using NITOS</em></li> <li><strong><em>SubExp#1.4:</em></strong><em> Using w-iLab.1 (datacenter room)</em></li> </ul> </li> <li><strong><em>SubExp#2: </em></strong><em>Static point-to-point Wi-Fi communications using fixed</em> rate</li> <li><strong><em>SubExp#3: </em></strong><em>Mobile point-to-point Wi-Fi communications using auto-rate (Minstrel)</em></li> <li><strong><em>SubExp#4: </em></strong><em>Static multiple access Wi-Fi communications using auto-rate (Minstrel) </em> <ul> <li><strong><em>SubExp#4.1:</em></strong><em> Using w-iLab.2 (bidirectional) (medium to high SNR scenarios)</em></li> <li><strong><em>SubExp#4.2:</em></strong><em> Using w-iLab.2 (bidirectional) (low SNR scenarios)</em></li> <li><strong><em>SubExp#4.3:</em></strong><em> Using NITOS (bidirectional)</em></li> <li><strong><em>SubExp#4.4:</em></strong><em> Using w-iLab.1 (bidirectional)</em></li> <li><strong><em>SubExp#4.5:</em></strong><em> Using NITOS (2 STAs)</em></li> <li><strong><em>SubExp#4.6:</em></strong><em> Using w-iLab.2 (2 STAs)</em></li> </ul> </li> <li><strong><em>SubExpExample</em></strong>: contains raw experimental logs, parsed data and simulation results, to show how data extracted from the nodes is processed to be compatible with the OE approach and comparable with OE and PS simulation results.</li> </ul> <p>Each experiment has an individual folder, named according to the date and time of the experiment and the nodes used. Inside, there’s a folder for the <strong>parsed</strong> experimental results, which contains</p> <p>This folder contains the details and parsed logs of the experiment, as follows:</p> <ul> <li><em>date_time</em><strong>.cfg </strong>– configuration details of the experiment</li> <li><em>date_time_NodeID<sup><a href="#_ftn1"><strong>[1]</strong></a></sup>_SenderID<sup><a href="#_ftn2"><strong>[2]</strong></a></sup>_ReceiverID<sup><a href="#_ftn3"><strong>[3]</strong></a></sup>_FlowType<sup><a href="#_ftn4"><strong>[4]</strong></a></sup>_Params<sup><a href="#_ftn5"><strong>[5]</strong></a></sup></em><strong>.snr </strong>– logs of the Signal/Noise ratio (1 file per node/flow) </li> <li><em>date_time_NodeID_SenderID_ReceiverID_FlowType_Params</em><strong>.stats</strong> – logs of the packets received (1 file per node/flow) </li> <li><em>NodeID</em><strong>.</strong><strong>waypoints</strong> – coordinates of the static nodes</li> <li><em>date_time_MobileNodeID</em><strong>.</strong><strong>waypoints</strong> – waypoints of the mobile nodes (when applicable)</li> </ul> <p>The experiment’s folder also contains a folder for the simulations <strong>output</strong> with the simulations statistics files, for the multiple simulations approaches considered, as follows:</p> <ul> <li><em>date_time_NodeID_SenderID_ReceiverID_FlowType_Params</em>.<strong>simstats </strong>– logs of the packets received (simulation)</li> </ul> <p> </p> <p><sub><a href="#_ftnref1">[1]</a> ID of the node Logging node</sub></p> <p><sub><a href="#_ftnref2">[2]</a> ID of the Sender node</sub></p> <p><sub><a href="#_ftnref3">[3]</a> ID of the Receiver node</sub></p> <p><sub><a href="#_ftnref4">[4]</a> Flow type: Unidirectional, Bidirectional or Unidirectional with Multiple Access</sub></p> <p><sub><a href="#_ftnref5">[5]</a> Configurable parameters: Sender/Receiver Transmission Power and Data Rate (when applicable)</sub></p>
Data and code related to the article "Characterization of the Log-normal Model for Received Signal Strength Measurements in Real Wireless Sensor Networks"
<p>This upload contains the data and code related to the article "Characterization of the Log-normal Model for Received Signal Strength Measurements in Real Wireless Sensor Networks", (D.O.I: <a href="https://doi.org/10.3390/jsan9010012">10.3390/jsan9010012</a>) published in the the special issue on "Localization in Wireless Sensor Networks" of the <a href="https://www.mdpi.com/journal/jsan"><em>Journal of Sensor and Actuator Networks</em></a> (ISSN 2224-2708).</p> <p>The data and code included allows to replicate the results of the article.</p>
Dataset for Anomaly Detection in a Production Wireless Mesh Community Network
<p>CSV dataset generated gathering data from a production wireless mesh community network. Data is gathered every 5 minutes during the interval 2021-04-13 00:00:00 to 2021-04-16 00:00:00. During the interval 2021-04-14 02:00:00 2021-04-14 17:50:00 (both included) there is the failure of a gateway in the mesh (nodeid 24). </p> <p>Live mesh network monitoring link: <a href="http://dsg.ac.upc.edu/qmpsu">http://dsg.ac.upc.edu/qmpsu</a></p> <p>The dataset consists of single gzip compressed CSV file. The first line of the file is a header describing the features. The first column is a GMT timestamp of the sample in the format as "2021-03-16 00:00:00". The rest of the columns provide the comma-separated values of the features collected from each node in the corresponding capture.</p> <p>A suffix with the nodeid is added to each feature. For instance, the feature having the number of processes of node with nodeid 24 is named as "processes-24". In total, 63 different nodes showed up during the samples, each being assigned a different nodeid.</p> <p><br> Features are of two types: (i) absolute values, for instance, the CPU 1-minute load average, and (ii) counters that are monotonically increased, for instance the number of transmitted packets. We have converted counter-type kernel variables to rates, by dividing the difference between two consecutive samples, over the difference of the corresponding timestamps in seconds, as shown in the following pseudo-code:<br> feature.rate are columns computed from feature as<br> feature.rate <- (feature[2:n]-feature[1:(n-1)])/(epoch[2:n]-epoch[1:(n-1)])<br> feature.rate <- feature.rate[feature.rate >= 0] # discard samples where the counter is restarted<br> where n is the number of samples</p> <p><strong>features</strong><br> - processes number of processes<br> - loadavg.m1 1 minute load average<br> - softirq.rate servicing softirqs<br> - iowait.rate waiting for I/O to complete<br> - intr.rate <br> - system.rate processes executing in kernel mode<br> - idle.rate twiddling thumbs<br> - user.rate normal processes executing in user mode<br> - irq.rate servicing interrupts<br> - ctxt.rate total number of context switches across all CPUs<br> - nice.rate niced processes executing in user mode<br> - nr_slab_unreclaimable The part of the Slab that can't be reclaimed under memory pressure<br> - nr_anon_pages anonymous memory pages<br> - swap_cache Memory that once was swapped out, is swapped back in but still also is in the swapfile<br> - page_tables Memory used to map between virtual and physical memory addresses<br> - swap <br> - eth.txe.rate tx errors over all ethernet interfaces<br> - eth.rxe.rate rx errors over all ethernet interfaces<br> - eth.txb.rate tx bytes over all ethernet interfaces<br> - eth.rxb.rate rx bytes over all ethernet interfaces<br> - eth.txp.rate tx packets over all ethernet interfaces<br> - eth.rxp.rate rx packets over all ethernet interfaces<br> - wifi.txe.rate tx errors over all wireless interfaces<br> - wifi.rxe.rate rx errors over all wireless interfaces<br> - wifi.txb.rate tx bytes over all wireless interfaces<br> - wifi.rxb.rate rx bytes over all wireless interfaces<br> - wifi.txp.rate tx packets over all wireless interfaces<br> - wifi.rxp.rate rx packets over all wireless interfaces<br> - txb.rate tx bytes over all ethernet and wifi interfaces<br> - txp.rate tx packets over all ethernet and wifi interfaces<br> - rxb.rate rx bytes over all ethernet and wifi interfaces<br> - rxp.rate rx packets over all ethernet and wifi interfaces<br> - sum.xb.rate tx+rx bytes over all ethernet and wifi interfaces<br> - sum.xp.rate tx+rx packets over all ethernet and wifi interfaces<br> - diff.xb.rate tx-rx bytes over all ethernet and wifi interfaces<br> - diff.xp.rate tx-rx packets over all ethernet and wifi interfaces</p>
Synthetic dataset for mobile wireless networks with SUMO -- aggregated traces
<p>Aggregated dataset from a published wireless dataset generator base in SUMO mobility model. </p> <p> </p> <p>This work was supported by national funds through Fundação para a Ciência e a Tecnologia (FCT) with reference UIDB/50021/2020 and SFRH/BD/132053/2017.</p>
Snow depth, air temperature, humidity, soil moisture and temperature, and solar radiation data from the basin-scale wireless-sensor network in American River Hydrologic Observatory (ARHO)
Open the record for dataset details and reuse information.
SIMBED+ - Replicable Real Wireless Networking Experiments using ns-3
<p>Wireless networking R&D depends on experimentation to make realistic evaluations of networking solutions, as simulation is inherently a simplification of the real-world. However, despite more realistic, experimentation is limited in aspects where simulation excels, such as repeatability and reproducibility.</p> <p>Real wireless experiments may be difficult to repeat. For the same input they can produce very different output results, since wireless communications are influenced by external phenomena such as noise, interference, and multipath. Even if repeatable, experiments may still be difficult to reproduce. Namely, other researchers may be unable to reproduce an experiment and confirm previous experimental results right away, because either the testbed is unavailable – offline or running other experiments when using a community testbed –, or inaccessible at all when a custom testbed was originally used.</p> <p>Fed4FIRE+ testbeds such as w-iLab.t, although operating in controlled environment, do not fully address the problem. This is even more evident in testbeds running in non-controlled and very dynamic environments, such as CityLab, where they may suffer from radio interference and competition from existing networks sharing the same radio spectrum.</p> <p>What if we could make any wireless experiment repeatable and reproducible? What if we could share the same Fed4FIRE+ testbed execution conditions among an "infinite" number of users? What if we could run wireless experiments faster than in real time?</p> <p>INESC TEC has developed the Offline Experimentation (OE) approach that combines the best of simulation and experimentation to achieve the above-mentioned goals. By relying on Network Simulator 3 (ns-3) and its good simulation capabilities from the MAC to the Application layer, we have been exploring how ns-3 can be used to replicate real-world wireless experiments using real traces containing 1) position of nodes and 2) the quality of each radio link.</p> <p>The previous <strong>SIMBED </strong>project validated the OE approach for controlled environments and helped identifying some of its limitations. The OE approach was then improved to support experiments using Multiple-In-Multiple-Out (MIMO) and shared radio spectrum with concurrent networks. To further validate the improved OE approach, the <strong>SIMBED+</strong> project aimed at running a set of experiments on top of the controlled and non-controlled environments of w-iLab.t and CityLab Fed4FIRE+ testbeds. For that purpose, we configured different fixed experimental scenarios, representative of Wi-Fi range of operation, subjected to controlled and non-controlled interference from concurrent experiments. For each experiment the achieved network throughput was measured. Then, we repeated each experiment using, both, Pure Simulation (PS) and OE approaches (now with MIMO and channel occupancy information) based on ns-3, also measuring the network throughput for the same set of experiments.</p> <p>To compare the network throughput of the real experiments with their PS and OE counterparts, Cumulative Distribution Function (CDF) curves were used, plotting all 1-second average throughput samples. For all the experiments performed in SIMBED+, using the improved OE approach resulted in network throughput considerably closer to real than using the PS approach. This is even more evident in non-controlled environments using MIMO and shared radio spectrum.</p> <p>These results were important for further validating the OE approach, producing two conference papers and one journal paper. The SIMBED+ results increased our confidence on the OE approach ability of reproducing past experiments, and are envisioned to foster the adoption of the OE approach by the networking community, in complement to the use of real experimentation.</p> <p> </p> <p>The following dataset presents the results of the SIMBED+ project, organized in different folders, for each subset of experiments carried on:</p> <ul> <li><strong><em>SubExp#1: </em></strong><em>Trace-based PHY rate with SISO support (802.11a, BW 20 MHz) </em></li> <li><strong><em>SubExp#2: </em></strong><em>Trace-based PHY rate with MIMO support (802.11n/ac, BW 20/40 MHz, MIMO 3x3) </em> <ul> <li><strong><em>SubExp#2.1: </em></strong><em>IEEE 802.</em><em>11n, 20 MHz, MIMO 3x3</em></li> <li><strong><em>SubExp#2.2: </em></strong><em>IEEE 802.</em><em>11n, 40 MHz, MIMO 3x3</em></li> <li><strong><em>SubExp#2.3: </em></strong><em>IEEE 802.</em><em>11ac, 40 MHz, MIMO 3x3</em></li> </ul> </li> <li><strong><em>SubExp#3: </em></strong><em>Shared radio spectrum support (occupancy at the sender)</em></li> <li><strong><em>SubExp#4: </em></strong><em>Shared radio spectrum support (occupancy at the receiver)</em></li> <li><strong><em>SubExp#5:</em></strong> <em>Trace-based PHY rate, MIMO and shared radio spectrum support</em></li> </ul> <p>Each experiment has an individual folder, named according to the date and time of the experiment and the nodes used. Inside, there’s a folder for the <strong>parsed</strong> experimental results, which contains</p> <p>This folder contains the details and parsed logs of the experiment, as follows:</p> <ul> <li><em>date_time</em><strong>.cfg </strong>– configuration details of the experiment</li> <li><em>date_time_NodeID<sup><a href="#_ftn1"><strong>[1]</strong></a></sup>_SenderID<sup><a href="#_ftn2"><strong>[2]</strong></a></sup>_ReceiverID<sup><a href="#_ftn3"><strong>[3]</strong></a></sup>_FlowType<sup><a href="#_ftn4"><strong>[4]</strong></a></sup>_Params<sup><a href="#_ftn5"><strong>[5]</strong></a></sup></em><strong>.snr </strong>– logs of the Signal/Noise ratio (1 file per node/flow) </li> <li><em>date_time_NodeID_SenderID_ReceiverID_FlowType_Params</em><strong>.stats</strong> – logs of the packets received (1 file per node/flow) </li> <li><em>NodeID</em><strong>.</strong><strong>waypoints</strong> – coordinates of the static nodes</li> <li><em>date_time_MobileNodeID</em><strong>.</strong><strong>waypoints</strong> – waypoints of the mobile nodes (when applicable)</li> </ul> <p>The experiment’s folder also contains a folder for the simulations <strong>output</strong> with the simulations statistics files, for the multiple simulations approaches considered, as follows:</p> <ul> <li><em>date_time_NodeID_SenderID_ReceiverID_FlowType_Params</em>.<strong>simstats </strong>– logs of the packets received (simulation)</li> </ul> <p> </p> <p><sub><a href="#_ftnref1">[1]</a> ID of the node Logging node</sub></p> <p><sub><a href="#_ftnref2">[2]</a> ID of the Sender node</sub></p> <p><sub><a href="#_ftnref3">[3]</a> ID of the Receiver node</sub></p> <p><sub><a href="#_ftnref4">[4]</a> Flow type: Unidirectional, Bidirectional or Unidirectional with Multiple Access</sub></p> <p><sub><a href="#_ftnref5">[5]</a> Configurable parameters: Sender/Receiver Transmission Power and Data Rate (when applicable)</sub></p>
Data for Secure communication in IP-based wireless sensor networks via a trusted gateway publication
<p>This archive file contains the raw data obtained from Contiki sensor nodes during Cooja experiments in the folders e2e, terminate, terminate_1st and plaintext.</p> <p>The archive accompagnies the IEEE ISSNIP 2015 publication titled "Secure communication in IP-based wireless sensor networks via a trusted gateway" by Floris Van den Abeele, Tom Vandewinckele, Jeroen Hoebeke, Ingrid Moerman and Piet Demeester.</p> <p><br /> Also included is the data_parser python script that converts the raw data into CSV files that are parseable by R. The script contains the definitions of the contents of the raw data files.<br /> Finally, the R scripts that use the CSV files to generate the plots from the paper are also included.</p>
On Synchronization of Wireless Acoustic Sensor Networks in the Presence of Time-varying Sampling Rate Offsets and Speaker Changes
<p>We present an open-source database for evaluation of time synchronization algorithms for wireless acoustic sensor networks . More Information and examples on how to use the database can be found on our GitHub page: <a href="https://github.com/fgnt/paderwasn">https://github.com/fgnt/paderwasn</a></p>
Available Wireless Sensor Network and Internet of Things testbed facilities: dataset
<p>In this data set, we present data collected for the purpose of carrying out a systematic review of the available Wireless Sensor Network and Internet of Things testbed facilities. The data was collected through multiple stages and in each stage the pre-defined criteria were applied. We provide a dataset describing the hardware and software aspects of Wireless Sensor Network and Internet of Things testbed facilities available in the market and scientific community. The data were gathered through an extensive systematic review process of scientific articles published between the years 2011 and 2021. The review aims to obtain good quality data for people who are actively researching the Internet of Things facilities or anyone who is interested in that field.</p>
Write-only File System for Privacy-aware Wireless Sensor Networks Evaluation Dataset
<p>Evaluation dataset for the paper <strong>"WoFS: A Write-only File System for Privacy-aware Wireless Sensor Networks"</strong> published at the <em>49th IEEE Conference on Local Computer Networks (2024)</em></p>
Results of "Collaborative Spatial Reuse in Wireless Networks via Selfish Multi-Armed Bandits"
<p>This dataset contains the results obtained for the article "Collaborative Spatial Reuse in Wireless Networks via Selfish Multi-Armed Bandits", authored by Francesc Wilhelmi, Cristina Cano, Gergely Neu, Boris Bellalta, Anders Jonsson and Sergio Barrachina. The article has been sent to Elsevier Ad-hoc Networks.</p> <p>The content of this dataset has been obtained by means of the code allocated in the following GitHub repository: <a href="https://github.com/fwilhelmi/collaborative_sr_in_wns_via_selfish_mabs">https://github.com/fwilhelmi/collaborative_sr_in_wns_via_selfish_mabs</a></p> <p>Contact information: francisco.wilhelmi@upf.edu</p>
Reliable Many-to-Many Routing in Wireless Sensor Networks Using Ant Colony Optimisation
<p>Results files for testing of ACO protocol for many to many routing in wireless sensor networks. </p>
Weighted Link Schedules in 100-node Fixed Topology Wireless Networks
<p>This is a data repo for the data samples used for learning the link scheduling in a fixed-topology placed networks. This data set contains samples for 100-node networks, and the scheduling decisions are made from delayed column generation (DCG) algorithm.</p>
Weighted Link Schedules in sub-100 node Random Topology Wireless Networks
<p>This is a data repo for the data samples used for learning the link scheduling in a randomly placed networks. This data set contains samples for sub 100-node networks, and the scheduling decisions are made from delayed column generation (DCG) algorithm.</p>
Weighted Link Schedules in sub-100 node Fixed Topology Wireless Networks
<p>This data repo contains the link schedules in a multi-hop wireless networks that aims to maximize the weighted throughput. Each instance is represented by a numpy data file that contains the necessary data fields to reconstruct the original problem instance.</p> <p> </p> <p>Note: 100_7_new.tar.xz should be in the repo https://zenodo.org/deposit/7671940.</p>
Instances of the problem of Designing a Multi-sink Clustered Wireless Sensor Network.
Open the record for dataset details and reuse information.
Measuring Network Latency from a Wireless ISP: Variations Within and Across Subnets - Dataset
<h1>Overview</h1> <p>This archive contains the data from a network latency measurement campaign conducted inside the wireless ISP JackRabbit Wireless between 2023-10-30 and 2023-12-01. The measurement setup and an analysis of the data is provided in the paper "Measuring Network Latency from a Wireless ISP: Variations Within and Across Subnets", accepted for the ACM Internet Measurement Conference 2024. </p> <p>Code for parsing the data and reproducing the plots can be found at <a href="https://github.com/simosund/Measuring-Network-Latency-from-a-Wireless-ISP.git">https://github.com/simosund/Measuring-Network-Latency-from-a-Wireless-ISP.git</a></p> <h2>Manifest</h2> <ul> <li><strong>The raw subfolder:</strong> contains the original data captured by epping from the measurement campaign. However, note that we have merged all subnet entries from the internal network into a single entry at each timepoint to avoid revealing details about the subnet structure on the internal network. Some internal subnet entries that only carry control traffic have also been removed. It is still possible to recreate all the results from the paper with this data.</li> <li><strong>The processed subfolder: </strong>This contains processed versions of the data that have been merged in a few different ways, allowing the results from the paper to be recreated quickly without having to parse all of the original data. <ul> <li><strong>subnets_stats_merged.json:</strong> The data from the entire measurement period have been merged into a single entry per subnet</li> <li><strong>{lan,wan}_per10s_stats_merged.json:</strong> All the internal or external data merged into a single entry per timepoint (10s).</li> <li><strong>top_100asn_stats_10min_json:</strong> The external data merged per ASN (for the 100 ASNs with the highest amount of downlink traffic during the measurement period) at a 10 minute resolution.</li> <li><strong>protocol_counters.hdf5: </strong>Counters for number of packets of each <a href="https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml">IP-protocol</a>. The most common protocols, such as TCP, UDP and ICMP are named, where less common ones are just numbered.</li> <li><strong>ecn_counters.hdf5:</strong> Counters of the four ECN-marks (Not-ECT, ECT(1), ECT(0) and CE).</li> </ul> </li> <li><strong>The overhead_measurements subfolder: </strong>CPU and network load measurements from a later period used to estimate the overhead of the epping tool. In the covered period, epping was running between the 19th of April and the 3rd of May. <ul> <li><strong>InfluxDB_CPU_20240413-20240513.csv:</strong> CSV with hourly CPU utilization per core on the DuT.</li> <li><strong>jackrabbit-shaper-per\_day-20240421-20240513.csv:</strong> CSV with network load metrics (throughput in bytes and packets) every 48 minutes.</li> <li><strong>proglistoutput_after_enabling_bpf_stats_24hr.txt:</strong> Output from <code>bpftool prog list</code> after enabling <code>sysctl -w kernel.bpf_stats_enabled=1</code>, containing run counts and cumulative runtime for all eBPF programs on the system.</li> </ul> </li> <li><strong>rrc14_20231115_ipasn.dat: </strong>Data from RIPE´s route collector RRC14 in the middle of the measurement campaign (2023-11-15), used to map subnets into ASNs.</li> <li><strong>asn.txt:</strong> RIPE's list of AS names (from <a href="https://ftp.ripe.net/ripe/asnames/asn.txt">https://ftp.ripe.net/ripe/asnames/asn.txt</a>), used to translate ASNs into AS names.</li> </ul> <h2>Data format for raw data</h2> <p>The raw data is organized into one subfolder per day, with each subfolder containing one compressed json-file per minute. All files have been included in a tar-archive.</p> <p>The JSON format in each file consists of a single list of entries. There are three types of entries.</p> <h3>Configuration entry</h3> <p>Each file starts with one configuration entry, containing the following fields:<br><br></p> <ul> <li><strong> timestamp:</strong> Unix timestamp in nanoseconds when entry was created</li> <li><strong>bins: </strong>The maximum number of bins in the histogram of a subnet entry. Always 250 in this dataset. Note that histograms may contain less bins as unused bins in the upper range are truncated.</li> <li><strong>bin_width_ns:</strong> The width of the bins in nanoseconds. Always 4000000 (4ms) in this dataset.</li> <li><strong>aggregation_interval_ns: </strong>How often the aggregated stats are reported in nanoseconds. Always 10000000000 (10s) in this dataset.</li> <li><strong>timeout_interval_ns: </strong>How long epping will keep a subnet entry around since it last saw traffic for it. Always 30000000000 (30s) in this dataset. Note that a subnet entry may only be deleted after its stats are reported, so no stats will be lost regardless of value.</li> <li><strong>ipv4_prefix_len:</strong> Subnet size to aggregate IPv4 traffic. Always 24 (/24) in this dataset.</li> <li><strong>ipv6_prefix_len: </strong>Subnet size to aggregate IPv6 traffic. Always /48 in this dataset.</li> </ul> <p>Example:</p> <pre><code>{<span>"timestamp"</span>: <span>1698661062033443066</span>, <span>"bins"</span>: <span>250</span>, <span>"bin_width_ns"</span>: <span>4000000</span>, <span>"aggregation_interval_ns"</span>: <span>10000000000</span>, <span>"timeout_interval_ns"</span>: <span>30000000000</span>, <span>"ipv4_prefix_len"</span>: <span>24</span>, <span>"ipv6_prefix_len"</span>: <span>48</span>}</code></pre> <h3><br>Subnet stats entry</h3> <p>The most common entry will be the subnet stats entry, which contains the aggregated stats for one /24 subnet (or /48 if IPv6) over a 10 second period. Each entry always contains the following fields:</p> <ul> <li><strong>timestamp:</strong> A unix timestamp in nanoseconds of when the entry were reported. The entry will thus contain the stats for the period [timestamp - 10s, timestamp].</li> <li><strong>ip_prefix:</strong> The subnet in standard IPv4 or IPv6 CIDR notation.</li> <li><strong>rx_stats</strong> and <strong>tx_stats:</strong> Packet and byte counts for packets received from/transmitted to the subnet. Note that <em>rx</em> and <em>tx</em> is from the perspective of the epping node, not the perspective of the subnet, so <em>rx</em> is packets epping has seen sent from the subnet, and <em>tx</em> is packets epping has seen sent towards the subnet. <ul> <li><strong>TCP_TS</strong>, <strong>TCP_noTS</strong> and <strong>other:</strong> Entries for TCP traffic that has TCP timestamps enabled, TCP traffic with TCP timestamps disabled, and non-TCP traffic, respectively. The entry will be omitted if there is no traffic of the relevant type. <ul> <li><strong>packets:</strong> Number of packets of the specific type</li> <li><strong>bytes:</strong> Sum of bytes in the observed packets, including headers (up to and including the 14-byte Ethernet header).</li> </ul> </li> </ul> </li> </ul> <p>Additionally, the following fields will be present if any RTT has been observed for the subnet. Note that the subnet will include RTTs for traffic going towards the subnet, i.e. SRC -> subnet -> SRC.</p> <ul> <li><strong>min_rtt:</strong> The minimum observed RTT in nanoseconds.</li> <li><strong>max_rtt:</strong> The maximum observed RTT in nanoseconds.</li> <li><strong>histogram:</strong>: A histogram with all observed RTTs. The bin width and maximum number of bins is specified by the configuration entry (always 4ms wide bins and max 250 bins in this dataset). Note that the histogram will truncate 0-bins after the last non-zero bin (e.g. if the maximum RTT is 7 ms, the histogram will only contain 2 bins).</li> <li><strong>count_rtt:</strong> The total number of RTTs observed (sum of histogram bin counts)</li> <li><strong>mean_rtt:</strong> The approximate mean RTT in nanoseconds.</li> <li><strong>median_rtt:</strong> The approximate median RTT in nanoseconds.</li> <li><strong>p95_rtt:</strong> The approximate 95th percentile of the RTTs in nanoseconds</li> </ul> <p>Note that <em>mean_rtt</em>, <em>median_rtt</em> and <em>p95_rtt</em> are all calculated from the histogram, assuming all RTTs are in the middle of the histogram bins, and will thus be +/- 2ms of the real value in this dataset.</p> <p>Example:</p> <div> <pre><code>{<span>"timestamp"</span>: <span>1698661072800129847</span>, <span>"ip_prefix"</span>: <span><span>"</span>100.64.0.0/24<span>"</span></span>, <span>"rx_stats"</span>: {<span>"TCP_TS"</span>: {<span>"packets"</span>: <span>64816</span>, <span>"bytes"</span>: <span>23063341</span>}, <span>"other"</span>: {<span>"packets"</span>: <span>39783</span>, <span>"bytes"</span>: <span>16074723</span>}, <span>"TCP_noTS"</span>: {<span>"packets"</span>: <span>8505</span>, <span>"bytes"</span>: <span>7403649</span>}}, <span>"tx_stats"</span>: {<span>"TCP_TS"</span>: {<span>"packets"</span>: <span>134424</span>, <span>"bytes"</span>: <span>175370347</span>}, <span>"other"</span>: {<span>"packets"</span>: <span>76267</span>, <span>"bytes"</span>: <span>86104300</span>}, <span>"TCP_noTS"</span>: {<span>"packets"</span>: <span>7946</span>, <span>"bytes"</span>: <span>5174210</span>}}, <span>"min_rtt"</span>: <span>50766</span>, <span>"max_rtt"</span>: <span>440315940</span>, <span>"histogram"</span>: [<span>622</span>, <span>596</span>, <span>835</span>, <span>1106</span>, <span>932</span>, <span>410</span>, <span>228</span>, <span>139</span>, <span>108</span>, <span>68</span>, <span>78</span>, <span>79</span>, <span>73</span>, <span>63</span>, <span>49</span>, <span>35</span>, <span>22</span>, <span>33</span>, <span>31</span>, <span>24</span>, <span>21</span>, <span>18</span>, <span>23</span>, <span>15</span>, <span>20</span>, <span>20</span>, <span>37</span>, <span>35</span>, <span>96</span>, <span>113</span>, <span>95</span>, <span>80</span>, <span>36</span>, <span>22</span>, <span>24</span>, <span>27</span>, <span>17</span>, <span>31</span>, <span>9</span>, <span>9</span>, <span>14</span>, <span>18</span>, <span>10</span>, <span>21</span>, <span>22</span>, <span>21</span>, <span>22</span>, <span>25</span>, <span>8</span>, <span>9</span>, <span>16</span>, <span>8</span>, <span>12</span>, <span>9</span>, <span>7</span>, <span>5</span>, <span>6</span>, <span>6</span>, <span>3</span>, <span>4</span>, <span>4</span>, <span>2</span>, <span>2</span>, <span>1</span>, <span>1</span>, <span>3</span>, <span>3</span>, <span>1</span>, <span>0</span>, <span>3</span>, <span>2</span>, <span>0</span>, <span>1</span>, <span>1</span>, <span>1</span>, <span>1</span>, <span>2</span>, <span>2</span>, <span>1</span>, <span>2</span>, <span>1</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>1</span>, <span>2</span>, <span>0</span>, <span>1</span>, <span>1</span>, <span>0</span>, <span>0</span>, <span>1</span>, <span>0</span>, <span>1</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>1</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>0</span>, <span>1</span>], <span>"count_rtt"</span>: <span>6568</span>, <span>"mean_rtt"</span>: <span>37529232.64311815</span>, <span>"median_rtt"</span>: <span>18000000.0</span>, <span>"p95_rtt"</span>: <span>150000000.0</span>}</code></pre> </div> <div> <h3>Global counters entry</h3> <p>Each report interval will also contain one entry with global counters, with the following fields:</p> <ul> <li><strong>timestamp:</strong> Unix timestamp in nanoseconds of when the entry was reported. The entry will thus contain stats for the period [timestamp - 10s, timestamp].</li> <li><strong>protocol_counters:</strong> A set of fields with packet and byte counters for the <a href="https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml" rel="nofollow">protocols indicated in the IP-header</a>. The most common protocols will be named, specifically <strong>TCP</strong>, <strong>UDP</strong>, <strong>ICMP</strong>, <strong>ICMPv6</strong> and the special <strong>non-IP</strong> for non-IP packets. All other protocols will simply use the protocol number. Protocols for which no traffic has been observed are omitted. <ul> <li><strong>packets:</strong> The number of packets of the specific type</li> <li><strong>bytes:</strong> Sum of bytes in the observed packets, including headers (up to and including the 14-byte Ethernet header). Only the list of named protocols above will include this byte counter.</li> </ul> </li> <li><strong>ecn_counters:</strong> Counters for the four distinct ECN code points in the IP header. May contain the fields <strong>no_ECT</strong> (00), <strong>ECT1</strong> (01), <strong>ECT0</strong> (10) and <strong>CE</strong> (11).</li> </ul> </div> <p>Example:</p> <div> <pre><code>{<span>"timestamp"</span>: <span>1698661072848798575</span>, <span>"protocol_counters"</span>: {<span>"TCP"</span>: {<span>"packets"</span>: <span>249032</span>, <span>"bytes"</span>: <span>242282230</span>}, <span>"UDP"</span>: {<span>"packets"</span>: <span>119778</span>, <span>"bytes"</span>: <span>108251262</span>}, <span>"ICMP"</span>: {<span>"packets"</span>: <span>1523</span>, <span>"bytes"</span>: <span>445347</span>}, <span>"ICMPv6"</span>: {<span>"packets"</span>: <span>87</span>, <span>"bytes"</span>: <span>25031</span>}, <span>"41"</span>: {<span>"packets"</span>: <span>1</span>}, <span>"47"</span>: {<span>"packets"</span>: <span>251</span>}, <span>"89"</span>: {<span>"packets"</span>: <span>22</span>}}, <span>"ecn_counters"</span>: {<span>"no_ECT"</span>: <span>347980</span>, <span>"ECT1"</span>: <span>2</span>, <span>"ECT0"</span>: <span>22709</span>, <span>"CE"</span>: <span>3</span>}, <span>"errors"</span>: {}}</code></pre> </div>
New key management scheme lattice-based for wireless sensor networks
<p><span>The cluster structure can effectively reduce the cost of mutual authentication of sensor nodes, which is conducive to the expansion of the network, and can guarantee the security of authentication between sensor nodes even in the post-quantum era. The size of the lattice-based authentication proposed in this paper does not change much with the continuous improvement of the security level of the RSA algorithm. The size of the certificate is kept at a stable level, which is more suitable for encrypting large data at a high-security level.</span></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.