 Good afternoon. My name is Raymond Knopp, and I'd like to give you an account of open-air interfaces open software in 5G radio access network, core network, and mosaic 5G. Originally I was supposed to give this talk with my colleague Doug nicely from Qualcomm, but under the current pandemic situation that was extremely difficult to organize. So we decided that I would give this on behalf of both of us. So, who am I? I'm a professor in communication systems at an institute called Eurocom, which is in the south of France actually in the heart of the French Riviera. At the same time almost the president of the open-air interface software alliance which is a nonprofit organization, which tries to promote the open-air interface software packages. My main area of work today is in the radio access network component of modern cellular systems. So before I continue here I'd like to first thank our sponsor and a strong OAI supporter, Qualcomm, and in particular Doug nicely who normally would have been my co-presenter. So what is open-air interface? And who are some of his friends in this type of software environment? Well, it's become feasible today to put a compliant 4G or 5G base station, what are known as enobies or genobies, and the telecommunication network functions of the core network or the 4G and 5G in a commodity x86 box or cloud infrastructure for that matter. And some major vendors today start to adopt this approach to some extent. Now, there are different types of software out there today that can do this. Some are closed and some are open. You have a piece of software from Emorysoft, which is a very, very solid piece of software, a commercial software closed source, which provides 4G, 5G, ran and core network solutions. Open-air interface, which is open source code and also provides 4G, 5G, ran and 4G, 5G core network. And adopts what I would call a 3GPP friendly licensing policy. You also have software that's coming out of the O-RAN open source community, which is partially open source radio access network components. And also adopts what I would call a 3GPP friendly licensing policy. And then you have a strictly speaking open source projects like SRSLTE and what is coming SRS-RAN, which is 4G, 5G, ran. You have the OMEC project, which is a 4G EPC. The MAGMA project or MAGMA foundation, which is provides a 4G EPC and now also 5G core network components. And then you have 5GC, which is a 5G core network solution and open 5GS, which is both 4G and 5G. Now, because of all the software that's coming out, there is the emergence of what you can call radio hackers and development and user communities that are experimenting with 3GPP software implementations. And Open-air interface is one of those, both the software and the community. The Open-air interface software lies itself. It was founded in 2014 as what is known as a fond de dotation and the English equivalent is an endowment fund. So this, this fund really has the objective of maintaining and extending the Open-air interface software packages that were initially developed by Eurocom and actually donated to the fund. They donated, Eurocom donated the software to the fund. So today they're, we're actually looking and we have a lot of strategic partners from the 3GPP ecosystem that are either users or contributors to this, to the software packages. And we're actually looking to them to help us improve and make the software usable for the 3GPP ecosystem itself, so that it could serve as a reference software implementation for the ecosystem. Today we also have many associate members both from industry and academia. And often these are partners in collaborative projects in various framework programs, whether they be academic or industry. Now, since it is an endowment fund, we do accept donations and these are used to maintain an engineering support team. These are CICD, community management and building, project management, and industry relations to a certain extent. Today, these are the strategic members in 2021. So you can see it ranges from operators like Orange to equipment vendors like Fujitsu or semiconductor vendors like Qualcomm or Sequence or Xilinx. So intellectual property and research companies like Interdigital. And also institutional partners like the Power Project Office, which manages a lot of innovative research projects and research platforms in the United States. So today, what is open interface? Open interface is open source code, cloud native telco software. So I'm just going to show it here with a picture. A telecommunications network today or what it will become is going to be an interconnection of many clouds running a lot of software. And it's really disaggregated into three pieces, one which you can call really the control plane which houses the core network and even some of the RAM control network control plane protocols. And that's interconnected with something that is responsible for the radio access network. And also edge networks, which are clouds that are deployed close to the radio infrastructure for new services that require things like low latency, or for storing content closer to the users. And finally, you would also have other clouds which house controllers, which are managing the different software pieces that are running in the various clouds in the infrastructure. So, you know, open interface today are all of these blocks that you see on the top, top left, the AMF, the SMF. And the different software elements that constitute the core network or the control plane, the core network. And also one on the bottom left here which is one that would is actually part of the, but what we would call today the base station, which could be today very very far away from the actual radio equipment itself. And it's deployed with tools like Kubernetes and packaged in in helm charts for instance. So today open interfaces really like that. And also what's coming now is closer to the to the edge you might have pieces of the core network like the user plane function. The user plane of the of the base station, both in the upper part of the protocol stack and the lower part of the protocol stack and the physical error, what is called the DU. In terms of the controller, you would have a piece of controllers that would influence the core network. You would have an agent that would actually be running in the core network cloud. And similarly a piece that would be handling the radio access network and controllers that are that are installed or deployed in the, the radio cloud or the edge cloud or the radio. These, these elements that are that are that are reflected by the controllers are essentially what are produced by communities like the, the, the Iran, or the open radio access network community, where they, where they come up with the term like the ran intelligent controller that's what we have here. So all of these different the different pieces, you have to look at them like apps that are deployed in a cloud infrastructure today. And an open interface packages its software today in that kind of a framework other frameworks as well but that that is one of the target frameworks today. So, what do we manage today. Essentially, there are different project groups that are inside the community. Basically, those can be divided divided into two pieces, one one piece that uses the the way the way I public license and another piece that uses the classical three class BSD license for the way I public license components that that includes the four five g radio access network. So by that we mean the the you know bees the genome bees the UEs, which run the layer one and layer two network functions, and also RF modeling when when you put simulation into some of the systems. There's the five g core network components, which follow the three GPP service based architecture network functions. And finally the mosaic 5g, which are the controller functions. So, and also have some forms of orchestration and management inside that project. So these three project they represent basically the three clouds that I described in the previous slides. So for the BSD components, we do still maintain the release 16 mobility management entity, which is the one of the control the control playing functions of the 4g core network, and also the 5g non standalone core network. And this is now part of the magma foundation project. And this is this is managed jointly with the partners inside of the magma foundation and particular Facebook connectivity. Oh, I is also today managing a CI CD pipeline. So it's a very classical CI CD pipeline with we have a good repository which is at your home. There are also some components in particular the 4g core network components that are housed for historical reasons on a public GitHub repository. But basically from these two repositories, when people in the various communities push code to to the repository that triggers various pipeline stages that are running today, primarily at the at the your home infrastructure, and actually test different pieces of code. And when it when it comes to testing telecommunication software and in particular the, the, the radio access network components where you're running radio software which is operating devices, which have very random behavior. So that's extremely difficult and a challenging task for for CI CD. And we're actually looking for new methods to explore the the the different ways at making this more robust. So if I go into a little bit more detail now of the brand project group. On the left you can see the sponsors here, and some of the the contributors these are the some of the big contributors you see on the right. You can see it's like if you know the institutes as you can see that it's a mix between industry and fairly high profile Richard research centers. Now, the, the ransom from where I had can be deployed in different ways. And I won't go into all the details here but you can see here the, these were the different phases of development that we had leading up to the beginning of this year, when the the basic the three phases of the basic development of 5G were finished. And basically on the left hand side you have the, the so called non standalone 5G, which requires actually the 4G network to be deployed alongside the 5G network. And so you have the 4G 5G base stations that are talking, and the terminal switches between the two technologies as a function of when it is in coverage of the 5G cells. You can actually switch it actually stays connected in the control plane perpetually to the 4G side. And it just uses the 5G for the user plane connection. So an open air to this today you can deploy a this this hybrid or non standalone mode of 5G and much more recently, and later I will show you a demo. The full 5G solution which uses the 5G core network, and the full 5G ran for both the user plane and the control plane. So today, open interface can operate in these different modes. We can support different platforms. And I'm giving here a list of some of the radio units that we that we're using currently. So we can support the the the National Instruments USRP so the universal software radio peripherals, all of them. The, the, the different features of the, the, the air interface can be exploited differently on the different platform because some of them are more sophisticated than others. But these can be used both for the 4G and 5G components. And more recently, we're supporting some more commercial radio units, one from an Irish company called Benetel, which provides actually something very interesting from the community perspective. It implements one version of the O-RAN 7.2 frontal, which I'll describe a little bit later. We're also working with another radio unit from a company in France called AWS, which is functional both for LTE and 5G new radio. And this uses an EC pre frontal interface, which is, is which is a little bit different, but similar in spirit to the to the O-RAN. And here we've listed some of the UIs that we've tested with the with our software. Some of them are tested only in so called non standalone or the hybrid mode, and others have been tested both in standalone and non standalone. So the, what do we support an open interface both in 4G and 5G. You saw in that the big picture I showed the different clouds. Basically here you can see two of those clouds from the radio access network on the top you have the so called central unit. So that was the unit that was split actually between the core network cloud and the radio cloud. And that split actually connects to a another network element called the distributed unit, which implements the layer two protocol stack of 4G and 5G. So between between those two elements you have an interface that is specified by the 3GPP called the F1 interface. Now today that is standard in the open interface 5G solution. We have a version of it for 4G but it doesn't really have the same impact as the 5G version which is something that as today there are commercial components available that that we can interoperate with. So we do implement that F1 interface both the control plane and the user plane of that is actually a new implementation that was brought into the the software this year. And we're doing interoperability testing with a commercial solution from a European vendor called Accelerant to test the open interface DU against the Accelerant C. So that is one of the interests of implementing a an interface like this we can mix and match and take pieces from open interface and mix it with a piece from another software vendor. A little bit lower down between the within the what what 3GPP calls the DU there's an interface that is specified by the small cell form called the FAPI interface or the N FAPI interface, both both of them exist and if it's networked, if it's networked, it's in FAPI if it's within a data center or in between two chips on a system on chip it would be the FAPI interface. The open interface implementation of PHY and MAC, they implement the small cell form FAPI. So today all the layer one procedures that we have are compliant with the small cell form specification. So 4G and 5G for that matter. So here too we can interoperate with different software vendors at the level of the within the within the DU. And finally, if we go down a little bit lower, the frontal interface that which interfaces the actual radio equipment with the with the DU or the physical layer of the DU. There are different solutions. One that which I already mentioned the the or N72 user billing solution was this is something that was done with the with the Irish company Benetel. And we are actually now planning to do interoperative testing with other remote radio unit vendors and it's going on right now. We've just received a few of the radio units in our lab. We're going on with collaboration with one of our partners Xilinx using one of their new, one of their new accelerator called cards called T1, which you'll see a bit more in a minute. So all of these areas these different interfaces are a very important part of open interface because it allows allows us to interface with other partners. So if I can just quickly go over the roadmap for the rest of this year. We're in the process of stabilizing the, the interconnection procedures between the 4G and 5G for the so called non standalone or hybrid mode. We're bringing in support for my mo now in the in 5G both for non standalone and standalone up to four by four my mo if the hardware supports it. And we're in the process now of improving our throughput. So our targets today are anywhere from 100 to 400 megabit per second downlink. If we are using a 40 40 megahertz channel and 200 to 800 mega megabits per second downlink from a 400 megahertz channel. If we use a high end RRU. So the, the targets really are going to depend on the type of radio equipment you're going to connect to our software. Those are downlink throughputs and we're much more modest on the uplink for the moment, only targeting 30 or 60 megabit per second on the uplink. We're in the process of improving our link adaptation to take into account feedback from the from the terminals, and this will actually help us get to these targets. We are working on the basic frequency range to interoperability so those that that's the millimeter wave frequencies are the very high frequencies up at 26 gigahertz in the United States or, or even higher than that, including some of the beam forming procedures. So this is using some experimental hardware from our partner interdigital. They have a millimeter wave radio unit that that we're working on for the working with to interface and test to AI with commercial with commercial terminals. We're now adding support for flexible bandwidth and additional subcarrier spacings. This is in particular to support the low latency scenarios of 5G. So in particular we're looking at one additional dedicated bandwidth part for the low latency, and this is in a standalone mode. We have partners that are introducing the SDAP support so that that is the protocol layer to support quality of service control. As I mentioned also the F1 integration with a commercial CU solution from XLRM, the European software vendor. If we look at what's going on for next year. Essentially we are now integrating TTC and three interfaces in the EDLB and the GNB. This is to allow the an all software conformance testing of the UE protocol stack. The protocol vendor wants to use open air interface to test the conformance of their protocols. They can do that. And this is a new project that we started with the French chipset vendor sequence and a startup in France called Firesome. We are also going to introduce the so called E1AP. This allows the separation of the control and user plane in the in the radio access network. So basically in that first picture that I showed of the, the three clouds. There was one radio access component that was in the, the core network cloud. And this E1 interface is what allows that to happen. We are starting to introduce support for localization, coming from the release 16 specifications of the 3GPP. This is more specific to the standalone mode. We're looking at supporting frequency range to so the very high frequencies. The handover procedures will be integrated next year. And some early contributions for support of non terrestrial networks is coming in some of our European projects with some of the members of the OIA community that are involved both in developing OIA. And pushing contributions to the 3GPP standard in this area. We are going to enhance the support for the ORAN 72 frontal in particular by introducing the control plane in addition to the user plane and starting to use the this T1 card from Xilinx with commercial radio units. We will also introduce and I'll talk about this a little bit more in the context of Mosaic 5G support for the ORAN controller interfaces. So the E2 interface and the O1 interface. And in particular adding the necessary RAN agents inside the OIA 3GPP components so that we can allow the controllers to influence the behavior of the radio access network. So this corresponds to the third cloud that I described at the very beginning of the controllers that are influencing potentially both the core network and the radio access network. In this case it's the radio access network. A little bit more on this T1 card because in addition to being a providing support or interfacing for the radio units coming from the ORAN community. It actually also will provide us accelerator services that we can improve the computational efficiency of the implementation by offloading some of the very, very heavy signal processing and particularly the forward error correction off of the generic cloud compute resources and putting it into PCI express cards that are plugged into the nodes. So basically we will offload some of the channel decoding procedures. And you know this is a project that we're working on very, very closely with Xilinx and some other partners that work with Xilinx, an Indian company called DVDN. And we're working on some of the basic dbtk based drivers to allow this, this offload. So basically this ldbc channel decoding will be integrated into the OIA Geno B. In fact it already is integrated, and we are now doing testing with end to end with with with real UEs. So later we will look at the the lower L1 offload from the from for the ORAN 7 to using the same card. Okay, if now I switch to the 5g core network project. So here the the objective is to develop a fully three gpp compatible 5g core network stack standalone as open source software for the OIA community. And here the license as I mentioned at the very beginning is the, the OIA public license version 1.1 contributions are open to anyone who signs license agreement that that is our policy and today we have contributions from all over the place. We have, we have some, and we're very grateful to our sponsors Qualcomm, Facebook connectivity and international that are that are providing the funds to allow this, this project to, to advance at the speed that it is advancing. Today there there are several contributors you can see some academic contributors like your own Beijing University of post and telecommunication. And there are some contributors from the community there are too many for me to mention. I'm just listing some of some of the big ones here. Now, if I look at the status of this project, basically what we we set up to, to as an objective from the beginning was to get a solid and functional 5g core. So the basic procedures to allow multiple terminals multiple UEs with multiple PDU sessions. And then the network function and registration procedures and the session management procedures. And then maybe some additional features like network function registration network function discovery. So to be able to discover and select the right SMF or UPF. Some of the core network handover procedures core network paging. And a few other a few other procedures. Basically, there are, there are different flavors when it when it comes to deploying the, the basic five 5g core. The most minimal flavor is just the, the four basic nodes the, the AMF, the SMF the nrf and the UPF. That's enough to to sustain a communication with the commercial you. And then you can add other other elements, which are there for authentication and a, some of the more advanced database elements, which which you don't actually need to to to stay in communication but in a large scale network are required. And so the user plane, the user plane function is something that is not always deployed as software, in fact, in large network it is not definitely not only software it is heavily software controlled. But it is definitely a hardware element because of the amount of traffic that has to flow through it. And we have different flavors we have we have a software flavor that we inherited from the 4g core network, which has additional features features for 5g. And we can use the, the VPP UPF which relies on the VPP implementation from traveling, which is an open source implementation which has the PDK support. So those two are actually software solutions. But we're also working with a production grade UPF from a Canadian company called Colum, which is a, which is a UPF that runs on on before fabric, and can switch extremely high, high throughputs. So today we're trying to operate with with different solutions, so that we can enter interconnect with potentially commercially viable solutions as well. Now, in terms of the validation, we do our CICD with a professional tester. So we use a commercial piece of software from developing solutions called DS tester. We use to test the MFS MF and UPF with simulated radio access network components. We also do dragon test for MFS MF. So we test the MFS MF with simulated core network components so simulated SMF UPF and of course also the rank components. So that's isolating particular elements in the core network. We do over the air testing to and we use the, now we use the OEI Geno B, and even the open interface user equipment and commercial commercial modems like from Quack, Quack Teller Simcom to test the core network. We also use commercial Geno Bs, so MRI soft, by cell Geno Bs, our partners in China are using by self at your home. We also use MRI soft now. We use there, of course, we also use a commercial off the shelf few weeks. We use open source ran simulators. Things like Geno B Sim and UI ransom. Also in our testing so we have a variety of different tools that we use to get as much different types of stimulus as possible to make the software as as robust as possible and all of this is integrated into the the testing procedures with our machine. Now, in terms of deployment, both for CI CD and for even production deployment, the traditional or classic deployment is done on bare metal servers or virtual machines. We have ways to do that with all of our software components. We have also automated deployment of the network functions in Docker containers that are using doc compose and one of the one of the demos I'll do later we'll actually be using that pre deployed but we'll be using that. And then we also have a fully cloud native deployment like the one I described at the beginning, which uses helm charts on on the open shift cluster that we have in in so if you want to produce. I'll do a very quick video demo of deploying it on on a cluster. Here you have the timeline, which you can see this this was very ambitious project and there was there was virtually no software at the beginning. And today already in the middle of the project we have a fully functional 5G core that has been deployed in several labs across the world. We deployed and used with various genome be so this was actually very ambitious and very successful to this point. If I just jump to more or less where we are today. You know, we are now starting to test the the core network with production grade commercial UPF solutions. We are integrating already the, the, the network slicing functions from 3GPP. And we are also considering different event exposure procedures for all of the, the, the components that we have where we're going towards the end of the project which should be in March or maybe a little bit after March next year. We will also already have classification services redundant transmission for ultra reliable low latency communications, and also more, much more mobility support than we had today. Okay, if I now go quickly over the, the, the third project before we go into the, the demonstrations. The 5G is the newest addition. And you'll see in a minute, it was actually its own project up until the, the, the middle of this year. And the objective hasn't changed. We just brought it into open interface because typically mosaic 5G was used with open interface. The features are a little bit different and very much related to the, the original cloud picture I showed at the beginning. They were to provide an ecosystem of open source 4G and 5G service platforms reusable components and use cases. And at the same time to provide an SDK to be able to architect and compose your custom 4G 5G network service delivery platforms that are tailored to the use case. So it's a little bit different than, than developing the, the core components of a 3GPP network this was really at the, at the periphery of the 3GPP network, but necessary to, to actually deploy a real network. So, inside of mosaic 5G when you combine it with open interface there are really three platforms. There's one now that is called trier Maddox, which is all about orchestration and management. So AI operators, the elements of resource control monitoring, everything related to deploying on Kubernetes. The notion of image storage is there and blueprints for deploying in your own environment that's that's within trier Maddox. There's also the flex Rick, which is basically the ran intelligent controller. And it will use the, which is already actually starting to use the, the oran e2 interface. And it is there to, to provide a an example of a real time controller. So the ran agent, which is the piece of software that's running in the proximity of the, the genome be so the, the CU component, the genome be, and the do come on with the genome be so that the, the, the controller can actually influence the, the behavior of the protocols in the system. And there's another new piece of software called flexion, which is the equivalent but now acting on the edge network, and the core network components. So, if I just look at the highlights, the, that are coming, there will be a flexible ran intelligent controller SDK, the e2 agent, and xapse xapse in the in the oran sense. A flexible core network controller and associated xapse and intelligent ran and core network operators and use case driven CICD for the, this component combined with with open interface and potentially actually also other ran platforms. So here you see a little bit of the past and where mosaic 5G came from. It was its own project, developing the, the similar components with different names. Some of them have changed names, but the spirit is remain the same. And where it is today now that it's fully integrated with open interface is providing really an agile 5G run and core network service platform on top of AI. And here you have the roadmap, which I think you can, you can look at afterwards. Okay, so before I show you a couple of demos. Just a brief overview of your comes infrastructure and social police. So, we have a state of the state of the art computing computing cluster, which is running right at OpenShift. And this is done in collaboration with Red Hat. And we use it in various projects with them. So it is a server farm with with the switching fabric, which is also interconnected with some radio equipment. So you can see an example of a small cell tower that's on the top of a building with with radio units that are connected to the the switching fabric, so that we can actually do outdoor testing of some of the software components that we have. So the demo that I'll show you here will be using the cluster to various degrees. Some of it using actually in OpenShift and other pieces of it on bare metal, and on just on servers as docker containers. But you know it depends on the type of deployment that we do but we can do a full solution, like the one I described in the first slide. So if I just now describe the first demo. So what I'm going to show you basically is an end to end OEI stack deployed on on OpenShift using Helm charts. So you can see the six, the seven components that I have here are a subset of the components you would have in a full scale 5G network. So you have the AMF, SMF. I'm even putting in a GenoB here and a UE, which are there to in a simulated traffic. It's actually a full implementation of both the GenoB and the UE that are connected with what we call the RF simulator, which allows us to have actually test the GenoB and UE software running in real time on whatever computer we like. And this is interconnected with the core network and all of it running on the same cluster. So here there's actually no radio equipment, but all of the elements of the radio network are actually there and running. And what they are is basically pods inside the OpenShift Kubernetes cluster. And they're interconnected on the fabric of the cluster. Some of them within the nodes and some of them are operating on different nodes. For instance, the GenoB is definitely not on the same node as any of the core network elements. Okay, so if now I go to the short video that my colleague prepared and I will explain you what's happening in real time. So here he's logged into a machine you can see it's called Iliad. Basically that's the jump host that allows us to instantiate elements in the cluster and also monitor the cluster on the command line. And you can see he did a helm install of the OII NRF, which is one of the elements you saw before. And he's just checking that it's actually deployed on the cluster with the famous OCE commands. So OCE get pods, it lists the pods that are deployed in the namespace. He's just deployed the AMF and checked that it's deployed. And now he is deploying the SMF. And you can see a few logs that came back after it was deployed. So he'll deploy all of the elements. And then he will, as a new element makes connection with another one, you will see that he'll grab the logs from the elements just to show that it was actually connected. He's still in the process of deploying every element. So here he's getting the logs from the SKWU or the, or the equivalent of the UPF. Just to check that it was connected properly to the SMF. So this is what I mentioned before this is the, the, the tiny SKWU, which is a, which is basically a UPF. And it's a common piece of so code with the, with the 4G SKWU. So he's already deployed the Gino B. And he's checking that the AMF sees that the Gino B is connected. And that's, that's what happened. And now he will install the, the UE so that it can connect it, it can connect to the network completely. So he's listing all of the pods that were deployed. And now he's checking if the UE is actually registered with the network. And it is. And now he will, he is now doing an RSH into the container of the UE. Looking at the network interfaces, he's going to show that the, the UE got an IP address from the network. And now he will just show you that it is actually connected to the internet. He will ping using the tone interface to Google. So we deployed a full 5G network on a single cluster. Of course, the, the, the Gino B and E node B were simulated, but they were RF simulated. So it's actually a full implementation of the Gino B and the UE. And we had full connectivity. Okay, now I'm going to do a little bit more of a risky demo. This is really an end to end 5G standalone demonstration with, with a commercial terminal. So you can see the terminal here, a picture of it, it's in our lab. I'm saying it's a bit risky because I'm going to log in live into our network here. So what has been pre deployed here on this time not an open shift, it's on another server using Docker compose. And it's essentially the same thing, although without the helm charts. So we have a, the same network that you, you saw earlier in the, in the open shift deployment. The only difference is the synthesis of a particular machine it's fairly simple for me to go on to that machine and I've logged on to one of those machines already. I've placed wire shirk, I've started wire shirk on the network interface so that we can sniff the traffic between the radio access network and the core network. The terminal that we have here is a, an embedded SIMCOM module that you see here on the mother board of this mini Linux box, which is actually running a Qualcomm Snapdragon 855 modem. The genome be itself is a is running in one of the servers that you see in this, in this rack here it's its name is Mozart you'll see that the machine that I'm on is Mozart. And here I'm not running the split genome be I'm running the monolithic genome be, and it's connected to this device here which is one of these national instruments. So that's three, three, 10 radios. Okay, so that's that's the scenario that we have. So let me go into my virtual machine. So, here you get this is the wire shark window here. This window you can see I'm on this machine Mozart, I've already pre logged in here beforehand. So here I'm just going to invoke the, the unit be. Okay, and normally what you should see. Let me just run it once, and then stop it because the usp needs to be poked once. I'm going to run it and normally here in the wire shark window you should see the excuse you see it twice because I ran the genome be once before you see the ng setup request and response so that means that the genome be is connected to the core network. That's what my colleagues are going to show you before in the logs of the the AMF. And here we're seeing it with with wire shark. What are the other things do I have here. I here I have a status window, which is just giving me traces from the genome be that shows me that it's actually running. And in this window here. You can see the name and our module one. That's the name of this machine that's the little mini Linux box that had the, the SIMCOM module on it. And what I have here is a little script. This is the, which basically tells Linux to attach the, the module to the network. So these QMI clear is the is the set of scripts that work with these kind of modules to trigger the connection so I'm going to try this, and hopefully it will work right off the bat, and it did. So you can see here in the status in the we that it obtained an IP address. You can see in my status window here that I have all kinds of nice statistics telling me how good the the radio quality is the way I do not be. And here in wire shark, you can see the full trace of the protocol of the, the attached sequence of the 5G network. So if you have people that are well first in the 3GPP and GP, you will recognize these messages. So here I've completely connected this module and normally I should be able to ping and I will actually show you that I'm using the interface. 150. I should be able to ping. And I am able to ping Linux. So just to show you one other interesting thing I have here a local machine, which is local to our notes, I'm sorry, wrong IP address local to our network, which actually shows you the latency avoid you know be in this configuration we're down somewhere in the order of seven to 10 milliseconds round trip on a pink, which is not too bad for this configuration of 5G, which is go back to conclude here. In conclusion, all the components are available today, and can be used to build an experimental 5G network like the one I just showed you. So today we animate three project groups radio access network 5G core and then the new mosaic 5G group within open interface. So I'm encouraging everybody to get in touch and to get involved. We have slack channels mailing lists, regular online meetings, and by annual workshops to. I'd also like to thank again our sponsor and the way I support her.