 Good morning. Good morning. Who is actually from the Netherlands? At least some. So my Dutch is a little bit limited, but at least I can speak some words and I can understand. Now, talking about acceleration in the Netherlands actually sounds like an oxymoron to me. Because when I come from Germany, driving here by car and cross the border, I have to slow down drastically, actually. And also, the Netherlands, for me, is a country where I decelerate, where I go sailing, where I go for bicycle ride, or just the beach. So accelerating the pace of the industry, originally I was looking for a picture showing the acceleration, the need for acceleration actually from the Dutch Grand Prix. The last Dutch Grand Prix in Sanford happened back in 1985. So quite some time ago, and I didn't find a picture, but I found a picture from another Grand Prix, also happening in the dunes in Bahrain, showing the need for acceleration. Because here you saw, right after the start of the race, and the one who won the race, that was Rosberg, he was actually ahead of the crowd, and you see Bottas in that Williams car crashing into Hamilton here. And as a result, Hamilton only finished the race at third position, and Rosberg became the world champion in that year. So now, what does that mean for our industry? What does that mean for the telco industry? It's so simple, and I managed to press the wrong button. So what does it actually mean for the telco industry? Why do we need to accelerate? And we have that well-known picture out of the Cisco VNI expectation on the traffic. Traffic is growing exponentially, and we actually don't see an end to the exponential growth. In some areas, I believe that the Cisco numbers are actually very conservative. We're actually seeing compound annual growth rates, which are slightly higher in some of our regions, especially on the mobile network, but also touching us in fixed. So it's a safe assumption traffic will continue to grow over the next years. Now, in the past, Moore's law had actually helped us to keep our production cost under control, because with the densification of hardware, smaller structures on silicon, and higher performance at the same time, slightly lowering the price, we were actually able to keep our production cost under control. Now, Moore's law is flattening out, and that is definitely not helpful in that situation here, because I can't expect that I get higher performance equipment for maybe slightly lower price over the years. At the same time, obviously the Apu for traditional services, it's not expected to grow, unfortunately. It's more expected to be flat if we're lucky, or in reality, it might even shrink in a couple of our markets. Now, at that time, we're actually introducing a new technology generation. We're introducing 5G, we're rolling out 5G, and this is a paradigm shift which is touching us in many, many areas. We're seeing, obviously, a trend to move the service production into the cloud, some complete network production into the cloud. We will see network slicing, the full beauty of 5G coming slowly to the market. We're going to see initial steps towards rollout in the 2019-2020 timeframe, initially bringing out 5G new radio, and then over the course of the 2020s, you're going to see the introduction of the advanced concepts, kind of bringing 5G to its full beauty. So, all of that, if we cannot change the model we're using to build networks, we'll drive up our cost. Now, that's a situation we don't like to have, so we have to do something against it. We have to keep our cost under control. And I don't say here that the innovation we are receiving through our vendors is not good anymore. I worked on the vendor side for many years in my personal career, and the innovation driven by the vendors is one important element for this industry. But the vendors are facing the same challenges, and we're also facing challenges on the talent side, for example. Operators are facing the challenge to attract top talent, and the established vendors are facing the same issue. Now, in general, we see that there's a strong trend towards disaggregation and kind of taking away the concept of a black box, which is delivered as a combination of hardware and software, and replacing that by a best-of-breed approach, breaking up the system, and white box switches are one example where this is actually done, separating hardware and software and having open interfaces in between. Now, that's all easy said, but I mentioned this small challenge on the talent side. We're changing the model here completely. The way we are working is changing completely, and it's a huge skill set transformation which is required to actually master the challenge as well. So the move to DevOps, that is actually quite tough. So together with that open ecosystem, we see a development towards an open telco and that cultural shift that won't happen overnight. So when we started that journey towards cloudification of our network functions that was back in 2012, I was presenting at ONS in Santa Clara back in 2012, our vision on how services would be produced in the future, and that was the starting point later that year. Etsy and FV was announced sending a first signal to the industry, but what happened then was actually people fell back into their old behavior, into their old way of working, because you saw a lot of standardization people joining in there. You didn't really see the people with cloud experience joining. So as a result, I think it took a little bit longer than expected. Also, for our vendors, it took a little bit longer than expected to actually make that move and also re-architect and rewrite the applications they are selling to us in such a disaggregated production world. Now, we're seeing a lot of organizations. Actually, I started here back in 2000 when the Linux Foundation was actually founded. I put some organizations up here just to explain the selection of organizations where myself or my team or the teams of my peers have been engaged in. So if your favorite organization doesn't show up on that slide, I apologize, but it's not intentional. Just I sorted them on the timeline. So on the left, you see MEPH was created in 2001, and I put MEPH up here not as it's an open source organization, but the example was brought up a couple of times that there is a great collaboration established between what we're doing here in LFN, what we're doing in ONAP, and what's done in MEPH. So for me, that's a great example for collaboration in this industry, for collaboration between organizations. And likewise, you can put ONF up here with the work they are driving, how it relates to what we are driving in LFN, and also in other organizations. The Open Compute project was created back in 2011, and that was actually bringing in a new dimension, opening up the hardware layer as well, moving or extending the open source concept to the hardware layer as well, taking responsibility and taking a community R&D effort also on the hardware layer. Back in 2011, it was mostly a Facebook-driven activity with few others joining, but this really took off. When we look at it in 2015, 2016, when also lots of Tercos had joined the Open Compute project, the Tercos working group in OCP was formed back in early 2016, and for me that's a great success as well, the work which is driven there in OCP. Well, I cannot have a presentation without talking about the organization I'm sharing, so back at Mobile World Congress 2016, we had announced together with Facebook, Intel, Nokia, and SK Telecom the creation of the Telecom Infra project, which is actually taking that thought of community-based R&D on the hardware side, which was developed in OCP and extending it to the overall Terco infrastructure. And that's actually a real challenge because the overall Terco infrastructure, as soon as you're touching hardware, as soon as you're touching mobile, that's a world where you really have to watch out for existing IPR. And you have to adjust, you cannot just go with a traditional open-source approach in this world, you have to offer different IPR control mechanisms to the project groups driving work in TIP. Now, at the same time, the X-RUN group was announced opening up the Radio Access Network, and just recently in this year, X-RUN and C-RUN have merged to show up as O-RUN. Also in this year, LFN started operation with the work on ONAP before. Now, all of these organizations are extremely important for the acceleration of the innovation pace in this industry. The challenge I have in my day-roll at DT is how can we staff all of that? How can we make sure that things are going in the right direction? How can we avoid overlap between the organizations? Because kind of in my night job, Chairman of TIP, there is a certain tendency if you bring up a new organization that you want to grab some land and that you want to show, hey, it's my organization doing this great thing for the industry. But taking the other hat on again, looking from the industry perspective, looking at this scarce resource situation we have, we have to watch out and we have to reduce the overlap and we have to avoid the duplication of efforts under all circumstances. And that's what I'm pushing for in my role within TIP and likewise in the governance board within LFN. And I think especially here we're on a good track and hopefully you're going to see some announcements between some of the organizations listed on that chart actually moving forward. Unfortunately, I wanted to make some announcement today, but I can't because there was no agreement to go out with an announcement. Now, let's look a little bit at real life. Let's look a little bit at the technology we are deploying, the cloudification of network functions. Let's look at the way Tercos are actually deploying this. When we started the whole discussion on NFV, we actually envisioned the picture on the far right of the chart. The picture on the far right says basically the operators are taking full system integration responsibility. You're building this either on open source hardware, so OCP hardware or maybe also on commodity hardware, then you're putting an open source management layer like OpenStack on top, Onap on top, and then you put in the applications which still come from a vendor. But the service provider in this picture would take the full system integration responsibility both horizontally as well as vertically. When you look around in the operator world, there are actually only very few Tercos who have implemented in this way. AT&T is probably the front runner in this space and so are a couple of others, China Mobile and a few others as well in this space. But we are struggling as an industry actually to attract open source developers because if you follow that model, you better have a team of open source developers who are providing the traditional level 2 and level 3 support. And well, if you don't have the open source developers yourself, you better go with the support model. And we saw that in OpenStack. We saw that with Red Hat, with Canonical, Mirantis, delivering OpenStack distributions and selling support on these distributions. So that's how OpenStack as open source made it into a lot of the operators and we received support just like from a regular vendor on the regular product. Now, especially the smaller operators, the tier 2s, the tier 3s, they are more on the far left end of that spectrum. So they are approaching one vendor and the vendor delivers a full solution. That's what I would call a virtualized silo. Now, looking at that picture is actually very interesting if we're looking at the work of LFN, if we're looking at ONAP, that picture tells a lot what needs to be done in this industry to actually deliver ONAP in production to the operators. Because most of the deployments you see, more than 80% of the deployments you see, will require some commercial support for ONAP. Now, ONAP, I think it's a great initiative for the industry. It's great to have so many operators behind. It's great to have so many vendors behind as well. But it's also fairly big. So we don't see any vendor supporting the full beauty of ONAP at this point in time. I think the way forward is really go for a classical agile approach, identify a minimal viable product, which makes sense for a lot of the operators and position this as a commercial product in the market. I think that's a way forward for vendors in this space here to support the deployment models we're actually seeing. By the way, I didn't say that any of the deployment models are good or bad. I still love the one on the right, but all of them are valid deployment models. Now, it's actually interesting talking to a lot of people recently about the future of all of this. You saw some alarming articles some time ago, I believe that started back in 2016, 2017. The industry is behind compared to the original plans and some were doubting that the way to use open source is the right one anyhow. Well, I think that would be the wrong approach to just fall back onto the black box approach. But still we need to do something. So talking to people, there's one big trend coming up and that's the trend to talk about cloud native. And just before I show the next slide, I know it's sometimes a problem to show a religious picture in a multicultural event. The fact that we are running in Europe and that there are also beautiful museums here in Amsterdam and other European cities might give me an apology. I probably would not use that picture of paradise in an event we would run in the US. Anyhow, here's a picture from Lukas Kranach, which is actually in the Vienna Museum of Art, showing a picture of paradise. And many people are positioning cloud native as paradise today. Now, when you look at that picture in detail, so in front that's where God gives kind of the ownership of paradise to Adam and Eve. When you look at the second layer in the picture, it actually shows what can happen. Paradise can kind of develop into hell and you might get thrown out of paradise. Now, is that what's happening in cloud native? Not sure, because when we started that vision back in 2012, we actually had that vision of cloud native. There was actually a debate behind the scenes, at least within Deutsche Telekom at that time. Should we really call it NFV? Because I wanted to have a C in there for cloud, so I was really happy to see when the cloud native foundation created that term on the cloud native functions, CNF, instead of VNF. I think that's absolutely right description. I wanted to have it back in 2012. Unfortunately, the term NFC was already used at that time, so we couldn't use network function cloudification. Now, I really learned that the industry transformation takes time. I started at DT almost exactly seven years ago, and I learned why it's taking so much time. It's not just within DT, it's the same across the industry, and I mentioned it already. The talent topic is one, skill set transformation indeed takes time. The process transformation takes time, and I fully understand our vendors as well, that they didn't really jump on that initiative right away and started re-architecting their core services. Because obviously, when the service providers put more pressure on the margin side, it takes some time until you start to enter end-of-life for existing product, and then you indeed start with redevelopment and re-architecting it to be truly cloud-native. But the cloud-native world is not that easy, and I would say anyone who doesn't gain the experience in today's heavy virtualization, virtual machine-based world, will fail in the cloud-native world. The lifecycle management, the network IO optimization, these are topics you have to master in today's world as well. The orchestration is something you have to master in today's world as well. You cannot just say, we're waiting for cloud-native to solve all our problems. Then exactly what Karnath described in that picture, he painted sometime in the 15th century, will take place. So we do have the challenges on orchestration and automation. We do have a great initiative with ONAP, taking the right steps also towards the microservice world and the containerization, and that definitely will require some focus. Also the question how we bring in AI to actually orchestrate in a microservice world with distribution up to the edge. So that will be a very interesting question also moving forward here. Also the other Linux Foundation initiatives, whether it's Acumus or Acryno, will play an important role. One of the initiatives as part of LFN FIDO, I think is extremely important also for the future, for networking in containers, because most people who are talking about containers are actually not aware about the challenges this brings on the networking side. So that definitely requires focus and looking at my friends here in the first row, much like as a session, I believe this afternoon on this topic. Now, one important topic we have to cover as well and that's security. I was a little bit surprised, Michael, that in your survey, security popped up on the low end. I think looking at a microservice-based world, looking at a containerized production, we have to be aware that the security paradigm is actually changing. Because today's security paradigm is still based on good old access control lists. You know the Layer 3 and Layer 4 addresses and that's basically what you're using to set up your security. Now that doesn't apply anymore if you're spinning up and spinning down microservices on the fly. So you have to change the paradigm here and that definitely requires a lot of focus and likewise, the operationalization of the whole thing will require real focus from us to actually be successful with a microservice-based production in the future. With that, I'd like to close and thank you and hope you have a great rest of the day.