Nokia cMAG-c CUPS solution

The cMAG-c offers the familiar operational experience of the Nokia TPSDA product line, which includes SR platforms and the MAG-c. However, the cMAG-c is designed from the ground up for a cloud-native environment. Specifically, the cMAG-c is a Kubernetes (k8s) application that addresses limitations found in classic software architecture by allowing a declarative approach for deploying, scaling, and managing application pods.

Similarly to all other cloud-native software, cMAG-c applications need to be divided in stateless and stateful components to maximize the flexibility of scaling up or down. To ensure maximum efficiency and scaling, the cMAG-c architecture is further divided up into the following layers:

• load-distribution layer

  The load distribution layer redirects all control packets received from the UP and distributes them to pods in the cache layer for processing.

• cache layer

  The cache layer holds the temporary state until the processing is complete. Its purpose is to avoid retrieval of the full subscriber state information from the database in the data store layer. The database stores multiple millions of subscriber sessions, and retrieving individual sessions from the data store layer takes more time compared to retrieving it from the cache layer. In addition, the session management pod is instantiated in this layer, and it holds sufficient cache information to complete the control processing currently in progress. When the subscriber session setup is complete, its data is transferred to the data-store layer for long-term storage. The goal of the cache layer is to ensure horizontal scaling of pods to handle the heaviest load of processing when it occurs.

• coordination layer

  The coordination layer consists of stateful pods, such as ODSA and the UP manager, and it is used to store stateful information about the subscriber such as the assigned address , circuit information, subscriber ID, and so on.

• data-store layer

  The data-store layer is responsible for the long-term data storage. This is a critical component for storing the subscriber state and the configuration of the overall system. The data-store layer is also a critical component for resiliency. When other layers experience failure, the data-store layer backs up data and provides all the information necessary to restore the subscriber state to any pods in the coordination layer.

With the architectural split shown in cMAG-c high level architecture, the cMAG-c achieves improved operation with all the advantages of cloud-native software, namely agility, scalability, and resiliency. Application pods can be destroyed or recreated freely and pod software upgrades are possible without shutting down the entire system.

The database is a crucial part of the cMAG-c architecture, because it stores both state information and system configuration in case of failure of any of the components of the load balancing, application pods, or cache layer. When the application pods are recreated, the database can restore the subscriber session by restoring the necessary state information in the application pods or cache. In addition, any new application pods can invoke the database for full state information.

For more information about the cMAG-c architecture, see the cMAG-c Installation Guide.