Skip Headers
Oracle® Communications Service Broker Concepts Guide
Release 5.0

Part Number E15180-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

1 Understanding Service Broker

The following sections describe Oracle Communications Service Broker components:


Service Broker offers control and orchestration of service delivery and realtime charging for each session, call, or event in the telecom network. It delivers solutions for telecom networks across multiple domains, covering SS7-based networks, SIP/IMS networks, Diameter-based charging platforms and interaction with web services. Service Broker provides two primary functions:

Service Broker is fully compliant with IMS and NGN standard methodologies of service interaction, charging and orchestration, including support for IMS and IN interaction and integration with Diameter for online/offline charging.

Figure 1-1 shows the position of Service Broker in the network.

Figure 1-1 Service Broker Mediation Across Domains and Delivering Service Orchestration

Service Broker Mediation Across Domains

From a service delivery perspective, Service Broker enables the delivery of the following services:

From a charging perspective, Service Broker enables the use of:

Service Broker allows a gradual and seamless migration path from legacy networks to an IMS domain and IT-based services. During the migration, Service Broker fully supports the continuity of services already available in the network, leveraging existing legacy infrastructure and installed base. Service Broker focuses on new investments in the IMS domain while capping investments in legacy equipment, creating a new offering to operators who can now evolve their network to SIP, mostly throughout the application layer.

Functional Architecture

Service Broker is based on an architectural design that allows the system to adapt to and interact with service platforms and session control entities in both legacy SS7 and IMS/SIP domains. Service Broker architecture is composed of the following components:

At the core of Service Broker, the interaction is normalized to a common session and event model. Each IM provides the conversion between the Service Broker internal representation of the session and the applicable external protocol. Through an extensive set of network and application-facing IMs, the OE extends service orchestration beyond IMS to pre-IMS, for example, IN, SS7 networks, and other non-IMS domains, such as SOA and IPTV. This enables orchestration and mediation between various application and charging platforms across different domains.

Figure 1-2 shows the full architecture of Service Broker with the Orchestration Engine at its core and with a complete set of Interworking Modules.

Figure 1-2 Service Broker Functional Architecture

Service Broker Functional Architecture

Orchestration Engine

Service orchestration within the IMS domain is based on a concept of application assembly. This concept enables delivery of multiple services in a single session by routing the session through multiple applications. The chain of applications through which a session passes enables each application to accomplish its role in its turn.

The OE handles a session as follows:

  1. The OE is triggered through Service Broker network-facing IMs by session control entities from both legacy and IMS domains.

    IM-SCF enables triggering from a legacy domain, and R-IM-ASF and R-IM-OCF enable triggering from an IMS domain.

  2. The OE routes the session to multiple applications through Service Broker application-facing IMs.

    Interaction with applications is provided through the following:

    • IM-SSF towards IN SCPs

    • IM-OCF towards online charging servers

    • IM-ASF towards application servers

    The route through multiple applications is not static, but is determined in real-time mode by orchestration logic, which the OE selects and downloads dynamically. (For more information on how the OE selects and obtains orchestration logic, see "Service Broker Service Orchestration".)

  3. After the session passes the last application in the chain, the OE returns the session to the session control entity.

    Figure 1-3 shows an example of how the OE routes a session.

Figure 1-3 Routing a Session Sequentially through Multiple Applications

Routing a Session Sequentially through Multiple Applications

Interworking Modules

Interworking Modules (IMs) are fundamental elements in Service Broker architecture that allow connectivity between Service Broker and the various service platforms and session control platforms in the network.


The IM-SSF implements the SSP part of the IN call state model and provides the interface between the IN SCP in the legacy network and Service Broker. From the SCP perspective, Service Broker acts as an MSC/SSP implementing the Service Switching Function, generating IN triggers, and interacting with the SCP.

Figure 1-4 IM-SSF

IM-SSF architecture

IM-SSF modules are available for a variety of IN protocols and protocol variants including CAP, AIN, INAP, and WIN.

For example, the IM-SSF CAP supports the complete GSM SSF Call State Model allowing full CAMEL trigger interaction with any CAMEL SCP over CAP protocol.

IM-SCF (Reverse IM-SSF)

The IM-SCF implements the SCP part of the IN call state model for each IN protocol and variant it handles and provides the interface between the MSC/SSP in the legacy network and Service Broker.

Figure 1-5 IM-SCF

IM-SCF architecture

For example, the IM-SCF CAP supports the complete CAP Service Control Function (SCF) and IN state model, allowing interaction with any MSC using CAP protocol.

Acting as an SCP, it receives and arms IN triggers from an MSC/SSP and generates internal sessions to Service Broker, based on the trigger information.

IM-SCF modules are available for a variety of IN protocols including CAP, AIN, INAP and WIN.


The IM-OCF module implements the mediation module towards any external Diameter-based Online Charging Server, acting as 3GPP-compliant Charging Trigger Function (CTF).

Figure 1-6 IM-OCF

IM-OCF architecture

Online Charging Server is a telecom platform providing online rating and charging, as well as subscriber balance management. IM-OCF is an application-facing module that interacts with online charging platforms using Diameter Ro, allowing real-time charging for any session, whether IN, SIP, or any other session or event that is mediated through Service Broker.

Deploying IM-OCF with Service Broker's IM-SCF provides a complete online charging solution for SS7-based networks using various IN protocols. Combining IM-OCF with Service Broker's R-IM-ASF provides a complete online charging solution for SIP-based networks, effectively acting as a 3GPP IMS Gateway Function (IMS-GWF).

The variety of protocols supported by Service Broker's IM-SCF allows IM-OCF to provide a real-time, online charging solution to CAP/INAP-based GSM/UMTS mobile networks, WIN/IS-826-based CDMA/1X/EVDO mobile networks and wireline AIN and INAP. It paves the way to a full prepaid/postpaid convergence for voice and data and the migration from legacy nodal Prepaid SCPs solutions to converged and unified charging.


Reverse IM-OCF (R-IM-OCF) is a network-facing IM. It provides an IMS Online Charging Function (OCF) frontend to the network. R-IM-OCF connects Service Broker with IMS core elements that implement 3GPP-compliant Charging Trigger Function (CTF), such as IMS-Gateway Function (IMS-GWF), using the Diameter Credit Control Application interface. It converts charging triggers for online rating and charging to an internal Service Broker representation.

Figure 1-7 R-IM-OCF

R-IM-OCF architecture

Deploying R-IM-OCF with Service Broker's IM-SSF provides an online charging solution for IMS-based networks using legacy SS7 IN-based charging, that is SCPs. Deploying R-IM-OCF with Service Broker's IM-OCF provides an online charging solution for IMS-based networks that require mediation towards IMS OCFs. Therefore, R-IM-OCF allows real-time charging for IMS-based sessions using any charging function, whether IN or IMS.

R-IM-OCF allows Service Broker's OE to orchestrate real-time charging requests.


IM-ASF enables Service Broker to interact with IMS entities, that is applications and session control entities. It provides IMS entities with an IMS frontend to Service Broker. Typically, IM-ASF serves as an application-facing module that enables the delivery of a service to all session control entities. However, not all applications necessarily deliver services to all the entities.

IM-ASF is used in solutions where the application responds to sessions initiated by Service Broker. Applications that initiate new sessions interact through R-IM-ASF.

Figure 1-8 IM-ASF

IM-ASF architecture


Reverse IM-ASF (R-IM-ASF) enables Service Broker to interact with IMS entities, that is applications and session control entities. It provides IMS entities with an IMS frontend to Service Broker. Typically, R-IM-ASF serves as a network-facing module, enabling Service Broker to be invoked by core IMS elements, such as S-CSCF, as well as other pre-IMS elements, such as Soft switches and MGCs. This allows IMS core elements to trigger applications that are connected to Service Broker.

IMS applications or session control entities that initiate new sessions interact through R-IM-ASF. In solutions where the application responds to sessions initiated by Service Broker, IM-ASF is used.

Figure 1-9 R-IM-ASF



IM-PSX is a network-facing module that enables Service Broker to communicate between SIP applications and HLRs or VLRs in GSM and CDMA networks.

Integrating IM-PSX into Service Broker-based solutions enables SIP applications to:

  • Query a legacy network on information about subscribers, such as a subscriber's state, location, and the services a subscriber receives

  • Receive notifications from an HLR when a subscriber who was previously unaccessible 1254537 accessible again

  • Modify information about subscribers in a legacy network (in GSM networks only)

Figure 1-10 IM-PSX

IM-PSX architecture

From the HLR's perspective, Service Broker acts as a standard entity in the same network. HLRs can communicate with Service Broker using the MAP protocol (in GSM networks) or ANSI-41 protocol (in CDMA networks). IM-PSX provides interfaces for both MAP and ANSI-41.

Supplementary Modules

Supplementary Modules (SMs) are optional on-board modules, each facilitating Service Broker solutions in a different manner.


SM-Local Subscriber Server (LSS) is an implementation of a profile server that can be used as a source for service orchestration logic. LSS can store subscriber profiles, including orchestration logic defined in Initial Filter Criteria (iFC) format. When this supplementary module is deployed, the OE can retrieve orchestration logic from the LSS.


SM-Parameter Mapping Engine (PME) is a flexible XML-based engine that manipulates parameters in the headers and body of internal Service Broker SAL messages. SM-PME complements generic solutions with specific requirements and allows fine tuning of parameter mediation for standard and non-standard protocol parameters.

For example, SM-PME can manipulate XER representation of IN messages, allowing CAMEL Furnish Charging Information to update from one format to another Service Broker' OE can chain SM-PME at any point of the service orchestration in the same way that it chains Interworking Modules.

Signaling Server Units

Signaling Server Unit (SSU) is a Service Broker component that enables Service Broker to connect to SS7-based networks and IMS-based networks through standard software and hardware interfaces. There is a specific SSU implementation to support connection to each network domain.

Service Broker includes the following SSUs:

For more information about SSUs, see "Service Broker Signaling Server Units".

Tiered Deployment Architecture

The Service Broker deployment architecture is based on a separation into the following logical tiers as shown in Figure 1-11:

Figure 1-11 Service Broker Deployment Architecture

Service Broker Deployment Architecture

Axia Platform

The Signaling and Processing Tiers of the Service Broker make use of a modular OSGi (Open Services Gateway initiative)-based platform called the Axia platform. The Axia platform provides platform-level server services and a processing environment that:

  • Isolates individual processes and provides a container for managing those processes

  • Supports concurrent processing

  • Offers atomic and isolated execution of operations

  • Enables services to be transparently distributed to all Signaling Servers and Processing Servers in their respective domains

  • Provides redundancy and is scalable for high availability

  • Deploys Service Broker processing modules, such as IMs, OE and SSU components, within the Signaling or Processing Tiers

Both Signaling Tier servers and Processing Tier servers host platform-level server services.

For the purpose of modularization, the Axia platform is based on Oracle WebLogic Server and Equinox OSGi 3.5. Equinox OSGi is an Eclipse project that implements the OSGi framework. Service Broker components are packaged and deployed as OSGi bundles.

For more information about OSGi, see the OSGi Alliance Web site:

About Server Services

Server services offer functionality that is provided at the platform level. You configure certain server service functionality using the Administration Console or management scripts.

Server services include:

  • Deploying and managing the life cycle of Service Broker components. The deployment artifacts are OSGi bundles. You can perform a number of operations including installing, uninstalling, starting, stopping, and updating bundles.

  • Collecting, storing, and updating configuration data and propagating configuration data to Service Broker components across the domains.

  • Storing application-level data used by IMs and server services during runtime. This type of storage is provided as a memory store managed as an Oracle Coherence partitioned cache. The data in the cache is always replicated on at least two servers to ensure high availability.

  • Generating logs for each server in the domains. Logging is based on Log4J.

  • Generating notification messages for management and monitoring purposes, such as messages about the current state of a component or process, and warning and error messages.

  • Collecting traffic usage statistics. A usage statistic is a count of the number of events or messages that are sent and received. Usage statistics are generated, collected and stored for each server in a Signaling Domain.

  • Routing events to the appropriate Service Broker components.

  • Managing processing threads. Service Broker uses a number of work managers that share a pool of threads. The system automatically adjusts the thread pool to the work being scheduled in order to maintain as high a throughput as possible.

Service Broker Domains

From a system administration perspective, Service Broker deployments are managed using domains. A Service Broker domain is a logically related group of servers. A Service Broker deployment includes two types of domains:

A Service Broker production deployment usually includes two domains, a processing domain and a signaling domain. Each domain is deployed as a set of at least two servers.

When the Signaling Tier provides connection to more than one network, as shown on Figure 1-11, different signaling domains manage each network connection. In this way, each signaling domain manages a pair of Signaling Servers and the SSUs running on these servers.


For testing and evaluation purposes, it is possible to deploy Service Broker with both the Signaling Tier and Processing Tier co-located on a single machine.

The Signaling Domain and Processing Domain interact, and propagate protocol events across the tier boundaries.

The following sub-sections describe domain-related concepts and terminology, which are also shown in Figure 1-12.

Figure 1-12 Service Broker Domain

Service Broker Domain

About Signaling Servers and Processing Servers

Each server in the Processing and Signaling Tiers runs on its own Java Virtual Machine (JVM), and the term "server" reflects a JVM rather than a physical machine.

Servers can be added to and removed from the Processing Tier and Signaling Tier domains while the system is running, without service interruption.

Servers within a domain are symmetrical, which means that they all have the same Service Broker OSGi bundles installed and started.

Load balancers can be introduced between network nodes and Signaling Servers to distribute traffic between the network nodes and Service Broker.

Domain Configuration Directory

A domain has an associated domain configuration, which is stored in a domain configuration directory. All servers in the domain have read-only access to the domain configuration directory. Each time a Processing Server or a Signaling Server is started, it retrieves configuration data from the domain configuration directory and then stores a read-only copy of the data for use during runtime. The domain configuration directory is accessed using a shared file system or via the Domain Configuration Web server.

The domain configuration directory stores also the Service Broker OSGi bundles.

The domain configuration directory is also accessed by the Administration Console, see "Administration Console".

Administration Console

The Administration Console enables you to manage a domain. Through the GUI, you can view the data stored in the domain configuration directory, and have read / write access to the domain configuration directory.

The Administration Console can be installed and run from any machine that has access to the domain configuration directory.

The Administration Console can run in two ways:

  • Standalone Administration Console

  • Web Administration Console

The Administration Console manages a single domain. In a typical production deployment there are two instances of the Administration Console, one to manage the signaling domain and another to manage the processing domain.


In a test environment, where one domain includes both Signaling Servers and Processing Servers, there is only one Administration Console instance. In this case, the Administration Console manages both the Signaling Tier and Processing Tier in one domain.


Scalability is the ability of a system to provide throughput in proportion to, and limited only by, available hardware resources. A scalable system is one that can handle increasing numbers of requests without adversely affecting response time and throughput.

The growth of computational power within one operating environment is called vertical scaling. Horizontal scaling is leveraging multiple systems to work together on a common problem in parallel.

Service Broker scales both vertically and horizontally. Scaling options differ according to whether you are scaling the Processing Tier or the Signaling Tier.

Processing Tier Scaling

The Processing Tier of a Service Broker deployment includes two or more servers, employing an N+1 high availability schema, where several Processing Servers are grouped together to share a workload. The Service Broker Processing Tier can increase its throughput by adding a new Processing Server to the processing domain. You can add a new Processing Server on either of the following:

  • A new physical machine (horizontal scaling)

  • A machine that already executes another Processing Server (vertical scaling)

In either way, all servers are grouped under one processing domain and administered from one instance of the Administration Console and in the same Domain Configuration Directory.

Signaling Tier Scaling

The Signaling Tier of a Service Broker deployment consists of pairs of servers on which SSUs run. The Service Broker Signaling Tier can increase its throughput by adding pairs of Signaling Servers. You administer each pair of Signaling Servers in a separate signaling domain.