Selecting a service composition

Upon receiving a request from the network, the SIS determines the set of services — called a composition — to handle that request. The composition specifies both the services and the order in which the SLEE will invoke them.

finding a composition

When the SIS receives an initial request, it performs some processing to select which composition to execute. This process of selecting the composition is called triggering. The SIS can be configured with many trigger rules, to specify how it selects which compositions to execute for different types of initial requests.

The SIS evaluates each trigger in order, until it finds one that applies to the incoming request. Each trigger has:

  • a trigger condition, that the SIS can evaluate to determine whether the trigger applies

  • a set of service composition selectors, that the trigger uses to select a service composition from the set of service compositions provisioned in the SIS

  • an optional failure clause, for the SIS to execute if trigger doesn’t select a service composition for processing.

Note Triggers and compositions are specified in XML.
See also Triggers.

Including local and external services

A service composition specifies a particular service-combination scenario. For example, a particular user may require PrePay Charging, VPN, and Call Screening functionality. A composition defines which services can be invoked for a given scenario, and the order in which those services can be invoked. A composition can also include branches, so that certain services are only invoked under particular circumstances.

The services in a composition can be any combination of local SLEE services and external services. In the above example, the VPN and Call Screening services might be implemented in external network nodes, while the PrePay Charging service runs as a local service and interacts with a Diameter online charging system. The SIS treats both local and external services the same when it comes to interaction management, as shown below:

sis arch option 4b

Running a service composition

When invoking services in a composition, the SIS passes the request to each service in turn, then waits for the outcome from the service. Each outcome is protocol-specific — it may be a response generated by the service or a new request, depending on the protocol. Once the SIS receives the outcome, it determines which service in the composition to invoke next, and repeats the process, until all necessary services have been invoked. Finally, the SIS sends a response to the original request back to the network (as appropriate for the protocol).

As part of this process, the SIS isolates the services from each other — as far as each service knows, it is the only one handling the request. The SIS ensures each service gets the request in the right order, and any changes the service makes get to the next service according to the network protocol. For example, if a service adds SIP headers to the request, the SIS ensures they are visible to subsequent services in the composition.

SIS service chains

The following diagram shows a service composition, as a directed, a-cyclic graph of services to execute, with branching points that the SIS evaluates as it processes the initial request:

sis composition chains

The righthand side of the diagram shows all the possible service chains that can result from processing an initial request to completion. A service chain is a subset of services in the composition that the SIS has selected to run for a particular request. Once built, the SIS uses the service chain for all subsequent related requests (for example, the SIS uses the same service chain for all messages on an SS7 dialog).

In this particular example, the service composition includes six services (S a, S b, S c, S d, S e, S f), and two decision points (C 1 and C 2) where a different path through the service composition is possible.

Processing initial and subsequent requests

The SIS treats incoming requests as either:

  • an initial request — a request that creates a new protocol-specific activity, such as the InitialDP request on a new CAP dialog, or an INVITE on a new SIP dialog

  • subsequent requests — requests on already-established activities, such as the CAP EventReportBCSM operation, or a mid-dialog SIP NOTIFY request.

Initial requests

When the initial request fires through each service in the composition, the SIS keeps track of which services are interested in receiving future requests on the activity. How it works depends on the network protocol:

  • The SIS for IN tracks the services that want to monitor a dialog, by inspecting the RequestReportBCSMEvent operations that each service emits.

  • The SIS for SIP looks for services that insert Record-Route headers in a dialog-creating request.

An IN example — processing the initial request

The following diagram is an SS7 example based on the service composition in the bxref:#[executing compositions tab.

process initial event

In this example the SIS has received an originating InitialDP with calling party A and called party B.

  1. The SIS invokes service SCP A. This service processes this InitialDP and directs the call to a different destination (B2). It does not wish to monitor the call further so does not arm any events. The SIS will not involve this service further in the composition.

  2. The SIS then evaluates condition C 1. In this case the result is that the next service to trigger in the composition is SCP B.

  3. The SIS invokes service SCP B. This service processes the InitialDP, arms some events, and sends a Continue

  4. The SIS then evaluates condition C 2. The next service to trigger in the composition is SCP F.

  5. The SIS invokes service SCP F. This service processes the InitialDP, arms some events, and sends a Continue

  6. The SIS finally sends a final result to the network on behalf of the service composition. In this case the SIS arms some events (based on the events armed by SCP B and SCP F and sends a Connect.

Subsequent requests

When a subsequent request arrives, the SIS passes it to those interested services, in the appropriate order for the protocol. So the initial request for an activity determines the path for subsequent requests on that activity.

Continuing the IN example — processing subsequent requests

process subsequent event

The destination party (B2) answers the call. The SIS has received an EventReportBCSM for O-Answer. The only services that remain in the service composition are SCP B and SCP F. The SIS delivers the EventReportBCSM to services in the reverse direction that the InitialDP was processed, as the reported event relates to the destination party. In this case SCP F is invoked before SCP B.

Previous page Next page