Through the development of detailed specifications of the interfaces in Figure 1 the O-RAN Alliance has enabled an ecosystem where, for instance, vendor A can connect their implementation of a Control Unit component’s User Plane to vendor B’s implementation of a Distributed Unit component using the detailed F1-u interface specification [3]. This is a significant step towards interoperability, but many challenges remain to get to a truly interoperable ecosystem.

As shown in Figure 2, even though interoperable interfaces are in place we need to develop an ecosystem that allows construction of the complete RAN from the detailed system level specifications of the end user operator or enterprise customer. One way to do this is the use of Blueprints [4], but these amount to the construction of a set of reference designs and the need for blueprints underlines the difficulty in satisfying a unique system deployment requirement from a collection of communicating components. Also, it is unreasonable to expect that such system level reference designs will continue to be developed, essentially for free, by O-RAN affiliated companies, to cover all possible RAN scenarios. In any specific deployment there remains a critical role to be played by a systems integrator in taking all of the components and putting them together.

Unlike the big traditional OEMs, in the Open RAN multi-vendor scenario the system integrator will not have ready access to the engineers who developed the components that make up the RAN system. Though these components will talk to each other in a robust manner, they are unlikely to be optimized to perform well when integrated together for a particular system requirement. Think of it like a car that is made from parts shipped from manufacturers all over the world; wheels, engines, suspensions and so forth. The car system integrator is then given a set of specifications to build a dune buggy. But she is not clear on which wheels combined with which suspension and which braking system, will meet the system requirements. In fact, the exact suspension system required to be combined with the best wheels for traction on the beach may be a redesign of one of the options she managed to procure off the shelf. Backing this car analogy up into our O-RAN problem, for a specific use case, to get an optimized solution for power or performance, components will have to be tuned together by the system integrator to get to the best solution possible. So, it is more complicated than simply plugging things together. Blueprints allow motivated organizations to open-source potential solutions for general classes of use case, but they will not necessarily fit the use case or traffic model that the system integrator has. Building a system from components you can readily procure may make for a fantastic Johnny Cash song [6] but not a satisfactory RAN deployment.

In fact, O-RAN’s success will lead to a proliferation of O-RAN deployments, driving a wide ecosystem of Software and Hardware vendors providing various open RAN components, delivering choice and flexibility for Operators and Enterprises. This wider ecosystem then creates a new challenge of multivendor integration and optimizations across a wide variety of use cases and traffic scenarios. Johnny Cash is now trying to build his dream car by stealing parts not just from Cadillac but also Nissan, Fiat and maybe a Tesla electric drive thrown in for good measure. So how to solve this new problem?

The answer is Domain Specific Languages (DSL) and Automation, and it isn’t even a new idea!

2. Machine Learning Shows the Way: Develop a DSL and Automate Deployments

We summarize the challenges facing O-RAN system integration in Figure 3. These constraints are similar to those that faced the Machine Learning (ML) community a decade ago. Each Machine Learning problem was a unique deployment but implementation on a particular platform was complicated and error prone. The ML community turned to the use of Domain Specific Languages (DSLs), for instance TensorFlow [7] and TVM [8], which allowed them to write specific ML deployments abstracted from implementation details, and, critically, to automate the deployment of these programs onto multiple platforms. A similar trick can be performed in the RAN deployment space with the development of a DSL specifically focused on RAN construction, specification, and constraints.

For any DSL to be useful you must be able to “compile” the language onto a variety of platforms. In this case this compilation means intelligent and domain specific automation that can solve the NP-complete problem of mapping the RAN deployment for a particular set of system constraints on a particular hardware target, essentially a synthesis of the solution from the DSL description. It is critically important that the DSL is not simply “syntactic sugar” that provides a more human pleasing syntax in which to develop code. It must also expose the opportunity for automation of some of the hardest tasks in deployment onto hardware which is becoming more heterogeneous and specialized. Any DSL must allow for code portability simultaneously with optimality for a particular platform.

In order to implement the constructive description of a DSL on a platform we need an abstract description of the hardware platform. We believe the current effort in O-RAN WG6 to define extensions to the AAL [9] will allow for a suitable hardware abstracted platform description. The DSL concept we describe here is very synergistic with the current O-RAN efforts and can be seen as the “missing piece” to allow full automation of RAN system integration.

Intelligent automation and an open-source RAN domain specific language (like Cirrus360 RDSL™ shown in Figure 5) facilitates interoperability, that is flexible enough to encompass a wide variety of use cases across vendors and deployments. This extends the current O-RAN framework by advancing two important goals: software hardware disaggregation via abstraction and enabling a new level of control of multi-vendor components in the process of system integration.

3. Unlock the Potential of the RAN Intelligent Controller (RIC) Using DSL

The RAN Intelligent Controller (RIC) stands out as a new and important concept introduced by the O-RAN Alliance. The enablement and success of the RAN Intelligent Controller (RIC) interfaces is a critical goal for O-RAN adoption. RIC adoption in the O-RAN community and actual O-RAN deployments can be greatly accelerated if we can overcome the difficulty in aligning the functionality supported in the O-RAN components (such as DU and CU) that is currently exposed on the RIC interface with the need for new analytics in the RIC to unlock new opportunities to enhance the RAN performance. This need has already been recognized in the industry [10] [11].

Therefore, the RIC is a great example of the need for a DSL in the development of components in the O-RAN deployment because the DSL allows new functionality, in this case new analytics or system control hooks, to be added to an existing component if it has been developed using a DSL. In Figure 4 (a) we show the current architectural predicament, with a new RIC app that requires analytics from the DU in this example that the current DU deployment simply doesn’t provide. This is not an interface issue; it is a functionality issue. Figure 4(b) shows the obvious solution to this problem, which is an addition of a new function to the DU to support the new RIC app. But, of course, this requires a redeployment of a DU that is slightly changed from the current deployment, which in turn requires the system integrator to negotiate a new contract with the DU vendor and is generally a long and painful process that can discourage innovation in the RIC. Automation of this process via a DSL provides a viable answer to unlocking the RICs full potential for O-RAN.

So, automation of RAN deployment becomes a key enabler of the value of the RIC and therefore part of the key value chain of O-RAN itself.

4. An Example of RDSL Use for RAN Deployment

To briefly give the reader an idea of what a DSL for RAN might look like, in Figure 5 we include a code snippet from a complete deployment, using the Cirrus360 RDSL™. RDSL™ follows the principles laid out by the pioneering work of the Delite and Lingua Franca teams [12] [13], with a simple, declarative, immutable, and time cognizant syntax. In our RDSL™ we use inspiration from the Delite DSL framework to develop a language that is declarative rather than imperative (so the programmer describes what to do, not how to do it) and which exposes opportunities for optimization as it is immutable (variables are assigned a value only once). Lingua Franca is a great example and inspiration for anyone wanting to develop a language that is time aware and suitable for real time system descriptions.  The RDSL™ descriptions are therefore intuitive to a human programmer but offer a precise description for real time deployment automation. We use a format similar to that used in O-RAN’s AAL [9] to describe the target platform as well as other system constraints. The deployment can now be automated. We believe that the technology to develop and optimally deploy using DSLs is now well understood, and a decade after the success of Machine Learning, the time has come for O-RAN to embrace Domain Specific Languages.

5. Conclusions

O-RAN has made amazing progress in disaggregation of the components of the RAN to allow for multivendor deployments, and examples exist today in the field of this success. In order to keep the momentum, O-RAN now needs to embrace Domain Specific Language descriptions to extend disaggregation between software and hardware, and within software modules in a O-RAN component, rather than just across interfaces. This will allow disaggregated and multivendor solutions to truly compete with the classical closed box solutions in performance and lifecycle maintenance, while outpacing them in new innovation and cost.  The time has come for O-RAN developers to embrace the DSL concept and leverage its benefits to produce RAN components that outperform traditional solutions in agility, reliability, and performance. At the ecosystem level, O-RAN standardization of a DSL can expedite system integration and provide an even greater level of plug-and-play interoperability between components from multiple companies.