Sponsored By

Video Experience & Monetization: A Deep Dive Into Cisco's IP Video ApplicationsVideo Experience & Monetization: A Deep Dive Into Cisco's IP Video Applications

A look at Cisco's ability to deliver advanced IP applications Advertising insertion Session shifting Personalized content & user interface Web 2.0 integration & more

June 5, 2009

31 Min Read
Video Experience & Monetization: A Deep Dive Into Cisco's IP Video Applications

Editors Note: This report series documents the results of tests involving Cisco IP video infrastructure, demonstrations of its associated applications, and tests of its data center infrastructure. Earlier this year, following months of talks with Cisco Systems Inc. (Nasdaq: CSCO), Light Reading commissioned the European Advanced Networking Test Center AG (EANTC) to conduct an independent test of a premium network solution to facilitate advanced IP video services for service providers, enterprises, and broadcasters alike.

As discussed in the previous report in this series, Cisco has been marketing its ability to deliver multifaceted visual media over IP networks. (See Testing Cisco's IP Video Service Delivery Network.) These media-aware networks Cisco calls "medianets" encompass network elements such as Cisco’s 7600, ASR 9000, and CRS-1 routers, data center switches like the Nexus 7000 and 5000, and a set of associated services that deliver media applications.

This is the second of three reports covering Light Reading's and EANTC's massive test effort of several aspects of the Cisco's IP video end-to-end solution. The first report focused on the service delivery network. The final report, coming next week, will concentrate on the data center infrastructure. This report is dedicated to IP video applications, including the creation of a unique user experience and adding ways for service providers to make money on IP video services.

Building applications for IP video networks and delivering new services to consumer TVs is a software-centric business. Those aren't Cisco's roots, but it is an area where the company known for its switches and routers has spent billions in R&D and acquisitions in the past several years. (See Cisco's Latest Buy: Flippin' Sweet, Cisco Gains Presence With Jabber Purchase, Cisco Pays $120M for Pure Play, and Cisco to Acquire Scientific-Atlanta.)

In this study, EANTC and Light Reading independently confirmed that Cisco could demonstrate an ability to create advanced IP video applications for consumers and enterprises, including:

  • Advanced advertising insertion

  • Session shifting among the TV, mobile phones, and computers

  • A personalized user interface on the TV

  • Web 2.0 integration with the TV set

  • Adding user-generated content to an IPTV provider's traditional programming fare

For service providers looking to make money with subscriptions, transactions, revenue sharing, and advanced advertising on IP video networks, Cisco's foray into IP video applications will be of special interest. What's more, consumers will want to read about these demonstrated capabilities as well. They'll want to discover: What is Cisco showing it can do that their current pay TV providers lack?

Our methodology
Having already discussed our approach to testing in the previous report, it is important to note that we spent some time coming up with a methodology for validating the applications presented by Cisco. This wasn't a test, per se, so the challenge we faced was to make sure that the capabilities that Cisco wanted to demonstrate were truly supported and performed well. If testing a router, switch, firewall, deep packet inspection device, or entire network solution for performance and scalability values were the target of the test, our testing partner for this engagement, Spirent Communications, would be able to measure them.

Things were different for this exercise – we needed to verify that a specific feature simply existed.

We agreed to the following conditions:

  • EANTC would receive a live presentation with the complete solution, live devices, and TV screens at Cisco’s media-centric briefing center.

  • EANTC reserved the right to examine any part of the infrastructure, trial the applications ourselves, and disconnect any cable in the lab (and we did just that on more than one occasion). This enabled us to physically verify that the demo we were receiving was really running over the network.

  • EANTC used Wireshark to monitor the network and record the traffic flows presented on the demonstration screens. The Wireshark packet traces allowed us to see that the set-top boxes, for example, were sending the appropriate requests for multicast groups, requests for content on the Web, etc.

Once we agreed to the above we felt comfortable to independently explore Cisco’s IP video applications. Following is the hyperlinked table of contents for this report:

— Carsten Rossenhövel is Managing Director of the European Advanced Networking Test Center AG (EANTC) , an independent test lab in Berlin. EANTC offers vendor-neutral network test facilities for manufacturers, service providers, and enterprises. He heads EANTC's manufacturer testing, certification group, and interoperability test events. Carsten has over 15 years of experience in data networks and testing. His areas of expertise include Multiprotocol Label Switching (MPLS), Carrier Ethernet, Triple Play, and Mobile Backhaul.

— Jambi Ganbar is a Project Manager at EANTC. He is responsible for the execution of projects in the areas of Triple Play, Carrier Ethernet, Mobile Backhaul, and EANTC's interoperability events.Prior to EANTC, Jambi worked as a network engineer for MCI's vBNS and on the research staff of caida.org.

— Jonathan Morin is a Senior Test Engineer at EANTC, focusing both on proof-of-concept and interop test scenarios involving core and aggregation technologies. Jonathan previously worked for the UNH-IOL.

Next Page: A Man's Home Is His CAISL

The demonstrations described in this section were performed in a concept lab in one of Cisco’s many San Jose facilities. The lab, called CAISL (Cisco Advanced IPTV Systems Lab), is used for IP video executive demonstrations. It houses a complete network from video head-end to diverse access solutions such as cable and DSL. The lab is designed to impress executive-level folks with plush leather seats, a well stocked mini-bar (which we did not abuse), and three distinct areas: the network (hidden behind sound-dampening glass), the Network Operation Center (NOC) area, and the living room (with three TV sets).

The network in CAISL is constructed following best practices with full end-to-end resiliency – from the dual attached video grooming and multiplexing devices (which Cisco calls Digital Content Manager – DCM) through diversely routed aggregation, core, and distribution routers. We have already met a number of the network components in our Service Delivery Network tests, save for the data center and ASR 9010 pieces.

The complex nature of any IP video and any-play deployments was clearly visible in the lab. In the service area we were faced with a myriad of components, all filling different pieces in the IP video story:

  • Video encoders for high and standard definition (from Scientific Atlanta)

  • Video multiplexers

  • Network Time Protocol (NTP) server

  • Dynamic Host Configuration Protocol (DHCP) server

  • Operation Support Systems (OSS)

  • Network Management Systems (NMS) for Multicast

5674.jpgNext Page: IP Video Network Monitoring Tool

We often hear from service providers that they wish they had more comprehensive tools to monitor their IP video offerings. (See Getting the Signals Straight and IPTV in the USA.) Solutions are required that integrate the worlds of video quality monitoring on one hand, and packet transport network monitoring on the other. Troubleshooting is more cumbersome when one tool tells you that video quality is bad, and another (unrelated) tool tells you about transport network issues.

Now the challenge is for vendors to get out of their favored domains (like packet switching or video applications) and to understand the other side. The solution should also scale to tens or hundreds of thousands of customers, cover all types of video streams (broadcast and on-demand), and be integrated into the existing equipment so that deploying additional probes can be avoided.

There are three depth levels that come into play in the pool of IP video monitoring. The shallow water encompasses the simplistic view of the network as a collection of devices and their interfaces. Such monitoring tools provide information such as “interface has issues” or “switch has crashed.” In a network delivering video, such information should be translated by the NOC personnel into “Houston, we have a problem.” Still, in a fully redundant network, the NOC still needs tools to identify the level of impact such failure has on the end users and the transport of the video to said viewer.

Here comes into play the second pool issue: You can still stand, but the water is deep enough to swim. Monitoring quality indicators for networks delivering MPEG video or voice-over-IP applications is specified in an Internet Engineering Task Force (IETF) informational Request for Comments (RFC) document called “A proposed Media Delivery Index (MDI).” The RFC focuses on two network quality indicators – Delay Factor (DF) and Media Loss Rate (MLR).

Delay Factor specifies the maximum difference between the arrival of media streams and the specified "drain rate" – the rate at which the stream should arrive. DF measurements are useful to indicate potential congestion in the network that in turn forces the set-top box to buffer more video packets. The MLR value is much simpler. It indicates the number of packets lost or put in the wrong order over a set duration of time.

In the deep-water side of the pool we have a different set of swimmers all together – these monitor the actual viewer experience. Up until this area, all monitoring is done within the network, but at the end of the day, what operators care for, especially in these days of fierce competition and diverse service offerings, is what the user sees. Here a fairly large primer of information is available from an array of standard organizations such as the the International Telecommunication Union, Standardization Sector (ITU-T) , Alliance for Telecommunications Industry Solutions (ATIS) , and the Broadband Forum (specifically, TR-126).

The Cisco folk stated that they have analyzed their service provider customers’ requirements. As a result, Cisco brought its latest video monitoring solution to the test – Video Assurance Management Solution (VAMS). It is aimed at delivering centralized, real-time monitoring of core and aggregation networks for broadcast video transport. The system monitors IP multicast streams and is able to report on a number of multicast-related parameters relevant to the health of the IP video distribution system.

The strength of such a video quality monitoring system is to identify and solve problems before customers notice them. Service providers delivering IP video are challenged by their competition in most markets (the other service providers). But the service provider’s very own IP video customers are strict critics anyway – each of them is an expert in video quality, with a long experience in traditional cable, terrestrial, or satellite TV quality. [Ed. note: That's why they hire cinematographers to do quality assurance – See Video Quality.] For IP video services to be generally accepted and financially successful, the quality of the video experience cannot deviate from what the viewer is used to.

We put VAMS to the test: First by creating failure conditions in the network and seeing how the system reacts, and second, by assessing how useable and intuitive the solution is.

The VAMS interface is Web-based; we used Microsoft Internet Explorer running on a Windows XP client system. The interface is driven by the notion of a “Service Tree.” The services populating the service tree are, in essence, broadcast TV channels transported using IP Multicast – a channel per Multicast destination address. We had a total of 29 channels running in the network, hardly the typical service offering, but as a proof-of-concept we considered this acceptable. Some of our channels had two groups (for resiliency), and the system dealt with this grouping nicely – each per-channel tree could be expanded to show all multicast group addresses associated with the channel, and each one of the groups could be monitored.

The interface also offers a network view in which the different network elements are seen as well as their links. Green links and icon colors mark a healthy network; red-marked links and icons should sound the alarm with your NOC staff, while the yellow color indicates a non-fateful issue. In our test we simulated conditions to actually verify the transitions between these states.

We simulated a network failure between the video source and its gateway router. The IP video content in the network continued flowing as Cisco’s network implementation included two video sources (the head-end). We were not interested so much in the video at this point but rather in the visual information on the screen in front of us: Can the system identify the link failure; how soon before we will see an indication that the head-end is gone; and what other useful bits of information will VAMS deliver to us to enable our mock-NOC personnel (read: EANTC project manager) to diagnose the problem?

Shortly after the fiber disconnection, the system showed all channels marked as yellow. It was good news that something happened, and the reaction was also correct – we had another source for all channels apart from one that was also, not surprisingly, the only channel that showed red. At this point our NOC should be alarmed and on the phone calling the data center folks to go check out the status of the video head-end. We, however, wanted to be more proactive, so we clicked on the channel now marked with red and looked further into the specific alarm. The alarm provided us with a very logical explanation – “video probe media loss rate exceeds threshold” – and provided us with another clicking opportunity to launch Cisco’s Multicast Manager (CMM), another application that is part of VAMS, and trace the flow.

5675.jpg5676.jpgIn short, the functionality was there, and for features that were obviously customer driven. The system is simple enough at first glance to enable basic first-level support and to interact with it, and is also sophisticated enough to enable more detailed troubleshooting. Since the system uses Simple Network Management Protocol (SNMP) to collect its information, some delay is expected between the error condition and its announcement in the system. However, this is a system designed for human use, so a delay of a few seconds is not an issue.

Next Page: Web 2.0 Integration Over Cable & DSL

These days there is a marketing push for any set-top box (STB) attached to the television to also allow Internet access. And the trend of extending access to content isn't just a set-top story, either.

In a recent Heavy Reading survey of service providers, access to preferred content across devices and viewing environments was a recurring theme. One service provider noted: "An important driver here is the ability for a consumer to easily, simply move content from the PC to the TV, allowing for the video experience to be on the TV but sourced from the PC."

With that in mind, we aimed to understand the state of the art in this area: Has the Web-integrated set-top box already grown up? We sat down in the leather couches in Cisco’s demo lab and dug into the technology behind Cisco’s shiny big TV screens.

Using the STB’s (Cisco's IPN430MC) remote control we were able to navigate to Yahoo’s RSS news feed. Since we were also monitoring the uplink from the set-top box to the network at the same time, we actually recorded the "HTTP Get" requests for the Web content. This was no pre-canned static solution, but a live application that fetched its content from the Internet and displayed it on the screen. The application menu included, in addition to Yahoo News, Yahoo regional weather reports and Flickr, the photo-sharing site.

A fundamental difference exists between the Yahoo news or weather and the Flickr menu option. Yahoo applications are simply available on the Web, while Flickr requires a method to search for pictures or create an account. As the set-top box vendor would have a hard time anticipating any Internet applications potentially required all over the world, the set-top box needs to support an application programming interface (API) – the more versatile the better. Now, we would have loved to explore Cisco's API to program a live ticker of German Bundesliga, for instance, but we lacked the opportunity and time to play around with it in the demo lab.

5677.jpg5678.jpgInstead, we focused our questions on the Flickr application again. The challenge for all these TV applications is to be simple enough to be operated with a remote control. While adding a keyboard is not a technical problem – and Cisco showed us one available for the set-top box – it would destroy the idea of an easy, straightforward user interface. So how would we enter the Flickr account info? The trick is that it needs to be preconfigured in the set-top box installation process.

5679.jpgFor Web-savvy folks this might sound like a major limitation: Access to a single account? Pre-configured? But consider for a moment the target audience: It is not only the less Web-savvy folks anymore, but also more sophisticated computer users who do not want to grab the laptop and link it with the TV and connect the WLAN and log in and so on...

Cisco explained that the system is integrated into the presentation layer of the STB – the same layer in which the program guide appears. The system is driven by HTML and Java code and is essentially part of the software running in the STB. This means that the user can change the position of the RSS ticker, or the polling interval, for example. No need to call the service provider.The same demo ran over both the DSL and cable infrastructures in Cisco’s lab.

Next Page: Walled Garden Over Cable & DSL

After seeing the integration of pre-configured Web access into the set-top box, we had to ask: What about service providers that are not interested in allowing access to Web content directly from the set-top boxes?

Is there a similar solution for the "walled garden" telecoms of the world?

Cisco showed us a Walled Garden application from CloverLeaf Digital LLC called DotDaily, available as part of the set-top box software.

5680.jpg5681.jpgThe application, when chosen from the STB menu, offers localized content such as weather, news, and entertainment. The content is designed for the “10-foot” experience – the user does not sit in front of a computer, but in front of a large TV screen, 10 feet away. From our 10-foot view, the application felt more like a program guide with added bells and whistles than a Web browser. We supposed that this was the intended effect that Cisco was trying to reach.

We were able to click through various entertainment, weather, and local news pages, all appearing to be fast and responsive. The data presented to the viewer was much like what we saw from Yahoo, but centralized and screen-dominating. This was another application available on the TV: Watch TV; watch TV with Yahoo weather ticker; or read entertainment or local news. The upshot is that a viewer can receive information that is easily available on the Web, but without needing to know anything about computers: "Just turn on the TV, Mom."

This demo was conducted over both DSL and cable infrastructures in Cisco’s lab.

Next Page: Customizable User Interface Over Cable & DSL

Over the last decade, computer users have grown accustomed to being able to change the look and feel of the user interface on a given application or operating system. This customization process came about slowly: Winamp had skins then Windows XP; Mac users were able to change the color scheme of the graphical user interface (GUI); and these days everything from cellphones to Gmail is customizable. Why should the user interface on a set-top box be any different?

Cisco’s STB allowed us to choose between two TV skins – with the fancy names of “Cool Breeze” and “Dark Blue.” (We briefly considered taking a few beers from the fridge in Cisco’s demo lab and set up a naming contest.) The skins enable the user to customize the set-top user interface by changing the look and feel. The changes include background colors, font sizes, and the style and order of menus.

None of the details were user-configurable; the service provider would just prepare a few skins and offer them as monolithic choices, which is, after all, similar to what users have grown accustomed to seeing in Web portals. After we made the change (from “Dark Blue” to “Cool Breeze”) the STB required a reboot, which happened automatically and took about 60 seconds. We were also able to change our mind and go back to the original skin from which we started.

5682.jpg Although these two skins were not very exciting by themselves, they show the ability of the set-top box to modify the user interface, providing a number of different sets of colors, fonts, etc., to satisfy user preferences.

Where this can go is anyone's guess. Ringtones weren't very exciting, either, but consumers love the ability to change how their phone rings to something that speaks to their personal identity. And they happily pay for the privilege, too.

For service providers, having the options to add a perceived value to the consumer experience is always too big a deal to dismiss.

Next Page: User-Generated Content

Over-the-top (OTT) content is somewhat counterintuitive in a test bed validating service provider-supplied IP video services. OTT content refers to content delivered over the Internet, or via any means other than traditional managed IP video services. OTT includes YouTube or Hulu content – in this case, the service provider does not offer a service related to the content, but rather simply delivers the IP packets sourced by YouTube.

Triple-play service providers are in an ambivalent position in relation to OTT content. On one hand, it makes their customers happy to access all sorts of videos (the so-called “long tail”). On the other hand, OTT is not a revenue source, is not tied to a specific Internet service provider, and could consume a lot of bandwidth, which has led to service provider experiments with bandwidth caps and Internet metering. (See AT&T, TWC Fit Beaumont for Caps.)

Integrating OTT content into the triple-play infrastructure could be desired anyway, to increase the customer’s stickiness (because the competitive service does not offer OTT integration) and to benefit from the rich variety of video content otherwise not available in the walled garden scenario.

In this video interview, Heavy Reading's Adi Kishore does a masterful job of explaining service provider interest in OTT, and sizing up the Internet's role in pay TV:

{videoembed|174877}In this demonstration, we looked into Cisco’s solution for integrating Web video into the TV set and enabling the user to create virtual channels based on his or her own interests and preferences. This is an attractive idea: Choose from the video on demand (VoD) menu containing content that is actually streamed directly from the Internet.

5683.jpg Under the hood, Cisco’s set-top box is actually requesting a VoD stream from the content delivery system (CDS). Hence by the time the content is delivered to the set-top box, the format is ready to be enjoyed on the TV. Another benefit of "letting the CDS do the work" is the ability to use legacy STBs for this service. All the STB needs to do is request new VoD content – no extra knowledge about Web or video formats is required.

Upon entering the Cisco lab, one of Cisco’s engineers recorded a short video of our entrance using a Nokia E61 cellphone. The video was then uploaded from a PC to the CDS and was available as one of the OTT options as user-generated content (UGC).

The service provider must offer UGC as an option. The user then receives an account to which he or she uploads content, and the content appears on the on-demand menu. At a time in which YouTube content like Fred is getting a million subscribers, UGC is harder than ever to ignore. (See News Bits: Fred Gets 1M YouTube Subscribers.) It is the logical step for carriers to keep their customers in front of the TV by providing them with video content from the Web on the TV screen and allowing them to contribute their own content.

Next Page: Advanced Advertising

No media related story seems to be complete these days without a discussion about advertising. The industry has learned from Google’s AdWords that targeted advertising is a truly efficient way to advertise.

Indeed, as Cisco's John Morrow points out in the following video, the goal is to help service provider networks become just as effective at targeting ads to consumers as Internet is today:

{videoembed|174830}Telecom equipment makers the world over have embraced this view: Since service providers already have some level of demographic and geographic information about their residential subscribers, why not use this information to serve tailored ads? Depending on the service provider’s database, legislation, and the customer-base feelings about privacy, the amount of information can be anything from lean to very rich.

Cisco's demonstration of advanced advertising used a very small amount of information, just separating customer income groups by neighborhood. The demonstration included two TVs: one representing a mid-income household, the other high-income. We used each STB to choose a video from the VoD library and were shown two different ads before the movies actually started playing.

The benefits for service providers are obvious: Delivering personalized advertisements tailored to the customer’s unique needs makes for more effective advertising and therefore a new revenue stream to the service providers. Now, in addition to receiving VoD revenues from the consumer, the service provider could also be earning revenues by selling ads on a local, regional, or national level. After all, the information is there.

Cisco claims that the ad insertion system is built to Society of Cable Telecommunications Engineers (SCTE) standards, specifically SCTE130, which covers "Digital Program Insertion – Advertising Systems Interfaces." We did not have the opportunity to validate details of the implementation.

Next Page: Amazon Set-Top Box Integration

In this stage of the demonstration, we were redirected to watch another TV set. A video was started on the TV. As soon as we pressed the pause bottom on the remote control, a small window popped up asking if we would like to see items related to this video. When we clicked "yes" we were redirected to Amazon.com Inc. (Nasdaq: AMZN)'s Website.

Cisco explained that the Amazon plug-in was built using Cisco’s software development kit (SDK) that allows for rapid application development. Since we did not develop the Amazon plug-in ourselves, we could not comment on the speed of development – “rapid” is surely a subjective measurement.

We were, however, told that the application took only two months to develop and was built using the Amazon API. According to Cisco, Amazon is ready to work with service providers and pay a “finders fee,” if you will. That is, Amazon would pay service providers for bringing customers to its site. This is perhaps another step up the ladder for service providers to monetize on their IP video services.

5684.jpgIn addition, the fact that the system has an SDK that allows service providers to develop money-making applications means service providers could potentially come up with their own unique, additional revenue streams.

How about an iTunes store plug-in? That would be music to our ears.

Next Page: Session Shifting

Service providers are realizing that their business is moving toward delivering video on several different types of devices that connect to the same IP network. Heavy Reading's Adi Kishore makes that point quite clearly in this video clip:

{videoembed|175510}Indeed, video content, especially music videos, is slowly orienting itself towards mobile viewing. Directors, knowing that their video clips will be viewed on cellphones, are creating clips that are comfortably viewed on smaller devices – the picture is centered and the movement is sharp and bright. For a large image space, such as modern Plasma or LCD TVs, this means a lot of movement and the need for fast image refresh intervals. Imagine that you start watching a video on your cellphone. When you get home wouldn’t it be great if you could turn on the TV and continue watching from the exact point you paused before going into the car park?

The ability to shift video across three screens – TV, PC, and mobile – was the last in the series of hands-on demonstrations we received. It is also a capability Cisco has been showing publicly for more than a year. (See Cisco Tees Up Anga Demos.)

We started the demo by watching a film on TV. A few minutes into the film, we paused it and moved to a computer. We pointed the browser to our mock service provider site and were able to see the film waiting for us there paused at the same spot we left it on the TV. The same exercise was then repeated from the PC to a mobile (Nokia E61).

In all instances, the video was paused as expected by the last device on which it was viewed. Not only that, but since we are skeptical people (we doubt – that's what we do), we played around with the videos, stopping in several places, and on all three devices, the system still continued working.

This validated Cisco’s claim that they have a solution that allows content to follow the user across the three types of screen that dominate our lives. At this point, we were informed, the solution is not shipping.

Next Page: Multipoint Telepresence

So far, we have seen demonstrations that were focused on residential consumers, but IP video encompasses business applications as well – one of which is Cisco’s Telepresence solution.

Telepresence could be understood as a wide-area remote meeting application. Each participant in the meeting sits in front of one or three large screens with a camera and is able to talk to and watch other participants in the conference as if they were in the same room. Slides can be shared as well.

Cisco sells the solution as an appliance (a bundled, closed system). Compared to other solutions in the market, Cisco’s Telepresence avoids mixing video and audio streams in multipoint conferences, thus saving a lot of latency involved with the mixing. Also, Cisco focuses on high-definition video with high bandwidth requirements, although the software takes various steps to reduce the bandwidth and video quality when monitoring packet loss.

But where is the service provider in this scenario? Traditionally, large enterprises have installed video conference rooms themselves. Cisco explained that they envision the service provider taking a fair share of the video conferencing business, offering the service on top of a VPN solution. The conferencing rooms could be rented to enterprises case-by-case, or as a long-term loan. (We did not ask for the price of the solution.)

For this demonstration we left the IPTV lab and moved to a different Cisco lab focusing specifically on Cisco’s Telepresence solutions. Here we faced three screens; two attached to one domain (location) and one attached to another. The analogy in this setup is to two businesses or two offices belonging to the same business looking to arrange a video conference.

5685.jpgThe two businesses would use VoIP phones (as you suspect, provided by Cisco as well) to set up the Telepresence call. Both domains will register with a session border controller (SBC) sitting in the network, which in turn will set up the communications between the two domains without the domains having to learn about each other’s IP information.

After we established the call, we were curious: Since the user is sitting in front of a single screen on one end and two screens on the other end, how does the system know who is now talking and whose stream to display? The answer was somewhat unexpected – the decision is done by the special multipoint-switch, which decides based on whoever is the loudest.

Cisco says the multipoint Telepresence we were seeing was encrypted. Unfortunately, we could not verify that the conversation was really encrypted – that would have required capturing all the video and audio streams, inspecting and decoding them, and knowing the encryption keys and method. The only indication of encryption was a little display on the VoIP phone that showed a lock.

This demonstration seemed a bit of a fish out of water when compared with the other, more consumer-centric applications. But some form of advanced video conferencing will make its way into consumer homes when the bandwidth allows it and carrier business models can support it. Also, this demo served as a reminder that the network used to provide consumer IP video services can be the same one used to deliver services to small businesses as well. That's something service providers will, no doubt, consider as they look to drive more cost out of their networks.

Next Page: Conclusions

Carrier executives are concerned about one major question more than anything else: How do I monetize consumer video services by expanding the business model beyond simple pay TV subscriptions? Are transaction-based paid services, revenue sharing, and advertisement revenues possible today?

Service providers face a huge consumer demand for seamless IP video services across PC and TV screens and an enterprise demand for advanced video conferencing services. But the question is how to differentiate the video service? Lots of vendors are making claims, but do these advanced applications actually work?

In this report, EANTC and Light Reading independently confirmed that Cisco could demonstrate an ability to create advanced IP video applications for consumers and enterprises, including:

  • Advanced advertising insertion

  • Session shifting among TV, mobile phone, and computer

  • A personalized user interface on the TV

  • Web 2.0 integration with the TV set

  • Adding user-generated content to an IPTV provider's traditional programming fare

These applications, if deployed and scaled, present several ways for service providers to make money on IP video distribution, including:

  • Increased pay TV subscription revenues

  • Web commerce transactions

  • Revenue sharing between content and digital service providers

  • Advanced, targeted advertising revenues

All the solutions that we witnessed in Cisco’s demo labs worked on a functional, single-user base, as claimed by Cisco. A large fraction of the functionality was implemented in Cisco’s set-top boxes, but many other middleware and transport components were successfully linked into the application architecture.

The complexity of delivering a comprehensive IP video solution is mind-blowing. We counted more than 10 different boxes in the data center to deliver these functions.

As a result, we saw that the service provider does not need to rely on subscription-based (often flat rate) revenues anymore. Transaction-based revenues for VoD and, most importantly, advertisement-based revenues using targeted ad insertion and Amazon collaboration was demonstrated successfully.

Cisco’s solution takes care of individualized content as well, to increase the customer base stickiness. Since triple-play provider decisions are often taken by a number of family members together (as compared to broadband Internet plan decisions), differentiating the service from competitive offerings is important to reduce the customer’s likelihood of switching to another carrier even if the other one provides cheaper service. Over-the-top video integration, customizable "skins" for the programming guide, and user-generated content are examples of such competitive differentiators.

As more IP-based streaming video services are available on the TV, data requirements per household will increase, driving up the demand for network components. This aspect was covered in the previous report, which leaves us with the next aspect: the data center. Our final report in this series, coming next week, will take the data center to task.

— Carsten Rossenhövel is Managing Director of the European Advanced Networking Test Center AG (EANTC) , an independent test lab in Berlin. EANTC offers vendor-neutral network test facilities for manufacturers, service providers, and enterprises. He heads EANTC's manufacturer testing, certification group, and interoperability test events. Carsten has over 15 years of experience in data networks and testing. His areas of expertise include Multiprotocol Label Switching (MPLS), Carrier Ethernet, Triple Play, and Mobile Backhaul.

— Jambi Ganbar is a Project Manager at EANTC. He is responsible for the execution of projects in the areas of Triple Play, Carrier Ethernet, Mobile Backhaul, and EANTC's interoperability events.Prior to EANTC, Jambi worked as a network engineer for MCI's vBNS and on the research staff of caida.org.

— Jonathan Morin is a Senior Test Engineer at EANTC, focusing both on proof-of-concept and interop test scenarios involving core and aggregation technologies. Jonathan previously worked for the UNH-IOL.

Return to Introduction

Read more about:

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like