Note: If you are using this then do cite our work. https://ieeexplore.ieee.org/abstract/document/9186099

F. H. Kumbhar and S. Y. Shin, "DT-VAR: Decision Tree Predicted Compatibility based Vehicular Ad-hoc Reliable Routing," in IEEE Wireless Communications Letters, doi: 10.1109/LWC.2020.3021430.

Each row contains characteristic information related to two vehicles at time t. Data set feature set (column headings) are as follows: 

- Euclidean Distance: The shortest distance between two vehicles in meters

- Relative Velocity: The velocity of 2nd vehicles as seen from 1st vehicle

- Direction Difference: Given the direction information of each vehicle, the direction difference feature identifies the angle both vehicles are moving towards. For instance, two vehicles going on the same road can have direction difference 0, whereas two vehicles moving in the opposite direction will have a difference of 180. we calculated direction difference using: |((Direction of i - Direction of j+ 180)%360 - 180)| .

- Direction Difference Label: To ease the process for the supervised learning model, we also included direction difference label information by identifying three possible directions ( 0 if difference < 60, 2 if difference >120 and 1 if none of above)

- Tendency: The Tendency is an interesting label that is required to differentiate between two vehicles which are moving in opposite directions, but either they are approaching each other or moving away from each other. 

Target Label (Compatibility time): Our goal is to identify how long two vehicles will be in the communication range of each other. The predicted compatibility time label tells us five possible values:

L0 means Compatibility Time is 0

L1 means Compatibility Time is more than 2 seconds but less than 5 seconds

L2 means Compatibility Time is more than 5 seconds but less than 10 seconds

L3 means Compatibility Time is more than 10 seconds but less than 15 seconds

L4 means Compatibility Time is more than 15 seconds 

Since this is a multimodal database, the images in RWMF is related to texts by share the same tag, which is saved in `Foodhealth/im_label`

* `Foodlog`: the real-world food images and the associative instant bio-data
{
** `Image`: the folder that contains all the real-world foodlog images.
** `biodata.csv`: the csv file that contains all the associative instant bio-data, these data are associated to food images by the file names of images.
** `biodata.txt`: the txt that indicate the attributes of each column in `biodata.csv`.
** `data_category.csv`: the health category tags that help the model test the performance of cross-modal retrieval.
** `data_category.txt`: the txt that indicate the attributes of each column in `data_category.csv`.
}

* `Foodhealth`: the food description texts and the associative food nutrition composition data
{
** `description.csv`: the csv file that contains all the food description texts refered to each tag.
** `description.txt`: the txt file that indicate the attributes of each column in `description.csv`.
** `composition.csv`: the csv file that contains all the food nutrition composition data refered to each tag.
** `composition.txt`: the txt file that indicate the attributes of each column in `composition.csv`.
** `im_label.csv`: the csv file that contains all the tags related to each image.
** `im_label.txt`: the txt file that indicate the attributes of each column in `im_label.csv`.
}

The following data set is modelled after the implementers’ test data in 3GPP TS 33.501 “Security architecture and procedures for 5G System” with the same terminology. The data set corresponds to SUCI (Subscription Concealed Identifier) computation in the 5G UE (User Equipment) for IMSI (International Mobile Subscriber Identity) based SUPI (Subscription Permanent Identifier) and ECIES Profile A, the IMSI consists of MCC|MNC: '274012'. 

In the 5G system, the globally unique 5G subscription permanent identifier is called SUPI as defined in 3GPP TS 23.501. For privacy reasons, the SUPI from the 5G devices should not be transferred in clear text, and is instead concealed inside the privacy preserving SUCI. Consequently, the SUPI is privacy protected over-the-air of the 5G radio network by using the SUCI. For SUCIs containing IMSI based SUPI, the UE in essence conceals the MSIN (Mobile Subscriber Identification Number) part of the IMSI. On the 5G operator-side, the SIDF (Subscription Identifier De-concealing Function) of the UDM (Unified Data Management) is responsible for de-concealment of the SUCI and resolves the SUPI from the SUCI based on the protection scheme used to generate the SUCI. 

The SUCI protection scheme used in this data set is ECIES Profile A. The size of the scheme-output is a total of 256-bit public key, 64-bit MAC & 40-bit encrypted MSIN. The SUCI scheme-input MSIN is coded as hexadecimal digits using packed BCD coding where the order of digits within an octet is same as the order of MSIN. As the MSINs are odd number of digits, bits 5 to 8 of final octet is coded as ‘1111’.  

# Example Python code to load data into Spark DataFrame

df = spark.read.format("csv").option("inferSchema","true").option("header","true").option("sep",",").load(“5g_suci_using_ecies_profile_a_100k.gz”)

Provided dataset is cleased, pre-processed, and ready to use. The users may modify as they wish, but please cite the dataset as below.

M. A. Teixeira, M. Zolanvari, R. Jain, "WUSTL-IIOT-2018 Dataset for ICS (SCADA) Cybersecurity Research," 2018. [Online]. Available: https://www.cse.wustl.edu/~jain/iiot/index.html.

The dataset consists of 5 pcap files, namely, normal.pcap, sparta.pcap, scan_A.pcap, mqtt_bruteforce.pcap and scan_sU.pcap. Each file represents a recording of one scenario; normal operation, Sparta SSH brute-force, aggressive scan, MQTT brute-force and UDP scan respectively. The attack pcap files contain background normal operations. The attacker IP address is “192.168.2.5”. Basic packet features are extracted from the pcap files into CSV files with the same pcap file names. The features include flags, length, MQTT message parameters, etc. Later, unidirectional and bidirectional features are extracted.  It is important to note that for the bidirectional flows, some features (pointed as *) have two values—one for forward flow and one for the backward flow. The two features are recorded and distinguished by a prefix “fwd_” for forward and “bwd_” for backward. 

Copyright (C) 2018 Intel Corporation

SPDX-License-Identifier: BSD-3-Clause

#########################

Welcome to the Intel WiFi RTT (FTM) 40MHz dataset.

The paper and the dataset can be downloaded from:

https://www.researchgate.net/publication/329887019_A_Machine_Learning_Ap...

To cite the dataset and code, or for further details, please use:

Nir Dvorecki, Ofer Bar-Shalom, Leor Banin, and Yuval Amizur, "A Machine Learning Approach for Wi-Fi RTT Ranging," ION Technical Meeting ITM/PTTI 2019

For questions/comments contact: 

nir.dvorecki@intel.com,

ofer.bar-shalom@intel.com, 

leor.banin@intel.com, 

yuval.amizur@intel.com

The zip file contains the following files:

1) This README.txt file.

2) LICENSE.txt file.

3) RTT_data.csv - the dataset of FTM transactions

4) Helper Matlab files:

O mainFtmDatasetExample.m - main function to run in order to execute the Matlab example.

O PlotFTMchannel.m - plots the channels of a single FTM transaction.

O PlotFTMpositions.m - plots user and Access Point (AP) positions.

O ReadFtmMeasFile.m - reads the RTT_data.csv file to numeric Matlab matrix.

O SimpleFTMrangeEstimation.m - execute a simple range estimation on the entire dataset.

O Office1_40MHz_VenueFile.mat - contains a map of the office from which the dataset was gathered.

#########################

Running the Matlab example:

In order to run the Matlab simulation, extract the contents of the zip file and call the mainFtmDatasetExample() function from Matlab.

#########################

Contents of the dataset:

The RTT_data.csv file contains a header row, followed by 29581 rows of FTM transactions.

The first column of the header row includes an extra "%" in the begining, so that the entire csv file can be easily loaded to Matlab using the command: load('RTT_data.csv')

Indexing the csv columns from 1 (leftmost column) to 467 (rightmost column):

O column 1 - Timestamp of each measurement (sec)

O columns 2 to 4 - Ground truth (GT) position of the client at the time the measurement was taken (meters, in local frame)

O column 5 - Range, as estimated by the devices in real time (meters)

O columns 6 to 8 - Access Point (AP) position (meters, in local frame)

O column 9 - AP index/number, according the convention of the ION ITM 2019 paper

O column 10 - Ground truth range between the AP and client (meters)

O column 11 - Time of Departure (ToD) factor in meters, such that: TrueRange = (ToA_client + ToA_AP)*3e8/2 + ToD_factor (eq. 7 in the ION ITM paper, with "ToA" being tau_0 and the "ToD_factor" lumps up both nu initiator and nu responder)

O columns 12 to 467 - Complex channel estimates. Each channel contains 114 complex numbers denoting the frequency response of the channel at each WiFi tone:

O columns 12 to 125  - Complex channel estimates for first antenna from the client device

O columns 126 to 239 - Complex channel estimates for second antenna from the client device

O columns 240 to 353 - Complex channel estimates for first antenna from the AP device

O columns 354 to 467 - Complex channel estimates for second antenna from the AP device

The tone frequencies are given by: 312.5E3*[-58:-2, 2:58] Hz (e.g. column 12 of the csv contains the channel response at frequency fc-18.125MHz, where fc is the carrier wave frequency).

Note that the 3 tones around the baseband DC (i.e. around the frequency of the carrier wave), as well as the guard tones, are not included.