Service Broker Operator Guide 2.0 by Prestige Media

Service Broker 2.0 Service Broker Operator Guide

Free Operator Guide The Moriana Group November 2010

Table of Contents Market Need for Service Brokers 5 What Is A Service Broker?

Summary 14

Globe Busines Case Executive Summary Challenges, Solution and Results at a Glance

The Business Problems 19 The overall Amdocs jNetX Solution 20 The Amdocs jNetX Service Composition / Blending

The Amdocs jNetX Protocols Conversion / Capabilities Exposure The Benefits to Globe

ABOUT Amdocs jNetX 27 About Amdocs

Amdocs jNetX Customer Evidence 28 Amdocs jNetX Market Offering Overview

Convergent Service Platform How It Helps

Proven Performance and Reliability 30 Communications Applications 31 Convergent Charging

Products and Services 35 Service Broker, Product Overview

Service Broker, Functional Overview 37

Leveraging Service Brokers to Extend the Reach of Existing Legacy and New IMS Applications 45 Navigating the Transition to IMS

The IMS Challenge of “old to new” and “new to old”

Examples of such services include: 48 The Service Broker and IMS

Extending the reach of Legacy Applications and IMS

Thought Leadership White Papers

MORIANA

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 network 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 questions that inevitably come up as networks and applications 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 connectivity solution…the Service Broker.

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 IMSSF, 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â&#x20AC;&#x2122;s current network assets and application investments while also introducing new services over NGNs.

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 multiply 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 Application 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 Execution and Creation 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 subscriber 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.

Service 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 subscribers 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 provides a gateway to legacy service networks that implement CAMEL services which are widely deployed in GSM networks. The IM-SSF acts as a gateway between SIP session control and CAMELbased 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 services 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.

At the core of the IM-SSF implementation is a finite state machine (FSM) that defines the different 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 registration 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; examples 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 finding that bringing 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 connected 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.

IN 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 parameters, 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 messages that can be used or extended at will. Each IN protocol is a set of messages and FSM that unambiguously define valid and invalid actions and responses. In addition, there are many different SS7 IN protocols, with extensive message sets and different 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 vendor 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 triggering of SCPs. This is known as “service chaining”. 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, however. 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 discrete services strung together by trigger chaining. This is illustrated below on the following page:

IN interaction within a Service Broker goes beyond service chaining, however. First, a Service Broker 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 accordingly. 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.

Switch

Switch FSM for Service A

Multiple messages

Service Broker

Multiple messages

• Service selection logic & service chaining Service Broker Proxy FSM Service Broker Proxy FSM • Adjust signalling messages • Inject additional service logic • Default behaviour • Error handling • Invocation of other applicationsSwitch FSM for Service A SCP FSM for Service A and services • Protocol conversion

SCP

Service A

SCP FSM for Service A

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.

Service 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 solution enables the control and orchestration of service delivery from multiple applications 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, enabling 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 sequentially 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 application servers should be invoked and how several such applications 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 subscriber 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 platforms. 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.

Web 2.0 Gateway Functionality The Service Broker’s location within the CSP network architecture also makes it an ideal candidate 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 concurrently 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 customer 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.

The call flows for both cases are illustrated in the diagram below that follows:

To be consistent with the above mentioned requirements, a typical Service Broker allows customization of the call flow logic and protocol messages in an arbitrary way. In particular, a Service Broker can: ••

Analyze the content of the received protocol messages and make decisions of how to handle 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 programming language such as Java or via XML scripting as discussed previously.

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, application silos and continued network convergence. Service Brokers offer a solution that increases the reach of existing voice services and opens up NG network applications to a wider audience of existing subscribers on existing networks.

Service Broker Forum members who contributed content to this Report:

Business Cases

AMDOCS | jNetX Customer and Business Case

MORIANA

Customer and Business Case Executive Summary Continually enhancing prepaid subscriber loyalty is a major business focus for premier telecom service provider Globe Telecom. Philippinesbased Globe wanted to reduce time to market for new services, increase service innovation, and to enhance prepaid loyalty. Overall, Globe wanted to increase business flexibility. A complex, siloed service architecture was hindering these goals and was also expensive to operate and maintain. Globe turned to Amdocs for help with a strategic transformation of its service layer to a common horizontal architecture [Service Delivery Framework (SDF)]. As part of the SDF deployment, Globe selected Amdocs jNetX Service Broker to deliver any service on any network to any user. Results include reducing time to market from months to weeks, a double-digit increase in ARPU, tripling take-up of broadband promotions, reducing operations costs, and cost avoidance of approximately $1 million U.S. by enhancing capacity with the Amdocs jNetX solution. Globe now benefits from Amdocs’ next-generation service delivery platform, a foundation that prepares Globe for future network evolution and places Globe in a strong competitive position in the Philippines market.

Company at a Glance • Globe Telecom, Inc. (Globe™) • Headquarters: Mandaluyong City, Metro Manila, Philippines • Major provider of telecommunications services in the Philippines • Web site: www.globe.com.ph • Stock Exchange: Philippine Stock Exchange (PSE) with ticker symbol GLO • Annual Service Revenues (2009): US $1.35 billion • Lines of Business: wireless, fixed-line, broadband • Number of Employees: 5,450 (as of June 30, 2010) • Number of Mobile Subscribers: approximately 24.6 million (as of June 30, 2010)

MORIANA

Challenges, Solution and Results at a Glance Challenges • Enhancing prepaid subscriber loyalty • Improving service innovation • Reducing time to market

Solution • Amdocs jNetX to help achieve a strategic transformation of the Globe service layer • Move away from proprietary systems and reduce operating expenses by deploying the standards-based, convergent Amdocs jNetX solution • Increase business agility by eliminating silos in service layer architecture with Amdocs jNetX • Implement Amdocs jNetX Service Broker to enable increased services, especially in the vital mobile broadband market • Globe is now able to: o Introduce any new service from any vendor/technology (IN, IMS or Web Services based) o Deliver these services to any Globe prepaid or postpaid subscriber o Develop and provide each service with an independent roadmap that does not impact the others

• Increased prepaid subscriber loyalty and customer satisfaction • Reduced time to market for new services to just weeks instead of months • Tripling take-up of broadband promotions • Cost avoidance of approximately $1 million U.S. by enhancing capacity with the Amdocs platform • Reduced internal costs for operations and maintenance • Double-digit increase in ARPU with increased service volume • Protected investment by leveraging legacy IN services while introducing new services • Enhanced competitive differentiation by enabling service innovation including the introduction of a wide range of mobile broadband services • Enabled potential new revenue streams with enhanced infrastructure flexibility

MORIANA

Results

The Business Problems “Our primary challenge was flexibility: we needed to be able to make innovative offers to our subscribers, especially in the prepaid broadband area that is one of the most popular service types in the Philippines today,” said Mario Domingo, Head of Product Design and Service Creation at Globe Telecom. With multiple inflexible, multi-vendor IN prepaid systems, it was not possible for Globe to quickly and cost-effectively introduce new features and services to its overall prepaid user base. Globe turned to Amdocs to help address this issue by deploying a new SDP solution including the Amdocs jNetX Service Broker.

Need to address prepaid loyalty With approximately 25 million mobile subscribers, Globe Telecom is the second largest mobile service provider in the Philippines. Prepaid penetration in the Philippines is one the highest in the world (approximately 98 percent), consequently, Globe Philippines subscribers’ base is almost exclusively prepaid. Prepaid users do not have contracts and, as such, have a low barrier to churn. They essentially follow the best prices, which can reduce ARPU. In order to counter churn and increase ARPU, Globe made a strategic plan to increase its service offerings to prepaid users.

Need to extend existing IN services’ lifespan Like many other service providers, Globe Telecom has built its service layer architecture over time, introducing, with each new silo, solutions for Voice, SMS, MMS, etc.

As a result, many silos/island applications have been developed over the years. This has created a complex system of IT and Network elements supporting specific business requirements, along with buried or unexposed capabilities of the underlying infrastructure.

MORIANA

Need to reduce high Operating Expenses (OPEX) Most of the legacy IN services installed in the Globe network were not flexible enough to enable service innovation and they were also far from cost-effective to maintain and to operate. These concerns motivated Globe to move away from a proprietary system to a standards-based convergent solution that could help reduce OPEX.

Need to enable SS7 to NGN convergence flexibility In addition to the high OPEX, most of the Globe legacy IN services did not handle any convergence across SS7 and Next Generation Networks, such as IMS or IP. As a consequence, it was not possible to use any existing IN services for new IMS customers or to combine any existing IN services with innovative IMS or WS services.

Need to reduce time to market

The overall Amdocs jNetX Solution “Our architectural infrastructure lacked the flexibility to generate new offers rapidly, and this was dangerous in a volatile broadband market,” Domingo explained. “We partnered with Amdocs to help us gain the agility to grab market share by attracting and retaining prepaid subscribers.” To address its challenges, Globe targeted a strategic transformation of its service layer, with the following clear goals:

MORIANA

Launching a new service was a long process, so that when the service was finally launched, it was often too late for the market. On average, nine weeks were required for Scoping, eight weeks for Business Case Validation and 18 weeks for Development and Testing. In total, an average of 35 weeks was needed, which was obviously too long.

• Reduce time-to-market for Globe services • Maximize use and re-use of existing capabilities Globe focused on creating a common horizontal architecture or Service Delivery Framework (SDF) from which it can provision, control and bill for all composite services, whether such services are created internally or by third-party application developers; thereby, offering customers a combination of services. Domingo stated that Amdocs’ strong reputations in the convergence and prepaid areas were major elements in choosing the Amdocs solution. “Amdocs is known globally for its strength in charging, rating, BSS and OSS solutions,” Domingo said. “In selecting the Amdocs jNetX solution here at Globe, we were very aware of Amdocs’ reputation for customer focus and innovative products.”

A full-blown SDF solution including Amdocs jNetX Service Broker A new Service Delivery Framework solution significantly reduces the amount of time it takes to develop and deploy new services and provide Globe with maximum re-use of existing systems. This SDF solution comprises the following two essential components. 1. A network layer composed of the Amdocs jNetX Service Broker, providing the Network Abstraction, Service Control and Service Brokering functionality, supporting SS7 based interaction (for the MSC, HLR and IN platforms) and a NextGeneration IP-based network.

2. An IT layer or Service Oriented Architecture (SOA) layer providing IP-based interactions for the Messaging Gateways, Location Servers and especially the Globe proprietary provisioning systems and provisioning interfaces for the prepaid and postpaid platforms. The SDF solution provides network abstraction, enabling it to deliver greater flexibility and rapid service creation through modular, reusable application programming interfaces, carrier-grade scalability and creation of a highly extensible architecture.

The Service Brokering solution In order to solve its main business challenge of increasing the loyalty of its prepaid subscribers, Globe is now offering an expanding range of new mobile broadband services to its entire prepaid customer base. New services including Community and Location services and Voice and SMS Bonuses are enabled by the deployment Amdocs jNetX Service Broker.

MORIANA

The Amdocs jNetX Service Composition / Blending

When a call requiring some particular intelligence is established, the MSC/Switch, responsible for routing this call, interrupts its call establishment and triggers, through an SSF (Service Switching Function) an Intelligent Network Application Server in order to know what to do with this call. This call establishment follows a model called BCSM (Basic Call State Model). This model is standardized, very well defined, rigid, and based on a complex state-machine. This model was not conceived to handle multiple IN application invocations per call establishment. As a result, traditional TEMs have developed some workarounds to allow several IN applications to be invoked during a single call establishment. One of these workarounds pertaining to the SSF enables the possibility of doing

MORIANA

For historical reasons, Globe was using two legacy IN Prepaid platforms from two different Telecommunication Equipment Manufacturers (TEMs). This meant that some prepaid subscribers were attached to a first legacy IN Prepaid platform, while others were attached to the second legacy IN Prepaid platform from a different vendor. Because of this multi-vendor IN environment, Globe was unable to combine IN services across its entire prepaid subscriber base before Amdocs jNetX Service Broker was deployed.

multiple triggering. However, with such a solution, only one IN application is able to control the call (i.e. being in interrupt mode), the other IN applications can only be notified (i.e. in notify mode). Furthermore, this solution is mono-protocol (for example, both IN and AS need to run on top of CAPv2). Another solution, developed by traditional TEMs, consists of combining applications that are running inside a single SCP by adding an initial small application script that jumps internally to the appropriate applications. Of course, such a solution only works for applications coming from the same TEM and running on a single SCP. This pushes service providers towards a vendor lock-in situation. As a result, and as mentioned above, for a long time, it was not possible to combine IN services in a multi-vendor environment. Obviously this limited service providersâ&#x20AC;&#x2122; capabilities to market new services by combining existing IN services. Using the Amdocs jNetX Service Broker, Globe has been able to immediately introduce new Location and Community services to all of its prepaid subscribers by supporting the service composition between the new applications and the two existing legacy IN Prepaid services.

In addition, always with the objective to retain prepaid subscribers, Globe is now offering Voice and SMS bonuses to its entire prepaid customer base. Globe has one IN platform from one vendor for Voice Bonus and another IN platform from a different vendor for SMS Bonus. Here again, the Amdocs jNetX Service Broker is used to handle the service composition between the various Bonus platforms and the two legacy IN Prepaid platforms, while enabling the offloading of the legacy IN Prepaid whenever possible. The following high level call flows elucidates this service composition or service blending:

MORIANA

1. A call is made. The Amdocs jNetX Service Broker decides which set of services to invoke for that call. 2. The Community Service is invoked first to check if the call is made within the community (special announcements, pricing, barring rules may apply). 3. The Bonus Service is then invoked to check whether or not the call can be allowed for free (with maximum call duration) 4. The call is allowed free of charge: 4a OR the call needs to be charged: 4b. 5. The charged call goes on.

The Amdocs jNetX Protocols Conversion / Capabilities Exposure

In addition to the Service Composition or Service Blending presented in the previous section, the Amdocs jNetX Service Broker offers unique protocol conversion and network capabilities exposure functions. The following figure highlights the main protocol conversion and network capabilities exposure used in the Globe project.

MORIANA

Initially deployed

Future deployment

Protocol Conversion • CAP X to CAP Y • CAP to INAP CS1x • INAP CS1x to CAP

Protocol Conversion • CAP/INAP to SIP (re-IM-SSF) • SIP to CAP/INAP (IM-SSF)

Network Capability Exposure • CAP to Web Services • INAP to Web Services • MAP to Web Services

Network Capability Exposure • Any Network protocol to Web Services

As the Amdocs jNetX Service Broker benefits from the convergent Amdocs jNetX technology, virtually all proprietary IN protocols are or can be supported by the Amdocs jNetX Service Broker. Amdocs jNetX has a proven track record in manipulating IN protocols from several IN vendors, and this vast experience is currently helping Globe to fully exploit its existing IN assets. Benefiting from the service composition, protocol conversion and network capability exposure from the Amdocs jNetX Service Broker, Globe is now able to differentiate its offerings from those of the competition by rapidly introducing a wide range of mobile broadband services. The Amdocs jNetX Service Broker represents a unique opportunity for service providers to fully re-use all of their legacy IN services, while harmonizing its respective service planes.

The Benefits to Globe As part of its new SDF deployment, Globe selected the Amdocs jNetX Service Broker to be able to deliver any service on any network to any user. Globe has succeeded in increasing its prepaid subscriber loyalty. In addition, Globe is now benefiting from Amdocs’ next-generation service delivery platform, improving service time to market and solving any network evolution challenges that Globe may face in the future.

MORIANA

Having deployed the Amdocs jNetX Service Broker, Globe has succeeded in first unlocking its service plane and has been able to achieve the following business objectives: • Introduce ANY new service from ANY vendor/technology (IN, IMS or Web Services based) • Deliver these services to ANY of its Prepaid or Postpaid users • Each service can have its own roadmap and does not impact on other services

1. Increase prepaid subscriber loyalty and customer satisfaction 2. Reduce time to market for new services to just weeks instead of months 3. Triple take-up of broadband promotions 4. Achive cost avoidance of approximately $1 million U.S. by enhancing capacity with the Amdocs platform 5. Reduce internal costs for operations and maintenance 6. Achieve a double-digit increase in ARPU with increased service volume 7. Protect its investment by leveraging legacy IN services while introducing new services 8. Enhance competitive differentiation by enabling service innovation especially in the market-critical area of mobile broadband services 9. Enable potential new revenue streams with enhanced infrastructure flexibility In conclusion, Amdocs jNetX Service Broker has succeeding in helping Globe retain its strong competitive position in the Philippines telecom market. “Amdocs really delivered on its promise of expertise, flexibility and speed,” Domingo stated. “From our initial meetings with Amdocs, we saw that their team was very knowledgeable about the issues we were facing and very committed to helping Globe address these challenges in a timely manner. When there were challenges during the project —including the difficulties of a multi-vendor environment — Amdocs swiftly acted on them. In addition, Amdocs’ continuing account management is excellent.”

MORIANA

Combined with Globe’s strategic promotional effort, the new Amdocs platform has helped Globe:

ABOUT Amdocs jNetX jNetX, acquired by Amdocs in October 2009, pioneered the use of Java-based technologies to become the leading provider of communications application server solutions for convergent network service environments. Amdocs jNetX provides an extensive portfolio of rich communications applications supported by an expert community of communications application development partners. Together with Amdocs Turbo Charging, Amdocs jNetX is the carrier-class service control point for Amdocs solutions for prepaid services. Over 35 of the world’s leading service providers use Amdocs jNetX solutions, including: •

Vodafone Group

•

Telefónica Group

•

mobilkom austria Group

•

British Telecom

•

Deutsche Telekom

•

SingTel Group (AIS, Globe, Optus)

•

eircom Group

About Amdocs Amdocs is the market leader in customer experience systems innovation. The company combines business and operational support systems, service delivery platforms, proven services, and deep industry expertise to enable service providers and their customers to do more in the connected world. Amdocs’ offerings help service providers explore new business models, differentiate through personalized customer experiences, and streamline operations. A global company with revenue of $2.86 billion in fiscal 2009, Amdocs has approximately 18,000 employees and serves customers in more than 60 countries worldwide. For more information, visit Amdocs at www.amdocs.com.

MORIANA

Products and Solutions

AMDOCS | jNetX Company Solutions and Offerings

MORIANA

Company Profile Amdocs acquired jNetX, the market leading provider of open service delivery environment for mission-critical applications, in October 2009. The Amdocs jNetX technology and its rich portfolio of applications (including Online Charging control), currently supports more than 35 leading service providers worldwide, including: • Vodafone Group • Telefónica Group • mobilkom austria group • British Telecom • Deutsche Telekom • SingTel Group (AIS, Globe, Optus) • eircom Group

Amdocs jNetX Customer Evidence

The Amdocs jNetX solution allows operating groups to achieve important savings by leveraging the hosting capabilities of the solution across the group. Services are developed once and deployed, and customized when necessary, in many affiliates. The following figure represents the Amdocs jNetX references around the world:

MORIANA

Amdocs jNetX Market Offering Overview Amdocs offers the industry’s first and most complete pre-integrated product portfolio spanning BSS, OSS and service delivery. Modular and flexible, the Amdocs product portfolio allows service providers to transform their businesses at lower risk and ensure a high return on investment. The Amdocs product portfolio encompasses the following domains:

The Amdocs jNetX market offerings are part of the following two domains: SERVICE DELIVERY • Part of the Convergent Service Platform • Part of the Communications Applications

REVENUE MANAGEMENT • With the Next-Gen SCP, part of the Convergent Charging solution The following chapters provide a high level introduction to the Amdocs jNetX-based market offerings.

Convergent Service Platform The Amdocs jNetX Convergent Service Platform extracts core network capabilities and exposes them as simple-to-use Java and Web services interfaces. These interfaces are used by the telecom and web developer communities to create missioncritical and web-enabled applications. Such a technology enables service providers to take control of their services roadmap and to deliver innovative and personalized applications. It provides the ultimate means to quickly react to market threats and opportunities.

MORIANA

How It Helps The Amdocs jNetX Convergent Service Platform addresses a number of the common problems found in the development of network services, including: • Intelligent Network Evolution: Provides the means to migrate inflexible, costly or end-of-life Intelligent Network (IN) legacy platforms into future-proof, open, programmable and carrier-grade solutions for smooth transition to next generation networks • SDP Evolution: Enables the transition from outdated, proprietary and vertical application servers (e.g. IN), into a horizontal, convergent, open and programmable service delivery environment

• Network Capabilities Exposure: Extracts trapped network capabilities (e.g. voice, messaging, presence, payment), exposing them as basic or composite Web services to developer communities and business verticals; encourages new business models.

Proven Performance and Reliability The Amdocs jNetX Convergent Service Platform meets Tier-1 service provider performance requirements for throughput and latency: • More than 18 million busy hour call attempts tested on a single cluster • Latency (10-20 ms) • High availability and reliability (5x9s).

MORIANA

• Network Service Composition: Makes any service (IN, IP Multimedia Subsystem (IMS), Web) or composition, (e.g. prepaid, with “Ring Back when Free”) available to any user (pre/postpaid, fixed, mobile, etc.)

Amdocs jNetX solutions are delivered with a complete set of platform maintenance and management facilities required for a carrier-class environment.

Communications Applications Amdocs jNetX Communications Applications constitute the largest portfolio of enduser communication applications available today that leverage network capabilities of fixed, mobile and convergent fixed-mobile networks. These applications run on the Amdocs jNetX Convergent Service Platform and are described in the 100+ Apps catalog that today counts more than 120 applications. Amdocs jNetX Communications Applications enable service providers to quickly increase their revenues and their customer satisfaction.

Valuable Applications within Your Network Applications are developed by Amdocs jNetX, ISV partners and service providers in half of the time, when compared to traditional network platforms. Its Java environments and intuitive tools are part of the Telecom Services Studio unlock Service development. Following are some sample applications: • Amdocs jNetX Personal Call Manager: A suite of incoming call management features handling voice, SMS, MMS and video calls, including blacklist screening, anonymous call screening, do not disturb with white list exceptions, and find me/ follow me, typically complemented with a device-based user interface to provide end-users with an intuitive method for interacting with the service.

• Amdocs jNetX Missed Call Completion: A set of call completion features, including ring back when free, notify when free, missed call alert, call hold/call queuing and direct divert to voicemail. These services run on both SS7 and IP/IMS environments. • Amdocs jNetX Conferencing: A web-enabled convergent audio and video conferencing service supporting mobile, wireline and VoIP participants. The RESTful service exposure allows many user-interfaces to be developed (such as Widgets, Web-interfaces, plug-ins to Web2.0 services, etc.). • Amdocs jNetX Charging Pack: A suite of charging-related services for prepaid users, including pay for me, call me back, credit transfer, wallet and spending limit. • Amdocs jNetX Multi-SIM: A service enabling mobile subscribers to use multiple SIM cards while keeping the same phone number.

MORIANA

Following are additional Communications Application examples from the Amdocs jNetX Applications Catalog: • Online Charging • Free Phone/Premium Numbers • Convergent VPN • V-PBX and Virtual Switch Board • Virtual Line • Prepaid/Postpaid Calling Card • Multi-Channel Tele-Voting • Local Number Portability • Least Cost Routing/Carrier Pre-Selection • Free Divert to Voice Mail

Don’t forget your developers and partners… In addition to providing the largest portfolio of Communications Applications available on the market, Amdocs jNetX also helps to address any specific customer needs using the Amdocs jNetX Service Creation Environment – called the Telecom Services Studio (TSS). This solution includes: • A graphical environment to drag and drop icons when designing new applications • A pure Java environment (the jTSS) for IT developers who prefer using plain Java rather than the icon-based environment • A Resource Adaptor SDK to integrate new protocols (IP or SS7 based) • A Web Services SDK to simply create new Web Services directly from the WSDL document • The Network emulation environments to test the newly designed applications.

In 2010, more than 70% of the worldwide subscriber base was prepaid and this continues to increase. As a result, service providers’ networks must be able to cope with potentially massive growth and, to keep their prepaid users, they need to offer them a rich suite of services.

Call Control, Lower Costs, Integration and More Services The Amdocs jNetX NextGen SCP (Service Control Point) is a real-time call and charging control system possessing the following key differentiators:

Protocol Support and Architecture for Charging Flexibility Amdocs jNetX NextGen SCP handles all online charging requests through its native support for all legacy SS7 protocols (INAP, CAP, MAP and those with proprietary ex-

MORIANA

Convergent Charging

tensions), all Diameter charging interfaces as well as Radius, SIP, vXMS MSCML and other proprietary protocols. Based on a proven architecture, Amdocs jNetX NextGen SCP handles real-time credit authorization and account deduction by triggering external rating and account balance management functions for any external Charging system.

Fully Convergent

The Amdocs jNetX NextGen SCP goes beyond the traditional and soon-to-be-obsolete “black box” prepaid IN service control points (SCPs) and brings convergence in following two key ways: • Network convergence by abstracting and integrating any network protocol from both wireless and wireline environments (from legacy SS7 to next-generation IMS networks). • Prepaid/postpaid convergence by simultaneously interfacing legacy IN prepaid and online charging capable Billing systems, such as Amdocs Convergent Charging or any existing incumbent systems. With such a solution, you can start creating prepaid/postpaid hybrid plans without having to migrate subscribers from one system to another.

More Communication Services Entirely based on the latest Java standards for the Communication and Media Industry, Amdocs jNetX NextGen SCP offers the possibility to deliver many additional applications to complement the pure standalone charging services. Examples of such applications include Pay for Me, Credit Transfer, Spending Limit, Wallets, Sponsored Calls and any many other applications. By deploying the Amdocs jNetX NextGen SCP, you are benefiting from the largest communications applications developers community available on the market today.

MORIANA

Integrate More Quickly with Multiple Charging Systems Coupled with the Amdocs Convergent Charging, service providers can quickly launch innovative applications while increasing revenues by using flexible bundling, pricing schemes as well as real-time cross-sell capabilities. In addition, Amdocs jNetX NextGen SCP can be integrated with the existing incumbent Charging system, protecting investments already made by complementing and leveraging the existing Charging systems. No costly migration is required to start leveraging the charging capabilities and to enable service innovation.

Proven Performance Reliability Amdocs jNetX NextGen SCP meets Tier-1 telecom operators’ performance requirements in terms of performance/throughput: • More than 18 million busy hour call attempts tested on a single cluster • Latency (10-20 ms) • High-availability and reliability (5x9’s).

Amdocs jNetX NextGen SCP is delivered with a fully featured set of platform maintenance and management facilities that makes it carrier class and production ready for the demanding telecom environment.

MORIANA

Products and Services After having introduced the overall Amdocs jNetX market offerings, we will now focus on one product from the Amdocs jNetX Convergent Service Platform market offering: the Amdocs jNetX Service Broker. Service Brokering, Orchestration, Composition, Interaction, and Mediation are terminologies that represent different things to different people. They all, nevertheless, referring to similar concepts, “to reuse existing and independent services and assets to deliver new feature rich services” and occasionally “to coordinate the execution of multiple service sessions in which an end user is engaged.” The concept of reusing and combining services is not new, however, it is becoming more critical for service providers to differentiate, innovate, and improve their revenues while reducing their cost and time to market. Customers are presently being offered a multitude of IN and soon, IMS and Internet-based services. Problems arise when these users want to subscribe to multiple services and tailor them to their own needs. This is a legitimate end user service personalization need. Unfortunately, it is currently not always technically feasible for a service provider to combine IN or IMS services into a single consistent service offering. This lack of flexibility reduces overall customer satisfaction, since customers are forced to choose between these different services. This choice also limits additional revenue sources for service providers. Amdocs jNetX Service Broker has been crafted in order to solve this problem. The solution allows IMS, Internet, and IN services (even from different vendors) to be combined efficiently, seamlessly and transparently in order to significantly improve both customer satisfaction and the service provider’s ARPU.

Service Broker, Product Overview There is a lack of standardization in the telecommunication industry when it comes to combining telecom services to deliver a final and consolidated experience to the end user, especially in the IN space, where most of today’s services run. As a result, many people have different understandings of terminologies (such as, Service Interaction, Service Composition, Service Chaining, Service Orchestration, SCIM, Service Sequencing, Service Brokering, and Service Mediation). Amdocs jNetX has more practical “know-how” and experience in the service broker domain than any other supplier today. The Amdocs jNetX Service Broker enables end users to decide which set of applications they want to use. As an example, prepaid users are now free to subscribe simultaneously to additional services such as Ring Back Tone, Personal Call Management, Parental control, Ring Back When Free, VPN and so on.

MORIANA

The Amdocs jNetX Service Broker breaks the technical barriers that prevent multiple services from multiple vendors to be simultaneously subscribed and delivered to the end user. The result is increased revenues for service providers, reduced cost and considerably improved time to market. The Amdocs jNetX Service Broker enables service interaction between a combination of independent: • IN services or features (IN Mediation) • SIP/IMS services or features (SCIM) • Internet/Web Services

In addition, the Amdocs jNetX Service Broker utilizes the Amdocs jNetX convergent technology, enabling the following: • The Amdocs jNetX Service Broker can simultaneously communicate with Online or Offline Charging Systems (e.g. over Diameter Ro and Rf), with User Data Repositories (e.g. over Diameter Sh, Radius and LDAP) or with any other network elements that are required.

MORIANA

The Amdocs jNetX Service Broker is used to consolidate, in real-time, the interaction of services that are running within the Amdocs jNetX Service Broker and/or outside of it (external applications servers). When external applications or features are involved, the Amdocs jNetX Service Broker takes care of the appropriate protocol conversion. As a consequence, service providers can reuse their legacy IN applications in an IMS environment and vice versa and easily bridge IN and IMS services together with Web Services and/or SOA.

• The Amdocs jNetX Service Broker can simultaneously host any and all communications applications. Amdocs jNetX offers a large portfolio of commercial-off-the-shelf (COTS) communications applications that provide rich communications services, but at the same time enable services providers to replace their existing legacy IN applications (such as VPN, NTS, etc.) that are well on their way to reaching their respective end of life. • Finally, the Amdocs jNetX Service Broker can easily evolve to an Amdocs Prepaid solution or to an Amdocs Convergent Charging solution. The overall goal is to facilitate a smooth replacement of costly and inflexible legacy IN prepaid systems with the new generation of Amdocs Prepaid or Amdocs Convergent Charging systems. Many service providers that are currently using the Amdocs jNetX Service Broker started by combining IN or SIP services together with their existing and legacy Prepaid IN.

Service Broker, Functional Overview

Amdocs jNetX, together with a number of partners and major service providers’ R&D departments, have invested a great deal of research and engineering efforts in consolidating all of these approaches/definitions and have come to the conclusion that only four main functions are necessary to fulfill the basic principle of combining independent telecom services/applications into one. This basic principle is described by Amdocs jNetX under the “service brokering” terminology and includes the following four sub-functions: Service Selection, Service Interaction, Service Composition and Protocol Conversion.

MORIANA

Service Selection Service Selection is the function that decides which service logic(s)/application(s) should be invoked for a given initial network trigger (for example, an INAP InitialDP or an IMS SIP INVITE). Service Selection transmits information about the initial trigger to the Rule Engine, which in return, indicates which service(s) will be involved.

• If more than one service logic (either on-board or off-board) is interested in handling the initial trigger, the Rule Engine returns a Service Interaction Rule Set to be executed by the Service Interaction function or provides the control to Amdocs jNetX Application Router (JSR 289) that will handle the Service Interaction according to the SIP rules for the given SIP request. The Service Selection Rules are provisioned in the Rule Engine using the Amdocs jNetX Management Console.

MORIANA

• If only one service logic/application is interested in handling this network trigger, then the initial request is delivered to the appropriate service logic. This logic can be deployed within the Amdocs jNetX Service Broker (i.e. as an on-board service) or can be executed outside of the Amdocs jNetX Service Broker (i.e. as an off-board service). If a protocol conversion is required, then the service selection transmits the information to the protocol conversion function to be delivered to the appropriate service logic.

Service Interaction After the Service Selection function has been executed, the Service Interaction function executes several Service Interaction Rules provided by the Rule Engine.

A Service Interaction Rule Set (SIRS) defines the way each protocol message should be processed, and is used when more than one service logic needs to be invoked, each of them having a direct impact on the call/session control. The SIRS allows multiple services to be invoked (both on-board and off-board) from a single trigger, to arbitrate between them in case of conflict, to modify any single message, and to consolidate answers before sending a message back to the network.

When the JSR289 Application Router is configured to be used for SIP, then Amdocs jNetX Application Router takes over the Service Interaction session and executes the SIP Rules provisioned for the routing of the given SIP request. In addition to regular services, Service Interaction can trigger both the Protocol Conversion function and the Service Composition function, all within a single interaction session. The Service Interaction function, the Protocol Conversion function and the Service Composition function can all access external directories to retrieve the subscriber profiles sometimes needed to perform the associated function. SIRS (and SIP rules in cases where the JSR 289 Application Router is used) are provisioned in the Rule Engine using the Amdocs jNetX Management Console. The same principle applies to both IN and IMS/SIP based interactions.

MORIANA

Service Composition

Following is an example with a Prepaid Logic, a Location Service, a Rating Information Service and a Bonus & Promotion Service. A marketing campaign requires that, when an end-user makes a total of one hour of call while calling someone located in the user’s town, the user receives five free SMS messages as a Bonus. So, when this user initiates a call, the Service Selection Function transmits the information to the Service Composition function, which starts by invoking the Location Service to get the called party’s location (ascertaining if this party is in the same town). This Location Service is totally independent of the call/session and does not have a direct impact on the call management. The Prepaid Logic may also retrieve Rating Information from a standalone service (over Diameter interface for example) and at the end of the call the Prepaid Logic invokes the Bonus & Promotion Service to report the call duration. Bonus & Promotion is a totally independent service, invoked by many other services besides the Prepaid Logic. Another example could be a service where an incoming call (based on SIP, for example) would automatically pause the video-on-demand that the called party is watching. When the SIP INVITE triggers the call control application, a Web Service request is sent to a video streamer to pause the video until the call ends. At the end of the monitored call, the video resumes.

MORIANA

Service Composition is used when several service logics are involved in a call or a session, but only one of the services involved has direct control over the call/session.

Protocol Conversion A Protocol Conversion function is required whenever the external application servers involved (e.g. SCP, SIP AS, WS AS, and so on) are based on protocols different from the one of the initial trigger. For example, if the Amdocs jNetX Service Broker is triggered by a CAPv3 Initial Request (i.e. an IDP), some external application servers must participate in the service delivery, however they are based on protocols such as INAP CS1, SIP or WS/Parlay X. It is not possible to perform service Interaction directly over different protocols. Service interaction is, in fact, mono-protocol in the sense that the Service Interaction rules are applied to the protocol by which the user session was triggered; hence usage of other protocols by other services is transparent to the Service Interaction function. Indeed, the Protocol Conversion function hides the different protocols to the Service Interaction function. For example, if two applications, one SIP-based and one INAP-based, need to collaborate, then the Service Interaction will apply to either SIP or INAP, depending on the nature of the initial trigger and the corresponding SIP-to-INAP or INAP-to-SIP conversion will be performed by the Protocol Conversion function. Rule Engine The Rule Engine is the place where Service Selection Rules and Service Interaction Rule Sets (including SIP rules for the SIP Application Router) are stored.

Service Selection Rules For Service Selection, a rule is made of a Condition and an Action. A Condition is a criterion which is applicable to the type of the initial request, to the parameters of the initial request and to the user profile data. The Action is executed if the outcome of the set of conditions is TRUE. An action assigns the Service Name or Service Interaction Rule Set to be executed to the initial request.

Service Interaction Rule Set For Service Interaction, Service Interaction Rule Sets (SIRS) are used. For this, the Rule Engine works with the concept of Endpoints and Messages. An Endpoint is an identifier of a Service or the Network End (stack). A Message is the name of any protocol message that can be sent and received by the entities represented by the Endpoints. For example, when a SIRS has been identified by Service Selection, the following three procedures are conducted for every message received by the Service Interaction Function: â&#x20AC;˘ Find, in the SIRS, the rule that matches the message and the originating Endpoint.

MORIANA

• Define the new Message to be sent, apply modifications (if any) specified by current rule. • Specify the new Endpoint (i.e. other service or stack) to which the new Message should be sent in the next step based on the rule found. The Rule Engine mechanism allows the Service Interaction function to provide the following main features:

• Triggering of different services based on a single TDP, SK and so on. • Integration of external services supplied by third parties in a service chain, enabling each service to operate as if it were the only one handling that specific call. • Passing some extra information between the services involved in the chain (for example, FCI information that was set by one service can be accessed by other services). • Consolidating responses (e.g. ACH, RRB, ERB, and so on) and distributing only the required information to the necessary services.

MORIANA

Leveraging Service Brokers to Extend the Reach of Existing Legacy and New IMS Applications

AppTrigger Wally Beck Sr. Director of Marketing

MORIANA

White Pa p e r :

Today’s economic reality of cost constraints, consumer unrest and ever tightening budgets has intensified an already significant challenge within the Service Provider community. Many Service Providers have major IMS deployment initiatives underway, while the idea of IMS has done an excellent job of creating a foundation on which new feature rich applications can be built, the revenue–generating, table-stakes applications of the legacy network are commonly overlooked. The ability to leverage those existing services within an IMS environment can be viewed as a critical factor in the initial as well as ongoing success of IMS build outs and the overall go forward network strategy for Service Providers.

MORIANA

Abstract

M o r i a n a S e r v i c e Broker 2.0 Operator Guide

Navigating the Transition to IMS The search is on within the Service Provider community for a solution that can address the challenge of and provide the opportunity for leveraging existing, proven applications and network assets across IMS infrastructure. This white paper examines the state of IMS and how the Service Broker can enable a cost effective, future proof answer to the question of how best to navigate the transition to IMS.

Service Providers face a number of issues as they continue to struggle with ways to enable efficient, effective and timely application introduction. The challenge is not a new one. Tried and true application connectivity models for TDM/IN networks tend to utilize a “siloed” approach in which applications are individually configured and connected into networks. This can be seen in standalone voice applications as well as within large SCP based IN services. While the approach worked it came with a variety of issues (or challenges) for the Service Providers as they looked to enhance or adapt the application to the underlying network change and evolution. The promise of IMS is fundamentally the move to IP platforms which will allow Service Providers to achieve new revenue protection and growth while simultaneously reducing infrastructure cost. While the architecture may be complex and evolving, the motivation is simple: enable the Service Provider to rapidly deploy services that improve the user experience and open the network to create and foster an ecosystem of application developers to generate additional ARPU. Aggressive competition in a struggling world economy and an increase in consumer choice make time-to-revenue a critical competitive differentiator and SPs are quickly turning to IP-based solutions in order to deliver an improved user experience with services like Voice over IP and IPTV. Beyond time to revenue and application benefits, the migration into IMS can deliver CAPEX and OPEX savings. IMS streamlines back office systems, integrates two to three networks into one, and largely aims to standardize not only network elements but the networks themselves, easing inter-operator connectivity. The efficiencies promised by IMS and the associated rapid application deployment are key to Service Provider success, however the transition to an IMS network in today’s cost constrained environment is challenging. Hence, it is necessary for SPs to maintain and reuse existing applications and infrastructure in creative ways to maximize their existing customer base and revenues. In short, replacing non-IMS applications to comply with an IP structure makes little sense if there’s no additional revenue to be generated. To compound the problem, IMS makes little provision to allow legacy applications access to IMS elements directly; the net effect being that major IMS roll outs are delayed pending positive business cases.

The IMS Challenge of “old to new” and “new to old” As Service Providers continue to pursue the ideal application deployment environment via NGN and IMS build outs they are faced with realities that pose inherent risks

MORIANA

White Pa p e r :

regarding both new and existing applications. The reality is that while the Service Provider’s vision is to move to an efficient NGN environment where IMS provides the solution to fast, efficient application management, SPs and the market are not there yet. At this stage the majority of a Service Provider’s customers and the associated application revenue reside on established IN networks and the applications within them. Services such as traditional voice centric IN based apps like toll free and ring back tones as well as large voice mail services are the heart of existing ARPU streams and critical to maintaining ongoing revenue and customer usage goals. The risks facing the Service Providers are many when considering the market share, revenue and costs associated with their existing applications and their plans for new application introduction. From a revenue perspective Service Providers are faced with: • Lost ARPU from both old and new applications • Missed market opportunity • Increased risk of churn as customers are moved from known services and networks to unfamiliar ones With each application deployed (existing or new) there are inherent inefficiencies • The existing deployment process is slow and therefore negativity impacts ROI • Inefficiencies in porting existing IN apps to NGN/IMS networks and leveraging new apps to existing networks increases costs • There is an inherent complexity in transitioning each service. There is no “standard” process.

The challenge during this transition of old to new and new to old…is how to best minimize the risk and maximize the benefit of their existing applications while building and enabling the promise of new application innovation and markets via IMS. The future of application introduction is one in which applications can be introduced quickly and cost effectively with minimal risk to current and future revenue streams. IMS is the next step along the road to this vision. But reality tells us that in the majority of cases this is still a future vision, not current state. In order to address this current need, a solution has been introduced to the market in the form of the Service Broker. Service Brokers manage network connectivity for currently deployed applications, taking full advantage of a deployed infrastructure and applications, while also adhering to IMS architectural entities and easing the

MORIANA

Each of these issues contributes in its own way to the slow growth, high cost and overall slow transition and introduction of innovation within the Service Provider market place.

M o r i a n a S e r v i c e Broker 2.0 Operator Guide

migration into IMS. Service Brokers provide the service operator a true migration plan to IMS while fully leveraging existing revenue generating applications, existing infrastructure and post investments (CAPEX) and preventing IMS from becoming another network silo.

Application Delivery within an IMS Environment There is much speculation on when a full IMS network and applications will be completed. To date the industry at large believes that IMS will be a gradual build out over the next 10 years. “Carriers must come to grips with the fact that IMS is too costly and complex to adopt in a wholesale manner and that the architecture will be adopted over the next few years in an incremental fashion.” * From an architectural point of view, the IMS architecture merges applications with the capabilities of the Internet to address both wireless and wireline telephony. It also aims to deliver fixed-mobile convergence and other 3G/4G applications: a true multimedia experience incorporating voice and data (video, etc.) across all sorts of devices including mobile phones, computers, PDAs, etc. In order to deliver this vision, functional entities that comprise the overall architecture of IMS are documented. Each entity may or may not be a discrete product, but the functionality delivered by these building blocks is such, that in theory, interoperability is not a concern. Figure 1 depicts the overall IMS architecture (as conceived by 3GPP). Figure 1

IMS Overview

MORIANA

White Pa p e r :

The key application delivery entity in IMS is the IP-based application server (AS), which hosts and executes services, and interfaces with the network using the Session Initiation Protocol (SIP). The aim of the AS is to allow third party providers an easy integration and deployment of their value added services into the IMS infrastructure.

Examples of such services include:

The 3GPP standards body has identified three distinct types of AS, each with a specific role: • SIP AS: This is the native IMS application server, hosting value added services and triggered by the S-CSCF. The SIP AS utilizes resources such as the Home Subscriber Server (HSS) or User Profile Server Function (UPSF) to store and lookup the identities and information used in calls and sessions made by subscribers. These new IP-based application servers face the challenge of connecting to the existing wireline and wireless networks, which by design, are still TDM based. • OSA-SCS: an Open Service Access - Service Capability Server interfaces with application servers using OSA/Parlay API. As such, SCS is not truly a server as much as a gateway; however, from the S-CSCF point of view, applications reside at the SCS. SCSs allow application servers to view and gain access to IMS and legacy wireline and wireless networks. SCS provide a level of network abstraction by exposing the network via an API known as OSA/Parlay API. The SCS allows current service subscribers, which are on legacy wireline and wireless networks, to access the new IMS applications. This conversion function is critical to ensure the business cases for IMS remain viable by allowing coexistence of IMS and legacy wireline and wireless infrastructure. • IM-SSF: The IM-SSF is another gateway server. In this case, the IM-SSF provides networking between IMS and a CAMEL service environment by bridging SIP-ISC and CAP protocols. As with the OSA-SCS, from the S-CSCF point of view, it is an application server; in this case, with access to an IN network. A challenge not currently addressed is how to migrate to new IMS-based services while allowing the current applications to integrate with the new architecture. The IMS framework expects the application servers to replace existing TDM and legacy applications. It is this required migration that presents a unique opportunity for solutions that manage to bridge the gap between the feature rich, tried and true “legacy” applications and the IP core of IMS.

MORIANA

• Call waiting, Call holding, Push to talk, Call forwarding, Call transfer • Call blocking services, Malicious Caller Identification • Announcement and Conference call services • Voicemail, Text-to-speech, Speech-to-text • Location based services • Messaging, SMS, MMS • Presence information, Instant messaging, Find Me / Follow Me

M o r i a n a S e r v i c e Broker 2.0 Operator Guide

The Service Broker and IMS In an IMS deployment, a Service Broker delivers capabilities of the IM-SSF, SCIM, and OSASCS, to applications utilizing the Service Broker framework. It’s important to note that while the Service Broker may become all of these elements under one product, much as it already is in the TDM/VoIP arena, the focus remains on application deployment and delivery. From the point of view of the application, a media resource is just that, regardless of whether it’s located in the IMS domain or in the legacy network. A typical Service Broker will provide the right blend of traditional network elements, brought together under a single manageable product, to facilitate rapid application deployment and extended application reach across diverse networks, including IMS. The aim is to provide feature transparency to subscribers, regardless of the network employed. This is accomplished by providing an abstracted view of the network to the applications. The Service Broker delivers rich call control via an application-aware switch, media gateway, media server, trans-coding, signaling gateway, and protocol conversion, all under API control. A functional diagram of the Service Broker software is shown in Figure 3. The framework includes traditional IN and TDM protocols, plus VoIP, such as SIP and H.323. Figure 2

Service Broker Architecture

Application developers may utilize a number of available APIs to signal and control the behavior of the Service Broker and therefore bring innovative functions to their applications. Capabilities such as system partitioning, service arbitration and application policing allow centrally maintained network connectivity, regardless of the number of applications served by the Service Broker. A key enabler of the Service Broker is its ability to abstract and normalize the network, regardless of whether it is wireline, wireless, SIP, IMS, etc., and present

MORIANA

White Pa p e r :

this view via a number of available APIs. This has the effect of shielding the developer from the network and allowing for application portability between different networks. In addition, as long as the API remains constant or backwards compatible, new networks (i.e. IMS) may be abstracted by the Service Broker. The application remains unchanged and if so desired, unaware of network changes and provides a consistent interface to the user, regardless of network access.

Extending the reach of Legacy Applications and IMS A challenge not currently addressed is how to migrate to new IMS-based services while allowing the current applications to integrate with the new evolving architecture. The IMS framework expects the application servers to replace existing TDM and legacy applications. It is this required migration that presents a unique opportunity for solutions that manage to bridge the gap between the feature rich, tried and true “legacy” applications and the IP core of IMS. Service Brokers solve this critical need in the IMS architecture by allowing new IMS subscribers (those new subscribers added via SIP and SIP-enabled infrastructure) to access legacy applications, and therefore extend the useful life and associated revenue generation already in place by those applications.

A new IMS element within the Service Broker is designed to enable legacy applications to function in an IMS world, and therefore, bring feature transparency across the entire subscriber population. As subscribers are migrated from one network to the next generation network, their experience (revenue generating subscriptions) remains constant. In order to accomplish this, this new element emulates and translates function calls that would normally be answered by IN-enabled devices (those speaking INAP, MAP, WIN, etc.) by presenting appropriate IMS-based calls. This new IMS element is basically a “reverse” IM-SSF. Figure 3 –shows a representation of the Service Broker in place, with legacy applications interacting with the IMS.

MORIANA

While the IM-SFF was created as a mechanism to allow SIP AS and the S-CSCF to access CAMEL IN, the many other services and applications that depend on INAP, MAP, WIN and other mechanisms are not addressed. Viewed another way, by connecting all the current applications, the operator may continue to receive revenue from platforms that are not only proven, but potentially already fully capitalized. As a result, revenue opportunities from existing applications and network assets are extended.

M o r i a n a S e r v i c e Broker 2.0 Operator Guide

Figure 3 Service Broker Supporting Legacy Applications into IMS

The net effect is that legacy applications are able to work within the IMS network without the need to modify or rewrite them. The applications interact with the abstracted network using their current APIs, whether it’s C++, CCXML/VXML, or SIP 3PCC; other proprietary APIs may also be supported via dedicated API connectors. Those applications continue to utilize network protocols they were originally designed to utilize so there’s no requirement to rewrite and retest and ultimately redeploy existing applications. As an example, take an existing application that may have to execute a lookup against an HLR. With the Service Broker in place, the application believes that the IMS equivalent to an HLR, the HSS, is an active HLR and the Service Broker would do the appropriate translations between MAP and Diameter, and maintain session control and states to ensure the entire transaction is seamless. The capability of the Service Broker to support these current applications means that the Service Provider: • Saves valuable time and OPEX by redeploying current, tested applications on the new IMS network • Enjoys CAPEX savings by extending the useful life of existing applications and avoiding “reinventing the wheel” • Reduces churn by providing subscribers with familiar applications and eliminating the learning curve of replacement applications • May extend features (feature transparency) across into the IMS network, thus ensuring subscribers enjoy a richer experience AppTrigger introduced its Service Broker solution, the Ignite™ Service Broker, to meet these needs of providing efficient and cost-effective application connectivity for tier 1 service providers worldwide. The AppTrigger Service Broker resides at the application layer and sits between the application layer and the core network to provide interworking and manage connectivity to the evolving network. The Ignite Service Broker is able to connect any application to any user by incorporating a number of open standard APIs and is purpose built to deliver signaling, media and feature in-

MORIANA

White Pa p e r :

terworking between disparate networks that converged and consolidated applications require. The Ignite Service Broker solution leverages these capabilities to allow Service Providers to preserve their investment in current revenue-producing applications by enabling inter-working with next-generation network build-outs. This enables service providers the ability to re-purpose today’s profitable legacy applications with their new IMS networks as well as to maximize investment and reduce risk in the deployment of new IMS based applications with legacy IN/TDM networks.

Summary It will take several more years for the IMS vision to become fully realized. Early implementations of IMS are being installed today but there is a clear need to marry those with the existing revenue generation applications and networks of today. Those service providers that successfully transition to the IP world of IMS, without losing revenue in the process, will ensure a continued returned on their investment.

Service Brokers represents an innovative, pragmatic approach for Service Providers in their quest to move down the path to IMS by extending application reach and achieving higher ARPU for new and legacy apps in a cost effective manner. As networks evolve into true IMS, the Service Broker’s functionality fills an important role by providing cross network compatibility and application reach for revenue generating services. These innovative capabilities provide Service Providers with the means to maximize the potential within their existing applications and networks, insulate their legacy investments and prepare to embrace the future of IMS.

MORIANA