May 9, 2006

Pipeline Profile: Brian Cappellani

By CT Staff

SCTE sustaining (corporate) member since 2005

Title: CTO and VP Engineering, Sigma Systems

Broadband Background: Cappellani spoke with CT about the arrival of "all-play," a world of multiple and differing applications. Getting there, he says, requires more openness from existing systems and an operations support system (OSS) infrastructure that can both support and utilizeuse that openness.

Is there still a hold-up with the billing interface?

It's improving. The billing vendors are recognizing the need to provide better interfaces into their information. The goal of rapid service creation-not only creating the service on the network, but actually being able to bill for it-cannot be achieved without this type of integration. The next generation of services will require a rapidly accelerated service delivery lifecycle. Billing is a key component of that.

These next-generation services will feature a great deal of customer-driven personalization and management through self-care. Unless you can get to this data, you're not going to be able to deliver on those goals. But this requirement for access to data is not limited to billing; subscriber data cannot remain "locked" in any single system or service- specific silo.

So what's your approach?

What we're talking about is getting a unified view of subscribers and their services-their identities. Other systems may not be able to provide their subscriber information through APIs (application programming interfaces), or their APIs are not standards-based or optimally tuned. What we can do is sit in front of those systems and APIs to provide a unified view ... through APIs utilizing standards such as OSS/J and WebServices, thus easily supporting a move to a service-oriented architecture. We can also facilitate getting that information out to the systems on the network that can utilize it.

But what's the best database? Billing?

It really depends. The billing system may have information about what package or plan a customer may have, but it may not have the detailed information about the services that make up that plan. For example, you may not see information about email or the entitlements for content access. That information has historically existed in other, disparate repositories. Billing information will be part of the solution, but not the master of all the data.

Who then becomes the master?

We need to think of a "logical master." There needs to be a set of APIs you can go to for all this information, whether that is a fully replicated data store or a federated source of information drawn from many "masters." In the IMS (IP multimedia subsystem) and 3GPP (Third Generation Partnership Program) architectures, there are the concepts of the HSS (home subscriber server) and GUP (generic user profile) server entities where the goal is to allow key subscriber attributes to be available through common access to the application servers and components on the network. Any OSS system operating in this environment needs to be able to work with this type of entity.

And your role within an IMS framework?

We have talked here mostly about a unified subscriber view, but that is only one piece of the puzzle. Just being able to view the unified service profile is not enough-you need to support a unified management approach to these services as well. You need to be able to rapidly create and bring to market these converged services, across multiple technologies and access methods.

IMS talks about converging the network; an "all play" solution talks about enabling the end-to-end delivery of these converged services, including the integrated policy, interworking, identity and personalization that IMS promises. The progress toward IMS will be evolutionary, but the need to support these types of services cannot wait for a full IMS-based architecture.