Multi-Domain Deployments

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

Incoming 5G traffic is handled by one cross-domain CHF instance (CHF-in in Figure 1), and one Traffic Routing Agent (TRA-RT/DR) routes traffic to domains based on subscriber information. The CHF-in instance and the TRA-RT/DR must be the same version as the highest version MATRIXX Engine in any sub-domain in the deployment. CHF-in must be pinned to the highest common schema version and to service provider schema version 1. For example, if you have two deployments, one version 5241 and one version 5242, the CHF-in must be version 5242, pinned to schema version 5241 and service provider schema version 1.

A CHF instance in each domain (CHF-out-d1 and CHF-out-d2) handles outbound 5G traffic. These CHF instances do not require any version pinning during application of schema changes. Outgoing Diameter and SIGTRAN traffic is connection-oriented, using the received TCP connection. 5G responses return using the ingress path, with 5G notifications and payments using a domain-specific egress path.

The version of the MDC schema is pinned to the highest common version across domains. Private MDCs must use fields common to all domains for 5G messages. The key used for these fields must also be the same across domains. 5G fields are linked to the network function specification version. Outgoing requests use gateway components in the domain, using the MDC schema and ActiveMQ Gateway in the domain.

Each domain must have its own set of MATRIXX gateways and web apps.

All engine and sub-domain IDs must be unique. For example, if domain 1 has sub-domains 1 and 2, domain 2 must not have sub-domains numbered 1 or 2.

Figure 1 illustrates the inbound and outbound connections.

For more information, see the discussion about adding a domain in MATRIXX Installation and Upgrade.

One Cluster Per Site

The reference architecture supports deploying different domains to separate Kubernetes clusters or within the same cluster. Separate clusters allow an extra degree of separation required by some hosts or tenants. For example, if the tenants are mobile operators of a group host, the failure of a Kubernetes cluster cannot impact more than one tenant. Tenant domains are therefore expected to be deployed in separate clusters, likely physically close to the tenant, depending on the group cloud capability.

Figure 2 shows multiple domains deployed in namespaces. An ingress namespace has the TRA and CHF components common to all domains.

Domain Isolation

Namespaces allow a logical isolation between domains in a Kubernetes cluster. Deployments can optionally separate domains by Kubernetes cluster if required.

Figure 3 illustrates a deployment using a Kubernetes cluster per domain.