 Hello everybody, I'm Hasib Akhtar from Ericsson. Hi, I'm Doug Ying from AT&T. Thanks for coming over. We're going to talk about the network API exposure and context management at the edge. And I'd like to mention our colleague, Dr. Satai Bokoch from AT&T, who was actually supposed to be here as well. But because of some other business priorities, he could not, and we do like to acknowledge his contribution to this work that we're going to present with you. So this is kind of the agenda. So we're going to talk about the 5G architecture and edge, and then go into what are the contexts that are available or could be available, and then how those contexts could be exposed in the network, and then we'll talk a little bit about APIs. So going forward, the 5G architecture and how does that impact edge. So basically, you know, the advent of 5G and the evolution of 5G has a lot to, a lot of contributions actually towards the realization of edge computing. And a lot of the use cases are actually related to 5G, at least initially. So the key thing that happens in 5G from its earlier version in 4G is that there is desegregation of the RAN and the core network components. And what they have done is they have taken the baseband unit and then desegregated into two different components called central unit and the distributed unit. So in the 3GPP terms, it's called CU and DU. And then they have further desegregated the CU into the CU control plane and then the CU user plane. So basically what you have then that the desegregation of the baseband now enables you to have this CU-CP and the CU-EP as virtualized components. So that enables you to put it into a cloud not only just at the edge, you can put them in any cloud including private, public, and whatnot. And then also on the core network side there is a thing called control and user plane separation or CUPS. So that's also another desegregation where they have desegregated the control plane and the user plane separately. And then the user plane is shown here UPF user plane function that also now can be virtualized. I mean not only virtualized, it's now more componentized and can be moved about from the centralized data center to other places. And also there are a lot of other functions that have emerged as part of the desegregation of the core. There is a terminology called service-based architecture which is not today's topic but I just kind of highlighted that here in this blue background on our own app that shows that basically the EPG today which is the SGW and PGW and MME so those three components have been decomposed into various things. And we will go over a couple of them which are relevant to the edge at least the API part of it. The other thing that I wanted to mention here that all of these are going to be managed on a service layer by own app. So we also envision that there is going to be a version of own app that will sit into edge and we're just calling it own app with a small E on the left part. So I guess the takeaway from here if you see in the dredge circle that that's where we can kind of take both the ran and the core network components meaning the CUCP and the CUUP from the ran part and the UPF and the user plan function and put them into one place and then you have access to IP services of either the operator's IP service or the internet or even any other third party IP services. So this basically gives you a tremendous capability to move things around and bring components to the edge. And the other thing that I wanted to mention that the examples that we're showing here is the data center site and the central office sites cell and antenna sites. So it shows here that we're putting edge in the central office site but it can be anywhere. It could be the cell sites or as well as in the antennas. Any combination of those components can go on there. Anything else, Doug? No, I think the one thing is just to reiterate is the central office and the data centers are really just examples of locations. A lot of I think in the future what we'll be seeing is the edge will be defined not by location but by workload or capabilities. So moving forward, so this is kind of the example of the use case. On the left side, and these are 5G use cases actually, so on the left side you have kind of the three components of 5G and this is defined by IMT 2020. So the latency, the target is about one millisecond and that's basically from the UI to the edge of the network and then the throughput about at the edge on the average throughput is about 100 megabits per second and the peak throughput is in the 20 gigabits per second. So remember that these are the target for 5G. In the initial rollout it will be much less than that but as the technology matches you're going to move towards that. And on this multi-shaped diagram here we have different components of I guess the characteristics of the KPI so the throughput is denoted by the T here throughput then we're going towards clockwise latency, reliability, mobility availability, energy efficiency and the user and device density. So and then on the bottom here we have different use cases. We have the mobile broadband, then massive MTC so that's different IoT devices basically and then the dense information society where you have a lot of download of information at a location and then the connected vehicles and then you have those different type of third-party applications they are different manufacturing and the tactile type of components. So if you go with the use cases so this one shows that basically we need to have high level of availability and mobility for the mobile broadband and the other dimensions are not as much and going for the next one in the massive MTC we need like you know the higher user density and we have a lot of energy efficiency and also a lot of availability and the other dimensions are not as much. So I'm not going to go through this altogether but then the next use case is the dense information society. The next one is the connected vehicles where you need availability mobility as well as reliability and the latency and then comes the ARVR type of scenario where the throughput and latency are the key aspects. So the next one, Doug. Alright, so we talked quite a bit about the network especially the 5G oriented side. I want to look at some of the areas of focus that we have picked out and this is not a comprehensive list there's a lot of different areas where we feel that there are further work that needs to be done to further our understanding, the capabilities of the network or further our understanding of the products and services. Number one, I'm going to go through this real quick. Number one is what is the IT environment and what are the network operators going to provide? It's one of the key aspects is there's a combination of the applications and the offer that the service provider will provide. That's sort of what we would likely see, hopefully see at the edge of how do we get those to understand each other, work together and determine at least from the application and environment perspective what it's going to look like. From the traffic and networking perspective as I see mentioned there's an ability in 5G to what we call breakout traffic or branch out traffic in several different places along the network. But there still needs to be an understanding of how we're going to do that. At the end of the day we're still on IPv6 or IPv4 network and we still need to look at how we're going to manage the routing of traffic out these various exit points how we're going to discover the content or the information where it resides where it's best going to be served out and how are the devices or the users going to discover those locations. And then the next step is to really make this all sort of work together. We need to look at what we're calling here network APIs. Network APIs are both sort of what the network attributes will cover a little bit later but also potentially with the subscriber who the subscriber is or what kind of service have they signed up for. And not only what the APIs are but how are we going to expose them in the desire to have one set of APIs for both the internal needs and the external needs that sort of if we do that that would imply that we provided some level of simplicity but we have to now understand what's the best method of serving out externally the information that is desired or required but still protecting the network still protecting privacy of the customer, et cetera. Other parts of the edge and some of the other areas of focus and you've heard a lot about this during these sessions here is that we need to find the right footprint, if you will the right size for the VIM and some of these locations will be very small as far as compute and storage physical environment constraints and how do we find the right optimal VIM for this type of environment. And last one on the list here is the actual infrastructure who is going to own it, who is going to operate it how are we going to choose the environment that we're going to run on. So we talked a little bit earlier about context but a little bit deeper context to me is like who, what and where those types of questions that you want answered or you have questions about in more detail that you want to get answers to. So for example, monetization how would I monetize the experience that you're having or what monetization options would the service provider have what information can I get as if I'm an application supplier about the user who's asking to use the application for example, are they a prepaid user or a postpaid user are they signed up for premium QOS, et cetera what type of subscription do they have and how close are they to their thresholds if they're on a rate plan has a limited amount of usage user information this is our user location information this is all a set of information related to where are you now and how best to kind of match where you are with the right experience or right applications, et cetera we also have assumed that we need to provide information like latency and bandwidth available at this location whether or not you are moving if you're moving how fast are you moving what direction are you moving what are the conditions of the network are they free and open for high bandwidth are they congested and have a relatively constrained amount of resources and we have to be careful about how we allocate resources so we treat everybody fairly and all the applications can still utilize the experience that they need and some of the things that people may be interested in are things like topology of the network you may want to know again where the network functions are so you can match network functions with the applications things about nature so context is very broad but it truly is I think the upper left says it quite well is that it's going to be king it's really from the edge perspective that's one of the key capabilities that we need to leverage, exploit and provide in a matter that's safe but is easily to consume yeah so basically then the APIs how do we make use of them so as I've shown earlier and Doug mentioned a few other things that the 5G allows re-examining of the architecture so we can now move things into the edge and then a lot of the context that becomes available the big drivers we still feel that the service agility and the reduction of the cost so one of the thing of the API is to have quick service deployment so the service velocity would be much more faster and then the flexibility of the components that you can put into edge from an architecture and deployment perspective and we believe that this will lend to innovations and bringing new applications which will leverage the 5G strengths and the capabilities in the bandwidth the large bandwidth and the low latency aspects so the key question still remains today that what are the applications what applications are going to be used that will leverage the APIs and will actually need the APIs the onboarding application especially the third party applications is one of the challenge that the industry will have to solve right now at the edge we are pretty comfortable about deploying 5G or we have a pretty good vision how to deploy 5G, RAN and the core network components but as it comes to some of the other URL CC applications we really don't know how to onboard them how to connect together some of the applications like Air Applications that requires much more battery power in the mobile how do you offload them into the edge and how are those APIs would work together some of the applications such as analytics you could do a lot of the local analytics at the edge without sending the data to the core but how are those applications going to get connected have the internet services and so forth how would they get connected to the operators other third parties or even the over the top providers so again the context that I mentioned but we really have not as an industry kind of figured out what are those contexts going to be and of course the exposure mechanism is what we are trying to figure out that's what we need help from the industry kind of work together to work this out all right so there's a couple of key at least in the 5G network with an ONAP orchestration layer there's a couple of key functions that we think are critical to exposing the APIs that we've just been talking about we'll start with ONAP ONAP is going to be a consolidation point for a lot of the information that is coming from the network functions that are mostly in blue here some of the network functions are green and orange but you see these yellow sort of ovals with dotted lines they're sort of like where we know they need to be giving the information to ONAP we're not exactly sure what the interface will be yet we're not sure of the standardization but that has to happen in order to take advantage of the information that will be provided and generated by the network function in the 5G world so ONAP is definitely going to be a key hub for the software, the network functions that are creating the service layer here on top of that we are looking at a couple of different areas where how do you expose the APIs where do you expose the APIs should the API exposure be centralized or regional or highly distributed so we have several examples of that in the bottom left we have an NEF network exposure function which is a 5G core network function that its role one of its roles is to provide interface from an external world to request information that's within the 5G network so this could be information like we talked about before network conditions, user identity things about nature so that's one of the key functions that is provided by the 5G core and we're showing two different distributions again the highly distributed scenario where we have the network exposure function co-resident, physically co-resident with the UPF and a distributed ONAP instance as well and you can see also there's a radio access network functions as well this high distribution is probably what most people are thinking about when they think about EDGE and I think some of the other organizations like Etsy are thinking about when they're talking about MEC and this will likely be one of the scenarios here a more traditional scenario which may or may not be the first place we start with sort of look at how this topology will look over time is have a more of a centralized or regional approach where the NEF which is in the upper right hand side here is sort of sitting with its brothers and sisters in the 5G core this is a very much traditional you know, TOCO model in many respects in this model for the right now I sort of prefer because if you're an API based network you don't want the applications to have a hard time to find the API that you want to use so centralized or regionalizing might provide an easier way of initial consumption as we do optimizations I think you'll start looking at distribution over time but the goal here is that there's not one deployment method we'll probably see several different types and they're not all bad they're just different choices and different timelines and for different use cases I think in many respects if you have highly latency sensitive API requests and response and the information has to be derived from the networking might have a distributed solution you have less time sense of response or your response requires a gathering of much more information before a response can be sent back then it might be a regional or centralized deployment model it might be a better choice for you if you mention a little bit about the application function I'm sorry, thank you Haseeb so the application function which is on the bottom right here is another way of thinking about an API gateway in this case the AF stands for application function and it could be several different roles it could have the ability to be the destination of some of the user's traffic and then the user device or user themselves could query or request indirectly or directly information from the network it could be something that is monitoring what's going on in the network and based on conditions you can send information or request into the network exposure function or directly into the network function to make a request or in some other manner provide feedback back to the user again to another dense slide here but just to kind of talk a little bit about this slide on the far left is really a set of bullets that would equal a closed loop basically a combination of observation and then response so you see sort of the green is sort of what you would need to gather information and the orange is sort of a response based on what you've seen and what I really want to focus on here is the gaps so the gaps are this is not a comprehensive list of the gaps and if you're a security minded you'll probably immediately see that there's some security that is not listed as one of the gaps but it is clearly one of the gaps both from subscriber policy as well as sort of network and traditional security but the other types of gaps that we have highlighted are that we need to make sure we have a way of controlling and configuring these highly distributed systems I think you've probably heard about these same scenarios or same gaps in other forums and other conversations and so I think it's pretty well understood that some of these gaps are need to be covered synchronizing the observations or observability and controllability so in some cases we have to figure out how to do short term closed loop type of controls so that we don't have out of sync conditions or we have two or more types of actions trying to be applied to the same user or same network function there's also you know vendor lock-in is really a common problem that we want to avoid and openness is generally a way to do that and then some of the other things we want to look at are how do you get access to real-time data how do you get access to real-time control links and what are the right strategies to incorporate ONAP also sort of another note on the bottom right of the side is that O-RAN, OpenRAN is a relatively new initiative and it's looking to cover some of these gaps and it can't cover it all by themselves so we're going to be looking for a community to help solve these gaps that we mentioned plus others as we dig deeper into this topic and also I guess a couple of other things that are not mentioned here Doug is that the regulatory aspect of it the privacy aspect of it and then context when you have the context you need to kind of sanitize the context so that you don't give out the privacy information just to give out the data that are only necessary and that's as you know that in the industry it's being discussed a lot nowadays so we suspect that there will be some boundary conditions on that as we deploy this net in the future Yeah, very definitely Okay, so now we wanted to talk about the APIs like what are the APIs and what do we think that this model evolves towards so we kind of went through and classified them in four distinct areas and then of course as you see that ONAP is going to play a big role and the desegregated RAN and the core will of course have another play to it because of the 5G influence and the architecture so the first one is you know somewhat non-real type type of applications which requires you know information in the range of 100 milliseconds and these are internal third party applications and the internal and external here is mentioned in the sense or in the meaning of that it's external to the operators network and internal to the operators network and third party is mentioned as that anybody other than operators are basically working on that and the operators could also be now doing their own development as well and typically in this case here the third party also in some places means that non-traditional telco vendors like none of your incumbents basically so in the first case that you know there would be a lot of applications that would be going inside the ONAP in the D-MAP so they will have access to the ONAP data and they will basically provide different services you know microservices or otherwise and they would most probably be in the proximity of the DCAE which is the data collection and analytics engine and also you know stay with the policy framework to understand or get applied by the policy so that the APIs can again be executed properly and then a lot of the ANAI information which is the network status information would also most probably go into this type of applications the second one is it's the near real-time and this would basically sit in the core in the edge at the top of the RAM function very connected to the CUCP and these would be the internal applications again this will most probably be optimizing application for example to basically do programming of the RAM capacity management it could be related to your RF distribution or some sort of antenna kind of management as well so these are some of the things that could be very closely related to the RAM and the core network function but they would be internal but because of the desegregation of the RAM now you have the ability to kind of have modular presence towards some of the high-level abstraction of the RAM functions that you can now connect with those APIs and these would be in the range of 10 to 100 milliseconds and then there are the third kind which is the one that we currently see today in the 4G networks too these are the APIs that a lot of the operators today have exposed to the developers so this would most probably be going out of the external API framework of ONAP or some other gateway that the operators have today so this actually started from the old WipeGateways type of deployment so these are the same I guess the same type of functionality in a different incarnation in this context and then the fourth kind is again the third party external applications but they will be sitting in the UEs so there are a lot of applications that are in the UEs today but not all of them are really connected to the network or do not get to have access to the rich functionality that the network could offer so those are I guess some of the ways that we see the API to evolve so then quickly wanted to go over the deployment so the deployment as we know in the OpenStack terminology we have the control nodes and the compute and the storage and then we are showing that it's basically be deployed from an upper layer with ONAP with multi-cloud services so there will be different kind of VIM and then there are some tools, zero touch provisioning I mean the airship is one of the things that just came about which could be relevant here so there are many open source activities that are actually going on towards this in terms of deploying the edge components and we believe that the API would be one part of it so OpenStack, we all know about that there is OpenEdge computing which is kind of OpenStack++ with some changes in the chemo and then you have the EdgeX Foundry which are exposing APIs to some sort of developer base ONAP we already talked about it airship is some of the tool set that has been recently introduced to OpenStack that would be very useful for containerizing of the control plane of the OpenStack components to reduce the footprint and do some thin level of control then StarlingX is also some of the things that WinRiver has contributed to OpenStack to do a lot of the control plane management and optimization around in part of their titanium cloud portfolio and we have been hearing a lot about it in the form of Acreino that would be doing all of the or using all of those components from different open source and as well as it will basically develop some of their own components and think applications that are needed to basically deploy EdgeStack in more efficient and automated way So with that Just a quick view of this, I think we stole this from Condin but essentially what I wanted to say here is that the APIs we're referring to are really at the top couple of rows, right? So you have what I call services or the DNFs and applications, you have the APIs and in general I want to really point out that the APIs whether they be initially thought of an Edge API or initially thought as a centralized API the reality is I believe that we're going to have a common set of APIs across the entire network so at some point in the near future Edge and not Edge, whatever the not Edge is would be essentially using the same APIs and the same applications that we would develop or hopefully others will develop or be able to leverage them Okay, so the last slide So we basically in conclusion we are using the 5G architecture framework and a lot of the common platforms and we're hoping that Acreano will bring all of this together We still believe that the context is the king it has a lot of implications that could be realized and potentially provided as a service to the community and the business cases are not clear so that's one of the things that we need to work on as a community So I think that's all we had and we'd like to thank you these folks that are listed here for their contribution to this content The questions, right? Hey Doug, Jeff Hartley with Lumina Three-part question Have you gotten as far as defining like preferences or guidance for how you'd like transport protocol for the APIs to be handled something like, I don't know, pub sub-thin lightweight like MQTT, ZMQ, anything like that Secondly, to address the encryption with the advent of a couple of the bodies that you've just talked about and like with, you know, Daynose and things like that you have direct exposure to crypto offload and a lot of commodity network chipsets and like zions even and things like that So could that be used to sort of superimpose like TLS offloading for the security requirements of said transport even if we're just payload and third with the, not current but next release and in about six months of ONAP when you start to have containerization and decomposition of some of the things like SDNC and APC have you thought about like a microservice approach kind of encompassing that the API endpoint handling the transport protocol as well as any translation and CAPD, CAP, etc I know it's a big question Those are three questions The first one is we've just started to look at the protocols so we have not made a decision yet so it would be great help if people in the room or the community would because we want to find the right balance You mentioned everything from security and ease of use, things of that nature all have to be factored in to it I just want to make sure it's easy and consumable for all and standard and open and open I mean the standard is good but open is better is better required actually exactly and the last one there's a lot of work going on with ONAP I don't know if it's going to come in their next release but definitely ONAP's going to be critical to kind of make this it's the glue is what I referred to it to make this all work together a lot of these things are brand new in this discussion point we'll have to definitely factor it into the next several releases it's probably going to come in pieces as well Okay, we'll pitch in and we did not factor in the transport but that's going to be there I mean that's one of the things that actually makes a lot of these things happen We've been having a lot of luck with MQTT and ZMQ is why I throw those couple out there they're light and any little processor can do the in-cap and de-cap on them Awesome So thank you very much for mentioning that security was a gap I've been well trained at least I think I am Yeah probably by my office Walt Barnes Chief Security Office AT&T Have you thought about authentication and authorization because every point of disaggregation is a new API where there wasn't one before so what are your thoughts on how you're going to do that So there's we didn't really talk about it but NEF is going to be probably like a proxy or a gateway so what you see in the topology is there will be an external and internal interface points and the external ones will have much more highly scrutinized access controls for both authentication, authorization, roles things of that nature will all be part of that we're going to have to grow our way into it because none of these things don't exist yet so we'll probably start with very restrict rules and losing them up over time Internally, I think we need to kind of talk through it's the same API, same structure you know how much security do we need sort of within the network querying other network functions or getting information it's work in progress it's only broadly covered in some of the standardizations mostly left to implementation which is usually the case with security but we'll get there we can't deploy we won't deploy without security for operator and sort of indication of the requester but also making sure as Asib mentioned privacy is also going to be as big or bigger part we have to make the data secure and private and whatever that means for every use case might be a bit different but that's definitely what we need to factor in thank you we have time for one more? Paul Andre you said you would have an easy question for Asib so you talked about all those APIs and you mentioned that they need to work across vendors one set of APIs across the network that they would be open and are we heading towards a very rich set of APIs that have a lot of capabilities or a simple set and one of the challenges that I have is that there are people developing software for developing those applications and they don't know very much about the word as network its architecture, the different vendors their different characteristics but yet there are the people who would write the applications that would need those APIs let me start Asib can jump in so you said rich and where are we headed I think those are the sort of paraphrase so I think we're going to start with relatively small list but we need to get with the right list so what we don't mostly API definitions and discussions have been mostly focused on the standards organizations or organizations that are very narrowly focused on network type information and what we don't have right now is a community of application developers and what they would want and what they would need we did cover a little bit in the slides but not I didn't cover it in detail I think those are very critical what do you need to make your application work and what do you want if you had a clean sheet or we were able to provide it to you the two may not always align you'll definitely have more what you want than what you need but you need to figure out how to get at the minimum of what you want and extend to what you need so I think we're going to start small I think we're going to grow into what makes sense and we talked about wireless but I think the APIs need to be wire-line wireless access agnostic we should be thinking about it whether it be United States Comcast or AT&T or Verizon or CenturyLink it shouldn't matter from an adge application perspective how we implement the underlying capabilities of the network will be different so how we implement may be different but the API calls and exposure information should be the same the challenge still is to get the web developers into the loop, into the community and we are working towards that but that is a challenge I agree with that thank you I appreciate it