 Hello, everyone. My name is Rahman Doust-Mohammadi. I'm a research faculty at Rice University. Today, I would like to actually talk about our recently started project, Magma ML, which is a joint project with Ashur Sabarwal also from Rice. Magma ML is actually about automated management for low-resource 5G cellular network deployments. One of the biggest challenges in actually cellular network management for mobile network operators is troubleshooting the network. So whenever a problem happens that occurs in the network, these problems may sometimes require field tests. And if that's the case, these kind of problems may take hundreds of man-hours to fix. And this by itself adds billions of dollars to the operational expenditure of man-hours every year. So this problem could get even more difficult and get even worse by deployment of even more complex networks, including 5G networks. In particular, in the next generation of networks, we're going to densify the networks that create more problems. And then we're also going to deploy even more complex technologies, such as Massive MIMO, and that could complicate the problems even further. And these kind of problems could even be more pronounced in low-resource networks, where usually they are deployed in hard-to-reach areas and simply the lack of experienced people to fix the problems onsite exacerbate the problem. So now the question is whether the research community can help. And one of the most immediate solutions that can come to mind is like, why not use machine learning to sort of be able to sort of watch the network, probe the network proactively and detect these problems and be able to diagnose the problems. So usually to be able to do that, we need labeled datasets to be able to train models, to be able to sort of automatically come up with a cause of these issues. But it turns out that the sort of this sort of data and datasets is something that is privately owned by the mobile network operators and not usually open source. And even if they are, they're often limited by the sort of like the information that is exposed by the hardware that those MNOs are actually deploying. So it turns out there are actually some new possibilities in these days, particularly with the proliferation of city-scale wireless testbeds powered by software-defined radios. This could actually help us to some extent alleviate this problem, as well as the existence of a lot of open source software out there, such as Magma Core Network, which is actually the focus of this community, as well as OAI Radio Access Networks, SOSLTE, and so on. So as far as the city-scale wireless testbeds goes, there are multiple of them right now being deployed in the United States, such as Powder Renew and Cosmos, which are sponsored by the National Science Foundation. There are some other ones that are being funded by the Department of Defense. And there are several other ones that are being deployed in Europe and Asia as well. So with all of this, there's a possibility to kind of be able to learn to diagnose the cellular network problems by sort of using these facilities to sort of put the network in certain states, which actually can cause certain issues and observe those network states and then the BAT performance and the KPI related to BAT performance and create this sort of data sense. So I'm gonna talk about this a little bit further down the slides. So just go back to the city scales and give you a little bit of background on this. So as I said, there are multiple of these testbeds are being deployed. I'm gonna briefly talk about two of these testbeds that we are kind of involved with as well. So one is the Renew testbed, which is actually at Rice and another one Powder Testbed at the University of Utah. So Rice Renew is actually sort of a project that has been going on since 2017-18. And the goal for this was to actually deploy massive MIMO software defined radio platforms around Rice campus. And this actually has been done. Currently there are four massive MIMO base stations are deployed on different building sites on Rice campus. As you see in the pictures on the rice of the slides. And then these are 3.5 gigahertz software defined radio base stations, 96 antennas and 64 antenna base stations. This sort of like the world's first testbed of its kind actually. And the other one is actually the Powder Testbed which is actually being deployed at the University of Utah. And this is actually a public testbed as opposed to the Rice Testbed, which is actually private. And it uses a 2.5 gigahertz variant of the Renew hardware and is deploying it on this campus. And on top of that, there are a lot of other base station and client software defined radios are being deployed which have between two to four antennas on each of them as well. So this actually all of this gives us like the sort of like the infrastructure that we need to run the network that we need. And then we have open source radio access network software that I mentioned. Some examples of them are Open Air Interface and SRS LTE that this community might be are probably like familiar with. However, these software are not really well tested in the field, they're open source and they have their own community, but they still have a long way to go in terms of becoming completely operational in the field. And on top of that, they don't have some of the features of the next generation networks and similar technology such as Massive MIMO. So another sort of brand software that we are currently involved in when we're developing is called is the Renew Radio Access Network. And so the Renew is essentially still under development currently include only the physical layer for Massive MIMO. Well, it could also support essentially from four antennas all the way to 64 antennas. I'm gonna talk about this particular software in a little bit, it's called Agora. And then development of layer two and layer three to make it a full stack radio access network is underway as well. And the good thing about this software is that it's coupled to the Renew hardware which is actually a fully observable hardware that means that a lot of sort of configuration of the hardware is observable to the users and it could be actually kind of harvested in terms of the data sets that we're going to create for diagnosing the problem. As it turns out, a lot of the problems in cellular networks could be caused by the hardware malfunction, for example, as well. And it's always good to sort of be able to actually see what's going on in the hardware as well. So just to briefly talk about Agora is, as I said, is layer one processing and physical layer processing is completely done in software. It sort of addresses this ORAN community's open problem which is actually about virtualizing massive MIMO. So Agora addresses this problem, it implements a real-time physical layer processing in C++ and it can achieve real-time processing for 64 by 16 multi-user MIMO by simply running on a 36 oriental server. So this is a work that is also last year it was published in ACM Connex as well. So just to give you a little bit of detail, like there are, this is actually a plot of the latency results of Agora and it shows that for different number of antennas and clients, essentially it achieves, it meets the latency requirement of 5G enhanced mobile broadband use case, which is actually four millisecond. So Agora's latency is well below that. So going back to Magma ML, so what are the goals of Magma ML? We envisage Magma ML to be sort of an management agent for Magma with an inference engine, which actually combines rules-based, the rule-based methods and also train ML models to be able to first of all, proactively look at the network, the entirety of the network and the network state and KPIs and then detect faults or bad performance and then be able to suggest fixes to those issues to the network maintainer. So these are the goals of Magma ML. So there are three sort of big steps for the project. The project big tasks, the first task that we're actually currently working on is essentially be able to integrate a renew ran with Magma Core Network. And then once that is actually achieved, we're going to essentially do, like generate large scale data sets using these existing test bus such as the renew advice or powder at the University of Utah and then be able to also top of that, develop these Magma ML software module on top of Magma. So to be able to actually give you a little bit of examples on what type of data sets we can actually collect sort of immediately is essentially there are four examples here. One example could be that you have a network, you have a base station, which is actually connecting to a lot of users. We can actually play with high user load where it saturates the network and it affects the performance of clients in the network. You could actually like have a malfunctioning UE where it could affect the sort of the performance of other UEs in a network or we can actually intentionally sort of create an interfering node in the network that could affect the opting and downing performance as well as the sort of configuration of the InnoV or GenoV and creating bad configurations could also like affect the performance of the network as well. And while all of these scenarios are being created, we could actually measure certain KPIs such as the data rate of the bearers, the retransmission rates in HRQ, BLAR block error rate and so on. And the hope is that once we create these like preliminary datasets as the network is being sort of deployed elsewhere, like more datasets can be added to this as well by the community. And looking at the system architecture, essentially the MAGMA ML would be sort of part of the MAGMA orchestrator as a microservice to it and it could essentially be used to do a lot of different things such as let's say fault injection and learning from those faults. So essentially the process of creating the datasets that I just talked about, as well as like tools to sort of be able to infer those faults and be able to fix, so just fixes to the user as well. So to summarize automating cellular networks, network cellular network management and troubleshooting is highly needed, especially for low resource networks that are going to be deployed. We have open source software and open access test bits at our disposals that they provide a path for us to achieve this goal. And then MAGMA ML would essentially equip MAGMA with an engine that could essentially do this automated fault discovery and recovery. So that's it for me and thank you for your attention. Thank you so much. I believe we have Rahman on the call and we have maybe a minute or two if anyone has any questions, please feel free to get off mute and ask them. So Rahman, Prakash here again, question to you since you have mentioned this is more to do with the ML. ML comes post installation or do you want us to support during the installation itself? So yeah, I think this could be essentially both ways. So this is something that we can actually, I guess we can actually like look at offline data sets where we can actually look at certain problems that occur like in terms of let's say power control, power setting issues, gain issues that could happen, for example, in the networks that are based on software defined radios, things like that. Or yeah, of course it could be certain things that could be learned online that could be also part of the problem. But I think our first focus is to be able to look at these offline data sets and build certain tools that can be integrated in Magma. So there is a possibility of pre-provisioning usage once your model is ready. Sorry, can you repeat your question? So you have obviously data you should collect post installation and then you have a model. If the model is ready, then we may be able to use it at a later stage for. Right. Yeah, I guess it's both things are kind of necessary because obviously as you deploy networks in different environments, there could be issues that are coupled with the environment that they are in. So obviously, simply offline data sets may not be sufficient. Perfect. Hello. So yeah, I have a question. Like when we work on the data set, mostly offline. So we have a thing called data analysis. So we perform data analysis on that part. So after performing the data analysis, we get some insights. So in that we can get null hypothesis or some values which are not there and we did it through stuff. And there are some columns which we are actually interested in. For example, power consumption, then energy requirement, MCS calculation, even the modulation coding schemes and SNR, et cetera. So those columns which we are interested, we can actually work on that. And we also, for live network, then we need a data set which actually matches this column. Otherwise, when we build that model, it won't actually be useful, right? So that may be a problem then. Hello. Yeah, I mean, I guess this is actually by itself sort of a research, it's a big research area as well. So I understand there are actually a lot of questions like that that could come up. But I guess like, yeah, so I think we could actually like divide this project into two sections, the research part, which is actually could come with more deployments and a lot of these issues, we can actually understand them as we deploy. The other part is the engineering part of it where we actually can sort of develop this sort of additional features in Magma as part of Magma ML. So I understand, yeah, so there are a lot of issues like that. Because when we use edge devices and we use edge nodes, so we can get data which is not relevant and there can be some part which is actually like error rate. So error rate can be quite high at such times. I agree. So I think the space is very huge in terms of where the problem can happen. So if the problem can happen, let's say in the core network, the problem can happen in various layers of the RAM, the RAM software, for example, there could be a lot of software bugs and so on. So obviously this is actually like not an easy problem to solve. But I guess we could start with certain, I'd say in terms of massive MIMO, we can actually start looking at certain issues like let's say the power that could be, let's say the start of it and collecting. Because the thing is one of the features of the next generation is that a lot of them are not necessarily planned network, whereas traditionally we used to have a lot of planned systems and a lot of interference issues could arise. So that could be a particular dimension that we can look at and try to collect data so that area. Yeah, so I actually got it. The thing is that first we should have a vision. Like what exactly we needed and then we should divide that magma into two parts. One is the data analysis part, which is the research part and one is the implementation. So we need to work like that, right? Yeah, I definitely agree with that, yeah. So I think, yeah, definitely we're gonna take that step approach and look at certain problems first and then essentially move on. So I guess this is actually, I guess this is a start of it and we're hoping that later on it could turn into something that a lot of people can collaborate and create more advanced data sets, more advanced models. Yeah, thanks. Thanks. Roman, just a question on that and probably related to that comment. Have you looked into the ETL process to do the proper feature engineering to create these models? Do you have a stack in mind or that's still on the works? That's actually still on the works. We're actually looking into solutions, like I said in the presentation to kind of be able to integrate with Magma. I think that's gonna be our first step, which is going to take a lot of time. But at the same time, we can actually start collecting the data sets as we speak. This is something that for example, we have a lot of channel data sets that we can look into in terms of, let's say intercell interference, pilot contamination, things like that. We can learn from those and start creating these data sets. And then I guess later, hopefully later this year, we can start looking into the actual implementation of Magma ML and the integration with Magma. Okay. And on the machine learning portion, what algorithms or what kind of models are you planning to implement like itchy boost and normal decision tree stuff? Or have you decided that there's still also... Right. I mean, the thing is, as I I guess mentioned earlier, so many things that you can do. For example, if you're looking at, let's say power control in sort of multi-cell networks, you can actually look at deep learning models even. Like you can train models in terms of, what kind of problems could occur like that. But like mostly you could actually look at simpler things like regression, simple regression models. For example, that could be like one thing to start. But yeah, definitely not something that, you know, it's still to be figured out.