 The loss has been with the MAGMA team since late 2019, and he's one of the lead code maintainers for the project, and he serves as the area lead for the 4G and 5G services running on MAGMA. Prior to Facebook, joining Facebook and the team, he worked in a career across leading industry R&D labs on next generation wireless networks, distributed systems, content delivery, and network optimization. And I can tell you, and the community, ULOS is always a joy to work with. So please, without further ado, join me in welcoming ULOS. Thank you. All right. Thank you very much. Feel for the very nice introduction. I hope everyone can hear me. Your slides look great, ULOS. All right. Let's start. So I have been with the MAGMA project over a year now, and I should say it is really quite exciting to be part of the MAGMA development team. It is exciting because MAGMA has a lot of prospects in terms of disrupting and transforming how we provide a converged wireless connectivity to masses. It is very exciting because of the growing, solidly growing ecosystem partners who are invested in its success. But it is also very particularly very exciting for the software development community. Because of MAGMA's unique engineering approach in terms of how we try to solve the very hard problem of providing a low cost, high performance, highly available core networking fabric for the wireless edge. And while doing that, make it quite accessible for software developers so that they can take it and easily extend it for different scenarios and use cases. And in my talk, I will basically try to basic the common way what type of unique approaches we follow, what guides us in our day-to-day engineering decisions and roadmap discussions. With that, let me talk about what the content of the presentation is. It is divided in three parts. In the first part, I will spend a good amount of time talking about abstractions. This is not a general talk about abstractions. There are very nice materials out there, particularly I recommend people to watch Scott Shankar's talk about network networking abstractions. But I wanna basically approach this problem from the vantage point of abstractions for commerce access. And I will also provide maybe a critical look at how 3GPP failed maybe to deliver on providing proper abstractions. And in the second part of my talk, I will go into more MAGMA specific architectures decisions and abstractions. And I will wrap up my talk by shedding some light in terms of how we can evolve MAGMA furters so that as more and more partners are joining and more and more scenarios or use cases, we seek for how we can continue scale our architecture. And I will also conclude with two key take a waste from my talk as the final remark. So let's start with the abstractions. If you look at a technical definition of abstraction, it is really the process of removing physical details or attributes in the study of objects or systems to focus attention on details of greater importance. If you may, I mean, you can remove the physical details here and substitute it with low level details. The reason why we wanna focus on high level details is to trade off complexity with simplicity so that people can easily make decisions on how to scale their system, how to manage their system and how to extend it with new services. But the definition maybe is easy or straightforward, but when we look at reality, we see that abstractions are really hard to deliver. In a lot of systems, actually, we see that engineers or product owners, they are on the side of complexity rather than providing simplicity. Often, we end up with leak abstractions. We see this tendency to us over optimization across layers. We see information, data, low-level attributes moving between layers, between services that they shouldn't be aware of those low-level details. A lot of times, we trade off performance benefits or short-term development velocity over the long-term targets of systems, scalability, modularity, and reusability. Another pitfall engineers fall into is they try to provide a lot of features with a lot of knobs to play with, and we end up with these fat abstractions. But in reality, very few of these features are frequently used, and a special mastery is needed if one wants to use most of these features. The third issue with abstractions is in many times, we end up with requiring domain knowledge, and this is particularly true for the 3GPP-related system solutions. We notice basically with our experience with a lot of partners, 3GPP is particularly overwhelming for new developers, and it has a lack of usability across domains when you change your scenarios. Again, you need to have a lot of deep knowledge into the stack, and so that you can basically write the, write adaptation layers basically for that architecture, or in some cases, it is actually an impossible task even to transfer one domain application to be used in another application. And test of time. Can my abstractions survive multiple generations of technology? Unfortunately, for many systems, we develop for the wireless over the years, they do not. They do not basically pass this first test like the counterparts like the CPIP layering or HTTP that survived over many decades now. So when we do not deliver the right set of abstractions, Converge Core looks something like this. Basically what we end up with is orthogonal stacks of technologies that don't have any shared functional services with each other. The packets process by one stack is completely unaware of the other stack. This is the ship's passing in the night type of model. And this, I mean, although we say Converge Core here, as you can see, there is nothing Converge here. It is just a bundling of multiple stacks in the same box. When we talk about Converge Core with abstractions, this is really the pictures in our head. And this is the guiding principle how we evolve the magma software. As you can see on the bottom part, on the south band interface from Converge Core to the specific radio access networks, we see a unified programmable data path. So each of these brands connect to the same data path. And we also see an access network control path normalization. So we try to terminate radio specific, radio technology specific exchanges interfacing as early as possible in the cornet in this Converge Core architecture. And on the top of these two normalization layers, we see our common services like access control, IP address management, session control, data path control. And when we look at the northbound interface, we see also another layer of normalization against the OSS-PSS systems. Regardless of how the policies, subscribers, virtual network or slice definitions, the configurations or how the metrics and events are consumed by these OSS-PSS layers, we try to normalize on that so that the Converge Core actually has the same set of services that can be reused again and again while we are integrating with different OSS-PSS systems. Now let me go back to 3GPP non-obstructions and I will just provide a few examples here. First problem with the 3GPP is there is an inflation of identifiers. I will not go through this list because it is a long one, but for each generation, we have this inflation of identifiers and what is worse from generation to generation, although the purpose of most of these identifiers remain the same, they keep changing the names. The second issue with 3GPP is there is a lot of generation-specific procedures, message names and information elements. Now contrast this against the simplicity of GRPC or TRIFT, that provides a lot of extensibility and new innovative ways of doing things, but yet they provide generational backward compatibility out of the box. The third issue is functions and interfaces rather than services. Yes, 5G is a big lift-up, but when you look at the interaction between the RAN and the Core network, as one interface and two and one interface, as well as the COPS model, if you look at how the SMF and UPF interaction is happening, you see that there is a lot of still interface-oriented approach rather than a service-based approach and they still need a lot more work. The fourth is the policy rules. A lot of red, radio access technology-specific policy rules leak through those policies, rather than following a more generic intent-based policies approach. There are also some abstractions like Bayer errors and APNs. Surface of it, they look like reasonable, but when you dig deeper, you see that again, they leak through all across main functions and they overload basically. For example, Bayer errors are there for both QoS management and Pat management in 4G, while APN is used for packet gateway selection and QoS policy as well. Now let's jump into the Magma architecture and its abstractions. Let's start with the architecture. When you look at the Magma Converge course, there are three different layers or components that are immediately visible. At the bottom, we have access gateway, which provides a highly scalable and distributed core that is edge-ready. So when you connect a radio access node to our access gateway, you can have a straight access, local breakout to the internet or local edge cloud. When you go top of the hierarchy, we have the orchestrator that provides a restful APIs to the OSS, PSS days, and that also provides a network management system, NMS, to provide the user-friendly interface to consume data, to visualize what is happening on the network at the access gateway for subscribers and to configure these functionalities and provide lifecycle management. The third box or functionality is the Federation gateway, which is there to provide access to the legacy systems where the mobile network operator might be providing like the PCRFs, HSS, OCS, et cetera. As you noticed, the distributed part of our architecture is really the access gateway part. The access gateway on its own is an abstraction. It provides us a small fault domain. Each of these access gateways can be upgraded individually. We can have cannery deployments where different set of features or generations might be running across these access gateways. And also very importantly, these access gateways don't need to be the same access gateway. They can be personalized deployments. Sometimes it is a distributed EPC LT specific. Sometimes it can be a carrier Wi-Fi-based access gateway. Sometimes it can be a 5G core. Sometimes it is actually a combination of multiple of these technologies. And as you may notice, this picture is like a leaf spine network where these access gateways are like your top of the rack switches basically. But they are standalone components. So if they fail, they don't impact any of the other access gateways. And when you replace that particular access gateway with a new one, it just carries on with no problems. The reason why it can do that brings us to next slide basically, how we abstract the config time and runtime. When we look at the configuration or config time abstraction, we see that there is a logically centralized orchestrator. Day zero and day one configurations are managed through APIs from this orchestrator, or it is delegated to MNO specific legacy applications through the Federation Gateway. Orchestrator has the authoritative, durable configuration state for the entire system. So even if you lose access gateways, it doesn't matter. If you bring up a new one, it will sync up with the orchestrator to get this authoritative state about subscribers and policies. And orchestrator also has the knowledge base. It's just like a social graph, every entity in your network, which might be a function, it may be a policy, it can be a subscriber, it can be the access gateway not itself. They are stored as entities and the relations with each other are stored as edges. So we have a big graph representation for this knowledge base in the orchestrator. The runtime abstraction on the other hand stays with the access gateway side. State generating in the network due to the operation of the network is there and access gateway is the authority about that. That state, like the session state, the UES state, data pet state and other metrics, they are synced up to the orchestrator for further consumption. And these states, the runtime states are functional the configuration state. So, you know, whenever a new configuration comes in from the orchestrator, it will start a new evolution path basically in terms of how these runtime states are changing. And as I already mentioned, these states are transient. So it is okay if you lose one and bring up another node or offload to another node in this system. Let's go into a bit more detail here. When we look at the runtime abstractions, we see, you know, on one side is how we terminate the radio communication or radio access network specific communication on as the access layer. We see that the AAA function, MME function or AMF function that are relevant for Wi-Fi, LT and 5G use cases. They terminate and normalize this radio access specific messaging or signaling. And they are transformed into an ENOB or access point state, authorization state for the user equipment, connection state of the user equipment. They are stored as, you know, normalized states. When we look at the session D site, where we do the session management, the UE session states and policies are stored again in a normalized form. And regardless of which OSS-BSS systems are being used, they are managed in the same manner. When we look at the pipeline D which provides our user plane connectivity, we maintain the forwarding state. We perform the policy enforcement, we take offloading decisions and we manage the transport functionality. So at the end of the day, each of these services as we have seen in the previous slide really is about deciding what type of states owned by whom and how they are managed. So this brings us the next abstraction about state management. State is encapsulated such that at any time in the network, it has a single owner. And the distribution of that state across different services is acidic. It is level triggered, which I will come back to in the next slide. And these states are cached by the downstream services and they survive headless operations. For example, if your service management layers disappears for a time period, your user plane can still continue to function. If orchestration or cloud services go away for some period of time, the access gateway survives and can continue its functionality. And the third aspect is the validation. Faders happen, they happen quite often. The important point is, can we reconcile our states between these services in a stable and robust manner? Our validation is about reconciling the mismatch levels with the state owner upon service restarts and or periodically. And so that we make sure that all the states in the system are eventually consistent. Now let's go deeper on this aspect. I wanna contrast H-triggered versus level triggered approaches. 3GPP systems and standards mostly follow this H-triggered approach. Meaning an event happens that changes the state from one particular point to the next, a low point to high or high level point to low. And it basically triggers a one-off signal. So this change is propagated across different services and function. If you happen to lose that signal at any point, then the states basically start diverging across different services and functions and you need to somehow reconcile that. Contrast this against a level triggered approach where you don't actually communicate what has changed but you communicate what is the authoritative state and where it should be. So the state owner communicates that to other services and the other services try to obey that state and try to realize that state. And if they cannot, they report that back. This approach is continuous and it is robust against errors and noise. To give another representation of that, I show basically here again these two approaches. Let's say you have a source state, who is the owner and then you have a sync state which is basically another function that is interested in a particular state owned by another service. In edge-triggered approach, you may be sending the deltas like editions or editions of policies, subscriber sessions, et cetera. And if any of those messages being lost or the note fails and a burst of signals are lost, then we end up with a divergence in state. In the level-triggered approach on the other hand, you send the versions of different state and every state communication is self-contained. So even if there are partial losses or a burst of losses, it doesn't matter when the note recovers or the interface recovers, the source state gets synced up with the sync state, eventually with the correct value. Now, having covered all these different abstractions, let me go back to this Converge Core Promise basically that we made. When we look at the 4G and 5G Converge Core architecture, this exemplifies it very nicely. We don't build a new SMF, UPF, or AMF functionality from scratch. We reutilize the existing microservices on the Magma platform. For example, here the 5G connection object is actually the same as the 4G connection object except for few configuration parameters. The NJEP and 5G NAS functionality is there for normalization purposes so that we can terminate N1 and N2 connections. And the Session Day and Pipeline Day, there is very little change or variation between 4G and 5G. For now, for the development effort, some of the features look like we have some additional functionality at those Session Day and Pipeline Day, but eventually they will also disappear and abstract it out. Now let's conclude the presentation with a couple of slides. As we move forward, as more partners are joining it, there are more use cases being pursued, more application scenarios being pursued. So how are we gonna basically manage the delivery of our services to new customers and new application scenarios? It really boils down to again the packaging of the right access gateway for that use case. So what we are envisioning is with containerization of the services and Kubernetes-based deployments, we can define different pod types that are specific to the application domain so that they can bring up the right set of containers and package them. And one can deploy different realizations, different personalizations of access gateway in different parts of the network. And the final thoughts, there are really two key takeaways from this presentation. First one is convert procedural transactions to state management and distribution problems. What that means is terminate 3GPP-H triggers and procedural calls as early as possible. Model H transitions as state and use modern distributed system tools to efficiently propagate those states, also known as levels. The second key takeaway is emphasize abstraction over complexity. Normalize the radio access technology specific features as early as possible. Prefer reuse and scalability over optimization. Prefer flattened data and message models over deeply nested ones, like the ones used in 3GPP. And also prefer extensibility over code rewriting. With that, I wanna thank you, everyone. This is the end of my presentation.