A Q&A with Dish’s Sidd Chenumolu on the public cloud, network programmability and the role of the RIC
Dish Wireless has reached major coverage milestones in its effort to build out a nationwide Standalone 5G network using Open RAN principles. Company Vice President of Technology Development Sidd Chenumolu, in a conversation with RCR Wireless News, discusses the RAN Intelligent Controller (RIC) as the centerpiece of the operator’s Open RAN network.
Q: Can you give us a high-level overview of the network Dish is building, and give us some context on the technology choices, including an Open RAN architecture, that the company has made?
A: We decided to move to a public cloud, AWS to be more specific, because of scale and velocity. And obviously, with the public cloud, you get the programmability with that. But the way we started thinking is that we want to be a programmable network. That was the whole intent going into the RFP process for 5G.
So we are deploying an open network. It’s disaggregated. It’s, in fact, deployed in both on-prem and public cloud, our DUs…they’re designed to be both what we call distributed RAN and also centralized RAN. In addition, as I said, continuing with the disaggregation, we’re also deployed in AWS where we have…the control and user plane. Along with it, we have the management, observability, and control planes also sitting in AWS. So it’s a pretty distributed yet centrally managed network.
What I would like to call is that, when we talk about programmability, we are not just talking about programmability of a network function, not just about the configuration of the function itself, but it’s a programmability, the way in which we instantiate infrastructure, the way in which we instantiate to do lifecycle management or configure the platform. So the programmability goes from end to end, all the way from the application to the basic infrastructure too.
Q: To your comment on the RIC as the centerpiece of an Open RAN network, tell us what you’re thinking.
A: RIC…is what satisfies the requirements of programmability. Now, the whole notion is based on separation of intelligence from implementation. And so RIC, the way I describe it, is as the brains of the network. It is what makes the network smart.
Now, this idea of separation of intelligence from implementation is not something new. Every RAN vendor that I know of has been trying to implement that for a long time, and it is quite frankly implemented in multiple domains, non-telco domains. But with the O-RAN, for the first time, we’re standardizing the interfaces to make it happen.
But equally important, I think everyone is following, nowadays, all the AI/ML stuff. So the timing is about right. We’re able to use the massive data and machine learning to make much more centralized intelligent decisions. So two things are working in favor right now.
Coming back to the RIC itself, and as it is being defined in the Open RAN standards, I call it like outer loop and inner loop, two levels of hierarchy of intelligence. Both are distributed, but they’re coordinated. So you have one entity making bigger decisions at a larger timescale, another entity trying to make decisions for about a smaller timescale, but yet they’re coordinated.
The one simple way to think about this is imagine RIC has something that removes the stale intelligence from the network. Today, if you want to bring in something to the network, we have to wait six months, nine months, depending on the vendor release. But now, I have the capability to induce intelligence, modify it in a matter of a week, maybe a couple of days, depending on how fast we want to go.
RIC is not a replacement for any existing RAN vendor solution. I describe it as an enhancement, and the fact that that enhancement for RIC can come from the same RAN vendor too. Again, it’s about segregation, separation of intelligence versus implementation, not a replacement.
Q: Help us understand the role of the RIC in exposing network data to developers, and what that does for Dish.
A: I don’t know the exact path we would take or how prescriptive I can be that this is exactly how we would reach our end goal. But that is exactly the end goal—have the right application for the job.
But coming from a developer experience to whom we are going to expose the capabilities of the network as a programmable network, I see two sides to it. One side is, for the developers, we’re going to create applications for Dish in particular, those what I call inward applications, whether that’s about optimization or improving performance. And those applications would run on our RIC platform…and they can be sourced as a product, they could be as a service, or it could be even revenue share. So there are multiple models for these applications for developers. But again, all of them are inwards to Dish.
The second set, which is very interesting, is for the enterprises, where you say that if enterprises want to have a piece of the network, what we call network of networks, what capabilities can network enterprises have directly to manage the RAN aspect? So now, the enterprise can itself bring a RIC application. Again, they can bring their own applications that can leverage what we have. Both are possible.
So this is where I think it becomes very interesting. Now, I don’t know at what point we will be in the future saying that we can automatically figure out the right application for the job. I think, to me, that’s a little bit down the road…What I see in the short term is that we’ll have a catalog of services, a catalog of apps. And manually, initially, we’ll be mapping those services to the apps and qualifying them and put them in the network.
Q: Any learnings from what Dish has done and will continue to do that would be relevant to brownfield operators who are planning to deploy Open RAN and make use of the RIC?
A: I can tell you that in my position where I sit right now, I would say I’m jealous of the brownfield operators because they’re in an excellent position to deploy RIC. Not because of their open technology, but because they have a baseline of performance. They know exactly what to build on top of it. In our case, we’re building as a greenfield, we don’t have a baseline, so the only way for us to go is upwards, so that’s good. But brownfields have a good baseline.
Now, I completely acknowledge that the existing traditional vendors may not have open interfaces. But my suggestion would be that if we park aside the open interfaces part and focus on the data part, the data that the networks are producing at a massive scale and massive volume today, how can you leverage those data to make intelligent decisions sitting outside the RAN and influence the performance of it? I think that would be a big step forward. I’m pretty sure every engineer out there in the operator world would like to get their hands dirty with the data and machine learning. So this is an excellent opportunity.
Q: Any summary thoughts?
A: I think the biggest influence I see for Open RAN is in the enterprise field, where I see the programmability is going to make a huge difference as to how the operators are going to enter the enterprise site. Our existing solutions, as I said, they’re curated towards consumer. We don’t have anything for enterprises. If you take manufacturing as an example, it’s a huge field. Open RAN is the way in, and we should definitely take advantage of programmability there.
Editor’s note: This interview, part of the Open RAN Global Forum, available on demand here, has been edited for length and clarity.
