“The Future of Mobile is in the Clouds” – an Interview with David Khemelevsky a Senior Director of RIC & Cloud Solutions
We were thrilled to get an hour with David Khemelevsky, one of our stars at Parallel Wireless, who is leading the development of our innovative RIC and cloud solutions. For the past 3 years David has spearheaded a team of dozens of engineers as they worked to achieve breakthroughs that many in the industry did not believe were possible. We definitely learned a lot from this latest post in our Thought Leadership series and we’re sure you will, too.
As a Senior Director of RIC & Cloud Solutions, how do you see the role of the cloud in the future of mobile networks?
Mobile networks are continuously expanding, to support more devices, to add capacity and to increase coverage. This means that the physical footprint of a network, the locations of actual antennas, is growing, and for each antenna, various accompanying RAN equipment is required. This is what has driven the mobile industry to adopt “the cloud” in order to centralize and distribute (as needed) the various components without compromising the performance or the efficiency of the solution. Another goal is to establish a ‘single pane of glass’ to monitor and orchestrate the network, as the cell site, with all its components, becomes yet another resource that runs as software. Many industries have embraced cloud architecture, for good reason. There is inherent efficiency when systems can be monitored, administered and maintained centrally. However, underneath such a shift lies a cold technical truth; any software needs a hosting environment and in order to enable applications to successfully operate in a cloud environment, our team is responsible for providing an environment for applications to enjoy at least the same performance parameters that they reliably get when their software is deployed onsite on various physical HW. For RAN solutions this means, for example, the need to operate with very low latency (real-time) in order to deal with the high-volume of throughput and conditions. This may sound straightforward but it is actually very difficult to support. To meet the most cutting-edge requirements, there is no established playbook or practice to lean on, we must invent them as we go along.
That sounds challenging. Could you elaborate?
One of the challenges we face concerns the creation of a hosting environment that can support ultra low latency for cloud applications. The need for this is clear, since failure to meet latency requirements can result in lost packets and eventually in drops, which immediately develops into a User Experience problem.
In a fronthaul service, for example, there is a gateway that transfers the traffic from the L1 Phy to the radio head itself. This has a sensitivity of a few microseconds and this is the level of performance that the applications that manage it are expecting. The synchronization and scheduling are finely tuned. In order to support such requirements in the cloud, it is our job to make sure that the app containers get the performance they rely on or they will either start to misfire or shut down entirely. Since cloud environments are typically heterogenous from a HW perspective, we need to do this in a way that does not rely on the characteristics of any particular HW platform. So the way I see it, our role is to enable this environment to run transparently on different HW platforms, and this is what most of our team is working on.
If the benefits of a HW-agnostic approach are so obvious, why aren’t the larger players doing this?
Parallel Wireless is, at our core, a software company, and we are focused on disaggregating the software from the underlying hardware platform. The result is that our turnaround for delivering innovations and updates are quicker by an order of magnitude (days vs. months). We are able to identify problems within hours and solve them within days. That makes it easier to convert an unhappy customer to a satisfied customer. Our customers understand that in order to innovate and create cutting edge solutions, the assumption must be that there will eventually be problems and so the emphasis should be on making sure it is possible to quickly address those problems. Traditional telco vendors struggle with this philosophical disruption. They are still locked into a cycle of software development, hardware optimization and testing, which makes for a much longer development loop. In reality, the introduction of a more agile, SW-oriented approach, enables a “run it and solve problems as they arise” mode. It is a difficult challenge for them to change the mindsets of their engineering, operations and customer service staff to accept that it is possible to identify, analyze and correct an issue in short cycles.
This is a key strength of our solutions: Our ability to drill down and conduct the root cause analysis and bug fixing is much faster than that of our competitors and it will become even faster, for us and for our MNO customers, to identify issues even before there are complaints. We can identify in advance, and prevent, even a 5 minute outage; this is huge! There are indicators that precede any occurrence, the SMO can identify those signs and make the necessary correction before it happens and then push it to production.
Some might say that this is unrealistic. Is this an achievable scenario?
These capabilities are enabled by data, data that is generated, collected and analyzed. This data can be generated by each component in the network, and fed into the RIC. This is currently limited since the “old generation” of solutions do not generate/share data. In the long run, it should be possible to share data between different “new generation” solutions. It won’t come easily, but I anticipate that operators will exert pressure on the vendors to cooperate in order to feed a universal network monitoring system that will be able to effectively identify where the cause of failures lies and how best to fix it.
How pivotal is the role of the RIC? Can you clarify the roles of the RIC and the SMO?
The RIC (RAN Intelligent Controller) is a key enabler for these breakthroughs, a somewhat boring, but necessary software appliance. The RIC collects and generates data from various network components. It is generally considered a part of a broader system, the SMO (Service Management Orchestration).
Since the RIC sits “close” to the data, xApps that run on the RIC are able to apply automated policies in reaction to this data. When you have a Near Real Time RIC, as we have developed, the network can respond “instinctively” to certain data patterns in a “See problem, fix problem” mode. xApps can address specific use cases such as Energy saving, Traffic steering, Cell “hibernation” and Load balancing. With xApps, the problem has already been defined, the solution is clear and so is the expected behavior for every eventuality.
The SMO lies further downstream of the data and can analyze it to identify the patterns. It is responsible for correlating the incoming data from the RIC and the BBU. The rApps in the SMO are not necessarily aware of a specific problem they are addressing, and are not able to identify specific failures in the system, but they are positioned to recognize “what good looks like” and to compare between different cell sites to help figure out which one is misbehaving and why. The SMO can perform “static” corrective actions, while the RIC can perform real time corrective actions upon the prescriptions of the SMO.
What are the weaknesses of a cloud-oriented architecture and how can they be minimized? Are there elements that even today would not be entrusted to the cloud?
Operating in the cloud poses its own challenges, since cloud technology has evolved into microservices. For example, an SMO is not just a single service it can be composed of up to 80 different entities. It becomes so distributed that monitoring them becomes a problem and identifying, for instance, which one of those entities is not performing is difficult.
Another challenge is territorial; public clouds often prefer centralization and therefore your cloud may be hosted in a different country, creating legal and compliance issues. In the event of a service-level breach, or a data breach, you may have to resort to legal action in a foreign country with a different legal system and different data privacy regulations. For governments and large corporations, this can be a nightmarish scenario. That is why many countries want the public cloud to be hosted locally, in their territory.
That being said, public clouds are often harder, by far, to penetrate. Even if they are outside of the operators’ control, the public clouds will be much harder to breach than those of an operator, since the security measures of public clouds are much more robust, and their ability to withstand external attacks is much stronger, since their existence depends on it.
However, there are services, for example, where latency is a critical issue that may never, at least in my lifetime, be entrusted to a public cloud. You cannot run everything remotely, there are still physical limitations given today’s technology. In those cases, such as the fronthaul and Layer 1 service, you need to find a way to put the cloud on the edge and not to bring the edge to the cloud. For all intents and purposes, from an end-user perspective, it is in the cloud.
It is a process. Parallel Wireless has managed to bring the cloud close to the edge, as is reflected in our BBU. There can still be differences in latency, but once that is dynamically measured, the services can be placed in accordance with the capabilities and resources. There are different levels of Edge, and the distance can be from meters up to kilometers, but not more than a few hundred KM. Further than that, the latency will be too great.