Datasets
Standard Dataset
NANCY SNS-JU project "Italtel Italian in-lab testbed - Latency metrics"
- Citation Author(s):
-
AntonellaClavenna
Italtel S.p.A.AntoninoAlbaneseItaltel S.p.A. - Submitted by:
- Antonella Clavenna
- Last updated:
- Tue, 04/23/2024 - 09:14
- DOI:
- 10.21227/1ts7-c931
- Data Format:
- License:
266 Views- Categories:
- Keywords:
Abstract
This Dataset provides input data for the development of the B-RAN and attacks models for the NANCY framework, to model training and model inference functions. The data collected plays the role of ML algorithm-specific data preparation. The dataset contains time-series, collected transmitting a video content through the Italtel "VTU - video streaming and transcoding application", that can convert audio and video streams from one format to another, at multiple encodings schemes, changing resolution, bitrate, and video parameters. The data collected are related to the observation of some of the resources involved in the Usage Scenario: “Fronthaul network of fixed topology – Direct Connectivity/CoMP Connectivity”. In the Italtel Italian in-lab testbed, a MEC assisted 5G network scenario with a video streaming application for generating traffic is provided. Two different scenarios were set-up, related to downstream and upstream video flows. Each file captured is associated to a 10min video streaming of the “Big Buck Bunny” video. This video was transmitted with different resolutions, 480p, 720p, 1080p, 2160p; both in uplink (UL) and in downlink (DL); the type of metrics monitored is RTT (Round Trip Time).
Scenario nr. 1: Pixel7 UE (client role) requires Video from ITL Video Streaming APP (server role)
Steps and useful information:
• Pixel7 UE requires Video from ITL Video Streaming APP
• Video server streams the video in different formats (480p, 720p, 1080p, 2160p)
• During each video playing, in different format, RTT is sampled using ping every 1 sec (Ping is trasmitted every 1 secs from the video server APP, along with 64bytes, 708bytes and 1358bytes payload packets).
RTT = (a+b+c)*2 (RTT is the sum of the crossing time of segments a+b+c multiplied by two, and it represents the round trip time from the upper protocol layer of the “video streaming app” to the upper protocol layer of the “video application” on the UE)
• Every 1 sec, DLbrate and ULbrate samples are captured on the gNB from “gNB trace” (point B in figure), while RTT_ms is captured on ITL Video Streaming APP (point E in figure).
File naming convention (instructions):
<UE type>_<video Format>_ping<packet size>;
values: “UE type” = Pixel7; “video Format” = 480p, 720p, 1080p, 2160p, 4320p; “packet size” = 64b, 708b, 1358b.
Additional graphic representation provided too, where RTT samples are plotted against time considering different cases:
a) Fixed video resolution (e.g. 480p) - different Ping payload
b) Fixed Ping payload (e.g. 64bytes) – different video resolutions
File naming convention (instructions):
a) <UE type>_<video Format>_PingReports.pdf and <UE type>_<video Format>_PingReports_dots.pdf
b) <UE type>_<ping packet size>bytes_PingReports.pdf and <UE type>_<ping packet size>bytes_PingReports_dots.pdf
Scenario 2: Pixel7 UE (server role) streams video to ITL Video Streaming APP (client role)
Additional dataset generated for latency metric, swapping roles between Pizel7 UE (server) and ITL Video Streaming APP (client).
Steps and useful information:
• Pixel7 UE streams video to ITL Video Streaming APP
• Pixel7 UE streams the video in different formats (480p, 720p, 1080p, 2160p)
• During each video playing, in different format, RTT is sampled using ping every 1 sec (Ping is trasmitted every 1 secs from the video server APP, along with 64bytes, 708bytes and 1358bytes payload packets).
RTT = (a+b+c)*2 (RTT is the sum of the crossing time of segments a+b+c multiplied by two, and it represents the round trip time from the upper protocol layer of the “video streaming app” to the upper protocol layer of the “video application” on the UE)
• Every 1 sec, DLbrate and ULbrate samples are captured on the gNB from “gNB trace” (point B in figure), while RTT_ms is captured on ITL Video Streaming APP (point E in figure).
File naming convention (instructions):
EdgeApp_<video Format>_ping<packet size>;
values: “UE type” = Pixel7; “video Format” = 480p, 720p, 1080p, 2160p, 4320p; “packet size” = 64b, 708b, 1358b.
Additional graphic representation provided too, where RTT samples are plotted against time considering different cases:
a) Fixed video resolution (e.g. 480p) - different Ping payload
b) Fixed Ping payload (e.g. 64bytes) – different video resolutions
File naming convention (instructions):
a) EdgeApp _<video Format>_PingReports.pdf and <UE type>_<video Format>_PingReports_dots.pdf
b) EdgeApp _<ping packet size>bytes_PingReports.pdf and <UE type>_<ping packet size>bytes_PingReports_dots.pdf
An additional set of RTT samples has been collected for a duration equivalent to that of the video stream and under conditions of no data flow/traffic along the path. This makes it possible to sample RTT in order to collect reference values, which depend solely on the characteristics of the devices used in the testbed (to set the baseline of the testbed conditions and its inherent limitations related to specific equipment).
File naming convention:
Pixel7_novideo_ping<packet size>;
EdgeApp_novideo_ping<packet size>;
values: “packet size” = 64b, 708b, 1358b.
The collected dataset is representative resource-intensive video traffic that has the greatest impact on 5G/B5G network planning and provisioning. In each experiment, we fixed the location of the UE and the gNB.
Dataset Files
- RTT.zip (785.69 kB)
- RTT_novideo.zip (8.89 kB)
- Pixel7_NoVideo_PingReport.zip (45.03 kB)
