IBM has developed and tested numerous applications in lab and real-life settings to help AT&T move its u-Verse IPTV service and Lightspeed network towards mass consumer launch. By Steve Hawley

Managing processes

The primary benefit of using an SDP is that it provides a single point of control to manage processes in a consistent way, system-wide, using standardised data models and supporting accepted telecom and IT standards. IPTV represents a very complex integration of many parts, so synchronisation must occur between content delivery, content management, middleware, content protection, legacy billing systems and business rules databases relating to subscribers, programming and delivery. Another focus is in helping the end-to-end system detect and recover quickly from outages and still ensure that usage and billing records are generated.

According to IBM executives at the company’s Telecommunications Solutions Lab in Austin Texas, AT&T had insisted upon having a single point of control into the array of systems used to manage its IPTV. IBM engineers first looked at the SDP systems calls necessary for content management, as well as for integration with operational and business support systems (OSS/BSS).

Enabling ‘blackouts’

In one case, the IBM SDP was used in support of the Microsoft TV IPTV Edition, helping with TV channel management and channel packaging. An application was developed to perform a discovery process in which it could detect and manage TV programming and manage it as items of content. One situation where this came in handy was with ‘blackouts’, where events intended for broadcast in certain areas are not made available in others. The SDP was used to take the blacked-out programming out of service for the duration of the event, for the designated group of subscribers, during which it would swap in alternative programming, and then reinstate the original channel when the event is over.

Another example was for VOD, to help ensure that subscribers had continuous access to videos, by developing a service assurance application. In the event of a failure, an application was developed to determine what failed, which subscribers were affected, bring a backup resource online to provide uninterrupted service, and ensure that the right systems elements would exchange the right data and trigger the appropriate subscriber billing events; despite the interruption.

IBM’s SDP approach allowed the operator to look at business and functional requirements across the operator’s entire service model, taking into account the content, the network, the types of service, consumer devices and service management choreography, as opposed to just service activation and provisioning. For example, the SDP can store service policies that are sensitive to the subscriber’s context at a particular moment, such as the consumer device and network currently in use, then adjust delivery and billing accordingly.

Core functions

Starting with core functions like service definition and subscriber directories, the operator can rapidly build ‘solution stacks’; building blocks representing additional individual or composite features and integrations with other services, which benefit from having access to a common subscriber and service profile repository. Unlike cross-services integrations that use a gateway between IPTV and IMS platforms, or IPTV systems that are directly integrated with an IMS system, IBM’s SDP approach allows a level of abstraction that, as IBM claims, reduces single-source dependencies.

Once solution stacks are built, they can be leveraged for other deployments and adapted to work with the products of additional third-parties in a given infrastructure category, as customer scenarios arise, to produce pre-integrated multi-vendor solutions.