 I am Ulises Olvera Hernandez. I work for Interdigital Communication Europe. And today, we're going to come and show a mechanism that makes IP services both cost-effective and low-latency. This is exactly what we're going to demonstrate. We need to focus on those two nuggets that I gave, low-latency and cost-effective. This is what we're going to do. Right now, I'm going to trigger the deployment of the network. We'll go more into the details of what this network is with the PowerPoint presentation, which should be short. So please bear with me and let's do the deployment. And then we'll go right back into the presentation. Right now, 5G is all about meeting the requirements for KPIs. And if we take a look at the delivery of services that we have today, in some cases, these are pure end-to-end, meaning if you need to deliver a video to a single subscriber, and then you have millions of subscribers that will have to be multiplied accordingly. Of course, real delivery networks don't work necessarily one-to-one. We have content distribution networks, content delivery networks that attempt to mitigate this one-to-one delivery. But even in those cases, we have to configure those networks. We have to, if there are, for example, redirections of where this content is, and even if we have mobilized content delivery networks, they need to be configured for this to work. What we bring here is a possibility to rather than go to the content delivery network that is close to me according to the typology that could be handled based on these constraints, we're not going to the best possible access, which is the next hope. So that's the use of what we're trying to do here. So if we want to deliver content to some of these users, then it would be ideal that we can go directly into the immediate next hope rather than look for content in areas that could be far away from where the user is trying to access that content. So this is the leverage pitch that we have for you. So we're trying to come up with a system that looks like IP, smells like IP, but it works most better than IP. And if you put this into networks, then these networks will work much better than they do today. This is the problem that we're trying to tackle today. So we talk about these content delivery networks that we have today. They are difficult to configure. You can imagine trying to configure different DNS entries. And of course, when we're going to see the mobility, then that becomes even worse. So you end up with an overprovision network, and the cost for these networks is quite high. The solution. In our solution, we introduce an innovative multicast mechanism that takes advantage of ICN. However, what we're trying to bring here is of course not something that will require the operators or whoever deploys this to rip the network upon something new. So there is an important aspect. It has to be something that could be introduced using the technology that we're bringing, but it has to be backwards compatible. You cannot take devices to all of a sudden change just because you introduce new technology. By doing this, we reduce latency. And also, we improve the performance of the network using native multicast with the specific technology that we have. And the technology is based on a very simple idea where you exhort the link identities of those packets that are traversing. There's two aspects. One is the multicast game, and the other one is localizing the content. Now, for this demo, we're only going to show the first aspect, which is the multicast game. The localization of the demo that would be a topic for a different presentation. We're trying to play a video that is fed remotely. The video is fed remotely from Bristol in the UK. And in our lab in the UK, we also have 30 clients that are trying to download the same video that we're going to watch here. The idea here is that you have 30 clients plus us, 31 clients. And if you use current technology, you will have to send this video 31 times. With the technology that we have, we will send a single multicast that would be delivered to the access points where these clients have. So the network access point in Bristol will receive one single video. And we here will receive a different video. So you can see the video traversing. They're going to the remote place in Bristol and coming all the way here to Geneva. That's the first aspect that we're going to demonstrate today. And this is the topology of the network. The UIs that you see here, the use that we depict here are demonstrated with these UIs that we have here. We only have one. And we have the 30 emulated users that I talk about in Bristol. And in Bristol, we also have this HTTP living streaming video that is going to be played to all these 31 users. What you will see is the first aspect that we handle that we talk about, which is the multicast game. And that's what we're going to demonstrate today. So the second thing talks about, the second aspect would be the local delivery of this content. But as I said, this is not something that's going to be demonstrated today. The way this demo is going to work, I will trigger from the UI a request for a video download. And that request will have two purposes. Number one, to send an HTTP GET to get that video for the client that we have here. And at the same time, that will trigger the other 30 clients in Bristol to try to access that video as well. So what we see here, this is our dashboard where we record the demonstration that we're doing. So on the left-hand side, you can see a graph where we'll just show in time. And of course, we have exactly the time that we have here today. And it will show you how over time the multicast game that we have over a single transmission increases from zero to 3,000%. So let's now start watching the video here. So this should trigger the first HTTP request that you'll see here. Okay, now it's going up. So we can see the first HTTP right here. And how now it's going up to the maximum based on the amount of clients that are connecting to receiving the same amount of video. Of course, what the technology is doing is within a window, it realizes that an X amount of clients are requesting exactly the same content. And the technology knows that the delivery of this content within a window space can be sent to X amount of clients that are expecting that to be played. Of course, we know that within a certain size of that window, the video can be properly played. In this particular example, with the 30 clients that we have, we managed to send the very same video to these 31 clients with only one single multicast. Now, if we keep on playing this over time, you can see that, of course, some of these clients might drop, they might not want to see the video anymore, or there might be some network problems. And in that case, of course, you will see how the game drops. But at the very best, we have exactly the same performance that are, I mean, at the very worst, I would say, that when you go to zero, that would be the same performance that you would get if you were going to send this video with unicast links. You can see how some of the clients miss some of the chunks, but now they are going back to getting the video again. And as I said, this video has been sent from Bristol, delivered to the emulated users in Bristol, and delivered to us right here. This is the video that we're playing.