Cloud Native Computing Foundation Cloud Native Telco Day EU 2022, 19 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Lessons from Enabling Cloud Native O... Sunku Ranganath, Mike Recchia & Hanen Garcia

Description

Lightning Talk: Lessons from Enabling Cloud Native O-RAN RIC for the Edge - Sunku Ranganath, Intel Corporation, Mike Recchia & Hanen Garcia, Red Hat

O-RAN RAN Intelligent Controller (RIC) specs enable self-organizing networks to be deployed as microservices within K8s clusters with RAN AI capabilities. Instantiating key network functionalities in RAN AI applications (xApps & rApps) as K8s pods have arisen the need for customizing Kubernetes architecture to address resiliency, manageability and policy driven requirements for the O-RAN RIC. This talk addresses some of cloud-native considerations of O-RAN to efficiently enable RIC with RAN AI xApps and have the ability to interact with customized set of MEC microservices. Through a live demo using AI based Traffic Management xApp, telemetry based xApp manager & open-source RIC implementation, this talk provides architectural aspects necessary for integrating AI applications, interfaces required for scaling the data efficiently using K8s infrastructure. Importance of telemetry constructs are highlighted to adhere to the real-time requirements of the ORAN near-Realtime RIC pods through the demo.

A

Hello: everyone, I'm sungkuranganath, a global solutions architect at intel. I'm happy to be here virtually to talk about lessons from enabling cloud native oran rick for the edge with my colleague, hasta mustafa who's loading. The effort along with my rick here from red hat to start off. We have approached oran rick, enabling using a set of essential building blocks from our smartage open project. Smartage open is a cloud native software framework. We provide to enable you to build your customized edge solutions, leveraging kubernetes, while abstracting underlying hardware and network complexity for 5g.

A

Some of the highlights with this framework is that it uses kubernetes engine certified by cncf and offers additional optimization for ai and media workloads, helps utilize hardware, security capabilities, etc.

A

Smartage open provides these set of building blocks that enables you to optimize your solutions for edge such as high performance data, plane, constructs accelerators for ai and wireless networks, zero trust, security, multi-access drainage, constructs, telemetry, monitoring, etc, which formed the crucial components for enabling onandrick an easy to consume model, for example, could also be for someone who wants to deploy private 5g can utilize private wireless experience kit from the catalog of experience kits and as is and scale from there in terms of building blocks.

A

The left side here lists out different capabilities available through smartage, open through cloud native micro services model and aligning with different 5g standards. Multitude of these capabilities are being explored for rick, in collaboration with red hat. We are looking at utilizing building blocks on the right to enhance the rick to operate under certain sla.

A

Some of the aspects we are looking at are having hardware aware resource management with kubernetes constructs such as node feature discovery, topology management, core planning etc, which are really impactful for random workloads, utilizing sriov and various cni's. We are looking at fine-tuning high-performance data plane for rick utilizing open. We know based influencing for rand intelligence and accepts custom hardware telemetry to ensure real-time, slash within rig, etc. Are some of the items that we are enabling.

A

An example of a reference solution demonstrating open source sdram near real time, rick with ai-based connection management x-app with inferencing latency, less than 10 milliseconds is available for you to download via intel developer catalog with that I'll pass it on to mike to share further details on rick, enabling.

B

Thank you, sun coo and thank you hasn't from intel hi everyone. My name is michael recchia from red hat. I am a global telco solutions. Architect and today I would like to talk about application of the intel building blocks.

B

We'd like to talk about applying the building building blocks in three areas. Building blocks are applied to ocp proper, that is the openshift container platform itself.

B

The building blocks are applied to a oran component or a lran platform, namely the ram intelligent controller and, in particular, the software modules that are major components of the rick and then we'd like to talk about the rick use cases and how the building blocks can be used to optimize the use cases themselves or the end-to-end cellular use case, and so the output of course, of all. This are optimized ocp, optimized, rick and optimized use cases in general.

B

Again, looking at the different categories for the study, the first one being ocp or openshift container platform proper, we'll be looking at. How can the building blocks be applied to the native internal capabilities of ocp?

B

What are the things that are important from a performance perspective, a resource, consumption perspective and the networking perspective, and so those things that are part of ocp, it's sort of the native components of ocp will be looked at and the building blocks would be applied where they could be applied.

B

The new real-time rick itself is composed of many software modules, we'll look at the architecture of the rick in a moment, but there are some very important software modules, in particular in support of x apps. The e2 interface itself is a very critical interface.

B

So can we apply the building blocks to the e2 client, for example, on the ocudu?

B

um Can we apply the building blocks to the ric processes associated with e2, for example, the e2 termination and e2 manager and x-app e2 subscription manager? And of course there are other ric modules like the rmr, the recommended router, the data bus and so on.

B

Then a particular interest is putting it all together in an end use case, the use case proper. We call it, and mainly that would be what is the cellular use case of interest, we'll probably be looking at proactive maintenance type use cases where there is an anomaly detection in the ran, followed by traffic, steering to move the ues away from the anomaly.

B

So we'll look at that use case initially and we're going to try to move study a couple of areas.

B

One is the network layer flow, for example, the packet flow packet loss, throughput and latency, and the other one being uh the impact on objects like the sdn controller, the wreck modules, the ocp modules, the network interfaces and so on.

B

Now I mentioned the rick a few times, and I mentioned the software modules involved and you can see this is the sort of an architecture view of the near real time rick and you can see several different modules, and so the idea here would be. Can we apply the building blocks to these different modules, to gain some sort of value or to optimize them in some way? So, for example, can we use the building blocks on the message?

B

Bus as an example, and another thing we're looking at is potentially using red hat middleware as sort of replacement parts for some of these brick components, for example using amq interconnect as a component of the message, bus.

B

Again, starting out the use cases we're starting out with tend to be the proactive maintenance, telco use cases um so that that involves anomaly detection up front with traffic steering to move away from the anomaly, for example, interference or congestion.

B

We will be starting with a oh nse provided near real-time wreck and some x apps that are provided by the by the scenario turmeric and then over time, we'll be looking at potentially using some of our tech partner ricks as part of the study and some of the prerequisites for the testing include a far edge footprint, for example, using an open edge, a nokia, open, edge, form factor, a five server form factor that can be deployed just about anywhere externally or internally.

B

That's great for mobile applications. If a forage footprint is not available, we'll start with a general purpose machine like an hp or a dell.

B

We intended to use the o nsce release initially in ocp, 4.10 and, of course, rel and then we're starting out in the lab, with e2 sim, eventually migrating to actual ocudu, with actual e2 clients on the ocd.

B

So that's how we're starting out so the lab initially looks like this. We have the g note, b, emulation with keys t2 simulation on the left. We have in the middle representation of the edge data center, the orange block there.

B

You can see ocp there with the building blocks associated with ocp, the near real-time rick running on ocp and then the x-apps.

A

B

Are part of the use case uh on top of all that infrastructure and then to the right we're just blowing it up a little bit and then, as we migrate over time, we're going to have an actual g note b in the lab again ocuodu with e2 clients that will support the use cases of interest for telcos, and that's really the only change between the previous picture and this picture again. The near-term record is in the middle running on ocp.

B

We can see some of the more important modules there like the eat, to terminate or need to manager, and we can see the building blocks are distributed throughout the use case, including on the e2 clients, on the near real-time rick, on ocp and so on.

B

One of the things we're doing with intel is we're working on some standards for certain functionality. For example, this one has to do with communicating service attributes from the network layer to the cloud layer with application of the building blocks uh to each of the layers.

B

uh A particular interest here is network slicing, where we have multiple subnets and we want to apply the building blocks to each subnet and test this on a particular idea, which is to be able to meet the sla the end to end sla requirements for each on each of the slicing slice subnets. So application of the building blocks to each of the network slide subnets and each of the components within subnet uh those components we talked about earlier, like ocp and the rick, and so on.

B

Another um function that we're working on to standardize is this concept of mapping microservices on the user plane two particular x, apps running on the o-ring rick and basically the idea here is that you want to optimize the ran for the particular services that are running on the user plane. So if I've got edge services on the mac, um for example, gaming, visual virtual reality rendering I want to make sure that the ran is optimized for that particular capability.

B

And so I communicate that from the mac to the ric and the particular x apps associated with optimizing for that particular service are then invoked and then executed. And then you again, you can see the intent.

A

B

Is to execute the same capability, but also apply the building blocks as we're doing it.

B

And that concludes my portion of the talk. So thank you very much.