I have been analyzing the Service Broker market for some time as part of the Analysys Mason Service Delivery Platform Strategies research module that I lead. And I can say that the number of service broker deployments has increased significantly in the past 12 months. In order to understand these deployments, I recently talked to a major European operator about its service broker deployment.

A key requirement was to be able to bridge between the legacy networks and the next-generation networks. For example, the operator has a service platform that provides freephone -- or reverse charging-type -- services to its GSM subscribers. The service broker will enable the operator to extend these services to the IMS environment without modifying the service platform or the service application. It will also enable the operator to combine Centrex-type services with GSM services, such as ringback tones or VPNs.

The fundamental technical issue behind these requirements has been well known in the industry for a long time. In the legacy environments of GSM and PSTN, service platforms are part of the intelligent network. IN platforms are critical components of current networks – they support services such as call screening, number portability, prepaid and VPNs. In a GSM network, the home location register (HLR) identifies the services that a customer is subscribed to, but it only allows a single IN service triggering for a given customer. Where combinations of services are required from different IN service platforms, operators have employed several workarounds, including complex routing, chaining of triggers and tromboning calls. The service broker concept was originally developed to address these issues, and 3GPP developed a Service Capability Interaction Manager (SCIM) standard for a service broker platform. A critical development of this content has been the extension of these concepts to include next-generation SIP signaling in addition to the legacy CAMEL and INAP SS7 signaling.

The operator I interviewed regards the service broker platform as a strategic platform. It selected a vendor at group level, and individual operating companies were able to choose between the two selected vendors. The selection process included a proof-of-concept trial for the short-listed vendors. The operator chose Nokia Siemens Networks (News - Alert) for the actual deployment and used the OpenCloud’s service broker running on OpenCloud’s JAIN SLEE platform. However, the operator had already selected other strategic supplies for its service platform. It is using the service broker only to orchestrate established services, not as a platform for developing new services.

This deployment is typical of the wave of service broker deployments we have seen in the past year. The key drivers are to combine multiple services within and between legacy and next-generation service environments. Many examples involve extending GSM prepaid services to include additional services, such as home-zone billing based on location or integration with IMS/VoIP PC clients.

Analysys (News - Alert) Mason views service broker deployments as an important use case for telecoms application servers. Operators are increasing their focus on differentiating service offerings as competition intensifies in mature and emerging markets. Bundling established services is a relatively quick and economic way of addressing specific market segments in order to increase ARPU and customer loyalty. We expect the growth in service broker deployments to continue in the next three years.