 Hello, everybody. Welcome to this open networking and edge summit presentation about ONAP and O-RAN and how they're the perfect complement here. My name is Stephen Tirol. I'm a senior expert in automation and management at Ericsson and I was prior on the ONAP TSC and the ONAP architecture chair and had various roles in ONAP there. So together with my colleague, Mattias Sintton. I'm an expert in run traffic handling and performance at Ericsson and I've been working with O-RAN for the last two years. We're going to walk you through this presentation for the next 20 or 40 minutes or so. So in here what we believe that is and we see that O-RAN is defining an open and dis-advocated RAN. And at the same time, ONAP has been defining a network for automation platforms for multiple domains that includes the RAN. So we believe the question is not why these will meet, but how they should meet. Okay, so we start looking at O-RAN then. O-RAN is an industry initiative that works for additional desegregation of the RAN. It was announced at Mobile World Congress in 2018 and later in the year the first working group meetings was held. O-RAN has now 23 operator members and more than 100 non-operated companies contributing to the work. If we start to look at the O-RAN principles and what O-RAN would like to achieve, their aim is to create an industry initiative then, as said, for additional desegregation of the RAN. And it works with some principles where this openness then should bring service, agility and cloud-scale economics and intelligence for self-driving networks with AI optimized closed-loop automation. Through these principles, O-RAN works with three main objectives. The first one being desegregation and open interfaces. Within this objective, O-RAN is working on defining multivariate interfaces within the distributed unit defined by 3DPP. That means that there is another layer of desegregation introduced in O-RAN compared to 3DPP, which disaggregates the radio functionality and the baseline functionality. But here also, O-RAN works on making the 3DPP defined interfaces such as F1, truly multivander, and the initiative should try to make deployment of these multivander interfaces as easy as possible. The second objective of O-RAN then is automation and optimization. As part of this, O-RAN is defining two new control loops and two new radio intelligence controllers. The first one, the non-real-time rig placed in the SMO domain, the service and management and orchestration domain, is supposed to enable automation as part of the management domain. With the non-real-time rig comes an interface to work on a functionality called A1. The second of the new control loops is internal to the O-RAN and here O-RAN introduced the near real-time rig and the E2 interface for allowing AIML as a tool when trying to solve the radio resource management problem. The third objective of O-RAN is virtualization and open software. There is an aim to cloudify raw functionality as far as possible. And in doing that, O-RAN is creating a hardware and software reference architecture. And it also then looks on how to orchestrate cloud infrastructure for raw applications. If we look at the structure of O-RAN, there are nine different working groups defined. And these very much reflect the objectives of O-RAN. What we can see is that working group four and five very much relates to the objective number one with further desegregation. We're working group four works on the low-related script or on open front-all interface. And working group finds the standardization and work around the 3DP defined interfaces such as F1 and X2, for example. For objective number two, optimization or optimization, O-RAN has two working groups working on the new control loops and the controllers associated with that. And also, of course, the interfaces. If we look at the working groups six, seven and eight, those correspond to objective number three with virtualization and openness coming. Aside these working groups, working on specifications and details around the different objectives, we can see that there is an open source focus group in O-RAN. And this open source focus group is a collaboration between the O-RAN Alliance and Linux Foundation. We're the mission then to support creation of software for the radio access network as defined by the O-RAN architecture. Within the O-RAN software community, we can find currently 13 different projects running. And also here, those projects relate very much to the working groups defined by O-RAN. To the left here, you can see working groups related to work to the radio-intelligent controllers that O-RAN has defined. And to the right, then, you'll see projects related to the controller part of the management layer or the service management and orchestration domain. And those are the products then within the O-RAN open source community, which will be mostly related to the things that we discussed today and the things that O-RAN up to. If we look at the O-RAN architecture, this also then very much reflects the objectives of O-RAN. As we can see in this architecture, you can see how the different working groups map to this architecture. At the bottom here, we see the split in open-front all interface between the radio and base functionality. And in the middle, we can see the split between the 3DP defined functionality and O-RAN defined functionality in near real-time rig, which should allow for greater and simpler or more automated optimization of run functions. The near real-time rig should also be designed in such a way that it enables the usage of AI and ML as a tool to solve the radio resource management problems. And on top, we can see the service management orchestration functionality also then prepared to enable using AI and ML for use cases related to more management related tasks. And here we can also then see that there is an additional interface standardized by O-RAN called A1, which we will talk a lot more about later in this presentation. Also, O-RAN has just recently started to outline the internal structure of this SMO framework. And inside this, we can see that we can find the non real-time rig. And the non real-time rig is also, as part of the O-RAN work, split into two parts. One framework or platform part and then one part containing the intelligence that should solve automation use cases in the round domain. Within this split, O-RAN is then also talking about an R1 API, which will allow the split between platform functionality and the intelligence, which O-RAN called R-Apps. Thank you, Matthias. There's quite a lot going on in there. It must be very difficult to get track of it all. You've got the new interfaces with the A1 for the policy, the R1 for the apps and the traditional O-RAN for the configuration there. But with that already, I can see a little bit of how this relates into O-RAN App, where it's providing the automation platform. So it's a very good fit with the SMO concept as such there. I think that's really interesting. So I'm going to say a few words about O-RAN App then. As you know, O-RAN App started in 2017, it's been going for a while. So I assume that there's a lot of people that are very familiar with this already, but in case you're not, it could be good to say a few words about this as by way of introduction. So it actually stands for open in the sense of open source as well there, networking automation platform. And it's not really constrained to a particular domain. It goes across multi-domain. So O-RAN could be one of those domains if that's the way you choose to apply it. So there's I think a good touch point there. It creates a framework for model-driven service design and orchestration, policy-based control on analytics, and what that really is there to enable as well is sort of closed loop automation or control loop automation for virtualization and SDN. So this can be closed loop assurance, it could be open loop as well onto that there. And the way this is being built and organized, if you're not familiar with the O-RAN App there, it has this Linux Foundation Networking LFN board, that's a governing board. They deal with things like membership and they deal with things like money and marketing and so on goes into reporting into there. And they're very prominent, of course, in the ONES type of events and organizing those around the world there. Then when it comes down to the actual, the technical work, that's gathered and steered around what they call the TSC. So that's the Technical Steering Committee. And it has a number of subcommittees to support that, dealing with the requirements. So what's the requirements in the next release? So the TSC will be talking about what should be the content and what's the timing of the next releases and dealing with things like, yes, it's okay that this person, that we have the elections for the different subcommittees and projects and making sure the community is healthy there. Then the subcommittees have got requirements dealing with what should be the business requirements for the different projects, different for the releases, and that's looking at this from a cross-cutting perspective because the projects themselves actually produce the code, which is sitting here on the right, these are the code producing artifacts. So once this is for alignment of the contents, that will describe the impact into these. The architecture is looking for the architectural consistency. This is both someone has a new proposal, I think it should go like this, and this is very much related to how we can systemize these requirements. And of course, this should be a model driven platform. So modeling is very important. They're also dealing with the overall modeling. OWNAP has a security subcommittee and they're looking at both security requirements and security mechanisms and looking at how we can make this platform then secure. Control loop is looking at the cross-cutting the cross-project control loop and maturization there. As I said before, you've got the code producing projects. These are very similar to the architecture research. So you'll see things for service design and creation. You'll see one for policy, someone and so forth. I'm calling two out, one's dedicated to actually facilitating the documentation and there's also one that brings it together as this integration project. So that brings together a consistent release. We have a few coordinators and their purpose is that's a person and that can be a point of contact and they can bring things together. So one of them is the network management area and Magnus is working in that. He reaches out and deals, he's a single point of contact, but also reaches out to other communities. For example, with ORAN, but also with Etsy and making sure there's a good flow of information there. If we move on to the next page, so if we dig one level down, what is it? You can say that ONAP provides an automation platform for managing the services and resources throughout their entire lifecycle there. And so there's a, at a high level, a design time where you can onboard your resources and work with your service definition. When you're happy with that, you're pushing it over to the run time there. And that's taking feedback from the managed environment, which is the network, analyzing that, deciding what actions to be taken and pushing changes back down. It also has the ability here to, of course, instantiate or even modify a service definition. And then there is exposure, which is a lot about leveraging interact with other communities. So that you'll find TMF into there, you'll find little bits, well MEPH has come into there also via TMF. And we think about this from a number of particular dimensions, a number of particular aspects. So we think one aspect is that it provides a reference functional architecture. So we'll see, we'll introduce that on the next slide here, but you give expectations of the type of function, the functionality and architecture that could compromise a, that could make up an automation platform. When it has that architecture, there's a number of components that provides definitions for these reference components as well. And so far this is rather independent of the actual source code, but of course it is a reference source code as well. And you can take that piece by piece, or you can take that as the whole environment and use that there. It also comes with requirements on the VNFs and PNFs and CNFs in order to say, hey, here's what's necessary, here's what's recommended if you want to be managed by this network automation platform there. So it's looking for a bit of industry alignment around that way there. What you can see here is the most recent architecture from, from ONAP. I won't go into sort of, I won't go into all the details, I'll just pull out a couple of points. Here's the service design and creation part here. Actually, you have the design time, you have the overall runtime that was mentioned before, and here as we get down, we'll see actually, apart for actually watching and managing ONAP here. So this is making sure that the ONAP components are alive and can be instantiated and healthy there. What you see here is the service design and creation. There's a message bus for communication here. There's the data collection analytics and events for receiving and running for the receiving events, analyzing that, and actually an environment for different applications to be able to run on here. Adoption towards different cloud environments. We have these SDN control and application control, and now these are interfaces as down southbound towards the actual applications and understands the applications as well. And you could see that, okay, Matias was talking about the A1 interface, and that seems a good fit for what would go on in a controller here. Then we have the virtual function controller, and this deals with some of the software life cycle management as an NFEO and M capabilities. We have some infantry, service orchestration, policy, and actually managing the controller. In relation to the controllers, they have this common controller SDK, and that's a set of libraries and utilities for actually defining what you want on these controllers. So you don't have to be limited by these actual controller definitions. You've got other capabilities inside the CC SDK. This also applies for model utilities and the TOSCA password there as well. There's some common capabilities that are shared between this. Then, of course, you've got the external interfacing for both the human perspective and the external APIs. I said this also has component definitions, so here's just one example of a component definition. There's a definition for all of this, and this happens to be data collection analytics and events where you can see there's the south bound connections to the managed elements and also the services that are offered and construed. So you can see, for example, how it connects onto SO, how it deals, connects to CLAMP, which is closed loop automation and policy, so on and so forth. There is a description of this for each and every component. If we move along, one important aspect I think of ONAP is also the industry alignment, and it's a bit of a meeting point there, and here we see that both for ONAP and also for O-RAN. If O-RAN has the service management and orchestration that's focusing on the management of the RAN and ONAP is an automation platform that can cover different domains that includes the RAN, it's very natural that this can actually form an ecosystem, and ONAP could be one realisation, maybe there's others, but one realisation of the platform for the SMO. But together there's a broader community than that. Both ONAP, of course, can have a look at the 3GPP management interfaces, and O-RAN is, as Matias was mentioning, has obviously a great interaction with what is happening at 3GPP, both the network function side but also the management interfaces side. GM Forum has some capabilities for inventory management, service management, and that also relates to these scopes. Since they both ONAP and O-RAN deal with the virtual software as well, it's very natural that there's part of the ecosystem dealing with Etsy Mano, and ZSM, Zero Start Service Management, is also dealing with automation, and there's a good interaction between ONAP and ZSM, and I think there's even presentations about this in the recent layer 1, 2, 3, but there's interactions there, and that will of course take into account some of the O-RAN aspects as one domain. Of course, if you think about this from a connectivity perspective, both the ITF, MEF, and BBF have an interaction relationship here from the transport relation, and since this is not just specifications, since this is realisation, the CNCF is another important relationship there as well. And of course, this is interactions, and this is not always done through the formal means. A lot has been done, for example, as with the people that we have working together, both within the community and between the community. So for example, with the Etsy Mano work, the work we've been doing about the Etsy Alignment in ONAP, we've had presentations to the Etsy ISG about that, and there's the similar collaborations and presentations in between the ONAP and the O-RAN. Okay, so Matthias, you'll take us through some of the ONAP and O-RAN alignment examples here, I think. Yes, I will. Looking forward to that. You're welcome. As you pointed out, Steven, the scope of O-RAN is very, very big, but we thought, I mean, to exemplify this alignment, we'll touch upon two specific things where the scope of O-RAN and ONAP meets. Sorry, Matthias, I've lost your voice. Sorry, something happened there with the mute button. I'm terribly sorry. But I don't know where I was lost. The start of the page, I think, we can go back to. The start of the page, okay. Yes, so one specific example of where the scope of ONAP and O-RAN meets is then, as pointed out earlier, the A1 interface. And to understand the O-RAN interface, you need to understand the idea behind the non-real time rich. And the non-real time rich is being specified by O-RAN to add the capability to change the behavior of RAN based on analytics data and business policies on a per-UE basis and on a time scale that is down to several seconds. This should also be done then so that the non-real time rich is prepared for utilizing AI and ML as a tool to solve specific use cases. With this in mind then, the A1 interface is specified in O-RAN in addition to the ordinary configuration interface O-RAN. And this A1 interface then has the capability to issue policies for individual UEs down to the RAN so that you can affect the RAN behavior for individual users. And this is something that will be useful in cases where the default, when you understand from a management point of view that the default configuration is not working for a particular user. A good example of this is that with additional information of how fast the UE is moving, for example, you can trim mobility or set policies for mobility for the fast-moving UEs in an area to avoid ping pong effects or similar in RAN. But A1 also adds the capability to provide enrichment information to the RAN functionality from the management layer. So if you have analytics functionality in the management layer that gives an insight which would be valuable for the RAN function to work, this information can over the A1 interface be passed down to the RAN functionality as enrichment information. So that is kind of the overall objective of the non-return rate and the addition of the A1 interface. Okay, so for realizing this has been some work on the Converged A1 adapter, previously there was a little bit of work actually done in both the TSC inside of O-RAN and also there was an initiative started actually in ONAP as well. And now they've come together to put this together and created what's sort of a Converged A1 adapter. And this is done inside the common controller SDK to make the actual A1 adapter and then realized as part of the SDNC project and therefore part of the SDNC artifact there. This will then be upstreamed actually to the O-RAN OSC for integration. And this is described as actually I mentioned before there was a requirement subcommittee there is a requirement that's the ONAPs slash a 3GPP and O-RAN alignment A1 extensions. This is one example there are a few others but this is one example I think was worth highlighting and related to the A1 interface. Okay, the other specific defined by O-RAN is then the split between the the platform some platform functionality and R-Apps within the non real-time rick in O-RAN. And for this O-RAN is working on an R1 API that should allow for separate life cycle management of the different automation intelligence which O-RAN called R-Apps and a platform functionality. And this then decouples the automation into intelligence that addresses different kind of automation use cases from the platform functionality and is supposed to enable a simpler and more flexible handling of or a more flexible way to address different use cases with different kind of intelligence. Thanks Matias. So this R1 seems to be a very interesting interface. So I guess it needs access to data from the network and also be able to drive what you were mentioning describing before the A1 interface there. And to achieve that what we see is that there's a number of interfaces provided by own up components and I describe them the examples of those before. And what we see is there there can be an interaction and I think a sort of a subset of these could be quite valuable on the R1 interface. So we see and also thinking about from the R1 interface there could be needs that haven't been thought of today. So we see that there's a there'll be an influence between between O brand defining the R1 interface and a bit of a selection or adjustments to some of the the own app components interface. So this is a a cooperation that we an ecosystem in a way that we see that can be a very valuable land starting up now. Okay, now the if we move on to the concluding phase now the summary what we've been explaining is that O-RAN is creating an open and desaturated RAN and that includes the service management and orchestration layer there. We see that O-NAP provides a network automation platform and we see that there's a great opportunity for industry alignment here and we have and we see that's already started we provide a few examples of that. So with that I'd like to thank you for your attention or virtual attention today and I hope this was an enjoyable presentation from us and there was something in it for you. Yes, thank you very much for listening. All right, we have about four minutes for live Q&A with our speakers. Please feel free to submit your questions via the chat or Q&A panel and we will have our speakers answer them. Okay, can you can I be heard? This is Stephen. Yes, we can hear you. Great, thank you. I tried to answer some during the chat some of the questions that came up. Thank you for that. One was why is O-RAN linked so closely to O-NAP? What about OSM and other related solutions from big vendors like Nokia and Ericsson and so on there. And what I want to say there is O-RAN has a specification part and that's independent of any realisation and then it has an open source reference to the realisation work that they're starting up and working on and we think O-NAP is one possible reference platform for that. I'm not saying there can't be others and there's some activities that's ongoing like the A1 interface. As there's an example there and there could be others I think there was also a question from say a follow up question related to that as well as what about the front hall and the back hall and there's a few architectural options there to my understanding and of course O-NAP has transport orchestration capabilities I don't know that AT&T has been driving that thing for some parts as well and that could be a possibility I don't think it's at the top of the discussion tree at the moment but it certainly could be a possibility going forward as well. Yeah the first thing you guys I don't know maybe you have a better view. Yeah so well a slightly better view I would say because I guess we pointed out in the presentation on the scope of O-RUN it's very very big and I must admit that the lower layers here it's not my expertise perhaps but just to point out that there are open source projects in O-RUN related to development of the ODU and I guess it would be within those open source projects where the MAC schedule would be implemented. Okay I'll also note that not a question but apart from our colleague John Keaney who's actually will be demonstrating some of the ONF-A1 policy demos that has been done which is actually a representative of the work that we have in slides he has a link to that there so thanks for that now John. There was a question about the the slides and the quality of the format the quality of the text here the slides will be uploaded in the process sort of data. Was there anything else that people wanted to raise well I guess then we're at the end of our oh was there one coming in have you just have you just okay what about the relation to TMEF so the relation to MEF of course MEF has the legato and so on in general that relates into into ONF and it also brings in the the TM forum API is there and when it comes to the what the R1 interface could be that will be sort of influenced by the ONF platform there the part of that discussion I think could actually include what's the relationship towards the TMF APIs but it's very early very very mature to say exactly what R1 will do on on that one but that may come into into that play I don't know if there's anything else specific in R1 related to MEF other than other than that at the moment I've been answered the question Charles or addresses it maybe not answers it all right I think we have time for one more question it looks like it came through via the chat okay thank you okay so you're asking really about the A1 okay the the relationship about the A1 policy control and what happens with the 5QA it's an excellent question and something that can cause us a debate the way we see it and this is I can't speak for O-Round I can't speak for O-NAP I can only speak for the way we see this from every some point of view is that the R1 will be respecting the 5QIs that come from and the priority given by the 5QIs coming from the core network that's the business driven sort of requirement there but there are certain situations where you need to actually work at assuring the actual experience or doing slight optimizations while still respecting what comes from the core network and that's where they the cause nodging in the A1 could also come there are other cases that are independent of that for example policies for setting the frequencies for a fast-moving use and saying don't go to micro sale macro those are also but it's a very good conversation that one George all right well thank you to our sorry that's okay I just wanted to let everybody know that we did upload the PDF of the slides into the handout section so you should see a handout icon underneath your video panel where you can locate that PDF and I think that concludes our time today so thank you everybody for joining and please feel free to keep the conversation going using the Slack channel provided in the chat