3 Service Broker Service Orchestration

This chapter describes the components and the mechanics of the Oracle Communications Service Broker Orchestration.

About Orchestration Engine

The Orchestration Engine (OE) is core to Service Broker functionality and is responsible for delivering multiple services per session (see "Orchestration Engine").

To perform service orchestration, the OE uses orchestration logic. Orchestration logic defines a chain of applications to invoke, and the order by which the applications are invoked. The orchestration logic is different for each session.

The OE uses two types of components:

• Orchestration Profile Receivers (OPRs)

• Orchestration Logic Processors (OLPs)

Figure 3-1 shows how OPRs and OLPs are used by the OE to select and download orchestration logic.

Figure 3-1 Orchestration Engine Components (Core Engine: OPRs and OLPs)

When triggered by a session, the OE performs the following procedure:

1. Orchestration profile selection. To select and retrieve an orchestration profile, the OE uses the OPR that you specified when configuring the OE. You can specify one of the following OPRs:

   • Default OPR

     The OE uses this OPR to route a session based on the the static route OLP.

   • HSS OPR

     The OE uses this OPE to retrieve subscriber profiles from an HSS.

   • LSS OPR

     The OE uses this OPR to retrieve subscriber profiles from an SM-LSS.

   • Custom OPR

     This option is relevant for the Online Mediation Controller only. The OE uses this OPR to retrieve subscriber profiles from the Subscriber Store. If the subscriber profile is missing, the OPR returns the error, and the OE terminates the session.

   See the "Configuring General Parameters" section in the "Configuring the Orchestration Engine" chapter in the Oracle Communications Service Broker Processing Domain Configuration Guide for more information.

   The orchestration profile includes information on the type of OLP to use, and the specific parameters that this type of the OLP requires.

2. Application triggering. The OE interacts with an OLP component. The type of the OLP is specified by the OPR that was used in the previous step. Using the information included in the profile, the OLP obtains orchestration logic, processes the orchestration logic, and determines which application to trigger next. Once an application is selected by the OLP, the OE routes the session towards that application and waits for the application to return.

3. When the session returns, the OE continues processing the orchestration logic, looking for the next application to trigger. This process repeats until orchestration is completed. At this stage the OE routes the session back to the session control entity.

About Orchestration Profile Receivers (OPRs)

When OE triggers an OPR, the OPR responds with an orchestration profile. The OPR performs the following steps in order to obtain an orchestration profile:

1. Connecting to a profile server that holds subscriber data and orchestration profiles:

   OPR connects to a Home Subscriber Server (HSS) or to an on-board profile server (called Local Subscriber Server).

2. Selecting an orchestration profile:

   OPR uses session information (for example, session origination, session destination and IN Service Key) to select an orchestration profile.

3. Obtaining the orchestration profile:

   OPR obtains the selected orchestration profile and forwards it to the OE.

Different OPRs connect different sources of subscriber data and orchestration profiles. Service Broker installation includes the following OPRs:

• HSS Orchestration Profile Receiver

  The Home Subscriber Server (HSS) is the primary user database in the IMS domain. It contains subscription-related information including subscriber applications and orchestration profiles. The HSS OPR uses the Diameter protocol over the standard Sh interface to connect the HSS and select orchestration profile.

• LSS Orchestration Profile Receiver

  Service Broker offers an on-board implementation of a profile server, called Local Subscriber Server (LSS). The LSS is capable of storing subscriber profiles, including orchestration logic given in the Initial Filter Criteria (iFC) format. The LSS OPR connects the LSS to look up subscriber profiles with orchestration logic.

• Default Orchestration Profile Receiver

  When this OPR is used, the OE does not retrieve an orchestration profile from an external server. Instead, the OE triggers the Static Route OLP with its pre-configured orchestration logic.

It is possible to add new OPRs to Service Broker, to connect to other profile sources that exist in the operator's network. Service Broker can apply orchestration logic defined in HSS or any other profile source to the legacy domain.

About Orchestration Logic Processors (OLPs)

Orchestration Logic Processors (OLPs) obtain orchestration logic and process it in order to determine which applications to invoke and in which order. The OLP is triggered by the OE. It requires profile data and provides the address of the application that needs to be invoked in return. When the application finishes its processing and returns to the OE, the OE triggers the OLP again to receive the address of the next application to invoke.

Different OLPs are used to process different formats of profiles and orchestration logic rules. Service Broker installation includes the following OLPs listed. By default, the OE is installed with an OLP that executes initial Filter Criteria (iFC). It is possible to add new OLPs to Service Broker to support additional formats of orchestration logics.

• Initial Filter Criteria (iFC) OLP

  Initial Filter Criteria (iFC) is a standard format for specifying orchestration logic, specified in ETSI TS 129 228 V7.11.0, IP Multimedia (IM) Subsystem Cx and Dx Interfaces. iFC is a set of rules in XML format, composed of conditions (Trigger Points) and application servers that will be invoked if a condition is met. The conditions are given in logic expressions and can be applied on the content fields within the session.

• Static Route OLP

  The Static Route OLP uses a pre configured list of applications to determine which applications to invoke and in which order.

Supported iFC Trigger Point Methods

An iFC definition contains conditions that the OE uses to determine which applications to invoke for a given session. In effect, the iFC defines the application chain through which the messages in a session are processed.

The filtering elements in an iFC include the trigger point method. This value provides a filtering condition based on the message type of the incoming request.

As conventionally defined, the iFC trigger point method represents a SIP request type, such as INVITE or REGISTER. However, note that as a mediation layer, Service Broker transforms messages received from diverse networks into a common internal representation of the messages. As a result, the method types available for use as trigger method values in Service Broker OE comprise a subset of those defined by the iFC specification.

Specifically, the Orchestration Engine supports the following trigger point method types in its iFCs:

• INVITE

• REGISTER

• MESSAGE

• SUBSCRIBE

• NOTIFY

These method types directly correspond to their SIP method equivalents. For other networks, Service Broker performs a logical mapping between message types.