Workflow Configurations

This section describes the purpose of the default batch and realtime workflow configurations that are available in Routing Control.

The workflow configurations are intended as a baseline for implementation projects and can be adapted to meet specific customer requirements. For this reason, the description of the workflow configurations described in this document may deviate from your implementation. The default workflow configurations are designed for routing of Diameter messages but can be configured to handle other protocols, for example Radius.

Front-End Workflow and Back-End Windows

The Front-End Workflow configuration, named RC_WFL_FrontEnd , handles the decoding and validation of UDRs from the network. Various lookups are performed based on session- and subscriber attributes to determine the correct route and destination for each UDR. It forwards the UDR and responds to the source network element. Depending on the use case, the Front-End Workflow may forward UDRs to a Back-End Workflow, named RC_WFL_BackEnd for further processing.

The rationale behind separating the processing into two different workflow configurations is that it may enhance performance. When all use cases are executed in the front-end, rare but complex use cases may have a significant negative impact on the throughput. By offloading these use cases to the back-end, the overall throughput can be optimized. It is also possible to perform internal load balancing by executing multiple Back-End Workflows.

Error Handling Workflows

In case of errors when processing UDRs, a log UDR is stored before response to the source network element. The location and content of the stored Error Log UDR is implementation specific.

The default log UDRs contain the following fields:

Field	Description
timestamp	Time when the error was generated.
subsKey	The subscriber id, IMSI or E164, if available.
errorMessage	An error message defined in `RC_APL_Constants`. This is an APL code file imported by workflow configurations.

There a two workflow configurations for handling Error Log UDRs. The configuration, named RC_WFL_IWF_Error, collects Error Log UDRs from the Front-End Workflow in realtime. The UDRs are encoded and forwarded, via an Inter Workflow agent to a batch workflow named RC_WFL_Error_To_Disk that will send the UDRs to a local disk.

KPI Collection Window

The Front-End Workflow and the Back-End Workflow configurations calculates a number of KPIs and store these in UDRs on disk. The location and content of the stored KPI UDRs is implementation specific.

There a two workflow configurations that enable SLA Monitoring. The configuration, named RC_WFL_IWF_KPI, collects KPI UDRs from the Front-End Workflow in realtime.

The UDRs are encoded and forwarded, via an Inter Workflow agent to a batch workflow named RC_WFL_KPI_To_Disk that will send the UDRs to a local disk.

The default KPI UDRs contain the following fields:

Field	Description
key	The subscriber id, IMSI or E164, if available.
resultcode	An error code defined in `RC_APL_Constants`. This is an APL code file imported by workflow configurations.
latency	The response time to the source.
time	The timestamp of the incoming UDR.

Batch Provisioning Workflows

The workflow RC_WFL_Provisioning_Import reads UDRs from file and provisions the data using APL functions.

The reverse process is performed by running RC_WFL_Provisioning_Export which exports Routing Control configuration data to files.

Workflow Functionality

This section describes the default the preconfigured functions and use cases that are included in the default workflow configurations and which enable users to control routing of Diameter messages, through the Web GUI. Changes in the workflow configurations are typically required in order to introduce new uses cases or when adding or changing communication endpoints, data formats and protocols.

Routing Types

Session-Based Routing

Session-Based Routing provides routing of UDRs based on the session attributes of the incoming UDRs.

The UDRs for any given session are always routed to the same destination, also when the function is combined with Weight-Based Routing.

Subscriber-Based Routing

Subscriber-Based Routing provides routing of UDRs based on the subscription attributes of the incoming UDRs.

The UDRs for a specific subscriber are always routed to the same destination, also when the function is combined with Weight-Based Routing.

Weight-Based Routing

Weight-Based Routing provides load balancing of UDRs towards routing destinations.

Weight-Based Routing is always combined with either Subscriber-Based Routing or Session-Based Routing.

Workflow Bridge Routing

Workflow Bridge Routing forwards UDRs to the Back-End Workflow for further processing.

Next chapter:

3. Routing Data Model

Browser not supported