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: 

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 

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 

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 

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 

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.