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.
111
datasets available to search
ShareScore release 0.9.0
Dataset results
111 results for “5G”
Experimental Results for the AERO 5G project (Fed4FIRE+)
<p>The corresponding results refer to the experiments conducted during the life of the Fed4FIRE+ project entitled: "AERO 5G (Augmented Reality Tour Guide Architecture for 5G)". The public availability of the results aim to help future experimenters and researchers to obtain some intuition with regard to the benefits of 5G for content-based, bandwitdh consuming, MAR applications.</p> <p>----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------</p> <p>Short Description of the Experiments: All values have been rounded to two decimal places. Our team has conducted ten experimental runs for each of the following experimental scenarios.</p> <p>o <strong>4G SDR srsLTE-to-AWS</strong>: A 4G SDR srsLTE network deployed over the Fed4FIRE+ Iris testbed, between a Xiaomi Mi Mix 2S handset and an Amazon EC2 node at Amazon Cloud (AWS) that hosts the AR video content.</p> <p>o<strong> 4G SDR srsLTE-to-IMEC</strong>: A 4G SDR srsLTE network deployed over the Fed4FIRE+ Iris testbed, between a Xiaomi Mi Mix 2S handset and a bare metal machine at Fed4FIRE+ IMEC's VirtualWall that hosts the AR video content.</p> <p>o <strong>4G SDR srsLTE-to-Iris-MEC</strong>: A 4G SDR srsLTE network deployed over the Fed4FIRE+ Iris testbed, between a Xiaomi Mi Mix 2S handset and a MEC storage node located at the edge of the network infrastructure at the Iris testbed that hosts the AR video content. Although MEC is considered to be a 5G technology, our aim in this scenario is to explore the benefit of deploying edge storage nodes in wireless mobile telecommunication technologies in general. For this purpose, we assume that the video content has been stored at the MEC storage node a priori to the end-user's requests.</p> <p>o <strong>Commercial Three.ie 4G-to-AWS</strong>: A Commercial 4G network deployed by the Three.ie mobile operator in Ireland, between a Xiaomi Mi Mix 2S handset and an Amazon EC2 node that hosts the AR video content. Even though a MEC storage node could not be deployed in this scenario, our intention is to estimate the benefit of deploying edge storage nodes empirically by consulting the results concluded for the 4G LTE-to-MEC scenario.</p> <p>o <strong>2.4GHz Wi-Fi-to-IMEC</strong>: A 2.4GHz Wi-Fi (802.11 n) network deployed over the Fed4FIRE+ Iris testbed, between a Xiaomi Mi Mix 2S handset and a bare metal machine at Fed4FIRE+ IMEC's VirtualWall that hosts 4K AR video. This scenario serves us as a proof-of-concept that a 2.4GHz Wi-Fi network is not capable of supporting the delivery of high quality 4K AR content in areas where there are a lot of 2.4GHz Wi-Fi networks.</p> <p>o <strong>5GHz Wi-Fi-to-AWS</strong>: A 5GHz Wi-Fi (802.11 ac) network deployed over the Fed4FIRE+ Iris testbed, between a Xiaomi Mi Mix 2S handset and an Amazon EC2 node at Amazon Cloud (AWS) that hosts the AR video content.</p> <p>o <strong>5GHz Wi-Fi-to-IMEC</strong>: A 5GHz Wi-Fi (802.11 ac) network deployed over the Fed4FIRE+ Iris testbed, between a Xiaomi Mi Mix 2S handset and a bare metal machine at Fed4FIRE+ IMEC's VirtualWall that hosts the AR video content.</p> <p>o<strong> 5GHz Wi-Fi-to-Iris-MEC</strong>: A 5GHz Wi-Fi (802.11 ac) network deployed over the Fed4FIRE+ Iris testbed, between a Xiaomi Mi Mix 2S handset and a MEC storage node located at the edge of the network infrastructure that hosts the AR video content. Similar to the 4G LTE-to-MEC scenario, we assume that the video content has been stored at the MEC storage node a priori to the end-user's requests. </p>
PMU measurements altered by wireless communication such as 3G, 4G, 5G
<p><span>Dataset which shows the effect of three types of wireless communication (e.g., 3G, 4G, and 5G, respectively) on data integrity of two real Phasor Measurement Unit (PMU) measurements which are sent to a virtual Phasor Data Concentrator (vPDC) for timestamp synchronization function. Each file contains the values of the two real PMUs installed at each end of a high voltage (HV) transmission line located in a transmission power grid in South Europe. The datasets were collected using an advanced Power-Hardware In the Loop (P-HIL) setup, including in the communication loop between the PMUs and the vPDC a hardware network emulator. The later had the role to realistically emulate the macroscopic behavior of the communication delays and packet data loss of the three wireless communication networks. The delays and data packet loss were imposed only at one of the two PMUs (PMU Lab1) considering a power grid system running in balanced operation conditions. Therefore, only phase A was recorded in the data, and the reason why the current values from phase B and phase C are almost zero. </span></p>
Dataset of a 5G RTSP video streaming use case
<p><strong>About the project: monitoring 5G RTSP video streaming</strong></p> <p>This dataset collects data from a 5G video streaming use case. A video is streamed by a cvlc server (realized as a Kubernetes pod) through RTSP to a variable number of 5G UE clients that activate according to a daily traffic pattern. The values of the 4 dataset features (number of active UEs, gNB's downlink bit rate, pod's outbound traffic, and pod's CPU usage) are collected by a custom monitoring system deployed in the context of the MONB5G project.</p> <p><strong>Setup/Equipment</strong></p> <p>The Kubernetes cluster, including the server pod, runs in a COTS server. The 5G core and gNB is realized through Amarisoft Callbox Ultimate. The UEs are emulated through Amarisoft Simbox. In order to display the video in ffplay clients, we use the Remote UE from Amarisoft, so traffic from Simbox is forwarded to an external VM with GUI.</p> <p><strong>Video</strong></p> <p>The streamed video is Big Buck Bunny at 30 FPS from <a href="https://peach.blender.org/">https://peach.blender.org/</a>.</p> <table> <tbody> <tr> <td> <p>Video codec </p> </td> <td> <p>Advanced Video Codec (AVC) </p> </td> </tr> <tr> <td> <p>Width </p> </td> <td> <p>1920 pixels </p> </td> </tr> <tr> <td> <p>Height </p> </td> <td> <p>1080 pixels </p> </td> </tr> <tr> <td> <p>Display aspect radio </p> </td> <td> <p>16:9 </p> </td> </tr> <tr> <td> <p>Duration </p> </td> <td> <p>10 min 34 s </p> </td> </tr> <tr> <td> <p>Max Bitrate </p> </td> <td> <p>16.7 Mb/s </p> </td> </tr> <tr> <td> <p>Frame rate </p> </td> <td> <p>30 FPS </p> </td> </tr> </tbody> </table> <p><strong>What does this Zenodo project contain?</strong></p> <ol> <li>The csv file of the dataset (dataset.csv)</li> <li>A picture displaying an overview of the setup (overview.png)</li> <li>A picture displaying Grafana charts for each featuer (grafana.png)</li> <li>A picture displaying a screenshot of the Remote UE VM with multiple UEs playing the video (ues.png)</li> </ol> <p><strong>Dataset</strong></p> <p>The dataset has 5 columns (time + 4 features). Features:</p> <ol> <li><em>Time</em>: timestamp in epoch format.</li> <li><em>Number of active UEs (N)</em>: number of UEs that are currently downloading more than 100 kbps. No unit.</li> <li><em>gNB's downlink bit rate (R)</em>: aggregate downlinkg bitrate from the gNB to all the UEs. In Mbps.</li> <li><em>Outbound traffic (O)</em>: outboun traffic at the pod's interface, transmitting the video(s) packets. In Mbps.</li> <li><em>CPU (C)</em>: CPU usage at the server pod. In millicores (mc). Each iteration represents a whole day, composed of 24 "demand periods". Each demand period takes 2 minutes and is given by the number of active UEs consuming the video stream (N). N is included for informative reasons. Sampling rate is 10 seconds, but some parameters are refreshed at a lower frequency given monitoring limitations. This means that some parameters repeat the same value in consecutive measurements.</li> </ol>
Cooperative Proactive resource management for 5G in the unlicensed spectrum open data
<p>The data set consists of the following files:</p> <p><strong>1)COT information:</strong> The channel occupancy time of each channel for the first 5000 measurements. The COT values range from 0 to 1.</p> <p><strong>2)QL decisions uniform traffic:</strong> The decisions of QL for the channel utilization of the available SBS and their impact to the achieved throughput. In this file we consider uniform traffic generation patterns.</p> <p><strong>3)QL decisions NON uniform traffic:</strong> The decisions of QL for the channel utilization of the available SBS and their impact to the achieved throughput. In this file we consider non-uniform traffic generation patterns.</p> <p><strong>4)Performance measurements: </strong>The final results of the experiment in respect to the transmit power control and throughput measurements under different QL configurations.</p>
Implications of Handover Events in commercial 5G Non-Standalone Deployments in Rome
<p>Passive and active network measurements used for analysing the implications of Handover (HO) events inn commercial 5G Non-Standalone (NSA) deployments in Rome.</p> <p> </p> <p> </p>
Dataset of "Comparison of Localization Methods for Internet of Things in 5G Cellular Networks: A Wide-scale Assessment"
<p>As the 3rd generation partnership project (3GPP) organization pushes out new releases,<br>positioning in heterogeneous mobile networks enables the achievement of the accuracy required<br>in the majority of industrial applications without dependence on global navigation<br>satellite systems (GNSS). This study presents the results gathered during an extensive measurement<br>campaign related to the practical applicability of localization in next-generation<br>heterogeneous networks. We present an accuracy comparison of basic timing advance (TA)<br>localization with the k-nearest neighbor (KNN), decision tree-based random forest (RF),<br>extreme gradient boosting (XGBoost), and long short-term memory (LSTM) recurrent neural<br>network. Our results demonstrate that TA cannot be considered an optimal solution<br>from the perspective of localization accuracy because the error roughly corresponds to the<br>average separation distance from the base station (BS) to the end device (ED). In addition,<br>we found that the LSTM approach is not optimal for the outdoor localization of moving<br>ED because of the combination of multiple factors, with sparse deployment being the most<br>important. The median value of the location error of the LSTM was more than 200m higher<br>than that of the TA for the self-validation dataset. However, a simple KNN regression shows<br>solid results for 5G New Radio (NR) operating in the non-standalone (NSA) mode. KNN<br>provided the most accurate results of all methods, with median error values of approximately<br>12 (k=3) and 82 (k=5) m for the self-validated and cross-validated datasets, respectively.</p>
Dataset - A Standard-compliant Assessment of Beyond-eMBB QoS/QoE in 5G Networks
<p>The present dataset is open-sourced with the paper "A Standard-compliant Assessment of Beyond-eMBB QoS/QoE in 5G Networks".</p> <p>The paper is authored by Giuseppe Caso, Mohammad Rajiullah, Anna Brunstrom, Luca De Nardis, Ozgu Alay, and Marco Neri. </p> <p>If you use the dataset for your own research activities and publications, please consider citing the paper as follows: </p> <p><strong>G. Caso et al., "A Standard-compliant Assessment of Beyond-eMBB QoS/QoE in 5G Networks," in Proceedings of the IEEE Conference on Standards for Communications and Networking (IEEE CSCN'24), pp. 1-7, 2024.</strong></p> <p><strong>@inproceedings{caso2024standard,</strong><br><strong> title={{A Standard-compliant Assessment of Beyond-eMBB QoS/QoE in 5G Networks}},</strong><br><strong> author={Caso, Giuseppe and Rajiullah, Mohammad and Brunstrom, Anna, and De Nardis, Luca and Alay, Ozgu and Neri, Marco},</strong><br><strong> booktitle={Proceedings of the IEEE Conference on Standards for Communications and Networking (IEEE CSCN'24)},</strong><br><strong> pages={1--7},</strong><br><strong> year={2024}</strong><br><strong>}</strong></p> <p>A detailed description of the dataset is provided in the paper, and the README file provides additional details.</p> <p>Contact Giuseppe Caso (giuseppe.caso@kau.se) for more information on the dataset and potential access to additional data. </p>
[5G-IANA] UC6 - 5G Measurement Campaign
<p>5G network metrics (throughput, round trip time, RSRQ, and RSRP) in a particular area are collected between Nokia's Edge server and the OBU. The 5G network status was monitored using a tool developed by UULM/UDE. This dataset serves as the basis for training an LSTM model, enabling it to forecast future quantiles of RTT and throughput."</p>
DETERMINISTIC6G COTS 5G latency measurements
<h1>Measurement setup and dataset overview</h1> <p>The dataset contains the data collected during the latency measurements performed on a COTS 5G system. The 5G network operates in band 78, in TDD mode, with a total of 106 PRBs which occupies 40 MHz of bandwidth. The latency (one-way delay) samples were collected in both uplink and downlink directions using the <a href="https://github.com/heistp/irtt" target="_blank" rel="noopener">irtt</a> tool running on the end node (connected to the UE) and the edge node (connected to the 5G gateway). The clocks in the 5G system, end node and edge node were precisely (<200ns) synchronized using Precision Time Protocol (PTP). In addition to recording send and receive timestamps, various network conditions were also recorded for each latency sample.<br>The measurements were carried out in different sessions and for each session, there are about 1M samples in total which are contained in different parquet files corresponding to different rounds (30 mins) per session. Each session corresponds to a combination of direction (uplink or downlink), UE device, a packet interval and payload length, etc. A spreadsheet (COTS5G measurement campaign.xlsx) in this directory contains the information detailed information on the combination for each session.</p> <h1>Acknowledgements </h1> <p>This work was supported by the European Commission through the H2020 project DETERMINISTIC6G (Grant Agreement no. 101096504).</p>
Coverage and Performance Analysis of 5G Non-Standalone Deployments
<p>Passive and active network measurements used for analysing 'Coverage and Performance Analysis of 5G Non-Standalone Deployments'</p>
OpenDRIVE dataset of 5G Living Lab research track in Wolfsburg
<p>This OpenDRIVE dataset models a road network excerpt of the city of Wolfsburg, Lower Saxony, Germany. Main application scopes of this OpenDRIVE data are in the domain of automated driving: simulation, verification and validation. The data has been acquired in context of the research project <a href="https://verkehrsforschung.dlr.de/en/projekte/5g-reallabor">5G Living Lab in the Mobility Region Braunschweig-Wolfsburg</a>.</p>
5G Aerial RF Radiation Data
<p>Data is contained in zipped files. Each zipped file represents a measurement campaign. Data includes measurement (.mat, .csv, .xlsx) files, plot (.jpg, .fig) files, and a readme (.txt) file.</p>
Machine Learning Enabled Multi-Radio Access Technology Selection in 5G Networks
<p>In this paper, we present a machine learning algorithm for effective RAT selection in 5G networks by considering the geo-location (latitude and longitude) of the user as well as the received signal strength intensity (RSSI) from the base station as basic parameters, real live data from a 5G network base-station were collated, divided into training and testing data-sets, the training data-sets (input) were used to train models of supervised machine learning classification algorithm: Decision Tree (DT), Extra Tree (XTREE), Random Forest (RF), Gradient Boosting (GB), and eXtreme Gradient Boosting (XGBoost); these trained models are further tested with input test data-sets to predict/select the appropriate RAT (4G/5G) as labelled output. Evaluation of results showed a measure of accuracy of our chosen model of RAT selection; (XGBoost) at optimal level 93.86\%, which was further cross validated at 92.9\% when compared with other algorithms for its effectiveness on future data and mitigation ability on over-fitting and under-fitting issues, hence recommended for planning and optimization purposes in similar urban/dense-urban environment to assist in maintaining the rapidly increasing demand of network connections and devices.</p>
Datasets for the Results of Scratch Tests of Green Wood and Results of Scratch Tests of Timber Components (D2.1) and Output Database for Selected Wood Parts and Timber Components: Moisture Contents and Temperatures, Moisture Induced Strains and Stresses and Crack Risk (D2.2) of 5G-TIMBER EU Project
<p>7 June 2024: added D2.2_data_statistics.zip and D2.2_analysis_results.zip, which are the datasets for D2.2 "<span>Output Database for Selected Wood Parts and Timber Components: Moisture Contents and Temperatures, Moisture Induced Strains and Stresses and Crack Risk" of the Horizon Europe Innovation Action project "5G-TIMBER: Secure 5G-Enabled Twin Transition for Europe's TIMBER Industry Sector" (project reference: 101058505).</span></p> <p>D2.2 presents the Hygro-Thermo-Mechanical (HTM) models and the finite element (FE) analyses of selected wooden components that use the material properties of wood presented in deliverable D2.1 "Input database for selected wood parts and timber components: material properties, representative environmental conditions,<br>and loads" (see below). </p> <p>------</p> <p>Figures_22_23_24_25.xlsx : Results of Scratch Tests of Green Wood</p> <p>corrected_Figures_26_27_28_29_30.xlsx : Results of results of Scratch Tests of Timber Components (new version, uploaded on 26 October 2023)</p> <p>This dataset consists of 2 Excel files that correspond to the scratch test results reported in the deliverable D2.1 "Input Database for Selected Wood Parts and Timber Components: Material Properties, Representative Environmental Conditions and Loads" of the Horizon Europe Innovation Action project "5G-TIMBER: Secure 5G-Enabled Twin Transition for Europe's TIMBER Industry Sector" (project reference: 101058505).</p> <p>The purpose of D2.1, to which this dataset is related, is to present the input data needed for the Hygro-Thermo-Mechanical (HTM) models and the related finite element (FE) analyses planned for a follow-up deliverable, i.e., the D2.2. (Output Database for Selected Wood Parts and Timber Components: Moisture Contents and Temperatures, Moisture Induced Strains And Stresses And Crack Risk). The data include the material properties for green wood and selected wooden components, as well as the plans to collect environmental conditions and loads to be considered in the analyses for prediction of the crack risk of timber components under moisture variations. In additions, new results of scratch tests of wood and wooden components, supported by computed tomography (CT) investigations, are collected to define a model for shear failure risk to be added to the HTM computational models.</p> <p>In D2.1, scratch tests carried out at VTT are described and their results are collected to provide information about the moisture effects of wood logs during cutting operations in sawmills, as well as on relevant fracture and shear properties for wooden components in sawing centres before using them to produce wooden elements of modular buildings in the production. The scratch tests are supported by CT tomography investigations and these results are also reported in the deliverable.</p> <p>D2.1 is available here: <a title="Deliverable D2.1 "Input Database for Selected Wood Parts and Timber Components: Material Properties, Representative Environmental Conditions and Loads" " href="../records/10577505" target="_blank" rel="noopener">https://zenodo.org/records/10577505</a> </p>
5G-IANA: UC4 Dataset Mobile users data rate participating in the use case
<p>Location of the mobile user and its nearby place data including their type such as restaurant, café, market, banks and gas station</p>
5G Campus Network QoS Dataset for Open-Source gNB Implementations
<p>This 5G campus network dataset contains 6 distinct CSV files.<br>Three for each of the testbeds located at either the Norwegian University of Science and Technology(NTNU) or the University of Wuerzburg(WUE).<br>all_Packets: contains all One-Way-Delay measurement packets. Columns: src, Timestamp, SourceIPOuter, DestinationIPOuter, SourceIPInner, DestinationIPInner, PacketSize, SeqNum, iat, trel, gnb, sdr, bw, slots, ratio, pdist, piat, psize, pnpak, rep, scenario, direction<br>Packets_with_IATs: contains all One-Way-Delay measurement packets, with the Interarrival-times already calculated and added as column. Columns: src, Timestamp, SourceIPOuter, DestinationIPOuter, SourceIPInner, DestinationIPInner, PacketSize, SeqNum, iat, trel, gnb, sdr, bw, slots, ratio, pdist, piat, psize, pnpak, rep, scenario, direction<br>all_Throughput: contains all output information from the throughput measurements conducted with iperf3. Columns: mbpsactual_uplink, mbpsactual_downlink, meanjitterms_uplink, meanjitterms_downlink, meanloss_uplink, meanloss_downlink, gnb, sdr, bw, slots, ratio, mbpsoffered_uplink, mbpsoffered_downlink, rep, scenario</p> <p>src: Source Device<br>Timestamp: Timestamp from wireshark<br>SourceIPOuter: Source IP of the outer GTP packet<br>DestinationIPOuter: Destination IP of the outer GTP packet<br>SourceIPInner: Source IP of the inner GTP packet<br>DestinationIPInner: Destination IP of the inner GTP packet<br>PacketSize: Size of the packet<br>SeqNum: Sequence number injected during traffic generation<br>iat: Interarrival-time of the packet<br>trel: relative timestamp<br>gnb: gNB implementation used<br>sdr: SDR used<br>bw: configured bandwidth<br>slots: configured DL slots<br>ratio: configured DL:UL ratio<br>pdist: chosen distribution of the packet generation (deterministic/negative-exponential time between transmission of the generated packets)<br>piat: chosen interarrival -time during packet generation<br>psize: chosen packet size mode<br>pnpak: total amount of packets generated for this measurement run<br>rep: repetition of measurement<br>scenario: measurement scenario<br>direction: direction of traffic</p> <p>mbpsactual_uplink: actual uplink throughput in MBps<br>mbpsactual_downlink: actual downlink throughput in MBps<br>meanjitterms_uplink: actual uplink jitter in ms<br>meanjitterms_downlink: actual downlink jitter in ms<br>meanloss_uplink: mean loss in uplink<br>meanloss_downlink: mean loss in downlink<br>mbpsoffered_uplink: configured uplink throughput in MBps<br>mbpsoffered_downlink: configured downlink throughput in MBps</p> <p>This dataset stems from the Paper "Parameterizing 5G New Radio: A Comparative Measurement Study on Throughput and Delay" </p>
NCSRD-DS-5GDDoS: 5G Radio and Core metrics containing sporadic DDoS attacks
<p><strong>NCSRD-DS-5GDDos v3.0 Dataset</strong><br>===<br>NCSRD-DS-5GDDos is a comprehensive dataset recorded in a real-world 5G testbed that aligns with the 3GPP specifications. The dataset captures Distributed Denial of Service (DDoS) attacks initiated by malicious connected users (UEs). </p> <p>The setup comprises of 3 cells with a total of 9 UEs connected to the same core network. The 5G network is implemented by the Amarisoft Callbox Mini solution (cell 2), and we further employ a second cell using the Amarisoft Classic (cell 1 & 3), that also hosts the 5G core.</p> <p>The setup utilizes a broad set of UE devices comprising a set of smart phones (Huawei P40), microcomputers (Raspberry Pi 4 - Waveshare 5G Hat M2), industrial 5G routers (Industrial Waveshare 5G Router), a WiFi-6 mobile hotspot (DWR-2101 5G Wi-Fi 6 Mobile Hotspot) and a CPE box (Waveshare 5G CPE Box). All UEs are being operated by subsidiary hosts which are responsible for the traffic generation, occurring from scheduled communications times.</p> <p>All identifiers are artificially generated and do not represent or based on personal data. We identify each UE through its ‘imeisv’ ID, that corresponds to the device in use, due to vendor implementation, that uses the same IMSI for all UEs.</p> <p>This dataset captures attack data from a total of 5 malicious User Equipment (UE) devices that initiated various flooding attacks on a 5G network. Each record includes key identifiers such as the IMEISV (International Mobile Equipment Identity Software Version number) and IP address of the attacking UE, along with the device type. The file "summary_report.csv" summarizes this information. The traffic types used in the attacks include syn flooding, UDP flooding, ICMP flooding, DNS flooding, and GTP-U flooding. The benign users stream YouTube and Skype traffic.</p> <p>The dataset is recorded through the use of a data collector that interfaces with the 5G network and gathers data regarding UEs, gNBs and the Core Network. The data are recorded in an InfluxdB and pre-processed into three separate tabular .csv files for more efficient processing: “amari_ue_data.csv”, “enb_counters.csv” and “mme_counters.csv”. In this version, we use an Amarisoft Classic (cells 1 & 3, Core Network) and an Amarisoft Mini (cell 2) (more information on the products can be found in https://www.amarisoft.com/).</p> <p>The ”amari_ue_data.csv” provides information on the UEs regarding identification (“imeisv”, “5g_tmsi”, “rnti”), IP addressing, bearer information, cell information (“tac”, “ran_plmn”), and cell information (“ul_bitrate”, “dl_bitrate”, “cell_id”, retransmissions per user per cell “ul_retx” as well as aggregated bit rates for each cell).</p> <p>The ”enb_counters.csv” focuses on cell-level information, providing downlink and uplink bitrates, usage ratio per user, cpu load of the gNB.</p> <p>We provide separate files of ”amari_ue_data.csv” and ”enb_counters.csv” generated from each gNB (Amarisoft Classic and Mini).</p> <p>The “mme_counters.csv” provides information on the Non-Access Stratum (NAS) of the 5G Network and focuses on session status reports (e.g., number of PDU session establishments, paging, context setup. This part gives an overview of the connection management throughout the recording session, and provides information on features suggested by 3GPP for abnormal user behavior.</p> <p>We also provide a separate pre-processed dataset, that merges the two "amari_ue_data_*.csv" file, including labeling of the malicious/benign samples, and may be more flexible for interested data scientists.</p> <p>Please refer to README.txt for the features included in each file.</p> <p>If you use this dataset, please also cite the following papers:</p> <p>M. Christopoulou, A. Garos, A. Vekraki, D. Santorinaios, I. Koufos, S. Karamitsiani, G. Xilouris, M.-A. Kourtis, G. Gardikis, and P. Trakadas, “User Terminals as Attackers: An Open Dataset Analysis of DDoS Attacks in 5G Networks,” in Proc. 2024 IEEE Conf. Standards Commun. Netw. (CSCN), 2024, pp. 301–307, doi: 10.1109/CSCN63874.2024.10849694.</p> <p>G. Xylouris, A. Vekraki, M. Christopoulou, M. A. Kourtis, E. K. Markakis and P. Trakadas, "Advancing Predictive Security for Consumer Applications in Beyond 5G/6G Networks With Annotated Datasets," in IEEE Transactions on Consumer Electronics, doi: 10.1109/TCE.2025.3567151.</p>
Dataset for Agile 5G Network Measurements: Operator Benefits of Employing Aerial Mobility
<p>Dataset of paper "Agile 5G Network Measurements: Operator Benefits of Employing Aerial Mobility".</p> <p>The measurement data contains two different scenarios: Scenario 1 and Scenario 2, according to the paper. These two datasets include two different kinds of files: those related to measurements taken with a phone and those taken with a drone (UAV).</p>
5G-EMIT Project: EMF measurements of 2G/3G/4G/5G frequency bands captured with a IMEC/University of Ghent sensor on the terrace of a building in LOS to one antenna in the Esch-Belval Area, Luxembourg (2023-02-21)
<p>During the 5G-EMIT project, EMF measurements of relevant mobile frequency bands have been taken at various sites around known antennas.</p> <p>Focus was in measuring the the following standard frequency bands:</p> <ul> <li>5G 700 <ul> <li>Band 28 FDD down</li> <li>758 - 803 MHz (Luxembourg: 758 - 788 MHz)</li> </ul> </li> <li>LTE 800 <ul> <li>Band 20 FDD down<br> 791 - 821 MHz</li> </ul> </li> <li>GSM 900 <ul> <li>Band 8 FDD down</li> <li>925 - 960 MHz</li> </ul> </li> <li>GSM/LTE 1800 <ul> <li>Band 3 FDD down</li> <li>1805 - 1880 MHz</li> </ul> </li> <li>UMTS 2100 <ul> <li>Band 1 FDD down</li> <li>2110 - 2170 MHz</li> </ul> </li> <li>LTE 2600 <ul> <li>Band 38 TDD</li> <li>2570 - 2620 MHz</li> </ul> </li> <li>LTE 2600 <ul> <li>Band 7 FDD down</li> <li>2620 - 2690 MHz</li> </ul> </li> <li>5G 3500 <ul> <li>Band 78 TDD</li> <li>3300 - 3800 MHz (Luxembourg: 3400 - 3800 MHz)</li> </ul> </li> </ul> <p><br> Two sensor have been used: The MVG EME Spy Evolution and a sensor developed by IMEC/University of Ghent.</p> <ul> <li>The MVG Spy Evolution sensor is able to measure all of the requested frequency bands as defined by the standard.</li> <li>The IMEC/University of Ghent sensor is only able to measure the LTE 800, GSM 900, GSM/LTE 1800 bands as defined by the standard.<br> In the 5G 3500 band it is only able to measure the range of 3550-3700 MHz (3465-3785 MHz within a -5db response).</li> </ul> <p>The datasets of the ZIP file has following structure:</p> <ul> <li>measurements: <ul> <li>the files of the measurements as provided by the sensor or application</li> <li>combined file of measurements in case the measurements have been split into several parts</li> <li>potentially analysis files of the measurements </li> </ul> </li> <li>pictures: <ul> <li>pictures of the antennas</li> <li>pictures of the sensor</li> <li>pictures of the location of the sensor</li> </ul> </li> <li>Readme.txt: <ul> <li>Used time-zone in the tables</li> <li>Used units in the tables</li> <li>Calculation of the total values in the tables</li> <li>Used labels of the the frequency bands</li> <li>Used sensor (MVG EME Spy Evolution or IMEC/University of Ghent)</li> <li>Locations of the target antennas</li> <li>Potentially location of the fixed sensor</li> </ul> </li> </ul>
5G-EMIT Project: EMF measurements of 2G/3G/4G/5G frequency bands captured with a MVG EME Spy Evolution sensor while walking in LOS and NLOS to two antennas through the Esch-Belval Area, Luxembourg (2022-11-10)
<p>During the 5G-EMIT project, EMF measurements of relevant mobile frequency bands have been taken at various sites around known antennas.</p> <p>Focus was in measuring the the following standard frequency bands:</p> <ul> <li>5G 700 <ul> <li>Band 28 FDD down</li> <li>758 - 803 MHz (Luxembourg: 758 - 788 MHz)</li> </ul> </li> <li>LTE 800 <ul> <li>Band 20 FDD down<br> 791 - 821 MHz</li> </ul> </li> <li>GSM 900 <ul> <li>Band 8 FDD down</li> <li>925 - 960 MHz</li> </ul> </li> <li>GSM/LTE 1800 <ul> <li>Band 3 FDD down</li> <li>1805 - 1880 MHz</li> </ul> </li> <li>UMTS 2100 <ul> <li>Band 1 FDD down</li> <li>2110 - 2170 MHz</li> </ul> </li> <li>LTE 2600 <ul> <li>Band 38 TDD</li> <li>2570 - 2620 MHz</li> </ul> </li> <li>LTE 2600 <ul> <li>Band 7 FDD down</li> <li>2620 - 2690 MHz</li> </ul> </li> <li>5G 3500 <ul> <li>Band 78 TDD</li> <li>3300 - 3800 MHz (Luxembourg: 3400 - 3800 MHz)</li> </ul> </li> </ul> <p><br> Two sensor have been used: The MVG EME Spy Evolution and a sensor developed by IMEC/University of Ghent.</p> <ul> <li>The MVG Spy Evolution sensor is able to measure all of the requested frequency bands as defined by the standard.</li> <li>The IMEC/University of Ghent sensor is only able to measure the LTE 800, GSM 900, GSM/LTE 1800 bands as defined by the standard.<br> In the 5G 3500 band it is only able to measure the range of 3550-3700 MHz (3465-3785 MHz within a -5db response).</li> </ul> <p>The datasets of the ZIP file has following structure:</p> <ul> <li>measurements: <ul> <li>the files of the measurements as provided by the sensor or application</li> <li>combined file of measurements in case the measurements have been split into several parts</li> <li>potentially analysis files of the measurements </li> </ul> </li> <li>pictures: <ul> <li>pictures of the antennas</li> <li>pictures of the sensor</li> <li>pictures of the location of the sensor</li> </ul> </li> <li>Readme.txt: <ul> <li>Used time-zone in the tables</li> <li>Used units in the tables</li> <li>Calculation of the total values in the tables</li> <li>Used labels of the the frequency bands</li> <li>Used sensor (MVG EME Spy Evolution or IMEC/University of Ghent)</li> <li>Locations of the target antennas</li> <li>Potentially location of the fixed sensor</li> </ul> </li> </ul>
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.