Advertisment

Content Delivery Network: Beyond the Internet

author-image
PCQ Bureau
New Update

Mohan Tambe, Managing Director, Innomedia

Advertisment

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.

Advertisment

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.

Advertisment

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.

Advertisment

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.

Advertisment

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.

Advertisment