Bullpen: Implementing Multiplatform TV

Multiplatform TV is often called the three-screen video experience. However, the term multiplatform TV, or simply mpTV, is more comprehensive because it suggests, first and foremost, a television experience: To seamlessly provide television services to multiple devices by delivering content in multiple formats across multiple networks using multiple protocols.

Multiplatform TV is all about giving subscribers the freedom to watch television (in the broadest possible sense) on different screens (or devices). The important thing is not to throw away what is already excellent about the living room TV experience, but to extend that to the other devices in a natural and seamless way. Implemented correctly, mpTV enhances the subscriber experience and at the same time makes the service very sticky.

"Implementing mpTV as a seamless subscriber experience is best done using an open-systems approach."

There are aspects that the subscriber should not be asked to give up in face of this new convenience — for example, familiarity with the user interface, single point of billing, quality of service, linear services (especially live sports and news), and so on.

Possible use-cases

Suppose you are on a business trip, and in the evening you would like to catch up with an episode of your favorite HBO series. You log-in to your account from your laptop, using the hotel’s broadband connection, and as an HBO subscriber you already have access to their subscription on-demand service. You quickly find the episode you want using a search string. You start watching the episode. After a few minutes your wife calls. You "pause" the program, and, when you tell her what you are watching, she says that she would also like to see that episode, but couldn’t find it using the set-top guide. Now that the episode is saved in "my rentals," she can easily find the right episode. She can choose to resume playing from where you paused it, or watch it from the beginning of the show.

You are watching a live hockey game and it’s in the final period. However, you have arranged to meet a friend downtown in 30 minutes. You pause the game and drive to the light rail station a few minutes from your house. Once on the train, you can resume watching from where you left off using your iPhone. Since your iPhone application is linked to your cable account, the system automatically prompts you to resume a time-shifted session because you paused a live program on the set-top. The time-shifting is done in the network, so it doesn’t require any upstream bandwidth from your home. Given that you are now watching a unicast session, the system can target ads based on your demographic profile and your location, potentially alerting you to a nearby bar that has a happy hour.

Both of these examples feature session-shifting — moving from one device to another while maintaining continuity of the viewing experience. These examples have extended television from the TV to the laptop, to a smart-phone, or to any other multimedia, networked device. To achieve this, the delivery system must understand the state and context of what is being viewed on all devices on the subscriber account. These examples work well when the system is designed to anticipate the need and prompt the subscriber appropriately (according to pre-defined rules set by the operator).

How best to implement?

Implementing mpTV as a seamless subscriber experience is best done using an open-systems approach that links the various delivery systems together using a common back-office. This allows subscriber preferences, account profile, settings, and session state information to be stored and managed in a single system.

Operators already have a back-office that supports on-demand to the set-top. The challenge is extending it to provide a common control-plane for new devices. Using an open-systems approach makes each component interchangeable by carefully choosing its interfaces — keeping everything in the system constant except for the component that is swapped. This modularity has already been successfully incorporated into on-demand systems and has allowed operators to reap the benefits of rapid evolution of media servers without changing the service layer.

Now the same modularity allows an operator to change the type of media server; for example, from one that supports MPEG-2 transport streams to one that supports HTTP or RTMP.

Assets must be created and provisioned in multiple formats and then the appropriate format must be delivered according to the device type. There are a series of steps to do this for each asset:

1. The asset is received, typically i MPEG-2 format as an ADI (asset distribution interface) package.

2. The asset is transcoded into other formats and resolutions for the additional devices for which support is required. This will typically be MPEG-4 at various resolutions.

3. The asset is distributed to the various media servers, over satellite or terrestrial networks and placed into the on-demand catalog of available assets.

4. Catalogs are generated for each device type and delivered to the navigation client for each device in the appropriate format.

Since there are already tens of thousands of assets in many on-demand catalogs, these steps must be executed a great many times and require an automation system to effectively support multiplatform content management.

In addition, the back-office must be extended to support device-awareness. This starts with catalog generation (step 4 above), since only assets that can be consumed by a device should be offered to it. The next step is to ensure that when an asset is requested by a device, the correct one is played, from the appropriate media server over the correct network.

Although assets must be processed differently according to the device type they are destined for, many other functions are common across devices such as:

• Authentication. Each device must be authenticated before an asset can be delivered to it. This is done both to authenticate the subscriber and also to ensure that the device itself is registered and does not present a copy-protection threat.

• Purchasing and billing. Each purchase must be authorized against the subscriber’s account and billed accordingly.

• Advertising. Thanks to the stellar work from the SCTE Digital Video Subcommittee there is now a modular approach to advanced advertising with interfaces and architecture specified in the SCTE 130 standard. In addition, CableLabs is developing advanced advertising specifications to extend the scope to a common platform. There is nothing in these standards that limits the type of device, network, protocol, format, or conditional access system, so they can be directly applied to the mpTV case.

In summary, there are many advantages of using a common services layer to implement multiplatform TV. Some of these are most visible to the subscriber in creating a seamless, easy-to-use experience. Others allow the operator to maintain consistent operations across the various devices on the network.

Michael Adams is vice president, application software strategy, TANDBERG Television.