Tuesday 26 April 2011

New transport protocols for a better user experience

In the 1980s the telecom industry decided they needed a “broadband standards” and started defining some protocols under the project name “Asynchronous Transfer Mode”. Today people know ATM for something completely different because the project, which actually led to significant deployment in the telecom gears of various countries, came to a stop because of a competing technology called Internet Protocol.
A decade later IP, that did not require an access speed of 155 Mbit/s like ATM, started being deployed with a bitrate that on average did not even reach 3 orders of magnitude less the ATM’s. IP seemed to provide the level of speed that could make customers happy keeping the Plain Old Telephone System (POTS) in place while ATM required reaching millions of subscribers homes with optical fibers.

No one can blame telcos for trying to save trillions of dollars of optical fibers for the less costly Asymmetric Digital Subscriber Line (ADSL). The reality, though, is that our society is more and more video dependent but the fixed telecommunication infrastructure cannot provide the bandwidth that its users require. A lot of talk is being made these days around the “Next Generation Network” (NGN) acronym and, in due time, something is bound to come out, but very little prospects exist for the mobile network which is squeezed between a terrestrial broadcasting industry that sticks to its Ultra High Frequency (UHF) legacy while the need to carry video on mobile networks multiplies by the day.

Video is a strange beast. From time to time I regularly receive the question: How many bit/s are required to transmit video? My regular answer is: as many as you want, even no bits at all. I agree that some may see this answer as non-collaborative, but it contains a profound truth, namely that video is a really flexible beast because you can decide how many bit/s you use to transmit video. No matter how few bits you use, your correspondent will always see “something”.

Operators have exploited this feature to cope with the wide dynamics of networks characteristics. If transmitter is informed that receiver is unable to receive all the bits that it needs to decode a video, it can switch to a version of the video encoded at a lower bitrate. The user at the receiving side will see a less crisp picture and he may complain about the shortsightedness of telcos that did not invest in ATM (if they had done it, what would the phone bill be today?), but that is still better than a picture that keeps on freezing.

The problem is that operators has independently decided to use their own transmitter-receiver protocols. This was acceptable at a time when video was a past time of few, but it is no longer a solution today when video is so pervasive.

MPEG has spotted this problem and is close to releasing a new standard called DASH. The acronyms stands for Dynamic Adaptive Streaming over HTTP and is almost self-explanatory. The pervasive HyperText Transport Protocol is used to stream video but the bitrate used is dynamically adapted to network conditions using a standard protocol that any implementer can use to build interoperable solutions.

See a technical explanation at http://mpeg.chiariglione.org/technologies/mpeg-b/mpb-dash/index.htm

Leonardo Chiariglione