###### Abstract

Multimedia applications, mainly video streaming services, are currently the
dominant source of network load worldwide. In recent Video-on-Demand (VoD) and
live video streaming services, traditional streaming delivery techniques have
been replaced by adaptive solutions based on the HTTP protocol. Current trends
toward high-resolution (e.g., 8K) and/or low-latency VoD and live video
streaming pose new challenges to end-to-end (E2E) bandwidth demand and have
stringent delay requirements. To do this, video providers typically rely on
Content Delivery Networks (CDNs) to ensure that they provide scalable video
streaming services. To support future streaming scenarios involving millions
of users, it is necessary to increase the CDNs’ efficiency. It is widely
agreed that these requirements may be satisfied by adopting emerging
networking techniques to present Network-Assisted Video Streaming (NAVS)
methods. Motivated by this, this thesis goes one step beyond traditional pure
client-based HAS algorithms by incorporating (an) in-network component(s) with
a broader view of the network to present completely transparent NAVS solutions
for HAS clients.

Our first contribution concentrates on leveraging the capabilities of the
Software Defined Networking (SDN), Network Function Virtualization (NFV), and
Multi-Access Edge Computing (MEC) paradigms to introduce ES-HAS and CSDN as
edge- and SDN-assisted frameworks, mainly for VoD and live streaming,
respectively. ES-HAS and CSDN introduce Virtual Network Functions (VNFs) named
Virtual Reverse Proxy (VRP) servers at the edge of an SDN-enabled network to
collect HAS clients’ requests and retrieve networking information. The SDN
controller in these systems manages a single domain network. VRP servers
perform optimization models as server/segment selection policies to serve
clients’ requests with the shortest fetching time by selecting the most
appropriate cache server/video segment quality or by reconstructing the
requested quality through transcoding at the edge. Deployment of ES-HAS and
CSDN on the cloud-based testbeds and estimation of users’ Quality of
Experience (QoE) using objective metrics demonstrates how clients’ requests
can be served with higher QoE (by 40%) and lower bandwidth usage (by 63%)
compared to state-of-the-art approaches.

Our second contribution designs an architecture that simultaneously supports
various types of video streaming (live and VoD), considering their versatile
QoE and latency requirements. To this end, the SDN, NFV, and MEC paradigms are
leveraged, and three VNFs, i.e., Virtual Proxy Function (VPF), Virtual Cache
Function (VCF), and Virtual Transcoding Function (VTF), are designed. We build
a series of these function chains through the Service Function Chaining (SFC)
paradigm, utilize all CDN and edge server resources, and present SARENA, an
SFC-enabled architecture for adaptive video streaming applications. We equip
SARENA’s SDN controller with a lightweight request scheduler and edge
configurator to make it deployable in practical environments and to
dynamically scale edge servers based on service requirements, respectively.
Experimental results show that SARENA outperforms baseline schemes in terms of
higher users’ QoE figures by 39.6%, lower E2E latency by 29.3%, and lower
backhaul traffic usage by 30% for live and VoD services.

Our third contribution aims to use the idle resources of edge servers and
employ the capabilities of the SDN controller to establish a collaboration
between edge servers in addition to collaboration between edge servers and the
SDN controller. We introduce two collaborative edge-assisted frameworks
working for HAS-based live or VoD scenarios named LEADER and ARARAT. LEADER
utilizes sets of actions (e.g., transcode the requested quality in the local
edge server or a neighboring edge server with the highest available
resources), presented in a so-called Action Tree, formulates the problem as a
central optimization model to enhance the HAS clients’ serving time, subject
to the network’s and edge servers’ resource constraints, and proposes a
lightweight heuristic algorithm to solve the model. ARARAT extends LEADER’s
Action Tree, considers network cost in the optimization, devises multiple
heuristic algorithms, and runs extensive scenarios. Evaluation results show
that LEADER and ARARAT improve users’ QoE by 22%, decrease the streaming cost
by 47%, and enhance network utilization by 13%, as compared to their
competitors.

Our final contribution focuses on incorporating the capabilities of both peer-
to-peer (P2P) networks and CDNs, utilizing NFV and edge computing techniques,
and then presenting RICHTER and ALIVE as hybrid P2P-CDN frameworks for live
streaming scenarios. RICHTER and ALIVE particularly use HAS clients’ (i.e.,
peers’) potential idle computational resources besides their available
bandwidth to provide distributed video processing services, e.g., video
transcoding and video super-resolution. Both frameworks introduce multi-layer
architectures and design Action Trees that consider all feasible resources
(i.e., storage, computation, and bandwidth) provided by peers, edge, and CDN
servers for serving clients’ requests with acceptable latency and quality.
Moreover, RICHTER proposes an online learning method and ALIVE utilizes a
lightweight algorithm distributed over in-network virtualized components,
which are designed to play decision-maker roles in large-scale practical
scenarios. Evaluation results show that RICHTER and ALIVE improve the users’
QoE by 22%, decrease cost incurred for the streaming service provider by 34%,
shorten clients’ serving latency by 39%, enhance edge server energy
consumption by 31%, and reduce backhaul bandwidth usage by 24% compared to the
baseline approaches.

I would like to dedicate this thesis to my loving parents and my wife,
Sepideh, who have always motivated me to pursue and accomplish my dreams …

## Eidesstattliche Erklärung

Ich versichere an Eides statt, dass ich

  * –

die eingereichte wissenschaftliche Arbeit selbstständig verfasst und keine
anderen als die angegebenen Hilfsmittel benutzt habe,

  * –

die während des Arbeitsvorganges von dritter Seite erfahrene Unterstützung,
einschließlich signifikanter Betreuungshinweise, vollständig offengelegt habe,

  * –

die Inhalte, die ich aus Werken Dritter oder eigenen Werken wortwörtlich oder
sinngemäß übernommen habe, in geeigneter Form gekennzeichnet und den Ursprung
der Information durch möglichst exakte Quellenangaben (z.B. in Fußnoten)
ersichtlich gemacht habe,

  * –

die eingereichte wissenschaftliche Arbeit bisher weder im Inland noch im
Ausland einer Prüfungsbehörde vorgelegt habe und

  * –

bei der Weitergabe jedes Exemplars (z.B. in gebundener, gedruckter oder
digitaler Form) der wissenschaftlichen Arbeit sicherstelle, dass diese mit der
eingereichten digitalen Version übereinstimmt.

Ich bin mir bewusst, dass eine tatsachenwidrige Erklärung rechtliche Folgen
haben wird.

Reza Farahani

Klagenfurt am Wörthersee, July 2023

## Affidavit

I hereby declare in lieu of an oath that

  * –

the submitted academic paper is entirely my own work and that no auxiliary
materials have been used other than those indicated,

  * –

I have fully disclosed all assistance received from third parties during the
process of writing the thesis, including any significant advice from
supervisors,

  * –

any contents taken from the works of third parties or my own works that have
been included either literally or in spirit have been appropriately marked and
the respective source of the information has been clearly identified with
precise bibliographical references (e.g. in footnotes),

  * –

to date, I have not submitted this paper to an examining authority either in
Austria or abroad and that

  * –

when passing on copies of the academic thesis (e.g. in bound, printed or
digital form), I will ensure that each copy is fully consistent with the
submitted digital version.

I am aware that a declaration contrary to the facts will have legal
consequences.

Reza Farahani

Klagenfurt am Wörthersee, July 2023

###### Acknowledgements.

Three and a half incredible years of research work are enclosed in the pages
of this thesis. During this time, I had the honor of encountering wonderful
moments, making significant discoveries, overcoming substantial obstacles, and
meeting outstanding individuals. I owe my success to the numerous kind-hearted
and professional people who supported and assisted me throughout my Ph.D.
journey. I would like to take this opportunity to give them credit and thank
them for their help and support. First and foremost, I would like to thank my
excellent supervisors, Professor Hermann Hellwagner and Professor Christian
Timmerer. It has been a great pleasure to be able to work under their
supervision, who guided my first steps as a researcher. I will be forever
grateful to them for their patience, precious time, tremendous guidance, and
endless support. I want to thank my ex-professor Mohammad Ghanbari at the
University of Essex. I had the opportunity to continue collaborating with him
and receive his valuable comments and feedback to improve my work. I also
would like to express my appreciation to Professor Radu Prodan, with whom I
had the opportunity to collaborate on this dissertation’s last contribution. I
thank him for the insightful discussions and fruitful communications that gave
me valuable experience to prepare for future projects. I also like to thank my
Ph.D. visiting mentor and collaborator at the University of Surrey, Dr.
Mohammad Shojafar. I am thankful for all the online discussions and for
hosting my three-month research stay at the 5GIC/6GIC, University of Surrey. I
had the opportunity to work closely with Dr. Abdelhak Bentaleb, a postdoctoral
researcher at the National University of Singapore at the time and currently
an assistant professor at Concordia University. I want to thank all of my co-
authors, also my colleagues at the ATHENA Christian Doppler (CD) Laboratory,
plus my colleagues in the Department of Information Technology (ITEC) of the
University of Klagenfurt, especially Nina and Martina, for their constant
support. I would also like to acknowledge Professor Filip De Turck and
Professor Tobias Hoßfeld for their time and insightful feedback. I would also
like to mention the CloudLab team, who have constantly supported me in running
my experiments, no matter how unreasonable my demands were. The research
leading to this dissertation has received funding from the Austrian Federal
Ministry for Digital and Economic Affairs, the National Foundation for
Research, Technology, and Development, and the Christian Doppler Research
Association; their financial support is gratefully acknowledged. Christian
Doppler Laboratory ATHENA: https://athena.itec.aau.at/.

Last but not least, I also want to thank my family, especially my parents and
my wife: Majid, Masoumeh, and Sepideh. None of this would have been possible
without their continued support and endless love; I will forever be indebted
to them for making me who I am now.

Reza Farahani,
Klagenfurt, July 2023

###### Table of Contents

  1. List of Acronyms and Abbreviations
  2. 1 General Introduction
    1. 1.1 Motivation and Problem Statement
    2. 1.2 Research Questions
    3. 1.3 Research Methodology
    4. 1.4 Thesis Contributions
    5. 1.5 Publications
      1. 1.5.1 First Author Publications
      2. 1.5.2 Co-authored Publications
    6. 1.6 Thesis Organization
  3. 2 Technical Background and Related Work
    1. 2.1 Technical Background
      1. 2.1.1 HTTP Adaptive Streaming (HAS)
      2. 2.1.2 Content Delivery Networks (CDNs)
      3. 2.1.3 Peer-to-Peer (P2P) Networks
      4. 2.1.4 Software Defined Networking (SDN)
      5. 2.1.5 Network Function Virtualization (NFV)
      6. 2.1.6 Service Function Chaining (SFC)
      7. 2.1.7 Multi-Access Edge Computing (MEC)
    2. 2.2 Related Work
      1. 2.2.1 SDN- and/or Edge-Based NAVS Solutions
      2. 2.2.2 CDN- and/or P2P-Based NAVS Solutions
  4. 3 Edge- and SDN-Assisted Frameworks for HAS
    1. 3.1 ES-HAS Framework
      1. 3.1.1 ES-HAS Motivating Example and Problem Statement
      2. 3.1.2 ES-HAS System Design
        1. 3.1.2.1 ES-HAS Architecture
        2. 3.1.2.2 ES-HAS Optimization Problem Formulation
      3. 3.1.3 ES-HAS Performance Evaluation
        1. 3.1.3.1 Evaluation Setup
        2. 3.1.3.2 Evaluation Results
    2. 3.2 CSDN Framework
      1. 3.2.1 CSDN Motivating Example and Problem Description
      2. 3.2.2 CSDN System Design
        1. 3.2.2.1 CSDN Architecture
        2. 3.2.2.2 CSDN Optimization Problem Formulation
      3. 3.2.3 CSDN Performance Evaluation
        1. 3.2.3.1 Evaluation Setup
        2. 3.2.3.2 Evaluation Results
    3. 3.3 Summary
  5. 4 SFC-Enabled Architecture for HAS
    1. 4.1 SARENA Framework
      1. 4.1.1 SARENA System Design
        1. 4.1.1.1 SARENA Architecture
        2. 4.1.1.2 SARENA Optimization Problem Formulation
      2. 4.1.2 SARENA Lightweight Heuristic Algorithms
        1. 4.1.2.1 Edge-based Scheduling Heuristic Algorithm
        2. 4.1.2.2 SDN-based Management Heuristic Algorithm
      3. 4.1.3 SARENA Performance Evaluation
        1. 4.1.3.1 Evaluation Setup
        2. 4.1.3.2 Evaluated Methods and Metrics
        3. 4.1.3.3 Evaluation Results
    2. 4.2 Summary
  6. 5 Collaborative Edge-Assisted Frameworks for HAS
    1. 5.1 LEADER Framework
      1. 5.1.1 LEADER System Design
        1. 5.1.1.1 LEADER Architecture
        2. 5.1.1.2 LEADER Optimization Problem Formulation
      2. 5.1.2 LEADER Distributed Heuristic Approach
        1. 5.1.2.1 SDN Controller Heuristic Algorithm
        2. 5.1.2.2 Edge Server Heuristic Algorithm
      3. 5.1.3 LEADER Performance Evaluation
        1. 5.1.3.1 Evaluation Setup
        2. 5.1.3.2 Evaluation Methods and Metrics
        3. 5.1.3.3 Evaluation Results
    2. 5.2 ARARAT Framework
      1. 5.2.1 ARARAT System Design
        1. 5.2.1.1 ARARAT Problem Statement
        2. 5.2.1.2 ARARAT Architecture
        3. 5.2.1.3 ARARAT Centralized Optimization Model
        4. 5.2.1.4 Complexity Analysis of the Optimization Model
      2. 5.2.2 ARARAT Heuristic Approaches
        1. 5.2.2.1 ARARAT Coarse-Grained Heuristic Approach
        2. 5.2.2.2 ARARAT Fine-Grained Heuristic Approach I
        3. 5.2.2.3 ARARAT Fine-Grained Heuristic Approach II
      3. 5.2.3 ARARAT Performance Evaluation
        1. 5.2.3.1 Evaluation Setup
        2. 5.2.3.2 Evaluation Methods, Scenarios, and Metrics
        3. 5.2.3.3 Evaluation Results
    3. 5.3 Summary
  7. 6 Hybrid P2P-CDN Architectures for HAS
    1. 6.1 RICHTER Framework
      1. 6.1.1 RICHTER System Design
        1. 6.1.1.1 RICHTER Architecture
        2. 6.1.1.2 RICHTER Optimization Problem Formulation
      2. 6.1.2 RICHTER Online Learning Approach
      3. 6.1.3 RICHTER Performance Evaluation
        1. 6.1.3.1 Evaluation Setup
        2. 6.1.3.2 Evaluation Methods and Metrics
        3. 6.1.3.3 Evaluation Results
    2. 6.2 ALIVE Framework
      1. 6.2.1 ALIVE System Design
        1. 6.2.1.1 ALIVE Problem Statement
        2. 6.2.1.2 ALIVE Architecture
        3. 6.2.1.3 ALIVE Optimization Problem Formulation
      2. 6.2.2 ALIVE Heuristic Approach
        1. 6.2.2.1 Heuristic Workflow
        2. 6.2.2.2 Greedy-Based Algorithm (GBA)
      3. 6.2.3 ALIVE Performance Evaluation
        1. 6.2.3.1 Super-Resolution Models
        2. 6.2.3.2 Evaluation Setup
        3. 6.2.3.3 Evaluation Methods, Scenarios, and Metrics
        4. 6.2.3.4 Evaluation Results
    3. 6.3 Summary
  8. 7 Conclusions and Future Work
    1. 7.1 Conclusions
    2. 7.2 Future Directions and Challenges
      1. 7.2.1 Designing NAVS Systems Considering Traffic Encryption
      2. 7.2.2 Designing NAVS Systems Utilizing Emerging Protocols
      3. 7.2.3 Designing NAVS Immersive Video Streaming
      4. 7.2.4 Designing Sustainable NAVS HAS System

###### List of Figures

  1. 1.1 Global (a) IP traffic by application category and (b) Internet video by subsegment Cisco (2018).
  2. 1.2 An example of the first research question (RQ1).
  3. 1.3 An example of the second research question (RQ2).
  4. 1.4 The contributions of this thesis are classified along the scientific publications conducted by the author. The small rectangles indicate which research questions (RQs) are addressed by each publication.
  5. 1.5 Differences and relations between frameworks introduced in the dissertation.
  6. 2.1 Example of an E2E HTTP adaptive live video streaming system Kalan et al. (2022).
  7. 2.2 Illustration of a CDN architecture.
  8. 2.3 Illustration of a P2P network.
  9. 2.4 (a) Traditional and (b) SDN-based network architectures.
  10. 2.5 (a) Traditional and (b) NFV-based network components.
  11. 2.6 Illustration of an SFC-enabled system.
  12. 2.7 Illustration of cloud and edge computing.
  13. 2.8 Research gaps in the literature.
  14. 3.1 Exchanged messages in (a) SABR and (b) ES-HAS.
  15. 3.2 Proposed ES-HAS architecture.
  16. 3.3 Proposed time slot structure.
  17. 3.4 ES-HAS evaluation testbed.
  18. 3.5 ES-HAS MILP model execution time for different numbers of segment requests and cache servers.
  19. 3.6 Requested quality levels by the (a) BOLA and (b) SQUAD algorithms vs. forwarded quality levels for client 1.
  20. 3.7 (a) CDF of average playback bitrate, (b) average number of stalls, (c) number of requests for each quality level, and (d) average number of quality switches in pure client-based ABR, SABR, and ES-HAS systems for 60 clients.
  21. 3.8 (a) Pure client-based, (b) ES-HAS, and (c) CSDN approaches.
  22. 3.9 Proposed CSDN architecture.
  23. 3.10 CSDN evaluation testbed.
  24. 3.11 Impact of changing $\theta$ on playback bitrate: (a) $\theta$ = 0.5s, (b) $\theta$ = 50 milliseconds, (c) $\theta$ = 32 milliseconds, and (d) $\theta$ = 0.
  25. 3.12 Requested quality levels by (a) CSDN-BOLA and (b) CSDN-SQUAD vs. forwarded quality levels for client 50.
  26. 3.13 (a) Average number of downloaded video quality levels, (b) average number of quality switches, and (c) average number of stalls for pure client-based ABR algorithms, SABR, ES-HAS, and CSDN for 100 clients.
  27. 3.14 (a) Network backhaul bandwidth usage and number of fetches from the origin server for different approaches, and (b) network backhaul bandwidth usage and number of transcoded segments for different percentages of preloaded segments on cache servers for BOLA-CSDN for 100 clients.
  28. 3.15 CDF of average playback bitrate (a–b) and number of replacement quality levels and maximum quality deviation (c–d) for two types of users (I, II); parameters in (a) and (c): type I: $\alpha$=0.9, $\beta$=0.1; type II: $\alpha$=0.1, $\beta$=0.9; parameters in (b) and (d): type I: $\alpha$=0.1, $\beta$=0.9 and type II: $\alpha$=0.9, $\beta$=0.1.
  29. 4.1 Proposed SARENA architecture.
  30. 4.2 QoE results for the CDA, NVA, NTE, NRE, and SARENA systems for 250 clients.
  31. 4.3 Network utilization results for the CDA, NVA, NTE, NRE, and SARENA systems for 250 clients.
  32. 5.1 LEADER architecture.
  33. 5.2 LEADER action tree.
  34. 5.3 Proposed time slot structure (a), and example of bandwidth allocation strategy (b-c).
  35. 5.4 QoE (a–c), and network utilization (d–e) results for the NECOL, DECOL, and LEADER systems for 250 clients.
  36. 5.5 ARARAT action tree.
  37. 5.6 ARARAT architecture.
  38. 5.7 Workflows and proposed time slot structures: (a) Centralized, (b) Coarse-Grained approaches.
  39. 5.8 Workflows and proposed time slot structures: (a) Fine-Grained I, (b) Fine-Grained II approaches.
  40. 5.9 An example topology for bandwidth allocation strategy.
  41. 5.10 ARARAT evaluation testbed.
  42. 5.11 Small-scale topology used in scenario I.
  43. 5.12 Impact of increasing the number of arriving requests (req#) in (a) a small topology, (b) in the Geant toplogy, and (c) changing the bitrate ladder on the performance of the centralized MILP model, CG, and FG approaches in terms of ETV and (d) NOV.
  44. 5.13 Performance of the ARARAT approaches compared with state-of-the-art methods in terms of (a) ASB, (b) AQS, (c) ASD, (d) ANS, (e) APQ for 250 clients running BOLA and SQUAD ABR algorithms, and (f) APQ for each client group for the BOLA ABR algorithm.
  45. 5.14 Performance of the ARARAT approaches compared with state-of-the-art methods in terms of (a) CHR, (b) ETR, (c) BTL, (d) ANU, (e) AST, (f) NCV, and (g) ANC for 250 clients running BOLA and SQUAD ABR algorithms.
  46. 6.1 RICHTER system architecture.
  47. 6.2 RICHTER action tree.
  48. 6.3 Proposed online learning structure.
  49. 6.4 (a) time slot structure, and (b) a sample of the OL agent output.
  50. 6.5 Evaluation results for the NOH, NTH, ECT, and RICHTER systems for 350 clients.
  51. 6.6  ALIVE action tree; ETR:= edge Transcoding; PTR := Peer Transcoding; PSR := Peer Super-resolution.
  52. 6.7 ALIVE multi-layers architecture.
  53. 6.8  Proposed ALIVE heuristic workflow.
  54. 6.9  Illustration of video super-resolution pipeline.
  55. 6.10 Performance of different video SR models in terms of VMAF and FPS. Results are obtained with input resolution $640\times 360$ and target resolution $1280\times 720$. $30$ FPS line is shown to indicate real-time execution.
  56. 6.11  ALIVE evaluation testbed.
  57. 6.12 Performance comparison of applying peer’s SR on a lower representation in terms of (a) power consumption, (b) VMAF score, (c) VMAF/Bitrate, and (d) bandwidth saving.
  58. 6.13 Impact of (a) increasing the number of arriving requests ($Req\\#$), (b) increasing the number of live channels ($Ch\\#$), and (c) changing the bitrate ladder, on the performance of the MILP model and the proposed heuristic method in terms of ETV and (d) NOV.
  59. 6.14 Performance of the ALIVE system compared with other baseline methods in terms of (a) ASB, (b) AQS, (c) ANS, (d) ASD, (e) ASL, and (e) APQ for 350 clients running BOLA and SQUAD ABR algorithms.
  60. 6.15 Performance of the ALIVE system compared with other baseline methods in terms of (a) CHR, (b) ETR, (c) PTSR, (d) BTL, (e) EEC, and (e) NCV for 350 clients running BOLA and SQUAD ABR algorithms.

###### List of Tables

  1. 2.1 Overview of related approaches; HE := Heuristic; ML := Machine Learning; OL := Online Learning; RL := Reinforcement Learning; TR := Transcoding; SR := Super-resolution.
  2. 3.1 Number of messages to/from SDN controller.
  3. 3.2 ES-HAS Notation.
  4. 3.3 Impact of $m$, $\alpha_{1}$, $\alpha_{2}$, and $\alpha_{3}$ on MILP model behavior.
  5. 3.4 CSDN Notation.
  6. 4.1 SARENA Notation.
  7. 5.1 LEADER Notation.
  8. 5.2 ARARAT Notation.
  9. 5.3 Calculated fairness coefficients and allocated bandwidth for the example topology of Fig. 5.9.
  10. 6.1 RICHTER Notation.
  11. 6.2 Average transcoding times for a 5-min. video on peers.
  12. 6.3 ALIVE Notation.
  13. 6.4 Power consumption and battery usage of different approaches for a 5-min. video on peers.
  14. 6.5 Transcoding time and VMAF scores for 3-min. video on different peer types.

## List of Acronyms and Abbreviations

0-9
3GPP 3rd Generation Partnership Project

A
ABR Adaptive Bitrate
ALTO Application Layer Traffic Optimization
AP Access Point
AR Augmented Reality
AVC Advanced Video Coding

C
CAPEX Capital Expenditure
CDN Content Delivery Network
CMAF Common Media Application Format
CMCD Common Media Client Data
CMSD Common Media Server Data
CNN Convolutional Neural Network
CTA Consumer Technology Association

D
DANE DASH-Aware Network Element
DASH Dynamic Adaptive Streaming over HTTP
DNN Deep Neural Network
DNS Domain Name System
DRL Deep Reinforcement Learning
DRM Digital Rights Management

E
E2E End-to-End
EC Edge Computing
ETR Edge Transcoding
ETSI European Telecommunications Standards Institute

H
HAS HTTP Adaptive Streaming
HEVC High Efficiency Video Coding
HLS HTTP Live Streaming
HTTP Hypertext Transfer Protocol

I
IEC International Electrotechnical Commission
IETF Internet Engineering Task Force
IoT Internet of Things
IRTF Internet Research Task Force
ISO International Organization for Standardization
ISP Internet Service Provider
ITU-T ITU Telecommunication Standardization

K
KPI Key Performance Indicator

L
LES Local Edge Server
LP Linear Programming

M
MEC Multi-Access Edge Computing
MILP Mixed Integer Linear Programming
MINLP Mixed Integer Non Linear Programming
ML Machine Learning
MNO Mobile Network Operator
MOS Mean Opinion Score
MPD Media Presentation Description
MPEG Moving Picture Experts Group
MPTCP Multi-Path TCP
MS Multimedia Service
MSS Microsoft Smooth Streaming

N
NAVS Network Assisted Video Streaming
NES Neighboring Edge Server
NDN Named Data Networking
NFV Network Function Virtualization
NGN Next Generation Networks
NN Neural Network

O
OF OpenFlow
OL Online Learning
ONF Open Networking Foundation
OPEX Operational Expenditure
OTT Over-the-Top

P
P2P Peer to Peer Network
PED Parameters Enhancing Delivery
PER Parameters Enhancing Reception
PSNR Peak Signal to Noise Ratio
PSR Peer Super-Resolution
PTR Peer Transcoding

Q
QoE Quality of Experience
QoS Quality of Service
QUIC Quick UDP Internet Connections

R
RA Resource Allocation
RAN Radio Access Network
RL Reinforcement Learning
RTCP Real-Time Control Protocol
RTMP Real-Time Messaging Protocol
RTP Real-Time Transport Protocol
RTSP Real-Time Streaming Protocol

S
SAND Server and Network Assisted DASH
SDN Software-Defined Networking
SFC Service Function Chaining
SLA Service Level Agreement
SR Super-Resolution

T
TCP Transmission Control Protocol
TR Transcoding

U
UDP User Datagram Protocol
UE User Equipment

V
VCF Video Cache Function
VMAF Video Multi-Method Assessment Fusion
VNF Virtual Network Function
VPF Virtual Proxy Function
VQA Video Quality Assessment
VR Virtual Reality
VRP Virtual Reverse Proxy
VTF Virtual Trascoding Function
VoD Video-on-Demand

W
WebRTC Web Real-Time Communications

##  Chapter 1 General Introduction

In the first section of this chapter (Section 1.1), we describe the primary
motivation of the thesis and state the main problem. Section 1.2 outlines four
fundamental research questions (RQ1–RQ4) that must be taken into account to
solve the expressed problem. Section 1.3 explains the research methodology
utilized to address the RQs. Sections 1.4 and 1.5 discuss the principal
contributions and show outcomes of the thesis, which are published in or
submitted to partially highly prestigious journals or conferences/workshops,
respectively. Finally, Section 1.6 outlines the organization of the thesis.

###  1.1 Motivation and Problem Statement

The emergence of modern networks (e.g., 5G and 6G), the development of Over-
The-Top (OTT) content services (e.g., YouTube, Netflix, Facebook, Amazon
Prime), and steadily growing numbers of users who prefer to stream video
content online rather than using classical TV, have made video the dominant
traffic on the Internet Cisco (2018). According to the Cisco Annual Internet
Report, video traffic will make up more than 60% of the entire IP network
traffic by 2023. As shown in Fig. 1.1 (a), in 2022 consumer Internet video
traffic exceeded 300 Exabytes per month, which is equivalent to over 60
billion DVDs per month or 82 million DVDs per hour. This rise in traffic is
closely linked to the continuous development of video services. Nowadays,
video content is transitioning from Full HD (FHD) to 8K resolution. There are
also growing demands for Virtual (VR) and Augmented Reality (AR) equipment
with high-bandwidth requirements.

Fig. 1.1: Global (a) IP traffic by application category and (b) Internet video
by subsegment Cisco (2018).

Concerning video traffic, video streaming applications, such as video-on-
demand (VoD) or live video streaming, represent about 66% of the total traffic
over the Internet Sandvine (January 2023). Indeed, VoD and live video have
gained tremendous popularity in the last few years, where over 270 Exabytes
per month of both types were streamed by 2022 (see Fig. 1.1 (b)). These trends
are expected to continue; for instance, live video streaming will account for
more than 17% of total video traffic by 2023 Sandvine (January 2023).

Ensuring a satisfactory degree of satisfaction or a decreasing annoyance
quality perceived by the end user of an application or service, the so-called
Quality of Experience (QoE) Brunnström et al. (2013), is a vital business
incentive for these stakeholders in the Internet ecosystem, as it helps
mitigate the constant threat of customer attrition. Various video delivery
technologies have emerged in recent years in order to improve the performance
of video streaming services. The scale of current streaming platforms has
prompted a transition from protocols relying on the Real-Time Transport
Protocol (RTP) Schulzrinne, Henning and Casner, Stephen and Frederick, Ron and
Jacobson, Van (2003) to those based on HTTP Adaptive Video Streaming (HAS).
Among all HAS-based solutions, the Moving Picture Experts Group (MPEG)
standard Dynamic Adaptive Streaming over HTTP (DASH) Sodagar (2011) and
Apple’s HTTP Live Streaming (HLS) Pantos and May (2017) are two predominant
HAS delivery systems that OTT providers use for video streaming applications.

In HAS-enabled systems, the video sequences are encoded into various bitrates
or resolutions, known as representations, and then divided into small and
fixed segments, each consisting of a few seconds of the video. A manifest file
(e.g., Media Presentation Description (MPD) in DASH systems) stored on the
server side specifies the structure of the video in terms of available
representations and segments. At the start of the streaming session, the
client downloads this manifest file from the server and then requests the
video segments in a chronological sequence. Once one or more video segments
are downloaded and saved in the client’s buffer, the video playback commences.
In addition, HAS enables switching the video’s representations dynamically
during the streaming session. The switching strategy, known as the Adaptive
Bitrate Algorithm (ABR), is entirely placed on the client side, which makes
this approach highly scalable. The objective of the adaptation algorithm is
determining the most appropriate video representation according to the network
bandwidth or/and client buffer, with a key emphasis on providing uninterrupted
playback while maximizing the streamed quality Bentaleb et al. (2018b);
Barakabitze et al. (2019).

Although HAS-enabled delivery systems certainly offer benefits over non-HAS
streaming systems, most of the existing HAS-based methods are pure client-
based solutions, where the players’ ABR algorithms often make bitrate
adaptation decisions by only considering local device parameters (e.g., a
smartphone’s buffer status and estimated available bandwidth) without any
global network consideration. Given the large-scale distributed nature of the
Internet, individual nodes only observe part of the video streaming system,
which results in imperfect adaptations and poor long-tail performance Bentaleb
et al. (2018b). Moreover, various studies indicate that the adaptation
mechanisms in HAS players suffer performance problems in competitive
situations when numerous players compete for a shared bottleneck network link
Akhshabi et al. (2012); Huang et al. (2012).

Collectively, the aforementioned problems and the requirements of assuring the
users’ QoE have motivated OTT companies and ISPs to collaborate, upgrade their
video delivery systems, and introduce an emerging direction called Network-
Assisted Video Streaming (NAVS). NAVS systems refer to techniques used to
optimize video delivery over the Internet to devices that support HAS-based
streaming. In such systems, one or multiple in-network components with a
broader view of the network can be employed to provide fair network resources
to video players and assist them in making precise adaptation decisions, hence
meeting video usage with extremely high-bandwidth demands under high-quality
and low-latency constraints. Therefore, to provide modern NAVS services, ISPs
must overhaul their traditional network structures, which are based on IP
architecture principles.

This thesis aims to advance streaming services and content delivery
performance by introducing modern NAVS systems. Our NAVS systems employ
promising network models, e.g., virtualized and softwarized networks and edge
computing, and incorporate overlay networks such as Content Delivery Networks
(CDNs) and/or Peer-to-Peer (P2P) networks to provide support and assistance
for VoD and live HAS clients. One of the important services offered by such
NAVS systems is video transcoding services. Video transcoding solutions, such
as “AWS Elemental MediaConvert” AWS (2023), are typically used to adjust video
quality based on network conditions, device capabilities, and user
preferences. Indeed, converting a video file/segment from one format to
another, from a higher bitrate/resolution to the requested one, makes it
suitable for different devices with different bitrate/resolution or codec
support. The usage of such services is expected to grow in the future due to
the increasing demand for high-quality and high-resolution (e.g., 4K or 8K)
video sequences, newer video codecs (e.g., HEVC and VVC), and bandwidth-
intensive immersive streaming. The NAVS frameworks presented in this thesis
offer entirely transparent services to HAS clients to ensure that HAS clients’
adaptation decisions are free from any kind of confusion or risk. As a result,
clients can obtain acceptable quality video sequences with enhanced latencies.
While some of the developed techniques may be relevant to other types of video
transport, such as conversational or immersive video sequences (tile-based
360-degree VR), these use cases are not within the scope of our work. The
thesis studies video in terms of its transport and delivery, and thus video
encoding aspects are also considered out of our scope. Given the
aforementioned factors, this thesis aims to identify and tackle the following
challenges:

  1. Challenge1

Improving users’ QoE during streaming sessions. The users’ QoE in HAS-enabled
systems is affected by different factors, particularly stalling and quality
switches, as defined in the following. Since the HAS clients are not aware of
the real network conditions, if they are not assisted in improving the
delivered QoE, they encounter unnecessary quality switches and video playout
interruptions. Consequently, improving the users’ QoE should be considered as
the primary goal of designing NAVS systems.

     * •

Stalls:  Stalls represent video playback interruptions during the streaming
session, making users experience unexpected waiting times. The video typically
stalls due to a rebuffering event, i.e., when the player buffer is emptied.
Therefore, the video playback can only be resumed once the buffer is refilled
and the next segment is available. There are two key performance indicators
(KPIs) associated with stalling that impact the QoE: the stalling duration and
the overall number of stalls happening throughout the video playback. Studies
have indicated that the users’ QoE is more degraded by frequent short
interruptions than by less frequent longer interruptions Hossfeld et al.
(2013).

     * •

Quality switches: The dynamic nature of HAS resulting in varying video quality
during playback can lead to viewer distraction. Two crucial KPIs related to
quality switches are the overall number of quality switches and the switching
amplitudes. In order to ensure a satisfactory QoE, a balance must be struck
between maximizing the delivered video quality and minimizing the frequency
and amplitudes of quality switches Moldovan et al. (2017).

  2. Challenge2

Establishing collaboration between different stakeholders. Collaboration among
different business stakeholders, e.g., ISPs, CDN providers, OTT companies, and
P2P networks, is required for implementing NAVS systems. To this aim, edge
nodes are enabled to host third-party services, e.g., proxy servers of OTT
providers, of mobile network operators (e.g., MobiledgeX), and of CDN
providers (e.g., Cloudflare and Limelight).

  3. Challenge3

Presenting NAVS solutions compatible with HAS systems using minimum
modifications on the client side. Some of the NAVS systems impose
modifications on HAS clients or require specific software to be installed on
the client devices to play out the requested video sequences. Thus, designing
NAVS systems for HAS systems that can only leverage existing HAS protocols and
standards with minimum modification or extra software/plugin installment on
the HAS clients is challenging.

  4. Challenge4

Enhancing networking resource utilization. Video streaming often involves
dynamic and unpredictable network conditions, such as fluctuations in
available bandwidth. On the other hand, different video streaming applications
have varying requirements for network resources. Therefore enhancing resource
usage while achieving a desirable performance goal, e.g., ensuring high-
quality video delivery in designing NAVS systems, adds to the complexity of
the problem.

  5. Challenge5

Reducing streaming costs. Video streaming systems often require significant
amounts of CDN/origin servers’ storage and/or CDN/edge servers’ computations
for running computationally intensive tasks like video transcoding. Therefore,
devising NAVS systems that can efficiently distribute video content with
acceptable quality and latency across many users while avoiding excessive use
of storage and computation requirements is a complex task.

###  1.2 Research Questions

As mentioned in the previous section, the aim of this thesis is to propose
innovative NAVS systems for HAS clients to overcome the drawbacks of pure
client-based HAS systems. To achieve this goal, we take into account the
perspectives of different stakeholders (i.e., OTTs, CDNs, and ISPs) within the
HAS ecosystem and then elaborate on the following research questions (RQs):

Fig. 1.2: An example of the first research question (RQ1).

  1. RQ1

How can SDNs/CDNs provide assistance for HAS clients in order to improve media
delivery services?

As illustrated in Fig. 1.2, the SDN controller with a broader network view
could host multiple Virtualized Network Functions (VNFs) with particular
responsibilities to collect information (e.g., network map, path information,
cache occupancy, throughput measurements) from different network components
such as CDN servers or network switches (step 1 in Fig. 1.2). The SDN
controller controlling a single domain network (i.e., Autonomous System) can
use this network-wide information to improve delivery services. For instance,
collecting, processing, and distributing information about cache occupancy by
a central controller (i.e., the SDN controller) can help clients satisfy their
content requests from an appropriate cache server (step 2).

  2. RQ2

How can resources (i.e., computation, storage, bandwidth) provided by the HAS
clients be used to improve media delivery services?

Although several works introduced P2P or hybrid P2P-CDN video delivery
approaches (as discussed in Section 2.2.2), there is still a need to further
investigate this research question. An example is shown in Fig. 1.3, where the
SDN controller could employ an intermediate server holding multiple
functionalities to receive information provided by HAS clients (step 1 in Fig.
1.3), such as available resources, user behavior, content popularity, content
prefetching, and/or representation selection hints. This information can then
be used by the SDN controller (step 2) for several purposes, e.g., task
offloading into the P2P network, caching, or dynamic routing policies to
improve media delivery and network utilization. Moreover, HAS clients can be
used within a hybrid P2P-CDN NAVS system to provide low-latency video
streaming, improve network bandwidth usage (i.e., backhaul and fronthaul) as
well as enhance CDNs’ performance.

Fig. 1.3: An example of the second research question (RQ2).

  3. RQ3

What is the utility of the proposed assistance and collaboration service?

Although subjective quality assessment methods, e.g., using metrics like Mean
Opinion Score (MOS) Streijl et al. (2016), are still among the prevalent
methods for evaluating the impact of NAVS systems on the users’ perception,
they typically involve a large number of participants to rate the quality.
Therefore, such studies can be time-consuming and costly, particularly when
dealing with large-scale scenarios. To avoid such problems, objective quality
assessment methods via objective metrics estimate users’ QoE and offer
scalability, reproducibility, real-time monitoring, interpretability,
systematic analysis and cost-effectiveness as advantages. Thus, improving (1)
users’ objective QoE parameters, i.e., application QoS parameters (e.g.,
average quality bitrate, the number of quality switches, delay duration,
number of delays, standardized perceived quality metrics such as the one
obtained from P.1203 P.1203 (2020)), (2) CDN utilization (e.g., server load,
cache hit rates), (3) network QoS parameters (e.g., delay, throughput), (4)
network utilization (backhaul/fronthaul bandwidth, computation usage), (5) SDN
controller’s load (messages to/from the controller, load), (6) content
providers’ costs (video bitrate ladder), (7) edge server costs (e.g.,
computational or storage), etc. are considered as the principal utilities of
the proposed NAVS frameworks.

  4. RQ4

How can the utility of the proposed NAVS frameworks be thoroughly evaluated,
both theoretically and practically?

Large-scale evaluations employing realistic settings, assumptions, networking
topologies, video datasets, and network traces to conduct testbed experiments
are considered to evaluate the utility of the proposed approaches. Given the
wide scope of what can and needs to be investigated, conducting subjective
quality studies in such large-scale evaluations is impossible. However,
estimating the objective QoE through objective quality assessment methods,
such as application QoS parameters via P.1203 metric, is feasible.

###  1.3 Research Methodology

The design approach introduced by the Association for Computing Machinery
(ACM) Comer et al. (1989) will be used to address the RQs given in Section 1.2
with the following steps:

  1. Step1

State requirements: First, we investigate which type of information provided
by CDNs, SDNs, or HAS clients could be feasible and valuable to establish a
collaboration between them. Network maps, cache server occupancy, application
analytics information to an SDN/CDN, user behavior, content popularity,
content prefetching, representation selection hints or/and predictions to a
CDN might be considered as important information. Surveying state-of-the-art
works, standard specifications, and software/platforms’ capabilities are taken
into account in this step.

  2. Step2

State specifications: After finding appropriate information, we must define
specifications by designing innovative system architectures considering HAS
capabilities, novel networking paradigms, and communication protocol
requirements. We also require formulating the problem in mathematical terms
with a set of constraints.

  3. Step3

Design and implement the system: According to the system model, we will design
possible solutions that satisfy the constraints and meet the objectives
through optimization or heuristic approaches. Afterward, those solutions will
be implemented carefully in SDN/CDN environments.

  4. Step4

Test the system: Extensive experiments using large-scale testbeds under
various context settings will be conducted. The results of the proposed NAVS
solutions will be compared with other state-of-the-art and baseline approaches
in terms of metrics mentioned in RQ3 to show their performance.

###  1.4 Thesis Contributions

The scientific contributions of this thesis are summarized in Fig. 1.4. In
this figure, the author’s scientific publications are categorized according to
the employed techniques, i.e., (i) Emerging Networking Paradigms, (ii)
Delivery Networks Techniques, (iii) Learning-based Solutions, and (iv)
Emerging Communication Protocols to propose NAVS solutions assisting HAS
clients. Moreover, the color markers denote the research questions (RQs)
addressed by the scientific publications. The main contributions of this
thesis are summarized as follows:

Fig. 1.4: The contributions of this thesis are classified along the scientific
publications conducted by the author. The small rectangles indicate which
research questions (RQs) are addressed by each publication.

  1. 1.

Edge and SDN-assisted NAVS frameworks (Chapter 3). The first contribution of
the dissertation is focused on the utilization of the SDN, NFV, and MEC
paradigms to introduce two frameworks called ES-HAS Farahani et al. (2021b)
and CSDN Farahani et al. (2021a). The aim of these frameworks is to assist VoD
HAS clients by introducing Virtual Network Functions (VNFs) at the edge of a
single domain SDN-based network. These VNFs are named Virtual Reverse Proxy
(VRP) servers, and their primary responsibilities are to (i) gather requests
from HAS clients, (ii) retrieve networking information in a time-slot-based
manner, and then (iii) utilize optimization models as server/segment selection
policies to serve clients’ requests with the shortest fetching time. Indeed,
this is achieved by selecting the most appropriate cache server/video segment
quality or by reconstructing the requested quality through transcoding at the
edge. To demonstrate the effectiveness of the ES-HAS and CSDN frameworks, they
were deployed on cloud-based testbeds. The results showed that these
frameworks serve clients’ requests with higher QoE (by at least 40%) and lower
bandwidth usage (by at least 63%) compared to state-of-the-art approaches.

  2. 2.

SFC-enabled architecture for adaptive video streaming applications (Chapter
4). Our second contribution is focused on designing an architecture for
supporting different types of video streaming services (live and VoD) with
versatile QoE and latency requirements. To this end, we use the SDN, NFV, and
MEC paradigms and propose the SARENA architecture Farahani et al. (2023b).
SARENA introduces three multimedia VNFs, i.e., Virtual Proxy Function (VPF),
Virtual Cache Function (VCF), and Virtual Transcoding Function (VTF), and
builds various chains of them using the SFC paradigm. The SDN controller of
SARENA is equipped with a lightweight request scheduler and an edge
configurator to make it practical in real large-scale scenarios and to enable
dynamic edge server configuration (scaling up/down) based on service
requirements. The experimental results demonstrate that SARENA outperforms
baseline schemes in terms of QoE by at least 39.6%, latency by 29.3%, and
network utilization by 30% for two live and VoD multimedia services. It must
be noted that other aspects of designing SFC-enabled architectures, such as
stability and robustness, are not considered in the SARENA design and need
further investigation.

  3. 3.

Collaborative edge-assisted NAVS frameworks (Chapter 5). In the third
contribution, we utilize the potential idle resources of edge servers and the
SDN controller’s capabilities to establish collaboration between the SDN
controller and edge servers and between edge servers themselves. We introduce
two collaborative edge-assisted frameworks for live HAS clients called LEADER
Farahani et al. (2022d) and ARARAT Farahani et al. (2022c). LEADER introduces
sets of actions (e.g., fetch the requested quality from the local edge server
or a neighboring edge server that holds that and has the highest available
bandwidth; transcode the requested quality in the local edge server or a
neighboring edge server that has the highest available computational
resources) called Action Tree for serving client requests that consider all
feasible resources (i.e., storage, computation, and bandwidth) provided by
edge, CDN and origin servers for serving clients’ requests with acceptable
latency and quality. It also formulates the problem as a central optimization
model and proposes a lightweight heuristic algorithm to solve the proposed
optimization model. ARARAT extends LEADER’s Action Tree, considers network
cost in the optimization model and proposes extra coarse- and fine-grained
heuristic algorithms to solve the proposed optimization model. The evaluation
results show that LEADER and ARARAT enhance users’ QoE by at least 22%,
decrease the streaming cost, including bandwidth and computational costs, by
at least 47%, and enhance network utilization by at least 13% compared to
state-of-the-art approaches.

  4. 4.

Hybrid P2P-CDN NAVS frameworks for live streaming (Chapter 5). Our final
contribution aims to combine the strengths of both P2P networks and CDNs and
leverage the use of MEC and NFV techniques to develop RICHTER Farahani et al.
(2022b, a) and ALIVE Farahani et al. (2023c) as hybrid P2P-CDN frameworks for
live streaming scenarios. These frameworks utilize idle computational
resources and available bandwidth of HAS clients (i.e., peers) to offer
distributed video processing services, such as video transcoding and video
super-resolution. RICHTER and ALIVE formulate the problems as optimization
models, considering all feasible resources (i.e., storage, computation, and
bandwidth), provided by peers, edge, and CDN servers to serve requests with
the most appropriate action of the proposed Action Trees. They also propose
heuristic methods (based on online learning or lightweight algorithms) that
are designed to play decision-maker roles in large-scale practical scenarios.
The evaluation results demonstrate that RICHTER and ALIVE improve users’ QoE
by at least 22%, decrease streaming service provider costs by at least 34%,
shorten clients’ serving latency by at least 39%, reduce edge server energy
consumption by at least 31%, and reduce backhaul bandwidth usage by at least
24% compared to the baseline approaches.

###  1.5 Publications

The scientific papers that have been published are an essential metric to
measure progress and to highlight the accomplishments achieved so far. The
results of this dissertation have been published in/submitted to partially
highly prestigious journals and presented at flagship conferences/workshops.
The following list provides an overview of the publications during this Ph.D.
research. The seven works below marked with $\bigstar$ are included in this
doctoral dissertation; the other publications are not discussed further in
this dissertation. The overview in Fig. 1.5 highlights the differences and
relations between the frameworks introduced in this dissertation Farahani et
al. (2021a, b, 2022a, 2022b, 2022c, 2022d, 2023b, 2023c).

Fig. 1.5: Differences and relations between frameworks introduced in the
dissertation.

####  1.5.1 First Author Publications

  1. 1.

$\bigstar$R. Farahani, E. Çetinkaya, C. Timmerer, M. Shojafar, M. Ghanbari, H.
Hellwagner. ALIVE: A Latency- and Cost-Aware Hybrid P2P-CDN Framework for Live
Video Streaming. Submitted to IEEE Transactions on Network and Service
Management (TNSM), 2023.

  2. 2.

$\bigstar$R. Farahani, M. Shojafar, C. Timmerer, F. Tashtarian, M. Ghanbari,
H. Hellwagner. ARARAT: A Collaborative Edge-Assisted Framework for HTTP
Adaptive Video Streaming. IEEE Transactions on Network and Service Management
(TNSM), 2022.

  3. 3.

$\bigstar$R. Farahani, A. Bentaleb, C. Timmerer, M. Shojafar, R. Prodan, H.
Hellwagner. SARENA: SFC-Enabled Architecture for Adaptive Video Streaming
Applications. IEEE International Conference on Communications (ICC), 2023.

  4. 4.

$\bigstar$R. Farahani, A. Bentaleb, E. Çetinkaya , C. Timmerer, R. Zimmermann,
and H. Hellwagner. Hybrid P2P-CDN Architecture for Live Video Streaming: An
Online Learning Approach. IEEE Global Communications Conference (GLOBECOM),
2022.

  5. 5.

$\bigstar$R. Farahani, F. Tashtarian, C. Timmerer, M. Ghanbari, and H.
Hellwagner. LEADER: A Collaborative Edge- and SDN-Assisted Framework for HTTP
Adaptive Video. IEEE International Conference on Communications (ICC), 2022.

  6. 6.

$\bigstar$R. Farahani, F. Tashtarian, H. Amirpour, C. Timmerer, M. Ghanbari,
and H. Hellwagner. CSDN: CDN-Aware QoE Optimization in SDN-Assisted HTTP
Adaptive Video Streaming. IEEE 46th Conference on Local Computer Networks
(LCN), 2021.

  7. 7.

$\bigstar$ R. Farahani, F. Tashtarian, A. Erfanian, C. Timmerer, M. Ghanbari,
and H. Hellwagner. ES-HAS: An Edge- and SDN-Assisted Framework for HTTP
Adaptive Video Streaming. 31st ACM Workshop on Network and Operating Systems
Support for Digital Audio and Video (NOSSDAV), 2021.

  8. 8.

R. Farahani. CDN and SDN Support and Player Interaction for HTTP Adaptive
Video Streaming. 12th ACM Multimedia Systems Conference (MMSys), 2021.

  9. 9.

R. Farahani, A. Bentaleb, M. Shojafar, H. Hellwagner. CP-Steering: CDN- and
Protocol-Aware Content Steering Solution for HTTP Adaptive Video Streaming.
ACM Mile High Video (MHV), 2023.

  10. 10.

R. Farahani, H. Amirpour, F. Tashtarian, A. Bentaleb, C. Timmerer, H.
Hellwagner, and R. Zimmermann. RICHTER: Hybrid P2P-CDN Architecture for Low
Latency Live Video Streaming. ACM Mile-High Video (MHV), 2022.

####  1.5.2 Co-authored Publications

  1. 11.

V. V Menon, P. T Rajendran, R. Farahani, K. Schöffmann, C. Timmerer. Video
Quality Assessment with Texture Information Fusion for Streaming Applications.
Submitted to the IEEE International Conference on Visual Communications and
Image Processing (VCIP), 2023.

  2. 12.

V. V Menon, R. Farahani, P. T Rajendran, H. Hellwagner, M. Ghanbari, C.
Timmerer. Reduced Reference Transcoding Quality Prediction for Video Streaming
Applications. ACM Mile High Video (MHV), 2023.

  3. 13.

S. Chellappa, R. Farahani, R. Bartos, H. Hellwagner. Context-Aware HTTP
Adaptive Video Streaming Utilizing QUIC’s Stream Priority. ACM Mile High Video
(MHV), 2023.

  4. 14.

A. Bentaleb, R. Farahani, F. Tashtarian, H. Hellwagner, R. Zimmermann. Which
CDN to Download From? A Client and Server Strategies. ACM Mile High Video
(MHV), 2023.

  5. 15.

R. Shokri Kalan, R. Farahani, E. Karsli, C. Timmerer, and H. Hellwagner.
Towards Low Latency Live Streaming: Challenges in Real-World Deployment. 13th
ACM Multimedia Systems Conference (MMSys), 2022.

  6. 16.

F. Tashtarian, A. Bentaleb, R. Farahani, M. Nguyen, C. Timmerer, H.
Hellwagner, and R. Zimmermann. A Distributed Delivery Architecture for User
Generated Content Live Streaming over HTTP. IEEE 46th Conference on Local
Computer Networks (LCN), 2021.

  7. 17.

A. Erfanian, F. Tashtarian, R. Farahani, C. Timmerer, and H. Hellwagner. On
Optimizing Resource Utilization in AVC-based Real-time Video Streaming. 6th
IEEE Conference on Network Softwarization (NetSoft), 2020.

###  1.6 Thesis Organization

In Chapter 2, we provide the general technical background of modern networking
paradigms utilized in designing NAVS frameworks. Furthermore, this chapter
surveys state-of-the-art approaches in the areas of the described research
contributions.

The focus of Chapter 3 is utilizing edge and SDN capabilities to present NAVS
solutions for HAS clients. This chapter describes the details of the ES-HAS
Farahani et al. (2021b) and CSDN Farahani et al. (2021a) frameworks. More
specifically, in each section, we first express our primary motivation through
examples and define problems. We then describe the details of each system’s
architecture and formulate each problem as a mathematical optimization model.
At the end of each section, we discuss the details of the testbed design and
obtain and analyze results. Finally, we summarize the chapter’s achievements
and learned lessons.

In Chapter 4, we introduce an SFC-enabled architecture for adaptive video
streaming applications called SARENA Farahani et al. (2023b). We first
elaborate on the SARENA multi-layer architecture and formulate the problem as
an optimization model. We then propose a lightweight heuristic model before
discussing the details of the designed testbed and achieved results. We
finally conclude the chapter by highlighting achievements and the findings.

Chapter 5 proposes two collaborative edge-assisted frameworks for HAS clients,
LEADER
Farahani et al. (2022d) and ARARAT Farahani et al. (2022c), in two sections.
In each section, we first describe the system design perspective, including
the problem statement, architecture, and system model. Afterward, we propose
the heuristic solution(s), which are designed to remedy the high time
complexity of the proposed optimization models. We finally describe evaluation
setups and methods and perform in-depth analyses of these collaborative
systems before emphasizing the achievements and learned lessons of the
chapter.

Chapter 6 explains the details of two hybrid P2P-CDN architectures for HAS-
based systems, called RICHTER Farahani et al. (2022a) and ALIVE Farahani et
al. (2023c), in two sections. Each section first discusses the problem
statement, particular architecture, and problem formulation. It then discusses
the proposed heuristic scheme(s) before providing a comprehensive testbed
evaluation and model analysis. At the end of this chapter, we summarize the
outcomes and valuable insights that we have gained.

This thesis is concluded in Chapter 7 by briefly summarizing the conducted
studies, the obtained results, and the derived insights. Furthermore, four
promising future research directions are discussed at the end of this chapter.

##  Chapter 2 Technical Background and Related Work

Improving video quality for HAS users relying solely on embedded players’ ABR
algorithms is a complex and challenging task. This is because pure client-
based HAS solutions use limited awareness of streaming and network conditions.
To address this challenge, Network-Assisted Video Streaming (NAVS) solutions
have emerged. In NAVS systems, an in-network component (e.g., edge server or
SDN controller) with a broader view of the network is employed to assist video
players in making precise adaptation decisions, hence improving users’ QoE and
network QoS KPIs. In this chapter, we first discuss the end-to-end (E2E)
workflow of one of the popular HAS-based video streaming applications, i.e.,
live streaming. We also explain the concept of fundamental and emerging
networking paradigms in six different categories, which are leveraged in
designing our proposed NAVS solutions. Finally, we review prior work in the
network-assisted video streaming domain in two categories, highlight several
standardization activities, and describe research gaps in the literature for
designing NAVS systems.

###  2.1 Technical Background

This section explains the details of the HTTP Adaptive Streaming (HAS)
technology, plus the concept of six key networking paradigms. These paradigms
are utilized in the subsequent technical chapters (Chapters 3–6) to introduce
NAVS streaming frameworks for HAS clients.

####  2.1.1 HTTP Adaptive Streaming (HAS)

Although traditional video delivery technologies such as Real-time Transport
Protocol (RTP) Schulzrinne, Henning and Casner, Stephen and Frederick, Ron and
Jacobson, Van (2003), Real-Time Messaging Protocol (RTMP) Adobe (2014), and
Real Time Streaming Protocol (RTSP) Schulzrinne et al. (1998) have their own
merits, many works have revealed their limitations to achieve scalability and
vendor independency, and their high maintenance costs Bentaleb et al. (2018b).
Many technologies have emerged in recent years to improve video streaming
services. Among them, HTTP Adaptive Streaming (HAS)-based solutions, such as
Dynamic Adaptive Streaming over HTTP (DASH) Sodagar (2011) or Apple’s HTTP
Live Streaming (HLS) Pantos and May (2017), with delivering more than 50% of
video streams, have become the most prevalent technologies utilized by Over-
the-Top (OTT) providers for VoD and live video streaming applications Sandvine
(January 2023). In HAS-enabled systems, video sequences are split into short-
and fixed-duration segments (i.e., between one and ten seconds durations), and
then each segment is encoded into multiple versions called representations
(i.e., resolutions or bitrate levels). Information on the segments, including
their locations on media servers, e.g., CDN servers or origin server, is
stored within a manifest file such as DASH’s Media Presentation Description
(MPD). HAS players then process MPDs and consider the current network status
and/or capabilities of the user equipment (e.g., playout buffer) to adaptively
download appropriate representations from media servers using Adaptive Bitrate
(ABR) algorithms, consequently improving users’ QoE Dao et al. (2022).

Fig. 2.1: Example of an E2E HTTP adaptive live video streaming system Kalan et
al. (2022).

The workflow of a real-world E2E HAS-based system for live video streaming is
shown in Fig. 2.1, which includes five core parts as follows (part and step
numbering as in the figure):

  1. 1.

Capturing/Transmitting.  A live event is captured (step  1) and then
transmitted via satellite or dedicated network connection to the OTT
headquarters (steps  2 and  3).

  2. 2.

Processing/Storing. The raw input video is encoded through encoders to produce
multiple representations of a single video. After encoding, the produced
representations are sent to the data center (DC) (step  4). The DC can be
employed for both packaging (i.e., into a specific HAS format like DASH) and
caching functions (step  5) to improve the origin server utilization by (i)
avoiding to package all bitrates and (ii) storing a minimum number of
bitrates. When a client’s request for segment $s$ and bitrate $b$ comes to the
origin server, it does on-the-fly packaging and returns the requested ($s,b$)
segment to the client. To prevent running computation-intensive tasks, i.e.,
packaging ($s,b$) for another client request, ($s,b$) is cached on the origin
server (step  6).

  3. 3.

Analyzing.  Monitoring and analyzing tools can be used, focusing on network
conditions and client quality parameters. To do that, monitoring software can
be used to monitor both the origin and the CDN servers (step  7). The provided
information could be used for load balancing or the selection of the best
origin/CDN server. Moreover, monitoring software can be employed as an online
video analyzer tool to investigate client access patterns for some purposes
like producing popular representations.

  4. 4.

Delivering.  In order to provide fast delivery and a high level of
reliability, CDN provider services can be used as well. When ($s,b$) is
unavailable in the CDN, it will be fetched from the origin server (step  8).

  5. 5.

Rendering. Different types of clients, e.g., Web browsers, mobile devices, and
TVs, can be connected to and served by such an envirenment, where the number
of connected clients and requested bitrates changes dynamically.

This thesis uses existing and standard HAS technology to design NAVS systems
for VoD and live streaming.

####  2.1.2 Content Delivery Networks (CDNs)

A Content Delivery Network (CDN) is a distributed network of servers that work
together to deliver content to users. The content could be any type of digital
assets, such as data, web pages, or multimedia content. A conceptual
architecture of CDNs, including three key components, is illustrated in Fig.
2.2 Pathan et al. (2007). These components are:

  1. 1.

CDN Servers. These servers (also so-called surrogate, cache, or edge servers)
are located in different geographical locations close to the end-users to
cache and deliver content quickly and efficiently. Indeed, when a user
requests content, the request is first directed to the nearest CDN server.
Afterward, the CDN server checks the availability of the content in its cache.
If the CDN server holds the content, it serves the request directly, much
faster than retrieving it from the origin server. Otherwise, the content will
be fetched and served from the origin server, at rates slower than serving
from the CDN server.

  2. 2.

Origin Server. This server is responsible for generating the content, storing
the original content, and ensuring it is updated. When a CDN server does not
cache the requested content, the origin server serves the request and then
feeds the CDN servers for future demands based on the CDN content distributor
policy.

  3. 3.

CDN Content Distributor. This component manages content distribution across
the CDN and defines important policies for improving the CDN network
performance. For example, it monitors the CDN network to detect frequently
accessed content and to have it cached on CDN servers, reducing the load on
the origin server and improving the overall performance of content delivery.
Furthermore, it monitors user requests to distribute them across multiple CDN
servers to ensure that no single server is overloaded. These algorithms take
into account the CDN’s KPIs to ensure that content is delivered to end-users
quickly and efficiently.

Fig. 2.2: Illustration of a CDN architecture.

These components work together to build a CDN infrastructure that offers
scalable services and enhances website and application performance Pathan et
al. (2007). Due to the ability of CDNs in delivering large volumes of data and
the increasing demand for low-latency and high-quality video streaming
services, CDNs have become the primary method for video delivery Cisco (2018).
In the following chapter, we utilize CDN caching services to introduce NAVS
solutions for HAS clients.

####  2.1.3 Peer-to-Peer (P2P) Networks

A Peer-to-Peer (P2P) network is a decentralized content delivery network where
each device, a so-called peer, communicates and shares content directly with
others rather than relying on a centralized server. In fact, each peer in a
P2P network acts as both client and server, which enables content to be
downloaded and uploaded simultaneously Siano et al. (2019). It is worth noting
that content refers to data, digital media (i.e., audio, video), and software
in this context. An example architecture of a P2P network is shown in Fig.
2.3, where the following components play critical roles:

  1. 1.

Tracker Server. This server is responsible for keeping track of the peers and
coordinating their content exchange. When a peer requests content, it contacts
the tracker server to fetch a list of other peers which hold the content for
downloading. This list enables the peer to connect to others and download the
requested content directly without relying on a central server. However, it is
worth noting that in other P2P structures, peers can discover other peers
through other methods, e.g., distributed hash tables (DHTs), instead of using
a tracker server Anjum et al. (2017).

  2. 2.

Seeders. Seeders are one type of peers which have completely downloaded
content and are willing to share it with other peers. Once a peer downloads
the content from a seeder, it may become a seeder and continues sharing it
with others. Holding high resources, e.g., upload/download bandwidth and
battery, is another characteristic of seeders, which allows them to remain
connected to the P2P network for extended periods; consequently, other peers
fetch their desired content from these stable peers.

  3. 3.

Leechers. In contrast to seeders, peers which are still in the process of
downloading the content and have not yet fetched the complete content are
referred to as leechers. The P2P network would not operate effectively without
seeders since leechers could not complete their downloads without them.

Fig. 2.3: Illustration of a P2P network.

A swarm in Fig. 2.3 refers to a group of peers which concurrently download and
share content at a particular time. As more peers join the swarm and commence
downloading and sharing the content, the number of sources from which fetches
can occur increases, resulting in more efficient and rapid downloads.
Considering features provided by the P2P networks, many companies, e.g.,
Peer5111https://peer5.com/; last access: 2023-03-16.,
Strivecast222https://strivecast.com/; last access: 2023-03-16., and
Livepeer333https://livepeer.org/; last access: 2023-03-16. have been utilizing
peer-assisted networks with emerging communication protocols such as Web Real-
Time Communications (WebRTC) Roach (2016); Jansen et al. (2018) to assist CDNs
and provide low-latency and high-quality video streaming services. In Chapter
6, we leverage the decentralized property of a P2P network, show how
computational tasks, e.g., video transcoding and video super-resolution, can
be offloaded to peers, and introduce novel hybrid P2P-CDN frameworks for HAS
clients.

####  2.1.4 Software Defined Networking (SDN)

In traditional networks, all networking devices, such as layer 3 routers and
layer 2 switches, combine the control plane and data plane into a single unit.
Indeed, both functions are tightly integrated, and each proprietary networking
device performs both functions within the same hardware (Fig. 2.4(a)). The
control plane executes decision-making tasks such as routing, switching, or
security policy enforcement, while data plane functions involve forwarding
network traffic. As a result, managing such networks poses considerable
challenges, such as:

  1. 1.

Complexity. Network administrators must configure individual network devices
separately, which can lead to human error and misconfiguration, resulting in
complex network management.

  2. 2.

Lack of flexibility. Since each network device can only provide information
about its immediate neighbors, achieving a broader view of the network
topology is impossible. Consequently, when there is a problem in the network,
it can be complicated to troubleshoot the fault.

  3. 3.

Lack of automation. Network administrators must manually execute all
management and configuration tasks without any automation procedure, which can
be time-consuming.

Fig. 2.4: (a) Traditional and (b) SDN-based network architectures.

The aforementioned issues led to the developing network softwarization
paradigm, which replaces traditional networks with Software Defined Networking
(SDN)-enabled networks Kreutz et al. (2014). As depicted in Fig. 2.4 (b), the
control plane and data plane are decoupled in the SDN approach, and the
control plane is placed in a central entity called the SDN controller. This
decoupling allows the SDN controller to communicate with programmable network
nodes, manage traffic flows more efficiently, simplify network management, and
then apply network policies to satisfy network services’ requirements (e.g.,
video streaming), overall addressing the above-mentioned challenges. One
considerable difference between traditional and SDN-based networks is that SDN
presents a communication interface, such as standardized OpenFlow (OF) McKeown
et al. (2008), that connects network devices to the SDN controllers. This
feature allows network developers, administrators, and managers to define
network-aware policies for any type of application, such as video streaming,
that can dynamically adjust to changing network conditions and take advantage
of network resources more effectively. In Chapters 3–5, we show how the SDN
controller characteristics can be utilized to develop network-assisted video
streaming frameworks for HAS clients.

####  2.1.5 Network Function Virtualization (NFV)

As previously stated, the use of dedicated network devices in traditional
networks gives rise to numerous issues, such as high deployment costs, limited
adaptability, and difficult-to-manage services.

Fig. 2.5: (a) Traditional and (b) NFV-based network components.

To cope with these issues, a group of leading service providers, including
AT&T, Verizon, and Deutsche Telekom, established the Network Functions
Virtualization (NFV) Industry Specification Group within the European
Telecommunications Standards Institute (ETSI) in 2012 ETSI (2014). The NFV
group aimed to add the idea of virtualization to the network, which enables
network functions to be implemented as Virtualized Network Functions (VNFs) on
any network appliance. As Fig. 2.5 illustrates, traditional network functions
such as routers, switches, or firewalls are virtualized and run as software
applications, e.g., vRouter, vSwitch, or vFirewall on general-purpose
appliances, rather than being dependent on proprietary network devices.
Moreover, the NFV paradigm provides network layer virtualization to present a
slice of the NFV Infrastructure as an NFVI service Chiosi et al. (2012).

Considering the aforementioned benefits, the combination of SDN and NFV
paradigms leads to an agile, scalable, and innovative network. In such
networks, the SDN controller orchestrates the network resources and VNFs to
manage the network functions; thus, operators can provide E2E network services
that are highly automated, programmable, and adaptable to changing business
needs. For instance, the SDN controller has the potential to partition the
network into multiple virtual networks (i.e., slices) for different purposes
(e.g., video delivery), thus enabling operators to provide customized network
services to various users or applications Viola et al. (2023). In the next
technical chapters, we elaborate on how multimedia functions can be presented
as VNFs and how the SDN controller can orchestrate the network and VNFs to
deliver multimedia services.

####  2.1.6 Service Function Chaining (SFC)

Providing a range of network services in an NFV-enabled infrastructure using
only one type of VNF is impossible. This is because network services require
their traffic to be steered through a set of VNFs in a specific order. To
address this issue, Service Function Chaining (SFC), relying on the NFV
paradigm, has been introduced by the Internet Engineering Task Force (IETF) to
direct network traffic through a sequence or chain of VNFs Halpern and
Pignataro (2015).

Fig. 2.6: Illustration of an SFC-enabled system.

An example of an SFC-enabled system is shown in Fig. 2.6, where two different
network services from the source server are requested by client I (red) and
client II (blue). Suppose that both network services must be steered through
VNF1$\rightarrow$VNF2$\rightarrow$VNF3, and each intermediate server (i.e.,
server I-IV) holds a single or a set of these VNFs. Moreover, assume the
priority of the first service (issued by client I) is higher than the second
service. Based on the network service requirements and VNF availability, chain
VNF1$\rightarrow$VNF2$\rightarrow$VNF3 of the server I can be chosen to serve
client I. Furthermore, VNF1 of server II, VNF2 of server III, and VNF3 of
server IV, are selected to form the mentioned chain and serve client II. Note
that defining appropriate service VNFs, and suitable VNF placement, service
scheduling, and resource allocation algorithms involve many vital
considerations and decisions. Chapter 4 shows how the SDN and SFC paradigms
can be leveraged to present an architecture for serving various types of
multimedia services.

####  2.1.7 Multi-Access Edge Computing (MEC)

Cloud computing has become the de-facto technology in computing, enabling
users to quickly invoke a range of servers and deploy a variety of user-
customized infrastructure services (e.g., storage, resource management,
scaling, monitoring) on them. The edge computing paradigm, e.g., Multi-Access
Edge Computing (MEC) Taleb et al. (2017), has been proposed as a complementary
technology to cloud computing that provides storage and compute resources
close to end-users at the network’s edge, thus offering lower data processing
latencies, better user experience, and lower cost and bandwidth consumption
than cloud-based computing. In contrast to the cloud, edge servers often
include limited resources.

Fig. 2.7: Illustration of cloud and edge computing.

Due to the nature of edge computing (e.g., improved latency, network
congestion, scalability, reliability), it is one of the most suitable
techniques to support video streaming applications Khan et al. (2022a) (see
Fig. 2.7 for cloud and edge comparison). It can offer several merits in
various types of video streaming applications, including:

  1. 1.

VoD Streaming. Applying techniques such as most popular content caching or
content prefetching in advance at the edge enhances the scalability and
reliability of VoD services while reducing the load on cloud servers (e.g.,
origin server), enabling faster content delivery, and boosting user QoE.

  2. 2.

Live Streaming. Employing caching, transcoding, and processing content closer
to the end user, where data is generated and consumed, reduces latency and
improves live video streaming quality.

  3. 3.

Immersive Video Streaming. Processing and rendering content closer to the end
user reduces latency and improves performance for immersive streaming
applications. This is because such applications, e.g., Augmented Reality (AR)
or Virtual Reality (VR), require real-time processing and rendering of video
content.

In all our contributions, we leverage MEC capabilities to improve user QoE and
network utilization for the two first applications, i.e., VoD and live
streaming.

###  2.2 Related Work

This section surveys state-of-the-art solutions and highlights standardization
activities in two categories. At the end of this section, we summarize related
work properties in Table 2.1.

####  2.2.1 SDN- and/or Edge-Based NAVS Solutions

Innovations in network architecture, specifically in core and edge
infrastructures, have enabled large CDNs to manage their caching resources
better and enhance the quality of user experience. The SDN model is a
noteworthy advancement in this area, as it utilizes software-based principles
to enable CDNs to have more flexible and real-time traffic management, which
can be easily administered. Mukerjee et al. investigated the use of the
control plane for domain name system (DNS) load-balancing to improve the QoE
of live video delivery Mukerjee et al. (2015). The work by Kleinrouweler et
al. proposed an SDN-assisted architecture for DASH clients utilizing a
modified version of OpenFlow (OF) switches to support QoS differentiation
Kleinrouweler et al. (2016). They did not use the edge and NFV paradigms, and
QoS differentiation was their only objective. Wamser et al. proposed a dynamic
re-routing strategy to avoid link congestion during streaming sessions Wamser
et al. (2015). Since congested links primarily occur in the network edge, and
traffic re-routing can only be set within the core network, this method is
only partially effective in optimizing the behavior of HAS clients.

Bentaleb et al. introduced an NAVS solution called SDNDASH Bentaleb et al.
(2016), which uses SDN capabilities to dynamically allocate network resources
based on QoS criteria to increase the users’ QoE. They employed a client-side
probe to estimate the available network resources and allocate bandwidth
resources dynamically to each client. Using this method, they prevent quality
instability, unfair distribution of bandwidth, and inefficient use of network
resources among multiple DASH clients that share bottleneck network links.
However, Bhat Bhat et al. (2017) showed that such a probe-based solution as
proposed by SDNDASH leads to an overhead both for the network and control
plane. As an extension to this work, Bentaleb et al. proposed another NAVS
system called SDNHAS Bentaleb et al. (2017) to support a cluster-based
estimation for bandwidth requests and address the scalability issue of
SDNDASH. SDNHAS employed a reinforcement learning (RL)-based optimizer
component that utilizes the Structural Similarity Index Plus (SSIMplus) Rehman
et al. (2015) perceptual quality metric to create a logical network topology
and group the HAS players into virtual clusters. In such a way, clients
belonging to the same cluster receive similar recommendations (i.e., bitrate
levels and their corresponding qualities) and bandwidth slice allocations.

Bhat et al. proposed network-assisted content distribution for a QoE-driven
ABR video streaming system, entitled SABR Bhat et al. (2018). In an SABR-
enabled system, DASH clients are enabled to receive support from an SDN
controller by requesting information on available video sources, such as a
list of CDN servers, a list of video segments/qualities, and network
conditions, e.g., bandwidth history, for making well-informed decisions on
content requests. The authors also proposed a network-assisted caching
mechanism that helps to reduce the amount of data that needs to be transferred
over the network, resulting in improved video playback quality. However, the
client must be modified to be compatible with the SABR strategy. Bentaleb et
al. utilized an online reinforcement learning (ORL) model to introduce a QoE
optimization framework for SDN-enabled HAS systems, named ORL-SDN Bentaleb et
al. (2018a). ORL-SDN groups the HAS players into disjoint clusters based on a
perceptual quality index and then formulates the bitrate selection problem as
a partially observable Markov decision process. It finally executes an online
Q-learning algorithm to solve the QoE optimization problem and determine the
optimal bitrate decision for each cluster. Nevertheless, ORL-SDN imposes
considerable client-side modifications, making it incompatible with the most
common HAS players.

Kalan et al. presented an SDN-assisted HAS system for assisting clients in
selecting the video codec, bitrate, and routing the video packet over the
appropriate network paths Kalan and Sayit (2021). However, layered coding used
in their work is out of this thesis’s scope. Ozcelik and Ersoy presented a
chunk-size aware SDN-assisted DASH mechanism for streaming called CSASDN
Ozcelik and Ersoy (2019). CSASDN employs various segment durations over the
standard HTTP 1.1 GET and POST requests to provide fair QoE for the DASH
players while avoiding network underutilization. In the proposed system, each
player shares the device characteristics and the content details of the
requested video with the SDN controller, and the SDN controller supports them
in finding the optimal maximum bitrate. Ge et al. devised a novel framework
named MVP (mobile edge virtualization with adaptive prefetching) that assures
4K quality for VoD scenarios in 5G networks. This method employs a context-
aware adaptive video prefetching scheme deployed at the mobile edge to achieve
an improved QoE Ge et al. (2017). The authors in Ge et al. (2018) introduced
an edge-based transient holding strategy for live segments called ETHELE.
ETHELE uses QoE information from the users’ devices and RAN (Radio Access
Network) conditions provided by RNIS (Radio Network Information Service) to
conduct transient holding of a minimum number of video segments at the edge
servers, achieving a seamless 4K live streaming experience by eliminating
buffering and reducing initial startup delay and live stream latency. In fact,
utilizing the holding method assists the clients in selecting a suitable
initial video segment (IVS) that best matches their network throughput to
start the playback. However, all of these approaches modified the client side
to have a compatible system with any ABR algorithm. In addition, they do not
propose any solution for making an efficient collaboration between SDN
controller and edge devices as well as among edge devices.

As discussed in Section 2.1.7, edge computing is a technology for providing
computation and caching services for video streaming applications to satisfy
the QoE requirements. Bayhan et al. proposed the EdgeDASH Bayhan et al. (2020)
framework, which caches popular contents at a WiFi Access Point (AP) and
redirects clients’ requests to this edge node instead of serving them from the
origin server. EdgeDASH’s AP also assists DASH clients in making adaptation
decisions by offering a few quality levels higher or lower than the requested
ones if the alternative quality provides a better QoE. The authors showed that
EdgeDASH improved cache hits, decreased buffer stalls, and increased video
bitrates. Mehrabi et al. in Mehrabi et al. (2018) introduced an edge-enabled
rate adaptation system through a greedy client/server mapping strategy to
jointly maximize the QoE and fairness of competing mobile video streaming
clients. They demonstrated that the proposed solution outperforms client-based
rate adaptation heuristics. However, due to increasing content volume and the
limited cache size of the edge nodes (e.g., EdgeDASH’s WiFi AP), it is
impossible to cache all the contents locally through such approaches.
Considering the resource limitations of edge servers (i.e., storage,
computation, and bandwidth) and the heterogeneity of users’ requests, some
works like Tran and Pompili (2018); Baccour et al. (2020) proposed
collaborative caching and processing schemes, mainly when several clients’
requests exceed the available edge servers’ resources. However, they did not
utilize the SDN controller capabilities as a network orchestrator.

Since Initial Video Segment (IVS) parameters affect QoE performance, Wang et
al. designed Rldish Wang et al. (2020a), a reinforcement learning (RL)-based
strategy, which is deployed at the edge server to dynamically select a
suitable IVS for new live viewers. In fact, Rldish monitors users’ QoE at the
edge servers and uses QoE values as a reward function of the RL algorithm. The
QoE metrics in this system are defined as a weighted combination of a maximum
start-up delay and buffering time. However, training RL models in real-time
and achieving convergence in dynamic environments can be challenging. Zhang et
al. introduced a video super-resolution (SR) and caching system named VISCA
Zhang et al. (2021), which utilizes a video super-resolution technique for
upscaling the requested video from a low-resolution video at the edge of the
network and designs an edge-based ABR algorithm to improve users’ QoE.
However, since the output of the super-resolution module is raw-input video,
recompression is needed to transmit the reconstructed video segment. Thus,
extra delay and distortion will be imposed by the system. Therefore, the best
place for applying the super-resolution technique can be the peers, where the
decoded segments will be immediately played out after reconstruction.
Moreover, edge servers in the aforementioned systems do not have comprehensive
information about the network topology; thus, they individually could not be
the most suitable candidates to assist HAS users. Therefore, employing a
network entity with a broader view of the network, e.g., an SDN controller,
besides edge servers, could further improve users’ QoE and network
utilization.

Although edge computing pushes the services to the edge closer to the end user
with lower latency and higher throughput, this approach comes with several
challenges, like limited computational resources and handling heterogeneous
users’ requests. Hence, combining the SDN and MEC paradigms and integrating
them with the existing network infrastructure brings advantages, e.g.,
improved interoperability between different network components through the
coordination of the SDN controller Baktir et al. (2017); Jiang et al. (2021).
Liotou et al. devised a video segment selection and caching strategy using SDN
and edge computing called QoE-SDN Liotou et al. (2018). Their approach allows
feedback from the Mobile Network Operator (MNOs) to the Video Service Provider
(VSPs) toward a better network-aware video segment selection. However,
scalability needs to be investigated further in this solution. Erfanian et al.
leveraged the SDN and NFV concepts to form a multicast tree(s) for live
streaming and then introduce a cost-aware real-time video streaming approach
Erfanian et al. (2020). Their solution uses a set of edge virtualized
components to gather clients’ information, cooperate with the SDN controller
and transmit them through a hybrid multicast/unicast approach. However, the
edge components are limited to functioning independently, as the SDN
controller did not include any techniques to enable edge servers to facilitate
the use of idle resources of other edge servers or network components. Thus,
collaboration among edge servers can result in improving the utilization of
available resources.

####  2.2.2 CDN- and/or P2P-Based NAVS Solutions

With emerging HAS-based technologies, OTT companies often utilize distributed
CDN servers in different geographical locations to get more reliable and cost-
effective content delivery. Intense research in a variety of aspects relevant
to content delivery performance and costs, like user request routing Chen et
al. (2015); Zhu et al. (2022), content placement and replication Passarella
(2012); Li et al. (2019), server offloading Fang et al. (2022), and transport
costs Rizk et al. (2017), as well as content popularity and content awareness
Koch et al. (2018); Yao et al. (2019) has been pursued in recent years. Many
works such as Pedersen and Dey (2015); Ma et al. (2017); Choi et al. (2018);
Zhang et al. (2022) propose new caching strategies to improve CDN hit rates
and eventually enhance video QoE. The detailed “interplay of quality
adaptation mechanisms, network bandwidth information, as well as caching
strategies” Bhat et al. (2017) is barely addressed in works on global control
for CDN-based video delivery, e.g., Ganjam et al. (2015).

Some works like Akhshabi et al. (2013) use a server-assisted HAS adaptation
approach where an element, e.g., CDN server, can assist HAS players in
deciding the next segment’s representation. The proposed method in Akhshabi et
al. (2013) aims to detect quality fluctuations by analyzing client requests.
Once such oscillations are identified, a corresponding server-side algorithm
is triggered, restricting the maximum segment’s quality level the client can
access. This restriction is implemented to stabilize the stream quality level
and mitigate further oscillations. Although such solutions improve the HAS
adaptation performance compared to the pure client-based approaches with only
local parameters’ consideration, they encounter significant problems in large-
scale deployment. A network-assistance approach can be taken into account as
an alternative solution, where both in-network elements and servers support
the bitrate adaptation. For example, the authors in El Marai et al. (2017)
introduced an enhanced server and client cooperation called ESTC. ESTC
facilitates rapid convergence among different clients’ bandwidth levels
towards the estimated bandwidth through enabling close collaboration between
the server and client sides. It also appropriately assigns the allocated
bitrate to clients, where the clients have the responsibility for making the
right bitrate adaptation decisions for efficiency and service stability
insurance. In addition, the server leverages information such as the number of
connected clients, current download bitrates, and bottleneck link bandwidth to
ensure fairness among competing clients.

The Server and Network-Assisted Dynamic Adaptive Streaming over HTTP (SAND)
standard Thomas et al. (2016) was introduced by MPEG. SAND tries to mitigate
DASH performance problems by enabling protocol messages to be exchanged among
network components, e.g., CDN servers. However, SAND does not specify how to
handle such messages efficiently. SAND defines four message types, i.e.,
status messages, metrics messages like buffer occupancy, packets enhancing
reception, and packets enhancing delivery. If a network component can process
all mentioned messages or a subset of them, it is called a DASH-Aware Network
Element (DANE). A novel delivery scheme that combined both SAND and Content
Centric Networks (CCN) was introduced in Jmal et al. (2017). The authors
demonstrated how the SAND architecture could solve the bandwidth oscillation
problems of DASH-based systems over traditional delivery architectures by the
existence of cache proxies in the CCN delivery network. However, the proposed
approach primarily targets CCN-based architectures, which are distinct from
the more widely used CDN-based architectures. Although SAND-based systems can
improve client-side adaptation decisions, they are not straightforward to
implement, and only a few papers like Kalan et al. (2019); Thomas et al.
(2018); Kalan (2021) have pursued this approach yet Farahani (2021).

A specification by the Consumer Technology Association (CTA) in the Web
Application Video Ecosystem (WAVE) project has introduced solutions termed
Common Media Client Data (CMCD) and Common Media Server Data (CMSD) CTA-5004
(2020); CTA-WAVE (2021). The primary motivation behind designing the CMCD and
CMSD was to address questions as follows Lim et al. (2022): (i) How could a
streaming client relay media-related information (e.g., segment
type/duration/format, content/session IDs) to the CDN in a way that allows the
CDN to associate individual GET requests with playback sessions? (ii) How
could a streaming client relay playback-related information (e.g., current
buffer length and latency) to the CDN in a way that enables accurate
generation of dashboard metrics, such as delivery performance, player software
issues, and viewer experience? (iii) How could the CDN react to the time
constraints implicit in media segment requests (e.g., prioritize delivery for
urgent requests)?

The CMCD protocol outlines data collected by a client and sent to the CDNs,
which facilitates the correlation of CDN data with client data. This
correlation enables content providers to enhance CDN performance while
ensuring that viewers receive high-quality content. For instance, by utilizing
the CMCD information, CDNs can improve their performance via (i) intelligently
responding to the implicit time constraints of each request and (ii)
identifying performance issues that may be linked to particular devices or
player software versions. The CMSD specification enables the CDNs to send
useful information back to the clients Begen et al. (2021). Bentaleb et al.
Bentaleb et al. (2021b) built an initial proof-of-concept system that adheres
to the CMCD specification on both the client and server ends. Their proposed
system deployed a buffer-aware bandwidth allocation mechanism to enhance the
clients’ QoE for clients that share network bandwidth. Begen et al. in Begen
et al. (2021) presented an overview of the CMCD and CMSD specifications and
demonstrated various applications of CMCD to improve HAS-based streaming.
However, this work did not provide any implementations.

Several prior works like Xie et al. (2008) proposed solutions for establishing
a collaboration between network service providers and content providers
leading to an Internet Engineering Task Force (IETF) standard called
Application-Layer Traffic Optimization (ALTO) Alimi et al. (2014). ALTO
enables P2P applications to obtain abstract maps of network information,
including from CDNs, to optimize network resource consumption and traffic
delivery while maintaining application performance. However, some studies
reveal that the ALTO protocol still has drawbacks, and its usage is limited
Ellouze et al. (2013). As another well-known peer-assisted product, Akamai
introduced the NetSession interface Zhao et al. (2013) that provides peer-
assisted delivery and supports peer-CDN cooperation. However, it is required
to install the software on the client’s device. Our works differ from the
above-mentioned approaches because we do not modify the client side. As a
consequence, the proposed NAVS frameworks can be compatible with any ABR
algorithm. In the last decade, both academia and industry have considered
combining P2P and CDN delivery networks to improve performance and reduce the
cost of OTT video delivery services. A P2P-CDN NAVS system is a hybrid
architecture that aims to use the advantages of both P2P and CDN systems. In
such systems, the most challenging research question is: “How should the
traditional CDN and P2P networks be integrated to enable OTT providers to
efficiently employ users’ resources and benefit from both CDN and P2P
networks’ advantages?”

Xuening et al. proposed a commercial hybrid CDN-P2P system for live video
streaming applications called LiveSky Yin et al. (2009). LiveSky used the CDN
servers to deliver the video sequences from the source to the edge of the
network, while the P2P network was employed to deliver the video sequences
from the edge to end users. Moreover, the authors propose an adaptive scaling
mechanism to provide fairness in video delivery by dynamically adjusting the
contribution of each peer in the P2P network based on its available bandwidth
and buffer status. Ha et al. presented a dedicated hybrid P2P-CDN system for
live video streaming to reduce CDN usage significantly Ha et al. (2017). In
their proposed system, the video segments are portioned further into small
chunks of equal size. The HAS player modules were customized and equipped with
an additional P2P module that prefetches the video chunks ahead of time.
However, Yousef et al. Yousef et al. (2020) showed that the prefetching
process in such a system might be incomplete due to the peers’ heterogeneity.

Khan et al. Khan et al. (2022b) proposed a Computation Offloading in the
D2D-Edge framework called CODE. They proposed Integer Linear Programming (ILP)
models, i.e., maximal offloading with delay constraint (MOD), minimum delay
offloading (MDO), and a lightweight heuristic to form cooperation between edge
servers and peers in MEC networks to efficiently utilize the edge
computational resources during large-events live streaming. Ma et al. proposed
learning-based methods for hybrid P2P-CDN live video streaming systems that
enable their trackers to perform peer selection Ma et al. (2021). They first
analyzed a large-scale hybrid CDN-P2P live streaming system and collected a
dataset of popular channels in Europe and North Africa, and then trained a
neural network (NN)-based model. All the systems mentioned above use only the
storage and bandwidth resources of peers, not their computational resources,
for reconstructing the requested video from available higher quality (e.g., by
transcoding) or from lower resolution (e.g., by super-resolution), besides CDN
servers to enhance users’ QoE and network utilization. To fill this gap, we
will use all feasible peers’ computational resources and propose two hybrid
P2P-CDN NAVS frameworks in Chapter 6.

Nacakli et al. combined the SDN and edge computing paradigms to present a
novel hybrid P2P-CDN live video streaming service Nacakli and Tekalp (2020).
In their proposed architecture, the edge data centers fully control the
service with the support of an SDN controller. In fact, their proposed edge
servers employ a P2P grouping method and a P2P scheduling algorithm
considering CDN locations to reduce CDN server loads, overcome the QoE
fluctuations in each flow, and improve fairness between heterogeneous clients
that request different video qualities/resolutions. The authors in Kumar et
al. (2022) leveraged the SDN concept and presented the concept of “CDN at the
edge” where end hosts can collaborate for video streaming in a pure P2P manner
to provide better QoE. They used the capability of the SDN controller to
provide timely information about leaving or joining peers. Additionally, the
proposed method involves the SDN controller calculating the E2E bandwidth and
latency between potential candidate peers and the requesting peer. The
calculated values are subsequently communicated back to the requesting peers,
enabling them to select the optimal peer to retrieve the video segment.
However, the proposed systems only rely on overlay networks’ bandwidth and
storage capacities to serve clients’ requests. In other words, the
computational resources that can be leveraged to perform various video
processing functionalities at edge servers or P2P networks (e.g., video
transcoding) are not taken into account in such systems.

As a summary, Fig. 2.8 depicts the research gaps in the literature that the
technical chapters of this dissertation address. Moreover, in Table 2.1, we
outline an analysis of the important state-of-the-art works, with a focus on
their streaming type (i.e., VoD or live), networking paradigms, deployed
functions on edge, P2P, and/or CDN nodes, and the environment in which their
evaluations took place. We also show that they are either formulated via an
optimization model and/or solved by heuristic or learning-based methods. In
this table, $\times$ means that a particular related paper does not include
any information about the specific aspect.

Fig. 2.8: Research gaps in the literature. Table 2.1: Overview of related approaches; HE := Heuristic; ML := Machine Learning; OL := Online Learning; RL := Reinforcement Learning; TR := Transcoding; SR := Super-resolution. Paper(s) | Streaming Type | Networking Paradigm(s) | CDN Function(s) | MEC Function(s) | Peer Function(s) | Optimization | Heuristic | Evaluation
---|---|---|---|---|---|---|---|---
Wang et al. (2020a) | Live | CDN,NFV | Caching, RL Agent | $\times$ | $\times$ | $\times$ | RL | Real Testbed
Baccour et al. (2020) | $\times$ | MEC,P2P | $\times$ | Caching, TR | Caching | $\checkmark$ | HE | Python
Bayhan et al. (2020) | $\times$ | MEC | $\times$ | Caching | $\times$ | $\checkmark$ | HE | Python
Bentaleb et al. (2016) | VoD | SDN | $\times$ | $\times$ | $\times$ | $\checkmark$ | HE | 50 Nodes
Bhat et al. (2017) | $\times$ | SDN,CDN | Caching | $\times$ | $\times$ | $\times$ | $\times$ | Real Testbed
Bhat et al. (2018) | $\times$ | SDN,CDN | Caching | $\times$ | $\times$ | $\times$ | HE | Real Testbed
Borcoci et al. (2010) | $\times$ | NFV,CDN | Caching | $\times$ | $\times$ | $\times$ | $\times$ | $\times$
El Marai et al. (2017) | $\times$ | CDN | Caching | $\times$ | $\times$ | $\times$ | HE | NS-3
Erfanian et al. (2020) | Live | SDN,NFV,MEC | Caching | $\times$ | $\times$ | $\checkmark$ | $\times$ | Mininet-WiFi
Ge et al. (2017) | VoD | NFV,MEC | $\times$ | Caching | $\times$ | $\times$ | HE | Real Testbed
Ge et al. (2018) | Live | NFV,MEC | $\times$ | Caching | $\times$ | $\times$ | HE | Real Testbed
Ha et al. (2017) | Live | P2P,CDN | Caching | $\times$ | Caching | $\times$ | HE | 10 Nodes
Jmal et al. (2017) | $\times$ | CCN | $\times$ | $\times$ | $\times$ | $\times$ | HE | ndnSIM
Kalan (2021); Kalan and Sayit (2021); Kalan et al. (2019) | $\times$ | SDN,CDN | Caching | $\times$ | $\times$ | $\times$ | HE | Mininet
Kleinrouweler et al. (2016) | $\times$ | SDN | $\times$ | $\times$ | $\times$ | $\times$ | HE | 4 Nodes
Kumar et al. (2022) | $\times$ | SDN,P2P,CDN | Caching | $\times$ | Caching | $\times$ | HE | Mininet
Liotou et al. (2018) | $\times$ | SDN,MEC | $\times$ | $\times$ | $\times$ | $\checkmark$ | HE | ViennaSim
Ma et al. (2021) | Live | P2P,CDN | Caching | $\times$ | Caching | $\times$ | ML | Trace-Driven
Mehrabi et al. (2018) | $\times$ | MEC | $\times$ | $\times$ | Caching | $\checkmark$ | HE | SimuLTE
Mukerjee et al. (2015) | Live | CDN,SDN | Caching | $\times$ | $\times$ | $\times$ | HE | 10 Nodes
Nacakli and Tekalp (2020) | Live | SDN,MEC,P2P,CDN | Caching | $\times$ | Caching | $\times$ | HE | Mininet
Ozcelik and Ersoy (2019) | VoD | SDN | $\times$ | $\times$ | $\times$ | $\times$ | HE | Mininet
Tran and Pompili (2018) | $\times$ | MEC | $\times$ | Caching, TR | $\times$ | $\checkmark$ | HE | Numerical
Xie et al. (2008) | $\times$ | P2P | $\times$ | $\times$ | Caching | $\checkmark$ | HE | PlanetLab
Yin et al. (2009) | Live | P2P,CDN | Caching | $\times$ | Caching | $\times$ | HE | Real Testbed
Yousef et al. (2020) | $\times$ | P2N,CDN | Caching | $\times$ | Caching, Prefetching | $\times$ | HE | Matlab
Zhang et al. (2021) | $\times$ | MEC | $\times$ | Caching, SR | $\times$ | $\checkmark$ | HE | 3 Nodes
ES-HAS Farahani et al. (2021b) | VoD | SDN, NFV, MEC, CDN | Caching | Caching | $\times$ | $\checkmark$ | $\times$ | Real Testbed
CSDN Farahani et al. (2021a) | Live, VoD | SDN, NFV, MEC, CDN | Caching | Caching, TR | $\times$ | $\checkmark$ | $\times$ | Real Testbed
SARENA Farahani et al. (2023b) | Live, VoD | SDN, NFV, SFC, MEC, CDN | Caching | Caching, TR | $\times$ | $\checkmark$ | HE | Real Testbed
LEADER Farahani et al. (2022d) | Live, VoD | SDN, NFV, MEC, CDN | Caching | Caching, TR | $\times$ | $\checkmark$ | HE | Real Testbed
ARARAT Farahani et al. (2022c) | Live, VoD | SDN, NFV, MEC, CDN | Caching | Caching, TR | $\times$ | $\checkmark$ | HE | Real Testbed
RICHTER Farahani et al. (2022a) | Live | MEC, NFV, P2P, CDN | Caching | Caching, TR | Caching, TR | $\checkmark$ | OL | Real Testbed
ALIVE Farahani et al. (2023c) | Live | MEC, NFV, P2P, CDN | Caching | Caching, TR | Caching, TR, SR | $\checkmark$ | HE | Real Testbed

##  Chapter 3 Edge- and SDN-Assisted Frameworks for HAS

This chapter leverages the SDN and NFV paradigms to propose two edge- and SDN-
assisted frameworks for HTTP adaptive video streaming, named ES-HAS and CSDN
(ES-HAS extended by the transcoding capability), designed particularly for VoD
and live streaming, respectively. We introduce VNF components called Virtual
Reverse Proxies (VRPs) at the edge of single domain SDN-based networks. These
systems (via the SDN controller) provide VRPs with information on network
conditions and available video sources (cache servers). In addition, VRPs
collect clients’ requests for video segments and aggregate them in time slots.
Using this information, VRPs run optimization models as server/segment
selection policies to help clients get their requested segment quality levels
from cache servers with the shortest fetching time or receive from cache
servers better replacement quality levels with minimum deviation from the
original requested quality levels or, in CSDN, use transcoding functions to
transcode qualities from a higher available quality level. We implement the
proposed frameworks and their modules on a cloud-based large-scale testbed and
conduct various experiments in different scenarios. We also evaluate the MILP
models’ behavior and compare the results with other state-of-the-art
approaches. Experimental results demonstrate that, on average, ES-HAS and CSDN
outperform their competitors in terms of common QoE and network KPIs.
The first contribution, i.e., “ES-HAS: An Edge- and SDN-Assisted Framework for
HTTP Adaptive Video Streaming” was presented at the 31st Workshop on Network
and Operating Systems Support for Digital Audio and Video (NOSSDAV) Farahani
et al. (2021b). The second one, i.e., “CSDN: CDN-Aware QoE Optimization in
SDN-Assisted HTTP Adaptive Video Streaming”, was presented at the 46th
Conference on Local Computer Networks (LCN) Farahani et al. (2021a).

###  3.1 ES-HAS Framework

This section presents the details of the ES-HAS framework Farahani et al.
(2021b), which adopts and extends the core idea of SABR Bhat et al. (2018) to
introduce an edge- and SDN-assisted solution for HAS clients. Section 3.1.1
motivates the ES-HAS method through an example before elaborating on the
details of the proposed architecture and optimization model in Section 3.1.2.
The ES-HAS evaluation setup and results are discussed in Section 3.1.3.

####  3.1.1 ES-HAS Motivating Example and Problem Statement

We present our main motivation by means of the following example. Concerning
the components involved in the example, we refer to the ES-HAS architecture
depicted in Fig. 3.2 and the fact that ES-HAS adopts and extends the core idea
of the SABR framework Bhat et al. (2018). We consider a simplistic scenario
with only one cache server, an SDN controller, several OpenFlow (OF) switches,
one virtual reverse proxy (VRP) server, and two clients. We assume clients
request their next video segments in an SABR-enabled system Bhat et al. (2018)
(Fig. 3.1(a)) and an ES-HAS system (Fig. 3.1(b)). As illustrated, the SDN
controller should initially receive cache map messages from cache servers
(step $1$). Each cache map indicates the presence of representations (quality
levels) of requested video segments. The structure of a cache map is
illustrated in Fig. 3.2. Whenever an OF CDN-side switch cannot find a matching
rule for ($1$), it sends a packet-in message ($2$) through the OF protocol to
the SDN controller. The SDN controller replies to the packet-in ($3$) and
installs a path for the cache server. Finally, the cache map will be received
by the SDN controller ($4$).

Fig. 3.1: Exchanged messages in (a) SABR and (b) ES-HAS.

In an SABR-based system (Fig. 3.1(a)), the clients send requests ($5$) to the
SDN controller for acquiring cache map and network status information. An OF
client-side switch uses OF packet-in messages ($6$) for these non-matching
HTTP requests. After obtaining the replies ($7$), the OF switch forwards these
requests to the SDN controller ($8$). Assuming that the clients support SABR,
after receiving the requested information from the SDN controller ($9$), they
determine a joint cache map, including all cache servers for the requested
segments. The desired segments are requested by the clients ($10-11$). Then,
the SDN controller installs the corresponding routes between the clients and
the determined cache servers ($12-13$). Consequently, the requested segments
($14$) are transferred to the clients ($15$). It is clear that when the number
of DASH clients increases, the number of exchanged messages to/from the SDN
controller (via OF and HTTP) will increase proportionally. Hence, system
efficiency will decrease gradually.

Our proposed framework employs a VRP at the edge of the network to overcome
the aforementioned problem. A VRP works in time slots as follows. As shown in
Fig. 3.1(b), the clients send requests ($5$) to the VRP for the desired
segments’ qualities, and the VRP collects these received requests in each time
slot. The VRP plays the role of a gateway for the client to the network and
vice versa. Therefore, the VRP requests the cache map and network status
information from the SDN controller for all collected requests ($6-10$). Using
aggregate messages in these steps decreases the number of exchanged messages
to/from the SDN controller (via OF and HTTP) as compared to SABR. After
receiving the demanded information from the SDN controller ($10$), the VRP
runs an optimization program to determine the optimal cache servers for the
gathered clients’ requests. For the sake of simplicity, let us assume that the
requested segment quality levels are available on the cache servers. Then they
are requested from the cache servers and transmitted to the VRP ($11-16$). A
second reduction of exchanged messages (as compared to SABR) may occur in this
stage since the VRP does not forward identical requests by clients redundantly
to the SDN controller and cache servers. Finally, the fetched segments are
transferred to the clients ($17$). The details of the ES-HAS framework will be
discussed in the next sections.

The number of communicated messages to/from the SDN controller for both
systems (Fig. 3.1) is shown in Table 3.1. In real scenarios with a large video
dataset, this amount of exchanged messages could overload the SDN controller
in an SABR-enabled system. In our proposed structure, we introduce VRPs at the
edge of the system for collecting client-side requests, which increases costs
and imposes additional delay to the system. However, the number of messages
to/from the SDN controller, the load on the SDN controller, and the network
bandwidth consumption are significantly reduced. With an increased number of
clients, we can enlarge the VRP’s resources or, alternatively, add another VRP
to manage more clients efficiently.

Table 3.1: Number of messages to/from SDN controller. Arch. | Number of $\ldots$ OF msgs. |  $\ldots$ HTTP msgs.
---|---|---
SABR | $2N_{cache}+5N_{client}$ | $N_{cache}+2N_{client}$
ES-HAS | $2N_{cache}+2N_{VRP}+3N_{cache}N_{VRP}$ | $N_{cache}+2N_{VRP}$
Fig. 3.2: Proposed ES-HAS architecture.

####  3.1.2 ES-HAS System Design

In this section, we first present the ES-HAS architecture and its main
components and then explain the ES-HAS problem formulation.

#####  3.1.2.1 ES-HAS Architecture

ES-HAS includes three main layers: (i) Application/Control, (ii) Network Core,
and (iii) Network Edge (Fig. 3.2). On the application/control layer, the SDN
controller periodically monitors available bandwidth and the cache servers’
occupancy information (cache maps) and stores them in its database. Thus, we
define a Monitoring Module (MoM) as the controller’s main application module
to collect the aforementioned information from the OpenFlow switches.
Therefore, the database in the controller has accurate information about cache
servers and paths’ available bandwidths and serves the VRPs’ requests through
the Controller-to-VRP Interface. The network core layer consists of the
OpenFlow switches connected to the SDN controller, CDN components, including
an origin server, and multiple cache servers. In the network edge layer, we
employ several VRPs, which are equipped with three main modules as follows:
(i) Request Analyzer Module (RAM), (ii) Service Optimizer Module (SOM), and
(iii) VRP-to-Controller Interface.

Before describing the modules, it is noted that VRPs operate in time slots
with an equal duration of $\theta$. As shown in Fig. 3.3, each time slot
consists of two intervals: (i) Data Collecting and (ii) Optimization interval.
In the first interval, users’ requests are gathered and aggregated by a VRP’s
RAM. To prevent sending identical requests (issued by multiple clients in a
given time slot), RAM identifies them and considers only one request per
segment. Moreover, using RESTful messages, the VRP periodically retrieves the
required information (cache maps plus available bandwidths between each cache
server and the VRP) from the SDN controller and stores them in its DB. Then,
during the first interval, the VRP can fetch them from its database. The SOM
is executed by the VRP in the second interval to serve clients’ requests
optimally.

Fig. 3.3: Proposed time slot structure.

Note that, according to the SOM’s results, the data transmission will start in
the first interval of the next time slot. Actually, for each request, using
the optimization model presented later in this section, the SOM selects an
appropriate cache server that hosts the requested quality. However, when the
requested quality is not available in a cache server, the SOM either
determines an optimal replacement quality level on a cache or fetches the
originally requested quality from the origin server.

In this work, we employ the concept that a replacement quality may be
delivered to the client rather than the requested quality level of a segment,
based on Consumer Technology Association’s Common Media Client Data (CMCD)
standard Consumer Technology Association (2020). This standard defines the
information that a media player can communicate to (within media object
requests) and have processed and considered by CDNs. One piece of information
is the “requested maximum throughput that the client considers sufficient for
delivery of a content asset”. In our system, we interpret this as conveying
the information that a client will accept potential replacement (but only
better) quality levels in lieu of the actually requested quality of a segment,
up to a certain limit set by the client. For the sake of simplification, we
assume that each DASH client can request just one segment during each time
slot. However, it is possible to consider multiple requests from each client
in each time slot without fundamental changes in the proposed model. Note that
we will discuss how to determine the time slot duration in Section 3.1.3.2.

Table 3.2: ES-HAS Notation. Input Parameters |  |  |  |
---|---|---|---|---
| $\mathcal{S}$
---
$\mathcal{C}$
$\mathcal{A}$
$a^{c,s}_{q}$
$v^{c,s}_{q}$
$\mathcal{R}$
$R_{s}$
$i_{c}$
$m$
$\mathcal{K}_{c}$
$\delta^{c}_{q}$
$\pi^{c}_{q}$
$\theta$
| Set of cache servers and origin server, $s\in\mathcal{S}$
---
Set of clients, $c\in\mathcal{C}$
Set of available qualities in $\mathcal{S}$
$a^{c,s}_{q}=1$ if quality $q$ requested by client $c$ is available in server
$s$, $a^{c,s}_{q}=0$ otherwise
$v^{c,s}_{q}=1$ if the requested quality $q$ is available in any cache server,
$v^{c,s}_{q}=0$ otherwise
Set of available bandwidth values
Available bandwidth between VRP and server $s$
Quality level requested by client $c$
Integer number to limit the range of potential replacement quality levels for
$i_{c}$
Set of eligible quality levels for a quality requested by client $c$, where
$\mathcal{K}_{c}=\\{i_{c},{i_{c}}+1,...,min[{i_{c}}+m,q_{max}]\\}$
Size of the segment of quality level $q$ delivered to client $c$
Bitrate of the quality level $q\in\mathcal{K}_{c}$
Time slot duration
|  |  |
Variables |  |  |  |
| $B^{c,s}_{q}$
---
$T^{c,s}_{q}$
$F_{c}$
$Q_{c}$
|  $B^{c,s}_{q}$=1 if quality $q$ requested by $c$ is served from server $s$
---
Required time to fetch quality $q$ for client $c$ from server $s$
Deviation of quality level to serve client $c$ w.r.t. $i_{c}$
Selected quality bitrate to serve client $c$
|  |  |

#####  3.1.2.2 ES-HAS Optimization Problem Formulation

Let set $\mathcal{A}$ denote the cache map (i.e., availability of
segments/bitrates) that a VRP receives from the SDN controller, where
$a^{c,s}_{q}=1$ means that the quality level $q$ requested by client
$c\in\mathcal{C}$ is available on the server $s\in\mathcal{S}$ (see Table 3.2
for notations). Moreover, let a VRP’s database host set $\mathcal{R}$
containing available bandwidth values between the cache servers and the VRP.
In the SOM module, we introduce a mixed-integer linear programming model
(MILP) which tries to minimize the segment fetching time if the requested
segment quality is available in at least one cache server; otherwise, for each
non-cached segment quality, it determines whether to serve the client’s
request by a replacement quality from a cache server or by the original
requested quality from the origin server. The proposed MILP model finds the
optimal solution by minimizing the fetching time and the segments’ quality
level deviations while maximizing the selected quality bitrates. We derive the
following constraints that must be satisfied to achieve an optimal solution.

Let us define $i_{c}$ as the quality level requested by client
$c\in\mathcal{C}$. We also define
$\mathcal{K}_{c}=\\{i_{c},{i_{c}}+1,...,min[{i_{c}}+m,q^{c}_{max}]\\}$ as the
set of eligible (potentially, replacement) quality levels for the segment
requested by client $c$, where $m$ and $q^{c}_{max}$ denote the maximum
deviation from $i_{c}$ and the maximum quality level of the segment requested
by $c$, respectively. In each optimization interval, we select only one server
to serve client $c$. For this purpose, we introduce binary variable
$B^{c,s}_{q}$, where $B^{c,s}_{q}=1$ indicates that quality level $q$ must be
served to client $c$ by cache server $s$. As mentioned earlier, if $i_{c}$ is
available in any cache server, we should force the model to select one cache
server to serve the client’s request in the original quality by setting the
following constraint:

$\displaystyle\sum_{s\in\mathcal{S}\setminus
Origin}B^{c,s}_{q}~{}.~{}{a}^{c,s}_{q}=v^{c,s}_{q},$ $\displaystyle\forall
c\in\mathcal{C},q=i_{c}$ (3.1)

where $v^{c,s}_{q}=1$ if the requested quality $q=i_{c}$ is available in any
cache server; otherwise $v^{c,s}_{q}=0$. In the case of a cache miss, i.e.,
when $i_{c}$ is unavailable in any cache server, the VRP can fetch it from the
origin server or use other quality levels available in cache servers. Thus,
the following constraint must be satisfied:

$\displaystyle\sum_{s\in\mathcal{S}}\sum_{q\in\mathcal{K}_{c}}B^{c,s}_{q}~{}.~{}{a}^{c,s}_{q}=1,$
$\displaystyle\hskip 11.38092pt\forall c\in\mathcal{C}$ (3.2)

The required time to fetch the quality $q$ for client $c$ from server $s$,
denoted by $T^{c,s}_{q}$, is determined by the following constraint:

$\displaystyle\delta^{c}_{q}~{}.~{}B^{c,s}_{q}\leq T^{c,s}_{q}~{}.~{}R_{s},$
$\displaystyle\forall c\in\mathcal{C},q\in\mathcal{K}_{c},s\in\mathcal{S}$
(3.3)

where $\delta^{c}_{q}$ is the size of the quality $q$ requested by client $c$
and $R_{s}$ is the available bandwidth between the VRP and cache server $s$.
We define $Q_{c}$ as the selected quality bitrate to serve client
$c\in\mathcal{C}$ according to the following constraint:

$\displaystyle\sum_{s\in\mathcal{S}}\sum_{q\in\mathcal{K}_{c}}B^{c,s}_{q}~{}.~{}\pi^{c}_{q}\geq
Q_{c}$ $\displaystyle\forall c\in\mathcal{C}$ (3.4)

where $\pi^{c}_{q}$ is the bitrate of the selected quality level $q$ for
serving client $c$. To determine the quality deviation when the requested
quality $i_{c}$ is not available in $\mathcal{K}_{c}$ and a replacement
quality has to be found, we introduce the following constraint:

$\displaystyle\sum_{s\in\mathcal{S}}\sum_{q\in\mathcal{\mathcal{missing}}{K}_{c}}|i_{c}-(B^{c,s}_{q}~{}.~{}q)|\leq
F_{c}$ $\displaystyle\forall c\in\mathcal{C}$ (3.5)

Finally, the proposed model is formulated as follows:

Minimize $\displaystyle\hskip
8.5359pt\alpha_{1}\sum_{c\in\mathcal{C}}\sum_{s\in\mathcal{S}}\sum_{q\in\mathcal{K}_{c}}\frac{T^{c,s}_{q}}{T^{*}}+\sum_{c\in\mathcal{C}}(\alpha_{2}\frac{F_{c}}{F^{*}}-\alpha_{3}\frac{Q_{c}}{Q^{*}})$
(3.6) $\displaystyle s.t.$ $\displaystyle\hskip
14.22636pt\text{Constraints}\hskip
14.22636pt(\ref{ESHAS:eq:0})-(\ref{ESHAS:eq:4})$ $\displaystyle vars.$
$\displaystyle\hskip 14.22636ptT^{c,s}_{q},F_{c},Q_{c}\geq
0,B^{c,s}_{q}\in\\{0,1\\}$

where $T^{*}$, $F^{*}$, and $Q^{*}$ are the maximum values for the fetching
time, the quality level deviation, and the quality bitrate for client $c$,
respectively. The SOM runs the above model for all clients’ requested
qualities in a time-slotted manner to minimize the fetching time and quality
level deviations as well as to maximize the qualities delivered to the
clients. Furthermore, in the objective function (3.6), we set priorities for
$T^{c,s}_{q}\text{, }F_{c}\text{, and }Q_{c}$ by adjusting the wightings
$\alpha_{1}$, $\alpha_{2}$, and $\alpha_{3}$, respectively. The weighting
values are tuned empirically by considering the network conditions or
application policies. Section 3.1.3.2 discusses the impact of these weighting
coefficients on the model’s objectives.

####  3.1.3 ES-HAS Performance Evaluation

In this section, we evaluate the performance of ES-HAS compared to SABR Bhat
et al. (2017) and pure client-based approaches.

#####  3.1.3.1 Evaluation Setup

Our testbed consists of 72 nodes running Ubuntu 18.04 LTS inside Xen virtual
machines. The proposed network topology is built in the CloudLab Ricci et al.
(2014) environment. As shown in Fig. 3.4, it includes five OpenFlow (OF)
switches, 60 AStream DASH players Juluri et al. (2015); AStream (2020), two
VRP servers with the modules described in Section 3.1.2. Moreover, we employ
four cache servers and one extra server that jointly hosts an origin server
and a dockerized SDN controller. The bandwidth values in different paths
between each VRP and the cache servers are set to 100, 80, 60, and 40 Mbps,
respectively, which explicitly gives higher priority to download segments from
the local cache servers. Cache servers I and IV are local cache servers for
client groups I and II, respectively, with 100 Mbps bandwidth. The bandwidth
values to the origin server are set to 20 Mbps for both VRP servers. Apache
Apache (2020) and MongoDB MongoDB (2020) with supporting RESTful APIs for
cache map exchange are installed on all cache servers.

Moreover, the Least Recently Used (LRU) is considered in all cache servers as
the cache replacement policy. The policy on a cache miss is that the requested
quality will be fetched from the origin server only to the related local cache
server, i.e., cache server I for client group I and cache server IV for client
group II. Floodlight Floodlight (2020) is used as an SDN controller. Among
other tasks, it monitors the network to find paths’ available bandwidth (in
one-second intervals) and thus assigns paths with the highest available
bandwidth between a VRP server and each cache server. For the sake of
simplicity, we assume that all clients have already joined the network. Ten
test video sequences Lederer et al. (2012) with 300 seconds durations are used
in our experiments. These video sequences comprise two-second segments in five
representations (89k, 0.262M, 0.791M, 2.4M, 4.2Mbps). 60% of the video
sequences’ segments are stored in each cache server randomly. All clients run
simultaneously in all scenarios. Each client requests one video where
$video_{1}$ is streamed to clients (1,11,21,31,41,51), $video_{2}$ is streamed
to clients (2,12,22,32,42,52), and so on.

Fig. 3.4: ES-HAS evaluation testbed.

The time slot duration is set to 52 milliseconds in all experiments. (We will
discuss how to obtain the time slot duration in the next subsection.) Two
different ABR algorithms, BOLA Spiteri et al. (2016) and SQUAD Wang et al.
(2016), representing buffer-based and hybrid approaches, are used in all
experiments. Python and the PuLP library PuLP (2020) are employed to implement
and solve the proposed MILP model.

#####  3.1.3.2 Evaluation Results

One of the critical parameters for analyzing the performance of ES-HAS is the
time slot duration. In the adaptation process, the client’s ABR algorithm
estimates the network’s bandwidth by measuring the time between sending the
request to download a segment and having received the segment’s last packet.
An additional delay in the request-response interval (due to an overly long
time slot duration in the VRP) may convey an incorrect network situation to
the client; consequently, the client may request a lower quality level for the
next segment. Hence, in the first experiment, we investigate various time slot
durations for various segment durations in order to find suitable values of
$\theta$. For each segment duration of 2, 4, and 6 seconds, we start the
experiment with the initial value of $\theta=10$ ms and gradually increase it
in each run. The results show that for time slot durations longer than 52, 95,
and 200 ms for 2, 4, and 6 sec. segments, respectively, clients start to
request lower quality levels. We conclude that these values are the maximum
time slot durations without any negative effect on the clients’ adaptation
behavior.

In the second experiment, we numerically investigate the scalability of the
proposed MILP model execution. As illustrated in Fig. 3.3, each time slot
includes data collecting and optimization intervals. In the worst case,
requests arriving at the beginning of the optimization interval should wait to
be processed in the next optimization interval. In other words, a request
could possibly wait for two optimization intervals plus a collection interval.
To avoid optimization interval overlapping, in this study, we assume the
optimization interval should be less than or equal to $\frac{\theta}{2}$.
Therefore, based on the first experiment, this value should be less than 26,
47, and 100 milliseconds for 2, 4, and 6 sec. segments, respectively.

Fig. 3.5: ES-HAS MILP model execution time for different numbers of segment