 I'm Ola Goldner, Director of Technology, Strategy and Centralization in MDACS, and two years ago during O&S in Europe, I provided a session on SDO and open source partnership, the joint value which is being developed in open source as a part, as an implementation of a different standards. And this session is an update of the session, what has changed during the past two years, and specifically we zoom in on those things which have changed and which are relevant. So we will be talking on the open source side, mostly on those organizations which organizations are on up, O&F, OpenV and Acrena, those organizations mostly involved and impacted and implementing a different standards. And on standardization side, it is a TMS forum doing all those open API on connecting with the external system, with BSS or SS system, free GPP, of course, developing all 5G related standards, also 5G network management standards, SC, SCNFB, SCM, SCMC, they of course are being implemented by open sources, which we can see here and I've mentioned it and I'm going to explain what exactly is being done and what exactly was done during the past two years. And the new one which actually I'm also going to cover is ITF as it has developed its process on developing transport network slicing and what we are doing in O&F in order to support that. Now, O&F is very interesting one because O&F sits on the intersection of open source and standardization with having all an alliance thing done in free GPP and then actually implemented by different open sources by O&F, by all an open source community and by on up and this is what I'm also going to cover today. So for the standard usage outline for on up, this is what I'm going to cover first. So SCNFB, of course, this is the key group of standards you know, implementing all those IFA, sole interfaces, interconnecting, orchestration of the third party with orchestration of on up, interconnecting with managers, all those standards have been updated but no new standards have been implemented or produced in the last two years except for some extension for cloud native. So the effective components on on up side are SDC, SO, VFC, VNFM adapters in SO and FEO adapters external API and so on. All these tools, of course, the work has been continued and the effective components are SDC, AI, DC, same form as a external API to the BSAS system and then SO, AI, DC components are involved and implement those changes on access at the same which is producing an end-to-end architecture for network slicing for the closed loop operation. The most impacted modules are SO and SO adapters, 3GVP, that's the key for developing and implemented the network slicing architecture network slicing use cases which is the key use case in on up. So they developed quite a few of the new standards for the past three years and on up network slicing use cases is fully following those. Now on 3GVP again slicing and that has been extended quite a lot in release 17 and now in release 18 and what is being defined by 3GVP actually by the same people who participate in on up activity is being implemented for network slicing use cases with SDC, APSI, DC, the most impacted entities. ITF as I said is defining a transport network transport network slicing for the transport part. So that has been implemented for the network slice use case in on up. So of course, it's the same interworking that has been defined for quite a lot of time and affected components SDC and NFS decay. The next one I'm going to cover is ORAN and you know the major body which is defining ORAN standard of course is ORAN Alliance and ORAN Alliance is working in a very close cooperation with 3GVP of course. This is at the same as at the same defining the full end to end architecture while ORAN is concentrated on ORAN piece at CNFV of course for all virtualization aspects regarding on up interworking. There is quite a lot of work being done on actually implementing a different interfaces. The Q1 is A1 interface and then non real time rig for the sum of the use cases those have already been implemented and there are more pieces in work. I'm going to cover that as well or two interface which is currently being defined by ORAN Alliance in process of defining is also planned to be implemented very short. Now for 3GVP the most important and affected companies are all one interface and potentially also A1 interface. Now ONF, ONF has started the implementation of actually near real time rig and so we get to start but that definitely will be done the integration and interface with ONF towards the joint solution and the affected companies of components of course ORAN near real time rig E2, O1 and A1 interface. Now Ukraine you know the affected SDL partners doesn't change that much for the last two years for at CM it's at CMEC obviously I would say this is the key at CMEC open APIs to be used by Ukraine and the affected companies micro-MC a crane architecture. ONF that's the age deployment use case applying age being orchestrated by ONF also work is done in order to support it and ORAN of course it's radio edge cloud placing run network functions on the age. That's those are the major that hasn't changed much you know the list hasn't changed but the implementation ORAN has been advanced quite well through the last two years the same as ONF and so you know while implementing age deployment by ONF actually with the leverage by leveraging of those standards you know the new ones the extended ones have been used. Now regarding the NFV SCOPE relative to the scope of ONF that hasn't changed that much still you know they have slightly different scopes with SCOPE being a subset of ONF SCOPE so here on this picture we can basically see what is the subset at SCOPE you know marked by yellow with red which is being implemented the intersection scope which is being implemented by ONF and ONF SCOPE include OSS features such as pnf orchestration service and application configuration and service application FCA. Now it's very important to see how ONF interfaces with external management system by leveraging at different SCNF interfaces because in many cases basically you know a service provider have an existing orchestration existing with NF manager which needs to interconnect with ONF so for that in that sense you know of course the key interfaces so five interfaces interconnecting ONF with legacy NFVO there might be so three interface connecting with VNF managers or many VNF managers so for that so one it is very important to see how ONF interfaces the external network management system because service provider may already have orchestration system VNF manager system legacy OSS system and those actually are supported by ONF by using those access sol interfaces and here you know I have an outline so for example for interfacing with external legacy NFVO we use sol five interface for interfacing with VNF managers basically sol three is being used for interfacing with VNF sol three sol one VNF descriptors are being used also so two interface can be used for the legacy OSS system interconnection sol five is being used and again then sol one with defining NS descriptors are being used so all those are implemented by ONF that's important so to mention so basically for the deployments which have an existing orchestration system ONF provides a full set of the tools to actually to interconnect with those Now I'm going to talk briefly about ONF access at the same interworking as I said access at the same is the key for the definition of end to end network service management and you know the key use case for 5G is network slicing which leverage leverages access at the same standards there's a key network use case is implementation with the closed loop basically while detection and correction of the issues is performed in closed loop without user intervention and all those actually are being defined by access at the same which has been done a lot of work for the last two years so they're defining domain orchestration services domain intelligence services as I said for closed loop operation domain control services for each one of the domain to serve the state of each managed entity as well not just end to end but also how end to end zooms in into each one of the domains and domain assurance services which actually monitors the management entities and provides live performance and full data to support closed loop operation so I would say that those standards are extremely used and they're conceptual they're conceptual in order to give a guidance to Onup to Oran to Ukraine even in order to implement that end to end service so that might be connected of course to a different domain level and functionality of management might be implemented on the domain level as well but access at the same actually the key strength of access at the same is to define how all those interconnected into the same solution and so while implementing that network slicing use case closed loop use case in Onup we are guided by access at the same standard regarding Onup support as I said it is you know the key use case that is currently being implemented as end to end network slicing and it has several domains it has RAN management domain core network management domain NFV management domain for interconnection between virtualization actually interconnection of a different domain it might also have transport management domain not mentioned that on these slides that access at the same is also defining how transport is interfaced with RAN and with core and how that whole end to end thing works so the interconnection that fabric which works between those different domains is actually being implemented by Onup by leveraging access at the same standard Onup for GPP interworking that's again you know the key use case is network slicing and for GPP SA5 is the group which defines the slicing for RAN and for core not for transport transport is being defined by ETA so basically what is being done when we implement RAN and a system of core and a system of functionality and on the interfacing between those you know all the parameters which of the slice slice subnets which are being provided slice profile a subnet profile all those things are being done by implementing the standards defined by SA5 actually in the very close collaboration with SA5 people Onup ITF interworking as I said transport network slicing use case is being defined by ITF now in the network when we implement an end to end solution for mobile especially you know it has RAN it has core but it also has transport so implementing transport for the end to end solution meaning getting all the measurements and combining them into holistic end to end picture and then actually providing parameters from the end to end to transport is extremely important and this is why Onup actually is interfacing or implementing you know transport network configuration by actually using the definitions of ITF for transport network slicing you can see here briefly how it works so basically transport network configuration are provided here from the end to end solution front hole, mid-hole, back-hole you know there might be several subnet inside of the transport of course in case of foreign then we have RUD, UCU those are splits so that is still in progress not fully completed but some implementation of this already exists in Onup and that was done even before actually you know the RFC of ITF is issued so by the same people who are working with in ITF on actually building those definitions and implementing them in Onup now Oran interworking Fridge WP and SCNFB zoom in into that architecture doesn't change much but it has been extended a lot you know the interfaces the O2 resource management interface based on SCNFB was really in process of defining for the last two years and you know the standard supposed to be issued in December I believe this year now A1, O1 interfaces has been largely extended in Oran Alliance in order to support those O1 also in Fridge WP in order to support the functionality and you know has been part of it has been implemented by Oran part of it has been implemented by Onup and of course you know as standards gets more matured you know more implementation is getting into Onup and Oran when Onup and Oran interworking Fridge WP this is actually new thing this is a management data architecture which was developed or is process of developing by Fridge WP SA5 actually so you may know about NWDAF network data and analytic functions which exist ever since Fridge WP release 15 and in addition to that SA5 group of Fridge WP has been developed management data analytics which can be end to end can be in a different domains and study have been concluded and now they're in process of formal specifications of standardization in release HIN so this is the work which is ongoing now if we zoom in into this and look how that interfaces and interacts with Oran then basically Onup SA5 might be implemented in Fridge WP cross domain MDAF consumer and then Oran can be implemented cross domain MDAF producer and those would be interfacing then of course there might be also a producer of the information for MDAF in core domain and in random now MDAF might also introduce interact with NWDAF for providing and gauging overall analytics not just management data analytics but analytics on subscribers and any other types of analytics in order to assist the functionality so this is the new thing which was developed in standard release process of developing in standards recently and you know again we are closely watching that as soon as standard is mature then we'll be in place hopefully by the end of this year beginning of the next year you know those implementation will also come into place for data analytics flow and now Oran Interworking Onup that is not a new thing that has been updated so we can see here Oran open source some more environment with non-real-time rig near real-time rig as I said near real-time rig might be implemented also by ONF and that collaboration will come in place as well now which is important here and which I show for the different interfaces the status of the support as of now so or two as you can see not yet supported in ONF in present but hopefully it will once the standardization is completed end of this year now A1 RESTful Interfaces supported in ONF today O1 Netcom Interface supported in ONF today O1 WEST EMCM PM supported in ONF today as well and microservices for F-Cups you can see that there as well as ML AI being a part of the SMO limited support in ONF today will be extended as we move forward of course because this is the use case which is considered very strategic by ONF and by O1 now ONF based SMO non-real-time rig framework for control grid so basically non-real-time you know here we can see with a little bit of the zoom in specifically SMO and non-real-time rig the way they should be and they are about to be implemented in ONF so ideally you know when we complete the implementation non-real-time rig framework will support running 10 communications from VSS, UI or ONF and FSMF R apps LCM control of a machine learning model including control loops operation and AI ML workflow for training and update of machine learning models and of course system integration with SMO framework yeah so as I said previously the ONF activity to support non-real-time rig and applications related to is quite a new one so as it gets matured we're also planning to get into integration of what is being done by ORON what is being done by ONF and what is being done by ONF or ONF and here you can see the slid down of the architecture into several for non-real-time rig on a strict implementation and the split into OCU or DU and or RU architectures and those modules which is currently being implemented by ONF again this is a comparatively new activity and we are looking forward in order to integrate ONF and ORON these ONF outcomes so for conclusion you know obviously networking standards and open source collaboration have a lot of the common ground for supporting the requirements of open standard based network it must be working together because actually you know the best thing which can happen to the open source to the standards is that there is an open source actually implemented to try to wait and this is exactly what is happening right now as I explained in ONF in ORON in a cryon in ONF without waiting in a year's implementation you know standards are being produced and right away being implemented and then even being corrected and updated as a result that that collaboration actually helps a lot also to feedback into standards and to you know make an updates in the next release of the standards based on what was implemented and how it works in open source so really works in both direction that contributes of course to faster adaptation of open source and standards by the market ecosystem you know interest both clearly on the vendor side and on the service provider side to make it works to a test and to build those reference architecture those implementations by open source in order to see how standards work and of course it's accelerated eventually service provider network transformation and service innovation uh thank you very much in this presentation which you may get after that there will be a full description of all of the implementation of standards in open source and all of the interruptions so you could see also what was implemented not just for the last two years which I mostly covered now but in general what exists and what collaboration exists between network standards and open source in general thank you