 To present the open air interfaces contribution to automation in the magma community, we have Rafael Delacro who has been working as a CICD expert at OAI since 2018. Along with Rafael, Mohit Baez will present the OAI's contribution from the core network side in the magma community. Mohit is based in France and due to time zone considerations we have prerecorded his presentation, but Mohit is on the bridge and if time permits we will have a Q&A. Hello everyone, my name is Mohit Baez and I am working as a software developer at the open air interface and today I will be talking about the contribution of the open air interface in the magma project from the core network's perspective. So let us start from how it all started. The magma EPC was a fork from the OAI original code which was known as the open air CN and they used the magma, the OAI code from 2016 as the base and the last upstream push from magma to the open air CN was in the year 2017. Moving forward from here both the development tracks diverged soon with magma worked a lot on the robustification or say the hardening of the code source based and the OAI kept on adding new features to cater the needs of the 5G and also to make sure that we are on the path to make it cloud native support with full 3GPP compliance in our code. Moving towards the converged MME this can be best described as the consolidated MME functionality which caters the needs of both magma as well as the OAI community. What does this actually means? This means that over the S6A interface we can support both GRPC as well as the 3GPP compliant diameter protocol. Over the S11 interface we can support both embedded Skateway and the GTP V2C stack and for the development environment we can work with both Debian based virtual machine and the Docker containers. This project was started in the fall of 2019 and the sole objective of this project is to make sure that both the MME developer communities contribute to the same code base. Let us start from the OAI's contribution to the magma project. The first contribution which we carried out was the S6A abstraction. The S6A interface is the interface between the MME and the HSS which is used for the authentication procedure and to obtain the subscriber information related to both location as well as the service. As described in the presentation in the diagram the S6A interface can support both GRPC activity for the magma requirement and the free diameter for the full 3GPP compliant based OAI core. Free diameter can be described as an open source implementation of the diameter protocol which is standardized by the 3GPP and designated to work on the S6A interface. The addition of the S6A task was a primary objective of the S6A abstraction. When we discussed the S6A interface testing framework I would like to discuss that we used S1AP tester which was magma native and the DS tester which we are using here at the open air alliance. And it works as let us say the RAN emulator to test the core and we used both OAI HSS and the CUPS SP gateway to check with the traffic generator and we tested with both excess gateway variant from the magma and the full 3GPP compliant MME variant from the OAI core network. After finishing the S6A abstraction we worked on the S11 abstraction. S11 interface is the interface between the MME and the S gateway and is used to handle events like session creation deletion, default bearer creation deletion, dedicated bearer creation or deletion and many other LTE events. The S11 interface in magma supports both embedded SP gateway which is an inter task thread which is more magma native and the GTP V2C stack which we used in the OAI core. GTP V2C is a GPRS tunneling protocol and is used to carry the packet radio service in LTE networks. Under the S11 abstraction our main objectives were to add the S11 task and the GTP V2C stack in the existing magma code. And the testing framework for S11 abstraction was similar to that of the S6A abstraction where we used S1AP and DS tester as RAN emulators and we tested both the variants MME and the excess gateway with the traffic server and also with the OAI developed HSS and the CUPS SP gateway. In the final quarter of the previous year we worked on the 5G non standalone addition, NSA or say non standalone access is a 5G deployment mode with the control plane of the existing LTE network while 5G and are focusing mainly on the user plane. The NSA, the addition of the NSA in magma started with the upgradation or say addition of the release 15 based ASN.1C which was added to cater the needs of the NGAP based services. Moreover we added some extra messages and new information elements which are based on the 3GPP release 15. Discussing about the testing framework for the NSA it was a lot different from the S6A and the S11 abstraction because addition to using the S1AP and the DS tester for the NSA testing environment we also used commercial OPPO handsets and some modules from a company called Quicktel and they are based on the latest 5G framework. Please stay tuned at the end of this presentation we will have a demo of this full NSA connection. This was the story so far and moving forward we are planning to optimize the code with some ITTI optimization and we are planning to add the LTE M or the NBIOT support to the existing code as well. In order to summarize the OAIS contribution to the magma project this is a small diagram in which we can see that in the first quarter of 2020 we finished the S6A abstraction followed by the S11 abstraction in the second quarter. The release 15 edition was done in the final quarter of the 2020 and we are in the month of February right now where we have finished the NSA validation and moving forward we are planning to add the NBIOT support. Hello my name is Raphael Dovoseu I am the leader of the DevOps team here at OZA. Today we will talk about our contribution of automation to the magma project mainly from a continuous integration perspective also from a continuous development perspective. Like Muitz talked about during the converge MME phase we also developed a pipeline to validate S6A as S11 contributions and we use the magma VMs but also OAI containers. And here you have a view of how the pipeline works so the first testing with the magma deployment with the VM the so-called no S11 and then rebuild the MME with S11 and testing with OAI Cups as the gateway. Since the merge in 2020 July the pipeline has been officially part of the magma CI purpose and you have the URL that is maintained by our friends. First before continuing I will talk about deployment so virtual machine versus container so the magma usual development flow is using DBL virtual machine to host all the main basic core network services. And the orchestrator is deploying container outside of the VM. OAI prefer a more clone native approach with plain Ubuntu 18 container for our community but also we are deploying pods inside the OpenShift cluster in Aturicom. So that means that we have necessary to maintain at least these two OS and to keep our development model working in the magma master branch. So that's the reason why we are hosting a CI for OAI in magma. So let's look at it. So it always starts from the magma repositories and not only the magma but also the OAI GitHub repositories. Then we are linking to a Jenkins server that is also hosted in our OpenShift cluster here at Aturicom and how it does it's hooked with webbooks. So that means anytime you have a pull request that trigger a job where we are building an image to test. Once your image is tested, is built and validated in that point of view, then we call a shape jobs to test not with other components and with stimuli. The approach is the same for our own components like HHS, SPK2C or SPK2U. So what does a magma MME image builder job? So first of all again is triggered by your pull request on the magma GitHub repository. We do retrieve the source code of your pull request and do a local merge with the current master branch status. That means that we are ensuring that your merge request or pull request is mergeable. Then for the moment we are building a Ubuntu 18 MME image that will be tested. And if this build is positive, that means it wants to completion, then we call a child job to evaluate with the rest of the opener CN components and stimuli. So the pipeline URL is this one and you have an open blue ocean view of the CG. So retrieving, building, testing. But the testing is a child job. On your pull request you will have a notification that if it's path or fails. The child job that is testing versus DS tester is the one that we are also using for all our components. So we are using this third part tooling, it's called DS tester from developing solution. It emulates the run and the UE attachments. So scenarios are developed and used by developer and the CI team. And so that means that they are across the board. Then we are deploying using Docker Compose with parameters that are in line of course with the DS tester scenarios. And we pick one of the image to validate. So for example HSS or the magma MME. And all the other components are using golden images. So the stimuli and the expedient answer checks are done by a framework. So this is totally automotivity. So you will have a path or fail criteria for each scenario. So URL is the following one and again deploy, test and deploy. In addition of your GitHub notification you will retrieve by email a slick HTML report. Where we have a summary of the run. So for example here is the test one. You have the name of your pull request, the name of the run. The commit that has been tested. You have details on the image that has been used for deployment. So in this case it was the magma MME CI temp that is the one for the PR from magma. And also the details on all the scenarios that has been run. And as you can see my PR was on magma. So the test image I use was the magma MME. So our next steps is also to add another pipeline to build Red Hat 8 images also all the time. Definitely we need to add more scenario to the DST test suite. So for any support with the pull request that is currently open by Moet. But also later on NBOT, X2 handover and so on and so forth. For any future features that we will add in. For us also at OZA and OAI, what is very important is to have this second shell pipeline that will deploy the whole OAI stack. So not only the core network, so with magma and the rest of the open RCN. But also the run, so that means NB and GNB attach a 5G commercial phone and do end-to-end traffic test. For us it's very important that we do validate the whole stack all the time. Let's talk a little bit of our deployment strategies. So as I mentioned most of our bare metal Ubuntu community is using Docker compose. So there is one example in the CI pipeline in the master branch right now. I will do a full tutorial soon so I don't forget to look at that. But also here at Uricum we have our own OpenShift cluster. So it's a Red Hat 8 Kubernetes cluster. And we are using ElmChart to deploy. So you have this GitHub repository where this ElmChart are located. Get a look and don't hesitate to ask questions. So for example if I look at the Docker compose approach, so we are using two Docker private networks. And so we deploy Cassandra with HSS, then we are deploying a Redis container and with a magma container. Then I deploy the ORI spec that we see and the spec that we use and then the InnoB and the GenoB. Everything is containers. Then if you look at the deployment in the cluster, then we have a notion of pods. A pod can contain multiple containers. So here we are deploying three Cassandra pods for robustness. Then we are deploying a pod for this one is HSS with a TCP DOM that is a tool for capturing pick up. For debugging purpose. For example if I look at the MME pod, we are deploying a MME container. So the magma MME image, the Redis container and then also again a TCP DOM container. And the same way for the SP gateway. So let's look at the term at the demonstration. And thanks a lot for following us. You can always reach us on the magma stack workspace. And once again you are welcome to help us. Bye bye. Hey this is Raphael. I'm going to show you the demonstration that we recorded last week. So it is a 5G NSA base with magma MME. So I'm deploying the containers using my Docker compose. It's a bit too small. So don't worry I will put a link on YouTube for having a better resolution for you guys. So we can look directly at the MME live log file. So we can see that the HSI is connecting through the SXA diameter interface. So we will start the UI in a bit by metal on the second server. We can see that he attached in the MME and we can see the name of the in a bit. So we might be replaying again for us. So we are using two B210 USRP board to show that here we have the in a bit ready. And we'll start. Also the G node B. Bottom right. So as soon as the G node B started, we have the X2 connection in STP with the in a bit to do the handling of the NSX support. Again on the second USRP board. Red light on. So we will attach the UI and we are in 5G. So if we look at on the top right corner, we will see in the speaker if we see that the IPRS of the G node B appear. Once 92168.18.1998 that's the G node B IPRS. Thanks a lot. And follow us on social media. We'll have the details of the new tutorial.