& cplSiteName &

Who Makes What: Telecom Service Brokers

Light Reading

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:

    The Service Broker Product Category has developed over the past twenty-four months as a result of the evolving 3rd Generation Partnership Project (3GPP) interpretation of SCIM and the need to address operator’s [sic] requirements for a flexible, cost-effective, efficient and future proof application to network connectivity solution. This Service Broker solution efficiently manages network interactions by providing key features such as IM-SSF, SCIM, IN to IN Trigger Management, Protocol/Call Flow Management and Subscriber Data Management Interaction. This enables the rapid delivery of new and existing services across multiple networks.
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":

    In a next-gen network, services are separated from the switch and the core of the network into a service layer; they then execute in an SDP or an IMS application server. Invoking services in a next-gen network no longer appears to be the same as managing service triggers at the signaling layer in a legacy network. In an IN, there is no doubt that the network is in charge of invoking and controlling service interactions.

    There is considerable market confusion and "religious" argument, however, over whether, as a service broker, the IMS SCIM can coordinate both service invocations at network level and "application events" that need to be triggered in the service layer. Many believe that the IMS service brokering role must be split between the IMS S-CSCF and another application server-level mechanism. After three or more years that the SCIM has been around as a concept, there is still no agreement over which service interactions need to take place at the session control level and which need to take place in the service layer.
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

(2)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Tinniam V Ganesh
Tinniam V Ganesh,
User Rank: Light Beer
12/5/2012 | 4:40:51 PM
re: Who Makes What: Telecom Service Brokers

Using orchestration of SOA services with BPEL as a solution to traditional IN networks, protocols and frameworks sounds scary. I am not sure whether such a solution will be able to provide the stringent performance needs of the telecom networks.

User Rank: Light Beer
12/5/2012 | 4:38:26 PM
re: Who Makes What: Telecom Service Brokers
I fully agree with Ganesh's comment above. There is a big difference between orchestrating Business Processes (Web Services) in a SOA environment, using languages such as BPEL, and orchestrating IN (and IMS/SIP based) services. Service Brokering (telecom level), at some point in time, needs to access and manipulate stateful protocol messages/sessions (such as CAP, INAP or SIP based). Mapping these low-level protocol messages to WS operations and use some WS transport mechanisms + BPEL to orchestrate the services is extremely heavy (and time consuming for a time-critical environment). Even if it could work for a HelloWorld type of service interaction, it would not be appropriate for the majority of the existing IN/IMS services (like prepaid). Service Brokering (SCIM/IN Mediation) and IT Orchestration (BPEL-like) are complementing techno, not competing.
Featured Video
Flash Poll
Upcoming Live Events
March 12-14, 2019, Denver, Colorado
April 2, 2019, New York, New York
April 8, 2019, Las Vegas, Nevada
May 6, 2019, Denver, Colorado
May 6-8, 2019, Denver, Colorado
May 21, 2019, Nice, France
September 17-19, 2019, Dallas, Texas
October 1, 2019, New Orleans, Louisiana
October 10, 2019, New York, New York
November 5, 2019, London, England
December 3, 2019, New York, New York
December 3-5, 2019, Vienna, Austria
All Upcoming Live Events