## A Perceptual Study of the Decoding Process of the SoftCast Wireless Video Broadcast Scheme

The SoftCast scheme has been proposed as a promising alternative to traditional video broadcasting systems in wireless environments. In its current form, SoftCast performs image decoding at the receiver side by using a Linear Least Square Error (LLSE) estimator. Such approach maximizes the reconstructed quality in terms of Peak Signal-to-Noise Ratio (PSNR). However, we show that the LLSE induces an annoying blur effect at low Channel Signal-to-Noise Ratio (CSNR) quality. To cancel this artifact, we propose to replace the LLSE estimator by the Zero-Forcing (ZF) one.

Instructions:

Anthony Trioux, Giuseppe Valenzise, Marco Cagnazzo, Michel Kieffer, François-Xavier Coudoux, et al., A Perceptual Study of the Decoding Process of the SoftCast Wireless Video Broadcast Scheme. 2021 IEEE Workshop on Multimedia Signal Processing (MMSP), Oct. 2021, Tampere, Finland.

The SoftCast Database consists of 8 RAW HD reference videos and 156 cropped videos transmitted and received through the SoftCast linear video coding and transmission scheme considering either the LLSE or the ZF estimator. Each video has a duration of 5 seconds. Note that only the luminance is considered in this database. Furthermore, the number of frames depends on the framerate of the video (125 frames for 25fps and 150frames for 30fps).

The GoP-size was set to 32 frames, 2 compression ratio (CR) were considered: CR=1 (no compression applied) and CR=0.25 (75% of the DCT coefficients are discarded before transmission). The Channel Signal-to-Noise Ratio (CSNR) considered in this test vary from 0 to 27dB by 3dB step. This database was evaluated by 30 participants (9 women and 21 men). They were asked to select which one of the two displayed version of the reconstructed videos they prefered based on a Forced-choice PairWise Comparison test. A training session was organized prior to the test for each observer in order to familiarize them with the procedure.

Video files are named using the following structure:

Video_filename_y_only_GoP_32_CR_X_Y_ZdB_crop.yuv where X equals either 1 or 0.25 Y refers to the estimator used (ZF or LLSE) and Z is either equal to 0,3,6,9,12,15,18,21,24 or 27dB.

The original video files are denoted: Video_filename_y_only_crop.yuv.

Each video file is in *.yuv format (4:2:0) where the chrominance plans are all set to 128. (This process allows to perform the VMAF computation as VMAF requires either a yuv420p, yuv422p, yuv444p, yuv420p10le, yuv422p10le or yuv444p10le video format).

The preference scores for each of the stimuli are available in the PWC_scores.xls file.

The objective scores (frame by frame) for each videos are available in the objective_scores_ZF_LLSE.zip file.

Categories:
126 Views

## Simulated Megaconstellation Ephemerides

Time-varying positions, velocities, and orbital elements of 1584 satellites in a simulated megaconstellation modelled on Phase 1 of SpaceX’s Starlink.

Instructions:

Please refer to the attached documentation for a detailed description.

Categories:
74 Views

## Multi-Conductor Power Line Communication CTF, Impendance, and Noise

Several experimental measurement campaigns have been carried out to characterize Power Line Communication (PLC) noise and channel transfer functions (CTFs). This dataset contains a subset of the PLC CTFs, impedances, and noise traces measured in an in-building scenario.

The MIMO 2x2 CTFs matrices are acquired in the frequency domain, with a resolution of 74.769kHz, in the frequency range 1 - 100MHz. Noise traces, in the time domain with a duration of about 16 ms, have been acquired concurrently from the two multi-conductor ports.

Instructions:

The dataset is available in the MATLAB format *.mat. The instructions and basic examples to display data are available in "script_load_dataset.m".

Categories:
120 Views

## Crashing Waves: An Empirical Vehicle-to-Barrier Communication Channel Model via Crash Tests

Vehicle-to-barrier (V2B) communications is an emerging communication technology between vehicles and roadside barriers to mitigate run-off-road crashes, which result in more than half of the traffic-related fatalities in the United States. To ensure V2B connectivity, establishing a reliable V2B channel is necessary before a potential crash, such that real-time information from barriers can help (semi-)autonomous vehicles make informed decisions. However, the characteristics of the V2B channel are not yet well understood.

Instructions:

In this repository, data for five different crash tests are uploaded. The details about each of these crash tests are discussed in the paper. The data for each crash test are categorized according to the USRP log files, Crash test photos & videos, Crash vehicle acceleration sensor data, and Crashed barrier design & dimensions.

Categories:
153 Views

## Supplemental Information for A Signal-Space Distance Measure for Nondispersive Optical Fiber''

This file contains the Supplemental Information cited in:

R. Rafie Borujeny and F. R. Kschischang, A Signal-Space Distance Measure for Nondispersive Optical Fibersubmitted to IEEE Transactions on Information Theory.

This file is a header file written in C containing the numerical values as well as the function that calculates the approximation of the adversarial distance.

Instructions:

This header file contains a routine that can be used to computed

the adversarial distance between two complex points according to

the formulation given in

@misc{borujeny2020signalspace,

title={A Signal-Space Distance Measure for Nondispersive Optical Fiber},

author={Reza Rafie Borujeny and Frank R. Kschischang},

year={2020},

eprint={2001.08663},

archivePrefix={arXiv},

primaryClass={cs.IT}

}

https://arxiv.org/abs/2001.08663

The distance calculations are performed based on the approximation

given in the above manuscript. For the normalized evolution equation

q'(z) = i * |q(z)| ^ 2 * q(z) + n(z), 0 < z < 1,

for two complex numbers z1 and z2, with polar coordinates

z1 = r1 * exp(i * t1),

z2 = r2 * exp(i * t2),

the approximation of the adversarial distance is given by

d(z1, z2) = (1 / 4) * (r1 - r2) ^ 2 +

a(r1, r2) * sin^2(( t2 - t1 - \phi(r1, r2) ) / 2).

The function a(r1, r2) is approximated using numerical methods,

as described in the reference manuscript, and the corresponding

values are given below in the array a_fit. The function distance

below calculates the adversarial distance between two points. For

use with the unnormalized equation

q'(z) = i * GAMMA * |q(z)| ^ 2 * q(z) + n(z), 0 < z < L,

you should change the assigned values to L and GAMMA in the

associated macros.

*/

/*

This file contains the following:

1- a macro named L, which represents the length of the

fiber in [km]

2- a macro named GAMMA, which represents the nonlinearity

coefficient in [1/W/km]

3- a macro INDEX(i,j), which converts 2-D index to 1-D

indexing to access the array a_fit (to be described later).

4- an array of doubles X, which contains the 31 grid points along the

x-axis. This grid points are the same along the y-axis as well. That

is, for any x in X, and any y in X, we have a corresponding

value a(x, y) in the array a_fit.

5- a double DX, which is equal to the increment between the grid points

in the x-axis, i.e., DX = X[1] - X[0]

6- a double DA, which is equal to the area of a surface area element,

i.e., DA = (X[1] - X[0]) * (X[1] - X[0])

7- a function distance, which takes two complex numbers in polar

coordinates and calculates the adversarial distance between them. This

function uses bi-linear approximation to estimate A(x,y) from the

existing numerical values given in a_fit.

Categories:
30 Views

## 5G Campus Networks: Measurement Traces

This data set contains packet captures (PCAPs) of a 5G campus network.

The corresponding paper can be found at 5G Campus Networks: A First Measurement Study

Instructions:

The instructions are within the READMEs(.md/.pdf).

In addition the source code of this project is available on Github: https://github.com/justus-comnets/5g-campus-measurements

Categories:
427 Views

## Massive User Transmission Enabled Combinatorial Based Non-Orthogonal Multiple Access Wireless Networks With Theoretical Analysis simulation

This is the MATLAB .fig file from the paper "Massive User Transmission Enabled Combinatorial Based Non-Orthogonal Multiple Access Wireless Networks With Theoretical Analysis"

Categories:
106 Views

## Augmented Reality Streams for Cloud-Based Rendering

A promising technique to realize augmented reality on future light-weight glasses is to offload computationally extensive rendering tasks to the cloud. This however places considerable demands on the network as well as the air interface with respect to latency, reliability and throughput. For evaluation of these architectures and for traffic modelling, a dataset is provided, which contains realistic payloads of cloud-rendered augmented reality in form of video files.

Instructions:

Provided are the raw video files after rendering with a resolution of 7200x6360 pixels. For low-latency encoding libx264 ffmpeg version 4.2.4 was used with flags -preset ultrafast -tune zerolatency at a target bitrate of 8Mbit/s. The streaming is taking place with ffmpeg and the custom nut output muxer. The resulting packetized output is sent to a UDP port on localhost. The encoded video files as well as the captured traffic traces are provided.

Categories:
120 Views

In this paper, we propose a novel resource management scheme that jointly allocates the transmitpower and computational resources in a centralized radio access network architecture. The networkcomprises a set of computing nodes to which the requested tasks of different users are offloaded. Theoptimization problem minimizes the energy consumption of task offloading while takes the end-to-end latency, i.e., the transmission, execution, and propagation latencies of each task, into account.

Instructions:

Notes on the simulation files:

1.   Number of single-antenna users, which is equal to the number of tasks

2.   Maximum acceptable latency of tasks

3.   Ratio of RAN latency to the maximum acceptable latency

5.   Data size of each task

After receiving the parameters, DTO.m executes the disjoint method and returns the outputs as in the following:

1.      Acceptance Ratio

3.   Propagation latency of all tasks

4.   Execution latency of all tasks

1.      Number of single-antenna users, which is equal to the number of tasks.

2.   Maximum acceptable latency of tasks

4.   Data size of each task.

After receiving the parameters, JTO.m executes the disjoint method and returns the outputs as in the following:

1.      Acceptance Ratio

3.   Propagation latency of all tasks

4.   Execution latency of all tasks.

Categories:
87 Views

## In-browser and network traffic based web response time measurements

This repository contains the results of 30 public Internet browsing experiments, from a computer at the campus network of the Public University of Navarre, out of which 20 used plaintext HTTP browsing, while 10 used HTTPS. We present both the original data sources in the form of network packet traces and HAR waterfalls, as well as the processed results formatted as line-based text files.

Instructions:

Each experiment consisted of a Selenium-automated web browser (Google Chrome 80.0) visiting a set of predefined web sites, with all caching options disabled. Both network packet traffic traces and in-browser measurements were collected. The network measurements were collected using tcpdump running at the client, while in-browser measurements were collected through the HAR Export Trigger extension. We have uploaded both sets of files.

The sets of websites for HTTP and HTTPS experiments are different, as modern web sites usually support HTTPS but not HTTP. The HTTPS set was obtained by collecting the top 2000 web sites from the Alexa Top Ranking. The HTTP set is the subset of these top 2000 websites, those that supported plain-text HTTP. To extend the amount of measurements of plain HTTP traffic, each of these websites was crawled, following the embedded ‘http://’ links.

For each web resource requested by the browser, we computed the time elapsed between the HTTP request being sent and the response being fully received; this is referred to as the resource's response time. Each response time obtained, along with the URL for that resource, and the timestamp at which the request was made, is referred to as a sample. These samples are obtained from the browser measurements and from network traffic. For the HTTPS experiments, the network data was decrypted using the ephemeral per-session encryption keys generated by the web browser. The files containing these keys have also been uploaded.

A number of resources are requested more than once during each test, such as cascade style sheets or images. Although we deactivated the cache, the browser still sometimes reported some resources as requested with a false response time of zero, since the request is never issued to the server but obtained from a cache. Also, a small number of requests trigger an exception in the browser, which prevents data being collected at the client side, although the request and response are present in the network traffic. These behaviours complicate one-to-one comparisons between network and in-browser measurements because a different number of response times for a specific resource may be found in the network traffic and in the browser report. We exported to text files only the first response time seen for each resource with a unique URL. This filtering removes false measurements reported by the browser. In case this filtering is not desired, all the data can be obtained from the pcap and HAR files uploaded.

The dataset contains the original PCAP and HAR files, and also the post-processed files obtained from them. The raw data is contained in the raw_http.zip and raw_https.zip files, while the post-processed files are contained in the data.zip file. Inside the data.zip archive there are two directories, corresponding to the HTTP and HTTPS experiments respectively.

Both raw data archives contain files named X.pcap and subdirectories named X_har (with X being the name of each individual experiment), corresponding to the data gathered from network traces and in-browser measurements respectively. Inside each X_har directory, a .har file is stored for each visited site with the full download waterfall. Additionally, decryption keys for the HTTPS experiments are provided, under the name of X.key.

The data.zip archive contains three files for each experiment, amounting to a total of 60 and 30 files for HTTP and HTTPS respectively.

The three files describing each experiment contain line-based text data, and are named X_network_tresp.txt, X_browser_tresp.txt and X_conn_info.txt, with X being the name of each individual experiment. The first two files contain, on each line, space-separated fields describing a single request-response sample. X_network_tresp.txt contains the information gathered from network traces, while X_browser_tresp.txt was obtained from browser instrumentation. On the other hand, X_conn_info.txt contains, on each line, space-separated fields related to each TCP connection present during the experiment, obtained through network traces.

The connections in X_conn_info.txt and the samples in X_network_tresp.txt are associated through a unique connection ID field present in each line in both files. Note that this is a one-to-many relationship, meaning that a connection ID is associated to a single TCP stream (i.e. line in X_conn_info.txt), but one or more samples (i.e. lines in X_network_tresp.txt).

We describe below the line format for each file. This information is included as well in the "format.txt" file, located on the top level directory of the compressed archive.

X_conn_info.txt:

Connection ID

RTT (milliseconds)

Number of retransmissions

Number of sequence holes

Number of data packets, client to server

Number of data packets, server to client

X_network_tresp.txt:

Request timestamp (seconds)

Response time (seconds)

Requested URL

Response size (bytes)

Connection ID

X_browser_tresp.txt:

Request timestamp (seconds)

Response time (seconds)

Requested URL

Categories:
130 Views