Network Request Processing

Call Control Framework (CCF) can allocate incoming requests to any processing blade within a customer sub-domain.

Network Enabler performs load balancing across all the available processing blades in the active engine for the customer sub-domain. For more information about customer sub-domains, see the discussion about engine scalability and customer sub-domains in Architecture Overview.

So that calls and sessions are not lost in case of blade or engine failure, the MATRIXX database holds the state information for each session, such as how long the call has been active, the maximum duration allowed for the call, who called who, the protocol state, and so on. The processing blades in the engine chain of the sub-domain share all updates so that a different blade or engine can handle the session if a software or a hardware failure occurs.

If Network Enabler cannot route a message to a process on a blade, by default it sends back an SCCP UDTS or XUDTS message to the network device, as appropriate. You can override the default Network Enabler fallback processing and configure CCF to use special message handling instead. For information, see the discussion of Network Enabler fallback processing.

The following diagram shows the main MATRIXX components for processing network requests using the voice charging and SMS charging services.
Figure 1. Network Request Processing
When Network Enabler receives a network request for a voice call or an SMS message, it is processed in the following way:
  1. The Mobile Switching Center (MSC) sends a TCAP (InitialDP) request to Network Enabler.
  2. Network Enabler determines the sub-domain of the subscriber and sends the TCAP message to Camel Gateway on any processing blade within the sub-domain.
  3. Camel Gateway sends an MtxTcapMsg message to the Charging Server containing the decoded information from the TCAP message.
  4. The Charging Server retrieves the subscriber details from the database and applies normalization business logic to the MtxTcapMsg.
  5. The Charging Server then applies Call Control Framework (CCF) business logic to determine the service to invoke, for example, the voice charging service or the SMS charging service.
  6. The Charging Server determines whether to apply rating and then passes the message to the Enrichment module to add any extra required data to the message.
  7. The Charging Server passes the message to the Transaction Server and the Transaction Server commits any changes to the subscriber data, such as balance updates, to the database. The Transaction Server then returns the MtxTcapMsg message to Camel Gateway.
  8. Camel Gateway encodes the MtxTcapMsg message and returns the appropriate TCAP response message to Network Enabler, for example, Camel Gateway could return a TCAP Continue message to allow the session to continue.
  9. Network Enabler sends the TCAP response message to the MSC.