Welcome to the MATRIXX Software documentation, where you can find information about how to install, configure, and maintain a MATRIXX environment. The following information describes how to provide documentation feedback, how to use and navigate through the MATRIXX documentation.

MATRIXX Release Notes provides information about new features, resolved issues, data changes, configuration changes, interface changes, upgrade paths, third-party software requirements, and known issues.

The following information applies to release version 5290 of MATRIXX. For a list of hardware and software requirements, see MATRIXX Installation and Upgrade.

Documentation for MATRIXX is available online and in PDF format.

MATRIXX Architecture provides a high-level overview of MATRIXX core components and functionality. It also provides reference architectures for MATRIXX deployments.

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 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.

A MATRIXX reference configuration runs in Kubernetes clusters in a private or public cloud.

Multi-domain MATRIXX deployments allow different pricing plans, MATRIXX Data Container (MDC) definitions, and RS Gateway instances for each domain.

MATRIXX uses features of Kubernetes and Helm to ease high availability (HA) and scalability of components.

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 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 (TMF Gateway) is deployed in a cloud native environment and implements the set of TMF microservice APIs supported by MATRIXX.

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.

The Business API SDK is a framework that includes a set of tools to manage, customize, and extend RS Gateway for your business needs.

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.

In a MATRIXX environment where multiple customer sub-domains are implemented, the Route Cache (a database) is required in the traffic-routing layer.

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 is comprised of several applications that run seamlessly on one MATRIXX Engine to provide a total solution.

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.

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.

The MATRIXX Engine data model is object based. All objects are defined in XML, making them extendable and the in-memory databases highly configurable.

The MATRIXX Engine modules run on top of MATRIXX Engine and contain the business logic for MATRIXX Telco applications.

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.

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 (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.

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 describes the tasks required to install MATRIXX components as containers using Kubernetes and Helm.

Cloud native MATRIXX deployments have infrastructure requirements for third-party software versions, Kubernetes pod characteristics, and container characteristics. Nodes running MATRIXX components have operating system, memory, networking, and storage requirements.

Different MATRIXX features are supported depending on whether your installation is based on Topology Operator or Engine Operator.

A cloud native MATRIXX installation consists of containers installed with the MATRIXX Helm chart in a multi-node Kubernetes cluster (or clusters), requiring MATRIXX images and MATRIXX Engine custom resource definitions and controllers.

These examples show how you can configure the installation of multiple MATRIXX Engines in a single namespace, multiple namespaces in a single cluster, and multiple clusters.

MATRIXX is configured using Helm properties. Questions and answers in create_config.info files can also provide configuration using configuration sources. For information about how to configure MATRIXX, see the discussions of those topics in MATRIXX Configuration.

The Topology Operator method of MATRIXX Engine pod management utilizes multiple custom resources (CRs) and operator pods working together to manage the installation and upgrade of multiple sub-domains and engines across Kubernetes clusters, including the loading of pricing and taxation data.

Use Helm and Kubernetes to manually add or remove pods as necessary. You can also use Kubernetes to manage resources available to MATRIXX Engine pods.

For Call Control Framework (CCF), only the deployment of Network Enablers (NEs) in a Kubernetes cluster is different from a standard deployment.

When deploying CAMEL Gateway as part of the reference architecture, you can use any namespace within the Kubernetes clusters. You can make multiple deployments into multiple namespaces, for example, to have different environments for testing and production.

An SSH key, used for password-less SSH login, is required to enable _glossary/mef.html publishing in Kubernetes. A secret holds the SSH private key, and the key is specified in Helm values. The SSH key allows administrators to write to a target directory in a secure manner without having to enter a passphrase.

Transport-layer security (TLS) encryption can be enabled for replay between processing and publishing pods and between engines.

Cloud native MATRIXX deployments support MongoDB as an event store using the MongoDB Enterprise Operator for Kubernetes.

The Event Streaming Framework provides a connector for sending event stream data to Apache Kafka. Using 5G event streaming also requires Apache Kafka, which is not provided with MATRIXX. You can use a Helm chart to install and configure Apache Kafka.

A Kubernetes Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.

MATRIXX components store log files in persistent storage on the node by default, in a persistent volume (PV) at the location specified in global.storage.localStorageDir property (/home/data by default).

Upgrading cloud native MATRIXX has several stages.

This example shows migration from a MATRIXX version XXXX deployment managed by Engine Operator to a deployment managed by Topology Operator. The same approach applies when migrating from Engine Controller.

Migrating from a bare metal MATRIXX deployment to a cloud native deployment (from the same MATRIXX version) requires temporarily using a hybrid platform made up of components from both deployments. This hybrid environment allows migration to the cloud native deployment without disruption of services.

Operations teams can use the Admin Service to administer a MATRIXX deployment with domain-specific commands based on the components that are installed. It allows administration of the installation without providing unrestricted direct access to the Kubernetes cluster. You can secure commands based on user roles and audit command usage.

Use the helm uninstall command to uninstall MATRIXX Engine components installed from the Helm chart.

MATRIXX Configuration describes the tasks required to configure MATRIXX components.

Configure MATRIXX by adding values for properties from the MATRIXX Helm chart in your Helm values file. The MATRIXX Helm chart includes component sub-charts in a hierarchy of reusable components.

MATRIXX Engine configuration can be applied from a configuration source.

Traffic Routing Agent (TRA) configuration can be added to the deployment with a configuration source.

In a MATRIXX environment where multiple customer sub-domains are implemented in separate engine chains, you configure sub-domain routing so that traffic is directed to the correct customer sub-domain where the subscriber is homed. You must configure different components across MATRIXX for sub-domain routing to work.

Example configurations are provided for single-engine, dual-engine, and dual-engine with Traffic Routing Agent in disaster recovery mode (TRA-DR) cloud native MATRIXX examples.

In a non-containerized installation of MATRIXX, configure MATRIXX gateways and web apps using files in the /opt/mtx/conf directory in the pod(s) hosting those components. In a cloud native deployment, configuration files can be provided in the /opt/mtx/conf directory of the component container(s) using the following methods:

The MATRIXX Engine can import and rate Solution42® call detail records (CDRs) and generate MATRIXX Event Detail Records (EDRs) from them. Generally, this is used only when integrating with an Oracle BRM system. Other projects should use external mediation to convert external CDRs into Diameter messages for MATRIXX processing.

In a cloud native MATRIXX installation, MATRIXX Engine configuration specified in the create_config.info file is applied with a configuration source. This file contains a list of the questions asked by the configuration script during the configuration process and the answers provided by the administrator. Each question sets a configuration parameter. The engine(s) are configured with these parameters with a helm upgrade command.

The information in MATRIXX Security is best-practice information and identifies MATRIXX-specific security considerations and implementations. For container-specific and Kubernetes security information, see the third-party documentation.

The information here addresses cloud native security and includes recommendations for securing your cloud native implementation.

MATRIXX uses certificates signed by a trusted certificate authority, or validated by other means, to establish secure communications with another party with the corresponding private key.

Transport Layer Security (TLS) provides secure internet connections by encrypting data sent between a browser, a website, and the website server to ensure that data is transmitted privately.

Network zones are stacked with increasing proximity to the open internet or DMZ. Each zone is traversed by ingress and egress points through an application or server, with appropriate authentication and authorization for connecting system traffic.

Application security includes configuring web applications and gateways.

Depending on your MATRIXX environment, you can use multiple external databases.

MATRIXX supports third-party identity and access management application integration.

MATRIXX Integration describes the tools and tasks for integrating MATRIXX functionality in a MATRIXX environment.

The /opt/mtx/data/mdc_config_system.xml file has all system MATRIXX Data Container (MDC) definitions, subtype definitions, and relationship definitions.

MATRIXX includes images that contain utilities to aid in the deployment, operation, and configuration of cloud native MATRIXX installations. You can run these utilities directly or scheduled as cron jobs using the MATRIXX Helm chart.

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 (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.

This section provides an overview of subscriber data relationships.

A MATRIXX Engine can optionally load EDRs (Event Detail Records) into the MATRIXX Event Repository, a database separate from the MATRIXX Engine platform that serves as a long-term event storage repository. The Event Repository is an optional component separate from MATRIXX Engine that is implemented in MongoDB (you must purchase and install MongoDB).

This section describes how the MATRIXX Engine publishes notifications to a JMS message broker and how you can customize the information included in notifications.

The Business API Gateway is a development framework that includes the Business API SDK, Rest Services Gateway (RS Gateway), Gateway Proxy, and application tier. It allows custom mobile applications, web clients, and other custom implementations to integrate with MATRIXX.

You can extend MATRIXX Engine functionality to capture new subscriber-related data and then use the extended fields as a basis for pricing, rating, and policy decisions. You can also add new Diameter AVPs to capture information from the network and base rating and post-rating operations on this data.

The MATRIXX Data Export image (data-export) has the data-export.jar utility. This utility uses checkpoint files to transform database contents and MATRIXX Event Files (MEFs) to comma-separated value (CSV) files. This image also creates SQL files for creating RDBMS tables and loading the data from the CSV files.

Selective updates are commands that enable the system to selectively update a MATRIXX Data Container (MDC) as it is processed. They perform basic transformations on the MDCs.

The MATRIXX Toolbox image has scripts and utilities to aid in the deployment and operation of cloud native MATRIXX installations.

The MATRIXX Misc image includes utilities and files to aid in the deployment and operation of cloud native MATRIXX.

You can use the third-party Linux tcpdump utility to capture network traffic for a MATRIXX application.

MATRIXX generates General Ledger (GL) information for accounts that you specify during rating. It then captures that information in MATRIXX Event Files (MEFs).

MATRIXX Diameter Integration provides information about MATRIXX Engine Diameter support and configuration.

The following information describes the Diameter Gateway.

The following information describes External Diameter Gateway (EDGW).

MATRIXX Call Control Framework Integration provides information about MATRIXX Call Control Framework support and configuration.

MATRIXX includes an integrated GSM Service Control Function to support call control capabilities for telephony services.

MATRIXX Call Control Framework (CCF) provides support for message sequences using the Camel Application Part (CAP) protocol.

This section describes how to configure MATRIXX Network Enabler.

CAMEL Gateway is a CAMEL Application Part (CAP) server. Configure CAMEL Gateway to allow communication between MATRIXX Engine and Network Enablers through the CAP protocols.

Configuring routing preferences allows you to define how routes are prioritized between CAMEL Gateway on each engine and Network Enablers.

Call Control Framework (CCF) supports configurable correlation ID lengths. CCF handles 10 digit correlation ID lengths by default.

Call Control Framework (CCF) supports the processing of roaming voice calls that use the CAP1 protocol.

Call Control Framework (CCF) provides support for processing and applying charging for voice calls that use the CS1 INAP protocol.

You can configure Call Control Framework (CCF) to send Furnish Charging Information (FCI) operations at specific points during call handling. CCF sends FCI operations to instruct the Mobile Switching Center (MSC), or service switching point (SSF), to add charging information to the call data record (CDR) for a call.

When handling a mobile terminating (MT) call, Call Control Framework (CCF) can forward the call to another number if the call is not answered, or the called number is busy.

Call Control Framework (CCF) can handover (relay) incoming TCAP requests for subscribers that MATRIXX cannot find in its subscriber database to another platform for processing. For example, when migrating to the MATRIXX platform, CCF can relay incoming TCAP requests to the incumbent platform for subscribers that have not yet been migrated across. After handover, the incumbent platform processes the TCAP request without any further involvement with MATRIXX.

MATRIXX Call Control Framework (CCF) provides support for playing pre-call announcements. The following topics describe CCF pre-call announcement functionality and explain how to configure CCF to play announcements.

Call Control Framework (CCF) supports making Mobile Application Part (MAP) Unstructured Supplementary Service Data (USSD) call out requests to deliver USSD notifications to a subscriber. CCF also supports USSD services for queries, call back, and interactive menus using MAP-Process-UnstructuredSS-Request messages, and MAP-UnstructuredSS-Request messages.

Call Control Framework (CCF) provides support for menu driven announcements using IVRs and interactive USSD service menus that give subscribers options for retrieving and updating their balances and account details.

You can configure Apache FreeMarker templates for handling Call Control Framework (CCF) services such as Unstructured Supplementary Service Data (USSD) query and call back services, and menu services using announcements or interactive USSD menus.

MATRIXX Call Control Framework (CCF) provides support within the Charging Server for making MAP call out requests to an external platform in response to TCAP or Diameter messages that require them.

You can extend the data used in Mobile Application Part (MAP) callout requests and results. You can include customized private extension data in the extensionContainer parameter in MAP ATI (AnyTimeInterrogation) and MAP SRI (SendRoutingInfo) operations. This feature enables you to manipulate the data sent and returned in MAP callouts, for example, to correct the digits dialed by a user when roaming.

Call Control Framework (CCF) provides support for making Lightweight Directory Access Protocol (LDAP) call out requests to an LDAP server in response to TCAP or Diameter messages that require them.

Call Control Framework (CCF) holds response data for Mobile Application Part (MAP) callouts and Lightweight Directory Access Protocol (LDAP) callouts for a call or a session in MATRIXX Data Container (MDC) format.

MATRIXX TM Forum Integration describes the tasks required for integrating TM Forum (TMF) APIs with MATRIXX and provides overviews, recommendations, and conceptual discussions to help you understand these tasks.

MATRIXX TM Forum Open API Gateway (TMF Gateway) implements the set of TMF microservice APIs supported by MATRIXX.

Install the TM Forum (TMF) microservices in a cloud native environment.

TM Forum (TMF) microservices map TMF API data to custom MATRIXX Data Container (MDC) extensions, where each custom field has the same name and field type as the TMF API field that maps to it.

The TMF party management API supported by MATRIXX provides a standardized mechanism for party management for creating, updating, retrieving, and deleting individual and organization information.

The TMF635 usage management API supported by MATRIXX provides a standardized mechanism for creating, updating, retrieving, importing, and exporting a collection of usages.

The TMF640 service activation and configuration API supported by MATRIXX provides a standardized mechanism for configuring and activating subscription services.

The TMF677 usage consumption management API supported by MATRIXX provides a standardized mechanism for retrieving usage consumption data associated with a subscription.

MATRIXX provides a continuous integration and continuous deployment (CI/CD) pipeline to deliver custom TM Forum (TMF) microservices using the MATRIXX TMF Integration Builder.

MATRIXX 5G Integration describes how to implement the Service-Based Architecture (SBA) Gateway and messaging. In addition, this document provides information about security configuration (secured and not secured).

This section describes the Service Based Architecture (SBA) Gateway, which provides the framework to build 5G network function (NF) services based on 3GPP technical specifications.

This section describes the Charging Function components and how to deploy and configure them.

MATRIXX 5G Event Streaming describes how to aggregate and stream charging data records (CDRs) from the SBA Gateway to an sFTP server using a Kafka broker.

SBA Gateway can stream HTTP requests and MATRIXX Engine HTTP responses to a Kafka broker. The 5G event streaming applications convert the received JSON objects to ASN.1 binary format for export to Kafka applications and can optionally aggregate and route based on content. The GTP Prime Adapter microservice is provided for sending records from Kafka to a GPRS Tunneling Protocol (GTP) server.

Charging data records (CDRs) are processed by the CDR ASN.1 Streamer Kafka client application to convert them from JSON into ASN.1 objects. After the ASN.1 objects are serialized as a binary message using Basic Encoding Rules (BER), they are placed in another Kafka topic for further processing. The ASN.1 sFTP Sink application then writes the message to file before transferring it over Secure FTP (sFTP).

Each time the ASN.1 sFTP Sink application receives a batch of records, if the number of records is greater than or equal to the configured closure condition, the aggregated ASN.1 record is generated. Otherwise, the batch is held for the next ASN.1 record.

Every request received by SBA Gateway from the SMF results in the creation of a 5G event, also known as a network _glossary/cdr.html. To avoid sending excessive records to a downstream system, CDRs must be aggregated on a per session basis so that only summary level CDRs are sent to third-party CGF or the BSS domain. The CDR Aggregation Function (CAF) application is a Kafka Streams application that aggregates network interactions handled by SBA Gateway on the 5G N40 interface.

The CDR Kafka router republishes each _glossary/cdr.html based on its content, either as received or enriched with additional data on a conditional basis.

When Kafka is unavailable, the producer continues attempting to send to the Kafka broker until a timeout is reached. On timeout, the records are written to a separate log file on disk.

Request and response records are sent in JSON format.

The Kafka partition key used is the SessionId for the exchange. If none is available, for example if there is an error returned by the engine, then no partition key is used.

The 5G event streaming applications are delivered as images for container creation in a Kubernetes cluster using a Helm chart. The following sections describe the installation process. The procedures assume you have knowledge of and access to the kubectl tool.

Configure 5G event streaming by providing values for properties in one or more Helm values files.

The 5G event streaming applications are configured in the Helm values file, the nf.yaml file, and an application.yaml files for each application.

You can apply configuration for 5G event streaming applications in several ways using the Helm values chart. These methods are not mutually exclusive and can be used together.

MATRIXX Event Streaming describes the tasks required to create custom event streams for events received by your MATRIXX environment. An event stream is sent to the Event Streaming Framework from the Event Stream Server running on MATRIXX Engine. The Event Stream Server provides the APIs, libraries, and other files needed to create custom event streams. The Event Streaming Framework provides connectors for sending event stream data to event stream platforms, such as Kafka and ActiveMQ.

Use event streaming to integrate downstream message systems with MATRIXX. Fully optimize these message systems to filter, transform, and deliver events to multiple secondary targets.

Use these steps as a summary of tasks required for event streaming in a MATRIXX environment.

An Event Streaming Framework connector is required to stream events. Out-of-the-box connectors are explained in this section. For information about setting the log level for individual connectors, see the discussion about monitoring event streaming in MATRIXX Monitoring and Logging.

The Event Stream Server and Event Streaming Framework require administration tasks. The Event Streaming Framework administration tasks includes manually recovering events from streamed event files.

MATRIXX Administration describes how to monitor MATRIXX Engine components and to perform daily operations for maintaining a geographically redundant system. This includes administration for the engine, Traffic Routing Agent, MATRIXX gateways and web apps, and Notification Framework. It also provides information about recovering from a total system failure.

The topics in this section have information about maintaining, managing, and resolving issues with a MATRIXX Engine installation.

The topics in this section describe administering Traffic Routing Agent (TRA) servers, including starting and stopping Traffic Routing Agent nodes and clusters. The information in this section applies to all Traffic Routing Agent functions unless otherwise noted.

The topics in this section describe administering the Route Cache.

US tax data is imported from CCH tax data, compiled in My MATRIXX, and output as compact MATRIXX Data Container (MDC) files, including an MDC file containing tax database metadata and status information. MDC files are packaged into a .zip file and loaded into the MATRIXX tax database.

This section has information to help identify and resolve system issues.

MATRIXX Web App Administration describes the tasks required to install and administer MATRIXX web apps as containers, using Docker and Kubernetes.

MATRIXX includes the following MATRIXX web apps.

In a non-containerized installation of MATRIXX, configure MATRIXX gateways and web apps using files in the /opt/mtx/conf directory in the pod(s) hosting those components. In a cloud native deployment, configuration files can be provided in the /opt/mtx/conf directory of the component container(s) using the following methods:

Configure My MATRIXX by configuring properties, setting up a pricing repository, configuring authentication, and importing or exporting third-party pricing data.

MATRIXX Backoffice Customer Tool can be deployed on the local host or a remote system that communicates with MATRIXX Engine through Gateway Proxy and RS Gateway.

This section has information to help identify and resolve web app issues.

MATRIXX Monitoring and Logging describes monitoring and logging for MATRIXX components in a MATRIXX environment.

The following information describes monitoring metrics and alerts information for MATRIXX. MATRIXX Support recommends using the Prometheus and Grafana third-party products to monitor a MATRIXX environment, along with aggregated logging.

The following describes logging information for MATRIXX.

The following information describes tracing information for MATRIXX.

The following information describes monitoring different components for MATRIXX.

MATRIXX Policy describes the tasks that must be completed to configure MATRIXX Policy Application functionality and provides overviews, recommendations, and conceptual discussions to help you understand these tasks. In addition, it describes the supported Diameter policy AVPs and MATRIXX Policy Application SubMan APIs.

The MATRIXX Policy Application provides the business logic and integration into a third-party Policy Control Function (PCF) to support real-time policy decisions and rules. It enables your PCF to deliver flexible policy and charging control rules to your 5G network.

The 3G/4G MATRIXX Policy Application provides the business logic to support real-time policy decisions and rules. It allows charging and network quality of service (QoS) to be flexibly and dynamically linked to customer, service, and network parameters.

Policy configuration in My MATRIXX includes both session management and spending limit configuration.

A MATRIXX Policy failover can be due to a hard failure or can be planned.

During policy profile selection, product offers are evaluated in descending order from highest to lowest priority. Policy profiles are collected for Sy and N28 policy counters, Gx command-level QoS, and N40 TIME_LIMIT and VOLUME_LIMIT usage triggers.

You can configure a product offer so that Spending Limit Control/Sy policy components and Session Management/Gx components are applied when quota is authorized or denied.

The Sy policy counter APIs include MtxRequestDeviceEvaluatePolicyCounterSet and MtxRequestDeviceQuerySession.

MATRIXX Engine supports the Sy and Gx interfaces for policy control.

MATRIXX Kafka CDR Consumer provides information about how to install, configure, and extend Kafka CDR Consumer and its out-of-the-box extensions.

Kafka CDR Consumer is a cloud native Apache Kafka Consumer microservice that consumes charging data records (CDRs) that are injected into Kafka topics by external systems or from MATRIXX CDRs. The offline Kafka CDR Consumer retrieves the events from the Kafka topics and injects them into MATRIXX Engine for usage rating and charging.

Deploying Kafka CDR Consumer and extensions involves installing and configuring the Kafka CDR Consumer and extension Helm charts. This section explains how to install and modify the Helm charts and the properties you configure. For information about the Helm properties, see the discussions about Kafka CDR Consumer properties and each extension.

Use aggregated logging and the Prometheus and Grafana third-party products to monitor Kafka CDR Consumer.

The TAP3 JSON Kafka CDR Consumer is an out-of-box extension that consumes JSON-mapped TAP3 messages from Apache Kafka topics and maps them to MtxDiamRoMsg messages for MATRIXX Engine rating.

The Diameter CDR Kafka CDR Consumer is an out-of-box extension that consumes plain MtxDiamRoMsg protocol buffer binary files and maps them to MtxDiamRoMsg charging messages for MATRIXX Engine rating.

The CHF CDR Kafka CDR Consumer is an out-of-box extension that consumes plain Mtx5GMsg compact MDCs (CMDCs) and maps them to Mtx5GMsg charging messages for MATRIXX Engine rating.

You can create your own custom Kafka CDR Consumer extensions for charging implementations that are not covered by out-of-box extensions delivered with the Kafka CDR Consumer.

All Kafka CDR Consumer extensions can use the same Helm chart. After you create an extension, you can use a Helm values file to manually deploy the image. Each extension you create can have its own values file.

MATRIXX Pricing and Rating provides an introduction to MATRIXX pricing and rating functionality and describes how to define the catalog components necessary for rating and policy selection. It also provides an overview of the MATRIXX rating process and an introduction to My MATRIXX, a web-based user interface application you use to create and manage product catalogs.

The following information describes MATRIXX Charging Application rating functionality.

MATRIXX Pay Now describes the tasks required to configure MATRIXX Pay Now and the MATRIXX Payment Service that enables Pay Now and provides overviews, recommendations, and conceptual discussions to help you understand these tasks.

MATRIXX Pay Now enables the Charging Server to request immediate payment for product offer and bundle purchases, postpaid balance payments, and recharges from a Payment Gateway Provider. Subscribers can make quick and secure purchases using payment methods such as credit and debit cards.

System administrators must configure the Payment Service to enable communication between Apache ActiveMQ, MATRIXX Engine, and the Payment Service. In addition, they must configure the Payment Service third-party Payment Gateway Provider properties file location.

This procedure describes how to run the Payment Service as a service.

Each Payment Gateway Adapter can support multiple features, operations, and payment methods.

Each client that communicates with the Payment Service has different requirements based on the payment gateways that it supports. Client developers should contact MATRIXX Support for information specific to their client implementation.

MATRIXX Subscriber Management provides an overview of subscriber-related data, including users, groups, subscriptions, devices, balances, and notifications. You can capture any attribute of a subscription and base rating on it, enforce subscription and group spending limits across all services and networks, and notify users associated with subscriptions and groups when the subscriptions and groups are nearing spending limits.

Authorization is the process of verifying the subscriber's balance has the amount required to allow usage. MATRIXX Engine supports service authorization and cut-offs to ensure subscriber usage is valid and revenue loss does not occur.

You can associate a subscription with a user in a many-many relationship using the user APIs.

When a network message is received, the device information is used to guide the service usage to the subscription. A subscription can have any number of associated devices.

Managing subscriptions includes adding subscriptions to groups, removing subscriptions from groups, setting the status of subscription objects, and associating users with subscriptions. You can perform these operations by using MATRIXX Backoffice Customer Tool and any custom applications that call the SubMan APIs.

You can create, provision, and delete devices by calling the SubMan APIs and scheduling automated tasks.

Managing users includes creating and deleting users, associating users with subscriptions, and assigning roles to users. You can perform these operations by using MATRIXX Backoffice Customer Tool and any custom applications that call the SubMan APIs.

Managing product offers includes purchasing and canceling product offers, and removing expired product offers. You can purchase and cancel product offers by using MATRIXX Backoffice Customer Tool and any custom applications that call the SubMan APIs. Expired product offers are removed from _glossary/subscription.html and group wallets automatically after a configured amount of time.

Use purchase packages to dynamically group catalog items and package them so they can be purchased as a single unit by a subscriber or group. Purchased items can be added to or removed from a purchase package through the purchase package APIs without requiring pricing changes, providing a single entity for promotional and business operations.

Rehoming is the process of moving a user, group, device, or subscription from one sub-domain to a different sub-domain in a multi-domain platform.

MATRIXX Subscriber Management API provides information about the MATRIXX Engine APIs, including functions, syntax, and result codes, and the MATRIXX Engine REST and Java API implementations.

The following information is an overview of the SubMan APIs and architecture.

The following sections introduce how the various in-memory objects are managed.

The SubMan API reference includes SubMan API and MDC descriptions.

RS Gateway supports the REST API bindings for accessing subscriber data in MATRIXX Engine. RS Gateway consists of an rsgateway application and a set of REST APIs.

This part describes how to use the REST API bindings to interface with MATRIXX Engine.

This part provides an overview of how to use the Java™ API binding for the SubMan v3 API as an interface to the MATRIXX Engine.

MATRIXX Business API SDK provides the APIs, libraries, and other files needed to create a customized version of the RS Gateway.

The Business API SDK is a flexible framework that includes a set of tools to manage, customize and extend Rest Services Gateway (RS Gateway) for customer-specific business needs. Using the SDK, you can extend existing projects or create entirely new projects to add, replace, or modify services that leverage existing functionality.

The Business API Gateway is a development framework that includes the Business API SDK, Rest Services Gateway (RS Gateway), Gateway Proxy, and application tier. It allows custom mobile applications, web clients, and other custom implementations to integrate with MATRIXX.

You create extensions using a Maven archetype and then add those extensions to the RS Gateway as JAR files.

You can create a custom filter by creating a named filter or a filter class. A named filter is useful for simple filters while a filter class should be used for complex filters (for example, when the returned results must be modified).

When you upgrade the MATRIXX software, you must upgrade the Business API SDK as it is possible that files have changed or have been deprecated. Use the manage_integration_project.py script to remove the current release from your project directory structure and upgrade to the latest release. You should do this even if your files are not checked into Subversion.

My MATRIXX Help provides information about My MATRIXX, a web application that offers a central location for creating pricing plans and configuring MATRIXX charging and rating behaviors. My MATRIXX is intended for pricing administrators who are responsible for creating and maintaining pricing plans and for IT administrators or developers who configure the rating and charging behavior of the online charging system.

The following information describes the My MATRIXX interface.

You use My MATRIXX to validate and compile the pricing configuration file, compile pricing, and set up and manage user roles and domains; create and manage catalog items and catalogs, manage eligibility features and rules, and manage the Normalizers interface; create and manage balances, pricing, offers and bundles, general components, and application-related components; and policies for charging and rating. Use General Configuration to create components that support pricing items and charging functionality such as announcements pricing components, attribute definitions, denial codes, products, decision tables, Final Unit Indication (FUI) profiles and generators, general ledger transaction types, notification profiles, normalizer templates, and subscriber information query actions, profiles, and generators.

The following information describes the tasks that can be performed using the My MATRIXX Home menu.

Catalog Configuration contains the Catalog Items interface that you use to create, change, or delete catalog items; the Eligibility interface to manage eligibility features and rules to determine whether a subscriber, group, or device is eligible for a catalog item; and the Normalizers interface you use to edit normalizers.

Charging Configuration has the interfaces you use to create and manage balance, pricing, product offer and bundle, general, and application-related components.

Policy configuration components are used by MATRIXX Charging Application and MATRIXX Policy Application for charging and rating.

MATRIXX Backoffice Customer Tool Help describes how to use MATRIXX Backoffice Customer Tool to view and manage subscription and group account information, including purchased offers, services, and balance amounts. MATRIXX Backoffice Customer Tool users are granted privileges (including managing subscriptions and groups) based on the user role they are assigned. For information about what roles MATRIXX Backoffice Customer Tool supports, see MATRIXX Security.

Log into MATRIXX Backoffice Customer Tool with the following procedure.

When you log into MATRIXX Backoffice Customer Tool, the Home page displays.

If enabled, use the debug mode to retrieve information about the MATRIXX Backoffice Customer Tool deployment for debugging issues. For more information, see the discussion about enabling debug mode in MATRIXX Backoffice Customer Tool in MATRIXX Web App Administration.

You can perform a general search for users, devices, groups, or subscriptions. In addition, you can search for an object by defining certain criteria. The available search criteria depends on the object type.

Use the User Summary page to display information for a user. Users have a many:many relationship with subscriptions and groups. If assigned the Admin user role, the user is the recipient of group notifications.

Use the Subscription Summary page to display information for a _glossary/subscription.html.

MATRIXX Backoffice Customer Tool allows you to assign devices to users and search for devices by Access Number, IMSI, Object ID, or External ID. If Login devices are enabled, you can search for devices by Login ID.

A group is a collection of one or more subscriptions, users, other groups, or a combination of those. A group can belong to one other group only, but a subscription or user can belong to any number of groups. Each group can have one or more optional administrators (a subscription or user with an Admin user role). If an administrator is added, it must be an existing subscription or user but does not have to be a group member. Use the Search page to display information for a group.

To view all the current offers in the MATRIXX Backoffice Customer Tool database, click View Offers on the Home page or click the Offers tab in the header on any page other than the main page.

To use a CSV file to add/modify subscriptions, groups, device, and users directly, click Bulk Operations on the Home page or click the Bulk Operations tab in the header on any page other than the main page. You must have the MTX_ROLE_BULK_OPS role to display this tab.

MATRIXX Third-Party/Open Source Licenses lists the third-party and open source software licenses that protect the third-party and open source software programs that MATRIXX uses.

This document lists the third-party and open source software programs shipped with MATRIXX. Except where noted, all software programs are integrated in code without modification.