Conference PaperPDF Available

Enriching HTTP adaptive streaming with context awareness: A tunnel case study



Content may be subject to copyright.
Enriching HTTP Adaptive Streaming with
Context Awareness:
A Tunnel Case Study
Eirini Liotou, Tobias Hoßfeld, Christian Moldovan, Florian Metzger, Dimitris Tsolkas, and Nikos Passas
Department of Informatics & Telecommunications, National & Kapodistrian University of Athens, Greece
Chair of Modelling of Adaptive Systems, University of Duisburg-Essen, Germany
{eliotou, dtsolkas, passas}, {tobias.hossfeld, christian.moldovan, florian.metzger}
Abstract—Video streaming provided by Over-The-Top (OTT)
service providers through a cellular network is a common usage
scenario for many people today. While video streaming will work
reasonably well in a stationary scenario, several issues arise
for mobile users. For instance, travelling through short areas
without cellular coverage, such as an automobile tunnel, will
often result in quality degradation or video stalling. To combat
this, this paper provides an analytical investigation of the video
quality degradation problem as it is experienced by mobile users
and suggests a context-aware HTTP Adaptive Streaming (HAS)
strategy to prevent stalling and minimize the impact on Quality
of Experience (QoE). This provides a solution that can completely
prevent stalling when appropriate context information (such as
positional information from satellite navigation) is present. The
collected evaluation results encourage further research on how
context-awareness can be exploited to further enhance video
service provisioning by OTT service providers.
A. Motivation
Following the trend for video streaming, which currently
constitutes the majority of the Internet load [1], mobile opera-
tors, Internet Service Providers (ISP) and Over-The-Top (OTT)
players are very interested in understanding and, thereafter,
improving the Quality of Experience (QoE) of their customers
(end-users). Conventionally, each one of these stakeholders
makes use of their own available data and possible means of
controlling their end-users’ experience, intervening in parame-
ters that reside in different OSI layers. For instance, networks
providers can influence their customers’ QoE by controlling
QoS network parameters (e.g. implement packet prioritization,
traffic shaping, etc.), while OTT providers can control higher-
layer parameters (e.g. adapt the video resolution, encoding
rate, etc.). In parallel, end-users have mechanisms to control
their streaming experience, for instance using application layer
techniques, such as HTTP Adaptive Streaming (HAS) [2].
Beyond these interventions of different stakeholders to
isolated OSI layer parameters, the idea of designing cross-
party and cross-layer mechanisms has also emerged [3]. The
main challenge is to exploit the “context”, referring to any type
of information that raises the aforementioned isolation. More
specifically, context-awareness may be based on information
that a) is globally available or well-known (e.g. a map),
b) can realistically be passed on from one interested party
to another (e.g. information about network traffic or social
context information), or c) can be acquired from different OSI
layers or by other means (e.g. awareness of the signal strength
or the user’s speed at the application layer).
In this paper, we focus on video streaming scenarios and
show how context-awareness can enable more strategic de-
cisions towards guaranteeing a seamless viewing experience
of the end-users. Specifically, we focus on HAS, which is
currently becoming the prevalent way of video streaming
over the Internet. Our intention is to improve a client’s HAS
strategy by exploiting context information about the current
and future situation of the user.
To best reveal the context-awareness perspective in our
approach, we focus on a realistic scenario where a video
streaming user is moving towards a tunnel. Inside this tunnel
the user is expected to experience limited or zero-bandwidth
conditions, resulting in stalls during video playback. Since the
largest QoE-degrading factor for video streaming services is
the number of stalling events [4], the main objective of the
proposed scheme is to proactively avoid them. This can be
accomplished by taking pre-emptive measures to overcome
buffer depletion, in light of the context information that the
end-user is approaching a tunnel.
B. Related work and paper contribution
Enhanced HAS strategies that account for future network
conditions have lately emerged. The authors in [5] propose a
technique that identifies zero-bandwidth spatiotemporal events
and triggers the HAS client to react accordingly. They show
that by proposing a reactive “replace-request” method that
substitutes higher quality segment requests with lower quality
ones, stallings can be successfully prevented. However, in
more challenging cases, such as a tunnel scenario, proactive
rather that reactive HAS strategies are required in order to
sufficiently prepare for longer limited bandwidth conditions.
More similar to our approach, proactive HAS strategies
that take geolocation information into account are presented
in [6] and [7]. These strategies rely on the collection of
device measurements and the creation of a bandwidth lookup-
service, which is then used to improve the prediction of future
bandwidth availability. Our main differentiation with these
approaches is the exploitation of context-awareness in order
IEEE ICC 2016 - Communication QoS, Reliability and Modeling Symposium
978-1-4799-6664-6/16/$31.00 ©2016 IEEE
to avoid the constant signalling with a bandwidth database;
Therefore we propose a context-aware rather than a predictive
strategy. In parallel, our proposed strategy is complementary to
any other HAS strategy, since it can be activated at a specific
instant of time, when the need arises.
The paper’s contribution is summarized in the following:
A proactive HAS strategy based on context-awareness is
proposed, capable of avoiding stallings usually experienced
by streaming users under limited bandwidth conditions.
Under a realistic scenario (tunnel scenario), the problem of
preventing stalling events is described mathematically and
formulated as a linear programming problem. To solve this,
a close to optimal strategy in terms of QoE is proposed.
The minimum advance time, when the enhanced HAS
strategy should start running to guarantee a seamless video
streaming experience, is estimated both analytically and via
simulation. Constraints and dependency factors (e.g. tunnel
length) of this time parameter are investigated.
A comprehensive discussion on the feasibility of the pro-
posed approach into a real network is provided.
An extensive evaluation process is followed, including end-
users’ QoE assessment through subjectively-validated HAS-
compliant QoE models.
The remainder of this paper is organized as follows. In
Section II the system model is described and the problem
under study is formulated. The proposed context-aware HAS
strategy and the optimal solution are described in Section III.
Evaluation results are presented in Section IV, while Section V
concludes the paper.
A. Problem description: The tunnel scenario
Consider a mobile user streaming video content over TCP
(e.g. YouTube). Due to the unstable nature of the wireless
medium, mobility, and physical obstacles, the channel quality
may fluctuate significantly and, thus, the user may experience
“coverage holes”. The existence of a tunnel is a common
example of a coverage hole in a cellular environment, meaning
that users travelling through it will experience limited or no
connectivity. This event is described as an “outage”. For video
streaming users, such an outage will eventually lead to a
stalling event due to buffer depletion, i.e. to video freezing.
Figure 1: Problem description using buffer status information.
Assume a single streaming user inside a vehicle (e.g. a
bus or train) travelling in a particular direction and with a
specific speed (Figure 1). We assume, that the positioning
and the length of an upcoming tunnel are known in advance
(due to context awareness). Therefore, the remaining distance
between the vehicle and the tunnel’s entrance is also available
at the client side. This distance corresponds to a travelling
time of t. Let bbe the current buffer status of this user’s
HAS application; Then, during t, this buffer level will be
boosted by b+but also reduced by b. Throughout the tunnel,
the buffer will be reduced by btun. Note that inside the
tunnel there is negligible or no connection, so there is no
buffer boost, i.e. btun+= 0. When the user enters (exits)
the tunnel, the application’s buffer level will be btunin
(btunout), respectively, and it will hold that:
btunin =b+b+b,(1)
btunout =btunin btun.(2)
Then, we can express the objective of the proposed HAS
strategy as the following:
btunout bthres,(3)
which ensures that when the vehicle is exiting the tunnel, the
buffer status of the HAS application will be at least equal to
the minimum buffer threshold, bthres, and so the video playout
continues uninterrupted. Using equations (1) and (2) inside (3):
b+bthres +b+btunb. (4)
This condition answers the question about how much the
buffer of the HAS application needs to be pro-actively filled
during t, so that no stalling will occur. This should be achieved
despite the imminent connection disruption. Note that all the
parameters on the right hand side of (4) are known to the client
or can be easily estimated (bthres is fixed, bis directly known
to the client application, while b,btuncan be estimated).
In the next section, we estimate the minimum required time
tadv tto ensure a stalling-free video streaming.
B. Approaching the minimum required “advance time”
Based on the previous system model, at any point t, we
can estimate the b+, namely the required buffer boost (in
bytes or in seconds) to avoid any stalling inside the tunnel.
This measurement can be then further translated to a minimum
required “advance time”, tadv, when the travelling user needs
to start running the proposed proactive HAS strategy, at the
latest, in order to avoid stalling. The tadv should be sufficiently
large so that the user has enough time to react; Otherwise
a stalling will be inevitable, in which case the user can be
warned and be given the option to watch the video later. We
assume that the users switch from any standard HAS strategy
to the enhanced one exactly at tadv.
We can express b+as a function of tadv as follows:
where r(bytes per sec) is the estimated experienced data rate
by the client’s application. Namely, ris the user’s perception
of the average available network bandwidth, as estimated by
the HAS strategy. Therefore, the minimum required advance
time in order to avoid any stalling would be:
tadv bthres +b+btunb
tadv will ensure that b+will last for the whole zero-bandwidth
tunnel duration. Since users, however, may travel at different
speeds (u), it would make more sense to further translate this
“advance time” to “advance distance”. Then, the minimum
distance (in meters) before which the user needs to be notified
about the tunnel, xadv, would simply be xadv utadv .
The crucial question left to answer is: What is the quality
representation per video segment that has to be downloaded,
namely what is the synthesis of b+(which layers to be
downloaded and in what order).
In HAS, each video is encoded at the server side in multiple
representations with a different quality level per representation
(otherwise called “layer”). Different quality levels have differ-
ences in the video bit rate (bps) or in the video resolution, etc.
Each representation is divided into “segments” of a few sec-
onds each. The availability of these different layers becomes
available to each user through a manifest file, before streaming
starts. Then, each user requests the next segment that he wants
to download, with the objective to eliminate any stalling.
This decision is taken by each user independently based on
information available at his side, namely: a) the manifest file,
b) the user’s current buffer level, and c) a “short-sighted”
perception of the network congestion, as this is perceived by
the throughput of the last downloaded segment(s). Namely,
standard HAS relies on taking decisions in isolation from the
rest of the network and unaware of the future network state.
“Standard-HAS” approaches will inevitably lead to stallings
in challenging network conditions (e.g. a tunnel). This led us to
the proposed strategy that attempts to overcome the existence
of stalling events even in zero connectivity conditions. The
main idea to achieve this is to pro-actively and deliberately
decrease the quality level of the requested segments for the
video streaming application in advance (i.e. before the user
enters the tunnel). As a result, the user’s buffer when entering
the tunnel will be kept at a higher level during video playback
than it would have been without such a scheme. This idea
is presented in Figure 2. In this figure, the “real time” axis
represents either the time spent to download a segment (before
tunnel start) or the time it takes to play a segment (after tunnel
start). Note that the magnitude of these time values are not to
be compared with each other in this illustration.
We now approach the problem of finding the appropriate
quality segments that will sequentially fill the b+a) as an
optimization problem and b) using a proactive HAS strategy.
A. Optimal HAS
A video consists of nsegments of equal length τ. The
deadline Diof segment idescribes the point in time when
the segment needs to be completely downloaded. Since there
Figure 2: HAS scenario with and without context awareness.
is an initial delay T0before the video starts, according to [2]
it follows:
Di=T0+iτ, i= 1, ..., n. (7)
Each segment is available in rmax layers, whereas xij repre-
sents segment iin layer jwith a quality value wij (e.g. the
layer) and a size of Sij (in bytes). The total data that have been
downloaded at a point in time tis b(t). This leads to the next
optimization problem: Maximize the quality value (weighted
by α) minus the (undesired) number of switches (weighted by
β) for a single user without stalling (α+β= 1, α > 0, β > 0).
αwij xij
β(xij xi+1,j )2
subject to: xij ∈ {0,1}(8)
xij = 1,i= 1, ..., n (9)
Sij xij b(Dk),k= 1, ..., n (10)
The three constraints in this problem are interpreted as follows:
xij is a binary value (Eq. (8)), each segment has to be
downloaded in exactly one layer (Eq. (9)), and all segments
need to have been downloaded before their deadline (Eq. (10)).
Let us now define a tunnel by the points (l, m), meaning
that it starts at segment land ends at segment m. In order to
seamlessly view the video until mthroughout the tunnel, it
needs to have been downloaded until l. This can be expressed
by adding one last constraint to the optimization problem:
Sij xij b(Dl) = b(Dm),(l, m)(11)
Compare b(Dl)with b+in Eq. (4). Also, note that full knowl-
edge of all parameters is necessary to solve this optimization
problem. While this can hardly be achieved in a real scenario,
partial knowledge may allow for sufficiently good heuristics.
B. Proposed HAS strategy
Overall, the main objective of any HAS strategy is to find a
close-to-optimal buffering and quality level selection strategy
that avoids any stalling events.
The HAS strategy proposed here is based on the estimation
of the required buffer boost b+as this was described in
Section II-A. As for the estimation of the expected downlink
rate (network bandwidth prediction), this is assumed equal
to the segment rate. The segment rate estimation is done
over a sliding window of the past kdownloaded segments
as follows: r= (1 ω)Size of last (k1) segments
T ime to download (k1) segments +
ωSize of segment k
T ime to download segment k (in bytes per second), where
ωis the weight (importance) given to the latest downloaded
segment. Based on this rate estimation, the expected bytes
that can be downloaded until the user enters the tunnel
are: b+expected =rtadv (in bytes), as in (5), while the
minimum required buffered playtime b+to exit the tunnel
and avoid a stalling is given by (4), in seconds. Therefore,
the required bytes per segment are: required video rate =
b+(in bytes per second). Note that the higher the
tunnel duration, the larger the b+and thus the lower the
required video rate (lower layer selection). Based on the
required video rate estimation, the HAS strategy will request
the highest possible representation jthat fulfills this condition:
τrequired video rate. Namely, requested will be the
highest layer jthat yields a video bit rate less or equal to
this estimation. The “required video rate” estimation may be
updated each time in order to account for the most recently
achieved data rate r. Alternatively, an average value may be
calculated in the beginning (on tadv) and assumed valid until
entering the tunnel. (Note: we assume that the player requests
the lowest layer when initialized). Overall, this algorithm will
determine the selection of the next video segment, proactively
degrading the quality if required.
C. Realization in the network
Although we are not going to delve into details regarding the
realistic application of the proposed framework in a network,
we will give some insights. This discussion concerns the
type of cross-layer and cross-party context information that is
needed and how it may be acquired. The information, assumed
to be known for this approach, is:
The existence of a tunnel, namely the tunnel starting and
ending point (or, equivalently, its duration). This information
is taken into account by the enhanced HAS strategy to
find the appropriate activation time. The acquisition of such
information is considered realistically possible, since terrain
maps are/can be easily available at mobile phones.
Information about the user’s direction and speed is required
to predict whether the user will pass through a tunnel. This is
also available via GPS information (current location, speed
and trajectory combined with a terrain map) and it may be
estimated by the device itself by a path prediction algorithm.
The minimum advance time tadv or distance xadv at which
the user needs to activate the enhanced HAS strategy. These
estimations mainly depend on the tunnel duration, the user
speed and the user’s perception of the network data rate.
Since the user is capable of knowing about the existence of
a tunnel a priori, he can estimate b+based on (4) and then
tadv based on (6). Therefore, the user is able to activate
the enhanced HAS mode on tadv without any network
assistance, and hence, avoid/minimize a stalling.
The standard information required for HAS is needed as
well, namely information about the available video segments
(acquired from the server), an estimation of the available
network bandwidth for this user (estimated at the client as
the size of downloaded segments over the time required to
download those), and the current buffer state, which is also
known at the client’s application.
In order to conduct an evaluation, a proprietary Matlab
simulation has been created. We have implemented the client’s
buffer using a queuing model, where the downloaded segments
are considered as arrivals, and the played segments as depar-
tures. To simulate the network traffic, we rely on real traces
recorded from a network, namely on a realistic traffic pattern
recorded in a vehicular mobility scenario by [8].
For the purposes of this simulation, the following parameter
values have been considered (Table I):
Table I: Simulation parameters.
Parameters Value
Segment duration 2 sec
Number of video segments 350
Available representations (layers) per segment 3
Buffer playout threshold (initial delay) 10 segments
Buffer size Unlimited
Tunnel starting point 200 sec after sim start
Tunnel duration [0..400] sec
HAS policy sliding window 50 segments
Bandwidth factor 0.8
Network traces used 30 different traces [8]
alpha (beta) coefficient 0.95 (0.05)
A. Estimation of the minimum required advance time
First of all, we practically estimate the advance time, tadv,
when the user needs to switch to the enhanced HAS mode,
and study the impact of the tunnel duration on this metric.
Please note that in the proposed system model, the user will
execute the standard-HAS before tadv and the context-aware
HAS right after tadv.
100 150 200 250 300 350 400 450
Duration of the tunnel (sec)
Minimum required advance
time to avoid a stalling (sec)
100 150 200 250 300 350 400
Duration of the tunnel (sec)
Minimum required advance
distance to avoid a stalling (m)
user speed = 30km/h
user speed = 60km/h
user speed = 90km/h
user speed = 120km/h
Figure 3: Minimum required advance time (tadv) and distance
(xadv) to avoid a stalling event inside the tunnel.
The respective simulation results are presented in Figure 3.
We validate the expected trend, namely that an increase in
the tunnel duration mandates an earlier reaction by the user (a
higher tadv), so that the enhanced HAS strategy has more time
to overcome the imminent network outage. It is also interesting
to observe that the standard deviation also increases for higher
tunnel lengths, which means that the level of uncertainty is
0 100 200 300 400 500 600 700 800
3x 107
Time (sec)
Buffer size in bytes
Context−aware HAS
Standard HAS
Optimal HAS
(a) Buffer size evolution over time.
0 100 200 300 400 500 600 700 800
Time (sec)
Buffer playtime (sec)
Context−aware HAS
Standard HAS
Optimal HAS
(b) Buffer playtime evolution over time.
0 50 100 150 200 250 300 350
Segment number
HAS layer
Without context: # switches = 77
With context: # switches = 72
Optimal HAS: # switches = 3
(c) Selection of HAS layers.
0 100 200 300 400 500 600 700 800
Time (sec)
Context−aware HAS
Standard HAS
Optimal HAS
QoEno−stall = 0.003*e0.064t+2.498
(t = time on highest layer)
QoEstall = 3.5*e−(0.15*L+0.19)*N+1.5
(N, L = number and duration of
(d) QoE evolution over time.
Figure 4: Comparison of the standard HAS (blue dashed line), the context-aware HAS (red solid line) and the optimal solution (green
semi-dashed line): The standard HAS strategy results in stallings, while the context-aware/optimal strategy results in no stallings.
higher in these circumstances. The reason is that any predicted
estimation of the network data rate for the future is riskier
when there is a lot of time ahead before entering the tunnel.
For a better understanding of the previous results, we plot
the same scenario assuming different travel speeds of the users
and present the required xadv, to avoid a stalling (Figure 3).
B. Proof of concept
Having estimated the appropriate advance times, we conduct
simulations that serve as a proof of concept of the effectiveness
of the context-aware HAS. The goal is to demonstrate how the
proposed policy can indeed overcome an otherwise inevitable
buffer depletion and thus, prevent any stalling. To prove that,
we plot four different metrics: a) the client buffer size in bytes,
b) the client buffer size in seconds (i.e. playtime), c) the HAS
layers selected for each played out segment, and finally d) the
QoE evolution in time for the travelling user. For the latter,
we use the QoE models of [2] and [4], assuming that they
hold also in a real-time scale.
In Figure 4 we present a) the conventional case, when no
context information about the tunnel is available, and conse-
quently, the standard HAS strategy is continuously executed,
b) the context-aware case, which automatically leads to the
selection of the new HAS strategy after tadv and, c) the optimal
solution. Looking at Figure 4a we can see that a stalling of
around 80 sec is completely avoided. A similar conclusion is
drawn by Figure 4b. The explanation behind the prevention of
the stalling lies in Figure 4c: Having downloaded lower HAS
layers, the buffer of the context-aware HAS client is fuller in
terms of playtime. In Figure 4c, also the number of switches
among the different layers is given. The impact on QoE for
both cases is presented in Figure 4d, where we can see that
even a single stalling event with a duration of a few seconds
has a significant deteriorating impact on the perceived QoE,
as compared to the selection of lower HAS layers.
Compared to the optimal case, we can see that the number
of switches in the proposed strategy are more. The reason
is that this number is not a decisive factor in the proposed
strategy (Section III-B). However, according to subjective
studies [9], the impact of switches on the user experience is
much lower than the impact of the “time on the highest layer”,
which is the major QoE influence factor. In fact, in terms
of QoE, the proposed strategy performs very well. However,
QoE fluctuates more often, because, as shown in Figure 4c,
layer 3 is not selected continuously (as in the optimal case),
but often switches among all layers. (Note: An enhancement
of this algorithm to account for fluctuations is left for future
C. QoE-related studies
Now we present results regarding the HAS layer selection,
QoE, and number of switches, comparing the proposed strat-
egy to the optimum for different tunnel lengths. It is, firstly,
interesting to observe how the selection of the HAS layers
is influenced by the tunnel duration (Figure 5). The baseline
case, i.e. for no tunnel present, refers to the tunnel duration
equal to zero in the plots, where we can see that the highest
layer occupies around 51% of the time, while layers 2 and
1 occupy 44% and 5%, respectively. As the tunnel duration
keeps increasing, more segments of layer 2 are being selected
against those of layer 3, while for even larger tunnel lengths, it
is mandatory to download at layer 1 up to 50% of the time, in
order to avoid any stalling. For the same scenario, we present
the QoE trend, which is slightly decreasing as it depends on
layer 3’s percentage only. Finally, the number of switches is
also decreasing as layer 1 keeps substituting the rest. As a
result, fluctuations are avoided (though at the expense of QoE).
Note that since the impact of the highest layer is much more
significant than the switches’ number, we have selected the α
and βcoefficients of the optimization problem accordingly.
0 50 100 150 200 250 300 350 400
Tunnel duration (sec)
Percentage of time on
each HAS layer
Layer 3
Layer 2
Layer 1
(a) Layer selection for context-aware HAS.
0 50 100 150 200 250 300 350 400
Tunnel duration (sec)
Percentage of time on
each HAS layer
Layer 3
Layer 2
Layer 1
(b) Layer selection for optimal HAS.
0 50 100 150 200 250 300 350 400
Tunnel duration (sec)
Context−aware HAS
Optimal HAS
(c) QoE scores.
0 50 100 150 200 250 300 350 400
Tunnel duration (sec)
Number of switches
Context−aware HAS
Optimal HAS
(d) Number of switches.
Figure 5: The selection of HAS layers, the QoE, and number of switches for various tunnel lengths.
In this paper, we have presented an enhanced context-aware
HAS strategy, complementary to any standard HAS approach
implementation. The proposed policy can successfully help a
client’s application be better prepared for an inevitable service
outage and therefore be in the position to proactively minimize
any negative impact on the viewing experience. Since HAS is
considered a major trend in HTTP video streaming these days,
we believe that proactive strategies such as the one proposed
here will be soon available in real systems.
The proposed HAS strategy may run independently at the
end-user device, relying solely on information that can be
collected in a realistic environment. Therefore, it would be
feasible to implement a smart “app” that runs at the user device
and utilizes context and cross-layer information (map, speed,
GPS, etc.). Such an app could then give the streaming user
the power to prevent or minimize video stalling in light of a
well-known coverage hole, such as a tunnel or a metro line.
Furthermore, the idea introduced in this paper can be seen
as a video stalling alert mechanism (at tadv), and as such, it
can be exploited in multiple ways. The proposed HAS strategy
described in this paper is just one possible method, but other
approaches may be also possible: e.g. a strategy altering the
buffer size of the client, or, even the implementation of a pop-
up notification at the user device, warning about an inevitable
video stalling and requesting for a user action.
Last but not least, it is worth noting, that even though the
word “tunnel” in this paper has been used literally, it may
as well be used to characterize any areas of low or limited
connectivity and of concrete duration that can somehow be
learnt (e.g. by the collection of big data by multiple devices).
In that sense, the system model and insights of this paper can
be directly applied to other, broader, cases as well.
In future works, we are going to study HAS scenarios
that rely on different context information, such as social
context (e.g. Flash Crowd formation) or economic context (e.g.
adjusting video consumption to a user’s data plan). Moreover,
we plan to make the proposed strategy more robust to QoE
fluctuations or reduce the switching amplitude.
This work is supported by the COST Action “ACROSS” (IC1304)
and by the FP7-PEOPLE MITN-CROSSFIRE project (grant 317126).
[1] “Cisco visual networking index: Global mobile data traffic
forecast update 2014–2019 White Paper,” 2015.
[2] T. Hoßfeld et al., “Identifying QoE optimal adaptation of HTTP
adaptive streaming based on subjective studies,Computer
Networks, vol. 81, pp. 320–332, 2015.
[3] C. Verikoukis et al., “Cross-layer optimization for wireless
systems: A European research key challenge,Communications
Magazine, IEEE, vol. 43, no. 7, pp. 1–3, Jul. 2005.
[4] T. Hoßfeld et al., “Internet video delivery in YouTube: From
traffic measurements to Quality of Experience,” in Data Traffic
Monitoring and Analysis, ser. Lecture Notes in Computer Sci-
ence, vol. 7754, Springer Berlin Heidelberg, 2013, pp. 264–301.
[5] V. Ramamurthi et al., “Using link awareness for HTTP adaptive
streaming over changing wireless conditions,” in International
Conference on Computing, Networking and Communications
(ICNC), Feb. 2015, pp. 727–731.
[6] H. Riiser et al., “Video streaming using a location-based
bandwidth-lookup service for bitrate planning,” ACM Trans.
Multimedia Comput. Commun. Appl., vol. 8, no. 3, 24:1–24:19,
Aug. 2012.
[7] J. Hao et al., “Gtube: Geo-predictive video streaming over
HTTP in mobile environments,” in Proceedings of the 5th ACM
Multimedia Systems Conference, ser. MMSys ’14, Singapore:
ACM, 2014, pp. 259–270.
[8] C. Müller et al., “An evaluation of dynamic adaptive streaming
over HTTP in vehicular environments,” in Proceedings of the
4th Workshop on Mobile Video, ser. MoVid ’12, Chapel Hill,
North Carolina: ACM, 2012, pp. 37–42.
[9] T. Hoßfeld et al., “Assessing effect sizes of influence factors
towards a QoE model for HTTP adaptive streaming,” in Quality
of Multimedia Experience (QoMEX), 2014 Sixth International
Workshop on, Sep. 2014, pp. 111–116.
... Streaming performance can be enhanced when the client can exploit additional information in the rate adaptation. This information, often referred to as context, can include positioning data (e.g., GPS) or historical information on the available bandwidth [59,82,98]. As an example, a mobile streaming client can be made aware of regions with limited or zero-bandwidth conditions, as a tunnel, to proactively avoid video freezes. ...
... In the event of future scarce connectivity, the client can ramp-up its buffer in order to compensate this condition. Liotou et al. propose an algorithm that deliberately degrades the quality requested by the client to ramp-up its buffer and provide a continuous playout in the low-connectivity zone [59]. When historical data on the available bandwidth are coupled with GPS position information, the bandwidth prediction of adaptive streaming clients is greatly improved, as shown by Riiser et al. [82]. ...
... These works try to reduce the occurrence of freezes by using the context information to anticipate future bandwidth drops. Relevant references: [59], [82], [98]. ...
Full-text available
Video streaming applications currently dominate Internet traffic. Particularly, HTTP Adaptive Streaming (HAS) has emerged as the dominant standard for streaming videos over the best-effort Internet, thanks to its capability of matching the video quality to the available network resources. In HAS, the video client is equipped with a heuristic that dynamically decides the most suitable quality to stream the content, based on information such as the perceived network bandwidth or the video player buffer status. The goal of this heuristic is to optimize the quality as perceived by the user, the so-called Quality of Experience (QoE). Despite the many advantages brought by the adaptive streaming principle, optimizing users’ QoE is far from trivial. Current heuristics are still suboptimal when sudden bandwidth drops occur, especially in wireless environments, thus leading to freezes in the video playout, the main factor influencing users’ QoE. This issue is aggravated in case of live events, where the player buffer has to be kept as small as possible in order to reduce the playout delay between the user and the live signal. In light of the above, in recent years, several works have been proposed with the aim of extending the classical purely client-based structure of adaptive video streaming, in order to fully optimize users’ QoE. In this article, a survey is presented of research works on this topic together with a classification based on where the optimization takes place. This classification goes beyond client-based heuristics to investigate the usage of server- and network-assisted architectures and of new application and transport layer protocols. In addition, we outline the major challenges currently arising in the field of multimedia delivery, which are going to be of extreme relevance in future years.
... Streaming performance can be enhanced when the client can exploit additional information in the rate adaptation. This information, often referred to as context, can include positioning data (e.g., GPS) or historical information on the available bandwidth [73][74][75]. As an example, a mobile streaming client can be made aware of regions with limited or zero-bandwidth conditions, as a tunnel, to proactively avoid video freezes. ...
... In the event of future scarce connectivity, the client can ramp-up its buffer in order to compensate this condition. Liotou et al. propose an algorithm that deliberately degrades the quality requested by the client to rampup its buffer and provide a continuous playout in the low-connectivity zone [73]. When historical data on the available bandwidth are coupled with GPS position information, the bandwidth prediction of adaptive streaming clients is greatly improved, as shown by Riiser et al. [74]. ...
... These works try to reduce the occurrence of freezes by using the context information to anticipate future bandwidth drops. Relevant references: [73], [74], [75]. ...
... The remainder of this chapter is based on content that has been published in [8,3,9,10,14,20] and is structured as follows. First, we discuss background and related work on adaptation strategies. ...
... This is because the two-step approach puts very high value on the optimization of the quality level and very little emphasis on the number of switches. Luckily, this problem can easily be averted by using a slightly di erent approach: In [9], a method is proposed that combines both steps into one, allowing the number of switches to be emphasized higher at a negligibly low cost of quality. ...
Full-text available
In the past two decades, there has been a trend to move from traditional television to Internet-based video services. With video streaming becoming one of the most popular applications in the Internet and the current state of the art in media consumption, quality expectations of consumers are increasing. Low quality videos are no longer considered acceptable in contrast to some years ago due to the increased sizes and resolution of devices. If the high expectations of the users are not met and a video is delivered in poor quality, they often abandon the service. Therefore, Internet Service Providers (ISPs) and video service providers are facing the challenge of providing seamless multimedia delivery in high quality. Currently, during peak hours, video streaming causes almost 58\% of the downstream traffic on the Internet. With higher mobile bandwidth, mobile video streaming has also become commonplace. According to the 2019 Cisco Visual Networking Index, in 2022 79% of mobile traffic will be video traffic and, according to Ericsson, by 2025 video is forecasted to make up 76% of total Internet traffic. Ericsson further predicts that in 2024 over 1.4 billion devices will be subscribed to 5G, which will offer a downlink data rate of 100 Mbit/s in dense urban environments. One of the most important goals of ISPs and video service providers is for their users to have a high Quality of Experience (QoE). The QoE describes the degree of delight or annoyance a user experiences when using a service or application. In video streaming the QoE depends on how seamless a video is played and whether there are stalling events or quality degradations. These characteristics of a transmitted video are described as the application layer Quality of Service (QoS). In general, the QoS is defined as "the totality of characteristics of a telecommunications service that bear on its ability to satisfy stated and implied needs of the user of the service" by the ITU. The network layer QoS describes the performance of the network and is decisive for the application layer QoS. In Internet video, typically a buffer is used to store downloaded video segments to compensate for network fluctuations. If the buffer runs empty, stalling occurs. If the available bandwidth decreases temporarily, the video can still be played out from the buffer without interruption. There are different policies and parameters that determine how large the buffer is, at what buffer level to start the video, and at what buffer level to resume playout after stalling. These have to be finely tuned to achieve the highest QoE for the user. If the bandwidth decreases for a longer time period, a limited buffer will deplete and stalling can not be avoided. An important research question is how to configure the buffer optimally for different users and situations. In this work, we tackle this question using analytic models and measurement studies. With HTTP Adaptive Streaming (HAS), the video players have the capability to adapt the video bit rate at the client side according to the available network capacity. This way the depletion of the video buffer and thus stalling can be avoided. In HAS, the quality in which the video is played and the number of quality switches also has an impact on the QoE. Thus, an important problem is the adaptation of video streaming so that these parameters are optimized. In a shared WiFi multiple video users share a single bottleneck link and compete for bandwidth. In such a scenario, it is important that resources are allocated to users in a way that all can have a similar QoE. In this work, we therefore investigate the possible fairness gain when moving from network fairness towards application-layer QoS fairness. In mobile scenarios, the energy and data consumption of the user device are limited resources and they must be managed besides the QoE. Therefore, it is also necessary, to investigate solutions, that conserve these resources in mobile devices. But how can resources be conserved without sacrificing application layer QoS? As an example for such a solution, this work presents a new probabilistic adaptation algorithm that uses abandonment statistics for ts decision making, aiming at minimizing the resource consumption while maintaining high QoS. With current protocol developments such as 5G, bandwidths are increasing, latencies are decreasing and networks are becoming more stable, leading to higher QoS. This allows for new real time data intensive applications such as cloud gaming, virtual reality and augmented reality applications to become feasible on mobile devices which pose completely new research questions. The high energy consumption of such applications still remains an issue as the energy capacity of devices is currently not increasing as quickly as the available data rates. In this work we compare the optimal performance of different strategies for adaptive 360-degree video streaming.
... The importance of such context factors in QoE monitoring has been discussed in, e.g., [28]. In this specific case context information can be used to accurately handle the "tunnel scenario" [29], [30] to provide even better quality predictions to the community in the future. ...
... So, only KLU with 80 s buffer size can avoid some stalling events. Such scenarios are discussed in [30] where first solutions for outage prediction and handling are presented. We therefore recommend to choose a large buffer to reduce the number of stalling events in these rare events. ...
... Initially, we formulate the per-user segment selection strategy of HAS logic as a Knapsack optimization problem, using [38] as a basis. We consider a video split into = 1. . ...
Full-text available
While video streaming has dominated the Internet traffic, Video Service Providers (VSPs) compete on how to assure the best Quality of Experience (QoE) to their customers. HTTP Adaptive Streaming (HAS) has become the de facto way that helps VSPs work-around potential network bottlenecks that inevitably cause stallings. However, HAS-alone cannot guarantee a seamless viewing experience, since this highly relies on the Mobile Network Operators’ (MNOs) infrastructure and evolving network conditions. Software-Defined Networking (SDN) has brought new perspectives to this traditional paradigm where VSPs and MNOs are isolated, allowing the latter to open their network for more flexible, service-oriented programmability. This paper takes advantage of recent standardization trends in SDN and proposes a programmable QoE-SDN APP, enabling network exposure feedback from MNOs to VSPs towards network-aware video segment selection and caching, in the context of HAS. The video selection problem is formulated using Knapsack optimization and relaxed to partial sub-problems that provide segment encodings that can mitigate stallings. Furthermore, a mobility prediction mechanism based on the SLAW model is introduced, towards proactive segment caching. A number of use cases, enabled by the QoE-SDN APP, are designed to evaluate the proposed scheme, revealing QoE benefits for VSPs and bandwidth savings for MNOs.
... In order to optimize the adaptation in video streaming, we use a quadratic program which has already been presented in previous work: [13] and [14] investigate a mobile video streaming scenario in which a mobile client enters a tunnel. Even though no data can be downloaded in the tunnel, no stalling must occur in the video. ...
... Based on the current throughput in the client's CV and the retrieved bandwidth, the server determine the appropriate video rate to send. In [195], [205], location information is used to find the 'close-to-optimal' buffering strategy that prevents video stalling in an area of limited connectivity. Basically, the adaptation logic adjusts its buffer based on how close it is from a coverage hole, such as a tunnel; and how long the hole is. ...
Full-text available
HTTP Adaptive Streaming (HAS) is the most recent attempt regarding video quality adaptation. It enables cheap and easy to implement streaming technology without the need for a dedicated infrastructure. By using a combination of TCP and HTTP it has the advantage of reusing all the existing technologies designed for ordinary web usage. Equally important is that HAS traffic passes through firewalls and works well when NAT is deployed. The rate adaptation controller of HAS, commonly called Adaptive Bitrate Selection (ABR), is currently receiving a lot of attention from both industry and academia. However, most of the research efforts concentrate on a specific aspect or a particular methodology without considering the overall context. This paper presents a comprehensive survey of the most significant research activities in the area of client-side HTTP-based adaptive video streaming. It starts by decomposing the ABR module into three subcomponents, namely: resource estimation function, chunk request scheduling, and adaptation module. Each subcomponent encapsulates a particular function that is vital for the operation of an ABR scheme. A review of each of the subcomponents and how they interact with each other is presented. Furthermore, those external factors that are known to have a direct impact on the performance of an ABR module, like content nature, CDN, and context are discussed. In conclusion, the paper provides an extensive reference for further research in the field.
... This is because the two-step approach puts very high value on the optimization of the quality level and very little emphasis on the number of switches. Luckily, this problem can easily be averted by using a slightly different approach: In [20], a method is proposed that combines both steps into one, allowing the number of switches to be emphasized higher at a negligibly low cost of quality. ...
Full-text available
HTTP Adaptive Streaming (HAS) is employed by more and more video streaming services in the Internet. It allows to adapt the downloaded video quality to the current network conditions, and thus, avoids stalling (i.e., playback interruptions) to the greatest possible extend. The adaptation of video streams is done by switching between different quality representation levels, which influences the user perceived quality of the video stream. In this work, the influence of several adaptation parameters, namely, switch amplitude (i.e., quality level difference), switching frequency, and recency effects, on Quality of Experience (QoE) is investigated. Therefore, crowdsourcing experiments were conducted in order to collect subjective ratings for different adaptation-related test conditions. The results of these subjective studies indicate the influence of the adaptation parameters, and based on these findings a simplified QoE model for HAS is presented, which only relies on the switch amplitude and the playback time of each layer.
Full-text available
A lot of people around the world commute using public transportation and would like to spend this time viewing streamed video content such as news or sports updates. However, mobile wireless networks typically suffer from severe bandwidth fluctuations, and the networks are often completely unresponsive for several seconds, sometimes minutes. Today, there are several ways of adapting the video bitrate and thus the video quality to such fluctuations, for example, using scalable video codecs or segmented adaptive HTTP streaming that switches between nonscalable video streams encoded in different bitrates. Still, for a better long-term video playout experience that avoids disruptions and frequent quality changes while using existing video adaptation technology, it is desirable to perform bandwidth prediction and planned quality adaptation. This article describes a video streaming system for receivers equipped with a GPS. A receiver's download rate is constantly monitored, and periodically reported back to a central database along with associated GPS positional data. Thus, based on the current location, a streaming device can use a GPS-based bandwidth-lookup service in order to better predict the near-future bandwidth availability and create a schedule for the video playout that takes likely future availability into account. To create a prototype and perform initial tests, we conducted several field trials while commuting using public transportation. We show how our database has been used to predict bandwidth fluctuations and network outages, and how this information helps maintain uninterrupted playback with less compromise on video quality than possible without prediction.
Full-text available
This chapter investigates HTTP video streaming over the Internet for the YouTube platform. YouTube is used as concrete example and case study for video delivery over the Internet, since it is not only the most popular online video platform, but also generates a large share of traffic on today's Internet. We will describe the YouTube infrastructure as well as the underlying mechanisms for optimizing content delivery. Such mechanisms include server selection via DNS as well as application-layer traffic management. Furthermore, the impact of de-livery via the Internet on the user experienced quality (QoE) of YouTube video streaming is quantified. In this context, different QoE monitoring approaches are qualitatively compared and evaluated in terms of the accuracy of QoE estimation.
We address the problem of delivering streaming video over changing wireless conditions in the context of HTTP Adaptive Streaming (HAS) systems, such as those based on the Dynamic Adaptive Streaming over HTTP (DASH) standard [1, 2]. In HAS, the video client plays the primary role in rate adaptation unlike server controlled video delivery systems. Performance of adaptive streaming over rapidly changing wireless conditions degrades due to the slower time-scale of response at the application layer compared to the time scale of changing radio link conditions. We propose a novel physical layer aware video rate adaptation strategy for HAS systems in which the HAS client uses physical layer modem statistics as a complement to application layer throughput estimate to enable quick identification and response to changing radio link conditions. This novel HAS rate adaptation algorithm includes a 'Replace Request' feature wherein the HAS client can replace a current video segment request at the HAS server under suitable conditions. We demonstrate improved video streaming performance of our approach through simulations on a 3GPP LTE (Long Term Evolution) system level simulator.
HTTP Adaptive Streaming (HAS) technologies, e.g., Apple HLS or MPEG-DASH, automatically adapt the delivered video quality to the available network. This reduces stalling of the video but additionally introduces quality switches, which also influence the user-perceived Quality of Experience (QoE). In this work, we conduct a subjective study to identify the impact of adaptation parameters on QoE. The results indicate that the video quality has to be maximized first, and that the number of quality switches is less important. Based on these results, a method to compute the optimal QoE-optimal adaptation strategy for HAS on a per user basis with mixed-integer linear programming is presented. This QoE-optimal adaptation enables the benchmarking of existing adaptation algorithms for any given network condition. Moreover, the investigated concept is extended to a multi-user IPTV scenario. The question is answered whether video quality, and thereby, the QoE can be shared in a fair manner among the involved users.
Conference Paper
Mobile video streaming sometimes suffers from playback interruptions which are typically due to considerable network bandwidth variations that a user may experience when s/he travels along a route. Segmented adaptive HTTP streaming that switches between video streams encoded at different bitrates -- and hence different quality levels -- can be used to alleviate the issues of variable bandwidth. An important issue with respect to users' perceived experience is how the system schedules the quality levels to match the end-to-end network bandwidth capacity. It is very beneficial if the application can estimate the future network conditions in advance, and therefore perform quality control and buffer control wisely. This work describes GTube, a video streaming system for receivers equipped with a GPS positioning sensor in mobile environments. The available network bandwidth for each location is collected by mobile users and then this data along with the measured locations are uploaded and recorded in a server. Mobile devices that stream video can send queries to the server in order to better predict the near-future bandwidth availability and plan quality adaptations accordingly.
Conference Paper
MPEGs' Dynamic Adaptive Streaming over HTTP (MPEG-DASH) is an emerging standard designed for media delivery over the top of existing infrastructures and able to handle varying bandwidth conditions during a streaming session. This requirement is very important, specifically within mobile environments and, thus, DASH could potentially become a major driver for mobile multimedia streaming. Hence, this paper provides a detailed evaluation of our implementation of MPEG DASH compared to the most popular propriety systems, i.e., Microsoft Smooth Steaming, Adobe HTTP Dynamic Streaming, and Apple HTTP Live Streaming. In particular, these systems will be evaluated under restricted conditions which are due to vehicular mobility. In anticipation of the results, our prototype implementation of MPEG-DASH can very well compete with state-of-the-art solutions and, thus, can be regarded as a mature standard ready for industry adaption.
Using link awareness for HTTP adaptive streaming over changing wireless conditions
  • V Ramamurthi
V. Ramamurthi et al., "Using link awareness for HTTP adaptive streaming over changing wireless conditions," in International Conference on Computing, Networking and Communications (ICNC), Feb. 2015, pp. 727-731.