Dual-Use Commercial and Military Communications on a Single Platform using RAN Domain Specific Language

TL;DR

This paper introduces RAN Domain Specific Language (RDSL) and a system solver platform to automate and optimize the construction of Radio Access Networks, especially for specialized military deployments, improving power and latency performance.

Contribution

The paper presents a novel RAN Domain Specific Language (RDSL) and a system solver platform that automate RAN configuration, enabling non-expert modifications and optimized deployments.

Findings

RDSL enables declarative specification of RAN requirements.

Automation with Gabriel(TM) improves power and latency over manual configurations.

Constraints formatted in YAML facilitate integration with automation tools.

Abstract

Despite the success of the O-RAN Alliance in developing a set of interoperable interfaces, development of unique Radio Access Network (RAN) deployments remains challenging. This is especially true for military communications, where deployments are highly specialized with limited volume. The construction and maintenance of the RAN, which is a real time embedded system, is an ill-defined NP problem requiring teams of specialized system engineers, with specialized knowledge of the hardware platform. In this paper, we introduce a RAN Domain Specific Language (RDSL(TM)) to formally describe use cases, constraints, and multi-vendor hardware/software abstraction to allow automation of RAN construction. In this DSL, system requirements are declarative, and performance constraints are guaranteed by construction using an automated system solver. Using our RAN system solver platform, Gabriel(TM) we show how a system engineer can confidently modify RAN functionality without knowledge of the underlying hardware. We show benefits for specific system requirements when compared to the manually optimized, default configuration of the Intel FlexRAN(TM), and conclude that DSL/automation driven construction of the RAN can lead to significant power and latency benefits when the deployment constraints are tuned for a specific case. We give examples of how constraints and requirements can be formatted in a "Kubernetes style" YAML format which allows the use of other tools, such as Ansible, to integrate the generation of these requirements into higher level automation flows such as Service Management and Orchestration (SMO).