Who Makes What: RESTful Service Delivery Platforms

Service Delivery Platforms (SDPs) for mass-market Web Services are now being routinely spotted around the globe as the first waves of big telecom service providers embrace the technology as a mainstream approach to build and expand their infrastructures. Recent examples from 2009 include Globe Telecommunications in the Philippines, TDC A/S (Copenhagen: TDC) in Denmark, and Telefónica SA (NYSE: TEF)'s entire Latin American operations.

And, inevitably, has come the global industry initiative to make it all official and boost the case for applications. In this case it’s the Wholesale Applications Community (WAC) , which “aims to unite a fragmented marketplace and create an open industry platform that benefits everybody – from applications developers and network operators to mobile phone users themselves.”

Launched during the hoopla of Mobile World Congress in February, the WAC so far embraces 24 service providers and three mobile device vendors, all big names in the mobile business. (See MWC 2010: Operators Form WAC Pack for Apps Push.) So it is serious stuff.

It’s them again
As is often the case with telecom services, much of the initial impetus for this movement has come from outside the telecom industry. Service providers generally have watched agog as Apple Inc. (Nasdaq: AAPL)’s iTunes AppStore has hit stratospheric levels of downloads and applications choice, as millions of users have demonstrated that, at last, here is something that they are prepared to buy in quantity – and something that telecom service providers could offer, too.

Certainly, the expansion and impact of Apple’s AppStore has been phenomenal. From its launch in mid-2008 it had grown to over 140,000 third-party applications by 2010, generating around 2 billion downloads (and numbers of dollars of the same order). According to AdMob Inc. , which serves banner and text-link ads on mobile Web pages for more than 15,000 mobile sites and applications globally, in December 2009 36 percent (about 1.5 billion) of global ad requests on its network were made by iPhones or iPod Touch devices, with the majority of requests due to apps.

“Major carriers have gone with SDP initiatives in the 2008/9 timeframe, whereas in 2007 they were still kind of scratching their heads and asking whether there was really a business case, and would people really use these applications,” says Joe C. Dyoub, worldwide solution manager for the HP Inc. (NYSE: HPQ) SDP Service Governance Framework (SGF). “What Apple did was to make a lot of those naysayers in marketing departments into believers. Now they view data services and apps as a proven, lucrative market moving at warp speed – now we have to do something.”

For Dyoub and many others in the telecom industry, that something is now obvious: Carriers and service providers need to exploit their network and IT assets and capture more of the service or application value chain. Indeed, Service Provider Information Technology (SPIT) is it. (See The SPIT Manifesto.)

Apple’s AppStore, for example, shares the application value between Apple and the developer (an agency business model), while the carrier receives only its normal data-service revenue – and data service plans being bid down by the carriers as they scramble for market share of these new, innovative devices on their respective networks.

“Many of our customers realize that, long term, that is not the best strategy for the communication provider. They would like to get to a more controlled environment where they can add their own value, their own differentiation to the subscriber experience,” says Dyoub. “And an SDP, because of its services-oriented architecture, RESTful Web 2.0 service exposure, and ability to bring in [telecom things] like location services, billing services, charging – whether prepay or postpay – and subscriber persona will help to differentiate the carrier from just being a pure bit pipe and hosting over-the-top services.”

In short, SDPs are a central component in the transformation of telecom network providers into more complex value-added service and application providers.

The exposure problem
But, if telecom service providers are going to steal Apple’s thunder by using SDPs to create their own agency business models with app developers and achieve differentiation by allowing telecom/subscriber attributes and capabilities to be included in apps, they have some problems to overcome. Primarily, developers need to master telecom APIs that give access to network capabilities, and these are notoriously recondite to non-telecom software developers. Further, there is a host of security, performance, and other issues to address before the engineering department will allow hordes of third-party developers loose on the communication provider’s network.

The access aspect is further complicated because just about every operator that already exposes its network capabilities to third-party developers has, for historical and business reasons, taken a different approach. Some are already based on SOAP/XML interfaces, while others have used Parlay X, or native interfaces, XML interfaces like the LIF MLP standard for location, and others use their own SDKs. But REST (Representational State Transfer) – hence RESTful as an adjective – has now emerged as an API approach that is very easy for third-party developers to use, as it is based entirely on a restricted set of widely used and understood standards – basically, HTTP.

“RESTful SDPs are fast becoming the preferred method for accessing subscribers and resources for a given service provider,” says Jaime Palmer, senior director of technology for BroadSoft Inc. “Primarily because it is lightweight, does not require advanced software development skills and permits for rapid application development. This is in contrast to other protocols such as SOAP that are still widely used, but better suited to perform transactional messaging such as provisioning or back-end systems integration.”

So SDP vendors now have a strong motive for making their products RESTful, and this Who Makes What thus takes a look at what this means for SDP products and their vendors’ approaches. However, caution is needed, because SDP is a very elastic term and can embrace a wide range of functions and, therefore, hardware and software products to implement them.

“More and more what we are seeing is that operators are creating a service delivery platform which is not a single box; it’s a complete environment based around an integration technology,” says Graham Cobb, director of service delivery marketing at Telcordia Technologies Inc. “Telcordia and companies like us supply the real-time systems that enable interactive services, whilst IBM or Oracle are building those environments and putting in some basic components such as a gateway function. Then services and service enablers are exposed, noting that one man’s service is another man’s enabler.”

So readers should resist the idea that an SDP is necessarily a single, well defined product like a server/software combination that can be ordered from a catalogue. And even if some can be, there are all the associated requirements for BSS/OSS, data management, charging/billing, e-commerce, ads, customer management, personalization, and so on that are needed to make third-party applications fly in a commercial environment.

The lack of a product archetype is somewhat unfortunate for a Who Makes What, and so the approach taken here is to take a fairly relaxed view as to what is, or is not, a true SDP, and to consider a fairly broad span of types of SDP and SDP-related products. Preemptively, the answer to your PR firm's "Why isn't my client's box/solution/magic dust included?" will have to be, for now, 'I dunno.' "

Here’s a hyperlinked contents list:

— Tim Hills is a freelance telecommunications writer and journalist. He's a regular author of Light Reading reports.

Next Page: What I – SDPs

SDPs have evolved a long way from their early first incarnations as custom-build IT projects undertaken by systems integrators for operators keen to sell ringtones, games, and other simple static content to customers as part of a walled-garden approach to new-service development. SDPs then moved towards a more product-based approach, with vendors offering specific solutions, and this approach in turn came under the spell of the Telco 2.0 movement – the idea that telecom service providers should mimic the Web 2.0 model and open some of their network capabilities to third-party application developers, even to those wholly outside the telecom industry.

Heavy Reading chief analyst Graham Finnie weighs in on IT's fundamental role in the "new" telco in this interview:

{videoembed|188658}At this point the story becomes a little Biblical, because the standards bodies had been on the general case for some time, and, notably, the industry’s Parlay Group (founded in 1998) had already produced a set of developer APIs for some basic telephone-network capabilities, such as call control and SMS. But these were deemed too complex for general developer use, and so Parlay begat Parlay X, a set of simpler APIs based on a SOAP-style of Web Services, which is a very well known and widely used technology in the enterprise world for enabling distributed applications in a Web environment. But there are still complexities around SOAP, and Web developers do not necessarily need all the features of a SOAP-based interface.

So more recently there has been the eruption into the telecom SDP world of the even simpler REST-based interfaces, which, in SOAP terms, are pretty lightweight and to which large numbers of third-party developers have become accustomed because of the central role that REST plays in the Web 2.0 economy – the Web being essentially a REST-based system. Many Web-based service providers and businesses, such as Amazon.com Inc. (Nasdaq: AMZN), Facebook , Flickr, Google (Nasdaq: GOOG), RememberTheMilk, and Twitter Inc. , provide REST-based interfaces. Examples are OAuth and OpenID for authentication and identification. And the combination of REST with technologies like Ajax allows browsers to support very sophisticated applications that scale well over large numbers of users. The latter is very appealing to telecom operators with large consumer markets, as these tend to be heavily browser based.

What SDPs do
To create an API, RESTful or not, it is necessary to know what the system to which it gives access does. This is where the elasticity of the term SDP becomes obvious, as vendors differ somewhat on this point.

A common buzzterm in the SDP world is communications service providers (CSPs). These are the people buying (or ought to be buying, as the industry sees it) SDPs – telcos, network operators, service providers of various sorts, and so on – and a point of the term is to emphasize that this part of the telecom environment is very diverse, and not only in terms of players. Networks may be IMS or non-IMS, fixed or mobile; CPE may be very smart or pretty dumb; and a core aim is somehow to bring all this together and leverage the capabilities into the new area of applications, in-house or third party. So the range of functions and capabilities of an SDP can be very broad.

At base, there has to be some kind of application server, real-time and carrier-grade for the heavyweight CSPs, that supports service creation and execution across a range of network technologies. So it has to expose various network functions and capabilities to the developer, which may be internal or external to the CSP. But the resulting application or service has to be managed in a great many ways – advertised, sold and provisioned to customers, charged, billed, revenue collected and redistributed between CSP and developer, and so on. And developers and CSPs need to be supported with software development kits (SDKs) and libraries, community forums, and so forth.

All this takes the SDP well into BSS/OSS territory and beyond, with the further complication that the SDP has to be accommodated within existing and next-generation network architectures, and to the migration paths between them. So it is not surprising that an SDP is not as straightforward a product class as, say, a router or Ethernet switch is, and that vendors may emphasize some aspects more than others. For example, some SDPs are currently focused on particular types of CSP (such as mobile operators) or market type (such as enterprise VoIP and Unified Communications) and are used for internal, professional telecom use, rather than for exposing network assets to miscellaneous third parties. Such SDPs can be offered as managed services to CSPs looking for a way of responding quickly to market changes but without having to provide large capital investment and operations support.

Thus, in her Light Reading Services Software Insider, "Telco App Servers: NGIN Revs Up for a Serious Run at SIP" (August 2009), Caroline Chappell observes that:

However, she reports that a mainstream view is beginning to emerge (reflecting that of IT vendors and systems integrators) in which an SDP is distinct from a telco app server and provides management functions across the service lifecycle. This means that the SDP orchestrates common management functions (including OSS/BSS functions) to support the lifecycles and operational needs of different types of services, whether communications services running on telecom app server(s) or content services and software-as-a-service (SaaS) applications hosted on behalf of third-party service providers or developers. Table 1 shows what this means in practice.

Table 1: SDP Common Functions

Next Page: What II – RESTful Technology

REST – Representation State Transfer – is a particular style or methodology for constructing distributed software systems, which in the telecom context may be very loosely defined as ones in which geographically distinct software processes are able to interact to produce a larger process. The Web itself is a (probably the) prime example both of such a telecom system and of a REST-style distributed software system; and one practical way of looking at REST is as a set of best practices for using the basic elements of the Web: HTTP, URIs, and so on.

The close relationship between the Web and REST is hardly surprising, as REST was proposed by one of the main authors of HTTP itself, Roy Fielding. In one sense, REST abstracts the best bits that the Web particularizes. So REST requires standard ways of uniquely naming (distributed) things, of linking things, of interacting linked things, and of transferring state information between linked things, to name some of the important ones. Its name clearly derives from the last.

On the Web, these are provided by URLs, hypermedia links, HTTP methods (such as PUT, GET, POST, and DELETE), and its general stateless way of operating, as servers respond to clients and then forget them. To a keep a sequence of interactions going intelligibly, each one has to include all the information on the current state of the sequence so that the server will know how to respond. This is in complete contrast to the traditional telecom finite-state-machine approach, where both sides know at all times where they are in the interaction and don’t need to be reminded as to what is going on.

It should be emphasized that REST doesn’t have to use HTTP; other Application Layer protocols that do a similar job and follow REST principles may be used. And, conversely, HTTP can be implemented in ways that are not compatible with REST principles. But, in general, the Web is very REST-like, and the adoption of REST into telecom SDPs is likely to encourage the spread of REST practices.

Table 2 summarizes some of the appealing characteristics of the RESTful approach to Web Services and examples of their applications scope. Hewlett-Packard, for example, recommends that any RESTful SDP gateway should support at a minimum the following HTTP content types: JSON, Atom, RSS, and XML.

Table 2: Some REST Characteristics

Standards
This being telecom, it is impossible to go very far without stumbling into standards requirements and initiatives. As BroadSoft’s Palmer points out, the need for REST is effectively embedded in the architecture of next-generation networks, as RESTful SDPs play a part in IMS migration and Web 2.0 convergence. The MMTel global standard that references the IMS architecture specifies the Ut-interface for the management of subscriber services and settings, and these are ultimately RESTful interfaces with XCAP payloads.

“The exposure of RESTful SDPs permits the convergence of Enterprise and Web 2.0 systems and enables an entirely new breed of applications called mashups,” Palmer says. “The de facto standards of Web services and the changing mind-shift towards openness is simplifying the integration of disparate systems. Further, service providers view Unified Communications and Rich Communications Suite as key market drivers, and UC and RCS typically require RESTful SDPs to deliver either core or value-added features to these overall solutions.”

The current core RESTful SDP standards initiative lies within the GSM Association (GSMA) OneAPI program, launched in early 2009 to specify a commonly supported API to allow mobile (and other network) operators to expose useful network information and capabilities to Web application developers. As part of this work, the Open Mobile Alliance (OMA) is specifying APIs that will handle REST and SOAP, and the initial APIs will thus be available in both RESTful and lightweight Web Service flavors. The OMA ParlayREST standards are expected to be finalized in late February or early March 2010 and will include key operator services such as messaging, location, and charging.

“It is believed that GSMA OneAPI will adopt this new OMA RESTful Parlay X standard and obsolete their existing standard. We also understand that some major global telecom carriers are going to adopt this new standard,” says HP’s Dyoub.

The point of creating such a harmonized set of APIs is application portability across providers – that is, if a developer writes an application for one operator, it is not necessary to rewrite it for use by another operator, even if the second operator is in a different country, which is currently a major issue.

Aepona Ltd. is the technology provider for the OneAPI reference implementation, and, according to Michael Crossey, VP of marketing at Aepona, both SOAP and REST versions of the exposed APIs were included to maximize choice.

“SOAP is more feature rich – it has more methods, there is more traceability with SOAP, and for certain applications that is desirable,” he says. “But for many Web applications that just need to query location or send a message, REST-based interfaces are desirable because they are very easy to use.”

A OneAPI beta has been running for about a year, and its first commercial launch, in Canada, was announced at the Mobile World Congress in February 2010, with the three major Canadian operators – Bell Mobility Inc. , Rogers Communications Inc. (Toronto: RCI) and Telus Corp. (NYSE: TU; Toronto: T) – participating in a commercial pilot commencing in February 2010. The pilot will use the GSMA's PathFinder number-translation service to determine which operator to send the OneAPI call to, while allowing for number portability. The GSMA says that PathFinder’s global nature will enable the rapid rollout of OneAPI to different markets around the world.

According to HP’s Dyoub, the new OMA RESTful Parlay X standards are likely to prove attractive to telcos and service providers because they do not rely primarily on an underlying SOAP/REST conversion, a common current approach to supporting REST.

“These new OMA REST APIs are very specific to REST structures and really take advantage of some of its inherent features,” says Dyoub. “From our view, they appear powerful and probably more attuned to what the telco customers are going to be looking for from their application developer community.”

Next Page: Another Angle – Hosted/Managed-Service Providers

Although the main interest of a Light Reading Who Makes What lies in telecom technology products and their vendors in the basic sense of hardware or software kit that can be purchased per se for telecom purposes, SDPs cannot be so neatly pigeonholed. The reason is that there is a market segment where hosted/managed-service providers create their own SDP-type systems to support the offering of primarily IP-based converged enterprise services through their own networks.

One such company is IntelePeer Inc. , which operates a worldwide carrier-grade voice peering network and offers a communications-as-a-service (CaaS) platform. The idea is to provide open access to carrier-grade telecom functionality with hardware, software, and network capacity delivered from the Internet cloud as an on-demand, fully hosted and managed service. Capabilities include dynamic protocol translation, transcoding, call routing, device discovery, intelligent call routing, SIP session management, and next-generation application development.

Underpinning this is the company’s AppworX RESTful SDP, introduced in mid-2008.

“A RESTful SDP is critical for telecom providers to make their next-generation voice and SIP-based services accessible for businesses and for Web services vendors that want to incorporate voice and rich media into their offerings,” says Charles Studt, VP of product management at IntelePeer. “Most developers are familiar with REST and RESTful APIs. A RESTful SDP simplifies the process for them and streamlines their ability to integrate and create a wide range of new voice and rich media services. For service providers, it dramatically reduces the time they need to bring new voice applications and services to market.”

Since introducing AppworX, the company has added a developer portal and community (fall 2009) and continues to add new toolkits and on-demand application components to simplify and speed the development process further.

The company argues that, in its market segment, there are significant differences in RESTful SDPs, particularly for voice and SIP trunking networks. Service delivery platforms vary in connection quality, performance, cost, time to deployment, and risk.

Next Page: Vendors & Products

As emphasized in the preceding pages, it is misleading to link the term "RESTful SDP" just to a single box or product with a limited and well defined set of functions. In many cases an SDP will be more like an extensive infrastructure or portfolio of different software (and server hardware) entities, varying from vendor to vendor, with more than a touch of systems integration and badge engineering to obtain the final result. The large telecom infrastructure vendors, in particular, tend to subsume SDPs into a wider service-solution portfolio – essentially a turnkey/systems-integrator approach in some cases. Including RESTful APIs into this mix is thus more functional extension than fundamental product design.

So Table 3 limits itself to a selection of vendors with interests in SDPs with RESTful APIs, and shows some SDPs and SDP-related products.

Table 3: Some Vendors With Interests in SDP RESTful APIs

In keeping with the potentially wide-ranging or portfolio nature of SDPs, vendors are continually acquiring specialist vendors to extend the capabilities of their offerings, or are making alliances to achieve a similar effect. Recent examples include:

Because SDPs, and RESTful SDPs especially, are intended to involve a wide circle of third-party apps developers, vendors are keen to encourage the formation of active communities of interest around their products. One obvious way of doing this is to foster a support environment and ecosystem that brings together developers, operators and service providers, and other vendors across the range of functions and business interests needed to enable and sustain an apps industry. Many of the vendors of Table 3 have either their own such programs or are involved in those of other vendors’. Notable examples are provided by Aepona, Alcatel-Lucent (NYSE: ALU), Amdocs, BroadSoft, Ericsson AB (Nasdaq: ERIC), Hewlett-Packard, and Huawei Technologies Co. Ltd.

Huawei’s inTouch SDP Partnership Program, launched in October 2009, is fairly typical of a large telecom infrastructure vendor’s approach. Announced rather grandly by the company as “an alliance of worldwide content and service providers employing Huawei's end-to-end solutions and a forum to share best practices and improve industry standards around the world,” the program provides a combination of tools and information that includes “access to Huawei's Technology Support Center, Application Innovation Center, and an abundance of market resources, including open Application Programming Interfaces (APIs), development tools and information, success stories, as well as research functions spanning customer behavior, market conditions, business development trends, revenue growth programs and pricing strategies.”

Recent new products
Given the somewhat amorphous nature of SDPs and that, as software, they tend to come in versions or as items and components adding further functionality to existing systems, a sample list of recent new products relevant to RESTful SDPs is somewhat eclectic, but shows the vitality of this area of telecom. A broad theme is the increasing integration of the SDP approach into wider service architectures and OSS/BSS:

Next Page: Vendor Angles & Activities I

As with all telecom technologies, vendors share some common views, but also have different emphases, directions, and interests. This and the following pages take a look at what this can mean in practice.

Aepona
Aepona’s Universal Service Platform (USP, diagrammed in Figures 1 and 2) is an SDP with RESTful APIs, founded on the company’s view of the Network-as-a-Service (NaaS) – analogous to software-as-a-service, but treating the operator’s network, as opposed to just software, as a consumable resource.

The company sees the key functions and features of such an SDP falling into four groups:

Aepona’s Crossey sees that last point as embracing a particular strength of the company, as the USP SDP includes a payments and settlement engine.

“It is all very well to be able to offer these services to third parties, but there needs to be a payments and settlement capability associated with the SDP,” he says. “As partners use network resources there needs to be a way for operators to monetize that usage. But also there must be a way for partners to get paid for their services, and the operator billing relationship is a valuable asset that can be offered for this purpose. And, given the multiple players in the value chain for these new business models, a comprehensive, automated multi-party settlement capability is required. ”

While the NaaS approach is aimed at the network of a specific operator, the company sees moves such as the GSMA’s OneAPI program as a sign of the future and a new business environment.

“That is somewhat different, because it extends the concept of single-operator NaaS and moves it into a cloud-based NaaS platform, exposing cross-network APIs to application providers across, say, a particular country or region,” says Crossey. “A developer can register for access to that cloud-based service, and reach all the subscribers in that country without needing prior knowledge of which network operator they are a customer of. That’s a key issue for developers these days, as they currently have to go to each operator separately for network access. With the cloud-based service there is just one portal, and the portal handles the routing to the right operator, as well as multi-party payments and settlement. So we shall continue to sell platforms to individual service providers, but we also see a new model emerging, where there will be more cloud-based service providers appearing and offering cross-operator service APIs.”

BroadSoft
On a general level, BroadSoft sees RESTful SDPs as an enabler for application development, whether internally or by a third party. The value proposition to service providers is that, through innovative service creation and delivering a superior user experience, they maintain stickiness with their subscriber base. This, in turn, drives adoption and usage and, in turn, results in increased ARPU.

A snag is that service providers don’t have all the answers to address the communications needs of every organization. Crowd sourcing third-party developers to integrate multimedia with next-generation business and consumer applications has the potential to overcome this problem, and the parallel introduction of app stores to attract third-party developers through some form of revenue sharing benefits both sides in terms of revenue and branding.

BroadSoft claims to be one of the first vendors to expose a flexible, secure, and robust set of RESTful SDPs, and says its BroadWorks Xtended program is based on three main pillars in addressing the application needs of its customers:

“We believe that there must be a defined path to monetization for a third-party program to sustain its vibrancy, but monetization of applications is not a trivial task,” says BroadSoft’s Palmer. “So we have defined the business, billing, and provisioning structure to help them go to market in a matter of months.”

Additionally, the company has its XLabs initiative to act as an incubator for innovative applications.

However, RESTful APIs do bring challenges for both vendor and service provider. For example, no standards currently exist to specify the controls to protect the core network. Thus the vendor is responsible for providing a reference implementation that is flexible enough to meet the variety of service-creation requirements while simultaneously balancing the concerns of the carrier in secure service delivery.

Next Page: Vendor Angles & Activities II

Hewlett-Packard
HP views RESTful SDPs as a very mature technology: The company delivered its first RESTful Web 2.0 gateway to an SDP customer in late 2008, for example, with a further delivery in North America in 2009 and is participating in lab testing in Europe and Japan. In general, HP sees increasing operator and service provider interest in SDPs, although that interest is still tempered with some caution and differing perspectives.

“Some are moving aggressively in this space, some are taking a wait-and-see approach, some want a hosted service offering, some in-network solutions” says HP’s Dyoub. “The biggest issue is getting telco customers that are still in a wait-and-see mode to change their strategy from a closed-garden approach to an open application developer environment, where key service enablers are provided by the carrier to maintain the value of the operator in the new Web Services marketplace.”

He lists the key features and function of a RESTful SDP as including:

Further, the SDP should provide not only policy and enforcement southbound to manage the access to the carrier's assets, but also northbound to manage the large ecosystem of developers that will want to consume these services as Web 2.0 RESTful APIs. In addition, a world-class UDDI Registry should be provided that allows application developers quickly to discover and download information about new services or changes in services offered by the SDP. That is, if a new version of SMS combined with charging is offered, then that metadata and WSDL or WADL need to be readily available for the application developers to locate and adopt for their applications.

Another important aspect is controlling the life-cycle of services, so that new application developers cannot register with mature or soon-to-be-retired services, and instead are pointed to the newest version of the service to be offered by the carrier.The SDP should also have a rapid on-boarding process for application developers to quickly discover and access the services, but with different classes of services and SLAs, as network operators don't want a rookie developer to have the same level of access (in terms of transactions per second, availability, and so on) as do proven professional developers. HP’s own solution to this is the SDP Service Governance Framework (SGF)(Figure 3).

And the SDP developer portal needs to be able to showcase winning applications, provide best practices, provide blogs for application developer discussions, and enable access to the latest tools, such as mashups and widget creation, for the apps developers.

HP argues that revenue management, monetization, and settlement are key elements of the its SDP solution, as the company has extensive BSS system integration expertise and can integrate the SDP into the communication provider’s prepay and postpay systems though its Internet Usage Manager (IUM) product. The SDP system has to be open and easy to integrate, as the communication provider will not want to purchase yet another BSS system just to do settlement.

Finally, there must be a Web Services service-creation environment to allow rapid creation of compound services – such as billing, premium SMS, parental control, and white list/black list – available for the network-operator marketing department to rapidly launch new services to the developer community.

From these considerations, and the company’s IT background, it is not surprising that HP sees SDPs as being more of a solution to integrate according to each customer’s network and business requirements than as a single specific product to be sold. Figure 4 indicates some of the software elements and integration expertise that are involved in the company’s SDP offering.

It follows that providing RESTful APIs, while important, is only a small part of the vendor’s task of implementing an SDP capability. In particular, Dyoub argues that transformation capabilities are essential. Existing Web 1.0 APIs – such as charging, location, and billing, but there are many others – must be converted to RESTful interfaces as part of the offering. This has to be done efficiently and supported, managed, and run in a high-availability telco-grade environment, and delivered either in-network to a customer or as a hosted service offering. The latter has recently become available through the company’s Enterprise Services business, formed through the acquisition of EDS.

The most recent iteration of HP’s portfolio of SDP elements is Service Delivery Platform 3.0. released in September 2009. This included a number of new components, including the SDP Service Governance RESTful Gateway, which automatically translates Web Services into REST.

A second is Web 2.0 Storefront Portal. This, Dyoub says, offers developers access to similar features and tools that they are used to on sites such as Facebook and Amazon – blogs, best practices, sample code, showcases, and so in. Additionally, and crucially, it provides a tie-in direct to the SGF to control the access, governance, and life-cycle of the application developers, and give tools to the carrier so that it can manage the ecosystem.

The third new element is the Service Orchestration Manager, which essentially handles the interactions for combinational services across different environments and technologies – for example, using a billing service with a Parlay X or SOAP/XML API in conjunction with SMS to create a new offering to developers via RESTful APIs.In a novel twist to the issue of adding SDP value, HP is looking at the possibility of helping the development of the application ecosystem through its consumer products division, and has already made some recent announcements in this area for application developers for touch screen devices.

“HP has a large product group that sells to consumers and that is now looking at smartbooks and netbooks,” says Dyoub. “They would have widgets that would consume services from the carrier for the netbook widget application – broadband widgets, wireless widgets, communications widgets. That, I think, is where HP can provide a lot of value to our telco customers because we extend the SDP value all the way into that realm, can extend into the subscriber’s home, and we can deliver value via the consumer device to that end.”

Telcordia
Telcordia’s main interest in REST is to provide the underlying real-time network services and service enablers that are accessed by such APIs, and not, for example, the gateways that are designed for integrating with third parties to support the APIs and other functions. According to Telcordia’s Cobb, this focus means that typically there are requirements for multiple APIs even within an operator’s network, and these are then exposed as different capabilities to the third parties. So Telcordia might provide a Web services-based API into an integration environment, and a further gateway function would convert that into one more RESTful or Parlay X API for third parties.

Figure 5 shows how the company’s Converged Application Server (CAS) provides this underlying enabler role.

“The underlying Web Services API that Telcordia provides is typically not standardized, but is very custom to the particular operator,” says Cobb. “We do have standardized APIs, but every operator wants their own extensions to them, because they want to be able to offer a variety of APIs targeted at different communities. Some will be standards based, some may be proprietary extensions with additional features. They tend to build an interface module which uses the underlying API that we expose, which is generally more functional than in the standards, so that they can create different niche APIs for different communities.”

Despite the imminence of standards such as OneAPI, Cobb sees the current mix of standards-based and proprietary APIs continuing for some time as the industry experiments with the possibilities: A major mobile operator might be interested in working with some big advertisers to enable some form of advertisement tagging that would work only with its network, for example.

“We think that some operators will move quite quickly to create both simple standardized interfaces and more sophisticated but nonstandard interfaces. Both could happen tomorrow, in principle, and will happen over the next 12 months. But, for the more complex ones – the sort we are working on in the TM Forum to try to drive some of that standardization – that process takes time, and that’s why the TM Forum kicked off the Content Encounter program a couple of years ago.”

In both cases, the result will be a wide range of APIs, with different requirements on them in terms of performance, scalability, reliability, and price. For example, an operator might offer a simple advertising service available at one price, and a much more sophisticated targeted advertising service at a higher one. And, although a charging service clearly has to be hugely reliable, setting up a simple voice call within a salesforce application may not need to be – especially if it is very expensive to ensure extreme reliability.

“Given that, within this SDP environment, operators are going to have to make some hard decisions about which things are real time, which things are not real time, which are highly available – what highly available means,” Cobb says. “In the IT world it probably means 99 percent or 99.9 percent; in the telecom world it typically means 99.999 percent; and in the Internet world it might mean just Best Effort. Which of those apply to the different interfaces? And it is going to be different for each one. There is no right answer to those decisions. You have to look at the business as well as the technical requirements.”

CAS is very much positioned at the high-reliability/high-scalability end of the spectrum, and recent development has been to introduce new, or to extend existing, capabilities for this underlying platform. Examples are in IP-based protocols, in particular DIAMETER, SIP, and HTTP, and in charging, which has been extended to include what the company calls "user policies." These allow users to define certain features, such as spending limits on particular capabilities, or permitted-caller lists.

An area that Telcordia is currently working on in customer pilots, although it is not yet shipping the product, is mobile advertising and marketing. The basic and much hyped idea within the industry is to enable third parties to deliver advertising as part of a content delivery service. In Telcordia’s view, mobile advertising has to be closely linked into policy, because to be acceptable the advertising has to be under the user’s control, so the user decides how many – and what kind of – adverts they are willing to tolerate. Crucially, to protect the user’s privacy, the personal information needed by the system is not released by the operator to the third party, as the APIs provide access only to anonymized and categorized information.

Next Page: Vendor Angles & Activities III

Volantis Systems
The company’s Content Delivery Platform (CDP) is specifically targeted as an integrated software platform for the delivery of varied and personalized content to large numbers of mobile Internet devices. It provides RESTful APIs (as well as Web services) that can be called by third-party developers and other members of the SDP ecosystem, but also uses RESTful APIs from various integration points across the SDP. The CDP has been integrated (via RESTful, Web services, and Java APIs) to extend the breadth of existing SDP solutions from vendors such as IBM, Huawei Technologies, and Oracle.

“Clearly, we support multiple APIs, including REST, to allow operators to adapt to the changing demands and needs of content providers, developers, and other SDP component vendors,” says Jennifer Bursack, head of product marketing at Volantis Systems. “Our technology allows operators to adopt emerging standards as they evolve, whatever the protocol or technology they use. We use, or recommend, appropriate APIs in the appropriate places – so expose Web-based APIs (REST, SOAP, and so on) for distributed users and remote systems, but also support standard Java APIs, JDBC, and so on, for local systems within the SDP.”

From the company’s perspective, the key characteristics of a current SDP are to scale to give network access to hundreds or thousands of third-party developers, while enabling features within the network that add value to developers and give the carrier or consumer control over the information being shared. Information and carrier services that are currently most relevant to the content and applications being served to consumers include mobile Internet and messaging gateways, and billing systems that allow the developer to monetize its apps. But, as the SDP expands, additional services will become important for developers, such as location information, age verification, and transcoding services. And the SDP will need to support a wide variety of developers, on different platforms, and an increasingly complex array of handsets.

Security is seen as one of the largest remaining issues surrounding the use of open RESTful APIs, but currently evolving standards, such as SSL and HTTP Basic/Digest authentication, OAuth, and OpenID, are helping to address this.

VOSS
VOSS concentrates on unified communications and Internet telephony for the enterprise market, and thus has a somewhat different approach to most of the vendors covered elsewhere in this Who Makes What. The core SDP-related product is currently VOSS 7.1 (see Figure 6), an automated unified-communications service delivery and management platform, designed specifically to address the issues of deploying and managing such services by service providers and enterprises.

“That is a pretty sophisticated market in terms of features required and the level of complexity in the underlying network that service providers are offering today,” says Chris May, founder and VP of business development at VOSS. “You have two opposing forces in this market. There are what we refer to as domain managers at one end – where we see ourselves – and who are down in the trenches and handle the minutiae of monitoring, configuration, and all the boring stuff that nevertheless requires sophisticated engineering skillsets. At the other end are the bigger-picture SDPs, with the IMS approach, a reference architecture where everything is well defined, with product catalogues, activation, processes, shared information models, and so forth. Our argument is that, in the enterprise telephony space, there is a yawning gap between the two. You cannot come into this space just as an SDP and expect to be able to perform the minutiae. You need highly sophisticated domain management skillsets.”

This does not mean that VOSS 7.1 is isolated from the developer world. It has fully published Web services APIs available to third-party developers, and some of its customers currently use these APIs to interface their own customer portal applications. The company is also working with Cisco to develop a standards-based multiservice architecture, based on the TMF Shared Data Model, for service providers.

However, the company’s aim is not to provide immediately a complete end-to-end SDP, but to focus on the requirements of its particular domain, such as the ability to create rapidly some order-management tools, some service cataloguing, and service management so that service providers can get their offerings up and running quickly.

But the third-party, open-API, SDP approach will certainly enter the enterprise unified-communications market, although it does raise issues of control, but most likely as part of a continuing evolution that sees service providers integrate increasing ranges of capabilities – such as order management and billing – into their offerings. That will increase the need for shared information models and a greater range of APIs to expose network and information assets.

Currently, the main direction of the VOSS platform is in pre-integration with the systems of the major enterprise systems and applications vendors, such as Cisco, IBM, and Microsoft.

“Anything to do with presence, for example, has to be network aware,” May points out. “And it is almost as if these companies are service providers in their own right. In managing something like presence we have to understand that this business unit is running, say, Avaya kit, that one Cisco, and Microsoft OCS [Office Communications System] is running across it here, but Cisco presence is there. If you do not understand the mapping of that network, you cannot offer a ubiquitous and useful presence engine. And that is the role that we are playing.”

— Tim Hills is a freelance telecommunications writer and journalist. He's a regular author of Light Reading reports.

Back to Introduction