Skip to main content
IEEE CTN
Written By:

Alan Gatherer, Chaitali Sengupta, Sudipta Sen, Cirrus360 Corporation

Published: 25 Sep 2023

network

CTN Issue: September 2023

A note from the editor:

Open RAN is a well-known network architecture that has gathered lots of interest from many parties over the last several years.  Most of us are aware of what Open RAN promises and the challenges that the ultimate road to success presents.  Some claim that the key to success is related to the required collaboration between various stakeholders, including service providers, equipment vendors, and regulatory bodies.  Beyond this there are network performance concerns, system integration challenges, potential security risks and the ability to effectively manage, program and maintain such diversely constructed networks. While disaggregating across defined interfaces has been the primary focus until now, disaggregating between software and hardware components is perhaps the holy grail. 

In this month, we welcome back to CTN Alan Gatherer, a veteran of many communication industry domains and long-term Editor in Chief of CTN.  Alan is now with Cirrus360, and they are focusing on how to solve some of these challenges and reach the above mentioned “holy grail”.  Cirrus360 believes that Domain Specific Languages hold the key to unlocking the full potential of Open RAN networks.  We are happy to present this different aspect of communications technology in this month’s edition of CTN.

Miguel Dajer, CTN Editor-in-Chief

Domain Specific Language: The Next Step in Open RAN Automation

Alan Gatherer

Alan Gatherer

Co-founder Cirrus 360

Cirrus360 Corporation

Chaitali Sengupta

Chaitali Sengupta

Co-founder Cirrus 360

Cirrus360 Corporation

Sudipta Sen

Sudipta Sen

Co-founder Cirrus 360

Cirrus360 Corporation

1. Open RAN: Are We Done Yet?

Open RAN, as developed by the O-RAN Alliance, is designed to allow multiple vendors to participate in the construction of a Radio Access Network, a process generally described as disaggregation of the RAN, using well defined interfaces as show in Figure 1. Though most of the interfaces in this diagram were originally specified in the 3GPP standard body, the O-RAN Alliance has done much of the detailed work to make them truly interoperable. The O-RAN Alliance has also been notable in its addition of the RAN Intelligent Controller (RIC) interface, that we shall discuss more later. The Telecom Infrastructure Project (TIP) and others have put the effort into reference implementations and interoperability plug fests [1], and thanks in part to  government funding O-RAN testing and compliance labs are now beginning to spring up [2].

Figure 1: ORAN Architecture Diagram (https://docs.o-ran-sc.org/en/e-release/architecture/architecture.html)
Figure 1: ORAN Architecture Diagram (https://docs.o-ran-sc.org/en/e-release/architecture/architecture.html)

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.

Figure 2: Open RAN system integration challenges. Graphic from [5]
Figure 2: Open RAN system integration challenges. Graphic from [5]

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.

Figure 3: Open RAN system integration challenges
Figure 3: Open RAN system integration challenges

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.

Figure 4: Evolution of RIC support with open box DU
Figure 4: Evolution of RIC support with open box DU

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.

Figure 5: Example RDSL™
Figure 5: Example RDSL™

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.

References

  1. TIP, "Test and Integration," [Online]. Available: https://telecominfraproject.com/test-and-integration/.
  2. O-RAN Alliance, "Testing and Integration," [Online]. Available: https://www.o-ran.org/testing-integration.
  3. NTIA, "5G Challenge," [Online]. Available: https://5gchallenge.ntia.gov/.
  4. TIP, "Blueprints," [Online]. Available: https://exchange.telecominfraproject.com/blueprints.
  5. Deutsche Telekom, Orange, Telecom Italia (TIM), Telefónica, Vodafone, "BUILDING AN OPEN RAN ECOSYSTEM FOR EUROPE," November 2021. [Online]. Available: https://www.vodafone.com/sites/default/files/2021-11/building-open-ran-ecosystem-europe.pdf.
  6. J. Cash, "One Piece at a Time," 1976. [Online]. Available: https://www.youtube.com/watch?v=uErKI0zWgjg.
  7. Tensorflow, "Tensorflow," [Online]. Available: https://www.tensorflow.org/.
  8. Apache, "TVM," [Online]. Available: https://tvm.apache.org/.
  9. O-RAN Alliance, "O-RAN Working Group 6. O-RAN Acceleration Abstraction Layer General Aspects and Principles, O-RAN.WG6.AAL-GAnP-R003-v06.00," 2023.
  10. X. Foukas, B. Radunovic, M. Balkwill and Z. Lai, "Taking 5G RAN Analytics and Control to a New Level," [Online]. Available: https://www.microsoft.com/en-us/research/uploads/prod/2022/12/JanusTechnicalReport.pdf.
  11. D. Soldani, "Introducing Rakuten Telecom eBPF," Rakuten Symphony, [Online]. Available: https://symphony.rakuten.com/blog/introducing-rakuten-telecom-ebpf.
  12. K. Olukotun, "High Performance Domain Specific Languages using Delite," 2012. [Online]. Available: https://ppl.stanford.edu/papers/CGO2012-1.pdf.
  13. M. Lohstroh, "Toward a Lingua Franca for Deterministic Concurrent Systems," 2021. [Online]. Available: https://dl.acm.org/doi/10.1145/3448128.

Statements and opinions given in a work published by the IEEE or the IEEE Communications Society are the expressions of the author(s). Responsibility for the content of published articles rests upon the authors(s), not IEEE nor the IEEE Communications Society.

Sign In to Comment