Find research datasets worth reusing

opencc-by-4.0Apr 2020View details →

VICINITY IoT Use Case Data Sets

<p>This repository contains Internet-of-Things (IoT) use case data sets from the VICINITY project. The use cases are described under https://vicinity2020.eu, where also the contributing companies are described in more detail. </p> <p>The use cases include: </p> <ul> <li>eHealth use case data by GNOMON/CERTH (anonymized)</li> <li>Smart parking, building control use case data by HITS, TINYM</li> <li>Energy management data set by ENERC</li> <li>Several other, smaller use cases with less data from open call winners. </li> </ul> <p>The data sets have also been the basis for the publications available for download under the same URL; the folder AAU gives additionally the data from AAU's publications. </p> <p> </p>

opencc-by-4.0Dec 2018View details →

Data used in paper "A comparative study of calibration methods for low-cost ozone sensors in IoT platforms"

<p>Data used in paper "A comparative study of calibration methods for low-cost ozone sensors in IoT platforms", submitted for publication. The data consists of: (i) raw data from three nodes with four MICS 2614 metal-oxide ozone sensors deployed in Spain, summer 2017, and (ii) raw data of five alphasense OX-B431 and NO2-B43F electro-chemical sensors, four deployed in Italy and one in Austria, summers 2017 and 2018. Moreover, we have added the calibrated data using four machine learning methods: Multiple Linear Regression (MLR), K-Nearest Neighbors (KNN), Random Forest (RF) and Support Vector Regression (SVR).</p>

opencc-by-4.0Jul 2019View details →

Context-Aware Dataset: STS - South Tyrol Suggests IoT Mobile App Data

<p><strong>STS dataset </strong>was collected by a context-aware recommender system mobile app named as<strong> <a href="https://play.google.com/store/apps/details?id=it.unibz.sts.android&hl=en">"South Tyrol Suggests"</a></strong>. The app provides <strong>context-aware recommendations</strong> for attractions, events, public services, restaurants, and much more based on the rating preferences and personality factors of users.</p> <p><strong>Contextual</strong> <strong>variables</strong> includes </p> <ul> <li><strong>distance:</strong> far away, near by</li> <li><strong>time available:</strong> half day, one day, more than one day</li> <li><strong>temperature:</strong> burning, hot, warm, cool, cold, freezing</li> <li><strong>crowdedness:</strong> crowded, not crowded, empty</li> <li><strong>knowledge of surroundings:</strong> new to area, returning visitor, citizen of the area</li> <li><strong>season:</strong> spring, summer, autumn, winter</li> <li><strong>budget:</strong> budget traveler, price for quality, high spender</li> <li><strong>daytime:</strong> morning, noon, afternoon, evening, night</li> <li><strong>weather:</strong> clear sky, sunny, cloudy, rainy, thunderstorm, snowing</li> <li><strong>companion:</strong> alone, with friends/colleagues, with family, with girlfriend/boyfriend, with children</li> <li><strong>mood:</strong> happy, sad, active, lazy weekday: weekday, weekend</li> <li><strong>travel goal:</strong> visiting friends, business, religion, health care, social event, education, scenic/landscape, hedonistic/fun, activity/sport</li> <li><strong>means of transport:</strong> no transportation means, a bicycle, a car, public transport</li> </ul> <p>More details can be found here:</p> <p><em>Braunhofer, Matthias, Mehdi Elahi, and Francesco Ricci. <a href="https://www.researchgate.net/profile/Mehdi_Elahi2/publication/283502363_Techniques_for_cold-starting_context-aware_mobile_recommender_systems_for_tourism/links/56ccaa7608ae059e37507cc0.pdf">"<strong>Techniques for cold-starting context-aware mobile recommender systems for tourism</strong>."</a> Intelligenza Artificiale 8, no. 2 (2014): 129-143.</em></p>

opencc-by-4.0Aug 2019View details →

Data set: Industrial IoT-driven remote path planning

<p>This compressed file contains data from three different experiments during the  IIoT-REPLAN experimentation phase (Industrial IoT-drive remote path planning). IIoT-REPLAN was funded by an open call from the  H2020 Fed4FIRE+ project.</p> <p>Contents:</p> <p>A. astar.csv<br> This file contains the timestamp of each movement of the Robot and the uncertainty (d) at each specific time that Switch 1 was checked. The first two columns refer to seconds while the third one is a scalar value. The total duration of the experiment is 62.33 sec and the setup of this experiment is the real time application of the Astar Algorithm with the localization being based only on the sensor of the Robot</p> <p><br> B. Dijkstra.csv <br> In this experiment the full functionality of the switching system proposed in this work is highlighted. </p> <p>C. Cloud.csv<br> In this experiment the localization algorithm and the path planning algorithm are always executed on the cloud.</p> <p>In both B,C experiments the values of each column are explained inside the Dijkstra.csv </p> <p>Also, two pictures of singlie vision-based self localization are included. </p> <p>A more detailed exposition on all of the above can be found at <br> github link : https://github.com/maravger/alphabot-ppl</p>

opencc-by-4.0Aug 2021View details →

Indoor Wireless Deterministic Anycast Transmissions Data from the FIT IoT-Lab testbed

<p>This dataset contains the raw openwsn results generated by indoor experiments.</p> <p>The data was collected on the <a href="https://www.iot-lab.info">FIT IoT-Lab</a> platform, using the m3 motes with a AT86RF231 radio chip, on the Grenoble's site.</p> <p>We rely on the following workflow:</p> <ul> <li>a modified version of openwsn that implements anycast transmissions at the link layer (CCA branch, <a href="https://github.com/ftheoleyre/openwsn-fw/releases/tag/duocast-mswim21">https://github.com/ftheoleyre/openwsn-fw/releases/tag/duocast-mswim21</a>). The firmware is implemented in C, and is executed by the m3 motes;</li> <li>a modified version of openvisualizer (<a href="https://github.com/ftheoleyre/openvisualizer/releases/tag/mswim21">https://github.com/ftheoleyre/openvisualizer/releases/tag/mswim21</a>)</li> <li>a tool to process the dataset and compute the metrics: end-to-end reliability, number of transmissions, CCA events, etc. (<a href="https://github.com/ftheoleyre/openwsn-data/releases/tag/mswim21-duocast">https://github.com/ftheoleyre/openwsn-data/releases/tag/mswim21-duocast</a>)</li> </ul> <p> </p> <p> </p> <p> </p>

opencc-by-4.0Mar 2024View details →

Dragon_Pi: IoT Side-Channel Power Data Intrusion Detection Dataset and Unsupervised Convolutional Autoencoder for Intrusion Detection

<h2><strong>Dragon_Pi</strong></h2> <div> <div>For a more in depth description of the Dragon_Pi dataset, please consult the journal article of the same name:</div> <div>Lightbody <em>et al.</em>, Future Internet, 2024, <a href="https://doi.org/10.3390/fi16030088">https://doi.org/10.3390/fi16030088</a> - specifically Section 3.2: Dataset Overview.</div> <div> </div> </div> <p>Dragon_Pi is an intrusion detection dataset for IoT devices. In the field of IoT security there are few datasets, and those which do exist tend to focus solely on network traffic. The Dragon_Pi dataset seeks to provide not only more data for the field of IoT security, but also, data of a somewhat under-published type: linear time series power consumption data.</p> <p>Dragon_Pi is a fully labelled Intrusion Detection dataset for IoT devices. It is composed of both normal and under-attack power consumption data obtained from two separate testbeds - one using a DragonBoard 410c and the other a Raspberry Pi Model 3 - Hence the moniker <em>Dragon_Pi</em>. </p> <p>These testbeds were set up with predefined normal behavour as described in the attached publications. The normal linear time series power consumption  was sampled from the testbed under these normal conditions. Both testbeds were then attacked using some common attacks on IoT - the linear time series power consumption captured under these condtions as well. </p> <p>Specifically, the testbeds were subjected to the Port Scan (using Nmap), SSH Brute Force (using Hydra) and SYNFlood Denial of Service (using Hping3) attacks. These attacks were repeated to gain insight to what their signatures looked like and also how varying the tool settings effected the resultant signature.  A fourth type of scenario was also conducted on the testbeds - the "Capture the Flag" scenarios. In these files multiple attack types were used with a more specific target - to exfiltrate a hidden file from the testbeds.</p> <p>Each file has three hierarchical levels of annotation for <strong>each sample</strong> within:</p> <ol> <li>A simple "Normal or Anomaly" label for the specific sample</li> <li>A specifc attack type label e.g. "SSH Bruteforce", for the specific sample</li> <li>A specific tool setting for that attack e.g. "Hydra_T16", for the specific sample</li> </ol> <p>Users can decide for themselves what level of annotation they require for their specific task. </p> <p>Each file in the Dragon_Pi dataset is accompanied by its own legend file. This file explains the contents of the specific .csv file and the specific indexes of the events within.</p> <p>The Dragon_Pi dataset consists of approximately 67 files, as shown in Table 1. Compressed, the datset totals approximately 13GB. Completely decompressed the dataset is approximately 80GB ( 30GB Pi data, 50 GB Dragon data). </p> <div> </div> <div> <table> <tbody> <tr> <td>Label Type</td> <td>Specific Label </td> <td>Number of Files DragonBoard 410c</td> <td>Number of Files Raspberry Pi</td> </tr> <tr> <td>Normal </td> <td>Normal </td> <td>3 </td> <td>2</td> </tr> <tr> <td>Port Scan Attack </td> <td>Nmap_T5</td> <td>2</td> <td>1</td> </tr> <tr> <td> </td> <td>Nmap_T4</td> <td>1</td> <td>1</td> </tr> <tr> <td> </td> <td>Nmap_T3</td> <td>1</td> <td>1</td> </tr> <tr> <td> </td> <td>Nmap_T2</td> <td>1</td> <td>1</td> </tr> <tr> <td>SSH Brute Force</td> <td>Hydra_T32</td> <td>4</td> <td>2</td> </tr> <tr> <td> </td> <td>Hydra_T16</td> <td>16</td> <td>2</td> </tr> <tr> <td> </td> <td>Hydra_T3</td> <td>8</td> <td>2</td> </tr> <tr> <td> </td> <td>Hydra_T1</td> <td>5</td> <td>2</td> </tr> <tr> <td>SYNFlood DOS</td> <td>SYNFlood DOS</td> <td>1</td> <td>1</td> </tr> <tr> <td>Capture the Flag</td> <td>Misc Attacks</td> <td>3</td> <td>5</td> </tr> </tbody> </table> </div> <div>Table 1. Enumeration of the in the Dragon_Pi dataset.</div> <div> </div> <div> </div> <div>For a more in depth description of the Dragon_Pi dataset, please consult the journal article of the same name:</div> <div>Lightbody <em>et al.</em>, Future Internet, 2024, <a href="https://doi.org/10.3390/fi16030088">https://doi.org/10.3390/fi16030088</a> - specifically Section 3.2: Dataset Overview.</div> <div> </div> <div> </div> <div><strong>Publication of this dataset:</strong></div> <div> </div> <div>This dataset was published in Lightbody <em>et al.</em>, Future Internet, 2024, <a href="https://doi.org/10.3390/fi16030088">https://doi.org/10.3390/fi16030088</a>. Consult and cite this article for a more in depth dataset description, as well as an in depth review of first AI Intrusion Detection model trained on this dataset. </div> <div> </div> <div>See article Lightbody <em>et al.</em>, Future Internet, 2023, <a href="https://doi.org/10.3390/fi15050187">https://doi.org/10.3390/fi15050187</a> for a detailed investigation on  the attack signatures discovered while creating this dataset. This work was an inital investigation of the dataset and can serve as a part 1 to the Dragon_Pi paper.</div> <div> </div> <div> </div> <div><strong>How to cite this dataset in your work: </strong></div> <div> </div> <div>Please cite these two DOIs when publishing using this dataset:</div> <div> <ol> <li>Dragon_Pi release publication: <a href="https://doi.org/10.3390/fi16030088">https://doi.org/10.3390/fi16030088</a> (most important)</li> <li>Zenodo Dataset DOI: https://doi.org/10.5281/zenodo.10784947</li> </ol> </div> <div> <div> </div> </div> <p> </p>

opencc-by-4.0Sep 2022View details →

Data set: Quantifying the Accuracy of Collaborative IoT and Robot Sensing in Indoor Settings of Rigid Objects

<p>This is the data set accompanying the paper "Quantifying the Accuracy of Collaborative IoT and Robot Sensing in Indoor Settings of Rigid Objects" by Sune L. Sørensen and Mikkel Baun Kjærgaard. Please refer to the paper for a description of the hardware used to record the data and how it is recorded.</p> <p>It consists of the following files:</p> <p><em>IoT camera images</em>: RBG images, named img_aa_bbb_0.jpg, where aa is the setup ID, bb is the camera ID (101, 102, 103 or 104).</p> <p><em>Robot RGB images</em>: RBG images, named aa0.png where aa is the setup ID.</p> <p><em>Robot point clouds</em>: pcd-files, named aa0.pcd where aa is the setup ID.</p> <p>The transformation from the IoT coordinate system to the robot coordinate system is:</p> <p>robotTiot = np.array([[0.914428, 0.134934, -0.378832, 3.76475],</p> <p>[0.393661, -0.49845, 0.772371, 0.791051],</p> <p>[-0.0846896, -0.855336, -0.509056, 2.37154],</p> <p>[0.0, 0.0, 0.0, 1.0]])</p> <p>Example, tranforming a pose in IoT coordinates to robot coordinates: p_rob = robotTiot * p_iot</p>

opencc-by-4.0Jul 2019View details →

ANGEL experiment-Fed4FIREplus-IoT Data-INFOLYSiS

<p>IoT Data from SmartSantander captured in different stages from the execution of the experiment.</p> <p>Explanation of the files included in the archive follows:</p> <p>* 1_data_input_HTTP_COAP_MQTT_INFOLYSISvDPI: All the data inserted in the system. They are 3 different protocols (HTTP, COAP, MQTT) and they were seperated in vDPI in order to be forwarded to the mappers.<br> * 2.1_data_HTTP_HTTPmapVNF: Data that reached HTTP map VNF<br> * 2.2_data_COAP_COAPmapVNF: Data that reached COAP map VNF<br> * 2.3_data_MQTT_MQTTmapVNF: Data that reached MQTT map VNF<br> * 3_data_processed_UDP_INFOLYSISvGW: Interoperable data that reached vGW after the mappers all by UDP protocol.</p>

opencc-by-4.0Dec 2022View details →

Research data from the two surveys on IoT implementation for Article "User and Professional Aspects for Sustainable Computing Based on the Internet of Things in Europe"

<p>The file includes data collected through two online surveys linked to the article "User and Professional Aspects for Sustainable Computing Based on the nternet of Things in Europe" published by journal Sensors in January 2023:</p> <ul> <li>Survey on factors that inlfuence IoT Adoption by non technical users</li> <li>Survey on recommended profile focused on IoT implementation for two professional roles in the context of Smart Cities  (SC) projects: SC engineer and SC technician.</li> </ul>

opencc-by-4.0Feb 2023View details →

NB-IoT vs. LTE-M: Measurement Data of the Energy Consumption of LPWAN Technologies

<p><strong>NB-IoT vs. LTE-M: Measurement Data of the Energy Consumption of LPWAN Technologies</strong></p> <p>This dataset contains the raw energy measurements as well as R scripts to reproduce the energy consumption plot for the corresponding paper.</p> <p>Each .csv file contains a specific set of measurements and we provide a script to read, process and plot the contained data.</p> <p><strong>Figure 3</strong></p> <p>Mean energy consumption of the different phases for Authentication for NB-IoT and LTE-M.</p> <p>Due to the fact that the duration of <em>Idle Connected</em> in the measurement scripts was 30 seconds and 60 seconds for <em>Idle Not Connected</em>, the D-value and the mean power consumption are divided by 2.</p> <ul> <li>Data – energy_measurements_fig3.csv</li> <li>Code – fig3.R</li> </ul> <p><strong>Figure 4</strong></p> <p>Mean energy consumption of the different phases for Data Connection and Download for NB-IoT and LTE-M for 1KB of data in HTTP.</p> <p>The delay between the measurements for Figure 4 were all 30 seconds long, but the identified <em>Standby</em> and <em>Idle</em> phases have different lengths. Therefore, the <em>Idle</em> phase values for both access technologies have been normalized and calculated for 20 seconds each.</p> <ul> <li>Data – energy_measurements_fig4.csv</li> <li>Code – fig4.R</li> </ul> <p><strong>Figure 5</strong></p> <p>Mean energy consumption of the different phases for Data Connection and Download for HTTP and MQTT for 1KB of data in NB-IoT.</p> <p>In this scenario the delay between the measurements were different again. For <em>MQTT</em> the delay was 150 seconds and for <em>HTTP</em> 30 seconds. Therefore, the data during the <em>Idle</em> and <em>Standby</em> (only for <em>MQTT</em>) phase is normalized and calculated for 20 seconds and 10 seconds, respectively. During the <em>MQTT</em> <em>Idle</em> phase measurements, the device disconnects. This is not taken into account for the evaluation, which is why these energy values are discarded for this figure.</p> <ul> <li>Data – energy_measurements_fig5.csv</li> <li>Code – fig5.R</li> </ul> <p><strong>Contact</strong></p> <p>For questions or issues with this code, please contact Viktoria Vomhoff (viktoria.vomhoff@uni-wuerzburg.de) or any of the authors of the related publication.</p>

opencc-by-4.0Jun 2023View details →

CEP-based Activity Detection Services generated from IoT Data

<p>Data set accompanying the paper "Data-driven Generation of Services for IoT-based Online Activity Detection" submitted to the International Conference on Service-Oriented Computing (ICSOC) 2023.</p> <p>The data set has 6 automatically generated activity detection services (*.siddhi files) for 6 different types of activities executed by 6 different production stations in a smart factory. The *.siddhi files have to be deployed to and activated on an instance of the <a href="http://siddhi.io">Siddhi</a> complex event processing platform.</p> <p>The data set includes the corresponding low-level IoT data for each activity (<strong>activity signature</strong>) that was used to generate the activity detection service (*.txt files). It also includes a visual representation of the activity signature for each type of activity (*.png files). To test the activity detection services, the *.txt files have to be read line by line, each line has to be send as one MQTT message to an MQTT broker and topic that the activity detection service is also listening to (standard: localhost).</p>

opencc-by-4.0Apr 2020View details →

IoT device identification - Multi user data (No fading)

<p>Artificial multi user observations without added fading generated as described in the associated paper Section III.</p> <p>Frequency: 863-870 MHz (center 866,5 MHz)</p> <p>Sample Frequency: 10 MSPS</p> <p>Date of measurement: 15 November 2018</p> <p>Location: Connectivity Lab, Fredrik Bajers Vej 7C, Aalborg University, Denmark</p>

dryad36/100

Measurement data of the industrial IoT scenario

<p>In these measurements considered in this dataset, 15 measurement points are deployed in the scenario. They are sorted in two groups. Among line 1, all measurement points are LoS scenarios. Among line 2, measurement points 1, 2, 3, 4, 5,and 7 are LoS scenarios, and measurement points 6, 8, 9 are NLoS scenarios. Due to the limitation of the cable length, measurement data of line 2 locations 1-6 is collected at mmwave band. The heights of the Tx antenna and the Rx antenna are 2.05 m and 1.45 m, respectively. The bandwidth of the intermediate frequency filter of the adopted VNA is 2 kHz. Both the Tx and the Rx antennas are omnidirectional antennas. 200 snapshots are collect at each Rx location. In terms of the 3-4 GHz data, the bandwidth is 1 GHz. The number of frequency points swept in each snapshot is 501. In the aspect of 38-39 GHz and 39-40 GHz data, the center frequencies are 38.5 GHz and 39.5 GHz with 1 GHz bandwidth, respectively. The number of frequency points swept in each snapshot is also 501.</p>

opencc-zeroFeb 2020View details →

opencc-by-4.0Jul 2023View details →

Outdoor NB-IoT and 5G coverage and channel information data in urban environments

<p>This dataset includes data for NB-IoT and 5G networks as collected in two cities: Oslo, Norway (NB-IoT only) and Rome, Italy (both NB-IoT and 5G).</p> <p>Data were collected using the Rohde & Schwarz TSMA6 mobile network scanner. 7 measurement campaigns are provided for Oslo, and 6 for Rome. Additional data collected in Rome are provided in the following large-scale dataset, focusing on the two major mobile network operators: <a href="https://ieee-dataport.org/documents/large-scale-dataset-4g-nb-iot-and-5g-non-standalone-network-measurements">https://ieee-dataport.org/documents/large-scale-dataset-4g-nb-iot-and-5g-non-standalone-network-measurements</a> </p> <p>The dataset includes a metadata file providing the following information for each campaign: </p> <ul> <li>date of collection;</li> <li>start time and end time of collection;</li> <li>length;</li> <li>type (walking/driving).</li> </ul> <p>Two additional metadata files are provided: two .kml files, one for each city, allowing the import of coordinates of data points organized by campaign in a GIS engine, such as Google Earth, for interactive visualization.</p> <p>The dataset contains the following data for NB-IoT:</p> <ul> <li>Raw data for each campaign, stored in two .csv files. For a generic campaign <X>, the files are: <ul> <li>NB-IoT_coverage_C<X>.csv including a geo-tagged data entry in each row. Each entry provides information on a Narrowband Physical Cell Identifier (NPCI), with data related to the time stamp the NPCI was detected, GPS information, network (NPCI, Operator, Country Code, eNodeB-ID) and RF signal (RSSI, SINR, RSRP and RSRQ values);</li> <li> NB-IoT_RefSig_cir_C<X>.csv, also including a geo-tagged data entry in each row. Each entry provides information on a NPCI, with data related to the time stamp the NPCI was detected, GPS information, network (NPCI, Operator ID, Country Code, eNodeB-ID) and Channel Impulse Response (CIR) statistics, including the maximum delay.</li> </ul> </li> <li>Processed data, stored in a Matlab workspace (.mat) file for each city:  data are grouped in data points, identified by <Latitude, longitude> pairs. Each data point provides RF and CIR maximum delay measurements for each <NPCI, Operator ID, eNodeB-ID> unique combination detected at the coordinates of the data point.</li> <li>Estimated positions of eNodeBs, stored in a csv file for each city;</li> <li>A matlab script and a function to extract and generate processed data from the raw data for each city.</li> </ul> <p>The dataset contains the following data for 5G:</p> <ul> <li>Raw data for each campaign, stored in two .xslx files. For a generic campaign <X>, the files are: <ul> <li>5G_coverage_C<X>.xslx including a geo-tagged data entry in each row. Each entry provides information on a Physical Cell Identifier (PCI), with data related to the time stamp the PCI was detected, GPS information, network (PCI, Beamforming Index, Operator, Country Code) and RF data (SSB-RSSI, SSS-SINR, SSS-RSRP and SSS-RSRQ values, and similar information for the PBCH signal);</li> <li> 5G_RefSig_cir_C<X>.csv, also including a geo-tagged data entry in each row. Each entry provides information on a PCI, with data related to the time stamp the PCI was detected, GPS information, network (PCI, Beamforming Index, Operator ID, Country Code) and Channel Impulse Response (CIR) statistics, including the maximum delay.</li> </ul> </li> <li>Processed data, stored in a Matlab workspace (.mat) file:  data are grouped in data points, identified by <Latitude, longitude> pairs. Each data point provides RF and CIR maximum delay measurements for each <PCI, Beamforming Index, Operator ID> unique combination detected at the coordinates of the data point.</li> <li>A matlab script and a supporting function to extract and generate processed data from the raw data.</li> </ul> <p>In addition, in the case of the Rome data additional matlab workspaces are provided, containing interpolated data in the feature dimensions according to two different approaches:</p> <ul> <li>A campaign-by-campaign linear interpolation (both NB-IoT and 5G);</li> <li>A bidimensional interpolation on all campaigns combined (NB-IoT only).</li> </ul> <p>A function to interpolate missing data in the original data according to the first approach is also provided for each technology. The interpolation rationale and procedure for the first approach is detailed in:</p> <p>L. De Nardis, G. Caso, Ö. Alay, U. Ali, M. Neri, A. Brunstrom and M.-G. Di Benedetto, "Positioning by Multicell Fingerprinting in Urban NB-IoT networks," Sensors, Volume 23, Issue 9, Article ID 4266, April 2023. <span>DOI: </span><a href="https://doi.org/10.3390/s23094266" target="_blank" rel="noopener"><span>10.3390/s23094266</span></a>.</p> <p>The second interpolation approach is instead introduced and described in:</p> <p>L. De Nardis, M. Savelli, G. Caso, F. Ferretti, L. Tonelli, N. Bouzar, A. Brunstrom, O. Alay, M. Neri, F. Elbahhar and M.-G. Di Benedetto, " Range-free Positioning in NB-IoT Networks by Machine Learning: beyond WkNN", under major revision in IEEE Journal of Indoor and Seamless Positioning and Navigation.</p> <p>Positioning using the 5G data was furthermore in investigated in: </p> <p>K. Kousias, M. Rajiullah, G. Caso, U. Ali, Ö. Alay, A. Brunstrom, L. De Nardis, M. Neri, and M.-G. Di Benedetto, "A Large-Scale Dataset of 4G, NB-IoT, and 5G Non-Standalone Network Measurements," <span>IEEE Communications Magazine, Volume 62, Issue 5, pp</span><span>. 44-49, May</span><span> 202</span><span>4</span><span>. DOI:  </span><a href="https://doi.org/10.1109/MCOM.011.2200707" target="_blank" rel="noopener"><span>10.1109/MCOM.011.2200707</span></a><span>.</span></p> <p><span>G. Caso, M. Rajiullah, K. Kousias, U. Ali, N. Bouzar, L. De Nardis, A. Brunstrom, Ö. Alay, M. Neri and M.-G. Di Benedetto,"The Chronicles of 5G Non-Standalone: An Empirical Analysis of Performance and Service Evolution", IEEE Open Journal of the Communications Society, Volume 5, pp. 7380 - 7399, 2024. DOI: <a href="https://doi.org/10.1109/OJCOMS.2024.3499370" target="_blank" rel="noopener"><span>10.1109/OJCOMS.2024.3499370</span></a>.</span></p> <p>Please refer to the above publications when using and citing the dataset. </p>

opencc-byJun 2022View details →

Tutorial for the 2022 ACM SIGMOD Conference: Spatial Data Quality in the IoT Era: Management and Exploitation

<p>Within the rapidly expanding Internet of Things (IoT), growing amounts of spatially referenced data are being generated. Due to the dynamic, decentralized, and heterogeneous nature of the IoT, spatial IoT data (SID) quality has attracted considerable attention in academia and industry. How to invent and use technologies for managing spatial data quality and exploiting low-quality spatial data are key challenges in the IoT. In this tutorial, we highlight the SID consumption requirements in applications and offer an overview of spatial data quality in the IoT setting. In addition, we review pertinent technologies for quality management and low-quality data exploitation, and we identify trends and future directions for quality-aware SID management and utilization. The tutorial aims to not only help researchers and practitioners to better comprehend SID quality challenges and solutions, but also offer insights that may enable innovative research and applications.</p>