 Okay. Oh, there's a microphone. Good to go? Yes. Okay, perfect. Thank you very much everybody for coming in today. My name is Mojab Bari. I am part of the infrastructure, a line of business at ARM. I lead mostly our initiatives in VRAN and OpenRAN. So mostly telco background and all that. So today's discussion is something we have started recently with the help of our friends in Wind River and Starling X community. And that's looking at how VRAN can run efficiently on ARM. These containerized and virtualized solutions on the ARM ecosystem. So a bit of background. Well, this is the motto of ARM. We truly believe that the future is being built on ARM. Even the present is being built on ARM. If you look at the numbers, there are around 250 billion chips based on ARM. That's 30, 40 chip per person in this world. Just last year, there was 30 billion chip based on ARM manufactured. There are 650 plus companies that are using ARM chips in their designs. So it's already everywhere. And in your water, in your scotch, everywhere. And we believe that estimates are that around 70% of the world are somehow using something that has ARM. The other 30% usually they are still babies, so they can't use. This shows the footprint. Of course, till now, mostly ARM was known for being ubiquitous in cell phones, sensors, etc. But that's not the case anymore. In cases like telco, ARM has been there for years. In the traditional vendors of the telco, these are Ericsson's, Nokia's, Huawei's of the world, ARM already has a strong footprint around 80% of the solutions out there. The classic RAM or whatever you call them, traditional RAM, was already based on ARM. But 5G is bringing its own challenges. So right now, there is almost 1 billion connections based on 5G. But it's expected that it's growing to 5 billion because a lot of countries are just deploying. India just started, for example, compared to East Asia that, for example, South Korea has, I think, 80% of the subscriber move to 5G. But in US and other places, there's still a long way to go. Besides that, 5G is much more energy-hungry. This is not technology being inefficient. It's just there's more bandwidth, there's more data to be pushed through. So each tower becomes more powerful, and that means more energy-hungry. And energy is becoming more and more an important one, not just because Russia decided to attack Ukraine. Every day, it's becoming more and more expensive to create, to generate energy. Almost 40% of optics of operators are already going to energy costs. That's why there was a recent poll by GSMA, that's the Association of Operators, that almost 70, 80% of the operators top concern was energy consumption. So what is driving the next generation of wireless infrastructure? One of them is the compute efficiency, because one of the most power-hungry sections of this whole equipment of the 5G is the silicon, the silicon's power consumption. And so compute efficiency is quite important for the industry. This goes for digital parts, like CPUs, and even analog parts, which is the radio side. That's a separate nightmare. Almost 80% of the power is consumed by the radios. They are very inefficient, something around 20-30% efficiency, sometimes even 10%. There is ecosystem support. This is the open-run movement. Operators want more and more partners in this industry. And finally, cloudification. The idea of Iran, which was suggested years ago, has found true champions. If you talk to leading operators, mostly European, they believe 6G will be just Iran. There is no DSPs in that. Everything should be fully cloudified. And where does this leave ARM? ARM four or five years ago started a line which is called ARM Neoverse. This is a modified version of ARM technology that can scale to many cores, and each core will be much more powerful. So this line is targeting not only beyond the cell phones, it goes to infrastructure. So cloud providers, similar like AWS, and Azures, and etc. And they have built chips based on this. If you have heard of Graviton 2, there is HPCs. Fugaku, which until recently was the number one supercomputer in the world, is based on ARM Neoverse. The 5G carriers infrastructure, which we are talking here, and of course Edge. There has been a long pass here. For the ARM Neoverse, there was a lot of announcement initially for the chips. There was operators standing behind ARM technology like Dish that said eventually they want to run everything on AWS Graviton 2 based on ARM. They built accelerator card based on ARM, Qualcomm partnered with HP. HP built chips based on ARM, silicon. And recently, operators have started making announcements. I'll come to entity documents, soft bank announcements. And recently, we have joined Open Infra Foundation and Starling X. It's not final finalized, but I think it's in the PO stage and I don't know. Somebody put a logo over there and etc. So we are almost there. And which is thanks to initiatives from Windriver and Starling X community. We are really happy on this. I'll talk more about the partnership. I mentioned about the entity DoComo. Recently, they are the Japanese top-doc operator. And recently, they did something with NEC that provides their core network. They moved it to an AWS instance. And this is from their press release that they saw 72% power reduction. Just from moving to some legacy Intel solution to an AWS Graviton 2, which is Neoverse based. This is something like 3.6 times increase in efficiency. Again, SoftBank, another operator in Japan, a few days ago in Computex, they made an announcement with NVIDIA that they want to move their solutions to a centralized 5G RAM. So the SoftBank's vision is to have mini databases across the nation that these databases are both working for RAM and anything else that is running over there. An inch like I don't know Metaverse. Metaverse time is passed. Generative AI or whatever is the buzz. And we see more and more this that if a country can handle centralized RAM, centralized RAM really needs access network fibers. So it happens easily in Japan and Korea. Everything is fiber. U.S. a bit harder because we don't have that much fiber. But if a country has a good fit for centralized RAM, this kind of solution would be interesting because it opens the path to operators to really get that growth they always wanted. They always complain that, hey, we do all the work of infrastructure and then Uber comes and makes the money, not us. This helps them make data centers and host applications and create revenues for them. So what is the arm advantage in the VRAM? We have done a lot of experiments with partners, modeling, simulations, actual running and measuring. And we see depending on how you run it, what is the something around two to four times you get improvement in power efficiency. That means something, your power drops like 50 to 75%. We don't know what you use, how optimized it is. And this is bare metal or containerized. It doesn't change much. And this makes ARM and Starling X a match made in heaven because what we love about Starling X, besides everything that operators love and they go and deploy, Starling X or its commercial version which is Wind River Studio, besides reliability, latency, edge security, all these that are perfect and not platform specific. It's the small footprint. Starling X was written to be really low footprint because of possibly the heritage that it has. And that makes it perfect because we have some low power consuming core here in the ARM Neoverse and that can host the Wind River, sorry, Starling X. Perfect. You have squeezed every bit of juice out of the system this way. These slides I've stolen them from BavaxDec. So thanks a lot. This is the general architecture of Starling X. The previous session was talking about how the open stack runs on that. So all this is the Starling X orchestration, the service, etc. runs on the Linux, of course, the real-time low latency or real-time Linux that runs on ARM and that's the plan. And how it works in the data, in the CUDU story. So if you're familiar with the Oran-Viran architecture, they broke the base station site, the BBU, which was at the base station at the site. It was usually cabinets of embedded computing. And they made it a distributed unit at a centralized unit. The central unit is some sort of mini centralized section that multiple sites connect over there. That will have its own, of course, cloudification. And the cell site is replaced by CUT servers at the moment, mostly X86. But what we are working towards is that ARM servers would be used. And the whole workloads are orchestrated and running on Starling X and Winterverse Studio, usually single instance of that. So something a bit compact. Because it's just managing one server or two servers. A bit more about the newverse until I can connect these together and how it will run. So newverse is a family of three series, technically. On the left you see the V-Series. These are the most performant chips. So they were designed with getting as much performance as possible without caring about how much power it consumes. E-Series is the opposite. And it is mostly focusing on reducing the power as much as possible. It's good for possibly small sales, for example, that you care about the power consumption or cost. V-Series is good for hyperscalers. Of course, even V-Series is more efficient than anything in X86, but they are hungry for performance. N-Series, which is more fit for 5G, is a balance between both. Both mix of power and efficiency. And on each one of these, there has been chips that are in the market, like N1, which was the first generation that came out, has the AWS Graviton 2 and NPR Ultra. We will talk more about that. N2 is Marvel's Octane 10 series. V1 is AWS Graviton 3, and the NVIDIA Grace, which recently made a lot of noises and softband ones to use, that is a V2 series. And of course, the rest of them are coming. In the E-Series, you see HQ, that's a California startup, that they are targeting small-cell deployments. So the chips that we have for servers, the cut servers, of course, there is AWS. AWS has something called Outpost, that it's a server that you put on cell site, or in your factory for edge. It's managed by AWS, but it's something local, if that's what you like. NPR is a California startup that has made a lot of chips based on ARM. There's NPR Ultra, Ultra Max, and there's another one coming called NPR 1. Marvel has a set of chips, Octane 10 Fusion and Octane 10, and eventually the NVIDIA Grace CPU or Grace Super Chip, which is 144 core. These are the chips that servers can be built. NPR has a lot of servers based on this. There's a set of ODMs that have built one. AWS builds its own servers. NVIDIA servers are coming. They were showcased in Computex. Marvel is a bit more complicated if somebody was interested, I can explain that. The ARM ecosystem, so a few years ago when we started this, of course we had a gap of 10 years to close with our friends on the Intel. So we started from private network companies onboarding small players to show hey, this is feasible, and we started growing from there. Now we have an ecosystem of carrier-grade solutions. These include server manufacturers like HPE and Supermicro. Containerization solutions like upcoming Wind River Studio based on the Starlink export that is happening. We have RAN Layer 1 vendors, players like Nokia, Fujitsu and NEC as RAN vendors on the open RAN side. And it grows by day. It is becoming something that two years ago when we talked to people, everyone says okay, pay me 10 million to do a port to ARM. And now it happens without even us knowing sometimes we see the announcement. The main reason is that there has been a lot of education in the market that with an x86 solution getting to the CAPEX-OPEX targets that operators have in mind is really hard. No matter how much you discount, the CAPEX-OPEX is always there. And ARM is seen as something that gets closer on open RAN or VRAN to a traditional RAN solution in terms of power efficiency, cost, et cetera. So this is the POC that we are working with the team. Technically we are using cut servers. These are either Supermicro or HPE. And based on ampere chipsets, these ampere chipsets usually we are using AT core here. They can both be 64 or even less. One beauty of ampere is that if you don't use the cores, each core consumes something like 61 milliwatts, almost nothing. So you don't have to use the whole thing to get to really low workloads. Of course the CAPEX part is always there. So the idea is that we will run. We have partners. I haven't put them here. We can talk about that a bit more officially. But they have ported their CUDU and now they are trying to integrate this with the Stalingex on ARM and get to a POC that can be shown to operators. Of course there is productization stage of that which has its own story. When it comes to running Stalingex on ARM, so of course the overall idea is to run everything on ARM64. For this we have to create build systems, move this LAT tool to ARM, make the ISO images over there. There are a lot of package work. We have to port source code, a lot of maybe more than 80. Something like 1400 packages needs to be rebuilt so they don't have to be ported, but this is also work. And so on container image, rebuild and feature adjustments. And more than that, we have to support the community with providing servers and packages and mirrors, et cetera. And of course there's various ways that Stalingex is deployed. Right now all in one simplex is the first target because that's most common in the DU deployments, but of course it won't stop there because although Stalingex is really good for telco, we know that it has much more use cases in edge and et cetera, so we are not limiting to what telco needs. We will go the whole game. So once we have done so far, it is a POC. We have created a native build system, we have rebuilt some, we have ported some packages at POC level, means that there are some workarounds and hacks that are over there just to get to this. In Mobile War Congress, we did a demo at Armbooth thanks to everybody that helped over there. And we don't have a video of that, but these are some slides out of that. You see the Stalingex here is running on an ampere instance. And it has its own parts. You see this is the nodes that are on Arm64 and many, many parts over there. And if somebody was interested, we can also go into a more detailed demo, not here, but somewhere else. Bob, I need Bob Axel on that. There is a roadmap ahead of, ahead to, well, as mentioned, the packages are then are ported in POC level. We are working on making them at product level. Some servers are going to be sent to the community, so it becomes part of the CICD of the future generations. And the rest of the items you see here. The work has been done till now in the partnership between Arm Engineering and Wind River Engineering and some Stalingex community. We are quite grateful for that. We are going to do more and more of the heavy lifting because of to take the team a little bit time to get familiar with the code base, et cetera. So it is a joint effort that is ongoing. I have two slides that are not Stalingex. I'm sorry, but since Arm Team is also involved in the Kata containers, they asked me to, as I mentioned this. So if you're not... Kata containers, of course, in another project in the Open Infra Foundation. It is something that gives the performance of containers, but security of virtual machines. It is heavily supported in China and finance by do these guys deploy Kata containers significantly. So what Arm has done is that we have made sure Arm is a Class 1 citizen in this project. A lot has been done, and we are just making sure whatever next version of the Kata Comes, Kata 3.0 is coming soon is fully supported on Arm 2. So this is an example that this was... The same team that was working on Kata containers now is owning the Stalingex port. So same way that they moved from scratch to moving Kata Arm as a Class 1 citizen in Staling... In the Kata, the Stalingex Pass is the same story. And that's a lot of thank yous. Thank you. Don't know if there is any questions. Yes, there is a question. This is compared to Ice Lake, Xeon Ice Lake. Usually a 32-core version of that is used in telco deployments. And so if you look at... We have a measure called megabit per second per watt. So how much data you are transmitting over the air to your users, actual throughput, per wattage that the server consumes. Based on that wattage, Arm is sometimes two to four times more efficient. The whole faceband, so the DU section. So that's layer one, layer two on the server with the NICs, accelerators, everything. SAFA Rapid, which is the new generation, closes the gap a little bit, but not that much. If you are interested, we can go into depth of depth discussion. I'm interested in performance. Depends, for example, the model that mostly we use is 4 by 400 megahertz. The frequency doesn't change for the DU because it's an RU problem, mostly. But even if you model the massive MIMO, usually the gain stays the same because the number of the cells change when you change the layers or the throughput or the bandwidth. But the relative number usually stays the same no matter if you're using a 20 megahertz, 2 by 2, or a massive MIMO, 100 megahertz. Yes, yes, definitely. Technically we try to be... We have contracted radices, if you know, this is a layer two, three vendor, to run the same work stack on R versus 686 to show exactly all staying the same what would be the gain. It's not that different. I mean, if you look, silicon has a measure called speckhint, if you have heard. It's like a general test of performance. And it mimics more various loads that a CPU can run from data center, database reading, memory reading, file access, computing, I don't know, mathematics, et cetera. Even if you compare the speckhint of an ARM server versus 686, you get to the same numbers. So what we learned after two years of testing is that VRAM loads are not that different from a CPU's point of view in terms of efficiency. So same numbers usually map that, for example. If you look at the material that AWS, for example, publishes about the efficiency of their arm instances, same numbers usually match over there too, depending on the load. One part that is quite different is if you want to do a look-aside layer one. So look-aside layer one is a layer one that runs on the CPU instead of some accelerator. And on that, there is some differences in technology of these two. So, but still, because of the sheer efficiency of ARM that result also very close, is very close. Yes, yes. AVX is a technology that Intel has that goes for 512 vectors. ARM's technology, which is called Neon or SV, goes to 128 or 256 bits. So you have smaller vectors. But the difference is that on an Intel server, sometimes you have 32 instances of AVX. But on ARM, this ampere one, you have 18 instances of 128. Sorry? 8-0. 80 cores. 80. So 80 cores that each one of them processes 128 bit, eventually triumphs 32 cores that support 512. Anything else? Okay. Thank you very much again for your time. Feel free to come to me.