Guy Daniels, TelecomTV (00:12):
Hello, you're watching TelecomTV. I'm Guy Daniels, and in today's programme we look at why voice is back at the centre of the transformation debate. We ask which telco cloud concerns are misunderstood and which are still valid and how the move to software-driven networks is changing the role of partnerships across the industry. And joining me today are Manish Singh, who is business development leader, Telco Cloud at AWS, and Ram Ramanathan, who is VP of Product, AI, Automation and Cloud with Ribbon Communications. Well, hello to both of you and very good to see you. Now, we know many operators are excited about AI, but AI-native services depend on flexible software-driven infrastructure. So the question I'd like to ask, and Ram, if I can start with you, can organisations realistically become AI-native whilst keeping critical communications workloads rooted in traditional architectures?

Ram Ramanathan, Ribbon Communications (01:18):
No, it's a great question, and we do get this question all the time from our carrier partners. When you look at AI-native, what does it really mean? There is an AI-native play from a monetisation perspective for carriers, which means that using edge AI and core AI services, carriers can monetise and provide services to the end customers, whether it's end users or businesses, they can offer services and charge for it. So that is one side of the AI play. The other side of the AI play is how do they keep their networks, which are becoming more complex by the day, how do they keep their networks up and running with automation, with AIOps, and cut down on unnecessary expenses, OpEx and CapEx, and so forth? So there is a monetisation side from a services perspective. There is an automation side from a running the network perspective.

(02:12):
So that is what, from my perspective, AI-native networks mean. Now, when you look at existing networks, some of them are physical networks, some of them virtual and moving to cloud-native networks, whether in public cloud or private cloud, it's in different variations in their journey, in their respective journeys. So when you look at the physical or virtual networks, they're not very flexible to offer on-demand services, and AI services are by nature on demand. It needs to scale up, scale down, create new services, go away when not needed, and save on bandwidth and compute and so forth. So on-demand, flexible, fluid nature of these services are not suited for the existing physical or virtual networks. And in the same token, when you look at the automation side of things to keep your network up and running, these complex networks, the physical and virtual networks are not suited for full automation.

(03:11):
You can do certain types of automation with the existing networks. When you talk about full automation in terms of the life cycle all the way from design, development, deployment, and then operating the network seamlessly, you do need cloud-native architectures to get the full bang for the buck there. So both from a services perspective and from an automation perspective, we as an industry need to evolve from physical virtual infrastructures towards cloud-native microservices architecture to keep the network fluid and to offer the services that we want to offer and generate revenue.

Guy Daniels, TelecomTV (03:45):
Great. Thanks very much, Ram. And Manish, let's get your view on this as well as to the problems of becoming AI-native when you've got these workloads on traditional architectures.

Manish Singh, AWS (03:56):
Yeah, so AI-native as a term or infrastructure, you can't have AI-native infrastructure that isn't software-native. Traditionally, all the architectures that we are used to from a critical comm workloads perspective have been vertical and they have not been software-native. So from that perspective, as Ram mentioned about AI thriving on elasticity, on data gravity, as well as fast iteration of running different iterations of AI interactions from an agentic or agentic workloads perspective, it's totally opposite of where we are sitting at the moment with the vertical stacks. But I think there is one important aspect that we overlook or don't focus on too much is about the data layer of all this. What happens to the data in terms of telemetry, in terms of what happens to the customer data, operational signals or accessible or governed data, where are you putting it, et cetera.

(05:04):
From that perspective, I think an infrastructure that allows you to put AI natively on top and interact with that data is so important. So I think operators don't have to choose AI-native or protect their critical workloads. They need to get there by standardising the platform and data and then letting AI ride on top of that. I think that's what it would be my perspective or AWS's perspective on that.

Guy Daniels, TelecomTV (05:35):
Great. Well, thanks very much for that clear starting position there. And I'd like to move on and focus on voice because voice has traditionally been viewed as one of the most demanding workloads in telecoms. So is voice becoming more strategically important to transformation efforts? What do you think, Ram?

Ram Ramanathan, Ribbon Communications (05:55):
No, I think it's, again, a great question because there are players out there that may claim that voice is dead, but actually we see from a vendor perspective and from an industry perspective that voice traffic is actually growing. And as you rightly said, it's one of the most difficult workloads to manage because the voice traffic is very real time. It is jitter sensitive, latency sensitive. You cannot retransmit packets like you do with data networks. So voice is really difficult as a workload to convert to IP-based networks and cloud-based networks. And Ribbon has been at the forefront of converting or transforming voice into cloud-native architectures. Now, when it comes to the strategic importance of voice as we go forward, as I said before, the voice traffic is increasing and it's not increasing in the traditional sense where people-to-people calls are being made. This is more people-to-AI calls or AI to AI calls.

(06:56):
So those are the ones that are becoming more prevalent and increasing the load from a voice perspective. And some examples of this are when you look at agentic contact centres, there's obviously human supplementation. There are human agents and agentic voice agents as well. And agentic voice agents can be flexible, they can scale up and down, they can work 24/7 and so forth. There's a lot of benefit by supplementing human agents with agentic voice agents. So when you look at that use case, whether it's Salesforce, Agentforce kind of contact centre or other contact centres that are supplementing humans with voice AI agents, you see the need for increased voice traffic in terms of just the industry growing from that perspective. And also you do need the right architecture sitting behind these voice AI agents to support voice as a workload, as I said before, with the caveats of jitter and latency sensitive nature of voice.

(07:59):
So as we see, there are more use cases evolving beyond the human-to-human communication. There are more use cases evolving for voice that the hyperscalers and the carriers are taking advantage of. But again, you do need that software-based, the cloud-native microservices base to support these new use cases as Manish was discussing before.

Guy Daniels, TelecomTV (08:21):
Yeah, thanks very much, Ram. This AI voice element is fascinating at the moment. Manish, do you see voice becoming more strategically important and are there any real world examples you can share?

Manish Singh, AWS (08:35):
Yeah, so when we started this network functions on AWS journey, everyone said, "Oh no, so don't go after IMS because it's dead." And then we looked at voice as one of the major ones because it was originally thought to be legacy and then it would not be something that the customers or operators would want to keep on premises and keep spending time and effort on. But very soon we realised that the growth on IMS deployments on AWS is not that much as we expected. And this was two, three years back before AI came on board.

(09:18):
And there were customers who had 10-year-old hardware deployments where they would just keep running it and they say, "I'm happy just not doing anything with it, just sitting there and no transformation required for the same." But in the last one or two years, we have started seeing a lot of different view coming in from the customers where they believe that with all these agentic voice and AI-based communication on customer channels or towards making voice more software driven or software-centric. So it's becoming more strategic now. And I think we are starting to see new workloads from the vendors which are actually talking about what Ribbon said and other vendors as well, where they are able to now talk about injection of AI-based services within the voice communication channels. But at the same time, we as a cloud provider have to ensure that not just the AI-based capability, but also the capability to be able to drive something that real time through our infrastructure services is so important.

(10:29):
So both of those, I think they go together, whether it's voice on AWS or actually having AI-based services directly injected into that voice communication channel.

Guy Daniels, TelecomTV (10:44):
Okay, thanks very much. I'd like to look at some of the concerns that are still around in practically every telecom cloud discussion that certainly we hear. There's concerns around cost, control, resilience and security. Manish, if I can come back to you, which of these concerns do you think is perhaps most misunderstood today, and are there any that are still actually valid?

Manish Singh, AWS (11:10):
I would actually add one more on top of that, which is data sovereignty. So if you look at cost, control, resilience, security, and data sovereignty, out of all these, I think the most misunderstood is control because when we look at from an operator's perspective of what they want to control from their infrastructure, it's not about them actually owning the box or owning that infrastructure. It's more about having a consistent policy or having observability which is across the board the same, whether it's talking about automation or you're talking about ability to manage that infrastructure better. And we believe that with cloud, you get all of those benefits of achieving that control better. And one of the things that we believe that when you look at the TCO, for example, and try and understand how to get the best total cost of ownership, that comes best with the right policies and right way of looking at the infrastructure.

(12:23):
Coming to the TCO aspect, now we look at the cost in many facets when we look at the cost and especially because we have internally within an operator, you have different cost centres looking at infrastructure and another cost centre looking at, for example, the software pricing. Because of that, they just consider the pricing of a core server hardware against what, for example, AWS is giving. Manish Singh, AWS (12:54):
And the tool, it's not an apples-to-apples comparison when we try to do TCO. And to me, that's one of the second most misunderstood aspects of what you get when you get onto AWS.

(13:10):
The other aspects of resilience, security, data sovereignty, I think they are valid concerns. We don't have a region in every country, for example, but we are getting there in terms of increasing the overall deployment. But whichever place we don't have regions, we have the means of setting up what we call as cloud continuum of actually taking that infrastructure closer to the customer with the help of services like local zones and AWS Outposts. So therefore we cover the aspect of security and data sovereignty by either providing local zones or AWS Outposts. And talk about resiliency. I think again, a misunderstood concept from a regional construct that many people don't know that an AWS region is a geographically distributed infrastructure setup of at least three availability zones which are separated by a minimum of 60 kilometres. And each of these availability zones actually have multiple data centres within.

(14:19):
So it's a very highly resilient infrastructure already and it's well defined, available in the public domain. Everyone knows what the failure domains are. Everyone is aware that the kind of sovereignty and the security that you can get is what everyone knows about from AWS. I think we need to just address it properly by looking at cloud in a different way, and actually cloud strengthens their position in all these aspects more than actually going against it.

Guy Daniels, TelecomTV (14:58):
Okay, Manish, thank you very much. And good analysis there of the major concerns. And Ram, I'd like to ask you the same question and find out what you are hearing from your customers.

Ram Ramanathan, Ribbon Communications (15:08):
No, I think it was a great... Some of the points made by Manish are really good. I'll just take a vendor aspect of the response now. In my mind and when we talk to customers, I think cost is the biggest concern that they have, but I feel that is really not at the right place in terms of looking at a total TCO. I think the first thing they look at is cloud, whether it's public or private cloud, is it expensive? Do I need to move my physical infrastructure to a cloud-native infrastructure? Is it going to be very expensive? That is the first concern that they have, but I think it's misplaced because of a couple of reasons. You need to look at the total cost of ownership, like Manish mentioned. It is not just the cost of the servers or compute or bandwidth, it is the overall TCO in terms of data centres that you have to maintain, uplinks and downlinks that you have to maintain, the partnerships you may need to bring in if you're doing it on your own.

(16:03):
So there are multiple facets to looking at the TCOs, not just at the pure server or compute cost. So that is one aspect. The second aspect of cloud-native is that is when you can create those next generation fluid services that we discussed before. Without a cloud-native architecture, you cannot create these new revenue generating services and be adaptive to the market out there. So there is a monetisation aspect here beyond the TCO. And the third thing I would say is from an automation perspective, in terms of AIOps, using AIOps to automate your network right from design deployment all the way to operations, it is much better suited to a cloud-native environment than a regular physical or virtual environment. So you can offer new services, you can run your network efficiently at lower cost. And then when you look at the total cost of ownership across these things, the cloud variation or the cloud architecture comes out on top.

(17:04):
So that is what we hear as the first concern. But then as we discuss this with customers in terms of the broader scope of the TCO, then they start to understand and gain confidence and they start to migrate towards cloud-native architectures. Now, in terms of the other concerns, control, resilience security, they are valid concerns, but in terms of the architecture that we're bringing to the table, we have a true microservice architecture from a Ribbon perspective, including security at the core, not bolted on, but built in to the architecture. So I think the architecture is the key as customers decide on the next-gen architectures like cloud native and Kubernetes and so on. It is the architecture, the microservice nature and security being built in. And resilience actually with cloud-native comes at a lower cost, the same kind of resilience that you have in your networks today.

(17:54):
So looking at the architecture is the key and then looking at the broader TCO is the key to look at these concerns. I'm not saying dismiss these concerns, but look at them with the right vendor architecture and the right TCO lens to see if it makes sense for you.

Guy Daniels, TelecomTV (18:09):
Thanks very much, Ram. Well, look, can we continue? Because Ram, I'd like to ask what you think has happened over the past few years that's making real-time communications more viable in cloud environments and what new opportunities might become possible when infrastructure's treated more like software than hardware?

Ram Ramanathan, Ribbon Communications (18:28):
Sure. I think what's happened in the past few years, ever since the advent or the increased usage of AI and new chipsets being developed and so forth, there is an increased focus on real-time workloads as well like voice. So we have worked with AWS, for example, on real-time workload architecture to make public cloud more suitable for real-time workloads with the new chipsets that have come in with new drivers that can really provide the performance benefits that real-time workloads need. So we have actually worked with partners such as AWS to tune the networks to keep the voice workloads going in terms of the specific needs of voice. So that has been done over the past three or four years to set it up to get voice into the new world of cloud-native Kubernetes-based architectures. Now what that does as we move into more software-based architectures, now we are making voice, data, internet data, everything run on the same infrastructure.

(19:38):
So it is not a separate network for voice, separate network for video and data and so forth. It's one network based on IP layers, layer zero to three, one set of layers, white box servers, if you will, you don't need specific vendor-specific custom hardware anymore, white box servers that are available at whatever footprint you need and resource requirement you need. So it's one set of architecture, one set of white box server compute architecture, whether it's in public cloud or private cloud, that can potentially support data, video, voice, all types of modalities on a single type of architecture. So what that does is it cuts down on the cost for the carriers because it's one type of architecture, it's normalised, and it also extends itself well to automation and AIOps because now it's one type of orchestration, one type of automation across the layers, across the domains, and that creates a service level architecture, not just a box by box vendor by vendor architecture.

(20:40):
It creates a service-level architecture that we can do one type of service automation and we can deliver services on demand in a much more fluid manner.

Guy Daniels, TelecomTV (20:51):
And Manish, what do you think's changed over the past few years and what has now become possible, do you think, for your customers?

Manish Singh, AWS (21:00):
I think there are three things that have changed, and one of them actually Ram already touched upon, which was the performance of chipsets and overall growth of computing as well as storage, as well as networking as well. I mean, that performance has improved much better now, and there have been advancements in there which have allowed this to happen. But again, from those three aspects that have happened is one is that proximity has changed. So we have brought cloud closer to the customer now. So that means you have now processing capability that can happen much closer to the end customer, and therefore latency or jitter budgets are met. The second thing is about platform consistency. So if you look at how we have been running workloads, if you were to go into the cloud, you might have a hybrid situation wherein you have some parts of the network running on premises and some running on the cloud, and then being able to have a common orchestration layer across all these workloads was simply not possible earlier.

(22:11):
But now with Kubernetes and EKS, which is AWS Elastic Kubernetes Service, and also being able to put this as a consistent layer across cloud as well as on-premises allows you to have a consistency that allows this overall communications to be more viable. I think the third thing is about intelligent automation, or you can call it agentic automation, et cetera, which Ram was also mentioning. If you are able to now seamlessly not just deploy, but do lifecycle management of voice overall across a hybrid network with the respective services of AIOps that AWS provides, I think it allows you to make it more viable and possible on AWS.

Guy Daniels, TelecomTV (23:04):
Great. Well, thanks very much. I've got a final question I'd like to put to both of you because historically telcos could buy infrastructure, deploy and manage it largely within their own domains. Now, as networks become more software driven and increasingly AI enabled, does success depend less on individual products and more perhaps on ecosystems and key partnerships? Manish, let me start by putting that to you.

Manish Singh, AWS (23:31):
I think absolutely. No single vendor can provide a fully AI-native stack. That is the need of not just the communication networks, but also the full software-driven networks that we talk about, whether it's packet data or voice itself. I think the era of being able to provide a best-of-suite is probably ending, and we are moving towards an approach where you need to have partnerships, not just between the ISV vendors like Ribbon and AWS, but also partnerships at the infrastructure level of being able to have a ubiquitous infrastructure that spreads across a hybrid stack. And if you look at what AWS does, AWS does best in terms of partnerships, in terms of working with the ISV vendors or the independent software vendors, and also working with the global GSIs to bring everything together. And then customers can buy outcomes with an infrastructure stack that provides you the best of everything from a partnership perspective, from a platform perspective.

(24:50):
And I think in this day and age, an ecosystem is a capability that a customer buys. They don't buy infrastructure stacks or they don't buy specific vertical stacks.

Guy Daniels, TelecomTV (25:08):
Well, Ram, let me put the same question to you. Does success now depend more on ecosystems and partnerships?

Ram Ramanathan, Ribbon Communications (25:15):
Yes, I completely agree with what Manish just said. I think gone are the days where carriers have to manage the full stack right from the bottom to the top. The infrastructure layer, which is where AWS comes in, right from the compute to the bandwidth to AI native connectors, if that can be outsourced to infrastructure partners, then the carriers can focus more on revenue generating differentiated services layers. That is where they can bring in their domain expertise and not have to worry about all the way from the bottom to the top of the stack. So with that in mind, they can create these new services with more partnerships, which is also the ecosystem play with Ribbon and AWS coming together. We can connect and stitch together more services with other partners, more from an AI perspective, but also from a networking perspective. We can create these services that are differentiated in nature and that are more fluid and dynamic in nature, create on-demand services and grow revenue for our carrier customers.

(26:21):
So really the focus should be for the carriers on the top of the stack in terms of creating revenue-generating services.

Guy Daniels, TelecomTV (26:29):
Thank you very much, Ram. Well, we must leave it there. We are out of time. It's been good talking with you both, and thank you both very much indeed for sharing your views and insights with us today.

Manish Singh, AWS (26:39):
Thank you.