 Hello everybody. Thank you very much for coming. My name is Hasib Akhtar from Ericsson. And I have my colleague, Tuber Keise, also from Ericsson. Okay, and we're going to talk about realization of infrastructure and network APIs at the edge. So we're going to go ahead. Okay, so I will start and get you some context for the following discussion related to the APIs. So what we have here is the 3GPP view of what the disaggregated run and disaggregated core network look like. So if you look in the middle of this picture, you see on the right hand side this disaggregated core that contains a number of different nodes. It's both control node and also the user plane functionality denoted by UPF. So we'll put some more emphasis on the UPF during this presentation. Then on the left hand side we have the disaggregated run and it consists of three major pieces here. One is the CUCP, which is the central unit control plane. And this is the functionality that handles the mobility management in a radio network. We also have the central unit user plane, the CUUP, and that handles the user plane processing, which essentially is packet processing. Processing packet is aimed for the radio network. And then on the leftmost side here, we have the DU together with the RU. So the DU here is the distributed unit and the RU is the radio unit. And primarily if you're familiar with notions like baseband processing, the signaling processing, that goes on in the DU. So in today's deployment, the CUCP, CUCU, and also the DU are usually deployed as one single entity in an embedded system. But now we are taking the steps towards this aggregated run. So a couple of these functionalities could typically be moving higher up in the network like the CU parts. They are typically very well aimed for virtualization. If you look at the CP part, it's a soft real-time problem that we are talking about. And if you talk about the UP part, that is packet processing. So it's throughput and latency that are important for this part of the applications. For the DU parts, it's a bit more complicated because we have a synchronous loop going on in this area. So we are actually on a one millisecond level, always making new decisions on what goes in the air. And if you are looking at 5G, which this is aiming for, then we are going down even further. We are talking about making decisions in a 100 microsecond level. So it's a completely different area. So now what we see when it comes to edge deployments, a typical application here is that we are combining the CU UP part in particular, the user plane processing. Together with the UPF function, which is the user plane function from packet core. And this is also something that has been happening in the packet core. You may be familiar with the notion of CUPS, which is a control user plane separation. So in this setup, we see that we place some of the user plane functionality from packet core in the same location as we have most of the centralized part of the radio. And then we need to have a third party application, otherwise this is kind of pointless. And the reason for this is that we want to move this functionality further out in the network for a couple of reasons. One is obviously we want to have a low latency application placed on the edge. There are other applications that we want to limit the amount of bandwidth that goes through the right-hand side in this picture. In the radio network, we are sort of going to handling tens of gigabytes per second in the air interface, but we usually don't have that kind of aggregated bandwidth when we are moving upwards in the network. Then also on the top here, we have another entity. So in this case, we have been using ONAP as an entity for orchestration and also deployment of the functionality. And also in this picture, the crime of edge tags comes into play in order to deploy this functionality. And if you move to the next one, we have a couple of interfaces that Hasib here will talk more about. So on the left-hand side, we have this API A which goes from the network up to this ONAP entity that actually collects a lot of information for the network. And then we have the purple, the API B which is changing configurations in the radio network but also injecting policies into the network. And then we also have these green interfaces that are more related to the actual deployment of the functionality. And there is where the acreno stack comes into play. So by that time, we will go over to Hasib to continue with the API discussion. Thank you, Tarbian. So what we see here on the API A side, which is basically the all of the network that you have in the form of the core as well as in the RAM, that information that needs to go into the ONAP. So these are the information that relates to the user. So for example, the device and the profile of the users, application and service characteristics, the bandwidth, for example, how much bandwidth the user is using or how much do they need. What are the latency sensitivity to these applications? Are they like bandwidth intensive like the video application or delay sensitive like speech and other type of speech sessions? Then also the network characteristics, like what are their congested network or if there are any specific latency that are associated with the network that needs to be communicated to. And then you have the key RAM related information. How are the mobility patterns? What are the mobility conditions in different parts of the RAM? As well as some of the RF environment related information where you have what type of frequency you have available, which frequency is congested, whether or not you have small cells around or how does the user could be handed off and so forth. So those are some of the information that requires APIs which could be fit into the own app, for example, as an orchestration and management. And then the next class of API, which we're calling API Setup B, so where you can now inject some of those information that you have collected to basically optimize and manage better of the RAM components. And the things that you could do, for example, you could inject UE specific policy information towards the RAM and tell RAM that, for example, if this is a premium user, you provide higher bandwidth or better quality. If there are some handoffs happening, for example, if the user is moving in high speed and going across multiple small cells, then there is no need to hand off the user to the small cells. You keep him to the regular macro cells and move forward. So a RAM component may not have that information, so you use a management and orchestration aspect, in this case, own app, to inject that information to RAM. There are other policy injections also could be done. For example, what are the neighbor relationship between multiple cells? What frequencies are available and configured? How much bandwidth are available in other areas? The traffic prediction in terms of what are the users that are coming in one cell versus your neighbor cells so that you can do a better frequency and capacity management. Also, you could put some of the data enrichment, for example, across domain information. So one of the things are also, for example, here could be useful is the transport network. And RAM by itself may not have the information related to transport. So own app could then, in this case, send transport-related information to RAM and provide this level of granularity and information so that you could do better optimization again of the user experience. And the next one is related to the edge applications, such as AR-VR, IoT, CDN, and or analytics. And there could be others. So those information could then be fed into the acreno edge stack in this case. And this is related to really the infrastructure of your NFVI. So the network function virtualization infrastructure related. And this could be related to the edge application placement. There could be latency, requirement for that application could be regulatory. Then also, of course, you have the compute, such as what kind of CPUs, what kind of pods you get connected to. And networking related to the OVS DPDK or SRIOV or IPv6, for example. On the storage, whether you need onboard or off-board. So for example, for analytics, you need much more type of storage than an application like IoT. It could be for just onboard storage information is good enough. And then you have the workload characteristics, like whether this application is virtualized or is it containerized or you want to run it on bare metal. So those are some of the things that you could send or you could make use of it using those APIs to onboard those applications. And then finally, the API category D, which is similar to API category C, is in terms of the nature and the characteristics, but it does consist of mainly the RAN and the core network applications. So this would be related to what type of application are you onboarding, whether it's like the CUUP or the user plan function of the core. And then the similar type of compute, networking and storage information and the workload characteristics that are needed for these applications to be onboarded. So those are kind of an overall view of the API set that we feel are needed to kind of enable 5G and the NFVI, in this case, Acrena and the orchestration and management in this example ONAP and some of the 5G applications as well as some of the edge applications that could work together. And finally, I'd like to kind of show how this could fit in with Acrena. So Acrena, as you can see on the top, there is an edge API that is provided from Acrena Stack to the different applications. And in this case, applications include both 3G, sorry, 5G applications, the RAN and core, as well as the edge applications. And then what I'm showing here just as a very high level, that the API set C and D as we specified earlier in terms of the application placement could get the information from the ONAP layer as well as the software components which includes OpenStack, Kubernetes, Calico, SRI, OVS and the operating system such as Ubuntu and so forth. So that's kind of an overall high level view of what we think would be a realization of the APIs for 5G applications at the edge. Thank you. Thank you, Turban. Appreciate it.