Service Delivery Platforms

Service Delivery Platforms are around for several years now. Even there is no standard definition of  them, a Service Delivery Platform (or SDP) , would be a platform that a telecommunications service provider uses to deliver and manage telecommunications services over standard interfaces. The SDP concept was defined by several vendors in several different ways. TMForum saw this inconsistency and started the “Software Enabled Services Management” standard which defines the main deliverable: “Service Delivery Framework”. I will explain this in a later post.

Service Delivery Platform’s main idea is exposing the service providers’ internal capabilities to the outside world  to increase revenue. Outside world consists of, end users, third parties, over the top service providers and other service providers. By involving more parties into the value chain, eventually, new services will emerge and increased service usage will lead to revenue growth.

What internal capabilities does a CSP has? SMS, MMS, Third Party Call, Status information, Location Information, Ring tones are the most popular ones. So, I have a service named SMS. It is running quite OK. But what stops me from delivering a, “if Location is X, send an SMS” type of service? This will first increase my service diversification allowing up-sell opportunities and  second increase service usage. There may even some other combinations where the CSP cannot imagine but third parties are dreaming of.

So SDPs are good. But how do they work?

All the NE’s that we encounter in the CSP network, expose some kind of northbound interfaces to communicate with the outside world. SMSC’s uses SMPP, MMSC uses MM7, IN can use PARLAY (or propriety). We take those services and abstract them under a standardized structure, typically web services. After that, internal applications, or 3PP’s can consume those.

This process is called the “service exposure” step in SDP terms. There are however, other steps that I should mention.

Typically SDPs have a “service creation environment” . Here is where the service components are gathered and service logic is applied. Service Creation environments can be used by the service provider itself, or they can be exposed to third party providers. These environments also allow service developers to to test the designed service before going online.

After, the service is created, it is deployed on the SDP application server to serve to the service requests. This is the step of “service execution”.

Whether they are atomic services such as “send SMS”, or complex ones that require database queries, web service calls etc, SDP services should be exposed in a secure manner. To achieve this, SDPs come with Policy and Access gateways, to secure the service access and enforce some policy rules.

SDPs also need to include Service Management capabilities to on board the services, to monitor them and to apply any changes  required. SLM comes into play where certain service levels are needed by the managed services. SDPs that does not have OSS capabilities would expose NBIs to other OSS components such as Fault and Performance Managers. For BSS integration(CRM and Billing), ESB’s come into play. SDPs have also rating and charging capabilities.

Another component of SDP is WAP/WEB Portals or Storefronts where the users are able to enter a wap  or web site to browse content and hopefully, activate new services. The key in here is the consistent and customized user experience. For the mobile part, these portals, render the content for the user’s device to ensure the best quality display on that specific device. They keep a device repository to find the device properties, such as screen size, color depth etc.

Suppose a ring tone service will be delivered. The service is designed and ready to be deployed. This is a content based service and the content is typically delivered by content providers. Here, a content management solution should come into play.

What a huge scope isn’t it? Lots of components and integration work. That’s why SDP projects are multi-million dollar projects which require a long implementation period. Most CSP’s, therefore, prefer to implement SDPs in a phased approach. They start small, such as implementing just the storefront side and continue growing their platform step by step.

SDPs bring agility, increase service diversification and increase CSP revenues.  However, only a small percent of the CSPs use them in full power. These expensive tools are demanding but definitely promising.