Below are details of the role the SIS plays in the network and a high level and more detailed view of the SIS internal architecture.

Role of the SIS in the network architecture

Current networks can be seen as having two layers:

  • The control layer, which includes signaling elements, such as service switching points (SSP) in SS7 networks and CSCF in IMS networks

  • The services layer, which includes signaling control elements triggered by the network on behalf of subscribers, such as service control points (SCP) in SS7 networks and SIP Application Servers in IMS networks.

SIS layers

The OpenCloud SIS interposes a service-interaction layer between the service and control layers. The OpenCloud SIS controls the sequence of services that it invokes, managing and coordinating the interaction between each service. The output from a service may influence the choice of which service the SIS invokes next.

From the perspective of:

  • the control layer — the SIS looks like one service that is interacting with the network

  • each service — the SIS looks like the control layer

  • the service interaction layer — multiple services are being triggered on one session.

Tip Services may be in external network elements such as an SCP or SIP AS, or be deployed with the OpenCloud SIS (as a JAIN SLEE service).

High level SIS architecture

Below is a diagram followed by descriptions of the SIS subsystems.

sis arch option 4a


User-provided scripts control the services that the SIS invokes for each call. The SIS defines a script syntax for compositions, which specify a collection of services and the order in which the SIS should invoke them; and triggers, which specify the service compositions the SIS should select in response to individual network triggers.

The SIS also includes a number of pre-defined service-interaction rules, which dictate how the SIS should handle the different outcomes that a service can generate. Composition scripts can influence the behaviour of many pre-defined rules. TIP: OpenCloud’s Visual Interaction Architect (VIA) is a visual design environment with a graphical interface you can use for building and scripting SIS components (triggers, compositions, and macros).

Service-interaction engine

The service-interaction engine is responsible for:

  • evaluating trigger scripts for each call, to select a service composition

  • evaluating the selected composition script

  • managing the protocol state machines, by invoking services at the appropriate time and processing the outcomes services generate

  • considering how the outcomes a service generates affect other services in the composition.


Without services to invoke, the SIS would have an easy life indeed! Local services, implemented as JAIN SLEE services, reside within the local Rhino SLEE. The SIS uses a virtual view of the call, so it receives outcomes for consideration without directly affecting the actual call in the network. The SIS can also invoke services residing in external SIP ASs or IN SCPs by using new network triggers.


You can manage all facets of the SIS (such as trigger and composition deployment, user subscription provisioning, and other administration tasks) using a standard management interface. You can also monitor the SIS through various statistics that it records and reports using Rhino’s statistics monitoring subsystem. And the SIS includes several pre-defined alarm conditions, such as raising an alarm whenever a connection to the network is lost.

SIS internal architecture in more detail

Below is a diagram followed by descriptions of the SIS internal architecture in more detail.

sis arch option 5

SIS management

You can manage all facets of the SIS (such as trigger and composition deployment, user subscription provisioning, and other administration tasks) using a standard management interface. This interface consists of a collection of JMX MBeans and a command-line tool (sis-console). A SIS extension module for the Rhino Element Manager is also available.

SIS monitoring

To support the critical need to monitor SIS behaviour in real time, administrators can:

  • monitor statistics that the SIS defines, using Rhino statistics-monitoring tools

  • augment SIS-specific alarms with Rhino’s threshold-based alarms

  • enable various kinds of detailed tracing on a per-session basis, for example to monitor particular sessions in fine detail without impacting the performance and responsiveness of the entire platform, or quickly and simply focus attention on specific aspects of SIS behaviour, without sifting through large log files.

  • use a SIS audit capability to run a self check and report any issues with the SIS configuration (such as compositions that reference services that are no longer deployed).

Rhino SLEE

The SIS is built on the Rhino SLEE platform. As such it includes all the capabilities of Rhino — all JAIN SLEE features (for example, the JAIN SLEE resource adaptor architecture) and all Rhino features (such as the statistics client, threshold-based alarms, clustering, and so on). The SIS can run JAIN SLEE services, which can any of the resource adaptors in the OpenCloud portfolio (such as SMPP, HTTP, MAP, SOAP, and so on).

Tip You can use any service that runs in the SIS, using IN or SIP, in a service composition.

Service-interaction customisation

While the SIS scripting language is very flexible, some service-interaction scenarios may require further customisation. For those situations, the SIS provides very powerful Java-based extension capabilities.

Service-composition selection Java API

You can use a service-composition selector extension Java component as part of the service-composition selection process. These components can use all capabilities of the Rhino platform (such as any resource adaptor, JDBC, and so on).

A common use case is to query an operator-specific platform, such as a subscriber database, as a part of the service-composition selection process.

Service-composition extension Java API

The SIS service-composition scripts are very powerful, with features such as conditional branching and the ability to adjust signaling parameters. For maximum flexibility and power, you can use a service composition extension Java component as a part of the execution of a service composition. These components can use all the capabilities of the Rhino platform.

A common use-case is to query to an operator specific platform, such as a subscriber database, and adjust signaling parameters based on the query result.

Tip The SIS scripting language is the preferred approach to defining service-interaction logic for the SIS. Each release of the SIS extends it with more capabilities. In particular, Metaswitch actively identifies use cases where customers often have to resort to using the Java extension mechanisms — and we provide equivalent SIS language-level support.

Service-interaction engine

The service-interaction engine is the core of the SIS, that responds to incoming requests, assigns them to a service composition for processing, and then manages and runs the service composition to completion.

Service composition selection

The service-composition selection function evaluates trigger scripts for each new session that reaches the SIS, and determines which service composition should be run. See The SIS Service-Interaction Model for more detail on this process.

Protocol state machines

The SIS service-interaction engine understands the protocol state machines of a number of protocols. It ensures that the signaling between the SIS and the network, and between the SIS and each triggered service, follows these protocol rules. It also ensures that the results of the services that are triggered will result in appropriate interaction with any other service that is part of the service composition. For example, if a service decides to release a call, the SIS will ensure that the other services that were due to be invoked as a part of the service composition will not be invoked.

The scripting language and the extension capabilities can be used to affect, or override, the protocol rules.

Composition executors

The composition executors are the part of the service interaction engine that runs service compositions. The composition executors run the service-composition scripts, invoke extension Java components, and apply the rules of the protocol state machines. The composition executors also include protocol-specific features for invoking services in external platforms (such as a SIP proxy).

Tip The SIS scripting language includes features for controlling the protocol-specific features. For example, a future release of the SIS IN module will allow a service composition script to specify a range of SCCP addresses for a given external service, with guidelines for how the set of SCCP address should be used (for example, active/standby, or round-robin).
Previous page Next page