With the majority of cellular traffic today being video, managing that bandwidth efficiently can both save considerable CAPEX investment and deliver a better quality of service to users. It’s better to stream at a consistent slower data rate than stuttering. Youtube, Google and Nokia propose a technical solution through IETF rather than 3GPP to address the issue.
The majority of cellular data traffic is video
Cisco report 55% of total mobile data is video and Ericsson forecast this will grow to 70% by 2020. Smartphone penetration continues to grow worldwide, with 72% of the US population owning a smartphone (end 2015), against only 4% in Ethiopia. APAC countries are catching up very quickly.
Free video offers, such as T-Mobile USA’s Binge-On, increase demand. Their network traffic has tripled since 2013, even though the service restricts data rates and offloads to Wi-Fi where possible.
Large scale video services already adapt to available data speeds
Much of this video is served from a few massively scaled sites, such as Google’s Youtube, Facebook and Netflix. These often use dedicated Apps on mobile devices which can automatically sense and adapt the data rate being achieved, downscaling to a lower data rate automatically in poor conditions.
Traffic shaping and caching is commonly used to manage traffic flows at the central network level, with some transcoding being used to reduce data volume (e.g. not sending large screen HD video to a small smartphone device).
But much of this video traffic is delivered over TCP and HTTPS, internet protocols which have been around for decades. TCP in particular wasn’t designed to cope with the highly variable speeds and delays in today’s wireless networks. A short glitch can cause it to back off and revert to much slower speeds and smaller unacknowledged packet window than before, taking a long time to recover.
A consortium tackle the problem
Youtube, Nokia and Vodafone worked together to develop and test a solution for the problem. They investigated the benefits of exposing network-level capacity information at the end-to-end transport layer, coming up with the concept of Mobile Content Delivery Optimisation based on Throughput Guidance.
Their approach was based on adding information into the TCP packet headers, informing the smartphone what throughput it might expect. Although this data is inserted by the basestation, which could be a small cell, it doesn’t affect any of the cellular protocols or information streams.
So rather than taking this to 3GPP, which standardises cellular systems, they submitted it to the IETF which handles IP and internet protocols. You can read their submission, which clearly argues their reasoning and method, here.
This slide deck submitted to IETF last year graphically illustrates the problem and solution.
Some key benefits
The solution has some very attractive benefits:
- - It works for both unencrypted (HTTP) and encrypted (HTTPS) streams. All YouTube and Facebook is encrypted by default these days, with many more sites adopting that policy.
- - It’s designed to be secure, with protection to avoid spoofing of this data and disinformation spread about actual capacity.
Network level metrics show an average improvement of 30 to 60%:
- - Reduction of end-to-end TCP round trip time 55-70%
- - TCP retransmissions reduced by 30-45%
- - Mean Client Throughput improved by 20-35%
- - TCP packet loss reduced by 35-50%
End user experience improvements were reported to be:
- - Click to play time reduced by 5 to 20%
- - Average video resolution improvement 5-20%
- - Improved battery life
It all sounds too good to be true.
Clearly, with video comprising such a high (and growing) proportion of data traffic, if even just the few large sites support this (and maybe watching video in the popular web browsers), then it could have a significant impact on overall network cost and performance.
Vendor specific implementation
Any small (or large) cell vendor could implement this feature by inserting the TCP packet header into data streams in their basestations. It doesn’t have to be network wide and perhaps has most benefit in congested areas – giving it more relevance for small cells. It doesn’t have to be implemented by all vendors within a network either – so can be a differentiating feature for a few.
It could be used for both 3G and LTE, and potentially even for Wi-Fi (although an access point might have more difficulty predicting the available network capacity). I'd expect the initial focus to be for LTE simply because that's where the majority of traffic is today.
Whether and how quickly this will be adopted by other vendors and video services remains to be seen.