Here in this post we will discuss about underlying principles of the Magma Access gateway, Magma components.Magma differs from traditional implementations of 3GPP in a few important respects, particularly in the way it achieves independence of the radio access technology for most of the system.Here in this post we will discuss the main building blocks of Magma , key design principles of Magma and main benefits of the Magma architecture for better reliability, scale, operations and heterogeneity.
So first before we discuss each and every component of Magma we list below the four components of magma:
- The Access Gateway (AGW), which implements user plane and mobility management functions for a mobile packet core;
- The orchestrator, which provides a central point of control and configuration for the mobile core and interfaces with many other components;
- The Federation Gateway (FGW), which allows Magma to extend and interoperate with existing mobile networks;
- The Network Management System (NMS), which provides a graphical user interface (GUI) for provisioning and operating Magma-based networks.
Advantage of Magma over 3GPP Implementation?
one of the main operational advantages of Magma over a traditional 3GPP implementation. In most 3GPP implementations, there has to be configuration of individual components, whereas Magma centralizes such configuration in the Orchestrator. The implementation is largely independent of the radio access technology (4G/LTE/5G or others such as WiFi).
- Separation of control plane and data plane.
- Store configuration state centrally, and runtime state at the edges.(Like SDN)
- Push data plane state to the edge.
- Magma uses a common core design for all radio access technologies
- Software-controlled data plane.
- Distributed kind to architecture to connect to different components of MAGMA
What is the Aim of Magma ?
Magma aims to provide a mobile core networking solution that will be:
- 3GPP networks compatible
- Independent of underlying radio technology or spectrum (4G/5G/WiFi/other)
- Manageable for operators providing network access in remote regions
YOU MIGHT ALSO LIKE :
Magma Architecture Overview
Below figure shows the overall Magma Architecture This image below shows the AGW, Orchestrator, and FGW. It also shows a number of interfaces to components in the “operator core”, which is relevant in the case where Magma is used to extend the operator’s existing mobile network. We will dig into the details of this diagram and those interfaces later.
Image source: https://github.com/magma/magma
The Orchestrator provides the configuration interface for Magma via REST APIs. It also integrates with a range of other systems to provide FCAPS (fault, configuration, accounting, performance, security) management capabilities (as they are known in the telco world). In the model just described, it implements the management plane for Magma. The Orchestrator also implements the centralized parts of the control plane for Magma. Based on the configuration information and observed (or discovered) state gathered from the network, it pushes instructions to the appropriate AGW that will be locally implemented.
Few Base stations per Access Gateway.A single Orchestrator connects to multiple Magma access gateways.To relay information to AGW and vice versa gRPC(Remote procedure call) is used .
The Orchestrator functionalities are:
- Metrics querying (Prometheus and Grafana)
- Event and log aggregation (Fluentd and Elasticsearch Kibana)
- Network entity configuration (networks, access gateways, federation gateways, subscribers, policies, etc.)
Access Gateway (AGW)
The Access Gateway (AGW) provides the runtime functionality of an EPC. These functions include (in the case of 4G) User Plane functions SGW, PGW, and Control Plane function MME. The Orchestrator receives the runtime state from AGW in response to that the Orchestrator send the configuration commands to AGW.
Some major functional blocks of the Access Gateway are as follows:
- Device Management
- Access control & Management
- Subscriber Management
- Telemetry & logging
- Session and Policy Management
Federation Gateway (FEG)
Federation Gateway acts as a proxy between the magma AGW and the operators network.This enables core functions, such as authentication, data plans, policy enforcement, and charging to stay uniform between an existing MNO network and the expanded network with Magma.
A simple way to think about the FEG is as a proxy: on one side it speaks 3GPP protocols (SGs, S6a, etc.) and on the other it speaks GRPC.The FEG handles control plane connections to the operator core.Both FEG and AGW are controlled by the Orchestrator.
There can be two FEGs (for high availability), as this is sufficient for the control plane traffic load.In comparison to the we need dozens of AGWs to support large networks.
When a message is send from AGW ———>FEG ,the message is send via Orchestrator,the Orchestrator determines the appropriate FEG based on the destination network.In case of FEG ———>AGW the directoryd services hold the required mappings of UEs to AGWs so that correct AGWs can be selected.
The Federation Gateway communicates between the Magma deployment and standard 3GPP protocols using interfaces:
- Online Charging System (OCS) using the Gy interface.
- Home Subscriber Server (HSS) using the S6a interface.
- Policy & Charging Rules Function (PCRF) using the Gx interface.
NETWORK MANAGEMENT SYSTEM
The NMS provides a GUI that is implemented on top of the REST API of the Orchestrator. This can be used to access features that might not be supported by the existing OSS/BSS, or can be used in greenfield deployments where no other OSS/BSS exists.
YOU MIGHT ALSO LIKE :
SUMMARY OF MAGMA ARCHITECTURE AND MAGMA COMPONENTS POST:
Here in this post we have discussed all the concepts related to MAGMA like Magma Architecture,Magma components,difference between MAGMA and 3GPP network Implementation.Hopefully you have gathered some information related to Magma.If you liked the content do share and leave comments.