Guy Daniels, TelecomTV (00:24):
Hello, you are watching the Open Ran Summit part of our year-round DSP Leaders Coverage. I'm Guy Daniels and today's second discussion. We are going to be reevaluating the RAN intelligent controller. What is the current status and viability of the RIC? What are the opportunities and the challenges and do we actually need a discreet RIC? Well, joining me on the program to help answer these questions are Richard MacKenzie, distinguished Engineer wireless networks at bt. Rahul Atri, president of the OSS Business Unit at Rakuten Symphony Juanma Canbal, Muñoz specialist Open Ran product strategy and planning with Vodafone and Eugina Jordan, chief Marketing Officer for tip, the Telecom Infra project. Hello everyone. Really good to have you all on the program. Now we've seen some major multi-vendor trials of the R and its associated apps. What can we conclude so far from these? What lessons are there for its development and commercial use? And Richard, I'm going to come across to you first because we last spoke about the RIC a year ago on last year's open ran summit. So what have we learned in this past year?

Richard MacKenzie, BT (01:54):
Well, this has been a big focus area for ourselves at bt, but the industry in general, and we've seen a lot of updates in this area. So at the RIC Forum, which was just over a month ago, we saw 18 different demonstrations of third party applications running on RIC's. I say a third party, 18 demonstrations of applications running on RIC's and most of those were capable of running third party applications. What we've done ourselves at bt, we've been involved in several tip projects. One in particular is worth mentioning that was running last year and has now completed, and that's the ARI 5G project. And in that one we had a single RIC, but we had three different app developers and we were showing that those third party X apps could be installed on a single R. And so it's possible to mix and match vendors on a single platform.

(02:52):
So that's what we learned from that project and that's now matured and finished and now started a new project that follows on from there. And we've sort of made the goals a little bit more ambitious this time. So now we're looking at multiple RICs. So we've got two RIC vendors in the project and we've got three different app developers. And the idea here is that we're going to try and install the apps on different RICs to check the portability. But what we're also going to do, and this is the big challenge for the industry at the moment, is we're going to run those applications on the R at the same time. So when those apps have different objectives, there's going to be the potential for conflict. So we know about potential conflicts and we started to discuss as an industry for the last couple of years how we might address them. In the last year we've seen the Oran Alliance have actively started addressing this. The work isn't completed, but we're seeing from a lot of trials now that we can give good examples of what happens when there are conflicts and also good examples of how to resolve them. So it's still work in progress, but this is probably the last big challenge before we can say that we're truly in a position to deploy third party X apps in a commercial deployment.

Guy Daniels, TelecomTV (04:14):
That's really interesting, Richard. Thanks so much for those updates. Moving along swiftly, aren't we? I'll come to Rahul in a minute, but first of all, Juanma, let me come across to you and what's your experience been? What have you witnessed as a result of all these trials over the past 12 months?

Juanma Canabal Muñoz, Vodafone (04:32):
Yes, I would highlight also the conflict. Okay, the conflict between the different applications that my colleague has just mentioned because we participated in a demonstration for T with two different applications with different and opposite goals such as traffic steering and energy saving, and both applications work smoothly. So with any problems without any conflict between them. But also I would like to highlight that it's very important to have when trialing the R and in general in simply running trials dedicated or very without a dedicated roadmap with the specific goals is ineffective. Okay. You have to trace a clear roadmap and you want to test and you want to try it with a specific goals.

Guy Daniels, TelecomTV (05:46):
Great. Thanks so much. One, we've got to be aware, we've got to know what we're doing and why, what our ultimate objectives are. Thanks for the update, Rahul, I promise to come across to you as well. What's your experience been of the past 12 months and what we've learned so far?

Rahul Atri, Rakuten Symphony (06:02):
The only difference with us is we have a production open ran network running, so for us it's more than trials. One thing which I believe, and I think everyone prior to me speaking also believe that it's RIC is a ecosystem player. You need a lot of partners to collaborate because everyone can bring in value. So there has to be a common R platform where you can onboard applications. When we talk about platform, the platform should be capable of hosting third party apps but also managing the application life cycles and integrating that with the telemetry systems and take actions. What we have seen is the early adoption, early use cases seems to be the so evolution a lot of so partners have started evolving their products and started calling them non realtime RIC applications. There've been some attention towards realtime RIC as well, but I think the whole ecosystem apart from the telemetry and AI models also need to evolve through that.

(06:58):
So for us, we have recaps in productions for some of the use cases we already talked about. It's a lot about ecosystem, a lot about coordination, conflict management, but that was again the case in so on as well. The good part in last 12 months is the ecosystem has evolved. There are a lot of roadmap not only with the design partners but also from the other players who have also started accompanying us into open ran ecosystem. This also shows that the industry is actually evolving towards open ran and that's why they're also starting thinking about not only day one use cases but also the day two use cases. Erik for us also is an evolution in terms of how to bring innovation into the RF engineering as well and then manage the network more like soft.

Guy Daniels, TelecomTV (07:46):
Great. Thanks very much for update rule and we heard in our earlier panel today about strategies for Brownfield open ran deployments, commercial deployments, and Rahul, you mentioned the importance of ecosystems there, which brings me nicely to our next point and that is the extensive ecosystem of developers and the creation of numerous new applications perhaps doesn't yet appear to have happened or at least certainly not as we might have thought it has. If that's the case, why not? What's holding back the growth of this particular sector? Eugina, do you have any insights and what progress are you seeing?

Eugina Jordan, Telecom Infra Project (08:26):
Really, really great question. So let's look at why any company would develop an ops and our app. They need to have a business case and they need to have a path to market and return on their investment. So let's look at five aspects. The first one is there's an example of app store and android store as well. One is open, one is closed. So we don't have a lot of open rigs here in telecom and it's extremely hard for an op or app developer to get onto a closed R unless there are trials like Richard was talking about with T four, Ari and Ariana. Number two, the requirements are not clear. The feature set is not clear for developers to realize the potential of their investment and that's the third one is the investment. The investments in telecom are shrinking, so if there's no feature set, if there's no business case for developers and there's no clear path to market on what risk they can get on, then they're not going to get investments from either private equity or traditional investors or even angel investments.

(10:02):
Number four, it's always about the process. There was a discussion last year as you mentioned about portability. It is still an issue how you're going to port apps onto different types of freaks and the last one is APIs and there is still discussion in the industry and that's what Ariana is working on, on APIs to other or on elements in the pole architecture. So it's figuring out how those APIs from R going to extend to X apps and AOPs. So unless as an industry we figure out what is the business case, where the investment will come from, is there going to be open or closed? What would be the process to implement port and integrate? We're not going to attract new app developers.

Guy Daniels, TelecomTV (11:08):
Very interesting Eugina. A lot of issues there that could potentially be very challenging. I'll come to one mind a minute, but Rahul, let's come back to you first. What are you seeing as the challenges to selling this to developers?

Rahul Atri, Rakuten Symphony (11:23):
Definition of RIC, I think the platform is what the platform telcos will own or the tier one partners will bring, but then the definition of RIC apps, when we talk about RIC apps and telecom networks, we talk about a lot of career grades and mission critical services, but when we talk about RIC, it can be any application. It doesn't have to be a closed loop, could be a business analytics could be giving the trains could be producing some reporting out of it. It's very difficult for somebody as a third party developer to look into telecom A as Eugene I mentioned about the operability. Where do you test it? If you have brought in a build application which can do a similar job as RIC, where do you test it? I mean there's no open platform to test it today. There's no infrastructure and nobody will open up their labs and it's a long cycle in telcos and probably you'll gain more value and have less time to market.

(12:20):
If you build an OTT app, you'll fail fast in that case. The second part of the puzzle is what do you define as rec applications? It doesn't have to be, as I said, sleeping cell energy savings or the usual things we do. If it's look into every CSP, their RF engineering teams, their optimization teams have built a lot of macros, lot of things which they do every day. Cluster optimization engineer, HQ engineer who comes and look into their area to say everything is good in my network, my area, or there is a dip in handover success rate. Why do I do steering of traffic here and there? Do I have outage in one carrier? So there's a lot of things which they do every day. They have small scripts, they have small manuals, they do scripting around it, macros, all those can be converted into recaps and then there's a lot of platforms available. Just have to put the code into a container and just load it on, integrate the APIs from telemetry and that can be an action.

Guy Daniels, TelecomTV (13:16):
Great, thanks very much. Rahul. There does seem to be a lot of challenges still and not all of them are technical challenges. Juanma, let's come across to you. Are you also seeing a problem in developing the ecosystems and attracting the developers?

Juanma Canabal Muñoz, Vodafone (13:32):
Mining is also technical. I mean building open run application is not just coding. Okay, it is, it requires a unique skillset and of course you need traditional developers but also you need people who knows who has a special skills on embedded deep on radio protocols signaling. So it takes time to develop expertise in.

Guy Daniels, TelecomTV (14:09):
Okay, thanks very much everybody. Great insights into what the industry is facing at the moment when it comes to the applications there. We've got X apps and we've got R apps, we've got the two aspects of the RIC. Are we seeing a preference amongst those supportive developers and indeed telcos themselves for either one or the other? Are there X apps getting more traction at the moment or are apps, Richard, from where you sit at bt, what are you seeing?

Richard MacKenzie, BT (14:41):
Well it is a really good question and it's really hard to get consensus across the industry at the moment about which one is the most important or the most useful or even which one will be rolled out faster than the other. But what I can share is some stats I collected from attending the RIC forum just over a month ago and although that didn't show every RIC vendor or every app developer, it was a good representation of the industry. There were 18 presentations of those 15 involved. The near real time RIC, only eight used the non-real time RIC and six used a hybrid so they used both near real time and non-real time. So in that sense you'd say that the near real time RIC is certainly getting more attention right now, but there are some solutions already where there's no intention to use the near real time RIC. So there's certainly disagreements and I would say overall most use cases there's an argument to use either or both.

Guy Daniels, TelecomTV (15:52):
Interesting. Richard, what appears to be a really simple question is actually quite tricky when you delve into it, isn't it? I think we all want to come in with some comments on this one, but Rahul I'm going to come across to you first if that's okay Then we'll get everybody else in but real let's hear it from you first.

Rahul Atri, Rakuten Symphony (16:08):
Pretty similar findings. I think it's very easy or probably desirable for all the current ecosystem players to uplift their current solutions like SA or CSON or eons into the non realtime RIC, but always if you talk to them and if you see they always have a roadmap or liking towards near realtime RIC, but it'll take a lot of other integrations and other possibilities to also look up to the realtime RIC, opening up the software stack, opening up the protocol layer, opening up the events on the real time and also having the right model trained and also taking the decisions in the run time. I think it evolves a lot of integration, trial testing and a lot of detailing around the ran vendors. Fortunately for us we have our internal sister company who works as ran software provider, so we're able to do some of the things early findings on that.

(17:11):
One thing which I'll also like to add is going into the future use cases like slicing and the edge and gaming use cases where quality of service and a lot of use cases which involves customer realizing the dip in the services change in the latency patterns and other important KPIs rather than only the round link uplinks or the scheduling would require the near real time break or a similar solution to be present because then you need to assure these services, this quality of intent and other use cases to the user. So whether they come directly preintegrated into ran softwares or they come as separate recaps as ecosystems for real time, I think we'll see in next six months evolving and especially when the ecosystem is adapting open ran a lot more. I think we'll see a lot more of these things coming up.

Guy Daniels, TelecomTV (18:09):
Yeah, you're right, it's developing. We'll have to keep a very close eye on this and see how it pans out. Eugina, let's come across to you next. Are you seeing a separation? Can you delineate between the two RICs and the associated apps yet?

Eugina Jordan, Telecom Infra Project (18:26):
So let, thank you. So let's look at where X ops and ROPs originated from. It's nothing new, so X ops, they are your so rebranded applications and the reason that there is more, I think Richard gave really good data. I think the reason there is more sun or ops, it's because it's been around for 10, 15, 20 years, so it's very easy to turn them into more portable applications for R. If we look at aaps, they are repackaged analytics, repackaged business intelligence reporting and the challenge with aaps, it's not just a technical one, it's actually a business one because X apps they deal with technology, they can come from the radio vendors. It's very easy to get the data. You can use unsupervised models to train X apps with AOPs, you touch your customer, you touch data that is private, you need to implement security, you also need specialized team to work on those AOPs. You cannot use unsupervised models because you deal with data, so you need to use supervised models because of you dealing with customer data and analytics. So it's not a surprise that we see more apps developing in the future when we have open RX and we have access to all the data, we'll probably see more a apps, but that's going to take some time.

Guy Daniels, TelecomTV (20:32):
Thanks very much for explaining that Eugina, that's great. And one more let's come across to you. Are you seeing a split yet? Are you seeing a preference for X apps say over our apps?

Juanma Canabal Muñoz, Vodafone (20:42):
I don't think there is any preference between X apps or our apps. I think Xap think of them as the high performance option. They are great for innovation and as Regina has said, they are user specific because they can make made user specific adjustments. On the contrary, our apps are just an evolution of season solutions, so they are more feasible currently, but I think at the end as technology advances there will be more UBS and also, let me put an example, a use case can be designed as an arap. For example, energy saving sales switch off, but at the moment you need a better adjustment following the traffic profile, following better the traffic profile and having a more dynamic response capability that ARAP translates or evolves into an Excel.

Guy Daniels, TelecomTV (22:10):
Very interesting. It does sound like this is a fast evolving space that we'll have to keep a close eye on. Thanks very much everyone for those insights. Let's move on because I wanted to pick up on app portability and subsequent integration challenges because these were brought up during last year's summit as being a big problem 12 months ago. Now we've already heard Richard, Eugina, I think maybe all of you have mentioned portability at some point already. Can we just briefly look at this again and tell me has there been any progress? Is this still a major problem or has the situation got better? Rahul, you are really closely involved in this. What are you seeing?

Rahul Atri, Rakuten Symphony (22:55):
I think for our apps the things have evolved. The portability, as I said, I think a lot of partners and a lot of customers have figured out what they want the platform to be, how they want the platform to be and that's very critical because that becomes your landings on that becomes your app store in this case and if you have solved the platform part and then how does it integrate with telemetry and how does this takes a closed loop action, whether it happens from the app directly or it goes via your central lifecycle management or configuration management. So onboarding an app, defining the lifecycle of an app and then managing the app on the coordination and conflict management. These are some of the things which are taking place. I think having an app on top of platform is the easiest thing. All the partners or all the rec players have found the gist of it and probably have the early standard defined to make that possible.

(23:54):
But when we talk about production, it's also very important that there's a central platform which is managing the applications, the apps, their health, how the heartbeats are monitored between them and the other systems integrated, how do you configure them? For example, one recap which is traffic steering. How do you configure that to do different kind of traffic steering across multiple clusters or across different clutter types or let's say in urban area, the suburban area and how do you manage that configuration in this case because so those are really a boundaries or specifications of those. Let's say sell IDs eNews to say these areas, this is the configuration to load and this is the decision tree to take and this is the business flow. How do you do that when there are different sets of configuration involved? A platform comes from somebody else, the app comes from somebody else. Those are the kind of integration, those are the conflict. Those are the areas where a lot of focus have been spent on recently.

Guy Daniels, TelecomTV (24:55):
Great. Thanks very much Rahul. A lot of factors there. A lot of questions we have to ask ourselves. Richard, are you happy with the progress that's been made on this front as an industry as a whole? Are we making progress on app portability?

Richard MacKenzie, BT (25:10):
Well, it's still certainly a big issue. Well, it's certainly an issue. It's how big an issue it is because what we have found is when we have an app vendor and they've already created an app that's onboarded onto one particular R, when they try to repackage or rebuild that to work on another R, it's not a significant amount of work. It might take a week or two and a couple of people's time, but it's not huge amount when we think of what real integration challenges can be, so it's there as a problem. It's certainly not plug and play. If we want to get anywhere near plug and play, then we certainly need updates to the standards. The standards are still lacking enough detail to achieve plug and play, but I'm not sure it's such a problem. There's only a finite number of RICs and we basically want to make sure that that's a manageable workload for any app vendor once they've created their app.

(26:09):
That's the main challenge, but then there's a bit of extra work if you want to make sure that it's compatible with every RIC. One other thing worth mentioning is probably every RIC vendor that I can think of, I don't think there's any exceptions, produces some apps, X apps or our apps and then some of those RIC vendors are quite keen to just promote their own portfolio and not really as focused on third party. And then there's the others that are very keen to encourage third party xap and that's the main differentiator at the moment. If the RIC vendor is open to helping with the onboarding process, it's very manageable and if they're not really open to that then it is a big challenge.

Guy Daniels, TelecomTV (26:51):
Good insight. Thank you very much for that. Richard and Juanma, let's come across to you and your thoughts about portability.

Juanma Canabal Muñoz, Vodafone (26:59):
Yes, I would distinguish between the onboarding of the ops or the Arabs and the fitting of the parameters of the R apps and x apps into your network. I would distinguish that and also I would put focus on certifications. Okay, we haven't speak about that and I consider that certifications are a seal of approval and way to advance in their availability for R apps and x apps.

Guy Daniels, TelecomTV (27:40):
Thanks very much. One more for that. That's much appreciated. Brings us to our final question and I just want to play devil's advocate very quickly here and that is to ask you all do we actually need a configurable and programmatic RIC because we hear that some operators are interested in its potential to enable service differentiation, but is the RIC actually a solution to a problem that we don't really have? Eugina, what are you going to tell me?

Eugina Jordan, Telecom Infra Project (28:10):
Such a great question because I always answer my questions with the telecom history, I guess I've been in the industry for too long, so let me take you back to 3G. When we had CDMA and GSM and both technologies had their controllers, then once we started working on lt, we decided you know what? We're going to have the X two interface and X two interface is going to be used for radios to talk to one another. What it did is it not only closed the network and hence the need for open ran to open it up, but also it created a lot of chatter and it prevented progress of some of the use cases that 4G was supposed to enable. Yes, my view is what RIC is solving is solving the mistake that we made as an industry when we eliminated the control of four 4G and it's going to help manage the base stations and also deliver better customer experience and in addition, it'll help with different use cases, IUT use cases, private network use cases where there is a lot of IOT devices and you need to manage them. So yes, we do need RIC because it's our ability to enable more devices, more use cases, more services and connectivity across home, outdoors, indoors, and so on.

Guy Daniels, TelecomTV (30:08):
Thanks Eugina, and as you say, we should never forget our history. We have to build on what we've done. I'm going to come across to all of you and Wema, I'm going to start with you and ask that simple question, do we actually need the RIC?

Juanma Canabal Muñoz, Vodafone (30:22):
Yes, of course. I think RIC is the solution as Eugina has said, well, it's complicated. We cannot rely on many different platforms with different purposes coming from different vendors. Thus is a lack of flexibility and an innovation of course, and also networks are becoming increasingly intricate, so we need to develop new services and manage new services and we need automation for that because automation is needed for a better deployment and faster also optimization in the field of optimization. We are very used to optimize the network at cell basis, at cluster basis or at different time of the day, but we are not used to optimize at that user specific level. This granularity is not achieved with traditional platforms with cson.

Guy Daniels, TelecomTV (31:35):
Thanks very much. Juanma. Very clear reasons why the RIC is important there. Rahul, let's come across to you next. We have issues that we need to address, but is the RIC the right way to go about meeting those challenges for telcos?

Rahul Atri, Rakuten Symphony (31:54):
The whole point of moving to open networks, open ran and software defined networks is to make network look like infinite and self config or always runtime configurable and if we want to achieve that, if that is the future use case, if that is the future monetization strategy, RIC is very important. The apps are very important to make that happen and that's how the ecosystem will grow. That's how you'll get the third party partners and if you're looking for third party developers and opening up, then we need to define those use cases, those services, and then let the platform be open enough to deliver those services faster and configure those networks. We will see the approach. People will have different definitions about open ran, even though with the current brownfield current non-cloud native networks, there's the only layer which will make network configurable on the radio side most of course, but configuring them for that specific use cases and services. So I'm very optimist that there's going to be very important layer and RIC actually will define or redefine how we see the networks, how do we see software defined networks and how do you see RAN and deliver those use cases. Next challenges, next monetization use cases for telecom.

Guy Daniels, TelecomTV (33:07):
Great, thanks very much Rahul. Another positive answer there and finally, last word to you, Richard, why should we continue all this work? Why should we put the effort into overcoming all these many, many challenges that we still have in order to make the RIC a success? Why do we still need it?

Richard MacKenzie, BT (33:22):
Well, as you said, there's a lot of challenges still to overcome, but right now do we need the RIC? Maybe not just in terms of 4G for mobile broadband, 5G for enhanced mobile broadband. If we're deploying open ran, we're just deploying them as essentially another base station so we can use the existing management platforms. We don't need the R, but as soon as we start offering different services, the R starts to have an advantage. As soon as we want to be able to create services quickly, then it's got a major advantage. And when we start thinking of, I always think that the earliest deployments of the R where we're really going to see the power are in the private networks. When we've got deployments that have completely unique requirements with the R, we can piece together the X apps and the R apps from a range of vendors from across the ecosystem to piece together your exact bespoke requirements, met with a R, and you can create that service very quickly, launch the service very quickly and ultimately optimize it as well. It's not just about launching the service, it's about making that service as good as it can be. When we start using the power of AI and machine learning, the R is in a perfect position to exploit that power and so as time goes on and we start launching better services and optimizing the network, that's where the RIC becomes essential. So right now, no, we don't need it, but in the future, yes we do.

Guy Daniels, TelecomTV (34:54):
Fantastic. Thanks very much, Richard. So if you're moving towards being a digital services provider, and I hope you all are, then you're going to need the RIC at some point very, very soon. Right? We must leave it there though. I'm sure we will continue this debate during our live q and a show for now, thank you all very much indeed for taking part in our discussion. If you are watching this on day one of our open ran summit, then please send us your questions and we'll answer them in our live q and a show, which is coming up very soon. You'll find the question form on the telecom TV website along with our poll. Goodbye for now.