 So the next panel on Keynotes is one of my favorites, because the problem that the panel will address in solving is one of global connectivity for VPNs. And while we can always say your location-based and your sort of a business is one particular city, most of us and most of the businesses operate globally. And so what we have is we have very, very, you know, senior executives from some of the leading companies here today. We're going to talk about, you know, what they're calling cross-cloud, cross-layer automation and orchestration. It's a panel, but before we get into the Q&A on the panel, each panelist would like to share a few ideas and thoughts and a few slides. Let me introduce the panel, and then I'll bring the first one in. So Dr. Fang is from China Mobile. She's the Chief Scientist and General Manager of the AI and Intelligent Operations at their CMCC R&D Center. Bill Ren is from Huawei. He's VP of Network Industry and Ecosystems. And then Fran Hiran, he's the Head of Cloud and Automation Group at the Vodafone Group. And so what we'll do is I'll bring in Fran first, and then he will bring in the speakers, and then we'll have a Q&A session. So, Frank, come on out. Good morning, and thank you for joining us. So I'm Fran Hiran. As Arpit said, I head up the Cloud and Automation Center of Excellence for Vodafone Group. We're going to talk about OWNAP and a contribution that a collaboration that we've done over the last six months in contributing to OWNAP. In the use case, that's very near and dear to our hearts in Vodafone. I'll talk about that as well. So we joined OWNAP and LLFN a little over a year ago, and in looking to where we could contribute into this open source program. It's not an area where typically Vodafone has been active before, but it's one that we're changing. We looked at a particular problem, not specific to us, but certainly very relevant for Vodafone. And it's one based on geography. And they say a picture speaks a thousand words, and I only have five minutes. So I'm going to use pictures rather than words. So this is Vodafone's footprint for those that aren't aware. So everything from, I guess, Ireland in the West, all the way over to New Zealand in the East, and lots of different territories in between. And I've colored it all red, but the truth is actually they're all different operating companies. Different histories, different heritage, different market drivers, local market conditions. But within the Vodafone group, this is the scale and the span that we have. And in looking to introduce cloud automation across the group, looking for levels of consistency across all of our territories is going to be a key part of our strategy going forward. What many of you may not know, though, is we also have a very extensive partner market ecosystem, which looks like this. And these are operators in markets where we don't have a physical presence or offer a service. But we do work very closely with these partners on strategy, on technology, and it expands, I guess, our visibility and our reach even further across the world. And then finally, there's a third layer to this, which is a very extensive enterprise business that Vodafone has, where we sell enterprise connectivity services and value-added services like unified communications and collaboration tools in an even more extensive set of geographies, pretty much giving us a global footprint. And in particular, on the enterprise services, as we look at automation, and this was really the driver behind the collaboration that we've done with China Mobile and with Huawei, and we're contributing into the next release of Onap and Casablanca, it was really about not just focusing on inside a single domain as we look to automate and build our clouds. It's about cross-domain. So it's equally important that we have the end-to-end automation between regions, between markets, between carriers, especially for the consumer-facing services, enterprise in particular. So if you're going to have a truly automated digital customer experience, very important we have no breaks in that process between our markets, between our partner markets, and where we're selling enterprise services as well. So there was really three key drivers for us in Vodafone, and I'll go actually right to left on this. The first is automation, and I've mentioned that. So I think at the same time as we're focusing on how do we automate within a single market, single territory, both on the network, but also on the consumer-facing services, equally important we stay focused on how we automate across territories. So north-south, if you will, within a single domain, east-west going across domains, and that's about really reducing the time to market, changing the customer experience, putting the customer more in control, giving them more choice. So key we have that end-to-end automation experience. Second area, and I mentioned traditionally, I suppose many of us in the industry are very standards-driven, but open source is playing a much more important role now as we transform our networks and build our clouds. So the agility we get from that and being able to move faster, define the standards quickly and iterate is becoming increasingly important, not just for us in Vodafone, but I think for the industry in general. And it's very much a mix of traditional standards, but also very much augmented now by open source, including projects like Onap. And if you look at the pace of change that's happened, even in the last 12 months since we first joined, it's been very dramatic in terms of driving those standards. And finally, this is really important for us, because this isn't the first exercise at driving cross-domain interoperability via API. Actually, we've used a lot of that prior work as well. But the out-of-the-box experience is key. And for us, I think if we leave too much as an exercise to the user to add an augment, the scope for variation and breakage increases dramatically as you look across all of those territories I showed. So having cross-domain interoperability for services out-of-the-box on a platform like Onap was a critical driver for us as well. So we'll talk during the panel more about the contributions that we're making, but certainly it signals, and this isn't the end of the collaboration, it's the beginning of our inputs into the open source community on Onap in particular, very much with the focus on what we can bring as a global operator with multi-domain requirements into a program like Onap. So that's our motivation. I'd like to invite on stage now Bill Ren from Huawei, one of our partners in the collaboration, to maybe take us through what was your motivations on this as well. Thanks, Bill. Okay, thanks for our friends introduction. Morning, everyone. My name is Ren Shidong and from Huawei. I'm in charge of the open source business in network infrastructure. In the next few minutes, I'd like to share with you our thoughts about network automation. So you can see my topic is turns the network service provided into a service manufacturer. So first, let's look at the history of this manufacturer. Actually, the history of efficiency. So 2000 years ago, the handicraft stage, the emblematic thing is a terracotta worries. So in this stage, the efficiency is quite low. You have to meet one by one. But if you have been to Xi'an, so you will find out that each terracotta worries is uniquely customized. So in 1768, the Chinese machine stands for the second stage, the massive manufacturer stage began. In 1908, the four type T is produced in streamlined product line. So all this increased the efficiency more than 10 times with single products. In 1955, the McDonald makes the food service kind of a manufacturer industry with a few types of menu. So in the second stage, the efficiency is higher, but the products are few. So start from AWS in 2006, the cloud business built the new stage. Both the efficiency and the products are much more higher. So we call it service manufacturer stage. So according to the Bournemouth law of cost disease, since the cost of those industries, which is labor intensive, will continue to rise due to the increased efficiency of the manufacturer industry. So those will lose their competitiveness. So we have seen many industries also already into the service manufacturer. For example, this cloud has transferred the traditional IT into a new IT service in manufacture. The e-commercial transfers the traditional retail to the new retail service manufacturer. Even the logistical warehousing is transformed to automated product line run by robots. And also the car, as we all know, has entered into the intelligent manufacturing stage. The different car demands by different user could be made in the same product line. So naturally, we would like to ask, why not the network service industry transfer to the service manufacturer? Of course, we are not imitating. So why, why we should transfer this network service industry? So on one hand, from a customer point of view, we have seen the network scale will continue to expand. It is expected to reach 75 billion connections in 2025. So the network complexity beyond the human capabilities. And also the quality of the network service is mainly driven by customer complaints. Also, on the other hand, the all packs increase faster than the revenue. So it needs only three people for OTT to maintain 10,000 devices. But for operators, it needs 300. So there's more than 100 different times of difference in efficiency. So that's why we say it needs the system architecture innovation to solve these structural problems. So that's why it's necessary to transform the network service industry from labor intensive to a service manufacturer industry. So how to transform? So refer to the architecture of this intelligent manufacturing of vehicle. So we can say, first, it needs a flexible or programmable material handling in the bottom. About that, file software system is needed. So you can see the parts control system, assembly management, and quality management system. And the top is design supporting system as well as modeling. Similarly, so for SDNFA has, in the past 10 years, turned the network into a programmable infrastructure with a VF marketplace input. So again, there are five more system is required to about that. Controllers, service orchestrations, policy-based closed loop, and the designer as well as this modeling. So look at the own app, the architecture, fits to this service manufacturer architecture very well. So we believe OTT is the most promising community in network industry. That's why we join hand with Waterfront and Channel Mobile to build this use case in the community. The CCVP proof of concept shows that the service manufacturer is feasible in our industry. So the core value of the own app is a common engineering language helps our three parties to assemble this VPN service in a streamlined. So that's all for my part. So with that, more detail of this CCVP use case, you could visit us in our booth. And regarding that, thank you for your attention. I'd like to invite Dr. Feng from Channel Mobile to talk about their thinking. Okay. Thank you, Ben. So good morning. I'm new in this community, so I carry my badge everywhere. I'm Jun Long from Channel Mobile. I'm from the AI background. And this is the first time in my life I come to a stage with two gentlemen sitting behind, giving me a level of protection, so I feel quite safe right here. Thanks to our partner, Huawei, and Vodafone. Thanks to FN. So today I'm going to share with you just a couple of minutes and what our recent changes inside Channel Mobile and what we do with own app and where we're heading. So inside Channel Mobile, from last year and this year, we dramatically increased our investment network of transformation. Internally, we've referred to the whole effort as NobleNet. It has three layers, infrastructure layer, application layer, and the management layer. We can do everything on our own. So I highlighted the boxes, the components, those are the ones we concentrate on. On the bottom layer, the white box, switches, and the cloud-based OS, the VIM. On the top, on the management layer for the super controller, cross domain controller, wing FM, and the EMS. And we do take Orchestrator and our own next version of OSS as the core, as the brain of the network for automation, for intelligence. This is how we try, well, this moment, from this month and last month, we have been put into lots of efforts to push some functions of own app into trial. Now, too, this one on the picture is the one we take the Amsterdam VOTI, VOLTE use case, and we run a trial in Zhejiang province. Zhejiang is one of the richest provinces in China. The other ones, we take the NFVO from the VFC into trial. We run the trial in Shanxi. So hopefully after those trials, we learn the lessons we can put into real use. There we struggle, same as the community, when we deploy own app on our business. There are lots of challenges, though, so I just list three, because three is the easy number for you to remember. So the massive code base, the complexity, and the stability, and the difficulty to put into any new use case. And we look forward to working with you all, and just to improve that, make it more modularized, flexible, and make it more kind of use case-driven. That's all now. Another strategic change inside China Mobile is we really think making the network intelligent is important. So as a reflection of that, earlier this year, we formed a new R&D center. It's called artificial intelligence and intelligent operation R&D center. That's why I'm here. And we consolidated the staff on two sides. We have, from last year in this year, we have deployed a few applications, some of a larger scale, some of a not yet. And we mean, looking in the future, we hope this can be a more systematic way of really making the network intelligent. The third point I want to make is a collaboration, because CCB-PN is really, I personally, I think our team really enjoyed working with Telephone and Huawei. So in the past, the SDO and the CERT working as a model document-driven, each recent takes years, took a year, years to go to the next one. And now it's open source. It can happen in months. And I think it's, in order to have a more stable component, the team needs to come closer. So it's more community-driven. That's the way we work. We came up with this idea. We talked last time in Los Angeles, right? And then was back in March. And the former team worked together. Really happy to see where we are now. So this is, because of my title, I named that CCB-PN Beyond. So although it's in the, if you go to the own Apple website, it's called Cross Domain Cross Layer. Actually, another one is Cross Operator. So back to March of this year, I remember there's a company called Keep Safe in Los Angeles. They have a market slogan that VPN is too hard for a fluffy lady brain. So now we have many ladies working behind to come up a new way of doing VPN. So I really encourage you to find more details on our booth. It's truly model-based. It's just a key of our own app. And it has a couple of processes. You can come to the booth and learn details. I think it will probably cover in the QA for some of the details. Okay. With that. And back to you. Thank you very much. All right. So this is really, you know, very fascinating. And, you know, especially, it's not just the multi-site. It's multi-operator, multi-country. It's a great showcase of how, you know, not just providers, but providers and vendors can come together and collaborate in open source. I particularly like one thing, Dr. Fang, which was you put own app in production in the richest province. So I picked that one up, right? So we'll probably sort of have others do that anyway. So I would like to go ahead and sort of, you know, ask a few questions if that's okay. The first one is, you know, clearly this is done as kind of a demo and it's live in the booth. How is each one of you and your teams, how are they going to contribute back to, you know, the open source team? And more importantly, you know, how many people roughly, how big, you know, if you can give us an idea on that so that, you know, the rest of the community can benefit. Okay. Lady first? Yeah. Absolutely. Okay. So I will answer part of it. Otherwise, they don't have anything to say. So we'll work, well, there, the source code definitely will go back SSO and AI. I think what we can contribute back is also the modules, the workflow, the configuration, and the onboarding process. So I think with that in place, whoever wants to do something similar, not just the code base, also this module can be reused. Okay. Yeah, I think for us, and I mean, our team in Vodafone is still relatively small working on this. As I said, in my opening remarks, it's traditionally an area we haven't been massively active in before, but that will change. So this is very much the beginning process for us. I think the big contribution is the APIs. And you can see it here on the diagram. So that east-west cross-operator, cross-domain set of APIs is a really important part of the contribution. Having those out of the box, very important to us. The data models, and the APIs are designed really to be used not just for a particular service, it should be multi-service. And then, to Dr. Fang's point, the data models and the artifacts within that used to represent a VPN service in this case is being contributed back into Onap, and also updates to the user interface for the ordering process as well. So it's a pretty extensive range, I guess, of contributions. And one we'll keep iterating through and growing our development team in Vodafone on this as well. So it's really nothing for me. Okay. I agree. Yeah, the source code API is most important. Also, as we all know, Onap is a framework. But for this framework, the user case driven is the most important. So the beauty of this CCVPN user case is the first time the industry joined hands to make the OT, SD1, this underlay-overlay service, work together to drive this service modeling, the interface, all be contributed back to the community. So any people who is willing to do this practice can take advantage of those contributions to do their POC. So that's one thing I have to mention. And also, regarding the modularity of contribution, as you all know, Huawei is the second largest contributor for this community. And also, almost each module relates to this CCVPN from SDC to ISO to DCE policy, VFC, and all those modules have been covered. So each module supports this use case. Very good. Very good. No, this is great, because I think one of the slides Dr. Fang had was a collaboration between SDOs and Open Source. And a lot of these are kind of evolving towards MAP APIs as well, that the collaboration has already been set up. So we're really excited. So that's great. Very good. How do you envision the Onap slash Open Source enabling you to digitally transform the company? So now we're talking about a next layer up transformation problem, in terms of not just now, but future plans. Friend, you want to go first, maybe? Sure. As I said earlier, it's becoming increasingly important for us, especially as we do cloud and automation. It's not an area traditionally covered by traditional standards, I guess. It's not just with Onap, but across all the layers of our cloud stack, Open Source is playing an increasingly important role. I think for us, there's a few challenges I think in the industry as well. One is the sheer range of Open Source projects can be a problem. So on one hand, you have this very broad scope, great range of programs, but it can be hard to pick which one to use. So I think there's some work we need to do there. And the other key thing that we're focused on is making, it's focused on stability and robustness. So there's always something we say in balancing the feature function richness with making sure at every point in time, it's fit for service, ready for global deployment. So it's an increasingly important part of our transformation program. It's something we'll balance with traditional standards, but very, very focused on readiness and stability and having that correct balance between both. Me? Okay. So I talk a part of our efforts, how we push on up into real use. I'm thinking is one side we do increase our R&D investment on this line of research and depth. I also want to point out this, there are two things. One is we really need to focus on a way we can build our own trajectory. We cannot take the whole thing and transform whatever exists now. You have to incrementally find the path. The path has to win the trust from the business. So that level of trust I'm thinking is very important. Another point I want to make is although it's open source, but it's not like open source in regular sense. Regular, so you have it on up, it's kind of a small piece of software. You can develop or you can someone download and use. I'm thinking on up is it's a software, but it's going to transform in the industry. So I just hope with the audiences, we hold our patience because any business transformation cannot be as easy as in storing a software. And especially the people part. The people, the organization, the way to work together, but I'm thinking we're doing something great for the future. Very good. Bill, your thoughts? So talk about open source. I think as I mentioned, it's for me, on up is as a common engineer language, I hope to say again, it's really approved the efficiency of our collaboration. You know, the surprise to me is, I think two weeks ago, I met our team, one of our customers team, the engineers, system engineer work together, even they never meet before, but they can talk in, in modularity level, in interface level, just because of on up. So that's make me feel a surprise. So because, you know, explain, explain the terminology for each company is really hard. So everyone has a big program. So how to let the industry understand your program is very tough and very low efficiency. Second, I think the open source gave us a new way of collaboration. As I mentioned, our three party, the C3P, in use case itself to prove that it's possible for the future, for the large scale collaboration, even without knowing each other. So the VPN marketplace is really expected in the industry. So we should make that happen. Very good. Very good. Now this is great. Let me ask one more here. And I think all of us know, you know, there's, I have this theory, right, that if there are a hundred things about a product or service, and 99 of them are like really good, and then there's that one bad thing or maybe a challenge, the engineer will zoom in and focus on that. But if you're a market here, and if there are 99 bad things, and that one good thing, the market here will focus on that one good thing, right? So let's put an engineer hat on and kind of ask, you know, the panel here, what are the challenges in deployment, right? Maybe start with Bill. You go first. Of course, we are part of the industry. I'd like to share is for me, look at the journey in the past, especially for C3P in the several months, I think the, I would prefer more lesson learned from what we got. The most important is the senior executive sponsorship for this ONAP deployment is most important for me, because for me, ONAP is more than just a software, it's a system, or it's just, I don't think it's just another OSS. So it's related to people to process to business transformation. So it's how to be strategy driven and top down driven. Otherwise, you don't have sustainable progress. You may make some progress, but it's never go far. So second thing, I think the real scenario, real problem solving is most important. So that's why we have this C3P in place. And except that, I think within each organization, the multiple department or cross department collaboration is most important, because how to put in all the real user within each organization, such as for carriers, I think the network department or operation department embodying it in the very first beginning, it's very important. Otherwise, the innovation always stay on the lab, it's never go anywhere. Oh, those are great lessons. How about you, Dr. Feng? I think I cover part of that. I'm thinking is, first, there are several levels. One level itself needs to be more stable. It needs to increase the easiness of use, because for now, everyone takes their own app to take substantial efforts to really make it work. Hopefully, that can become easier. And second level is we, each company has their own spec requirements, needs to take that as a core and work effectively to meet the internal requirements. That kind of efficiency also, it's very important. Another level I'm thinking is the collaboration, internal or external, internal collaboration. So we have to teach other parts of the company where the R&D and the network operation and construction have to, they feel comfortable. So we do quite a lot of kind of tutorials, presentations, so they learn details of what they truly learn what own app is, build that level of trust. I think external is we needed to improve the efficiency of our collaboration in the community. I'm thinking as if we have our own use case, other operators have their own use case. I'm thinking if we can work on something probably even for a short period of time, if we can share a common goal with truly laser folks that really make it happen, I'm thinking that kind of a collaboration is also important. Which is what you're showing here. I'm going to show you an example. Excellent. And Fran, you know lessons learned. Yeah, what to add to that. So I agree completely with all the points. I think maybe an important clarification from Vodafone's perspective when we talk about open source, because carriers are all different in their approach. This isn't about us taking the code out of the code base and deploying it ourselves and building it ourselves. We still very much rely on our vendor partners in this space. Open source is a great way to rapidly get to standards and interoperability. But I think the challenges we're seeing is the speed of vendor adoption. The speed at which vendors are, in the case of own app, for example, taking own app and applying the APIs and data models to their portfolios and then bringing that back into us. So there's a hardened robust platform to help address the overall complexity and quality issues. So it's an opportunity, I guess, and an open call to the vendor community, one of whom we have on stage, obviously, but there's others in the audience. I think we need to increase the pace at embracing openness. As we do cloud across operators, openness is the foundational element of everything we're doing and open source can help drive that, obviously. And I think, to Dr. Fang's point, we need more carrier inputs as well. So this collaboration has been great over the last six months. Each of us took our own particular experiences and requirements and applied it into the collaboration. Now we need more inputs from other carriers because their requirements will be different as well. So I think those two would be the key for us in terms of how quickly and how fast we can adopt and deploy this within the network. Very good. I think we are almost out of time. I would like to point out that there are sessions here that you should attend. Plus, obviously, visit the booth out there. And then there are experts from the vendor, from the community that can answer any technical questions. I know tons of developers here. So please stop by here. And with that, I would like to thank the panel. Please give a big round of applause. Thank you.