Workflow Packages for Routing Control
Workflow Configurations
This section describes the purpose of the default batch and real-time 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 a response to the source network element. The location and content of the stored Error Log UDR are implementation specific.
The default log UDRs contain the following fields:
| Field | Description |
|---|---|
timestamp | The 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 are 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 real-time. 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 calculate a number of KPIs and store these in UDRs on disk. The location and content of the stored KPI UDRs are implementation specific.
There are two workflow configurations that enable SLA Monitoring. The configuration, named RC_WFL_IWF_KPI, collects KPI UDRs from the Front-End Workflow in real-time.
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 files 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 preconfigured functions and uses 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 use 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.