 We're going to be presenting a brief demo of our work in progress adding support for 5G standalone mode to Magna's access gateway. And we're actually very excited to peel the covers off of a work in progress and let people look inside how not just the success that we're having, but the method that we're using in the open collaborative work that we're doing as this has transitioned to an open source project rather than a captive project. So last year Magna partnered with the telecom infrastructure projects open core network working group and agreed to do an implementation of OCN 5G fixed wireless access specifications, which were published last October. We haven't quite finished this implementation. We were hopeful that we'd be able to deliver a finished project today, but there have been a few complications getting it out the door. We're still excited to share it here. And we expect an early release of the code in the next few weeks. All of the development is being done in the open on our GitHub and we welcome you to visit the repo and take a look at the work in progress. I'm going to cruise the issues that we've raised, watch the discussions that are happening on our Slack channel as things are progressing very quickly at this point. Our demo will be presented by teams from Wave Labs Inc. and ACL Digital, who have stepped up to build the 5G implementation in our access gateway core. We introduced the two team leads from those two organizations, even though some others will be joining them throughout the course of the demo. Mensur Khan is CEO of Wave Labs Technologies, and he's a strong believer in the mission of connecting the unconnected and levering open source technologies to do so. We've been at 20 years across different organizations like Erison and Altran accelerating product development and personally oversees the connectivity industry 4.0 practice at Wave Labs. He's been very actively involved in this magma 5G journey along with his team. Mensur will be Narendra Dara, CTO of ACL Digital, and he heads their cloud and connected infrastructure portfolio. In this role, he heads technology initiatives, strategy and manages delivery of customer solutions and 5G and 4G, LTE, MECH, service orchestration, automation orchestration and network security. Narendra is also defined and managed development of ACL's framework of accelerators in network virtualization, orchestration and cloud automation. Prior to joining ACL Digital, Narendra has led product development and technology teams for data center, wireless and telecom networking services companies and network security. Mensur and Narendra, take it away. Thank you Phil. Hello everyone and welcome to this section of the presentation. I'm joined by Mansur Khan and Wave Labs team. Today, hi Mansur. Hi everyone, this is Mansur, pleasure meeting all of you. We're going to provide details about what we are doing with the magma 5G Converge Code project. As you have heard, this is a magma community project and it derives the specifications and requirements along with the use case priorities from the work done in OSEAN, the OSEAN project team. Now, let me share my screen here. ACL Digital and the teams from ACL Digital along with Wave Labs team. We have specific roles in this in contributing and developing this particular Converge 5G Converge Code application and our role has been in developing AMF functionality, SMF functionality and doing system integration support. And our focus in general in the industry has been around providing telco cloud solutions to our customers from operators to equipment manufacturers to enterprises. And Mansur, off to you to do your introduction to Wave Labs. Thanks, Narendra. At Wave Labs, we have this mission of accelerating the future of connectivity. And we do that by combination of offering unique services and solutions across digital cognitive and network services. Our role has been building the UPF, UPF development, the UPF SMF interaction, the N4 interface. We will be magma orchestrator, hopefully at a different time we can talk about how the magma orchestrator is designed both for the current environment of magical functions being BM and also on a continuous. Moving forward, we will be a strong SI partner for magma, partnering with RAN OSS basis companies, and also offer value auditory selling and support services for magma. But for this discussion, we will focus on the UPF development and the UPF SMF interaction. Thank you Mansur. The first use case we targeted to demonstrate through these converged core is fixed wireless access. As you heard from last the idea here is abstract the converged core apps to use the converged core abstraction layer and develop SMF-AMF applications and UPF and define a minimal feature functionality to showcase fixed wireless access. And today in this presentation, our goal is to showcase what has been done our project status and show a demo during this presentation. And why fixed wireless? Obviously, the market data is pointing out that fixed wireless access use case is going to take off with FIG and which is also confirmed during a lot of operator ground table discussions in the OSEAN project group meetings. So this is one of the primary targets. There's also a private FIG use case on the table, but today and this presentation and the primary focus initially for the entire team is fixed wireless access using the FIG converged core. And a bit of a journey that we took with the community and among ourselves as how this project developed. The OSEAN project group formally got launched in February 2020 and a lot of good work done in terms of community participation and coming up with requirements and prioritization of use cases based on feedback from the industry and formally a draft requirements specification was launched in August 2020. And the teams from Wave Labs and AltenCalc of Labs Digital started working and around the code base of the converged code base of Magma and started developing AMF, SMF and UPF features. And with the notion of demonstrating FIG fixed wireless access with the minimal viable features and some of the features targeted for the initial alpha release which we're hoping would be coming out very shortly. Some listed out here, UE registration, registration, PDU session establishment and release, upstream downstream data transfer, ideal mode, periodic registration and UE network initiated session modification. Now some of these are still under development and that's something we're going to share with you as we go forward. Now, I'm going to hand it off to Suresh who is going to talk about the demo scenarios we're going to show in this presentation as well as the UE initiated procedures. Suresh. Thank you, Narendra. Can you go to the next slide please. I spent around a minute to talk through the network functions within the AGW, the Magma X gateway, for the benefit of the developers on the forum. Thanks to the systems approach that we'll talk through this morning. You can see that in the Magma code base as such. The network function that you see here with XAP, XNAS is part of the network function called AccessDemon. In the current Magma repo, you will still find it named MME. It is going to be renamed to AccessDemon maybe the next one month or so. XAP supports S1AP and NGAP application protocol related encode decode functionality. XNAS offers the NAS termination for 4G and 5G related signaling procedures. In Magma, SMF related NAS also is terminated on AccessDemon of the Magma AGW network function, AccessD. In the diagram, you can see that as XNAS XAP is the only network function that is generation specific. The rest of the network functions are all generation neutral. The systems approach you can see in action here in the code base as well as in the architecture and design diagrams that we use and the design thinking that is put to use by the community while coming up with feature extensions on the network functions. On the right of the GRPC, you can see session D. Let's spend a minute on the design of the session D. The developer community will show like the kind of abstractions that went into the session D. You can see the code base into the header files, the RAG specific and RAG independent information elements are clearly separated out. And the session state object for example has 3GPP and non-3GPP information elements separated out. And again, the 3GPP information elements have 4G and 5G specific information elements separated out. In the 3GPP standard documents you see N4 and N11 interfaces and they're all restful CRUD operations. But in magma, we haven't adopted these 3GPP CRUD operations because the systems approach magma adopted has robust level triggered set operations. And all the network functions except access demon are made generation neutral. Magma designers have all the degrees of freedom bring in design elegance into the system and in many areas magma deviated and optimized and improvised for what is an offer from 3GPP specifications. Narendra, can you go on to the next slide please. We have some pictures of T-PLAB where magma HW is in system test today thanks to TIP telecom infrastructure project and Tech Mahindra for the system test lab and test support. Also let's walk through the video around T-PLAB these around four minutes. Can you share screen and video walk us through the T-PLAB. You can suppress the audio because there is acoustic noise on the video and Rajesh will talk us through the lab infrastructure. Just one moment I'm getting it set up. Thanks you. Yeah, we can take it. Hello, this is Rajesh. So here I'm going to walk through the 5G test page that we have prepared in the TIP lab. So this test is used to validate the interoperability of minimum viable 5G OCN core, which is based on the 5G magma software. So this lab is based at Facebook Menlo Park Headquarter. It is located in building 17. So in addition to the open 5G code, this lab also hosts like multiple projects like open RAM, open Wi-Fi, CI CD and many other projects. So here we are at the 5G OCN test base. So we have like 5G RAM provided by Bicel and a few commercial like 5G SUEs. This is a user area where we have like RF shell box, Bicel radio unit, UEs. And we have separate server room where we host like Bicel, central unit distribution, distributed units and OCN software. So these RF cage, UEs are placed in the cage in the control environment to reduce the interference. So inside the cage we have like two commercial UEs which has been certified by the Bicel team. These UEs are controlled remotely using like open source tools called Vicer and most of the team members, they use this lab 24-7. On top of that you can see some of the antenna feeders which has been placed. This whole setup is again based on the band 78 which is a TTT band and we have put some attenuators and based on the testing we adjust the automation. And as you move along, I think you will see the Bicel radio here. This is a fiber like cable which connects the radio unit and the distributed unit. So we will go to the server room in a while, but this is a, this Bicel GNodeB is based on the distributed like RAM architecture with split radio units, control central units and distributed unit. And as the scope of testing is more on OCN, we have like combined CU and DU on the single server running on x86 hardware which is provided by the Bicel. Here we are, we are not basically using the GPS. I think it's mostly functional validation so no mobility, no hand door. Now I think we'll walk to the server room. This is a server room where we have a CU-DU running. Again, it is running on x86 hardware. And we have combined both the CU-DU in the single server. And I think, and on the bottom you will see some of the Panta server which holds the OCN software running on the Kubernetes cluster. And the lab has been designed engineer based on the entity like cloud infrastructure, telco, task force specifications. So if you look back, I think you will see how the fiber coming out of the RU from the user area is connected to the DU which is in the server room. These servers are basically connected to Cisco labs, switch and router. And that is how that whole the CU, the OCN functions like AMF, UPF connects with each other. In fact, it's not shown here, but we also have like IPerf server running to validate the N6 interface. The TP lab is also connected over the VPN to the DS tester running as a bare metal instance on the packet.net. And also connected to the AWS Genkin which will be used for the whole CI CD pipeline and for the automation purpose. And it also connects with the TM find it which is a 5G UE simulator, which will be used for the performance validation. I think once we finish the functional validation of the OCN microservices network function. So far we have integrated like by cell geno B with OCN software. We have into interface up between by cell CU and AMF. And we are now trying to complete the 5G assay registration. We have passed authentication procedure and I think we are trying to resolve the one blocking issue with integrity protection, which I think Suresh will cover in the demo. Back to you, Phil. Thanks Rajesh and that is the real good information for the development community to see in real time what is the kind of infrastructure we are using in the lab. Yeah, this is a logical topology of the system test lab we have and the orange boxes here you see on the left are the radio node we have from by cell. And on the right, we have the magma AGW because it is a lab topology. We have the by cell node connected to a single physical nick on the AGW however in the real deployments in the field, we have many variants of the form factors. And we also have a integration test support tool from developing solutions called DS tester. Good to use for the sake of interoperability as well as early stage testing off the procedures that are built on magma AGW. Next slide please. Next we will get into the video demo off UE registration with magma AGW and also PDU session establishment TCP traffic flow via UPF and PDU session release. However, for the benefit of everyone before you see the video let us spend a couple of minutes browsing through what are the signaling traffic flows that happen behind the scenes that gives a better understanding of what is happening under the hood before we actually get into the demo. NetNet UE registration has a sequence of nine back and forth exchanges happening. And the first message coming from the UE is the initial UE message it goes via geno B on to a city bit demon a city bit demon has the capability to demultiplex the 4G and 5G traffic and eventually for the service bus, the traffic lands on the, I mean the initial UE message lands on the AMF. Next slide. Yeah. After validating the initial UE message, a MF sends the identity request back to the UE and the identity request also carries the API based on the permanent identifier of the subscriber for that reason the subscriber DB is consulted between AMF and the other network functions that are based on the service based architecture we have a GRPC based IPC infrastructure in the magma. And yeah, identity response comes from UE and it is processed on AMF and next. AMF sends the authentication request back to you. The message. Yeah, the authentication request goes to the UE and the authentication parameters are validated on the UE and UE response back with a authentication response. Next slide. Yeah, so the after authentication response, a MF sends a security mode command. And the security mode command is based on the integrity and encryption algorithm of the UE security capabilities that are received in the initial UE message and next slide. Security mode command is processed on the UE and UE response back with a security mode complete next slide. So after security mode command is accepted, then AMF responds back with a registration accept message to the UE and the UE response back with the registration complete. So this completes the UE registration procedure. After UE is registered on the core network. UE initiates a PDU session establishment request message and the PDU session establishment request is also NASA related on AMF this is a magma differentiator. The 3GPP specification talks about processing the nas messages of the PDU session establishment procedure on the SMF whereas in magma we terminate the nas for this on the AMF itself and AMF initiates a set operation as was indicated in the morning. The set operations are robust compared to the traditional rest operations of 3GPP. And of course these are level triggered. Session D responds back with the UPF TEID PDU session type and the QS characteristics that have to be supported on the particular PDU session. And with that AMF mirrors the session details on AMF and forwards a PDU session resource set up request to GNB. The state mirroring from session D on to AMF is done to bring in performance optimizations and efficiency in processing the N1 procedures. This is again a magma differentiator and GNB after configuring the radio resources will notify its own TID and IP address to AMF. And via the set operations up to number 7 session D goes on configuring the GNB TID on UPF and UPF reports the session states back to session D. So with this the first part configuration on UPF is done on the EGW and EGW now is ready to forward the downlink traffic towards the UE. After all these configurations are done AMF sends a PDU session establishment to accept message to UE and UE will now be said to send data traffic towards the DN. So the bidirectional data transfer can be initiated post the PDU session establishment. And in this demo you also can see the PDU session release operation. And here the PDU session release request is triggered by UE and that is processed on AMF and AMF forwards a set operation to session D. In turn we'll ask UPF to configure the fast path without the following rules and UPF reports back to SMF on the current session states. After all this housekeeping is done on the EGW. AMF forwards the PDU session release request to GNB so that GNB will release all the radio resources allocated for that particular UE's PDU session. And GNB will respond back with a PDU session resource release response to AMF. And with that the PDU session release completes. Now we hop onto a real demonstration which is a video demonstration because the teams are spread across globe in Asia, Europe and North America. And there can be logistic issues for which we can have connectivity issues. So for that reason we decided to run this demo as a recorded demo. Phil, can you share your screen and play the demo video? Phil is the audio off. We are not able to listen to any audio. Phil, can you turn on audio? We can see the screen but audio is off. Thanks for that. The video, the prior video had its audio turned off and that carried over in the sharing settings with your indulgence. I'm going to restart from the beginning. No problem. Thanks. You wish. Yeah. Let me start off with the demo scenario. Sure. Thanks. Good morning, afternoon, evening based on the location. Today we are going to demonstrate the fixed wireless access use case. This use case is based on the 5G code network functions developed as part of the magma repo. The main components we are going to use in the demo is the GNB and the US simulator, which is meant to generate the control and the data traffic. 5G magma 5G core services starting with MME, which is connected via Android interfaces. Other magma components, which has been the part of the 5G core is session D and pipeline D. We have averaged the existing magma infrastructure for the demo like subscriber DB, which is not shown here, but we have used it as part of the demo. So as part of the use case, we are going to demonstrate the UE registration, PDU session establishment, flows between SMF and UPF and this is based on the set interface. The same architecture is being used across other components. And in the end, we are going to show the TCP traffic flow between the UE and the DN. In this case, it will be 8.8.8. Over to you, Sanjay and Rupa. Thank you, Agesh. And hello all. Let's start with the magma services, Rupa. Let's verify the magma services are up and running. Great. So it looks good. All services are up and running. Let's verify the status of ports. First of all, HTTP port. It was good. So ports are up and GRPC ports. Yes, these ports are also up. We are good to go. And can you enable in and out packet statistics? Because bring up the simulator. This is a graphical user interface for GNB and UV simulator from where we are triggering use case scenario. Let's trigger the use case scenario. This has got triggered. Perfect. Thank you, Agesh. Thanks. We started seeing the packet capture on the left hand side, the leftmost terminal, table zero terminal. We can see it's the ingress table for collecting the stats for the incoming packets. The first two entries are for encapsulating and decapsulating the GTP packets, which are coming from the GNB or either coming from the UE. After the packet is marked for the encapsulation decapsulation, the packets are then sent to other intermediate tables. But finally, they end up in table 13, which is responsible for the QS enforcement. This is mainly used for recommending or to access to give the access to the packet. After crossing table 13, there are two copies of the packet which is made. One is sent to table 14 where it's locally consumed and the other is sent to table 20. So in table 14, which is the enforcement stats, this table is mainly used to track the statistics based on the packets and bytes for the subscriber, which is then made available to the existing applications for the billing purpose. And then finally, the table goes on to table number 20, which is the outgoing table based on the direction of the packet and the configuration. The packet is either sent towards the internet, that is to the data network, or it's passed on to the UE for to the UE application. Sanjay. Yeah. Thank you, Agesh. Let's check the packets captured in Wireshark. Yes, these are the packets are filtered by NJP protocol, which are got accessed between UE and AMF. The packet number from 8 till the packet to 16, these are the UE registration process and we got registered in AMF. After that, the PDU session establishment request comes from UE and the PDU session get established and then PDU session release request sent by UE and PDU session also got released. So, these are the packet captures. Go to you, Agesh. Thanks, Sanjay. Pupa, can you bring out the slide? Yes, perfect. Perfect. Yeah. So, this is the sample slice of the set interface that is being used between session D and pipeline D. This shows the set interface architecture we have been used in the 5G core services. As part of this session set, we are having this uplink and the downlink flows. Uplink flows classifies the packet, decapsulates the packet and sends it on to the internet and the downlink flow is towards the GNB4 with the GNP, GDP and capsulation. This whole session set is identified by subscriber ID, session ID and the version. This is how the set interface is implemented. Going to the next slide. So, yeah, once the set interface is received in the UPF or the pipeline D, the underlying fast path is programmed for packet processing. This flow sample shows the downlink flow in the OVS for packet processing. The first entry shows the ingress table where the packet is meant to be encapsulated over to the GDP and will be sent towards the GNB. So, it has all the components as the outgoing TIT and the IP addresses to be encapsulated or to be put on the packet. After that, the packet is passed on to the QS enforcement table as we have seen earlier. Here the parameters for filtering and radiating is applied on to the packet. If the packet is true, the stats will be counted and then the packet will be handed over to the outgoing table where then the packet will put on to the wire towards the GNB. So, this is a sample flow output for the downlink packets. Thanks. Over to you Suresh. So, this is the real demo of the procedures and traffic flow on HW. And in this case, the UE GNB simulator of developing solutions is put to use. With this, the demo is complete. Thanks, Phil, for bringing up the video. Now, Meridra, over to you. Thank you, Suresh and team. So, the summary status of this project, the features and functions that we have shown are incrementally added on with additional features working towards an alpha release in mid-March. And currently, some of the features that we have shown are under test in lab and alpha release testing going on in the lab. And spare portions of the code related to SMF and UPS are in the main branch and are available for download and also additional and also doing contributions. So, with that, we are really looking forward to taking this to alpha release in March. And thank you all for watching this session. And over to you, Phil. I'd just like to say thank you to all the team at Facebook Connectivity, WaveLab, ACL Digital, and also our collaboration with TIP for driving this forward as a collaborative community development and contributing towards this accelerated connectivity journey.