 Hi folks, we're just going to wait a couple of minutes so that more people can join before we officially get started, but welcome. Hi folks, we're going to go ahead and get started. Welcome to today's LFN webinar. Today's session is being produced by our end user advisory group and our topic is CSPs explore ONAP consumption models. We get into introducing our speakers, just a couple of housekeeping items. All of the attendees will be muted during the presentation. However, if you have questions, there is a Q&A dialogue box at the bottom of your screen. So feel free to type in your questions at any time. We will leave some time open at the end of the presentation to go over those Q&A live. Also, the webinar will be recorded and available for viewing tomorrow. So anyone who registered will get an email link to that live or to that recording. Okay, so let's go ahead and introduce our speakers. If we can click to the next slide please. So joining us today is Javier Herr. He's a her. He's a technology strategy architect, senior leader, advisor and consultant with telecom Argentina. And we've got Lee Huang. She's a researcher at China Mobile Research Institute. All right, so I'm going to go ahead and turn it over to our panelists. Okay. Thank you, Joe. Good morning. Good afternoon. Evening everyone. Welcome to the EOAG webinar, CSP's Explore ONAP consumption models. Today Javier and I will bring you this presentation today. Indeed, we have recently produced a survey and white paper about the adoption of ONAP within service providers, which shares the views on the most important considerations, opportunities and impediments towards assemblies and user ONAP deployment. Today's webinar will cover the key considerations for conception aspects of ONAP, what are the challenges, key concerns, models and reference, as well as the opportunities for CSP's looking at projects like ONAP. So today's webinar is an overview introduction of the ONAP conception white paper. If you want to know more details, please click the link to download the white paper. Next page please. So, so today Javier and I will lead you to explore the consumption and adoption model of ONAP from CSP's perspective. So we're sharing will start from the introduction part, then we will explain the purpose of this white paper. After that, we will bring you the options and analysis of consumption models. Also, based on what we have served in CSP's, we will introduce some key findings and bring up some recommendation from CSP's view. And we will also summarize these observations and recommendations. Specifically, as shown in this page, Javier will be responsible for the introduction, purpose, consumption models and will give the conclusion from the survey and analysis. And I will lead you go through the conclusions and suggestions of the survey one by one. So, that's welcome Javier first. Okay, thank you Lee and thank you also Jill for the introduction and good morning, good afternoon, good evening, depending where you are. And in this slide you have the agenda. As you can see, we will do firstly an overview and next we go through the purpose of this white paper. Remember that this presentation is a summary about the white paper title on a consumption model as Lee mentioned, a service provider perspective, published by the EU AG working group from the Lino foundation at working in June 2020. Afterward, we will go through the rest of the topic already enumerated by Lee. So, going to the to the introduction in this is in this is a let me do a brief introduction about the EU AG scope and objective. And also about the open source advantage and on a particularity. Probably most of you already know the end user advisory group, but for those people not familiar with this working group. You have on the left side of the line a quick overview. The end user advisory group was created by the Linux foundation at working to share view challenge and make practices between user organization highlighted highlighting new areas of opportunity of the developer community is made of individual from different user organizations, reference CSPs, and as the voice of the end user the end user advisory group supports also division of honor. So, going to the or seen on the on the right side of the of the line. You have some topics. The first one is the open source projects advantage. And one more thing that maybe I forget is that remember that the end user advisory group is the author of the white paper, looking for understanding the on up consumption, Lee has already mentioned that an adoption model within the CSP. And finally, facilitating them. I was talking about that that on the right side of the of the slide, you have some topics that probably again, everyone of you know, Additionally, all of these aspects. I will. All this that I will describe. You can find with more details in the white paper. Okay, but going directly to the advantage of the of the open source. Everybody knows they are related to to the code being publicly available and open for others, which enables the crowdsourced to go create and so on. And for the reason, the CSP has right have right now choices. The choice is one of the choices is proprietary versus open source or even a combination of both. But clearly, the advantage of the open source is that it allows the access to the underlying underlying functionality versus service and support encapsulation. So community collaboration versus vendor decisions, collective intelligence versus individual vendor leadership. Finally, open source is a choice to accelerate innovation cycle pace, have a Roma definition visibility, just to name some of them. The, the, the, the last but not least is a is a really important aspect that is the on a scale scale and and natural. We are dealing, we are dealing right now with the very special case. This case is very challenging for the community. Since currently, there are not many projects with similar characteristics. Again, talking about the scale and natural, neither in the past. Again, we are dealing with a very, very particular project. So we are trying to illuminate as part of the USG working group, the consumption challenge, the model consideration and opportunity regarding honor. Let's go to the post of this white paper. But first, let me explain something about the general scenario. The, the, the, we are living in what we call in the, in the paper, the now economy. We don't have time enough to go deeper into detail. But this now economy is part of a much broader scenario of changes, perhaps as a humankind never seen before, which is the four industry revolution. For those interested in, in, on this, you can consult source like, for example, such as the word economic form. Okay. In which they talk a change the of such magnitude that maybe they are asking theirself if we will continue as, as, as almost obvious. But coming back to the now economy, consumer are demanding new services and, and these services being offered or deployed in almost real time. For the reason we talk in the, in the white paper about agility, flexibility, efficiency, everything that you can see in the, in the, in the slide. And what does mean for the CSP, they have a huge impact in the CSP, because they need to transform structurally to meet this consumer requirement, becoming what is called DSP digital seller provider. That's mean go from an infrastructure centric view to a service centric paradigm, even adopting some principles that allow it in the, in per scale, be successful. The open source platform, or the model of the, the model based on open source platform is completely aligned with to this vision, because enables agile service design deployment and management to satisfy customer demand. Now, on the right side, you have something that we call the initiative fermentation. On the right side, we will list a couple of, of challenge related to open source and other initiative fermentation. They difficult resource and effort focus and also CSP option for, for, for selection, the right tools. This is the reason why in, in the bottom part, you can see that the, we try to represent the, the need to accelerate the cooperation, the collaboration and the alignment between all this initiative and also with the SDO, the standard development organization. In the middle of the line. Finally, you have a picture that it says some summary of this aspect. Let me briefly go through this picture. We have a service centric vision enabled by APIs and a model driving approach and analytics assisting in, in network operation, improving customer experience, making, sorry, making the, the network transparent to user and consumers and finally arriving to what we call the closed loop or the self healing, self healing network. Also orchestration and network and application control. Everything having or including a coordinated, a coordinated work with other initiatives, initiatives and SDO, as we mentioned previously, as a conclusion with honored being able to cover the ambition of solving the network out of automation puzzle. Well, in the last three, three years, and that is described in the, in the white paper, the primary, the primary on a development focus was the technical robustness of the platform is a functional maturity and operational readiness. For the reason the purpose of this paper is to help provide guidance to CSP who are considering adopting on it. Well, if we take everything we have described or we have been talking during this presentation, we can do a recap about the current on a scenario. On the left side, you can find some of the high level topics. For example, the need that the, I mean, the, the, the future service will be very different to the service that we have currently and that means that we need to transform from CSP to DSP. Also on a has gained a significant traction recently, delivering the value to user due to the reason that I describe in the previous slide. We have also described when we talk about the scale and nature, we have also talked about the complexity of the of this project. And finally, for all the reason the CSP should consider multiple aspect to integrate on up with direct system environment. This is a high level, but this last point can be spread in some other aspect or detail or bullets. Okay. That is playing what does mean for the CSP. For example, the integrated solution with career grade version of on a module service model application and microservice will to build to to running on the, the complaint and working infrastructure including PNF CNS BNF controllers also connected to on a operate operational operational changes developer tester and designer need to deliver and operate service through this platform and ensuring on up as a security problem. Many can be many, many other consideration but what we are trying to say here is that the, the, the, the several aspects that the CSP should consider. Okay. The, again, this slide is just a visual representation about the initiative proliferation and the need to harmonize them. Including SDL on the right side of the of the slide. Let me remark that there is a recent paper launched or published by the Lino foundation and working about this harmonization in this particular case. It is about the open source project and the standardization bodies are harmonization, including 5G network slicing with on up. In this picture, probably we can discuss sound of element or aspect, or this, I mean, needs of harmonization, but the objective, the final objective of this picture is, is, is again to show you the complexity of the scenario that we are, we are dealing with. In this slide. In this case, we would like to, to represent just a proposal for the end user advisor group about the steps to follow and on up deployment and reach a, let's say, a positive result. It starts with the, with the bottom up vision in, in which in the first step, you have to solve the integration with the network element. I mean, the sovereign interface. The next step is take a service management approach in order to orchestrate and be able to deliver this new service that the, as we mentioned, the, the, the consumer will be asking us. And finally, in, in order to, to, to reach some exponential value creation include the machine learning and artificial intelligence in, in order to reach the, the, the closed loop. But again, it is just a proposal. And this working group is aware, as we have been talking during, during the presentation. And as we will see also in the conclusion of the survey that Lee will, will present that there is not a single path a golden receive or a silver ballot, silver bullet to deal with this challenge. And let me remark that specifically each CSP will have their own definition and decisions, according with their reality. Many aspects are involved in, in these decisions, such as the CSP business strategy, culture process, processes, general context, countries, region, macroeconomy, organization level of maturity, scale, competency, and so on. Well, finally, we arrived to maybe the core of, of, of, of the white paper and, and the, and the survey. That is the conception model in this slide. I will present them quickly. And we will go through each one of them in the next slide. Basically, a project like on app can be consumed as we mentioned in, in multiple way by CSP. The first model that we, we discussed with, we call complete auto, autonomy model. In this model, the CSP is the responsible to be in the software and deliver it in house. After we will have a second type of model, which we call complete outsourcing model in which the CSP engage with the system integrator PSI primary system integrator or maybe a vendor who can do all this stuff for them. I mean, the, the deployment and the delivery. And we have also a third model, which we call semi outsourcing model in which the CSP look for some distro. Okay. And this, this on app distro is what they deploy in the, in the organization. And finally, what we have a fourth model type that is called standard basic reference implementation in which the CSP take on app as a reference and look for a, for a vendor or, or, or something else a third party in order to develop a a proprietary tool that follow the, the, the, the, the owner features and an evolution. So let's go right now through each one of them. First we have the completely the complete autonomy model. Okay. In this model, as I mentioned, the CSP are participating directly in the owner deployment and delivery. And everything being done in, in house. What are the advantage of these, of this model. Well, the CSP has the code control that can do the platform enhance or cost or customization when it is needed. And at the end, it promotes an open source culture within the organization. Remember that we need to, to do a huge change within our organization, including the culture. Talking about the disadvantage, maybe the disadvantage. In some way, the disadvantage are the other phase of the advantage. If you allow me. They include the effort to construct this culture and teams to deal with this challenge. The mindset organization changes and an important impact in the operative, in the operative model. Related to the, to the second model that we described the complete outsourcing CSP are still in control, but delegate in control of, of, I mean, of the, of, of, of the platform, but delegate it to third party. Integrator vendor. I mean, in this case, the CSP are still the accountable, but the third party are the responsible. Related to the advantage, CSP delegated the tax in, in, in a third part, which in some way alleviate the them of some tax and same, same when issues occurs or arise, arise during the delivery. On the other side, the disadvantage are that the CSP have to keep track of track of, of, of the changes requirement and so on. Therefore, they still have a hard work to do. Additionally, the CSP can become dependent in some way of the, of the third party. Okay. Right now, we will go to the third model, which we call semi outsourcing model. It is a well now a model in the industry CSP trusting in a distro. Sometimes per package. Let me give you an example. That can be similar to what is happening today with some open stack distro. And again, that is just to give you an example that can clarify the model. Related to advantage, the, the distro or the distro responsible can deliver a platform already tested and feed for the CSP purpose. The development in house can still be done. The third party responsible for the distro and CSP can take advantage of the professional service of the distro owner, for example. And related to disadvantage, if the delivery doesn't match or cover properly the needs or that the CSP has defined some friction can arise. Another challenging challenge can be the management of several teams participating in the delivery. We again, we again repeat that this is a huge project, very, very challenging project. And additionally, as part of the disadvantage, the monitoring and constant alignment is need is need between the, the responsibility of the distro and the CSP. In order to be sure that the, that the features or the, or the behavior of the distro is what the CSP has defined. Finally, the fourth model is that we call standard basic reference implementation is another well known model in the industry. On app, in this case, on app is a reference implementation and the CSP choose a partner vendor, I mean third party in general, which develop a platform with similar characteristics or features that than on app. You can ask what are the advantages. Well, CSP choose owners as reference and select the vendors of the vendors product that best fit the requirement, depending the vendors selecting is also the success, the, the, the probability of success, because the platform belong entirely to this third party. And the disadvantage is that we have the risk to not be able to, to, to develop within the company, a software culture. Okay, what I mean is to not make the change that the market is asking us. And also the dependency of the vendor is still high. But anyway, this can be an extreme also and not an disadvantage, depending of the CSP strategy. Again, remember that each CSP has to find what is the most suitable model for them. In this case, this can be even every one of the model but except the first one but This, these four model can be even an intermediate step in the journey to in the journey to to software centered culture. So, Lee, with this, I finished the first part and I think I can share with you the, the screen to continue. Yes, thank you, Javier. So let me start sharing. And in this page, I will bring you the CSP survey around consumption model. Thank you for collecting the consumption and deployment situation of CSP. We have designed a comprehensive survey in the early period of writing these white paper within EOAG in anonymous format. The survey contains 15 questions covering on app deployment, community participation, interoperability, survey scenarios, traditional OSS integration with on app and other issues. These questions are common issues that service providers generally pay attention to in the process of deploying on app. It can not only represent the basic requirements from CSP, but also reflect the application and deployment pattern of on app in future. In this part, the white paper will analyze the relevant consumption experience through Nike findings based on the feedback of Lee's survey for reference and give some recommendations from EOAG CSP perspective. The first key finding is about the status and future of on app consumption and deployment. From CSP's responses, we can analyze that about 80% of CSPs said they range from having a deployed version of on app in production to they have plans to begin lab evaluation of on app and no one said they have no plan to adopt on app. This shows that among the LFN EOAG members who respond on app is clearly a part of the network plans with CSPs taking material steps to increase the level of on app adoption in the near term. And in terms of Lee's key finding, EOAG recommend that while nearly half of CSPs surveyed have concrete plans to adopt on app in production, there are still several continuing to evaluate in their lab. So on app community would better explore if there are specific focus areas that could increase adoption in production to further accelerate the adoption of on app EOAG should further explore while what is happening CSP's efforts in deploying on app. Based on key finding one, for who are consuming and have plans for on app deployment, what components of on app are they planning to use? From CSP's response, around 55% plan to introduce mature on app components one by one on a per application scenario basis with specific focus on interoperability between newly introduced components and existing OSS, which account for the majority. And in terms of this key finding, EOAG recommend that further study could be undertaken to determine what is properly uptake of certain on app modules and which use cases prompt deployment of which on app modules, this would provide very useful information for other communities on prioritization and improvements. And with respect to CSP's on app adoption plans, each operators have different consumption models and strategies, each of them with its own advantage and unique features that are most suitable to their specific circumstances. The EOAG has classified these approaches into four basic types. As mentioned in Harvey's slides, there are four of them. One is complete autonomy model and another is complete outsourcing model and also we have semi outsourcing model and standard based reference model. And we can see from the survey that the feedback from the survey shows equals split across the consumption model approximately a third choose complete outsourcing model, while about a quarter are planning on the complete autonomy model and the standard based reference model, respectively. And interesting observation here is that the CSPs are almost equally split among the very different models. This shows that on app can be used in-house, but there is also enough interest in on app to create a support community of vendors that will assist CSPs. This should allay any inhabitants that vendor community may have on on app. So to serve the widest set of CSP's deployment plans, EOAG recommends that the on app community should enable all of these consumption models above. According to different consumption models, which can be classified to different deployment patterns. In terms of survey investigation, we have summarized the following three deployment patterns. They are centralized deployment, distributed deployment pattern and hierarchical deployment pattern, and there are still around 45% of CSP said they were uncertain or unable to respond to this question. In terms of what we have analyzed about, we consider that while the centralized deployment pattern received the most responses, given the variation and lack of clear feedback, the on app community should provide a flexible and decoupled architecture that allows CSP to choose different deployment patterns. In the process of on app consumption, operators usually need to carry out the division of labor and cooperation between internal teams and third party cooperative vendors. From the analysis in the white paper, the CSP's participate in on app deployment, development operation and testing accounts for more than 90% of total survey, and most of them are at least involved in the deployment operation and testing process. According to the analysis result, EOAG recommend that community may undertake consumption model compare with deployment model matrix, along with statistic and pattern for various activity down by participate CSP vendors or system integrators, which could be a community asset for CSP and user for reference while deciding on on app adoption approach. For different consumption models and deployment patterns, operators have several service scenarios that they focus on. With regard to these scenarios, we provide the following list to reflect the current deployment and future concern of these surveys. And in the above list, we can see from the slide, a service maturity index here reflects the maturity extent of the current surveys. The service with the lower maturity index has greater potential to be researched, and the service with higher maturity index has less, has less research space, which is now very mature and does not need to invest more in future for deeper research. And indeed, EOAG did the survey with a limit set of surveys or use cases put in front of CSP and some open-ended question on its aerial, presents CSP's focus seem to suggest a propensity towards newer surveys, which has more scope for automation, which on app has to offer. EOAG believe that on app has to evolve to a platform where it can act as an enabler for future surveys, even for surveys or use cases that are yet to evolve. In addition to service scenarios for existing network element and new network element management methods, most of the operators indicate that they would choose to integrate on app with the existing OSS system, which is also the current trend. For operators who are choosing to integrate with OSS, the current integration patterns include the following, the first one, on app and traditional OSS manage different management objects are constructed separately and operate independently of each other, which accounts for 18%. The second one is on app and traditional OSS manage different management objects are constructed separately while on app is responsible for directly managing new network elements, which account for 36%. The third one, on app and traditional OSS manage different management objects are constructed separately while OSS is responsible for directly manage traditional network elements, which account for 9%. And in addition, we have also 9% operators said they would decide different integration methods based on different situation and use cases, instead of using a single integration solution. EOAG survey has stated the obvious CSPs are unclear about how to protect their existing investments in existing OSS, as in some cases, there is duplicity in functionality provided by on app and OSS. The key aspect that on app community must ensure is how various southbound and northbound integration can work. And additionally, on a best effort basis, a series of artifacts explain a few OSS functions and how can on app play an integrated value adding role would be useful. About the organization models in CSP, nearly half of CSPs have adopted the loosely coupled model, which account for the largest proportion. The independent model and tightly coupled model accounts for 9% respectively and remain 36% were not sure or could otherwise not share a response. For CSP's perspective, it can clearly show that on app community has a very important responsibility to help CSP adopt the most suitable model that works for them. None of which can be singled out as the best or worst. Ultimately, each CSP has to work in their own model with as much support that on app the community can extend. In addition, we'd like to figure out what the network function operations will CSP use on app. The responses to this question are fairly balanced overall, but the result suggests that CSP that are using or plan to use on app in production more interested in the service delivery aspects, then the service assurance capability provided by on app. About this key finding, we think that CSP are currently using or planning to utilize the full range of on app service delivery and service assurance capability for network function with at least initially somewhat more focused on service delivery aspects. So after that, Javier will bring you some conclusion and and recommendation and observations based on the survey. So, yeah. Thank you, Lee. Let me, let me explain or let you know that this these are just a summary of the conclusion and in the with white paper, you have a table with eight, nine or nine options in which we describe a different conclusion in detail. But basically the conclusion, we were talking about, I mean, during the presentation, we were in some way going through the conclusions and Lee mentioned many of them. The on app concession model and the and the ecosystem for adoption, you know, is not an easy topic. Remember what we talked about the nature and scale and the particularity of this project. In the second parties, there is not a single or correct answer to the challenge. Again, each CSP will have their own answer in order to, to, to move to move forward with with such kind of project. There are several choices and and and and dependency each with different try off and with work is with work and it's most suitable for one CSP may be vastly different from the another one which is related with the previous comment or the previous bullet. Additionally, something that we already mentioned that there is a lot of fragmentation in the vision from the from from body of from the various CSP. It is per hat, because most of them are in the earliest stage of deployment. One of the examples what Lee mentioned related to the architecture. Most of them have a select in the in the survey them the centralized architecture, but 50% respond that they are not sure about the centralized or hierarchical architecture. So this fragmentation probably or this number of of of of answer 50% half of them saying and not sure means that there is a we there is a fragmentation in the vision and probably because we are in as we are we are mentioning the conclusion we are in the earliest stage of deployment and we need to gain more experience and expertise in the in the platform. Additionally, Lee mentioned also this this topic is the way the question were designed. We're representing a mix between Karen to show them a medium to long term perspective for different question. So maybe for the reason you have a mix and in the answers. And finally, the end user also grew from the little foundation and working has multiple recommendation or observation from the this survey, which are summarized it in the in the in the way paper. I mean, these are the tables that I was talking about that the very beginning of this slide. So Lee, that's it for from my side. Thank you. And just in our last page. And I would like to express many thanks to our group members. This paper has been authored by the members of our age team and would not have been possible without the countless base discussions and dedication and hard work of many contributors. I would also want to acknowledge members who took time to answer the survey, which ultimately lead to curation of data and the deployment of this white paper. Thank you very much for the contribution and the reviews. And also, I want to mention that you a G is also planned to produce another two white papers around 5G and automated testing. And if you are members of this piece, we will come and join us. So thank you. That's all of our today's sharing of our white paper slice. Great. Thank you both. So let's turn the we've got a few more minutes left so we'll answer some Q&A. So here's the first question that came in with the complete outsourcing model. How much knowledge of own app is required to be able to manage the process and maintain the deployments. I don't know if you want or I can I can mention you are talking about the complete outsourcing model, right? Yeah, that's that's what it looks like. Yeah. In my personal point of view, you need a lot of knowledge because although you are in some way delegating the deployment I mean the development and deployment tasks to a third party, you will be at the end the accountable for this task. It's a good model, I think, because you alleviate your company in order to do a lot of, a lot of stocks. I mean, even related to the people from your organization involved in the project, but at the end you will need a team that or your company will be accountable or you will need a team with the deep knowledge about the platform. So the short answer is you will need a lot of knowledge of the platform, at least the team that will be working on that and being accountable and delegating and working with the third party. Great. Thank you. So another question that we have is do you see these four consumption models, patterns shifting over time as on that becomes even more modular. Or do you want to answer? Yes, maybe I can try to answer these questions. And indeed, at present, our white paper has leased the application deployment challenge of these four models in operators. At least information is provided for your reference. And however, we have a lot elaborated on specific on that consume cases of operators in these white paper. So, because leased white paper, many hopes to analyze the current on that application and deployment status and future trends from such kind of macro perspective. And in fact, we have classified and sort out these four types of models based on current operators application deployment situation. And yes, and at least this is just for reference and regarding to lease for type of models and in order to have deeper understanding of them within operators. We have conduct a survey and reached some key conclusion in white paper and for reference. And all above information can be found in white paper. So she has to compliment I agree with me and she has to compliment. I will say from a personal point of view that that is possible, mainly going from the from the option for to option one, mainly in this direction because you can you can start gaining some expertise in the in the tool up to the time in which you're it depends. I mean, there is no, as we mentioned during the whole presentation, there is no silver bullet or just a golden receipt in order to do that. But what I can see is that some organization can can see the model for or free as a way to gain expertise in the in the platform in order to jump to another more challenging scenarios like the number two or one dependent depending obviously, of all the aspects that we mentioned I mean the business strategy the organization scale the general context the culture, etc. Great thank you. We did have a question about sharing the slides. So the yes the slides will be available, along with the recording after afterwards tomorrow. Another question do we also need a consumption adoption model white paper like this one to be prepared for X and F vendors. Three. Do we also need a consumption adoption model white paper similar to this one to be prepared for X and F vendors. Okay. Indeed, we have already published this kind of it's kind of white paper as the first step to in on that consumption adoption field, and also in the process of writing this paper. We have also planned to publish kind of specific white paper, such as best of practice white paper in CSP based on the application practice of operators, and it may more focus on interoperability. So, I think if you are interested in some specific practical applications, you can try to continue to pay attention to eog dynamics. Alright, I think we have time for one last question. So can you explain which consumption models your companies telecom Argentina and China mobile have chosen, and if that approach or the model is going to evolve over time. And do you have answers have you. So, I think I think, I think if you want to know more details maybe you can try to chat with us offline. Yeah, I think it's maybe a better way. Yeah, fair enough. Yeah. Safe safe for me we can we can talk offline about that. Okay, great well with three minutes left I think we can conclude today's session so thank you to our presenters thank you to all of our attendees and as we mentioned a recording of this and the slides will both be available. And we'll see you guys very likely tomorrow. So thanks again and we hope to see you on another elephant webinar coming up soon. Have a great day. Thank you all. Thank you.