InterDigital claims a new model is needed to handle growing video traffic
Video has crushed the Internet. In 2014, video represented 64% of all consumer Internet traffic, and that will grow to between 80% and 90% by 2019. The pain is especially severe in mobile networks: mobile network traffic is expected to see 57% compound annual growth per year through 2019, with an ever increasing proportion of it concentrated in video delivery. All my statistics are based on the 2015 Cisco Visual Networking Index, but they all point to the same thing: for fixed operators like cable companies, the pain is intense; for mobile operators, the pain will be astronomical.
The primary cause of the pain is mobile video is being delivered using a technology, and via a network architecture, designed with general data in mind. Video takes this paradigm and subjects it to a triple attack: a rapid increase in the data needs of the application through increased picture quality, multiplied by increased user adoption, multiplied by increased per-user demand. Solving the problem requires a look at the basic architecture and an examination of how both ends of the equation – the supply side and the demand side – can be reconfigured without harming the user experience.
When video was first transmitted over the Internet, it was all about Internet protocol television offerings. IPTV was a multicast model, slotting programs according to guides, at fixed times to whomever would tune in for the stream. You couldn’t customize it – choose to stream a video on demand – but it was very efficient, driving a single stream to multitudes of viewers.
Now, the IPTV offerings are being replaced with personalized viewing experiences. A user goes to their account, picks the video they like and starts playing it. This is an inefficient approach, which increases the cost of transmitting the video in linear proportion to the number of viewers. The market term for this is called HTTP level streaming, or HLS, a unicast model that has become the main way of providing these services. For a single piece of content it’s a great approach. But take popular, high-demand content: if one million people request an episode of “Breaking Bad,” it has to be sent one million times through the network … and that is the expensive part.
The coming of “5G” will resolve a variety of network issues, but in video it will only make the situation worse. Barring wholesale changes to approach, 5G will take the current linear dependency and impose even stricter performance requirements. For example, “service-level latency” of five milliseconds eliminates any potential waiting time. In other words, we have to add yet another demand multiplier to the file size, users and per-user demand equation: latency. Not a huge issue for content on demand, but insurmountable for image-driven applications like augmented and virtual reality.
I’ll conclude my first of two articles examining mobile video with an analogy. In the early days of aviation, plane races were the rage, with engineers taking early designs and simply increasing engine size and reducing drag with calling into question any basic principles. The approach reached its ridiculous zenith with the Gee Bee Model R – planes that were essentially overpowered propeller-driven engines with small winglets attached. Of the three built – one using the post-crash parts of the other two – all three crashed, killing two pilots.
What was needed was a rethinking of the problem. Within 15 years, a new approach would more than double speeds and break the sound barrier. In video delivery, meeting the demands of the future will also require more than a turbocharging of the current approach.
Editor’s Note: In an attempt to broaden our interaction with our readers we have created this Reader Forum for those with something meaningful to say to the wireless industry. We want to keep this as open as possible, but we maintain some editorial control to keep it free of commercials or attacks. Please send along submissions for this section to our editors at: dmeyer@rcrwireless.com.
