Join the CRAWDAD community

Reset your CRAWDAD account password

Datasets and tools by name

Datasets and tools by release date

Datasets and tools by keyword:

Datasets by measurement purpose:

About the CRAWDAD project

CRAWDAD contributors by country


Privacy Policy

Contact Us

CRAWDAD sponsors

Related websites


 Search CRAWDAD via Google:

The eurecom/elasticmon5G2019 dataset (v. 2019-08-29)  >  the 02-PreprocessedDatasets traceset

There is 1 trace in this traceset
last modified
short description

Processed monitoring data (derives from traceset 01-RawDatasets) by adding timestamps and cleaning out (i) corrupt\/inaccurate metric values and (ii) static values.


URL: ftp:/

A necessary pre-processing takes place to give a proper structure to raw recordings and to reduce the number of metrics per measurement from over 100 to 42.

In brief, each of the five comma-separated files in the second (processed) traceset contains:

-1- moving-away.csv: the UE moves away from the eNB to a maximum distance of 10 meters.

-2- movingcloserfarcloser.csv: the UE moves back and forth relative to the eNB, from a 0 distance up to approximately 10 meters.

-3- stableshortdistance.csv: the UE stands still in a short distance (approx., 0-1m) away from the eNB.

-4- stablemiddistance.csv: the UE stands still in a mid-distance (approx., 1-5m) away from the eNB.

-5- stablelongdistance.csv: the UE stands still in a long-distance (approx., 5-10m) away from the eNB.

reason for most recent change
the initial version
release date
date/time of measurement start
date/time of measurement end

This traceset derives from the raw monitoring date traceset. A necessary pre-processing takes place to give a proper structure to raw recordings and to reduce the number of metrics per measurement from over 100 to 42. Pre-processing is necessary for a series of reasons:

 → Adding a timestamp: Exact dates in raw measurements do not give useful information. It is necessary to add timestamps inside the recorded JSON tree of each measurement. This is needed for computing the time elapsed between consecutive measurements. → Cleaning out static values: Omitting specific metric fields that do not change over time. Such metrics maintain in a constant value across measurements regardless of the UE being in motion or not. Therefore, they offer no valuable information for prediction. Note that the remaining "dynamic" metrics after this step drops to 42. → Adjusting corrupt\/inaccurate metric values: There are measurements such as "macStats_phr", with corrupt\/inaccurate values due to integer overflow. The problem is addressed based on the type of metric and number of consecutive corrupt\/inaccurate values by replacing evidently corrupt\/inaccurate values with either (a) the median value of their neighboring rows or (b) the mean value over a period of time (e.g., past 100ms) out of a series of neighboring rows (resp., 100 rows). Option (a) was used in cases where consequent values created a trend that was not matched by the identified as “corrupt\/inaccurate” value, while option (b) was preferred for particular types of metrics such as “macStats_phr”. 
 the eurecom/elasticmon5G2019/ 02-PreprocessedDatasets/ trace
 how to cite this traceset