One might think that given the general lack of interactive services available in most markets, there must be little in the way of a supply chain to support interactive media. Disregarding small-scale, regional pilots that are the exception, it’s a decent assumption. But if you look at a cable network at a high level, you see a potent content distribution network that will mainly require some added business and service intelligence to support IP and interactive services.
Broadband and digital cable take rates are increasing steadily, as cable operators put the final touches on their two-way upgrades and IP infrastructure deployment. What cable operators must implement next—and they have begun to do so—are IP service management capabilities. These include quality of service (QoS) schemes such as multi-protocol label switching (MPLS) and security mechanisms like IPSec, which are relatively proven and readily available from a range of vendors. Once the network protocols are in place, it will be time for the OSS and billing applications to do their jobs.
The Next Incremental Step
The last-mile cable network is a shared pipe that ultimately will be over-subscribed in a similar manner to how telephony networks are engineered. It makes the most economic sense, and it’s an inherent factor given cable networks’ tree-like structure. With an oversubscribed shared pipe, it becomes more necessary to be able to activate and track managed, individual sessions so that, for example, Web page downloads that can afford some delay won’t interfere with VoIP sessions that can’t.
Though network security and QoS mechanisms are being deployed, what’s missing is the ability to provision multiple IP connections dynamically, each with its own QoS designation. This will be necessary for supporting simultaneous sessions, each delivering different types of content. There will be plenty of “public” sessions or channels that handle general page loads and emails, but other services will require different and individual varieties of traffic handling.
A QoS designation, therefore, will have to be associated with the subscriber’s content request, or with the services invoked, so the proper type of connection can be provisioned to deliver the service. In addition, other network functions might need to be invoked dynamically, such as initiating a session initiation protocol (SIP) session for a voice-over-IP call (or voice over DSL, in a telco broadband environment). In other words, the network needs integrated, intelligent provisioning controls to make sure each service is handled and delivered appropriately.
Applying Today’s OSS Technology
When applying current OSS applications to a dynamic environment where services are introduced rapidly and self-provisioned, the greatest constraint may reside with the way product catalogs are usually configured. With current systems, products are stringently defined in the product catalog or database before being rolled out. In an interactive environment, services will come from more third-party providers, making automatic updates to product catalogs and related systems desirable. Ideally, any ordered service should have associated with it some kind of universal identifier that allows it to inform receiving systems of key characteristics, such as content format, required network protocol support, QoS requirements or billing settlement instructions.
Acknowledging product catalogs’ basic limitations, current OSSs can still provide some key interactive functionality if integrated properly. In the early days of interactive media, offerings will be mostly controlled. In other words, cable operators will dictate what services are made available initially and will roll them out at a measured pace. If that’s the case, then maintaining a product catalog will be relatively straightforward. The key is to adopt a data model that will include service-handling designations. If there’s integration among the product catalog, IP-layer provisioning and activation applications, customer data and billing systems, and the customer-facing ordering capabilities, it should be possible to create an interactive flow-through provisioning platform that accounts for requirements at each layer of the network and business.
A Potential Service Scenario
A basic transaction can provide a clearer view of some of the potential requirements for supporting interactive services. Imagine that a customer is watching interactive television and sees one of those flashy BMW commercials. During and for several minutes after the commercial runs, he has an option to click on a menu item that will take him to bmwfilms.com.
Imagine that he now has his television show running in the background, with a picture-in-picture window running a browser that takes him to the Web site. He hits the site, and two things need to happen. First, bmwfilms has its own Flash and QuickTime-based movie viewer it wants the customer to download in order to access the short films. The customer loves cars and techno-toys, so he has no objection to installing the viewer and the extra data it provides about a range of BMW automobiles—those featured in the short films. The viewer is a relatively large file, however, and can take some time to download. Further, the short films are about 70 Mbytes each, so they would also require some special handling.
Since it’s not streaming the content in this example, the operator wouldn’t need an extremely high level of bidirectional QoS. It would just need to assign some kind of intermediate QoS designation to ensure that the download happens fast and clean and doesn’t take more than a minute. Ideally, the operator wants its network to be able to go to the site, grab the file, compress it, and blast it down to the subscriber.
It’s possible the cable operator would already have an arrangement with bmwfilms as a content provider, and perhaps has the viewer and films stored and compressed on a local cache for simpler, managed delivery. The intermediate QoS designation would be defined for bmwfilms services in the product catalog. When the customer clicks to download the viewer or a film, several tasks are created for the OSSs in the background. First, the customer’s account profile needs to be checked to verify that he can access the content he’s requesting. Next, the product catalog and service resource store must report details to the provisioning and activation applications to determine who the customer is, what network segment and equipment is serving him, and what kind of QoS should be applied to the connection as defined in the product catalog. What also must be determined is what kind of rating is applied to the service, who is billed for the download, whether it is considered part of the user’s monthly service, and whether bmwfilms is paying the operator a premium to ensure each download request is handled with priority.
Billing for a Distributed, Open Environment
Collecting revenue brings us to the most important piece of infrastructure the interactive environment will need: settlements and billing. To provide true billing support—and for that matter provisioning—in an open service environment, we need to break away from fixed product definitions. Product catalogs can often be a nightmare to maintain in today’s environment, so the idea of trying to keep one of today’s systems constantly up to date in the future environment is a little scary.
It’s also unnecessary. If we think about the relationships among content creators and service providers, we’re trying to develop a sophisticated supply chain comprising managed connections on interconnected networks, and some kind of shared operations functionality. Cable operators shouldn’t need to spend resources to keep their databases current simply in order to provision and bill for a service that customers want. If new services are going to be introduced rapidly and from a wide range of sources, it’s critical that the industry agree on some means to either share service information or share billing or provisioning services.
What it means to share information or services in this context is easiest to grasp with respect to technology. A few companies are beginning to push Jini, a service discovery technology in the Java family that is intended to allow disparate systems on a network to share services transparently (See “Standards Watch,” Billing World and OSS Today, September 2001). Essentially what occurs in a Jini system is that Jini-enabled devices or applications register their accessible services to a public registry where other Jini clients can make calls or requests on those services. Jini devices or applications essentially can tell other systems who they are and what they can do.
This capability can apply to billing and provisioning in the interactive world in several ways. Let’s say the customer finds a new gaming environment he wants to enter, but there’s no relationship between the cable and gaming providers. To support the service properly, the operator needs to know what kind of connection the service requires. It also needs to know whether any special protocols should be provisioned on that connection, such as a concurrent SIP or H.323-based VoIP session adjacent to the gaming session so the players can talk to one another. It also must identify the network providers in between and determine how to settle the end-to-end transaction.
And it needs to know how to rate and bill for the service. Say the cable operator is trying to figure out whom to bill for this service. The gaming provider has to pay something for access to the cable operator’s audience. The network providers in between may have to be compensated, which could be the gaming provider’s responsibility; or the cable operator could take care of it and charge the gaming company for the settlement service. Finally, the customer must be billed for whatever resources are required to support his service.
Jini Could Do It
What Jini can provide are the information, rating and traffic-handling details. The gaming provider’s systems could announce to the network how its gaming traffic needs to be handled and what elements are involved that can be billed. Theoretically, in a distributed Jini environment, a Jini-capable billing and/or provisioning system wouldn’t need to know how to contact the gaming provider’s server; it would just need to send a request to invoke some Jini services, which could involve just retrieving rating instructions. Or the system could request that another system housing a product definition for the service in question actually rate the specific CDR and then send the billing data back to the requesting operator’s billing system.
This kind of scenario applies to provisioning as well. Given the link between provisioning and the network, it seems more likely that services will announce their provisioning requirements, rather than having a remote system try to provision to someone else’s network, which would be nearly impossible to implement or maintain. (For more information on Jini in interactive services, see “The Mobile Society,” TelOSSource, June 1999).
Jini makes obvious sense in the settlement environment as well, because it will require a deep level of information- and service-sharing among providers.
An added benefit is Jini’s inherent ability to adapt to failures. Because it’s entirely distributed and transparent, it can work around network or application failures. Theoretically, if a billing system were to crash, a Jini agent could invoke rating services from other networked billing systems as a contingency.
Initiatives such as OSS-J, which promotes Java applications in the OSS arena, are helping to steer the industry toward more open, data sharing-type technologies, like Jini, that will help break old habits that encrust the product definition/long product release cycle and the closed-door approaches to systems development. These ideas are also beginning to be presented to groups like CableLabs’ B2B project, which has a strong influence over cable networks and technologies. Many of the pieces needed to enable the interactive environment during the next five to 10 years are still missing. If everyone does
everything independently, the interactive media movement will never reach its lucrative potential. Moreover, a common, collaborative direction today will save billions in the long run. It will spread development costs across several industry segments and put the necessary accounting mechanisms to enable an interactive services platform that’s actually profitable.
Watching the Horizon
It would be foolish to build an OSS environment that ignores apparent future requirements. Operators are in a shifting, intermediate stage, so the goal is to aim for where the network will be when they are ready to focus on monetizing the network assets they’ve built. It’s also critical to consider what services might actually sell (videoconferencing on a Palm Pilot may not be the killer application) and how the network will deliver what sells. For example, as popular as video streaming is, right now it’s most suitable for things like news clips and sports highlights—things that people don’t need to pay more for just to ensure perfect quality. It’s not a big deal to most users if a streamed clip of a foreign correspondent’s report is a little choppy, so investing in the network capabilities to clean it up may not be the best use of resources.
But the ability to deliver other forms of video content over IP, somewhere between a clip and a feature film, is likely to be an important requirement. Building a capability to support such services would also subsume the requirements for less complex ones, like music on demand or application services.
Consider that most video content can be compressed, downloaded and extracted for viewing, as in the bmwfilms example. It’s unidirectional traffic, and getting a local disk cache in every subscriber’s home is an evolutionary matter of rolling out the right kind of set-top boxes or home gateways. Perhaps operators will add some security controls to content so that, for example, if a user wants to keep a downloaded video, he’ll pay a premium for that privilege. For example, Sony Pictures Entertainment, Warner Brothers, Universal Pictures, Paramount Pictures and Metro-Goldwyn-Mayer recently announced plans to pursue downloadable movie services, but targeted to the desktop PC and not the television. Regardless, it seems to make more sense to compress and ship one-way video than stream it, simply as a matter of optimizing bandwidth utilization. A shared pipe will only support so many simultaneous video streams.
Video Without Streaming?
High-quality video entertainment services that people will pay for will be based on the robust cable RF network’s quadrature amplitude modulation (QAM) scheme. Video on demand (VoD) has its own set of controls that will have to be integrated into the general back-office environment. But VoD isn’t IP-based, so it won’t face the quality issues inherent with IP. Services such as gaming, music, film shorts, and home networking-oriented applications will require session control, but that doesn’t apply to VoD.
If one denies that short films and gaming are going to be huge areas for service creation and innovation, consider some important catalysts. Distribution of digital video capability has decreased production costs, making high-quality video production available to more than just movie studios. Also, shorts represent a huge step forward for advertising, as bmwfilms is showing. Further, interactive DVDs that will turn music videos into interactive shopping malls—everything in the video is clickable and for sale—will hit the market soon.
An increasingly tech-savvy audience will have more access to simplified development tools and eventually will have more ability to create its own online, interactive content. It’s amazing what people will do when the tools and the bandwidth are available. Even back in 1994 students at the University of Michigan were developing network applications and playing enormous, multi-user games of Doom at all hours. What better way to deliver what customers want than to give them the tools to build it themselves?
Where Do You Want to Spend Your Money Today?
It’s in a service provider’s best interest to encourage such developments, because ultimately it will increase traffic on the network and provide premium, value-added services that someone else pays to develop. Subscribers don’t want to be limited by one-to-one, operator-to-content provider distribution relationships. They want access to anything that’s available on any server in the world, and the operator must be able to track their wanderings, manage their sessions, and collect revenue on both sides of the transaction. How open the future environment will really be, given that media empires control much of the cable industry, remains to be seen. But it seems logical to give customers freedom and let them pay a little extra for the privilege.
The key here is that with more interactive possibilities, the human attention span will likely become shorter, so the faster the system can respond to a customer’s impulse, the more revenue the operator will generate and the more satisfied the customer will be with the service. In fact, the one thing that could kill interactive TV before it takes off is poor or inconsistent service. If the service doesn’t enthrall and captivate users, they won’t spend the extra bucks for it every month.
Delivering a reliable, interactive environment that responds in real or near-real time, which users regard as desirable and not far-fetched, will first require deep integration among core OSSs and processes. Implementing and integrating a platform that can deliver real-time interactive media is probably a more daunting concern for operators than the question of whether the technology is available to make it work.
Edward J. Finegold leads Stylus Communications, an independent consultancy focusing on OSS and interactive media. He can be reached at ejfinegold@styluscom.com.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article