Vodafone research on how Multi-access Edge Computing can enable better QoE in mobile video delivery. Presented and awarded at MEC Congress 2017, Berlin. In partnership with Saguna and Teragence.
5. “Just one buffering event decreases the amount of video watched by 39%” [MUX.com]
User behaviour
C1 – Vodafone External 5 12 October 2017
[H. Yeganeh et al., “Delivery quality score model for internet video”, ICIP 2014]
6. • Video service at MEC closer to users results in:
– Smaller and more predictable RTT
– Significant gain for users suffering from latency fat tails
– Powerful video delivery infrastructure cloud CDN (over-the-top) can’t go there
• MEC improves those KPIs:
– Time to start
– Number of stalls
– Waiting time (= sum of all stalls)
MEC for better video QoE: hypotheses
C1 – Vodafone External 6 12 October 2017
7. • Baseline RTT:
– UE – local video server 14 ms
– UE – AWS 26 ms
• HD video [03:12], 1080p (vp9 codec) forced (no DASH/ABR), TCP, 4G
• Local video server hosted in MEC site
Lab tests details
C1 – Vodafone External 7 12 October 2017
Small cell
MEC platform
Saguna vEdge
MEC location
RAN-side
congestion
EPC
Video server
on AWS
Local video
server
EPC location
EPC-side
backhaul
congestion
Co-location
Breakout
connectivity
8. Lab tests results: time to start
C1 – Vodafone External 8 12 October 2017
0
200
400
600
800
1000
1200
1400
0 10 20 30 40 50 60 70 80 90 100
ms
RTT to AWS in ms (increasing delay between MEC site and AWS)
HD1 video time to start with 0.4% packet loss
Local server (always at 14 ms RTT) AWS Linear (Local server (always at 14 ms RTT)) Linear (AWS)
Without MEC
With MEC
9. Lab test results: number of stalls
C1 – Vodafone External 9 12 October 2017
0
0.2
0.4
0.6
0.8
1
1.2
1.4
26 36 41 46 51 56 66 76 86
Averagenumberofstalls
RTT to AWS in ms (increasing delay between MEC site and AWS)
HD1 video stalls with 0.4% packet loss
AWS
Without MEC
With MEC = 0
10. Lab test results: waiting time
C1 – Vodafone External 10 12 October 2017
0
1000
2000
3000
4000
5000
6000
7000
0 10 20 30 40 50 60 70 80 90 100
ms
RTT to AWS in ms (increasing delay between MEC site and AWS)
HD1 video waiting time with 0.4% packet loss
Local server (always at 14 ms RTT) AWS Expon. (AWS)
Without MEC
With MEC
11. • Median RTT: 30-50 ms
• 80th percentile RTT: 50-60 ms
• Average packet loss: 0.4%
• More than 70000 samples
UK mobile networks: latency (RTT) and packet loss
C1 – Vodafone External 11 12 October 2017
0%
50%
100%
0-10
10-20
20-30
30-40
40-50
50-60
60-70
70-80
80-90
90-100
100-110
110-120
120-130
130-140
140-150
150-160
160-170
170-180
180-190
190-200
200-210
210-220
220-230
230-240
240-250
250+
ms
Latency (RTT), busy hour, all UK CDF
0%
50%
100%
0-10
10-20
20-30
30-40
40-50
50-60
60-70
70-80
80-90
90-100
100-110
110-120
120-130
130-140
140-150
150-160
160-170
170-180
180-190
190-200
200-210
210-220
220-230
230-240
240-250
250+
ms
Latency (RTT), busy hour, city CDF
• Crowdsourced measurement data provided by:
12. • Teragence’s crowdsourced data provided baseline field measurements
– Network testing embedded in 3rd party apps
– Large sample size (>100k real users across multiple UK MNOs)
• Location and time aware
• Main KPIs: latency, packet loss, jitter
• Teragence measurement tools deployed over lab network
– Latency and packet loss emulating field measurements
– No emulation of jitter therefore, lab conditions still less hostile than in live networks
• Lab tests show a realistic scenario somewhat optimistic
Normalisation of lab-based vs field-based measurements
C1 – Vodafone External 12 12 October 2017
13. Combined results
C1 – Vodafone External 13 12 October 2017
0
1000
2000
3000
4000
5000
6000
7000
0 10 20 30 40 50 60 70 80 90 100
ms
RTT to AWS in ms (increasing delay between MEC site and AWS)
HD1 video waiting time with 0.4% packet loss
Local server (always at 14 ms RTT) AWS Expon. (AWS)
Bad experience
for 20% of cases
Operating window
centered around
median RTT
clear gain
Without MEC
With MEC
14. Zoom on operating window
C1 – Vodafone External 14 12 October 2017
0
500
1000
1500
2000
2500
20 25 30 35 40 45 50 55 60
ms
RTT to AWS in ms (increasing delay between MEC site and AWS)
HD1 video waiting time with 0.4% packet loss (zoom 30-50)
Local server (always at 14 ms RTT) AWS Expon. (AWS)
Average RTT would be greater
than median
Suspect this will degrade
further when real-world jitter
is added
Without MEC
With MEC
15. • Videos fetched from the local MEC server start to play faster
• The more latency between the user and the video content, the worse the QoE
(higher number of video stalls - and hence, the larger total waiting time)
• Real world measurements from multiple UK lcations show a “fat tail” latency
distribution with RTT for 20% of cases in a range where lab results predict
considerable QoE degradation
• Congestion in the radio access network affects video QoE of remote content more
than it affects MEC-hosted content
• MEC significantly improves current poor QoE experienced by roughly 1 in 5 users
Conclusions
C1 – Vodafone External 15 12 October 2017
16. • Perfect baseline conditions: 0% packet loss, 14 ms to MEC site, 26 ms to AWS
What’s next? 4K
C1 – Vodafone External 16 12 October 2017
KPI MEC video server AWS
Time to start (ms) 1138 1258
Number of stalls 0 0
Initial buffering time (ms) 903 990
• Adding 0.4% packet loss
KPI MEC video server AWS
Time to start (ms) 1150 1811
Number of stalls 10 19
Waiting time (s) 64 269
17. • Lab constraints
– Jitter was not modelled yet further works is planned in order to understand its effect on the results
• MEC load/capacity
– Simulation of multiple devices in the same cell
• Real subjective QoE assessment
– To assess degradation beyond the simple used KPIs
• Different types of video
– To repeat the tests for all the most popular video codecs/formats
• Mobility
– To assess in-cell and handover mobility effects and compare them for MEC/non-MEC scenarios
• Deployment
– Compare “QoE gain” from MEC to conventionally located video server nodes (3rd party CDN, Operator CDN,
etc.)
Improvements and future work
C1 – Vodafone External 17 12 October 2017