 Hello everyone. Good morning. Good afternoon. Good evening, depending on the time zone that you are attending the session from. So I would be spending the next, let's say 20-25 minutes to present about our journey on leveraging open source for the realization of network slides and service orchestration in the indigenous end-to-end 5G dashboard. Okay, so I would like to split this presentation into two parts. The first part where I would be explaining about the end-to-end 5G testbed, which is an indigenous testbed, which is like a country-wide testbed, which was, which is being developed in India. I'll go over the details of that, of the larger picture of the overall 5G testbed. And then the second part of my presentation will focus on the orchestration layer for the testbed, wherein we successfully made use of open source in realizing what the testbed actually wanted. So this is in a nutshell. So without further ado, I'll just go directly into the overview of the testbed. So this 5G testbed, right? So this is an indigenous 5G testbed, which is like a nationwide testbed that is in India. And it has been sponsored by the government of India. I mean, when I say sponsored, the sponsorship is for the academic and research institutions. The sponsorship is given and it is also consisting of, or there are also industry partners who are part of this testbed in terms of active contribution to the development of the testbed. And as well, I mean, providing the technology stacks or whatever, they do get different kinds of benefits or they stand to gain from it in different ways. So there are different models, but at the end of it all, it is a kind of a collaboration between academia, research forums, as well as industry. And this is a nationwide testbed and I would say it is one of the, I would say a few, let's say large scale nationwide testbeds across the world. And even in India, in the previous generations also, we have been having testbeds over like I said, right? This is a true kind of an end to end testbed for 5G. Now, why do we want to have this testbed in the first place? So one of the primary goals of this testbed is that from a country standpoint, we want to be at the forefront of the 5G development and deployment in the sense that we want to be involved actively in the development of technology and not just be a consumer of technology as far as 5G is concerned. So in terms of active contribution to IP creation, in terms of innovation, contribution to standards and so on. Now, how does it, I mean, or why is it kind of important to us as a nation, right? One of the things is some of you might already be knowing about the make in India initiatives where we are focusing on developing technology indigenously within the country. So this is one of the kind of, I would say the enablers for such initiatives. And the second reason or the important reason is for initiatives like for example, smart cities which the government of India is driving, right? So for all these kind of initiatives where we want a real kind of an environment to test some of the technological components as well as the solutions in a real-world kind of setting, right? Not in a lab or not like partly, but from an end-to-end service or end-to-end use case kind of setting if we want to do, I mean, a validation of the solution for this also this testbed is going to be quite useful. And in general, in building the 5G ecosystem, right? And when I say the ecosystem, maybe I'll elaborate a little more as we move forward in the country, right? So this testbed is going to be one of the key enablers. And how this is going to be realized, right? If you look at it, so one of the things is we would be scaling and evolving some of the testbeds that are already existing. So I mean, for example, in 4G also, there have been some efforts to build testbeds. However, from an end-to-end point of view, it may not be still there and it definitely requires some scaling as well as enhancements and evolution. The second aspect is to come together, right? Whether it is academia or research for our right, maybe not one institution might be able to deliver or to realize or be able to realize all the components. So to be able to collaborate and build the modules, right? Grounds up which are missing or which are needed for the end-to-end testbed. And then the third is of course the industry partnerships where, I mean, active participation is sought from industry partners in terms of building this testbed. So if I have to say some, a few key points, right? About this overall testbed, one is the openness. So this is an open testbed. You should note that I'm not talking, I mean, I'm not saying it is open source. It is open in the sense that anybody can bring in their components, whether it is IP or solution or in the case of like orchestration, we are bringing like an open source based approach. So anybody can bring in their components, you make use of the testbed, contribute to the development of the testbed. Of course, the benefits and the what is in it for each of these stakeholders, right? Will be different, I mean, will be different depending on their contribution and depending on their role. So the openness is one important thing. Then the second thing is it kind of nurtures and builds the ecosystem with respect to 5G in the nation. And the third key aspect of this overall testbed is it's that it is indigenous. So when I say it is indigenous, it means that it is either built grounds up from within the country. I mean, whether it is academia or research or industry partners or we make use of open source. So typically we don't have, I mean, I would say not, I mean, commercial components as part of the, let's say the fundamental testbed, right? Anybody, any vendor or any supplier or any product company can bring in their solution and validate their products or their IP or their solutions. But the testbed itself, right, the end to end testbed itself, it's kind of indigenously built. So this is the essential thing that I wanted to highlight. Now, probably if you look at from overall the participants who are contributing to this testbed, right? If you see, so you can see that the academic and the research partners are pretty much spread across the geography of the country. And they are the premier institutes that you can find within India. They are all actively involved in the development of the testbed components. And they do this activity in collaboration with the industry partners. So the industry partners will touch upon a little while, but with respect to the reach and the accessibility, right? So because the various, I mean, the partners involved in the development of the testbed are geographically spread apart. The intention is that the testbed should be available as well as accessible to anyone within the country. So what this means is we will have multiple instances of the testbed running in different locations. But there may be some, okay, some variations, maybe certain specific components could be hosted only in certain locations. And the intention is also that people should be able to access it from anywhere they want, at least from within the country. Okay, obviously subject to the, I mean, the model in which they are allowed to access it. So if we look at the industry partners, you can see that there are quite a number of industry partners who are collaborating in terms of the actual development to the testbed, as well as they provide the required technology for stacks of the components. So I think this kind of illustrates that we do have active participants to the development of the testbed. Now, if you look at what this is being used for, right, what this testbed is used for, I mean, like I just touched upon briefly earlier that we want to develop the 5G ecosystem and we want to be at the forefront of technology development. But if you want to look at it a little bit more and be a little bit more specific, right? So these are some of the usages of the testbed that we foresee. So one is the use of IPs. So first of all, as part of the development of the testbed or creation of the testbed, there will be a lot of IPs that will be generated. This is not just about that. It is also about people can bring their own IPs and maybe they can do an interoperability testing as well to validate their IPs. Also they can also give their own IPs to the testbed. Obviously they will retain the IP rights in full because like I said, this is not an open source testbed, but this is an open testbed. So that way it kind of promotes development of IP as well as the use of IP. The second is R&D and product development wherein the testbed can be used as a real world kind of testing ground or a playground for experimentation, validating for the functional as well as the non-functional test interoperability, you name it, right? So this is going to be a key enabler and this is very, very significant if you look at who can stand to benefit from it, right? It's not just the big players, but for example, take the case of a startup. They may not be able to afford first of all to have a full-fledged end-to-end 5G testbed number one. Number two is even if they can afford it, it might take considerable effort and lead time and expertise to build a world-class testbed, right? So from that angle also it's going to be useful and the same applies to any academic or research institution also. While they may have their components specific or their, I mean, the interacting component kind of a testbed, a true end-to-end 5G testbed might not be that easy to realize. And the third is to be able to develop services and applications, right? So application development is going to be one of the, let's say we do not know whether it's going to be the killer thing for 5G, but it's definitely going to be one of the key things that we see with respect to 5G, especially because it is going to address a lot of industry vertical requirements in a custom made way, right? With the help of network slicing also. So in that sense application development, right? Whether it is edge applications or I mean like user applications, whatever it is, right? Whatever kind of applications this testbed can be really going to help them also to kind of test their interoperability as well as the performance and other aspects. The last point is about the skill building which is very, very essential from a country standpoint because we want to develop the 5G ecosystem and we want to generate a lot of skilled R&D workforce within the country. Just to give you an example, right? That this is a real thing and it's not just on paper. As of now, right? In this testbed about 400 to 500 engineers are actively, I mean, people are actively contributing in some way or the other directly to the testbed. And I mean, I would expect some many more also to be involved indirectly or I mean not, I mean, in some form or other indirectly as well. So this is a real thing and we want to take it very seriously from a country standpoint. So there are different ways in which we can use the testbed. I will not go into the details. But one of the things is that we could have, we could have like an application developer plug in their apps into the testbed and do the testing. The second thing could be that, for example, a product company, right? A small startup who just want to develop the L2 stack protocol stack, right? For the Genome B, they can just bring it in and plug it into the testbed and then do their validation and interoperability testing. Same way, somebody wants to develop a UPF, right? Then they can just plug it in a testing and validation of their solution. In the same way, right? For example, if some researcher, they want to check or they want to test their algorithms, obviously they will be testing their algorithms. But from an end-to-end standpoint, right, how their algorithms can affect the end-to-end, for example, call flow or the session. That they may not be able to find the layer for the finding. What we have realized of the orchestration layer was raised as a partnership again. See with concern, right? We considered a few choices in terms of how we want to build the orchestration layer. So one is the from scratch development that is build it grounds up. Second is the open source based approach, which is use the own app, right? The open network automation platform as the base and then make the necessary customizations and enhancements. This is the second approach. The third is a hybrid open source approach wherein we get some domain orchestrators or domain controllers like OpenDelight or open source Mano and then implement the end-to-end orchestration functionality, whatever is required. The fourth one we did consider, but we didn't actually take it seriously because as I said, right? We wanted to be an indigenous testbed, so we didn't really consider the use of third-party commercial products, at least as part of the core testbed. Of course, any third-party orchestrator company could plug in their orchestration solution and validate it. That's perfectly fine, but as part of the testbed, we didn't prefer this option at all. Then we kind of did a, I mean, a benefit versus challenges analysis. I'll not read from this slide. The bottom line is that, yes, apart from the open source related assets. So considering all that, what we did was necessary for our testbed. And some of the reasons are like, because it provides open and standard interfaces towards the network functions for the configuration, fault and performance management. And the other advantage that we saw in ONAP was it provides the orchestration for all the three domains, that is the RAM, core and transport, because we are really talking about an end-to-end 5G testbed. So orchestration across domains is quite important. Then the other aspects, I think we all know, it's microservices-based and then we can interoperate with third-party controllers. And the support for 5G use cases, which is quite active in the community. Of course, one of the challenges in ONAP was the hardware requirements, but this is a challenge that we had to overcome anyhow. Okay, so the next slide tries to give a little bit of an overview of which components we have started customizing or enhancing. I'll not get into the details here, but this just gives you a flavor of some of the components that we have started customizing and making suitable enhancements for our use cases. Now let me spend a couple of minutes on the use cases that we have been working on. So far, so one of the first use cases that we picked up was the having the 5G, basic 5G use case which involves the RAM and the core and using ONAP as the end-to-end orchestrator. Then having an end-to-end service with the RAM and the core and then sending some video traffic. So this was one of the first use cases because we believed that this would kind of set this stage for many more use cases. Okay, so this was the starting and then we successfully realized this use case last year and demonstrated it at the Indian Mobile Congress last October. So maybe I will just zoom in a little bit on what this use case was about. So this use case, it is about setting up the RAM and core service and having like an end-to-end traffic flowing from the UE towards the maybe like a video server. Okay, so the one of the first templates and onboard the service after which we instantiate the service and then once the service is instantiated we will be spinning up the core network functions that are part of the service definition of the service template and then we will also wait for the PNF. So as far as the RAM is concerned, we modeled it as a physical network function for the sake of simplicity to start with and then we wait for the physical network function to register itself with ONAP and once the registration process is completed we then push the remaining part of the configuration and once the configuration is completed then we start the traffic so that we can see the flow of traffic across the network functions that has been instantiated by ONAP. So without going into too much of in-depth details this slide kind of gives you a high-level view of this step and the core BNF related artifacts, physical network function we do the design and the onboarding then we instantiate the service and because this was also something that was in progress at the time we started with this ONAP journey so what we did was in order to demonstrate the end-to-end flow we used a RAM emulator which then was able to establish a connection with the real AMF and then subsequently we had the steps of the UA getting registered and then the traffic flowing. As part of the roadmap we will also be replacing this RAM emulator with the real RAM or the real 5GNR. So this we will see in the following slides. So the next step that we embarked upon or which is like work in progress right now is the simple closed-loop control using ONAP. Obviously not everything is available readily in ONAP. We had to make or VR in the process of making some enhancements here in order to realize it. Of course the basic closed-loop functionality is there but for the way that we want be in this agit right for our use case not all the functionality is present. So this requires some enhancements in the DCIE and some enhancements in the SO and CVS as well as the inventory as well. So again I will not go into the details of the ONAP components and the steps. So this flow chart gives you the high-level flow assuming that 5G services already active with 5GNR and 5G core network functions. And if I have to just summarize it at a high level right whatever steps are involved. So the first few steps are somewhat of a reuse of the phase one use case work where we will have to make some minor enhancements and then it will be up and running. That is the design of the 5G service and then instantiating the 5G service and performing the initial configuration. The key part for this phase is when we talk about closed-loop control one of the key things in closed-loop control is to have performance management data right that should flow continuously from the network functions and then based on the performance data that is reported by the network functions you analyze them and then you take suitable preventive or collective actions. Now in this case what we assumed was maybe I can just go on to the next slide what we assumed was we assumed that the network functions already know which performance management data to report. Later on we will also support the creation of the measurement jobs right like what is defined in 3GPP and similarly with respect to the actual PM data we try to keep it quite simple so that we are able to show the end to end flows and then we will add many more additional PM data that we will look at for analysis. So the idea is to demonstrate a full-fledged closed-loop for a 5G service that was the whole intention this is a work in progress. Yes maybe spending a minute or two on the lessons that we have learned so far right at least specifically focusing on the orchestration part so what we saw was this open source based approach right it enabled the industry partners right so we could work in close collaboration and we could have like a clear workspace so depending on their areas of expertise maybe one partner was very I mean kind of hands-on and skilled in deploying on app but another partner had the skills to develop some of the I mean implement some of the enhancements another partner had a good experience in integrating on apps with the network functions so that way we could clearly define the workspace and we could work in close collaboration across multiple industry partners which typically could be quite challenging right from an operational standpoint and it also enabled us to kind of explore as well as innovate and apart from that there was a good amount of learning for each of the partners involved and this open source based approach kind of simplified our needs and it also fulfills the testbeds current and the future needs with respect to the what is needed from a testbed standpoint right in terms of the functionality but what we also realized right during this whole journey we also needed not only a full-fledged orchestrator like on app but we also want a simple interface if we want to just monitor or use the testbed right not focusing on anything about orchestration or anything but just I want to see the health of the testbed or I want to maybe restart a VM or restart a VMF or whatever right without looking about the integrates of the end-to-end orchestration so for that we may need a simple interface we can call it like a simple network management function or an element management function whatever it might be or a simple management layer but this is something that we have started developing and we will be working further to realize it and the same way we will also need a mediation layer for the network functions to report the PMFM data so that we can keep the network functions that testbed agnostic to the orchestration layer because tomorrow if we want to bring in another orchestrator right we don't want to impact the network functions in terms of CMPM and FM interfaces so this is also something that we have started upon and I will not spend too much time for the roadmap so these are just this is just to give you a flavor of what we want to report now so the next step currently we have the close look only with the core of IG core we want to also extend it to the RAM and later on to the transport also and then also we also want to start with the network slicing related functionality because network slicing in own app open source that is just taking off in the Frankfurt and Quilin release that we are also actively involved so we want to leverage that as well and then we go into the advanced scenarios ok maybe I will just spend a few seconds before concluding and then leaving some time for Q&A so what we have done as part of this orchestration journey right so we have successfully used own app open source as the base and then made suitable enhancements or customizations in order to fulfill the indigenous testbed requirements ok and what we also anticipate right once the network I mean since now we have a very good base that is established we expect a lot of innovation to happen in the orchestration playing itself because network automation is a subject that is very active in the industry today in including AIML or even without it so we expect a lot of innovations to happen and we hope that the testbed will be like an enabler for such innovations to happen and so far whatever we have seen right the journey has been like a mutually beneficial one so we have been able to deliver some outcome to the testbed at the same time all the industry and the research partners who are involved in the development of the orchestration play we have been able to get something from it so in that sense it was mutually beneficial and I hope this is kind of I would not say a lesson or a case study but it can be looked up as an example of successful academia research and industry collaboration leveraging of open source in order to I mean realize a higher objective and deliver some tangible outcome thank you all thank you very much for your patience in listening and I would be very happy to take any questions that you may have thank you very much once again