Content Delivery Network: Beyond the Internet

Mohan Tambe, Managing Director, Innomedia

Internet has carved out the cyber roads connecting each home and office
across the world. The roads were primarily meant for text and low resolution
multimedia objects to travel. Today videos requiring higher bandwidths are
threatening to block the roads altogether. Incremental changes in terms of
widening the road will not help as the web servers themselves become choking
points. There is critical need for augmenting the Internet with a purpose built
“Content Delivery Network” - one which will not get suffocated with users
accessing HDTV quality videos simultaneously. A new layer called HDTV Internet
will emerge over the existing Internet. The ubiquitous HDTV will finally connect
each home in the world.

The Content Delivery Network (CDN) apart from the basic qualities of Internet
itself has to go much beyond it. It has to be decentralized and made
indefinitely scalable. However, unlike the Internet, it has to provide a
limitless capacity for delivering HDTV quality content in the last-mile and an
uncompromisable security for contents. It has to have an inbuilt accounting
mechanism for usage of each content by users, permitting billing and revenue
distribution to the content providers. It should facilitate videos to be sent
between devices, using mobile like IDs, which don't change even during roaming.
In contrast to Internet, the CDN contents will be cached in head-end servers
connecting users through their last-mile networks. Each “Universal Content” will
be a distributed content, allowing immediate access through a last-mile, high
bandwidth network. A “Universal Content Locator” (UCL), will be used to refer to
each of these Universal Contents. The interactive CDNs can be over networks such
as Ethernet, ADSL, PON, Cable Modem, WiFi, or WiMax and Broadcast CDNs can be
over mediums such as cable, satellite or terrestrial, with a weak return path
(they can be also over general Internet). Interoperable CDN (iCDN) will be the
key towards allowing interoperable STBs(Set Top Box) to access universal
contents through any head-end and indeed through multiple head-ends
simultaneously. The interoperability will ensure that the servers in an iCDN can
fetch the contents from each other in a Peer-to-Peer (P2P) basis. Many last-mile
networks, such as that of Ethernet and Wi-Fi, can allow iSTBs to fetch Universal
contents from each other on a P2P basis. P2P networks have the beautiful
scalability property, which enables better content delivery with increasing
number of iSTBs. The encrypted contents can only be viewed by the certified
iSTBs, when they are provided by the iCDN, with a content key for decrypting the
content. Each iSTB will also maintain an encrypted usage log, which records each
usage of the universal contents. This then will be made use of by the iCDN to
generate the billing information. The iCDN will guarantee accounting of each
universal content, such that the content owner and other ecology partners can
earn through each usage of content. Unlike the Internet, the iCDN, right from
the beginning, will be a thriving regulated market place with users being able
to access the best of the universal contents and paying for it on a library or
rental basis — this will obviate the need for buying.

iCDN Ecology players

Like the Internet, the iCDN ecology has to be self-sustaining and positively
scalable. Exponential growth would come with joining of each new ecology
partner. This is possible with each ecology partner playing a dedicated role and
complementing each other to cater to the needs of the iSTB users worldwide. As
in the case of the global Internet, there would be a need for a national level
control too. This would be of even more importance for the iCDN as regulator of
each country would like the universal content to abide by their censorship and
copyright policies and their charging norms.

Content and Channel Aggregators play a key global role in the ecology. An
iSTB will be generally connected to one or more head-end servers, which can
provide high bandwidth connection to it. Revenue Distributor (iRD) is the key
ecology partner in a country, for smooth functioning of the iCDN eco-system. iRD
is primarily a bank, appointed by the Regulator of the country to ensure proper
and timely sharing of revenues between the eco-partners.

Uncompromisable Security for the iSTB

The security requirements of an iSTB are guaranteed not by the manufacturer or
the middle-ware provider, but the “iSTB Chip Manufacturer”. The iSTB Chip
Manufacturer has to provide a “Content Protection Module” (iCPM), which will
work along with the hardware to ensure that on-the-fly decryption of contents
can happen with the content keys. The content keys being themselves decrypted
using the internal private key of the iSTB. It is the responsibility of the iCPM
never to let out the contents or the keys in the clear. The iSTB security can
thus be considered, as if it is a part of the basic hardware, which cannot be
compromised by any manufacturer, middle-ware provider or even a hacker.

What Content Aggregators gain

A Content Aggregator can now really focus on building a robust collection of
contents which would be of interest to a wide section of the audience for times
to come. It's a case of one time investment and all time return — as each
content will generate some revenue with each usage. A Content Aggregator would
primarily concentrate on contents for specific language and genres. He would
increase the reach of the content, by having it subtitled in various languages
and by creating synopsis, trailers, preview books etc. He can promote his
contents, by putting hyper links for the same along with other related contents.
He will also make versions of each video content available in HD, SD and LD
resolution so that it can cater to a wide variety of display devices.

What Channel Aggregators gain

A Channel Aggregator can now reach out to a world-wide audience through the
head-end servers; no longer would he be geographically limited. The iCDN ecology
will provide him with many more revenue streams. The Channel Aggregator would
encrypt his channels and provide the keys in the same manner as the Content
Aggregator. He will though, for extra security, use a key-pair and change one of
the keys every 12 hours. The iSTBs will pre-fetch the key-pair every 12 hours,
to avoid delays during a channel change. The Channel Aggregator will also keep
an archive of all the keys, changed daily, from the beginning of his operation.
This is necessary as an iSTB will record the channel only in its encrypted form,
and will need the key for it when it has to play it back.

As in the case of the Content Aggregator, a Channel Aggregator can also
provide HD, SD, and LD versions of the channels.

What Content Service Providers gain

Content Service Provide is the most visible member of the iCDN ecology. Like a
Mobile Service Provider, he registers a new iSTB, and hand-holds with it
subsequently for authenticating it, accounting its usage and billing it on a
prepaid basis. It allows an iSTB to tap the iCDN services throughout the world,
on a roaming basis, from the head-end servers. It also fetches for it the keys
needed for decrypting the encrypted contents and channels, from the resepective
Content and Channel providers.

A Content Service Provider, uses a “Fees” file provided by the Revenue
Distributor of the country, for calculating the monthly billing of an iSTB based
on the usage. For international roaming, it will use the Fees file, as provided
by the Revenue Distributor of that country. It is required to deposit the
billing amount every month with the Revenue Distributor, so that the same can
then be distributed to other eco-partners.

Last mile benefits

The head-ends and last-mile costs for an IPTV network were prohibitive in the
past, compared to the ARPU which could be realized. Special purpose video
streaming servers were needed, whose cost depended on the number of users which
were simultaneously served.

The iCDN architecture eliminates all these limitations by reducing the cost
of an head-end by an order of magnitude. This is possible by deploying plenty of
vanilla PC servers with gigabyte Ethernet links, for serving contents and
channels to the iSTBs. Each PC server can have a bank of low-cost, terabyte SATA
drives. A head-end can start with a modest size, and can increase the servers
and storage according to increasing demands of users. The head-end can also push
caching servers nearer to users, to improve the performance. Head-ends can be
giving contents on “Demand” or can push them to iSTBs through “Broadcast”. A
Demand Head-end is connected to iSTBs through two-way broadband network and
sends the channels as one-way multicast. A Broadcast Head-end is connected to
iSTBs through a broadcast medium, with a weak return path, possibly over
Internet. A Demand head-end can serve the iSTBs over networks such as ADSL, PON,
Ethernet, Wi-Fi and WiMAX. A Broadcast head-end can serve the iSTBs over
broadcast mediums such as cable, satellite and terrestrial.

Broadcast head-ends would be generally optimized for delivering channels in
parallel to all iSTBs tuned to them. The broadcast channels can have occasional
errors, and are not suitable for delivering files with data integrity. This can,
however, be achieved by a few repeated broadcast of a data file, with the iSTB
doing error correction by comparing the repeated transmissions.

An error corrected content, through a broadcast channel, will be
indistinguishable from a content received through aDemand Head-end. Thus, a
Broadcast Head-end can also be used to deliver contents requested by iSTBs as
“Video-on-Request” contents. The broadcast Head-end will generally queue up
these contents and prioritize them based on the number of iSTBs who have
requested for the same.

It is possible for an iSTB to simultaneously download contents/channels from
multiple head-ends. It records the number of “Broadcast bytes” and “Demand
bytes” downloaded through each head-end, for determining how the revenue earned
through the Broadcast and Demand contents can be shared.

Revenue generated for Broadcast contents would come from the fees for Channel
Library, Pay Channels, Pay Programs and iVoting and the revenue generated for
Demand contents would come from the fees for Audio/Video Libraries, TSTV
Library, Pay Contents and Ad revenues.