The Moriana Group
March 2010
Service Broker 1.0
Service Broker Operator
Guide
M O R I A N A
2M O R I A N A
M O R I A N A
Thought Leadership
White Papers
Section B
Thought Leadership
White Papers
M O R I A N A
M O R I A N A
3The Service Broker Forum
Service Broker Operator Guide
Understanding Service Brokers:
1. Market Need for Service Brokers 4
2. What Is A Service Broker? 5
IM-SSF Functionality...7
Reverse IM-SSF...8
IN to IN Trigger Management...9
Service Broker as a SCIM – Service Capability Interaction Management...12
Web 2.0 Gateway Functionality...13
Protocol/Call Flow Management...13
3. Summary 14
.
M O R I A N A
4M O R I A N A
1. Market Need for Service Brokers
As Communication Service Providers (CSPs) increasingly begin to engage their long planned next generation strategy they all have one aspect in common. They are faced with the mounting need to manage the convergence of their network layer in parallel with their services layer as it continues to grow. Historically, CSPs have been forced to replicate services across multiple net-work domains in order to ensure that all applications are available to all subscribers regardless of which network they are on. Next-gen application delivery needs the flexibility to interwork with yesterday’s, today’s and tomorrow’s networks and services. Over the past few years, multiple telecom infrastructure vendors have introduced unique disparate solutions to help bridge the converging network. However, this has resulted in a market approach which is very fragmented in regard to how these issues are being addressed and answers are being sought for the ques-tions that inevitably come up as networks and applicaques-tions converge:
1. What is the best way for a Service Provider to optimize multiple service platforms across converging networks to manage CAPEX and OPEX costs?
2. What is the best way to maximize multiple application resources across service platforms to create new service offerings and to maximize ARPU?
3. What is the best method to break the traditional silo service deployment model and move away from proprietary vendor lock-in?
Enter the need for a flexible, cost effective, efficient and future proof application to network con-nectivity solution…the Service Broker.
M O R I A N A
M O R I A N A
52. What Is A Service Broker?
CSPs looking to enhance services and retain subscribers have begun to consider the evolution to SIP/IP networks via NGN and IMS. Some have started that transition, others not quite yet; but most will agree that the transition will take place. This also means that CSP have found themselves in the position of supporting the current TDM networks longer than anticipated. And whether there are economic, technological or logistical reasons, or perhaps all of the above, the fact remains that this longer than anticipated transition will require the interworking of the current networks with the NGN/IMS networks for some years to come. The Service Broker is a next generation emerging network element that helps CSPs leverage existing services, launch and deploy new and manage interworking across their multiple network domains. At its foundation, the Service Broker provides the necessary network protocols, signaling and call-control to enable any service to interwork with any network. The Service Broker origin can be found in the 3GPP definition of the Service Capability Interaction Manager (SCIM). More recently it has been enhanced and expanded to deal with the various converging network and converging application challenges Tier 1 Service Providers are facing in light of the many challenges convergence creates. The expanded definition leverages the SCIM functionality but also includes additional functionality such as IM-SSF, Reverse IM-SSF and IN Trigger management all within a single stand-alone purpose-built Service Broker network element built to interact and provide any-to-any network to application connectivity.
In 2009, the founding members of the Service Broker Forum collaborated together to agree upon a standard definition for a typical Service Broker. A Service Broker is defined as a stand-alone network element that resides between the service layer and the converging network. The Service Broker decouples the core switch from the service execution or creation environment. The Service Broker product class is extending new and existing application reach while also interacting with data services management such as subscriber data and policy management elements. The result is an innovative alternative for protecting and leveraging an operator’s current network assets and application investments while also introducing new services over NGNs.
M O R I A N A
6M O R I A N A
The main key functionality provided by the Service Broker includes:• IM-SSF which allows legacy applications to be extended to NGN and IMS
• Reverse-IM-SSF which allows just as the name implies, next generation applications to be extended towards the legacy networks
• SCIM which is defined as SIP-based service interaction and orchestration
• IN/IN Trigger Management which is the ability of the Service Broker to extend and multi-ply IN triggers to multiple applications, thereby enabled the creating of IN-based service combinations
• Protocol / Call Flow Management for call model / protocol interworking which is how the Service Broker normalizes and interworks the different call models / protocols used by the underlying networks
Web 2.0 Gateway enables the IT development community to build applications for voice networks The next section of this report will go into further detail describing these key functions.
Service Brokers fit into the network, firmly placed between the application and control layers. The services layer is responsible for the service creation, management and execution services such as Voicemail, Prepaid, Ring back, Parental Controls, etc. In the application layer, different hosting platforms may be connected to the Service Broker: SCPs using CAMEL, IN Pro, SIP Ap-plication Servers, Large Apps, and Service Delivery Platforms.
Service Brokers provide all the necessary network Protocols, Signaling, and Media Call Control, required to enable any service to interwork across any network such as SS7, SIGTRAN, SIP, IN-based Protocols, and Call Control protocols like ISUP all running on industry standard server technology.
The Service Broker is then responsible for:
• Network Abstraction and Exposition by presenting APIs and connecting to Service Execu-tion and CreaExecu-tion environments
• Real-time charging interface providing key triggered charging events utilized by OSS/BSS for billing
• Database dips into the HLR/HSS to support new triggered applications and extract sub-scriber preferences
• State aware call / session control regardless of the different call models by providing all signaling interworking
• Signaling interworking, TDM to IP, IP to TDM
• Service blending and orchestration to host and execute service logic within it to be able to create those blended applications.
M O R I A N A
M O R I A N A
7Service Broker Resides Between the Services Layer and Control Layer
Following is a breakdown of each of the significant attributes of a Service Broker.
IM-SSF Functionality
During the evolving architecture of IMS, it was correctly determined that service providers would not be migrating to IMS networks in a clean, full cut. Instead, elements of the IMS architecture would be introduced to existing circuit switched networks allowing a gradual migration of sub-scribers and the related voice services. Since the IMS architecture is based on IP protocols there exists a need to interwork existing services with IMS and therefore a new functional entity was conceived: the IP Multimedia Service Switching Function or IM-SSF.
3GPP defines the IM-SSF as a “CAMEL functional entity that provides the interworking between SIP session control and the CAMEL state models. The IM SSF also provides the CAMEL interface to HSS for downloading the subscriber’s CAMEL Subscription Information data for IMS.”
Further exploring this definition, we find that the IM-SSF is really a type of SIP Application Server (SIP AS) that is connected to the control layer (S-CSCF) via SIP-ISC interface. This SIP AS pro-vides a gateway to legacy service networks that implement CAMEL services which are widely de-ployed in GSM networks. The IM-SSF acts as a gateway between SIP session control and CAMEL-based services hosted on SCPs, thus allowing CAMEL services to be invoked by IMS subscribers. From a service provider perspective this capability allows existing SCPs to deliver the same serv-ices regardless of subscriber technology and extends the useful life of a sizable investment. The goal of course, is to enable the utilization of both, existing applications and the new IMS network domain without requiring changes to either network and only provisioning required to redeploy those applications.
M O R I A N A
8M O R I A N A
At the core of the IM-SSF implementation is a finite state machine (FSM) that defines thedif-ferent states expected to be interworked between the network domains. How these FSMs are managed and modified to accommodate different service logic varies by implementation with XML scripting and Java-based programs as the most common options. In addition, the IM-SSF maintains connections to the HSS for registra-tion just like any other SIP-AS.
Beyond the strict 3GPP definition of the IM-SSF, the industry has embraced the concept and extended the capability of the IM-SSF beyond simply SIP-ISC to CAMEL interworking. IM-SSF may now include interworking of SIP to INAP and WIN, as well as concurrent implementations of multiple variations of those protocols. There are also implementations of the IM-SSF that go beyond signaling interworking to also include media handling or transcoding either on-board or off-board to accommodate applications that include media as part of the application; exam-ples include prepaid applications that may need to query subscribers for credit cards, etc.
Reverse IM-SSF
With the proliferation of next generation SIP-based applications, service providers are also find-ing that brfind-ingfind-ing the innovation found on IP to circuit switched networks can accelerate the transition to Next Generation and IMS. The need exists to implement the reverse functionality provided by the IM-SSF, namely a functional element to interwork IN-based protocols into SIP. 3GPP has not formally defined this role; however the industry has adopted the term Reverse IM-SSF or R-IM-SSF for a solution to this
need. The R-IM-SSF can be thought of as the opposite or reverse configuration of the IM-SSF, with SIP AS based applications con-nected via the R-IM-SSF to existing GSM MSC or PSTN switches.
The same considerations regarding FSMs, protocols and media handling of the IM-SSF apply here.
M O R I A N A
M O R I A N A
9IN to IN Trigger Management
SS7 Intelligent Network or IN telecommunication services are primarily concerned with sending and receiving messages in real-time. Their next action is determined by the message param-eters, accessing additional information very quickly (typically in a few milliseconds) and the occurrence of other real-world events. However, IN protocols are more than just a set of mes-sages that can be used or extended at will. Each IN protocol is a set of mesmes-sages and FSM that unambiguously define valid and invalid actions and responses. In addition, there are many dif-ferent SS7 IN protocols, with extensive message sets and difdif-ferent FSMs. As a consequence, the protocol handling and the service logic that comprise an IN service are completely intertwined. CSP consolidation, competitive sourcing of Service Control Points (SCPs) and IN services means that today’s mobile and fixed networks are comprised of a heterogeneous mixture of SCPs, IN services and IN protocols. This compounds the Service Broker challenge, bringing into play ven-dor platform, protocol and service differences and subtleties.
Service layer engineers have long needed to combine IN services to re-use existing service logic and to create new services. Modern MSCs / switches provide a pragmatic solution to this problem as they allow sequential trigger-ing of SCPs. This is known as “service chaintrigger-ing”. The core challenge is to work around the basic SS7 signaling system limitation that means only a single service can control a call. In the example illustrated here, the MSC triggers the first service (E.g. a VPN), then when it completes, triggers the second service (E.g. the prepaid charging platform).
Implementing service chaining is costly and introduces complexity into the service layer, how-ever. In addition to their own service logic, services have to be aware of the services that have been triggered before it is invoked and also those that may be triggered after.
Service chaining works for simple service interactions, but puts a great load on core network elements: the core network must trigger the service layer many times, using numbering plans to control how features interact.
By contrast, the IN function within a Service Broker – which sits in the signaling path between the MSC and SCPs – provides an elegant and efficient mechanism for defining and controlling many complex service chains. This means the MSC only triggers the service layer once and any additional IN triggering and associated logic is performed by the Service Broker. It also means that the CSP can treat the “composition” as a single service rather than as combination of dis-crete services strung together by trigger chaining.
M O R I A N A
10M O R I A N A
IN interaction within a Service Broker goes beyond service chaining, however. First, a ServiceBroker monitors services throughout their complete life-time and enforces the FSM rules of the protocol. So it is aware of the success or failure conditions that have occurred and can act ac-cordingly. For example, if a service releases a call, the Service Broker will ensure that the other services that are a part of the composition will not be invoked. As the Service Broker “sees” all the protocol messages that are passed between the switch and the SCP, it can “inject” logic into the workings of the service itself, while maintaining compliance with the demands of the FSMs. So it is not constrained to simple triggering of services together one after the other, essentially unchanged, as is the case with service chaining. This means that additional functionality can be invoked “mid call” within a service. This can be to record data, to trigger software in other domains such as the web and SIP or to invoke additional SS7/IN logic or services.
This is illustrated below.
More advanced IN protocols, such as CAMEL IV and various vendor-proprietary variants of INAP CS1 and CS2, have much more complex protocol FSMs as they allow multiple call legs. This means the interaction complexities become too great to compose services by service chaining. It also means that much more logic can be injected into a service midway through the service when a Service Broker is introduced.
Switch
Service
Broker
SCP
Switch FSM for Service A
Service A
SCP FSM for Service A SCP FSM for Service A
Service Broker Proxy FSM
Switch FSM for Service A Service Broker Proxy FSM Multiple messages Multiple messages
•Service selection logic & service chaining
•Adjust signalling messages •Inject additional service logic •Default behaviour
•Error handling
•Invocation of other applications and services
•Protocol conversion
Switch
Service
Broker
SCP
Switch FSM for Service A Switch FSM for Service A
Service A
SCP FSM for Service A Service A
SCP FSM for Service A SCP FSM for Service A
Service Broker Proxy FSM
SCP FSM for Service A Service Broker Proxy FSM
Switch FSM for Service A Service Broker Proxy FSM
Switch FSM for Service A Service Broker Proxy FSM Multiple messages Multiple messages
•Service selection logic & service chaining
•Adjust signalling messages •Inject additional service logic •Default behaviour
•Error handling
•Invocation of other applications and services
M O R I A N A
M O R I A N A
11Service Broker as a SCIM – Service Capability Interaction Management
The Service Capability Interaction Management (SCIM) is a new network element introduced by IMS standardized architecture for the purpose of orchestrating and streamlining the real time management of service delivery. Within the context of a Service Broker platform, a SCIM solu-tion enables the control and orchestrasolu-tion of service delivery from multiple applicasolu-tions platforms for each session or call. The SCIM delivers full compliancy with IMS standard methodologies of service interaction and orchestration, including support for standard filter criteria processing, as well as integration with IMS policy management, and on-line/off-line IMS charging functions. As a SCIM, Service Brokers go beyond the basic service composition through an extensive set of advanced service interaction and discrimination features, for both the IMS domain as well as legacy and IT/SOA domains. These capabilities may include comprehensive support for legacy telecom network technologies on both the application and switching/session control layers, ena-bling the delivery and interaction of services across both legacy and IMS telecom domains. Service orchestration within the IMS domain is based on a concept of application chaining, in which, for the delivery of multiple applications for a single session, the session is routed sequen-tially between multiple application servers, acting typically as back-to-back user agents (B2BUA) or as SIP proxies. Thus, a “chain” of services is created, through which the session is passed allowing each application platform to perform its role in its turn.
For this purpose, the SCIM is required to processes logic in real time which defines which applica-tion servers should be invoked and how several such applicaapplica-tions should interact, when applied for a specific call or session. This includes managing the per session interaction between CSCF/ Soft Switches, HSS, Online and Offline Charging Functions and the various application servers or IM-SSF/Reverse IM-SSF in the network. Service interaction is managed according to logic that may be stored in the HSS or other network repositories. This logic allows assigning each sub-scriber with his/her own unique service profile and service combination.
When integrated with the SOA / Web 2.0, SCIM capabilities can be extended through dynamic interaction with Web Services and external SOA service bus, delivering a comprehensive service layer evolution path to IMS and beyond.
Within the context of a Service Broker solution, SCIM provides service capability interaction management for services from different domains (legacy, NGN, IMS) and from different plat-forms. The SCIM takes a horizontal approach, when managing and orchestrating services from several domains and goes beyond standard IMS SCIM, when interacting with legacy services as well. As a Service Broker, the SCIM allows the introduction of multiple services for a single call, mobile or wireline, SIP or legacy. In this solution, the SCIM within a Service Broker acts as a service interaction control layer, allowing the delivery of services from different technologies and different domains towards unified service combinations, such that users can enjoy blended services delivered from multiple platforms whether IN or SIP based.
M O R I A N A
12M O R I A N A
Web 2.0 Gateway Functionality
The Service Broker’s location within the CSP network architecture also makes it an ideal can-didate to host APIs to expose the network (and application) capabilities to developers. Many network elements already in the CSP’s network already provide native C/C++ APIs, however the Service Broker is fairly unique in its capability to interact with several network domains concur-rently thereby presenting a common (abstracted) view of the network, and ensures that network evolution won’t render the APIs obsolete.
Internet-based applications (YouTube, LinkedIn, etc.) provide plenty of very accessible APIs (XML, SOAP, REST, etc.) that in turn has fostered developers to create mash-ups, or combined applications that re-utilize capabilities of other applications. With the exception of Google, most of these applications have lacked any integration into fixed and mobile voice networks.
Enabling the Service Broker with robust Web APIs delivers a Web 2.0 Gateway, which enables CSPs to offer a secure portal into their networks. CSPs are then able to market that access to internet developers who can create mash ups of traditional web applications that contain voice and other CSP-assets such as location and presence. Web 2.0 APIs may be vendor specific or based on standardized APIs such as 3GPP Parlay/X.
Examples of mash-ups utilizing Web Services include adding “click-to-call” functionality to cus-tomer service web sites, or adding automatic presence capabilities to a social networking site, so that users know whether a particular friend is available on his mobile. Another example includes adding SMS capability in social network sites where updates are automatically sent via SMS to a closed user group.
Protocol/Call Flow Management
In many circumstances a very high degree of control over the call flows and protocol messages is required to perform a particular service broking scenario:
• For example, it may be necessary to send CAMEL IDP message to an external SCP with the ServiceKey parameter different from the one received from the network level.
• Another example is an external SCP that provides the service logic in a non-standard way. • Consider for instance a “Bonus Service” application that allows free calls/SMS for the
eligible customers. When this application receives IDP message and determines that the originating subscriber is eligible for a free call/SMS, it responds with the CON message, otherwise it responds with the CONTINUE message. In this case the Service Broker should implement completely different scenarios depending on whether it has received CUE or CON response from the “Bonus Service” SCP. For example, the online charging platform needs to be triggered in the first case but may be omitted in the second case.
M O R I A N A
M O R I A N A
13 To be consistent with the above mentioned requirements, a typical Service Broker allows cus-tomization of the call flow logic and protocol messages in an arbitrary way. In particular, a Serv-ice Broker can:• Analyze the content of the received protocol messages and make decisions of how to han-dle the messages based on the analyzed results.
• Keep the context of the service interaction session, i.e. all the messages that have been sent and received before, and take this context into account as part of service brokering logic.
• Modify the parameters of the received protocol messages. • Generate and send new protocol messages.
• Usually this is achieved by providing “service brokering logic” blocks written in some pro-gramming language such as Java or via XML scripting as discussed previously.
3. Summary
For the most part, CSPs have embraced horizontal “IMS-like” architected networks as a solution to try to quickly and cost-effectively introduce innovative applications. However, CSPs are finding that to make this model work, they must also invest in infrastructure and applications that aren’t in line with that vision. As a result, CSPs spend tremendous time and money on new applications riding new networks with the potential promise of ARPU and market opportunity. However, these investments are risky and fail to address the potential of revenue-generating applications and services residing on existing networks. The real advantage of Service Brokers is their ability to enable CSPs to monetize the network by not only deploying new services, but leveraging existing application investments as well. Traditional application deployment models limit the opportunity to fully leverage this asset because of ongoing use of stand-alone proprietary solutions, applica-tion silos and continued network convergence. Service Brokers offer a soluapplica-tion that increases the reach of existing voice services and opens up NG network applications to a wider audience of existing subscribers on existing networks.
