MATRIXX Network Enabler

The Network Enabler is a MATRIXX service that load balances TCAP messages across the processing servers, which offer charging and balance control operations. Each Network Enabler acts as a signaling gateway process (SGP) and the MATRIXX services on the processing servers act as application server processes (ASPs).

Network Enabler normally runs on the same pod as the Traffic Routing Agent and routes messages through the CAMEL (Customized Applications for Mobile networks Enhanced Logic) Gateway. When the mobile switching center (MSC) or service switching point (SSP) sends a request message to Network Enabler, Network Enabler translates it and passes the message to CAMEL Gateway, which sends it to MATRIXX Charging Application for processing. The MATRIXX Charging Application converts the message into an internal DiameterRO message for rating and returns a TCAP message to the CAMEL Gateway such as a TCAP CONTINUE(ApplyCharging). The TCAP message provides instructions to the MSC on how to handle and report on the voice call.

For engine scalability, Network Enabler supports multiple customer sub-domains on multiple engines by routing traffic to an active engine for the customer sub-domain appropriate to the subscriber. Network Enabler performs load balancing across all the available processing servers in the active engine for the customer sub-domain. For more information about customer sub-domains, see the discussions about engine configuration and engine sub-domain configuration in MATRIXX Configuration.

Network Enabler Failover

To ensure that calls and sessions are not lost in case of a pod failure, the state information for each session is held in the MATRIXX database. This information includes:
  • How long the call was active.
  • Maximum duration allowed for the call.
  • Who called whom.
  • Protocol state.
All updates are shared across the processing pods in the engine chain of that sub-domain. This allows the session to be handled by a different pod or engine in the event of a software or a hardware failure.

If Network Enabler cannot route a message to a process on a pod, it sends back an SCCP UDTS or XUDTS message to the network device, as appropriate.

All state changes related to Network Enabler failover are logged as LM_INFO messages in the mtx_debug.log file.

Note: If all servers in the primary engine fail, some in-flight calls can be lost when the primary engine fails over to the secondary engine. This can happen because an update to the session data has not yet been synchronized to all processing pods in the sub-domain.