 Hi everybody. My name is Amar Kodmanaban. I'm one of the maintainers on the Magma project. Today I'm here to talk about Magma, a cloud-native converged core with a specific emphasis on the use cases that we're seeing market traction on and its cloud-native architecture. First, a brief introduction to what is Magma? Magma is an open-source packet core that's licensed under a permissive BSDV3 license. It's 3GPP generation agnostic in the sense that it can support both 4G and 5G architectures and its access network agnostic in the sense that it can support Wi-Fi deployments as well. This can be conceived as something similar to a mobile data offload or a t-back type architecture where a AAA and a PCRF and a PCEF integration exist within the Magma framework. The distributed EPC itself has a very small footprint. What this allows us to do is we can run the entire EPC all the way at the cell site or in slightly more centralized locations like edge pops or even in public clouds. The entire deployment is managed through a single orchestrator. This gives a single pane of glass that sort of abstracts away the distributed nature of Magma. This is what we call as moving the network from a device-centric way of managing things to a network-centric way of managing things. The interfaces that Magma implements are standard interfaces. For example, S1 for the 4G infrastructure and 1N2N3 for 5G infrastructure and standard radius and GRE termination for Wi-Fi infrastructure. This allows the Magma core to interoperate with any RAM that is based on standards. Most importantly for this talk at least is that Magma is a scale-out sort of a packet core as opposed to a scale-up packet core. This is fundamental to what makes it cloud native. For brownfield deployments, Magma also exposes REST APIs. These REST APIs allow integration into existing OSS infrastructure as well as a Federation Gateway which supports standard diameter interfaces that allows operators to integrate into existing PCRF OCS HSS type traditional core elements. Switching gears a little, here are the following use cases that we've been seeing Magma's market traction on. Primarily, Magma is a really good fit for fixed wireless access. This is where we've been seeing commercial deployment over the last 12 to 18 months. The big advantage with Magma and fixed wireless is because of its small form factor, you can actually deploy the access gateway at the sales site. By doing local breakout and network policy application at the edge, we're sort of making the LTE deployments transport network agnostic. GTPC which is S1C is very sensitive to jitter and a lot of ISP and rural deployments end up using microwave or unlicensed spectrum for backhaul or even satellite in some cases. The local breakout aspect of fixed wireless allows us to terminate all of the S1 signaling and then use IP as the main transport over a unreliable backhaul. The second use case where we are seeing some traction is the Wi-Fi access use case. This is similar to our mobile data flow model. So what this gives you that is slightly that's better than traditional T-VAC type architectures is that because Magma contains a PCEF as well, the Wi-Fi or mobile data offload traffic does not hit your expensive traditional P gateway. Also by using local breakout operators have the ability to transit of the existing infrastructure as early as possible. The use case that we're seeing more traction recently is the private LTE use case. This is mostly driven by the CBRS sort of deployments that are happening in the US. I have a specific slider on private LTE so I'll skip the deep bed for now. The two use cases that we're looking to prioritize in H2 for which we're doing a few lab trials as well as you know hopefully a field trial in the July or August timeframe are on network expansion and 5G. So network expansion allows operators to use Magma as a way to augment their traditional or the high value core networks by using Magma to extend it into more remote and rural areas. Further the insulation that Magma provides to the traditional MME P gateway and S gateway allows the operator to introduce new RANS radio elements and iterate on their evolution independent of their mainstay core. On the 5G SA site we're looking to leverage Magma's distributed architecture to pilot 5G fixed wireless use cases. We also support NSA in alpha form at this point. A quick deep dive into Magma the private solution. So the big driver for why Magma is a great fit for a private solution is its distributed form factor. The local breakout at the edge allows enterprises to deploy their own workloads and this is ideal for IoT and you know internet 4.0 type workloads. Magma also allows interconnect to existing infrastructure or service provider networks and this allows these sort of private networks to also develop as mutual host networks. The support for multi-tenancy allows a single service provider or an SI to offer services to multiple enterprises using the same centralized cloud managed infrastructure. Further a big advantage of using Magma for the private solution is that the upgrade from 4G to 5G is just a software upgrade. In fact going forward most Magma access gateways will support both the 4G and SA protocols as well as the N interfaces. Lastly the cloud native scale out micro form factor where you know Magma can fit into a box that's even just 2V CPU sort of very lightweight 2V CPU boxes allows Magma to be deployed at the extreme edges and this is particularly useful for you know IoT or like fairly remote sort of use cases where you know there are probably a couple of E-notes and you want a co-located sort of an EPC in that deployment. Just to re-emphasize the point on the form factor this is a sample Magma FWA bomb from one of our production deployments. As you can see here the Magma infrastructure is running on a four core atom box that's running a CPU at 2.5 gigahertz and with 4GB RAM. This box can support up to a thousand subscribers as well as you know 12 E-notes. So depending on your need you know such a small form factor can be a great fit for a fixed wireless or a private LTE or a 5G use case. Quickly a high level overview of the roadmap so we're almost at release 1.5. Release 1.5 should be available over the next couple of weeks. The key features in 1.5 are inbound roaming, S1 handover and a bunch of stability and usability improvements. 1.6 which we're targeting towards for the end of June is going to add 5G FWA support for SA enough to support lab trials as well as NSA support. We're looking to extend the 5G SA support in Q3 to introduce network slicing as a capability as well as you know harden the 5G FWA offering. So for folks who are planning to use a 5G SA of Magma we'd recommend the September release for when you can take it out to field. It would be lab ready by end of June for sure but for all the robustness improvements we are anticipating them to land by the end of September. This is about a six to eight weeks delay from the roadmap that we had announced in February as part of the Magma developer conference. A couple of things that we've also learned along the way is that the 5G SA ecosystem is also a little bit immature and so having reliable end-to-end testing infrastructure has proven to be a bit of a challenge and this is sort of slowing down our ability to iterate fast. Cool, switching gears again. So we're going to talk a little bit about Magma under the hood and what makes it cloud native. So the best definition that I've heard for what makes a workload cloud native or not is the difference between pets and cattle. Pets are unique, they're hand raised and cared for. When they get ill we nurse them back to health. They're all distinct and this is a clear definition of a workload that is not cloud native. A workload that is cloud native in turn looks a lot more like cattle. Cattle are almost identical to other cattle and when they get ill you get another one. So the transition that we're trying to affect in the service provider network with the Magma Converged Core is that of a transition from a traditional core to a cloud native core or in other words the transition from pets to cattle. There are many other definitions of cloud native workloads like stateless, is a container deployable, all of those are all attributes of a cloud native network. The fundamental thing though we'd argue is the difference between pets and cattle where if you have a cloud native network you're much more tolerant to failure and almost all your nodes are fairly identical. So with that framing in mind what are the key attributes that we think are important to create such a cloud native sort of core network? So the first principle that we think is important is the need to allow for failure. So a node failing should not impact the overall network. It should be a contained failure. This is pretty similar to what you notice in the data centers. Workloads are fairly distributed so taking out a router only causes failure on a particular path and the ECMP fabric is comfortable recovering for that period of an outage. So it's much more important solving for designing for a system where failure is a given. The second one is given that failures are going to happen. We need to simplify the failure semantics. Failures need to happen in a very well-defined way and these need to map to clean state boundaries. So this makes it easy for us to understand what state actually gets affected by a failure. And the third one is that we need to simplify recovery. So well-defined state and propagation of recovery is important to allow for a service to come back up. So this goes back to principles like clear demarcation of who owns state and clear propagation principles for the state to be repopulated. So allowing for failure. This one is fairly obvious. So scale-up devices have a large fault domain and they fundamentally need to be treated like pets. By distributing the EPC or the 5GC what we're trying to achieve with Magma is that the fault domain of each device is pretty small. Further, the finer the fault domain, the easier it is for us to upgrade these nodes. Implicitly, this improves agility a great deal. This is one of the key things that we're also learning at Facebook in our data center is that by pushing network workloads to smaller distributed form factors, we're able to upgrade them at an incredible velocity and that helps us keep our competitive edge. Before I talk about the state failure domains as well as recovery model, it is worth clarifying the two control planes that are in play in a 3GPP network. The first control plane as defined by 3GPP is actually an in-band signaling function that allows a user plane channel to be established for a wireless device. This is actually looking at the network from the UE standpoint. But an SDN control plane is the function that makes changes to the data plane to ensure that a desired state is realized based on discovered state. So take for example a UPF node. In a 3GPP sort of control plane view, the UPF node is purely a user plane element. But from an SDN standpoint, the UPF has a significant network control plane as well. So magma at the end of the day implements a hierarchical control plane motivated by SDN principles. Even though the end architecture looks a bit like cups, it is more than cups in the sense that magma implements a control plane at the edge and a control plane at the central location. So to simplify failure semantics, as I briefly described, we have a two control plane model. There is an edge control plane that encapsulates all edge state. What do we mean by edge state? It is the state associated with the UE that is maintained by the network. This is sort of transient or runtime state that gets generated by the UE signaling and establishing a user plane with the network. There is a central control plane which runs in a public cloud or in a more centralized location that is responsible for maintaining the global state. It is the authoritative owner of this global state. This is an always available application and today in magma it is just a pretty standard Kubernetes application. The advantage of this distinction of the edge control plane and the central control plane is that the edge control plane has a very clearly defined failure semantics. It aggregates the runtime state of the network and if an edge host machine goes down, you have lost all of the control or the runtime state associated with the UE as maintained by the network. By using standardized distributed systems techniques, like persisting this runtime state to a key value stored like Redis, which is what we do in magma, and replicating the state to the cloud or through other distributed system principles to other Redis nodes, we have the ability to checkpoint and restore this runtime state. This makes for a cleaner implementation of HA. The role of a central control plane is to communicate with an edge control plane, understand the discovered state, say a UE came onto a network and then use the desired state as understood by the configuration of the network to push down a realized state model that then gets implemented by the edge control plane through forwarding rules at the UPF or the PGP depending on which generation of 3GPP you're working with. The next principle around moving to a more of a cloud native sort of a core network is to simplify the recovery semantics. So let's take an example of N4. N4 in 3GPP is roughly defined across two planes. The first one what we call as node level procedures, like things like load reporting and hard beating, and then the second one is around session level procedures, which is the actual business logic of the SMF and the UPF. Our assertion here is that to implement a cloud native sort of a converged core, we need to remove the node level procedures out of the N4 implementation and dedicate it to a service control plane similar to like Kubernetes and model that as Kubernetes operators. The advantage of doing this is that say if a node goes down or a node comes back up, both your 3GPP point to point control interfaces and your Kubernetes are not trying to make independent decisions on how state needs to be restored. So what we think we're trying to what we're trying to do with Magma is to remove the sort of node to node interface procedures from the standard interfaces like N4 and only focus on the service level procedures like the session related procedures around session establishment modification and release which go from SMF to UPF and the session reporting which moves from the UPF to SMF. So the key takeaway from this principle is to delegate point to point node interfaces to the service control plane where possible. This allows the service control plane to make consistent decisions across all nodes in the network. The second aspect is how do we propagate the state? So taking a step back, the interaction between the SMF and the UPF is mostly about state synchronization. There is a clear owner for each sub state. The UPF node state is owned by the UPF. The session rules are owned by the SMF and the session stats are owned by the UPF. The existing 3GPP standards are edge interfaces. So they model all of the state synchronization using CRUD. What we assert is that for better reliability and to simplify recovery semantics especially given that we know state is uniquely owned by each of these devices. We think modeling all of this state as level interfaces is a much cleaner way of doing this. So what level interfaces are set based interfaces? So at any point in time the UPF and the SMF interact over set interfaces. This is very similar to the transition that has happened from SOAP to REST. SOAP was much more of a CRUD than stateful model and REST is now much more of a resource based model where we only use puts and gets. There's a great talk by Ullash that's available on YouTube which talks about the abstractions in Magma. That further clarifies this point in greater detail. So summarizing Magma product focused verticals. Currently we are focused around fixed wireless, Wi-Fi core and private networks. Magma 5GSA support is in alpha. We hope to be lab ready by the end of June and feel ready by September. Slizing support would be introduced in the September release of 2021. The Magma architecture is cloud native and the reason it is cloud native is it is an implementation that is focused on scaling out versus up similar to the pets versus cattle analogy. Magma adheres to the SDN principles of control plane and thus implements a hierarchical control plane. This is slightly different from a 3GPP cups implementation which just talks about control and user plane separation. It adds an additional slice in terms of the control plane being edge versus centralized. Thank you, everybody. Here is some additional information on how to plug into the project. There's a website. There's also all of this code is fully open source and all of our development happens in the open. GitHub.com slash Magma. There are two talks that give a much more detailed overview of the Magma principles. The first one is by me, introduction to a distributor DPC. And then the second is by Oolash on Magma abstractions and interfaces, both of which are available on YouTube. Thank you very much.