Rahul Atri is managing director of Rakuten Symphony. He was interviewed by Fierce Wireless’ Editor Bevin Fletcher on September 28, 2021 at Fierce’s Network Automation Week virtual event. Atri talked about network slicing and automation
This transcript was lightly edited for brevity and clarity.
Fierce: Hi, Raul.Thanks for joining us. I'm looking forward to getting into some topics on automation and networks, and I know you played a key role in end-to-end automation with Rakuten. And now you're at Symphony, which launched earlier this year, and it kind of houses different elements of the Rakuten Communications Platform. So where does network slicing and automation specifically fit in there, and what market opportunity does it present?
Atri: Short answer. We pride ourselves with automation, and network slicing and automation are an inherent part of the platform. We have different layers of RCP Symphony as a platform. Orchestration, OSS and slice management comes together on the most important layer. For us, it's been in our DNA and from day zero, we have taken automation very seriously. And there's this specific Center of Excellence in Rakuten Mobile. And we're taking all the learnings and experience in Rakuten Mobile Japan and plan to offer the same learnings and experience to operators around the world.
Fierce: Okay, great. And so when we talk about open environments, integration comes up a lot. If you're working in an open environment with different vendors and hardware suppliers, does it make it more difficult to create a slice that goes end to end across the network?
Atri: What an interesting question. I think it's the other way around. When you work with the right partners and right DNA and mindset, it becomes much more easy. What we did in Rakuten was really special that we worked on configuration templates, APIs, and the industrialization of all these integrations. Prior to acquiring Altiostar — which is one of the partners — we focused a lot on integrations and APIs and the vertical and horizontal stack altogether. Even the basic automation or zero-touch commissioning, or then deploying the cloud. We made sure that even if you rip-and-replace or plug-and-play any other component or any other part into the ecosystem, it should work. And I think that's the secret sauce which we have with Rakuten Symphony now.
Going forward, it becomes much more as a native integration exercise for us. Whenever a new partner comes to our marketplace, we just offer them the kind of templates and questionnaire. It’s as soon as they provide those APIs or templates, we take them into the lab and integration happens very swiftly. It was not very easy initially. But I think we've found the way and the details we have gone through, especially with open architecture, it becomes much more easy because everyone wants to make it a success. And the ecosystem is much more open rather than the proprietary APIs and proprietary integration between the interfaces. So, I think it's the other way around it makes it much more simple.
Fierce: And just to kind of ground us in the number of slices that we're talking about, what's typical? What could a typical network handle at a given time? Is it five slices, 10 slices, 100?
Atri: It can handle much more. So there is a 3GPP 15 spec parameter called slice type and slice differentiation — a million slices a network can handle. But realistically, practically, I think it's much more how the network is built. What is the architecture, how much spectrum do you have, how much transport bandwidth do you have and what are the use cases and services you're trying to offer?
The world has been talking about the basics of three different kinds of use cases like machine type, low latencies or ultra-low latencies, and broadband. I personally feel that it will be a combination of these services. For example, a VR handset, or let's say a self-automated car requires both high speed and very low-latency kind of specification. So it will be interesting to see how the ecosystem unfolds and what kind of use cases come through. But the number of slices depends on the capacity of the network and the use cases you are trying to solve and the type of services or customers you have.
Fierce: If operators are looking for these different service-specific requirements, can you talk a little bit about the role automation and orchestration plays in making sure that from the RAN to the core to the transport it all works together for what could potentially be a lot of different requirements?
Atri: So with the evolution of the network, one thing it really showed is that customers are enjoying the simplification. They want a good service experience and single-click service upgrades of our product catalog. But the management of the network is becoming much more complex because we have now not only the RAN, transport and the core layers, but with the virtual networks and cloud networks there are vertical layers as well from infrastructure cloud hypervisors and the orchestration and the OSS/BSS.
So automation is very much required, especially not only for instantiation, because most of what I've seen is people talk about instantiation of the slice, which is step one. But to make the customer get the experience, the lifecycle of slices is very important, and automation and orchestration play a very important role there. Now, you have to also stitch the lifecycle in terms of when you have instantiated the slice — and it can be shared or dedicated, it can be end-to-end, or it can be only RAN resources — but then you have to monitor the slice. Then you have to make sure that the same slice lifecycle is done. You then terminate it, or you make sure that the right amount of SLAs and KPIs are met.
Because 4G and 5G, the difference between them is the experience which the customer gets. It's not about the speed and other things. But slicing is more about the services which we have promised to the customer, whether it is enterprise or a use case. So for me, automation and orchestration become a must, not only for day zero, but for day one and day two, and the end of the slicing network.
Fierce: So, it's not just about turning up more slices or individual slices, but actually meeting those service level needs. Could you talk about some of the specific elements? It would seem businesses and different users would have a variety of needs, and that could vary by enterprise, by day-by-day changes. So how do you keep up with meeting those service requirements via automation capabilities?
Atri: So in radio networks, they monitor certain KPIs, and based on the certain KPIs, they do the analysis and then take the closed-loop action. Let's say for example, the accessibility went down a threshold, but I'm going to change the XYZ parameter and make sure that the accessibility is defined. Or for example, when your network is congested, right, and you have an enterprise customer that you have promised that you’re going to offer one-gig of speed. So how do you make sure that you actually have the visibility to know this? You might be able to instantiate the slice, but that slice has services and KPIs associated with it.
What are you monitoring? Are the telemetry real-time? And are you getting visibility on the run time? Once you have that, what about the non-slice or let's say SLA-based network? Because you have other customers to serve because you're going to instantiate slices based on locations and other things.
So for me, I think the visibility becomes the most important once you have the network up and running. And how do you monitor? I think gone are the days when we had the EMS and network management system, which used to publish the KPIs in 15-minute or an hourly basis. Now the services are offered in real time, so we need that visibility. After that, once you know that this is the SLAs or these are the service levels, how do you make sure that there is a balance and the services offered to the higher ARPU customers or slice customers are made through?
And if they are not, what actions do you need to take? You need to probably do resource management. You need to change your scheduler type. You need to do some architectural change or even do something as simple as installing a new site going forward. So, for us, and I think for the ecosystem going forward, it's very important to see this as the complete cycle of the network evolution. Slicing will become the most important part of the network going forward.
Fierce: If you're using just elements from Symphony — like you mentioned and you talked about quicker life-cycle timelines — what is a realistic timeframe for implementation to being able to offer services via a slice?
Atri: Interestingly, we were able to demonstrate the same in our network very recently in coordination with a Japan-government initiative. We were able to do a shared and a dedicated slice using the core from NEC and the radio from Altiostar. We are now working toward including the transport equipment as well with segment-based policies. So, realistically I think we are not that far off. It’s just about looking at the right use cases and enterprises and the capabilities, which will go forward to take this as a practical use case. But technology-wise with Symphony and in the architecture of Rakuten we’re very much ready. And we do a lot of lab trials, field trials, and first-office applications for some of the sites. And we recently did, as I said, a very good demonstration with NEC, Altiostar and Japan government.
Fierce: You mentioned Altiostar. Are you leveraging any of your other acquisitions, such as Innoeye, for these automation or network-slicing capabilities, and what do they bring to the table?
RELATED: Rakuten Communications Platform wants to conquer the world: Entner
Atri: In Innoeye, we're building the orchestrator, we’re building the slice manager, and we're building the next version of our OSS, which is now cloud-native and working as active, active with the new databases and the architecture changes. So, yeah, the acquisition with Innoeye comes with the OSS platform, which we worked with them in Rakuten. We further enhanced and made it a much more cohesive platform, including the orchestration and the slice manager into it.