In The Arena by TechArena - Bringing OpenSource to the RAN with Canonical

Episode Date: February 28, 2023

TechArena host Allyson Klein chats with Canonical’s Arno van Huyssteen and Wajeeha Hamid about the state of opensource for the network and their new solutions for RAN implementations.

Welcome to the Tech Arena, featuring authentic discussions between tech's leading innovators and our host, Alison Klein. Now let's step into the arena. Welcome to the Tech Arena. My name is Alison Klein. And today I'm delighted to be joined by Wajihar Hamid and Arno van Huisdien from Canonical. Welcome to the program, Arno and Wajihar. Thank you for the invite. Thank you for the invite. So why don't we just start with an introduction of, I think everybody knows Canonical, but it's the first time you've been on the tech arena and your relative roles at the company. Hi, my name is Arnaud van Hestien. I lead Telco for Canonical.

Canonical as a company is really the company behind Ubuntu, which is more famous, I would say, or more well-known. And our entrant into the telco market is fairly recent, about six years now. But we're making good strides in terms of helping service providers adopt open-source technologies. So you have described Canonical very well, so I would go with just my introduction.

So I'm Zia Hamid, currently working as a product manager and leading the efforts towards Telco strategies or roadmap and targeting especially open source man. So I have been in Telco area for around four years now and enjoying the advancement we have on a daily basis. So I'm glad that you brought up Telco. You know, Canonical has a long history of open source innovation, and Ubuntu has been a topic and a product that has been used for a long time across a lot of environments. But can you describe your specific leadership in the network arena and how it relates to the broader purview of Canonical? Sure. I would say Canonical as a company focuses,

as you said, heavily on open source technologies. And as a community member, open source community member, we pride ourselves on the fact that we don't take open sources value, try to repackage it and then sell it for profit. And we do offer support services in a number of different product SKUs. But our effort at Canonical, all of our investments, all of our engineering

teams focus on the ability for service providers to adopt technologies like OpenStack and Kubernetes and other open source technologies in production stacks with the right types of security and automation and the types of support you would need in a production environment. And for us, that's very important, right? Our company started with, obviously, Ubuntu. Everyone knows it. It is the most adopted Linux in the world.

And the types of things we focus on with Ubuntu on the enablement side is really working with silicon partners and customers to try and map out what does it look like when a telco really wants to run all open source. And that ambition has led us down the path of investing in things like open source security, open source applications, bring things like real-time kernel for radio use within Telco, infrastructure as code and other automation techniques to the table, I would say. I just wanted to add one point here is that open source, we have always been very supportive

to open source and the communities. So like, for example, we are part of the community for our every product. We don't have proprietary solutions out there, canonical leverage to provide open source to the market. And that is what Telcos and other industries need. So they need open source standards. And the value we are giving there is provisioning support for open source. So we always wanted open source to shine.

And we believe that making these efforts, I guess we can catalyze the open source communities. Now you talk about the journey that certain customers take towards full open source. When you think about that, there is some complexity in moving to open source. What is the primary value proposition for telcos to take that on? And how have you seen the trend as we've moved through the stratification of networks choose to go down this path? Well, I mean, telcos, and standards and the way that telco networks or mobile service providers have been architected over the last two decades. But it is essentially that the evolution of the service requires a certain level of technological

insights into how things get done. Are they efficient? Currently, big concerns around energy efficiencies are coming up. But in that evolution, in that evolution between the 2G, 3G, 4G, 5G, and potentially 6G fairly soon, it is important for those operators really to evaluate whether what they've done in the past really serves them still today, right? And in that, I would say, evaluation phase, they've come to the conclusion that in certain aspects of the design, open source can feature. I distinctly remember in 2004, 2005, when Ubuntu was just in its infancy, I was working for an operator and I approached one of the architect leads saying we should use Linux or Unix at that time.

And they asked me, who do I call if Linux breaks? I know who to call when Windows breaks, but who do I call when this Linux system goes down? So for me, that set a trend in terms of not having had the kinds of capabilities and support mechanisms. And I would say companies stand behind an open source approach. And over the last, I would say, decade mostly, that has changed, right? Etsy introduced ISG NFV to evolve architectures within them, the way you can deploy applications. Big companies who had proprietary applications changed the way that they approached the manufacturer or the development of their applications to run on more COTS hardware. And you see that evolution has been ongoing for a while.

Now, you were promised, like telcos were promised, a whole lot of OPEX and CAPEX savings when that evolution started. Unfortunately, not all of those savings were really realized along the way. So for us, it's important that when we propose the use of open source in a telco context, that it is not only capable, so feature parity and the ability for customers to stand up secure automated infra or applications using an open source method, but that it actually brings the economies of scale required to run services at better price points and improve the margin for the end user. It's not easy because most telcos still have internal teams and they're usually

very traditionalist in their approach. So organizational change and the adoption of technology while they're dealing with the types of technologies and services they offer is a big change for any operator. So we're there to help them kind of look at this evolution path and decide for themselves at which stage they want to consume open source and at what, it's not. And it's not a greenfield approach. It's more where within my brownfield deployment can I use technology to my advantage and at the right cost point, right? When you look at the total opportunity of cloudification, one of the things that was sold as a benefit, and this is true across all cloud environments, is sought as a benefit is true automated orchestration of workloads. I just finished a series on cloud computing, and there's still struggles in cloud to achieve that

one pane of glass automated orchestration of all workloads across a multi-cloud environment. We're making this even a bigger leap forward with network from core to edge. Where are we with open source delivery of automated orchestration and how is the industry working together to ensure that that is a solution of trust for telcos to rely on? So that's an interesting situation and that has always been. I guess we have talked a lot about the workloads

and the workloads deployment, the cloudification of those workloads, but we always forget one point and you discussed it, that telcos are not alone. So they have like integration requirements, they have requirements for their lifecycle management, they have requirements for their monitoring and scaling. So I guess this is the point where service orchestration comes into play

and we have like multiple tools over that open source menu and different tools. But they are at the top of the network stacks and I guess that is really necessary for the overall service orchestration of the network stacks and the workloads. of customers that they're serving with edge deployments. Do you see any trends in edge and how different industries are tapping the edge of the network to deliver new capabilities for their business? So our main telco customers who look at edge and edge really is something else for anyone you're talking to. So everyone thinks about edge in a different way.

So we like calling it highly distributed compute pools. And those bare metal clouds or those clouds with certain capacities really sit further out in their network. Now, whether we're talking about clusters of compute in an enterprise being served to those enterprises by telco or whether it is for networking use within the telco certain common trends keep emerging right is it infrastructure as code is it automated is it zero touch provision is it secure does it stand up on its own can i

lifecycle manage it can i change it can i reprovision it these types of things all revolve around similar topics, right? So, and that main topic there is automation, ease of use, lifecycle management. And that's really where Canonical helps customers understand that whether you're modeling and automating infrastructure for use in your data center, or whether you do it for a thousand cell tower sites or a hundred thousand cell tower sites, it's very important to choose a tool chain, a mechanism, a means to abstract complexity and across your data centers and your edge, not choose one for data center and one for edge. Customers have very many interesting use cases for edge, in the in the networking side we see things like 5g cups evolve where the upf so the user plane function would sit on an edge capable device or devices in the open rand space we see things like distributed units at cell tower sites

and then when you move up the stack you you see use cases like AR VR, in which a gaming company wants a slice of metal with GPUs and CPUs across 1000 cell tower sites as a commodity to be able to run augmented reality gaming at the edge. So for us in all of those use cases, the things that we're trying to help the customer with is understand what it takes to abstract that complexity and to be able to manage it and automate it to the point where it is essentially an API-driven call to get additional metal or services deployed. And that's really what we're working with customers on today. When you look at what you deliver to the market, you are known for Ubuntu primarily, but you also have Charmed OSM. Can you tell me about that platform and how it relates to the portability of NFVs and delivery of the edge and all the topics that we've been talking about?

Yeah, sure. So as I touched this point before, that we need the orchestration layer and the service orchestration, the variables orchestration, and even the infrastructure orchestration. So in that part, open source manual comes in, and it is basically related with NFE portability you asked about. It's an open source implementation of Etsy that is a European standard institute. And it's fully aligned with NFE information models. Like for OSM, like for the workloads deployment, we are using the Etsy specifications

to deploy those workloads. So it is the product which is completely aligned with the telecommunication standards and which is the basic need the telecommunication standards and which is the basic need for telecommunication right now, like to follow the standardization and being open source and to have the support for that. So a charmed OSM is basically an upstream OSM distribution delivered by Canonical. So we just improved the stability of OSM deployment and provides telcos with a production-grade platform. But we are fully aligned with Upstream, supporting open

source there. There is nothing different between the Upstream OSM and the Charmed OSM, other than some production-grade features and the support for that. And can I just add to this? I think it's important to understand what OSM is trying to achieve. Etsy defined a generic approach to virtual network function management and virtual network function orchestration, right? And that capability really plays in on one of the economic benefits that was supposed to be at the fingertips of operators from day one. Yet each network equipment provider created their own version of that virtual network function orchestration and a BNFM and a VO, right? Now, Etsy tries to ensure that there is data structures in place, that there is a common way for you to onboard

independently of the type of workload you're trying to onboard for Telco in a set way into OSM and be able to use OSM to target any substrate. So whether it is OpenStack or Kubernetes or Bare Metal Clouds or AWS tomorrow, that gives you the ability to go and deploy those workloads.

Now, standing them up is important. Making sure they're functional is very important. But lifecycle managing them is also as important. And stitching them together into network services is very important. So for us, the inherent in making OSM a success is to give more power to end users, to service providers, to be able to have a generic approach to the orchestration capabilities that they so dearly need to be able to ensure they don't have to run multiple teams with understandings of different incoming products to be able to do the same function to orchestrate workloads. Now, you've seen a lot of progress

in the space of software development for cloud-native networks. Where do you see the industry going over the next two years in terms of addressing new capabilities that are required for full adoption and migration to cloud native? And is there any particular area where you think the industry really needs to coalesce around innovation? Or have we already really developed the baseline and it's really just about tuning for broad scale adoption? I don't think we're actually at the point where we can say there's a baseline which everyone will adopt eventually. I mean, containerization of microservice architectures in software development is a

fairly new phenomena in the sense that we've been developing for a very long time and all of a sudden it was cool and okay to now take an application, a monolithic application, split it up into many different pieces, because you would then be able to do special things like scaling. So I think that evolution path for very many telco functions, especially network equipment providers who used to build monolithic functions on appliances in a proprietary way, is still underway for many. A lot of these companies have made big strides in terms of adopting a future in which containers

would play right. But I think we still need a little bit more focus on the types of technologies that they still embed and the types of mistakes they still make in terms of making those choices during the microservice architecture design phase of that piece of software. And it's not easy to do. If you think about just in a 4G network, I'm not even talking about 5G functions yet, just in a 4G network, a P-gateway would have 200 different functions inside that piece of software. So it's not easy to do and not everything will lean itself towards microservices. But what we're doing at Canonical is we're enabling the development communities, specialized tools and mechanisms and base container images that will really get them to think a little

bit differently when they're designing containers, for instance. And yes, containers is usually generally associated with Docker and Kubernetes, but NetEase is only really needed when you need to orchestrate containers. So for us, the ability to run a container, even on bare metal with the right hardware capability or things like OVS offloading to SmartNICs, that is really where we focus our attention in the software stack. And the types of tools we make available now to developers even to to microsoft and and other partners in terms of when you have to define what you need in terms of packages within a container when your function needs to

run how lean can that be we we develop specialized tools like we call it chisel internally, but it allows you to essentially cut out pieces of packages you would need inside your container to make your container the developer the choice to run in different packaging formats, in different container formats, in more Linux container formats, and whatever the need is of the application. So it's very important to ensure that we maintain our community developer ecosystem. I just wanted to add one thing here that like, if we take a step back from here and talk about like, as you asked for the next two years with the software development and all. So I guess we have enough advancements right now in the course for integrators and, you know, BNF vendors to partners with system integrators, operators to partners with system integrators to put that all

together and then offer to the telcos so they would be really, you know, compatible in adopting on these solutions. That's a really good point. I can't wait to see the innovation but let's start with mwc we're at mwc i'm sure that canonical is featuring some cool technology at mwc what are you featuring and and what is new coming from canonical at this important event well it's i think every mwc has a couple of buzzwords flying around about things that are cool and everyone's doing it. Everyone's saying they're doing it, but then essentially the technology is not there. In this case, I think mobile private networks is a very key topic or especially what the

telcos are looking at in terms of serving enterprise and other types of things. Canonical, in our journey in telco, has enabled more networking capabilities, and we will show this off at MWC as well, in that we've recently launched Ubuntu with Realtime Kernel for the telco radio market, specifically working with partners like Nvidia and Intel. At MWC, we're going to be showing off Ubuntu with real-time kernel and a snap-confined Kubernetes called MicroKits that will run self-instantiated DU devices on edge and to centrally manage those and have the device onboarding applications, all of the edgy type

stuff that you usually struggle with taking care of by automation and software. It's a co-innovation with a partner of ours, SpectroCloud, and we are very proud of the security mechanisms, the hardening, and the ability to now run actual open RAN functions on a single unit device without any downtime, even during lifecycle management like upgrades of the Kubernetes underneath, right? So those type of things are very important to us. We're also showing all the deployment aspects that operators care about when having deployed,

for instance, a DU, a distributed unit for ADO, and how the automation takes care of the tenant space orchestration to tie that DU back into a CU, into a core on AWS in this case, and showing you the capabilities that are there and at the fingertips of operators today, all through open source operator-driven methods and techniques. So we're really happy to see customers come and have a look at that demo. I don't know if you can think of anything else we're showing that's interesting. No, I guess you have covered all the points. So either you went to real time kernel thing, but the RAN story, I guess that

would be really demanding at this inter-BC because everyone would be talking about Edge, you know, private mobile networks. So let's see. I'm excited. I can't wait to see the RAN technology from across the industry and you better believe that I'm going to be stopping by your booth to check out your technology. For folks who are listening online, I'm sure that we've piqued their interest. If they want to engage at MWC, where are you going to be at? And if they want to engage online, where would you send them to find out more information about Canonical Solutions?

Well, everyone, customers and partners are welcome to come and see us at our executive meeting room. I would say the easiest way to do this is to go to ubuntu.com slash telco and reach out to us from there. We'll pick those up and set some time with you and your partners and customers. Sure. And we would be happy to connect on if anyone has any concern regarding anything. So happy to help there. Fantastic. Thank you so much for your time, both of you today. It was great catching up with you and we'd love to have you back on the show in the future. Thank you. Thanks, Alison.

It was nice to speak. Thanks for joining The Tech Arena. Subscribe and engage at our website, thetecharena.net. All content is copyright by The Tech Arena. Subscribe and engage at our website, thetecharena.net. All content is copyright by the Tech Arena.