Leveraging Service Brokers

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 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.

 

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.  

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 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. 

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. 

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: 

• 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

• 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.

 

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. 

 

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 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.

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. 

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.

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 1 –shows a representation of the Service Broker in place, with legacy applications interacting with the 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

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.

 

Get AppTrigger PDF White Paper and Service Broker Case Study here >>