FORGE Course

 

Full Height |  Two columns |  Parts | 

DASH streaming over wireless HetNets

DASH streaming over wireless HetNets University of Thessaly 30/06/2016 English
Wireless Networking HetNet DASH Streaming Handover

What is DASH?

What is DASH? University of Thessaly 30/06/2016 English
DASH
Mobile video has become an essential Internet service. This is due to several important trends: 
  1. An increasing number of people own smartphones, tables, and other mobile devices that can support video. 
  2. Wireless Internet service is improving, enabling high-bandwidth applications like video. 
  3. More video content is being made available to consumers over the Internet, instead of (or in addition to) traditional methods like TV. 
Mobile users expect the same high-quality video they would get if they were connected to a wired network, but this is a challenge when their link quality is constantly changing. If you send high-quality video, it will have to pause to buffer very often if the user's link quality is bad. If you send low-quality video, the user will be unhappy with the service. 

A common approach to this problem is to use adaptive video, in which the quality of the video sent to the user can change in time. That is, the user gets high-quality video when their link quality is good, and low-quality video (which can be transmitted without having to pause for buffering) when their link quality is poor. 

To do this, we divide the video into segments of a fixed size, and encode each segment at several different rates. The version of the segment sent to the client can depend on any part of the client's context (link quality, computing power, battery power) or the network context (network load, number of high-priority users in the network). 

DASH (Dynamic Adaptive Streaming HTTP) is a standard for adaptive video which is used in many commercial video products. DASH standardizes how to describe and address the different versions of the video content using a file called a Media Presentation Description (MPD) file. However, DASH does not standardize which version of a segment is sent to the client under what conditions - what we call a decision policy. That is left up to the individual implementation.DASH is an application-layer protocol which means that it doesn't try to control the underlying network - rather, it tries to understand what kind of service the network provides and adapt accordingly.


Figure 1: The DASH Architecture

The DASH policies for rate adaptation

The DASH policies for rate adaptation University of Thessaly 30/06/2016 English
DASH Rate Adaptation
In this experiment, we're going to run a VLC DASH client to retrieve a video from a DASH server over a wireless heterogeneous network (details given below). The DASH client always starts by downloading the MPD file, which describes what versions of the video (i.e., different bitrates) are available and what URL to get each video segment from. Go look at the MPD file for this course, which is available here. In this file, you will see some Representation stanzas that look like this: 

Representation id="0" codecs="avc1" mimeType="video/mp4" width="480" height="360" startWithSAP="1" bandwidth="101492"
Each Representation of the video represents another quality level. The one above, for example, is encoded at a bitrate of 101492 bps with a resolution of 480x360 pixels. Following each Representation in the MPD file, there is a list of URLs for each video file encoded at that bit rate. Look at the rest of the MPD file and try to find the rest of the Representation stanzas. At how many different bitrates is this video available? What are the bitrates? Make a note of these values. 

You will be able to run a series of experiments trying to evaluate 3 DASH rate; adaptation policies. In all of these policies, the client selects the highest available bitrate (We'll call the rate it selects the chosen rate) for a segment that is lower than some perceived available bitrate (We'll call this estimate the decision rate). The decision rate is first estimated as the actual bitrate observed over the download of the last segment (We'll call this the empirical rate). Then, it is adjusted according to one of the following policies:
  1. Policy 1: When the buffer is less than 30% full, the decision rate is zero, and the chosen rate is the lowest representation available.
  2. Policy 2: The decision rate is not adjusted, i.e. it is always equal to the actual bitrate observed over the download of the last segment (empirical rate).
  3. Policy 3: When the buffer is less than 30% full, the decision rate is equal to half of the actual bitrate observed over the download of the last segment (empirical rate).
These policies involve a trade-off between video rate and buffer status. Obviously, we want to download segments of a high video rate, because these offer better quality. However, we also want to avoid freezes (the state where there is zero video in the buffer) and we want the video playback to be smooth, avoiding big jumps in video rate. This experiment is about the interaction between a video protocol - DASH - and a network. The interaction between them depends on the decision policy we described previously.

There will be two major network quality factors affecting the video rate: 
  1. Wireless link quality (RSSI)
  2. Traffic on the network from other users
There will also be certain indicators of video quality we'll look for. These include:
  1. Smoothness. Do the changes in bitrate happen abruptly, or are they gradual?
  2. Average rate. Is the video delivered at a high rate most of the time?
  3. Interruptions. Does the video ever freeze? (A freeze occurs when the buffer status reaching zero percent)
Finally, we also want to think about the quality of the adaptation - does the adaptation policy make full use of the available bandwidth on the network?

HetNet and Handover

HetNet and Handover University of Thessaly 11/07/2016 English
HetNet Handover
HetNet (Heterogeneous Network)  is a word used for describing wireless networks that leverage on different access technologies. The most typical example is a wireless network that provides a service through a wireless LAN and is able to maintain the service, when switching to a cellular network. This representative example is provided through this course, where you are able to build a wireless HetNet consisting of a DASH server and a DASH client, connected through two wireless access networks of different wireless technologies (WiFi, LTE, WiMAX, etc.). You are able to select and configure the two wireless access networks and their features, through the interactive widget that is given below.

During the DASH video streaming over the HetNet, you will also be able to describe the time of the handover events will be done. Handover refers to the process of transferring a data session from one network (e.g. the LTE network) to another (e.g. the WiFi network). The handover mechanism is based on the work done by Makris et al., published in "Forging Client Mobility with OpenFlow: en experimental study".

Please, explore the widget below to understand deeper the capabilities of DASH video streaming and the challenges that come from the use of HetNets. 

VLC DASH streaming

VLC DASH streaming University of Thessaly 11/07/2016 English
Wireless Networking HetNet DASH Streaming Handover
You can use the widget below to configure the number of nodes that will be used for your experiment (between 3 to 5 nodes), the DASH policy used for choosing the video rate (between 1 to 3), and the times of the handover events, keeping in mind that the duration of the whole video streaming is 60 seconds.
For example, in case that the selected number of nodes is 5, you will observe the following topology:


Figure 2: 5-nodes Topology Example

where there is a label under each node with its role and identity. The upper-left node is the DASH server, the upper-right node is the DASH client, eNodeB connects the two nodes with the LTE/WiMAX technology, while the other nodes are used for connecting them through a 4-hop ad-hoc WiFi network. The widget is responsible for reserving the eNodeB and 5 nodes from the NITOS testbed, as well as to develop this network. Then, by using the OMF framework, an experiment will be developed and executed according to the configured parameters given by you (DASH policy and timing of Handover events).  
During the preparation time, messages will be printed to inform you about the current status in the setup of the desired network topology. 
At the end, live monitoring of the experiment will be provided through a dashboard including three plots. One is for the used video rate, which is chosen according to your selected DASH policy, one for the status of the packet buffer on the DASH client, and one for the video rate that is streamed over each wireless technology.
In the figure below, you see the results of such an experiment, where the handover from WiFi to LTE is done after 25 seconds of experiment runtime and the handover from LTE to WiFi after 45 seconds (the two moments are noted with blue lines and the end of experiment with a red line). At the end of the experiment, you are able to see the streamed video by clicking on the green button, or to click the blue button to release the resources.


Figure 3: Snapshot of the Dashboard