In a wholesale market, buyers and sellers of on-demand TV services do business based on mutually beneficial market opportunities and a common technology framework - like this one. 

or your margins too low. And if you are a big player and can afford these costs, you will still want to add more customers to further lower your cost base, increase revenues, and raise profits. 

If you are a European telecom operator, you no longer need to own your own on-demand TV system in order to bring on-demand TV services to consumers. And if you already do sell on-demand TV, then you can sell those services to consumers who live outside your network. That's the result of European local loop unbundling (LLU) regulations. That's also good news for ISPs looking to video as a way to attract new subscribers.

That's where telecom LLU comes in. LLU opens the door to wholesaling and wholesaling opens the door to scale. Now ISPs without video services can buy from operators who do. Wholesaling lets operators share platform, content, and operational costs and increase volumes of set-top box purchases - all of which reduce costs per subscriber. Greater size also reduces the percent-age error of subscriber growth forecasts - which reduces set-top box inventory costs. 

 Broadband connectivity and discount phone service no longer have the market appeal they once did - and competition is fierce. Margins are dropping, churn rates are high and the cost of adding new subscribers continues to increase. ISPs need more subscribers just so they can attract more subscribers - by lowering the cost base. That's why ISPs want their on-demand TV - it's a much fresher value proposition - with something fresh to attract new subscribers every day.

There's just one problem: on-demand TV is expensive to build and operate. Only a handful of major operators can truly afford to create and run their own platforms. Adding to network costs is the cost of content acquisition (e.g., football and premier movies) and high subscriber acquisition costs (> $1,800 / subscriber). Then there's the cost of packaging content in way that will differentiate one ISP from another. Again, it all comes down to scale. If you're not a big player, you won't have sufficient base over which to spread costs and your prices will either be too high 

It also lowers the year-on-year costs of Minimum Guarantees (MGs) for premium content - since those can be based on more precise subscriber growth estimates, which can be more conservative. 

This is like electricity deregulation in the 1990s - except that then the product was a commodity. Because all players agreed on voltages and frequencies, moving product among wholesale players was straightforward. In other words, there was a common technology framework in place that enabled easy interoperability - and the wholesale market to flourish. 

Wholesaling on-demand TV also calls for a common technology framework - again to enable efficient interoperability among players. This framework will enable any video provider to distribute product on any network, and also enable any network to distribute products to any small operator. 

Table 1. Example wholesaling scenarios and business benefits that result.

For example, an IPTV provider could be acquired by a major DSL retailer. The combination allows the retailer to offer IPTV to its subscribers - immediately enriching its broadband offering. In addition, the DSL operator will offer a white label broadband/IPTV service to other ISPs also looking to make a quick and low-cost IPTV entrance.

As Table 1 shows, these benefits often work in combination and often in favor of both buyer and seller of content or bandwidth. For example, when an on-demand TV provider and a telecom carrier work together it can increase revenues and lower the cost base for both.

Consider the deal between glowria, Continental Europe's leading independent personalized on-demand entertainment provider, and Neuf Cegetel Group, the largest alternative telecommunications carrier in France. As stated in their joint June 2006 press release:

Glowria has developed extensive partnerships with all the major movie studios and a vast majority of independent video distributors… As a result, the company has the broadest catalogue in France and a solid experience in on-demand entertainment. "glowria's strategy is to reinforce its position in the on-demand entertainment market and to provide services on any format, for any device, whether it be through the television or the PC," explains Mihai Crasneanu, CEO of glowria. The company is able to provide Video on Demand either directly through its Web site, www.glowria.com, or through ISPs and cable operators such as Neuf Cegetel.

Costs include: content licensing, customer acquisition and retention, and content delivery (e.g., bandwidth, QoS, and video expertise and capabilities). An on-demand TV ordering is distributed under its own brand and re-branded by multiple carriers that bring that ordering to consumers' homes An IPTV operator sells through distribution partners to expand its subscriber base over which it supports fixed costs and scales variable expenses - both capital and operating - to substantially reduce per-subscriber costs A DSL provider orders TV services from a third-party without taking the time or incurring the cost of building an on-demand TV system of its own A carrier with excess capacity carries on-demand TV between wholesale buyers and sellers to increase traffic on its network.

And from Neuf Cegetel 

"The group's aim is to provide its customers with an ever-wider range of affordable, high-performance and quality services," explains Xavier Gandillot, General Manager, Residential Division, Neuf Cegetel. "Video on Demand was the next logical step… Glowria was the most 

skillful partner to provide us with a turnkey solution that could be fully integrated into our current service offering and to allow us to deliver the best entertainment and content service to our clients." 

In some cases, wholesaling promises to reopen markets considered saturated by entrenched services such as cable - while allowing cable and satellite providers to extend services beyond existing market footprints. Europe's largest satellite pay TV operator (BSkyB in the UK) bought DSL provider easyNet to extend services beyond pay TV to VoD and triple play offerings.

In the Netherlands and Germany, two of Europe's most cable-saturated markets, cable companies should feel threatened by foreign IPTV players entering the domestic market on a much more level playing field - thanks to 10Mbps ADSL2+ bandwidth. Some of those players will be telcos competing with other telcos on lines leased from those telcos.

Framework Requirements - An Open Client 

Such only make sense, of course, if they are technically feasible within a timeframe and budget that investors find attractive. Each player in a wholesale relationship has something to offer - and the key is whether they can interoperate efficiently. It's very easy to think of 

technology barriers that would slow things down or add costs. Suppose operator A wants to play content to consumers on operator B's network. Just a partial list of possible issues would include:

• B's set-top boxes can't decode operator A's content streams 

• B's electronic program guide (EPG) can't handle A's EPG content 

• B's customers want content, applications or services that A's platform can't support 

• A's control system can't control B's set-top boxes 

• Content playback is not properly formatted for B's users (e.g., mobile phones) 

• A's playout is too fast for B's set-top boxes or network 

• Network B can't enforce A's conditional access 

• Operator A and Network B use different billing systems that don't talk to each other 

Looking at these issues, it's also easy to imagine what technology decisions might be at fault. One would be if technology pieces were hardwired together rather than deployed as plug-and-play components using standards-based interfaces within an open architecture. Two key pieces of IPTV architecture are the set-top box and the backend software. Software in the set-top box (the client) is responsible for communications with the backend (the server). That includes interpreting control signals (like "play movie"), presenting the EPG, and on-the-fly decoding of content.

Figure 1. The Players. In on-demand TV, operators will enter into opportunistic relationships based on complementary skills and assets. An obvious prerequisite is the technology base to enable these skills and assets to interoperate.

When operators' clients and servers don't interoperate (e.g., my IPTV offering won't play over your set-top boxes) that probably means we're using different vendors' technologies and that there's no easy interface between them. The only option left is for one of us to throw out our technology and adopt the other's. That is likely to be a very expensive barrier to cross - just to complete one wholesaling deal - never mind implement a "white label" strategy where you plan to wholesale IPTV with many different partners across Europe. 

How does someone create an IPTV technology that gets in the way of easy plug-and-play? By building a set-top box client that is either a) hardwired to particular brands of set-top boxes or b) hardwired to vendor-specific backend technology. An example of the first would be where the client is built on a C code base specifically written to run on a target set-top box hardware. Here the client is essentially a builtin extension of the silicon in the box. An example of the second is where the set-top box only understands content encodings, control protocols, conditional access schemes, and other technologies specific to the vendor's IPTV backend implementation. 

In either case, the result is the same: back office software can't interact with the set-top box because the two speak different languages. 

If this open-client model sounds essentially like a web browser on a set-top box - it is. Like a web browser, the open set-top box client is no more hardwired to particular set-top boxes than web browsers are hardwired to particular PCs. The model leverages standards like HTML, XML, and Java for a write-once/deploy-anywhere strategy. And just as web browsers can play different content encodings (HTML, CCS, Flash, MPEG4, etc.) so can an open set-top box. 

Similar portability applies to the EPG. Some wholesale partners will want to present a consistent and branded EPG everywhere regardless of whose programming populates the EPG or where the EPG itself plays - whether on a high definition television or a three-inch mobile phone display. Other players - a white label IPTV provider, for example - may want their programming selections to populate the EPGs of many different syndication partners - regardless of how they format the overall look of the EPG. 

This type of context-based adaptation again resembles the web. Just as Google™ Maps look the same on multiple devices, so should EPG content. (Maps' display resolutions change based on whether the end user is looking at a PC or a mobile phone, but the headings and controls don't.) And just as one website can populate content from multiple other sites within a consistent look and feel - an open set-top box client can to do the same with TV programming content.

The solution for both arenas: technologies like XSLT (XML Stylesheet Language Transformations) - for example, that let you reformat HTML on the fly to equivalent C code to display a set-top EPG on mobile phones. The EPG menu schema remains the same - what changes is how content is presented by the backend VoD or IPTV service. With XSLT, changes are based on whichever style sheet the server invokes - one for set-top box A, one for set-top box B, one for mobile, one for PCs, or whatever. It's just like what happens in a web session where the server senses client-side parameters before selecting an appropriate template through which to filter content. On a PC, those parameters can include display resolution, browser type, cookies enabled, Flash enabled, Java version, SSL digital certificate expiration date, and so on.

Another advantage of using web technology is, of course, access to the web itself. A truly native web implementation (as opposed to, say, a native C implementation) poses no hard integration points that prevent the TV from working as a standard web interface. This opens possibilities like playing multiplayer games off the Internet, watching videos downloaded off Google Video, or even setting an Internet-enabled home security system or a heating / ventilation / air conditioning (HVAC) system - all from the TV (or mobile phone or PC - given how the user interface is reformulated based on client context). 

A web technology base also implies an IP core - and making your platform IP native throughout (all the way to the DSLAM, QAM, or QPSK network adapter) brings its own advantages. IP makes network components easier to plug and play - and it gives you a head start on adopting emerging IP standards like SIP (Session Initiation Protocol). 

Figure 2. The Wholesale Service Backend. Architecting backend functions into discrete blocks makes it easier to configure the right combination of functions to fit a particular wholesale offering

The Wholesale Service Backend 

Also affecting a specific technology's "wholesale readiness" are backend design decisions. In particular, the decision to deploy backend functions as discrete units (Figure 2) - rather than as a single hardwired monolith - makes the backend much more scalable and easier to tailor. Even where industry standards 7 are absent, a modular platform with open APIs can let operators achieve interoperability in the three areas vital to successful wholesaling: 

•Support for the open client 

• Easy integration with partners' applications and internal IT systems 

• Support of core network functions in an open way, including 

-QoS assurance and flow control

-Session management

Open client support 

Supporting an open client requires three key attributes in the backend: 1) The right assets available when called (like a DRM encryption algorithm or a particular XSLT style sheet), 2) Robust business rules processing

to invoke the assets appropriately, and 3) That business rules processing be abstracted as a separate layer apart from the assets to which business rules are applied.

For example, it's the server, not the client, that determines based on client input which XML style sheet to invoke to package a particular piece of content. That takes business rules processing - which in an open architecture would be abstracted from both the particular content and the set-top box. (Hardcoding a DRM algorithm to a playback device means you don't need rules to decide whether to use that algorithm. However, it also means that only compatible content can be played and only on compatible devices.) 

Another example of open client rules processing is the decision whether to download content to local hard disk first or to stream it as it is consumed. That decision would depend, among other things, on network bandwidth and whether the client says there's a local hard disk available. 

Easy third-party integration 

Robust rules processing is also key to how you support the widest possible diversity of third-party applications and IT systems - and how multiple diverse assets too are employed to satisfy different partner 

Figure 3. Technology Framework Conceptual Overview. 

agreements. The fundamentals of plug-and-play program-to-program integration are well understood, as are the specific standards employed such as XML, SOAP, DOM, and others. But plugging diverse assets together is just one step. Making diverse IP services play well together is another. That's what backend middleware does today - and will continue to do in the future in support of yet another standard: IMS (IP Multimedia Subsystem). In fact, a service-oriented middleware may be defined as one with 1) robust business rule processing; in support of 2) diverse functional capabilities; and that is also 3) an ideal foundation for IMS. 

The question for technology providers is whether standards are in fact employed for: 

• Feature extensibility 

• Service flexibility 

• Partner IT integration 

Potential wholesale partners will plan a multitude of different applications and services and want to tailor offerings with distinctive look-and-feel, price differentiation, consumer segmentation, and value-added services such as transaction TV. That requires the ability to integrate a lot of different layered services with such core services as business rules processing and client communication. But it also points again to the importance of abstract rules processing - such as to say which three-for-one promotions or which free games are available to which consumers and for how long. 9 Specifically with respect to IT integration, consumers may not know (and probably won't care) that their broadband provider gets its IPTV services from a wholesaler. What matters is that whoever owns the customer relationship offers unified billing and customer service. That means somewhere in the technology framework a billing module exists that, again, is not hardwired to the specific services (including partners' systems) upon which it relies account information. What counts is that modules responsible for providing or processing account information do so in an easily supported transaction stream - such as via XML messages. That way all kinds of different services and service options can not only be offered as points of market differentiation - they can also be one bill - as long as they communicate to the central billing module in an industry-standard way. 

Managing the core network 

Just as someone must take ownership of the customer relationship, someone must take ownership of the customer's quality of service (QoS). That's an issue because of factors like packet delay variation 

(PDV) - i.e., some packets taking longer than others to traverse the network, and the amount of delay can vary from packet to packet. If PDV is too high, service will degrade or fail. 

A QoS policy determines acceptable limits of a performance metric (like PDV) and what to do if limits are exceeded. A QoS policy server enforces the policy - by looking at QoS at points along the network. The same network elements (like a QAM or DSLAM) reporting back QoS metrics to an ISP's network operations center (NOC) can also report back to a QoS policy server. In response, the policy server will invoke the proper policy (based on business rules) and perhaps take mitigation measures - such as to download an entire video before starting to play it. 

QoS policy service resides under session management - the backend function that sets up and monitors end-to-end interaction between the IPTV provider and the enduser. Like accounting, both QoS policy and session management touch multiple other functions. So they too should be abstracted out to their own layers rather than bolted onto something else - like a VoD server. On the one hand, you might want the option to employ a variety of QoS solutions - depending on which one were to deliver the best customer experience. On the other, you might not wish to invoke a different session manager for each service - one for VoD, one for games, one for IPTV broadcast, and so on. You would rather use a consistent session manager for all of them - just as you would wish to stay within a consistent user interface for operating all of them. 

And by making solutions able to support different services, you also make them able to support different wholesale partners - some of whom request support for session "payloads" other than those you already provide - such as PlayStation®2 games, in addition to the Xbox games you now offer in your games package. 

A Great Customer Experience - Across Wholesale Boundaries 

What this discussion and Figure 3 illustrate is that a great customer experience - and the ability to move it across wholesale partner boundaries - results directly from the architecture of the technology framework employed. Key to that architecture is the ability to decouple functions as content moves from backend to front end - and to decouple contexts within functions. Decoupling functions means that how you implement one function (e.g., a particular QoS policy server) will not dictate how you implement another function (e.g., a particular client EPG). Decoupling contexts means that you can reuse the same function (i.e., make one investment) to enable different interpretations of how the function should be performed. Applications may be different, but all applications need to have the session manager set up their payloads for playout. Networks may be different, but all networks need QoS. Rule setting (policy making) within the function defines 

how it's done in one context versus another. As previously described, XSLT style sheets are an example of how to enforce context rules for presentation in consideration of different EPG layouts, CPE resources, and other parameters. 

One reason for a wholesale technology framework is to reduce technology infrastructure costs. Equally important to the operator, however, is the cost of preparing content for input into that infrastructure. The whole value proposition of on-demand TV is to present and package fresh and exciting content in ways that consumers find attractive and also differentiating from what other ISPs in the same market offer. 

Operators, therefore, will want to ally themselves with content experts who know how to deploy content in ways that are more scalable across content types, platforms, and wholesale partners. That includes skills in areas like:

Content creation synergies 

Smart content preparation will exploit synergies of content creation. One example is sharing common metadata and production techniques across content intended for different platforms. Another would be to establish different content preparation pathways in anticipation of the different requirements of those platforms. 

Content rights management 

Content owners are concerned about theft and digital rights management issues. The rights to broadcast a particular piece of content on TV does not automatically include broadband and mobile rights. Licenses to redistribute a valuable content proposition to wholesale partners, therefore, need to be written in a way that's attractive to other companies. Content could be anything - applications, application services, video, audio, teletext, or whatever.