 |

SDPs - Delivering Future Service Capabilities Now
From Mobile Europe Supplement
February, 2008
| JUST AS THE MARKET WAS CONVINCED IMS WAS LIGHTING THE PATH TO A CONVERGED SERVICES FUTURE, SERVICE DELIVERY PLATFORM (SDP) VENDORS BEGAN TO PROVIDE PLATFORMS THAT PROVIDE CREATIVE SERVICE INTRODUCTION ACROSS MULTIPLE NETWORKS, INCLUDING LEGACY AND NEXT GENERATION NETWORKS – WITHOUT THE NEED FOR EXPENSIVE IMS TRANSFORMATION. SO HOW HAS THE SDP MARKET EVOLVED TO THIS POINT, AND WHERE WILL ITS FUTURE VALUE LIE? KEITH DYER SPEAKS TO TELENITY’S GUROL AKMAN, CTO, AND NITIN PATEL, VP STRATEGIC MARKETING, TO FIND OUT WHY THIS COMPANY HAS HAD SUCH SUCCESS IN THIS AREA, AND WHAT LESSONS OPERATORS CAN LEARN FROM THEIR APPROACH TO THE DEPLOYMENT OF SDPS. |
|
 |
WHAT IS DRIVING THE DEVELOPMENT OF SERVICE DELIVERY PLATFORMS WITHIN TELECOMMUNICATIONS OPERATORS?
GA: We are talking about a dynamic and ever growing environment where operators can manage existing services and introduce innovative services rapidly. Operators are in a highly competitive environment. At the same time they are facing increasing complexity. They face the challenges of FMC, NG networks/technologies, and the need to deliver more and more differentiated services. Enough warnings have been given about why operators should watch out against service silos (promote reuse instead) and why it is not feasible to perform OSS/BSS integration each time a new service needs to be introduced. Lastly, on the business front, it is crucial for an operator to establish and maintain effective third-party relations in a flexible way. With a wellarchitected SDP in place, an operator can do all the above.
NP: The convergence aspect highlights the issue of how telecom operators can control services across different networks - fixed, mobile, media/cable - and have a converged service delivery, integrated with their OSS/BSS. Point solutions are inefficient in a multi service environment. As market demand increases, networks evolve with a particular focus on improving the CAPEX and OPEX but also develop incremental services based on existing SDPs. To remain competitive from Web based application providers and offset with declining voice margins, SDP is gaining good traction in enabling an open market place of media rich blended services such as personalized ringback tones, VoIP, video mail, video conferencing or video on demand, IPTV, location-based services and messaging.
CAN WE ATTEMPT A WORKING DEFINITION OF A SERVICE DELIVERY PLATFORM, SOME OF ITS ELEMENTS AND ITS PLACE IN THE OPERATOR NETWORK?
GA: I visualize SDP as a collection of components with several overarching goals. One goal is being to create an environment where service partners and application developers can collaborate in serving to the needs of subscribers. If you can let third parties take a pro-active role in service creation, you are bound to get more creative ideas. SDPs should provide standards-based and policycontrolled ways of opening up programming interfaces in northbound direction.
Secondly, in southbound direction, an SDP needs to interface to the network layer to utilize various service enablers. Example enablers include location/map servers, SMS/MMS centers, IN, SS7, SIP/IMS network nodes and media servers. In all these cases, an SDP makes these external entities accessible to the service plane in an abstract manner. Decoupling of the service logic from the network technology helps launch services faster and migrate them easier.
“As market demand increases, networks evolve with a particular focus on improving the CAPEX and OPEX but also develop incremental services based on existing SDPs.” |
Thirdly, on what I call the near side of an SDP, lie OSS/BSS systems for charging, provisioning, network management, etc. This side is equally important because that is where operators frequently employ custom solution sand almost all services need to be tied to them. If you can use the same OSS/BSS integration points across multiple services, you will reduce costs considerably. This is also where the use of flexible business processes gain importance. As each operator’s business/technology requirements and relations with its partners vary, integrating technologies around standards in a flexible manner is crucial for success.
Finally, there is the business view of things and this cannot be considered on the side. It must in the center. The biggest issue with SDP continues to be its business case. This is where we believe availability of a rich set of new services should help. Attempts to sell SDP gear without accompanying new services make it difficult for an operator to understand the benefits of an SDP and the need for it. New services are instrumental in subsidizing initial SDP costs and improving the business case.
IS THERE A WAY THOSE INVESTMENT DECISIONS CAN BE VALIDATED TO HELP OPERATORS MAKE THAT BUSINESS CASE?
NP: There is, and this is why we have proposed a three step process. We want operators to realize the benefits of services that are actually creating revenues, whilst they are heading to a more complete solution. So we engage initially with point products that provide quick time to revenues. Then the second step involves the consolidation of these resources used by those individual point solutions toward a common architecture and services exposed to partners. These components are integrated with OSS/BSS systems, as needed without overrunning budgets. Finally, the deployment of a full blown SDP means the entire suite of products including existing services and large number of new services through operator “open garden” are utilized to create an end-to-end SDP deployment that is SOA compliant and features Web Services, with tight OSS/BSS integration.
And the feedback from this approach has been very positive. There are in essence two kinds of operators – greenfield and established. More often, the motivation for the established operators is CAPEX and OPEX improvements, and the management of a unified platform that is open to third parties. Greenfield and Tier 2 operators are primarily focused on market penetration through new services, on timely service creation and quick time to revenues. Our three step approach fits both requirements, creating a valid business model for simplification of existing elements, as well as the ability to create market-ready services.
IS THE DEPLOYMENT OF AN SDP DEPENDANT ON THE EVENTUAL MIGRATION TO IMS?
“Our added value is first in studying the access layer interface and creating specialized gateways featuring an aggregate set of service enablers in messaging, call/session and media control, location, and OSS/BSS domains. These carrier-grade gateways constitute an important facet of our strength and core competence.” |
GA: I think there’s been some really good communication to the market about SDP and IMS in isolation, but the same amount of clarification did not happen with regard to the relationship between SDP and IMS. There are important differences between the two technologies and their reasons for existence. IMS strives to deliver IPbased services over fixed and mobile networks using SIP as the underlying technology and it assumes an all-IP environment. Its challenges are multifold, including end-to-end quality-of-service. SDPs, on the other hand, strive to provide a service coordination and abstraction layer across all underlying network technologies including but not limited to IP networks and their focus is on effective service delivery. SDP can be a valuable asset without a full IMS network running beneath it and can serve as a key enabler of pre-IMS and IMS-like services. Having said all this, a SDP architecture should take SIP/IMS networks into consideration as part of its original design to be future-proof. SIP is already here, IMS is around the corner, and they are both real.

WHERE WOULD YOU SAY TELENITY’S STRENGTHS ARE WITHIN THIS MARKET?
The current state of the telecommunications industry can be summarized in one word: convergence. Convergence among operators, media/internet, Fixed-Mobile and all-IP networks, and services are different faces of the same trend. The SDP enables convergence of services, making networks and the Web programmable for large number of developers. It offers convergence of service enablers, interfaces, and OSS/BSS integration points under a common framework which also includes application development tools, service and partner management systems. The primary benefit of the SDP is to help operators increase ARPU and lower CAPEX/OPEX by facilitating reusability across large number of niche valueadded services. Getting new multimedia rich bundled services out to subscribers and monetizing them rapidly is the key to success in today’s competitive environment.
Telenity SDP meets the end-to-end needs of service providers seeking either a single vendor out-of-the-box SDP solution or a modular and loosely-coupled platform that allows select components to be part of other vendors’ end-to-end SDP offerings. Telenity SDP solution comprises:
- SOA compliant and heavily WS based system architecture
- Powerful service creation and execution environment
- Specialized gateways with open interfaces and high-value enablers for messaging, session/media control, and location-based functionality
- Single point of integration to OSS/BSS systems; flexible OAM&P framework
- Compelling set of pre-integrated multimedia services
As SDP continues to gain considerable traction among fixed and mobile operators, Telenity SDP components play a key role in small- as well as large-scale SDP deployments with proven reliability and performance scalability. Telenity SDP components have been interoperability tested with best-ofclass complementary products from leading infrastructure vendors.
Gurol Akman, CTO
Nitin Patel, VP Marketing, Telenity |
GA: We should first acknowledge that most IT vendors are very much interested in providing infrastructural software for SDP. If for nothing else, SDP opportunities represent a new revenue stream for them. Their core contributions are in places such as application servers, enterprise service bus and directories, business process management suites, and portal frameworks, and I believe they are doing a good job of that. Many of these areas have standards associated with them. Hence, we can rely on vendors such as Oracle, BEA, Sun and leave these areas to their expertise.
However, our added value is first in studying the access layer interface and creating specialized gateways featuring an aggregate set of service enablers in messaging, call/session and media control, location, and OSS/BSS domains. These carrier-grade gateways constitute an important facet of our strength and core competence. We add further value around these components with our unique OAM&P suite comprising service, partner, policy management capabilities as well as extended subscription management, personalization, revenue accounting, and reporting capabilities. Access to these capabilities is via our administrative, partner, and subscriber portals.
We also differ from our competitors in our unique approach to service creation as our toolset is network/technologyagnostic. We can help simplify IN vs SS7 vs SIP/IMS services creation as our service creation tools are designed to keep the service logic independent from the network technology used to realize it. We complement our service creation toolset with a carrier-grade service execution platform of our own. Once again, thanks to our technology-agnostic approach to service creation, our services can also be deployed and executed on industry standard application servers.
NP: Finally, unless you build and offer services using the approach you are advocating, not many people are going to believe in them. I would just place emphasis on our service layer, and the endorsement of the Telenity Canvas SDP components in various business models and range of operator sizes. We have gained significant experience both as one-stop SDP vendor, and also as a team player on a 10 vendor integration program proving standards compliance. One such work we have done is with Turkcell – where they were able to reduce their time to market for new services to one day, cut the number of interfaces they needed to support from 600 to 200, and standardized service orchestration and developer access. I’d also mention our work with Nawras, who have introduced our one-stop Parlay-X based SDP solution with extended range of services from our VAS portfolio, which sits across messaging, video ringback tones and a whole host of areas where we have created services using our own artillery. It makes it easier for others to believe in us when we prove that level of belief in ourselves.
|
 |