The service-interaction model defines how the SIS:
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.
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.
|
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:
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:
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
InitialDPrequest on a new CAP dialog, or anINVITEon a new SIP dialog -
subsequent requests — requests on already-established activities, such as the CAP
EventReportBCSMoperation, or a mid-dialogSIP NOTIFYrequest.
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
RequestReportBCSMEventoperations that each service emits. -
The SIS for SIP looks for services that insert
Record-Routeheaders 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.
In this example the SIS has received an originating InitialDP with calling party A and called party B.
-
The SIS invokes service
SCP A. This service processes thisInitialDPand 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. -
The SIS then evaluates condition
C 1. In this case the result is that the next service to trigger in the composition isSCP B. -
The SIS invokes service
SCP B. This service processes theInitialDP, arms some events, and sends aContinue -
The SIS then evaluates condition
C 2. The next service to trigger in the composition isSCP F. -
The SIS invokes service
SCP F. This service processes theInitialDP, arms some events, and sends aContinue -
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 BandSCP Fand sends aConnect.
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
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.
