5G and 6G networks are expected to support various novel emerging adaptive video streaming services (e.g., live, VoD, immersive media, and online gaming) with versatile Quality of Experience (QoE) requirements such as high bitrate, low latency, and sufficient reliability. It is widely agreed that these requirements can be satisfied by adopting emerging networking paradigms like Software-Defined Networking (SDN), Network Function Virtualization (NFV), and edge computing. Previous studies have leveraged these paradigms to present network-assisted video streaming frameworks, but mostly in isolation without devising chains of Virtualized Network Functions (VNFs) that consider the QoE requirements of various types of Multimedia Services (MS). To bridge the aforementioned gaps, we first introduce a set of multimedia VNFs at the edge of an SDN-enabled network, form diverse Service Function Chains (SFCs) based on the QoE requirements of different MS services. We then propose SARENA, an SFC-enabled ArchitectuRe for adaptive VidEo StreamiNg Applications. Next, we formulate the problem as a central scheduling optimization model executed at the SDN controller. We also present a lightweight heuristic solution consisting of two phases that run on the SDN controller and edge servers to alleviate the time complexity of the optimization model in large-scale scenarios. Finally, we design a large-scale cloud-based testbed, including 250 HTTP Adaptive Streaming (HAS) players requesting two popular MS applications (i.e., live and VoD), conduct various experiments, and compare its effectiveness with baseline systems. Experimental results illustrate that SARENA outperforms baseline schemes in terms of users’ QoE by at least 39.6%, latency by 29.3%, and network utilization by 30% in both MS services.

1. SARENA: SFC-Enabled Architecture for Adaptive Video
Streaming Applications
International Conference on Communications (ICC)
May 29th
, 2023
reza.farahani@aau.at | https://www.rezafarahani.me
Reza Farahani, Abdelhak Bentaleb , Christian Timmerer, Mohammad Shojafar, Radu Prodan, and Hermann Hellwagner

2. Agenda
● Introduction
● Proposed Solution
○ SARENA Architecture
○ Optimization Model
○ Heuristic Approach
● Performance Evaluation
○ Setup
○ Methods/Metrics
○ Results
● Conclusion and Future Work

3. Introduction

4. HTTP Adaptive Streaming (HAS)
1
https://bitmovin.com/dynamic-adaptive-streaming-http-mpeg-dash/
● Video streaming traffic has become the primary type of traffic over the Internet.
○ It includes 53.72% of the total video traffic over the Internet [1]
○ HAS is one of the prominent technologies that delivers more than 51% of video streams [1]
○ Live video streaming has become significantly popular, i.e., 17% of the total video traffic by 2022 [1]
[1] Sandvine, “The Global Internet Phenamena Report,” White Paper, January 2023. [Online]. Available: https://www.sandvine.com/global-internet-phenomena-report-2023

5. Video Streaming Challenges
2
● OTT video
● Live video streaming
● Immersive multimedia
● Video Gaming
● Video analytics for security,
quality assurance, etc.
Increase in amount of video
generated and transported

6. Video Streaming Challenges
2
● OTT video
● Live video streaming
● Immersive multimedia
● Video Gaming
● Video analytics for security,
quality assurance, etc.
Increase in amount of video
generated and transported
Versatile QoE, QoS requirements
Resolution (4K, 8K)
Latency (LL,ULL)
Bitrate

7. Video Streaming Challenges
2
● OTT video
● Live video streaming
● Immersive multimedia
● Video Gaming
● Video analytics for security,
quality assurance, etc.
Increase in amount of video
generated and transported
versatile QoE, QoS requirements
Resolution (4K, 8K)
Latency (LL,ULL)
Bitrate

8. Motivation

9. 3
Research Questions
✔ How to leverage modern networking/computing paradigms to serve different MSs requests
with acceptable QoE and improved network utilization?
✔ How to design a network-assisted HAS scheme without client-side modification ?
✔ How we can implement and evaluate proposed approach in a large-scale testbed?
SDN
S
F
C
HAS
E
d
g
e

10. Content Delivery Network (CDN)
4

11. Edge Computing
5
The SPEC-RG Reference Architecture for the Edge Continuum.
Jansen, Matthijs, Auday Al-Dulaimy, Alessandro V. Papadopoulos, Animesh Trivedi, and Alexandru Iosup.

12. Service Function Chaining (SFC)
6
VNF i VNF i+1 VNF n
VNF i VNF i+1 VNF n
SFC Chains
Chain 1
Chain m
…
…
.
.
.

13. Service Function Chaining (SFC)
6
VNF i VNF i+1 VNF n
VNF i VNF i+1 VNF n
SFC Chains
Chain 1
Chain m
…
…
.
.
.
Orchestration
Placement
Scheduling
SFC
Definition
VNF
Definition

14. ✔ Traditional network architecture:
◆ Complex Network Devices
◆ Management Overhead
◆ Limited Scalability
Software-Defined Networks (SDN)
7
Data Plane
Control Plane

15. ✔ Conventional network architecture:
◆ Complex Network Devices
◆ Management Overhead
◆ Limited Scalability
✔ The control plane (forwarding decision) is decoupled from
the data plane (acts on the forwarding decision):
◆ Centralized Network Controller
◆ Standard communication Interface (OpenFlow)
◆ Programmable Open APIs
7
Source: https://opennetworking.org/sdn-definition/
Data Plane
Control Plane
Software-Defined Networks (SDN)

16. Proposed Solution

17. SARENA Architecture
8

18. SARENA Architecture
8
Virtual Proxy Function
Virtual Cache Function
Virtual Transcoding Function
1
2
3
Multimedia
VNFs

19. SARENA Architecture
8
Virtual Proxy Function
Virtual Cache Function
Virtual Transcoding Function
CDN Cache
Origin Cache
1
2
3
4
5
Multimedia
VNFs

20. 3
SARENA Architecture
8
1
2
5
Multimedia
SFCs
1
2
4
1
1
4
1 3

21. 9
✔ The Requests Scheduler run an MILP optimization model to respond:
◆ Which SFC chain should be selected for each MS request to minimize the total serving time?
Optimization Model

22. Minimize total MSs serving times (i.e., fetching time plus transcoding time)
✔ chain Selection constraint
✔ Latency Calculation constraints
✔ Service Policy constraints
✔ Resource Utilization constraints
10
✔ Constraints :
✔ Objective :
Central Optimization Model

23. 11
✔ The proposed MILP model is NP-hard and suffers from high time complexity
✔ Divide tasks between Edge and the SDN controller
Heuristic Solution
Virtual Scheduler Function
Stats/Requests Collector (SRC)
Requests Scheduler (RES) Interval

24. 12
Edge Server Heuristic Algorithm

25. 13
SDN Controller Heuristic Algorithm

26. Performance Evaluation

27. ✔ Large-scale cloud-based testbed, including 280 elements and real backbone topology
○ Xen virtual machines
○ 250 Dash player
○ Four Apache cache servers and an origin server
○ 19 backbone switches and 45 layer-2 links
○ Five edge server
○ Floodlight SDN controller
○ BOLA ABR algorithms
○ FFmpeg transcoders
○ LRU cache replacement policy
○ Zipf distribution is used for video and channel access popularity
Evaluation Setup
14

28. Evaluation Setup
15
0.089
320
480
720
1080
1080
0.262
0.791
2.4
4.2
Resolution (p) Bitrate (Mbps) Bitrate (Mbps)
Resolution (p)
20
VoDs,
300
sec.
duration,
4
sec.
segments
320
480
720
720
1080
1080
1080
0.128
0.320
0.780
1.4
2.4
3.3
3.9
5
live
ch,
300
sec.
duration,
2
sec.
segments

29. ✔ Baseline systems:
◆ CDN-assisted (CDA)
◆ Non VNF-assisted (NVA)
◆ Non VTF-enabled (NTE)
◆ Non Reconfiguration-enabled (NRE)
✔ The performance of the aforementioned approaches is evaluated through
◆ ASB: Average Segment Bitrate
◆ AQS: Average Number of Quality Switches
◆ ANS: Average Number of Stalls
◆ ASD: Average Stall Duration
◆ APQ: Average Perceived QoE calculated by ITU-T P.1203 mode 0
◆ ASL: overall time for serving
◆ NCV: Network Cost Value
◆ ETR: Edge/P2P Transcoding Ratio
◆ BTL: Backhaul Traffic Load
Evaluation Methods/Metrics
16

30. Evaluation Results
17

31. Evaluation Results
18

32. Conclusion and Future Work

33. ✔ Use the cooperation of SDN, SFC, and edge computing to serve efficiently various
types of MSs with different QoE requirements.
✔ The experimental results over a large-scale testbed show:
○ users’ QoE by at least 39.6%,
○ latency by 29.3%
○ network utilization by 30%.
✔ Propose RL-based approaches and design FaaS-enabled solutions are our future
directions.
Conclusion and Future Work
19

34. Thank you for your attention
reza.farahani@aau.at | https://www.rezafarahani.me
All rights reserved. ©2020
34