When an obscure product class acquires its own forum, the telecom industry uses one of the oldest forms of signaling known to man – waving a flag to say, "look here!" Here in the current instance is the service broker, whose Service Broker Forum was revealed to an astonished world early in May 2009 by founder vendors Aepona Ltd. , AppTrigger Inc. , Convergin , jNetX Inc. , and OpenCloud Ltd.

As the Forum’s initial press release ponderously pronounced:

Very, very loosely, in other words, it looks as if the awful complexity of modern software-defined networks and services is beginning to hurt and something needs to be done. But there are also more topical reasons for shouting about service brokers, and one is that they can be viewed as a consequence of – or at least they mesh closely with – the telecom industry’s now-torrid love affair, courtesy of Apple Inc. (Nasdaq: AAPL), with the vision of vast numbers of third-party applications, open application ecosystems, and revenue-generating online application stores. Service delivery platforms will support all this by exposing network capabilities to applications, executing the service logic, and so on, thereby either incorporating service-broker-type functions themselves or requiring the use of a separate service broker.

And, indeed, this new services enthusiasm is the very reason Light Reading is so keenly looking at various parts of the Service Provider Information Technology (SPIT) ecosystem and hoping to make sense of it before the telecom industry becomes completely unrecognizable. (See Light Reading: SPIT Is It and The SPIT Manifesto.)

Service broker mania?
Well, "mania" is going a bit far, but there are some pragmatic reasons for being interested in service brokers just now, as they offer operators a way of extending the life of existing assets and services through interworking old and new network and service technologies such as IMS and 3G/4G mobile. These days, getting something more and new from what is already there is highly attractive.

“The recent interest in service brokers has taken us – and probably everyone – by surprise. It is exploding. A year ago, they would have been seen as an interesting piece of technology looking for a problem, probably,” says Jonathan Bell, VP Product Marketing, of SDP/service-broker vendor OpenCloud. “I think new-service prepay enablement is very key to this change, particularly in Asia and Eastern Europe, where prepay is dominant. Telecoms operators are asking themselves: How do we get some more services into our customer base? Prepay-enabling a service means that I can put it into the two thirds or 80 percent of the customer base that at the moment has just basic calling and basic SMS services.”

Certainly, service brokers are seeing a surge of mobile-operator RFIs/RFPs and, in some cases, contracts and deployments. Recent examples include AT&T, Chunghwa Telecom, Mobily Saudi Arabia, Orange Group, Vimpelcom, and Vodafone Group.

But, like many other things that are essentially software, service brokers are horribly complicated and involve contentious debates over highly abstract functional models and their realizations. As Caroline Chappel, frequent author of Heavy Reading research reports, pointed out in her September 2008 Services Software Insider, "Combining Telco Services: The Network Service Broker Opportunity":

This Who Makes What tries to avoid becoming bogged down in such arcana by taking service brokers to be network software platforms of various types that essentially allow telecom services and network functions to interact across at least some different technology domains (such as traditional IN, IMS, and Web) and also to allow new applications to be constructed and offered by both network operators and, eventually, third parties in a converged, open environment.

The aim is to present a list of selected vendors in the area and to make some comments on recent product developments and trends in the industry and technology.

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: Whats & Whys of Service Brokers

The underlying idea of a service broker is not new, and can be traced back to the early days of the SS7-based IN/AIN in the PSTN. Here a Service Control Point (SCP) would run service logic and mediate among it, the triggering of the various Service Switching Points (SSPs), and any Service Data Points (SDPs) or Intelligent Peripherals (IPs) involved in the service. This was a classic telecom situation of finite-state-machine call control, and the SCP provided a way of making that work by pulling the various functional and service interactions together at a single point, controlling their sequencing via a prepared script.

In their modern incarnation, service brokers allow a much greater range of services, applications, and network functions to interact across a much wider range of environments than just the PSTN -- and in much more complicated ways. This wider world includes the hugely important mobile extension of classical IN via Customized Applications for Mobile Network Enhanced Logic (CAMEL), and more fundamentally the entirely new Next-Generation approach to telecom services based on Session Initiation Protocol (SIP)/IMS protocols in an IP environment. It also increasingly embraces concepts and approaches stemming from the software/IT world, such as Service Oriented Architecture (SOA) and Web Services, where the network disappears into an invisible substratum and only a cloud of freely interacting software elements remain from which services and applications are assembled.

Now is the time
Given this huge extension in their scope, the current surge of telecom interest in service brokers is not too surprising, and has been building in the background for some time.

Sharon Aran, product manager, service broker product, of mobile services provider Starhome Mach , points out that the need for such service-broker functionality has long existed in mobile networks, but that many operators were not translating this need into a defined product category. It was more a matter of getting equipment vendors to enable a specific service for prepaid or VPN customers, for example, or -- for operators with sophisticated internal development teams -- to support capabilities such as prefix chaining to allow the gateway MSC (G-MSC) to trigger appropriately on a new sequence of service dial codes.

“Today you have more and more services, and subscribers are smarter,” she says. “They want to be a prepaid user with fun tones, special shortcodes, and things like that. Although you can support this if you do everything on the same SCP, it ties operators into a specific vendor. So operators need a way to enable their subscribers to have different types of services and to correlate them together.”

And all this is taking place against a general migration to SIP and IMS technologies in both mobile and fixed networks as operators embrace IP as the universal base of converged future telecom networks and services, and with it new network architectures (see Figures 1 and 2). However, this is a major task that is going to take many years to complete, and different operators will choose different migration paths according to their circumstances and needs. SIP and IMS references
For lots more on SIP and IMS and changing views over the years, please see:

Convergence pragmatism
“Every service provider is not going to be implementing a default new architecture blueprint and effectively start all over again,” says Patrick Fitzgerald, senior VP, Global Sales & Marketing, AppTrigger. “So there is a very pragmatic issue around managing convergence -- that process is going to take 10 to 15 years, and operators will need to have something that is independent of the specific architecture and that sits between the service and control layers to provide the necessary functions.”

Unsurprisingly in today’s chilly financial climate, operators find the idea of being able to sweat existing IN assets and services into the future attractive, and if this results in the faster and cheaper development of new services and applications by repackaging or otherwise reusing existing ones or software components, so much the better. Further, the high-level exposure of network capabilities is essential to the take-off of the third-party-developer model for application stores and the like -- and that, too, needs something to mediate between the various functions and layers.

Next Page: Service Broker Technology

As already hinted, the term service broker is attached to a linguistic morass, where lurk such expressions and acronyms as service orchestration, service interaction, application chaining, IMS SCIM, Telco 2.0 mashups, service blending, and the like. While some of this represents a combination of history and vendor marketing and approaches, it also reflects two fundamentally different domains of technology that are being brought together by converged NGNs: the telecom network itself and networked software (using this term for the sake simplicity).

So, for example, service orchestration tends to be used by the IT world for the kind of service-broker functions needed for interactions between distributed service-oriented architecture (SOA) software services -- that is, where loosely coupled and distributed elements of software can interwork to form larger units of software to form complete applications. SOA provides a standardized way of doing this, and supports a standard scripting language, Business Process Execution Language for Web Services (BPEL), for the scripts governing the interactions between the various SOA services. Web 2.0 mashups belong to the same general approach of stringing together dispersed bits of software and data to achieve interesting effects.

Fundamentally, the network-software view of the IT world is that the telecom network acts as just another software service -- summon it, it responds promptly, and it can be treated like any other software process. But that is a massive simplification.

“Telecom services are about finite-state machines, and moving from one state to another -- the basic call-setup model is very important to that,” says OpenCloud’s Bell. “The sorts of thing BPEL is about -- say, a procedure involving sending documents out, receiving responses, scheduling a phone call, and then the next thing happens and so forth -- are at a totally different level than controlling a phone call in flight. There, the finite-state machine is crucial, and things have to happen with very low latency.”

Enter the telecom/network service broker
This means that what might be called a telecom service broker, or a network service broker, has to be able to handle both the network-level service interactions and also a range of higher-level service interactions that come from exposing the network to the SOA-type approach.

Essentially, the most basic telecom service broker handles event triggering (which calls up network-based capabilities and applications) and process the relevant service interaction logic via a programmable rules engine. But real products provide extensive protocol handling and mediation/conversion, and also advanced capabilities for handling dynamic service interactions, and the like. Frequently, capabilities extend to service management aspects such as charging, policy control, provisioning, and subscriber data.

Bell sees five key motives behind the current application of such devices:

In terms of technology standards, AppTrigger’s Fitzgerald puts current operator interest in telecom service brokers in the following order:

“The least amount of interest is in the IMS SCIM,” he says. “The challenge of the SCIM is that it is really complex and has a lot of functionality and intelligence that people are having a hard time defining. In terms of a functional versus physical architecture, often SCIM functionality is getting absorbed into the CSCF within the IMS architecture, making that more the core intelligent switch.”

Next Page: Vendors & Products

Table 1 gives a selection of vendors relevant to the telecom use of service brokers.

It’s clear that several different kinds of vendor are now involved to a greater or lesser degree with at least some aspects of service brokers. Most obviously, and the focus of this Who Makes What, are those that offer specialist pure-play telecom service brokers. These vendors offer a definite and explicit service-broker product for use within other vendors’ telecom network and service environments, and one that is very much geared to handling the network aspects (signaling, protocols, call flows, and the like) as well as service-logic aspects. They are indicated in Table 1 by the entry Explicit in the "Telecom Presentation" column.

A second group includes the vendors of core telecom networks or other comprehensive telecom offerings. Essentially, these vendors have -- or are developing -- converged service architectures for their NGNs, and so inevitably need a battery of service-broker functions to support this. From this perspective, the service broker capabilities often look more like a part of their next-gen SDP offering, residing either in the SDP itself or in the CSCF as part of the company’s IMS portfolio, although a definite service-broker product may be available. So Table 1 dubs the "Telecom Presentation" of these vendors as Implicit.

A third group includes vendors that are coming more from the software, IT services, and OSS side of the industry. Typically, these are focusing on next-gen SDPs, SOA, Web Services, service orchestration, and so on. As with the second group, a range of service-broker functions are involved, and they are also marked Implicit in Table 1.Table 1: Some Vendors Relevant to the Telecom Use of Service Brokers

Early Consolidation
Despite being such a new sector, pure-play telecom service brokers have already been involved in industry acquisitions during 2009 and early 2010.

In early February, Oracle Corp. (Nasdaq: ORCL) announced an agreement to acquire Convergin for an undisclosed sum. The deal is set to close during the first half of 2010. Oracle stated that Convergin's products will complement its integrated product suite, including its Billing and Revenue Management software, Converged Application Server, and service fulfillment applications.

In October 2009 jNetX was snapped up for $50 million by Amdocs, which cited the synergies from combining jNetX’s offerings with its own existing customer experience solutions and service-delivery capabilities. A key point for Amdocs was that many of its competitors in the SDP market supported next-generation services solely on IP-based networks, so there would be differentiation in extending the company’s capabilities to include legacy networks as well.

A few months earlier, in July, Aepona made a similar technology bolt-on by acquiring Valista, an Irish provider of payment, settlement, and service lifecycle management systems to mobile and broadband operators. The idea is to provide operators with an end-to-end solution for the Network as a Service (NaaS) business model, where network and informational assets are treated as marketable resources that can be made available to third-party application developers, upstream service providers, and enterprises. The offering now includes open APIs toward core network capabilities, third-party relationship management, monetization, billing mediation and settlement, and service-lifecycle management.

Next Page: Vendor Angles & Activities I

The last 18 months or so have seen a fair burst of product activity from service-broker-related vendors of all types. A brief survey includes:

AppTrigger
Released Version 11 of its Ignite Service Broker to support legacy applications such as TDM voice or SMS to any NGN architecture, including IMS and LTE. There is prepackaged interworking functionality to speed time to market, and an XML-based toolkit to allow self-sufficient service providers to extend functionality as needed.

Later, in November 2009, the company announced support for five additional interworking (IM-SSF) solutions within Ignite, bringing its total of predefined application interworking solutions to 17. These are Non-Geographical Number (NGN); Universal Access Number (UAN); Universal Personal Number (UPN); Reverse Charging; Blacklist with PrePaid; 800 Service/Freephone; Local Number Portability (LNP); Calling Name (CNAM); Premium Rate; Virtual Private Network (VPN); Televoting (Mass Calling); Wireless Prepaid; Calling Card (credit-based); Color Ring Back Tone or Caller Ring Back Tone (CRBT); Find Me/Follow Me; Privacy Service; and Network IVR.

Convergin
Claimed an industry first in September 2008 by supporting real-time charging mediation at the SCIM layer‚ thus allowing the delivery of and charging for blended services across legacy‚ NGN, and IMS networks. Any communication session from any network, mediated by the Accolade WCS, can be charged or rated in real time by any IMS-compliant Online Charging system, the company said.

IBM
Coming from the IP/Web side, the company announced WebSphere Message Broker V7.0 in October 2009, an engine for the company’s enterprise service bus (ESB) solution. Message Broker functions as a message and protocol switch that supports a range of transports, protocols, and data formats to enable intelligent applications and services to receive and generate data over an interconnected infrastructure. Enhancements included connectivity for service oriented architecture (SOA), extended publish-and-subscribe capability better integrated with WebSphere MQ, new nodes for Web 2.0, interoperability, message sequencing, and enhanced adapter nodes for SAP Software, Siebel Business Applications, and PeopleSoft Enterprise.

Mavenir Systems
Announced in October 2009 its Rich Communications solution. This, implemented on the mOne Convergence Platform, provides a variety of GSMA Rich Communication Suite (RCS)–compliant features, including instant messaging (IM), group messaging, presence-enabled contact list, and multimedia content sharing.

Starhome
Launched its Next-Generation Service Broker in September 2008. The ability to incorporate newly deployed IMS services, such as IP Centrex and SIP VOIP, was added to Starhome’s existing IN service brokerage capabilities. The new capabilities include the IMS 3GPP Service Capability Interaction Manager (SCIM) and the IP Multimedia - Service Switching Function (IM-SSF). Starhome says that the Next-Generation Service Broker combines the company’s IN/SIP expertise and the 3GPP SCIM IMS standards into a core network element that enables multiple services to work together. The result is an integrated solution enabling multiple services to all subscriber segments for CAMEL/INAP and IMS networks, and allowing the introduction of new IN and IMS services alongside existing services with minimal impact on the network, and no dependency on network vendors. All Starhome’s existing services -- such as voice mail tromboning elimination technology (Optimal Voicemail Deposit), Mobile2IP, Intelligent Call Assistant, Local Roaming Number, Prepaid Anywhere, and Mobile VPN -- make extensive use of the service broker capabilities in the field.

Tekelec
Launched its Next-Generation Eagle XG signaling and session control platform in February 2009. This works with the company’s existing Service Broker product, and is intended to allow operators to deploy hybrid NGNs while exploiting existing technology investments, and to provide a scalable migration to IMS or LTE networks. It supports a converged database that enables multiple core network applications, consolidating subscriber and network routing data and eliminating the need to manage, maintain, and update databases for each application. The SIP Signaling Router (SSR) overcomes the lack of core signaling and session control in softswitch-based NGNs by serving as a SIP proxy, bridging SIP- and SS7-based architectures to gain access to all routing information. With a software upgrade, the SSR also serves as a Call Session Control Function (CSCF) to provide SIP signaling and session control for subscribers accessing IMS services.

Next Page: Vendor Angles & Activities II

Three vendors with a sharp focus on the telecom/network aspects of service brokers are AppTrigger, OpenCloud, and Starhome. They illustrate some of the different nuances in vendor perceptions of these devices.AppTrigger
At the core of AppTrigger’s Ignite Service Broker is a softswitch, although not of a type that would be useful in, say, rolling out a VOIP service.

“Fundamentally, it’s a softswitch that sits between the application and control layers, and which manages the protocol and call-flow interworking,” says AppTrigger’s Fitzgerald. “There is a lot of intelligence in it, and it is highly flexible and programmable. So we do have Web APIs to add new applications -- the service logic can sit on top of it or in an application server -- but we believe the service broker is a network element.”

In other words, a telecom-oriented service broker needs to do a lot of network heavy lifting that just doesn’t occur in, say, Web Services/SDP-type of world, where the underlying network connectivity is largely taken as given.

As an example of this network orientation, AppTrigger currently sees two aspects to the use of service brokers in enabling prepay services. The first is with operators that are deploying initial IMS next-generation networks and want to extend an existing legacy-based prepay service into the next-gen network, rather than to buy a brand-new IMS application. This is straight service extension, and, as legacy prepay is a CAMEL-based application, it requires the service broker to handle the CAMEL-to-SIP interworking and the management of the various call flows (see Figure 3).

The second is to increase the capabilities of an existing legacy prepay network by enhancing trigger management, either to take advantage of existing applications or to add new ones. Essentially, the service broker is here acting as an intelligent box that manages the triggering and network interactions.

“The service broker is an amalgamation of predefined functionality that over the last three years has made sense to put into a centralized network element,” says Fitzgerald. “The IMS-SSF is pretty well defined by the 3GPP standards, and what the dedicated service-broker companies like AppTrigger have done is say that the IMS-SSF makes a lot of sense financially and economically, but needs to expand to encompass more and more protocols and more and more applications.”

This means extending the IMS-SSF beyond its initial bias toward CAMEL-based applications to embrace applications based on WIN, AIN, TCAP, and so on. AppTrigger has therefore extended Ignite’s capabilities in these directions.

This extension is part of an approach that Fitzgerald characterizes as “any-to-any” -- having an engine to take any existing application and connect it to any network, and to connect any new application to any legacy network. He contrasts this to the more conventional approach of ongoing customization to, say, IP enable an existing application.

“We describe this as the 90/10 rule, which is 90 percent of the product has to be predefined and ready to go, and 10 percent has to be configurable,” he says. “What we are competing against in the marketplace is the ad hoc customized solutions that are out there. But we think that the market is ripe for a real product to do that versus customization.”

OpenCloud
One area that OpenCloud is concentrating on is in-network mobile telecom services -- that is, services generated within, and depending on, the mobile operator’s own network.

“A lot of the attention of the telecoms world over the past few years has been about over-the-top value-added services -- content and what have you,” says OpenCloud’s Bell. “But the carrier isn’t really responsible for any of these, and now I think you are seeing carriers saying -- there is value that we can bring and we are the ones delivering messaging, voice and so on to our customers. And that is what customers are spending 90 percent of their money on.”

This means that the company sees mobility, convergence, and producing personalized services in the core network as central to the role of service brokers.

“We think the reason people have a handset, make calls, and so on is about communications -- person-to-person communications -- and we are working to make the service broker deliver innovation in that space,” he continues. “We think that telcos have been hamstrung in doing that because the gene pool of people who have been able to produce new services has been limited to the network equipment providers.”

In contrast, a service broker, by allowing multiple services and service elements from different technology generations to interwork and be concatenated into new services through GUI-based SCEs, will offer telcos scope for innovation and differentiation similar to that enjoyed by Web Services and their associated mashups.

Behind this approach is the view that the mobile world, where much of the world’s infrastructure is still less than a decade old, is now inherently multigenerational in its technology, and will remain so for a long time. A full move to IMS and 4G networks may take 15 to 20 years, and even today the vast bulk of customers are on 2/2.5G networks. So mobile operators, egged on by the recession, are now much more concerned with handling this ongoing 2/2.5/3/4G mix, incrementally enhancing it and innovating with what they already have.

One aspect of this that will become increasingly important, as next-generation mobile networks gradually spread, is where to locate certain key services. The IMS SCIM is concerned solely with providing the next-gen IP/IMS network with access to the TDM domain. So OpenCloud’s Rhino Service Broker has been developed to support a Reverse SCIM functionality as well, thereby allowing the legacy SS7 circuit-switched networks and their users to access services on the next-gen IP domain.

“You can compose a service that is a hybrid across both of those network boundaries and use some of the capabilities of both as you wish, and you would remain anchored in whatever network you are in,” says Bell. “A SCIM would anchor everything in the IMS domain, which means that you need to buy the capacity -- if a service always involves that, you would need to write the relevant capacity in IMS, even though you have no -- or few -- subscribers there yet.”

OpenCloud has adopted the term Service Interaction Server (SIS) to denote the wider application of the IMS SCIM concept to include the composition of new services by orchestrating the signaling and messages of IN SS7-based circuit-switched network technologies, IMS/SIP telecoms networks, and Web Services-based communication solutions. Rhino SIS runs on the OpenCloud Rhino Application Server, as shown in Figure 4, which provides an illustration of the layered functional structures now common in the service-broker environment.

Starhome
Starhome has come to service brokers from a background in providing mobile-operator services oriented mainly around roaming. The company’s Next Generation Service Broker product (see Figure 5) comprises a core engine that supports the basic IN and IMS core network component functionality, and a collection of core modules that enable the platform to support a wide range of capabilities (such as protocol conversion, subscriber information handling, flow management, session control, and parameter manipulation).

The design is intended to overcome the limitation of IN networks and to enhance IN capabilities to enable multiple trigger support for a single IN service event, such as a call, an SMS, and a data session. In addition, incorporating the SCIM, IM-SSF, and reverse IM-SSF capabilities allows the NG Service Broker to trigger SIP Application Servers on the same IN Trigger. The opposite (triggering IN services on the basis of a SIP INVITE) is also possible.

“We had been dealing with service brokers for at least five years as an internal component, but we didn’t externalize it as a product in the beginning,” says Starhome’s Aran. “We needed internally to be able to have the G-MSC double trigger or multi-trigger a call, which means having multiple SCPs handle the same call.”

The issue was that operators wanted to segment their roamers in different ways -- for example, prepaid roamers and VPN roamers -- while using Starhome’s roaming services, thus requiring the different SCPs handling roaming, prepaid, VPNs, and so on to interact with the Starhome service SCPs. This led to the company developing its own internal service-broker functionality, which was subsequently considerably enhanced as a specific product to be marketed externally. This involved supporting multiple protocol variants -- such as ETSI INAP, Siemens, Nokia, Ericsson, and 3GPP CAMEL -- and, in the latest release (November 2008), IMS 3GPP Service Capability Interaction Manager (SCIM) and the IP Multimedia - Service Switching Function (IM-SSF) -- as well as being able to interact with IP Centrex and SIP VOIP services.

Aran argues that the difficult, and key, part of service brokers is the handling of telephony because, in practice, the telephony world is very idiosyncratic -- there are very many standards and even more operator- and vendor-specific variations on them -- so that a lot of workarounds are needed to do basic things such as passing a parameter from one service to another.

Obvious consequences are that Starhome sees flexibility and the ability to translate and interwork a wide range of protocols and service data as key service-broker attributes, and the Service Broker development reflects this.

“We have a very strong protocol conversion engine operating between all protocols supported by the broker,” says Aran. “We have taken it further because, for example, the IMS standards define the IM-SSF to translate between CAP and SIP, but only in one direction. You need to evolve that capability to talk and translate between other protocols.”

Such developments mean that the Service Broker is offered also as an IMS SCIM, and Starhome is moving additionally toward Web Services by creating generic interfaces supporting XML data interchange among Web Services, IMS, and telephony services.

“For Web Services, the basic capability is there and we are moving forward with it,” says Aran.

And flexibility means that service brokers have to be very dynamic, and able to support changes in network flows, service order, and service behavior, for example, and, of course, the rapid introduction of new or modified services. Aran points out that, strictly, service coexistence could be handled by specific hardware alone, but that his would be massively complex, expensive, and inflexible. A major raison d’être of the service broker as a separate software-based product class is to avoid these problems by emphasizing flexibility.

This is further reflected in the way Starhome offers the Service Broker. It is available both as a managed outsourced service and as an operator-controlled standalone hardware/software product, depending on the operator’s preferences. Generally, Starhome sees the market dividing between mainly larger operators with the internal resources to be able to handle their own systems and service development, and mainly smaller operators that prefer or need to outsource them. In both cases, predefined, but modifiable, services are available from the company to speed or simplify new-service deployments.

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

Back to Page 1: Introduction