Uniform Service Delivery in an SDP Depends on Resolving API Issues

Much has been written and spoken about Service Delivery Platforms, or SDPs. There will be plenty of opportunity for further discussion at the forthcoming SDP Global Summit in Prague, at which we are proud to be speaking and exhibiting. It is a good time to reflect on what the point of a SDP is, rather than how it should be constructed.

As far as we can tell, an SDP is a platform for unifying service delivery in an operator’s network. Unity is the key theme: an SDP provides a uniform mechanism for offering and supporting a range of services; a uniform way of integrating those services; and a uniform means to integrate the services with the billing and support tools that allow operators to bill customers and provision the services to which they are entitled. Critically, the SDP should allow innovation in service creation to be extended and broadened to maximise return on the operator’s assets.

There are of course, many problems with this description, not least is the fact that there is little current agreement on what constitutes an SDP. This is our opinion; others may have a different view. However, the area of most obvious concern to us is that of the uniform mechanism for offering and supporting a range of services. In order for this to be achieved, service enablers need to be provided, or exposed, by the underlying network assets owned by an individual operator. These can then be interpreted, composed and orchestrated to allow services to be created. The problem is that there is no consensus on how this can actually take place.

There have been many attempts to provide a solution. The problem stems from providing a means of the interpretation of complex signalling protocols that actually control call or media sessions into something that can be leveraged by a developer into a service. Normally, this takes place via one or more kinds of gateway. Such gateways provide an abstracted output of signalling information, making it available to applications that interpret it for processing. The output is typically in the form of an API. We touched on the theme of network APIs in our last post; let’s dig a little deeper now.

Various APIs have been developed for the presentation of signalling and session data. Efforts range from those that provide an interface of great granularity, with little abstracted from the signalling itself, to those that abstract the data to a very high degree. Highly granular APIs provide rich control possibilities, but create the problem that a pool of specialist talent is required to work with the resulting data. More abstract APIs broaden this pool, as less specialist knowledge is required to interpret the data, but can affect the utility of such data, limiting the scope of the application. Proprietary APIs have abounded, as different vendors created their own solutions to address the issue. However, this limited operator choice, led to vendor dependencies, and created interoperability issues.

Some groups have tried to address the issue by creating public standards that can be adopted b any vendor and are positioned at different levels of complexity, accepting the trade-off that greater abstraction reduces the advantage gained. Parlay is one example of such an initiative.

Parlay was created to abstract network resources sufficiently such that a wider pool of developers could be enabled and thus permitted to create applications that could run on an operator’s network. However, the resulting APIs were arguably too complex to allow this to happen and the use of Parlay was largely restricted to within an operator itself. Later efforts, such as Parlay X have attempted to address this, by providing further abstraction and delivering a format that was more familiar to non-telco developers. It remains to be seen if this will be successful, but early indications are that additional abstraction may be required. Still further efforts have been made using XML and SOA principles, and the quest will doubtless continue.

This is all very confusing for operators – which interfaces can be used to provide the right amount of access and control, allowing real third party innovation? In the context of an SDP, this is a critical issue. If the chosen platforms neither support nor expose the correct interfaces, the strength of the SDP as a means for uniform service delivery - or a platform for innovation - is fatally undermined. Operators face tough choices in assembling the elements that comprise their SDP in order to meet these needs.

At Gintel, we are faced with this problem all the time. Each operator’s network is different and contains a different array of solutions for the presentation of signalling information. We are not in the business of specifying APIs at a network level. However, our expertise has been critical in helping achieve uniformity in presentation of information for service creation. We are able to interface to a wide range of network gateway solutions, ensuring that our applications can be deployed in any network environment. This is a crucial advantage – we can adapt our solutions to any network interface, ensuring that operators can achieve the uniformity that is required for successful deployment of one of our solutions. We recognise that it’s simply not enough just to provide robust, feature rich applications. Operators also need application vendors that can understand the underlying network and ensure compatibility to both existing and future interfaces and architectures.

We are looking forward to the SDP Global Summit in Prague, where we shall certainly hear more about different approaches to resolving network interface issues. Our customers can be assured that this is one issue we have solved for them – one less thing to worry about in ensuring successful application delivery and deployment. If you plan to attend, be sure to drop by – we look forward to seeing you there!

Tore Saeter, September 2008

 

 

 

 

 

 

 

 

 

 

 

 

Want to learn more about Gintel?