Home
MATRIXX Architecture
MATRIXX Engine Software Topology
The MATRIXX Real-Time Engine software consists of a set of core software servers and one or more business modules. This is called a MATRIXX server.
Transaction Processing
The processing of each event takes place within an implicit transactional context that is created as the event enters the business logic processing workflow. The transactional context captures the changes to all in-memory database objects that are updated throughout the process flow and the data associated with the processed event.
MATRIXX Transaction Server
The Transaction Server coordinates and commits the transactions it receives from the Enrichment module. In addition, the Transaction Server participates in committing any transactions that are initiated by another server in the Parallel-MATRIXX™ cluster. This dual role allows the Transaction Servers across a cluster to keep transactional consistency of all their in-memory database copies.

Welcome
MATRIXX Release Notes
MATRIXX Architecture
- About MATRIXX Architecture
  MATRIXX Architecture provides a high-level overview of MATRIXX core components and functionality. It also provides reference architectures for MATRIXX deployments.
- MATRIXX Introduction
  MATRIXX is a real-time, transactional system designed to more efficiently support the growing volume and complexity of services that require real-time processing.
- MATRIXX Overview
  MATRIXX core components receive network messages, perform event-transaction processing, archive data needed for engine high availability or for disaster recovery, and publish or store event-transaction data for use by other systems.
- MATRIXX Reference Architecture
  A MATRIXX reference configuration runs in Kubernetes clusters in a private or public cloud.
- Multi-Domain Deployments
  Multi-domain MATRIXX deployments allow different pricing plans, MATRIXX Data Container (MDC) definitions, and RS Gateway instances for each domain.
- MATRIXX Engine High Availability and Scalability
  MATRIXX uses features of Kubernetes and Helm to ease high availability (HA) and scalability of components.
- MATRIXX Domain Architecture
  A customer domain is a set of subscribers that co-exist with a single homogeneous pricing configuration. It provides pricing and configuration separation from other potential MATRIXX environments in their own domains, such as in multi-tenancy or testing situations. You can build a customer domain upon one or more sub-domains. The simplest MATRIXX Engine deployment is a single engine chain implementing one customer domain (one customer sub-domain).
- MATRIXX 5G Interface (SBA Gateway)
  MATRIXX SBA Gateway provides a 5G interface for a Charging Server (OCS) and converged charging service (CCS) (including authorization and authentication) and is the consumer for Nchf_ConvergedCharging and Nchf_SpendingLimitControl for spending limit reporting. It is delivered as several images.
- MATRIXX TM Forum Gateway
  MATRIXX TM Forum Gateway (TMF Gateway) is deployed in a cloud native environment and implements the set of TMF microservice APIs supported by MATRIXX.
- MATRIXX Business API Gateway
  MATRIXX Business API Gateway includes the Rest Services (RS) Gateway and Gateway Proxy that translate REST and Java communication into the MATRIXX Data Containers (MDCs) that the other MATRIXX components use to communicate. This gateway is implemented as a high availability (HA) pair for reliability.
- MATRIXX Business API SDK
  The Business API SDK is a framework that includes a set of tools to manage, customize, and extend RS Gateway for your business needs.
- MATRIXX Traffic Routing Agent
  The MATRIXX Traffic Routing Agents (TRAs) load balance and route traffic among the MATRIXX components and provide high availability (HA) protection. Depending on their function, the TRAs can also load balance traffic and serve as a Diameter peer. In addition to HA protection, TRAs also provide a single virtual IP address point of access for BSS systems and network nodes to send network traffic to.
- MATRIXX Route Cache Controller
  In a MATRIXX environment where multiple customer sub-domains are implemented, the Route Cache (a database) is required in the traffic-routing layer.
- MATRIXX SIGTRAN Network Enabler Components
  The MATRIXX SIGTRAN Network Enabler is a MATRIXX service that load balances TCAP messages across the MATRIXX Engine processing servers, which provides charging and balance control operations. In terms of RFC4666 (M3UA), each Network Enabler acts as a signaling gateway process (SGP) and the MATRIXX services on the processing servers act as application server processes (ASPs).
- MATRIXX Applications
  MATRIXX is comprised of several applications that run seamlessly on one MATRIXX Engine to provide a total solution.
- MATRIXX Event Streaming Framework
  Used in environments in which the MATRIXX Event Streaming feature is enabled, or where event loading with MATRIXX Event File (MEF) is used, the Event Streaming Framework is a gateway that connects a MATRIXX Engine cluster to external systems that consume the event streams.
- MATRIXX Engine Software Topology
  The MATRIXX Real-Time Engine software consists of a set of core software servers and one or more business modules. This is called a MATRIXX server.
  - Business Logic Framework
    MATRIXX Charging Application and MATRIXX Policy Application each consist of the MATRIXX Engine event-processing platform and a set of business logic modules. The underlying engine provides the transaction-processing foundation and the modules provide the charging and policy functionality.
  - Algebraic-Decision Technology
    MATRIXX Charging Application can calculate rates and MATRIXX Policy Application can make policy decisions extremely quickly and efficiently because both solutions use linear equations rather than step-by-step hierarchical checks to determine calculations during rating.
  - Transaction Processing
    The processing of each event takes place within an implicit transactional context that is created as the event enters the business logic processing workflow. The transactional context captures the changes to all in-memory database objects that are updated throughout the process flow and the data associated with the processed event.
    - MATRIXX Transaction Server
      The Transaction Server coordinates and commits the transactions it receives from the Enrichment module. In addition, the Transaction Server participates in committing any transactions that are initiated by another server in the Parallel-MATRIXX™ cluster. This dual role allows the Transaction Servers across a cluster to keep transactional consistency of all their in-memory database copies.
    - MATRIXX In-Memory Databases
      MATRIXX Engine uses an in-memory database set to hold all transactional data. This object-oriented database works seamlessly with the non-locking transaction model. The database allows multiple read and update operations to the same objects to occur simultaneously while maintaining full transactional integrity.
    - MATRIXX Transaction Logs
      All database transactions are synchronously replicated across the processing cluster, logged to disk for durability, copied to shared storage for replication, and streamed to downstream engines for high availability purposes.
    - MATRIXX Event Detail Records
      MATRIXX Engine generates an _glossary/edr.html for all activities that can trigger rating, such as usage, catalog item purchases and cancelations, recurring cycle processing, or the first use of a balance. MATRIXX Engine also generates EDRs for non-rated events such as forfeitures. You configure event generation in My MATRIXX, including the events to generate and whether to add a custom container with additional mapped fields.
    - MATRIXX Event Files
      MATRIXX Event Files (MEFs) contain a list of usage and non-usage event types generated during transaction processing. MEFs are meant to be published to, and consumed outside of, MATRIXX and can be input to third-party applications.
    - MATRIXX Streamed Event Files (SEFs)
      MATRIXX Streamed Event Files (SEFs) are generated on the publishing pods on all MATRIXX Engines. They contain a list of usage and non-usage events generated during transaction processing. SEFs are created in _glossary/cmdc.html format and include a header that has the _glossary/global_transaction_counter.html and the number of events.
  - Task Processing
    Internal tasks related to data management operations are performed in the background by the MATRIXX Task Manager so transaction processing is minimally impacted. The Task Manager runs on the processing pods. Each one performs tasks concurrently in MATRIXX Engine so the workload is distributed evenly across the processing pods in an engine.
  - System Monitoring and Control
    Designed to be highly available, MATRIXX Engine is capable of being monitored and administered remotely. System health and performance are constantly monitored while collecting statistics on a configured interval for blade-level processes and cluster-level processes. These are stored in the statistics database.
  - Transaction Protocol
    Transaction Protocol is the MATRIXX Engine configuration for processing transactions. This protocol supports up to three processing servers. Two publishing servers are required.
- MATRIXX Engine Data Model
  The MATRIXX Engine data model is object based. All objects are defined in XML, making them extendable and the in-memory databases highly configurable.
- MATRIXX Engine Modules
  The MATRIXX Engine modules run on top of MATRIXX Engine and contain the business logic for MATRIXX Telco applications.
- MATRIXX Security
  MATRIXX should be deployed within a secure area of a carrier's network. Servers should have limited access points for event processing, business support systems, maintenance and monitoring, and local access.
- CAMEL Gateway
  In a MATRIXX environment in which Call Control Framework (CCF) is enabled, you can deploy multiple CAMEL Gateway servers in separate pods outside MATRIXX Engine.
- MATRIXX Traffic Routing Agent DR Features
  MATRIXX Traffic Routing Agent (TRA) provides an isolation layer between the network and the MATRIXX Engines configured as a Disaster Recovery (DR) group. It is installed on a pod located between the network and the MATRIXX Engine DR group and provides a single virtual IP address to which the network sends traffic independent of which engine is active at any given time.
- Transaction Replay
  Transactions are replayed first from all MATRIXX Engine processing pods in an engine to the active publishing pod in that engine. This creates the first redundant set of transaction events.
MATRIXX Installation and Upgrade
MATRIXX Configuration
MATRIXX Security
MATRIXX Integration
MATRIXX Diameter Integration
MATRIXX Call Control Framework Integration
MATRIXX TM Forum Integration
MATRIXX 5G Integration
MATRIXX 5G Event Streaming
MATRIXX Event Streaming
MATRIXX Administration
MATRIXX Web App Administration
MATRIXX Monitoring and Logging
MATRIXX Policy
MATRIXX Kafka CDR Consumer
MATRIXX Pricing and Rating
MATRIXX Pay Now
MATRIXX Subscriber Management
MATRIXX Subscriber Management API
MATRIXX Business API SDK
My MATRIXX Help
MATRIXX Backoffice Customer Tool Help
MATRIXX Third-Party Licenses
Glossary

MATRIXX Transaction Server

The Transaction Server coordinates and commits the transactions it receives from the Enrichment module. In addition, the Transaction Server participates in committing any transactions that are initiated by another server in the Parallel-MATRIXX™ cluster. This dual role allows the Transaction Servers across a cluster to keep transactional consistency of all their in-memory database copies.

The Transaction Server ensures the atomicity, consistency, isolation, durability (ACID) compliance of all transactions it coordinates or in which it participates. This happens in MATRIXX Engine without the use of database locks and without ever blocking the processing of an event to serialize multiple accesses to the same data. Instead, the Transaction Server employs a patented algorithm that detects and prevents data collisions just before they occur. The results of a given transaction are identical to what would have resulted had database locks been used, but these results are achieved with much higher efficiency and lower latency. This consistency-guarantee algorithm applies to the transactions that a Transaction Server is coordinating and all transactions running across the cluster. Every Transaction Server validates the consistency of every transaction in the cluster, and the Transaction Servers in the cluster agree on the consistency of all data before a transaction is committed. This creates a constant auditing of the consistency between all in-memory database copies, allowing any data corruption issues to be detected and addressed.

To ensure a durable copy of each transaction is available, each processing pod logs its transactions to the local Solid State Drive (SSD), and each processing pod performs redundant logging for another processing pod. To prepare for long-term auditing of every transaction and publication of Event Detail Records (EDRs) to downstream systems, the publishing pod replays all transactions and logs them to the shared storage.