 For our last presentation today, Amar Papandavan is going to walk us through the development priorities we are setting for MAGMA. Amar is one of the tech leads on the MAGMA program and one of its founding engineers. Prior to working on MAGMA, Amar was an architect at NYSERA Networks, an SDN startup that was later acquired by VMware. Outside his role on MAGMA, Amar serves as the Platinum Director at the Open Infrastructure Foundation. Please join me in welcoming Amar. Thanks, Kendall. I'm between me and everyone in a break, so I'll try to keep this short. So are folks able to see the screen? Yes. Yeah, so mainly three things that I just wanted to talk about. So the first one is about how we think about roadmap in general. And then the second one is what are our like sort of priority use cases? We touched upon it earlier today. I just want to tie it up on the back end as well. And then the third one is to just give a sneak peek into the roadmap itself. So a very important thing that we wanted to sort of bring to everyone's attention is how do we think about the roadmap, right? So one of the things that Facebook brings, and I think it's pretty valuable for us to try and influence the industry in this direction is the hacker ethos. So what is the hacker ethos? It's the belief that being open to possibilities and embracing uncertainty is necessary for the actual future to unfold in positive ways. So what does this actually mean? So we're very religious about building features based on concrete demand and then iterating and then figuring out where it is that the future is going to yield. Today, we saw a lot of cool ideas around decentralizing wireless networks through the Sylvia stock, courtesy stock, and then the helium stuff as well. Now that may be an idea that we're very interested in exploring because it adds a lot of value to the market. And by having a fairly flexible approach to how we develop the roadmap, we react to sort of concrete demand signals and use that to sort of prioritize our roadmap and releases. So just given that framing, there are three key tenets that I just want to also reemphasize. So the first one is we build what is needed, right? So there were some questions on feature asked around NBIOT as well as LTE-EM and our friends on the OEI side are actually prioritizing that into the roadmap. But the focus and the ability for us to move that feature forward into a hardened deployment ready use case is actually dependent on partner commitment, right? Like is somebody going to deploy this feature in the field? If yes, then we're fully committed to making that successful. And then as an open governance, we're obviously always welcoming patches around that. But the priority of testing and hardening is driven by concrete demand. The second one is around rapid iteration. So more often than not, we commit to concrete sort of features on a quarterly timeline because that's what we think is a consistent time horizon for an early stage project that is moving through the paces. And some use cases are obviously far more mature, like fixed wireless. But so some things like the 5G assay stuff that we saw today are all things that, you know, we're sort of tackling in bite-sized chunks of quarterly releases. And the third one, as we saw in the AWS demo as well, software delivery is actually a pretty key part of this. So we prioritized some features like hitless upgrades that are going to come as part of the stateless MME effort in 1.4, lightweight delivery through containers, which is a roadmap item that we are currently tracking. And then one of the cornerstones that Ullash spoke about is the independence of artist upgrade and the fortice addition of gateways. So you don't have like large EPC that you need to upgrade and take the risk of that. So again, reiterating, so we build what is needed. We focus on short-term roadmaps that we commit to and quarterly releases, and then heavily index on software delivery as a way to keep the iteration and the process going. The what, right? So we're currently focused on three main use cases, fixed wireless access, Wi-Fi core, and then private LTE. Mobile broadband and 5G are more future-looking use cases. And 5G at this point, we're working along with the TIP OCN group on focusing fixed wireless as the anchor use case for pushing SA out. But the primary set of use cases that we're focused on at this point are fixed wireless, Wi-Fi core, and private LTE. I'll just do a deep dive on fixed wireless. So fixed wireless, as we saw from the great articulation by Jesse on Wisconsin Connect, one of the key things that we have is it's a distributed architecture and it allows for a software upgrade into 5G. The deployment model is at a sales site. So this allows us to go over links that are unreliable or unlicensed backhaul. So it's far less jitter sensitive. And then the control plane and user plane is fairly separated in the sense that there are only certain control functions that need to each are back into the orchestrator, like authentication and potentially any charging and BSS semantics that you need to do. So the second aspect is it's fairly it's vendor agnostic, as well as transport agnostic, because IP gets terminated at the edge. So you can use any sort of backhaul to translate IP access all the way to the edge. The third big aspect of it is it's a scale as you grow. So your upfront capex investment is just in buying the small access gateway hardware that you saw in Merrill's presentation on Mural. But then as your sites grow, you can add additional capacity and your EPC capacity of your network grows along with your site deployment. The third, it's very third party friendly. It's all REST API based. So you can integrate whatever CRM or BSS processes that are built into your operator network. And there is a real time monitoring, reporting and alerting that are built into the system. And if it's a pre certified E node B, you have the ability to manage those E node Bs through the orchestrator as well. So this is one of the key reasons why we think like the magma product is sort of ideally suited for the fixed wireless solution. And that's also where we're seeing a lot of traction. The second variation of this is fixed wireless with MNO Federation. So in this case, say you're a tier one or a tier two who already has existing assets for HSS, PCRF and OCS, then you're you can deploy magma with the Federation architecture. It has all the benefits of the pure play fixed wireless or the isolated fixed wireless, but it also allows you to bridge your existing MNO core assets into a magma network. And then there are certain this makes it good as well for neutral host operators who are trying to federate into some other networks, HSS, PCRF and OCS. The third and newer use case that we're sort of trying to talk through these days, and we have a couple of early deployments on at least as Facebook is the private LTE private LTE use case. Here, the big selling factor is that the distributed EPC enables a bunch of the MEC use cases. And this is what you know, I think the AWS folks also alluded to earlier in their demo. There is also multi APN support. So this allows you to break out different traffic for different use cases, as well as interconnect back into an IMS sort of a central IMS sort of an integration. It's natively multi tenant. So the same operator can offer services to multiple enterprises, but manage it through a single OSS and a management stack. And within the next couple of quarters, we expect this to be fully upgradable from 4G to 5G as well. So the other very attractive thing is that it's a very small form factor. So snow devices are 4G based, and then the mural devices are all 2G devices. So these are fairly small shoebox size devices that you can ship around. And it's fairly easy to sort of stack. I think I have a typo on the dates. So the fixed wireless should be mid-March. That's what we're looking at. The 5G is a slightly more interesting thing. With 4G, it's much easier for us to understand what is an MVP because there are concrete customers who are already deploying it or are in the process of replacing existing equipment with magma. So it's very easy for us to understand what's a minimum viable feature set. So with 5G, we've actually partnered very closely with the open core network project group. So there we've defined the priority use cases and Mansoor and Narendra had mentioned fixed wireless being a priority use case. So through a collaboration with operators, SIs, as well as engineers, we've identified what is an ideal like sort of a fixed wireless 5G SA requirement that got published by open core around August. And then since then, we've been executing against that. So magma is effectively a reference implementation of that project group. So if you're interested in driving requirements around magma, please feel free to join the open core network PG. We're definitely looking for more concrete use cases, especially in the fixed wireless and private 5G sort of verticals. So and once the project, the code lands hopefully by mid-March is when we expect an alpha quality fixed wireless, that would again the reference implementation would feed back into the open core network project group and then go into lab and field trials through TIP. But obviously, since the software is available through GitHub, anyone is free to take this source code and run with it or create derivative works around the same. So the third one, and I think this is the most interesting part is the when this is the actual roadmap for the next couple of quarters. So all of this is fairly subject to change. So we're on a quarterly sort of a release cadence. So release 1.4 is imminent. So we're expecting that to go out within the next week or so. So the big marquee feature in release 1.4 is stateless MME. So what this is is that the all of the state in it's actually stateless access also including the MME all of the state in the microservices in magma is persisted in Redis. So any sort of software faults that cause the services to die doesn't affect existing user traffic. So all the flows and the forwarding state is cached in the kernel. So this is a great way for us to, you know, sort of improve the reliability of the system. And it's one of those things that helps us move fast, right? So as soon as, you know, software bugs are not taking out your network, you have the ability to sort of introduce more bleeding edge features and that in turn helps move the roadmap faster as well as, you know, innovate in the platform. The second interesting feature is Cloud HE. So this is where, you know, we rely on the S1 flex feature from the Enote B to have a cloud backup of the access gateway. So it's almost like a disaster recovery sort of a model where if your extreme edge access gateway fails, you still have an option of failing over the traffic transiently into a more central location. While S1 doesn't get terminated the edge, this is more of a like sort of a rainy day scenario. A couple other features around header enrichment, orchestrator service mesh, and a debugability feature called call tracing, which will allow you to understand where the packets are going and then general usability improvements that are coming as part of 1.4. The next release is 1.5, which is end of March. So the big feature here that I want to call out is inbound roaming. I know a couple of folks already asked for that in the call, including Miriel. And I think it's also pretty clutch for some of the work that the helium folks are doing as well. So it allows, it allows, it's basically a S8, right? So it allows for existing ISPs to sort of sign up for roaming agreements and generate additional revenue streams. And a big theme for 1.5 is around stability and usability improvements. And so you'll continue to see a bunch of like bug fixes and usability enhancements in the product. 1.6, which is likely end of the half, is when we're targeting NB IoT. This was also another feature that was requested on the chat side. And then the other big thing that we are tentatively targeting is the interaccess gateway handover. So this is S1 mobility across nodes. So this moves us squarely into the mobility territory for 4G. The 5G fixed wireless, we hope to have it beta ready by the end of the half. Release 1.7 is pretty speculative at this point, but it's mostly focusing on private 5G as well as some of the FWA 5G use cases along with IMS integration for the 5G use cases. But the best way for anyone to influence this roadmap here is to get engaged on Slack, bring us concrete demand, and then we're always happy to prioritize and understand what features make sense, what don't. Again, we're not like trying to implement every feature under the sun. So getting sort of a deployment lens to the way we look at features and functionalities of a network core is actually pretty useful and helps us align towards a tractable scope that we can execute against. The second thing apart from the technical side is we want more people to be able to support magma and take it to market. So as part of that, we're trying to launch a training program by the end of Q1 with heavy involvement from our foundation partners in the Open Infra Foundation as well. So this is mostly focusing on commercial entities like SIS or OEMs who want to take magma to market. And so we're developing a training program for L1 to L3 support with some sort of lab scenarios and then trying to figure out how we offer the exact same thing across the regions because we're a fairly global community at this point. And I think there were some questions on TCO as well that I noticed on Slack. So a lot of what is being developed for the training and certification will address some of those questions as well on like, okay, what's the business case? Why does magma make sense as compared to some other core? Or like, what's the business case for private LTE or fixed wireless? That's all I had. I don't know if I have time for questions, but thank you everybody. And it's been a great session all day actually. Yeah, I would like to offer who have been brave enough to stick with us through the whole day of content, deserve the chance. So please, if you have questions, chime in. Sure. Prakash here. Great presentation. Great conclusion number. And look forward to working with you folks. And essentially, it was a combination of various things. So it takes some time to sink in. So maybe we should talk offline after the event sometime. Thanks. I guess we need the site. Can you guys hear me? Yep. Okay. So I think one question which I have is for the site program that you guys just mentioned. How do we reach out to the folks in, you know, Facebook running magma program and get affiliated to that? Yeah. So I think the way that, so we're, so this is not going to be run as a Facebook exercise while we're definitely going to be helping author the content for a lot of the training material. This would be something that is done in the open through the magma open source project. So yeah. So as soon as we have the content, it should be something through the website. You just apply for it and, you know, you'll be able to have access to the training. Sure. Thanks, Amar. I appreciate it. Amar, there's a question regarding the network slicing lab testing in Q321. Yeah. So, Phil, I'm happy to take that. If you want to take that, either it can go either way. Go ahead Amar. Okay. So yeah. So we're at this point trying to look for an anchor use case where this can sort of see deployment. And so that will help us sort of define the exact scenarios a little better. And so, so at this point we think we're about like a couple of months away from actually finalizing the requirements and then from then on it takes a few months for us to actually develop that. The best way for anyone to get involved in this would be to also influence the open core project group from our direction standpoint and give like more specific requirements to Phil or me. And then we can figure out how to prioritize that. I don't know if you want to add anything, Phil. No, and I'll just say that the easiest entree for that is to bring your suggestion or question or use case to the MAGMA Slack channel in the general questions Slack.