 Hello everyone. We're excited to be here at O and E as September 2020. My name is Renu Nable and I'm VP and GM of the Edge Computing and Ecosystem Enabling Division at Intel. With me I have Prakash Kartha who is the Director of Edge Services segment at Intel. Together we're going to be presenting to you how we're bringing in real-time optimizations to edge deployments. Now the whole industry is shifting massively towards edge computing. The reasons for this are multi-fold. There's an explosion of data across different types of devices and different types of, you know, locations. There is the rise of artificial intelligence and analytics as well as the advent of 5G. All of this is propelling the industry massively towards edge computing. And some of the underlying drivers are low latency, high bandwidth, end-to-end security, as well as seamless and frictionless connectivity. Almost every business or enterprise or industry is looking at how they can take advantage of edge computing to derive, you know, actionable insights from the data so they can then impact their own business or attribute value to their own business. Intel is looking at edge computing from two different directions. On from one direction we're looking at how to continue to extend our clarification and network transformation of the network transformation efforts that we've been at since 2011. At the same time we're also looking at it from the IoT side where we're looking at how single function embedded devices are getting transformed to be multi-function intelligent edge platforms. Both of these efforts are together complementing and creating robust edge platforms that can address a variety of different use cases both on the on-premise edge as well as the network or the telco edge. As we look at what the Intel strategy is for edge computing it's threefold. Intel has a diverse portfolio of silicon, CPUs, accelerators, ethernet, storage. So all of this diverse portfolio has been optimized specifically for edge computing. In addition to that we have a robust set of developer tools, developer tools that are driving the convergence of analytics and inferencing media capabilities or media optimizations as well as a variety of networking workloads with some very vertical industry specific offerings. Some of these tools are called OpenVINO for AI deep learning inferencing, OpenNAS which is being used for networking and 5G capabilities, OpenVisual Cloud for media enhancements and DPDK for data plane acceleration. And on the third pillar of our strategy is ecosystem scale. We work with over 1200 ecosystem partners and over 15,000 end users in order to drive scale of these deployments and we use a variety of different initiatives such as the market-ready solutions, the RFP ready kits, the Intel network builders program as well as the Intel select solutions. I will now hand off to Prakash who will dive deeper into some of these very specific optimizations that we are doing for the edge. So Prakash. Thanks Surno, great to be here. So the topic for the day is really around how to enable different types of locations on the edge with cloud native capabilities. So whether you are on the access edge or the near edge or the on-premise edge our belief is that you need a common set of building blocks to have a uniform view of the architecture when it comes to different edge locations. So there are three things that are very critical to understand before we get deeper into the topic. Number one is to have a scalable platform. To have a architecture that works on all of these different edge locations you need a cloud-like environment and that's why cloud native has become so critical for the edge. You need a very modular approach too because once you start to put these different building blocks together you can piece these things together in different ways to serve specific use cases for these different edge locations. And you can you can drive all kinds of synergies between software investments that you're making between the cloud native capabilities and you do that by putting together these common sets of building blocks coming out of a common technology pool and if you have these common sets of building blocks then you can enable the ecosystem in a very uniform way. So there are three things we want to talk about. One is you kind of start at the bottom of the pyramid that you see here in terms of having a cloud native architectural foundation. We talked about it being scalable modular flexible so that's the foundation. Once you have that depending on the workload that you're trying to enable whether it's a base station, a 5G base station or a core network you can start to implement certain KPIs and the kind of KPIs that you're looking at in all of these locations would be things like high throughput, very low latency and high determinism. So to get these kinds of KPIs across these different edge locations you need these consistent scalable cloud native platforms underneath that and once you have that then you can start to enable all kinds of services innovation on top of it starting with convergence of workloads. You start out with enabling your core workload whether it be a networking workload whether it's a 5G base station or a D-PAC inspection or a user plane function but then you also start to integrate other non-networking workloads because that's where the future is going and to enable the cloud native workload converge kind of environment you also need open APIs because once you have those open APIs then you can accelerate your application development. So a lot of what we're going to talk about today is how all these concepts are going to come together into building blocks put together in the form of blueprints. So now let's dive a little bit deeper into one particular example. In this case we're going to talk about the VRAN the virtualized RAN and how all these different cloud native building blocks all the concepts we talked about so far come together to enable a cloud native VRAN platform. In this example we're going to talk about FlexRAN and FlexRAN is the containerized layer one for a 5G base station and we'll talk about how FlexRAN layered on top of the openness framework which provides the cloud native ingredients builds together brings together the full platform. So let's talk through some examples. The first one we'll talk about is the container network interfaces the CNIs. So FlexRAN requires multiple CNIs so the first thing you would need to consider is multis. So multis CNI enables you to attach multiple network interfaces to you to your pod. So typically in Kubernetes each pod has just one network interface with multis you can create a multi-homed pod which is multiple network interfaces. That's the first thing to consider. The default CNI that we have in this particular configuration is Calico but there's more to it. So for example the next question that comes up is how do you connect your containers to your NIC interfaces? So SRIOE for example the SRIOE CNI is used when you want containers to get access to virtual functions on your NIC ports that are SRIOE enabled meaning those NICs that have both physical functions and virtual functions and you're able to treat each virtual function as a separate network interface and you can configure its own MAC, VLAN IP and so on. Now that's one option. The alternate is if you want a simpler plug-in you would use something like a host device CNI which will essentially move the requested device from the host network namespace or the containers network namespace. Again you would use this if you did not have any complicated configuration that mentioned earlier. You can use a more simplified CNI like the host CNI or host device CNI. The next example of another CNI you would use is the user space CNI. Now the user space CNI is designed to implement user space networking as opposed to kernel space networking. So an example of that would be dpdk you know something like OBS dpdk with containers. So that's an example. So another one would be the bond CNI. So bonding basically provides a method to aggregate multiple network interfaces into a single logical bonded interface. So for that you would use a bond CNI. There's another one called tuning CNI. A very utilitarian CNI that you would use for changing certain system controls, interface attributes in a network namespace and so on. So ultimately what we're talking about here is a multi CNI type interface and you pick different CNIs based in the particular aspect that you are trying to accentuate. So the next element of the architecture are the one of the system parts that you would need to have. Node feature discovery is a Kubernetes plugin that you can use to detect and add you know basically detect and advertise hardware and software capabilities on a platform so it can be discovered and it facilitates intelligent scheduling. Again a very useful microservice to have within your within your VRAN cloud native architecture. The next one is core pinning. A core pinning is a again a Kubernetes plugin that provides core affinity for applications deployed as Kubernetes parts. Now let's take a look at some of the the platform parts. So an interesting microservice that we added to this particular configuration is something called RMD or resource management demon. So RMD is based on Intel's resource director technology. What it does is it provides a framework for monitoring and allocating cache and memory. So in the VRAN context, RDT aids detection of code and code noise neighbors which helps reduce performance interference. That's one example. Another example is you need specialized hardware like FPGAs for managing certain parts of your VRAN pipeline like the forward error correction. So we provide a Kubernetes operator that manages the software update the automation of the FPGA which can get quite complex without without this infrastructure. And finally in an ORAN type context we have a dynamic device profile or a DDP for the SMODNICS that Intel offers which basically run filters for different types of ORAN profiles like the ORAN front hall. So you can see how all these different building blocks become essential for you to consider as you build the overall platform. Now as we move forward let's talk about let's do a little bit of a double click and think through what are those specific real-time optimizations that we've enabled through openness for FlexRAN and for VRAN. So we're going to double click a little bit further. So first let's talk about deterministic IO. So you're talking about deterministic IO on the front hall to achieve ultra low latency and high performance. So openness provides a number of optimizations to achieve this including optimizations in DPDK, offloads to NICS, con level optimizations for SRIOV. So overall with these optimizations we are able to achieve less than 20 microseconds max latency on the front hall and we've tested this on an extended or an extended period with various conditions like noisy neighbors, a mix of real-time and non-real-time traffic and this 20 microseconds is the max. So the average is closer to the min but that's the max we've been counted. The next element is deterministic acceleration. So you know similarly openness provides a highly optimized implementation of 4G and 5G effect. We talked about this in the previous slide. So these are through optimizations in DPDK. We have flexible APIs to execute in either hardware or software in the FPGA or in an EASIC. Look aside models for hardware arbitration with optimizations for configuring up-link down-link ratios, configuring number of queues and so on and so forth. So a lot of good optimizations around just running forward error correction on that FPGR and EASIC. The next element is cloud native orchestration and how to do that in a deterministic fashion. We spoke about this a little bit on the previous slide but just going to couple you know pick out a couple more points. So NUMA awareness. So NUMA awareness is something that you achieve with a module called topology manager. Topology manager is a part of you know upstream to Kubernetes but it's in a very important component that you would need to have in your architecture. What the topology manager does is that it maximizes the performance by ensuring that the workload in this case flexRAN is placed on the socket in such a way that it removes the need for cross-UPI communication. What that means is UPI stands for ultra path interconnect. So it's interconnect that connects to CPUs. So if you have NUMA aware nodes and you're able to actually land your workload in this case flexRAN on certain sockets that minimizes that you know cross-UPI communication. Again it's all about determinism and latency. We talked about core pinning you know support for hyper threading, allocating CPU resources to parts and then we also talked about node feature discovery as another important part. And finally after all the software optimization you still need a very deterministic overall platform. So foundational to this is going to be implementing real-time and real-time preemption and Linux. So this is work that Intel has enabled with our operating system partners for several years and now we're making this available with Kubernetes as part of the openness experience kit. What this enables you to do in addition to the real-time is also enable that core isolation, allowing a user to deploy a deterministic workload like flexRAN like the RAN DU for example on an isolated core and then operate without any interference from other kernel threads. And even if you have a context switch let's say from you know context to a higher priority kernel thread then you are able to switch back to the real-time thread in a very deterministic manner. That's the key point. So it's not that you cannot context switch when you come back you do that in a very deterministic manner. There are optimizations specifically for that. Similarly we have optimizations for BIOS on this configuration. Again an example of that would be from our determinism standpoint is there are certain extensions, certain advanced kernel instructions like AVX 512 that is required for flexRAN which may take higher power and that may cause certain fluctuations in frequencies which may impact determinism. So we have implemented optimizations to minimize those fluctuations and then finally power management putting cores to lower frequencies, lower idle states with power states and so on. So collectively what we're saying here is a lot of these you know pointed optimizations are coming together in the form of this recipe that we've built an openness that makes it kind of easy for you to go deploy the far edge or the access edge. So now let's talk a little bit about another use case. So now let's talk about the near edge. So near edge is the next level of aggregation from the far edge. So what's obviously the big difference with the near edge is what is the workload running on it right? So now we're talking about the 5G, UPF, you're talking about deep packet inspection, network analytics but also we have AI, you have media, all of these different use cases are now starting to converge. So what we have done is if you think about the the platform that we talked about for RAND, the exact same platform with a slightly different set of ingredients, we are enabling that for the near edge. So we start with a solid foundation, right? The solid foundation is our hardware ecosystem. So through the Intel Select program we have for example what's known as the NFVI Forwarding Plane which is an Intel Select solution for the near edge which has the right skew of CPU, of Ethernet, NAICS, Quick Assist, even the ability to take that into select and start to add on different types of accelerators like AI cards. So you start with that as a baseline and then what you do is you add on top of that the high throughput data plane, right? So you see the whole DPDK family, OVSTPDK. So that becomes the data plane on top of that. Then you layer on top the openness distribution that we just talked about, tweak for the near edge use cases. And then finally you bring in reference implementations for the network functions, the edge services. What we've done is we put all this stuff together into essentially a blueprint. And let's move forward to show you how this blueprint is not just for the near edge but also for other locations. So now let's talk about how this one blueprint is kind of expanded to different edge locations. So we talked about the near edge which is more of a 5G UPF. But this architecture, something that we've been investing in for almost 18 months now, something we call the converged edge reference architecture. The idea that you can take an architectural blueprint and bring together workloads from different starting points, a networking workload, an inferencing and vision and media workload all coming together into a common architecture, what we call the converged edge reference architecture or SETA. So we in fact launched this in 2019 with the first instantiation for 4G and on-premise type environment which included a private wireless recipe for outdoor ruggedized type deployments. What we're doing now is we're taking the same concept and we're starting to build out SETAs or converged edge reference architectures for different network edge locations. The first one that we're releasing later in September is going to be for the near edge. So we'll have a converged edge reference architecture that we make available through the openness distribution for the near edge. And then we're also working to upgrade the on-premise edge SETA with support for 5G. So you can see how we've taken the idea of a cloud native platform building out a blueprint and then scaling it out into different edge locations. So the end game for all the stuff is that the SETA is kind of a starting point from a design perspective. It's an architecture and SETA is based on openness as the underlying cloud native platform. Now for us it's all about the ecosystem at the end of the day because the ecosystem has to be able to take these reference architectures and be able to scale that into the actual deployments. So we have an excellent set of scale programs at Intel. One of the scale programs is called Intel RFP ready kits program. What the Intel RFP ready kits program is is you have the ability to work with commercial partners to construct essentially kits that are ready to be deployed at customer RFPs. So what we're doing now is we're taking these SETAs, these converged edge reference architectures and then converting them into RFP ready kits. We already have RFP ready kits for the 4G on-prem SETAs that we built earlier. So those are already available as part of the catalog that you can get access to. And then for the new SETAs that we're building we're going to convert those also into Intel RFP ready kits but we don't stop there. So once an RFP ready kit is available the next step is to actually give them deployed in commercial instances. So that's when that RFP ready kit becomes what we call a market ready solution. The market ready solution is another scale program focused more on deployment. So once you have a number of these RFP ready kits deployed in the market then you can start to get scale. That's when system integrators come in and take these market ready solutions and then you have this ransom repeat. You get the same solution deployed with different types of use cases at different customers at different enterprises and telcos. So you can see how we've taken the idea of a cloud native platform converted into a reference architecture and scaled into the market. Okay so that that was our presentation. Hopefully you enjoyed it. We are really looking forward to having more and more you know investments in cloud native architecture specifically for the telco edge with the access and far edge going into the near edge and continuing to make investments and optimizing it converting them into reference architectures like the setup program we talked about and scaling into the ecosystem. Thank you very much and have a good day. Thank you so much we have you on. Feel free to answer any questions now that are in the Q&A panel. We have about five minutes left. You are live whenever you're ready. So Prakash I think we have one question here which is are there any good resources to learn more about the real-time optimizations to edge deployments? I think on our website which is openness.org you should find a number of resources white papers and other documents that also talk more about the real-time optimizations. Prakash anything you want to add? No that's good right now. So if you go to openness.org just look for a specific white paper on grand and you'll see a pretty detailed playbook and all the different things we talked about are documented there. Yeah and these these optimizations are included in the public version of OpenNEL. So that is the open source version so you should be able to get it from the open source version. I think there's another question on do you plan to include NSVI acceleration in any kit OBS or VR? I believe we do Prakash do you want to take that? Yeah yeah so for OBS we have two versions of the OBS and this is the OBS DPDK. Both are supported as CNIs through a project called cube oven and so again if you go to openness.org just do a search for cube oven cube OBM and you'll see a specific CNI that we've integrated to you know if you want to implement OBS or OBS DPDK in your cloud native environment that's the recipe that you can use. There's another question on have any components of CERA be deployed in telcos already? Yes so we have so like like we talked about earlier there are deployments today for the 4G on-premise version of CERA. We have deployments in a in more of an enterprise context. This includes a private wireless deployment in an industrial context as well as a retail context. We are moving now into the near-edge so you'll start to see more near-edge type deployments in the future. Any more questions or anything else from the OBS? Well if not Prakash, thank you so much for your time. This is great. We'll go into the end of the minute early. Thanks for your time. Thank you so much. Thank you for having us here. Oh you bet. Thank you.