Recent versions of ors-amarisoft are able to support different models of radio units (RU) at the same time. A single enb process can be shared by multiple radio units from different vendors, which is a first step towards interchangeable radio units
A typical use case for interchangeable consists of the following steps:
- deploy a macro-station with 3 sectors, each of which with 2 carriers;
- deploy the macro-station with a given vendor (ex. Lopcomm 4x40W, Nokia 4x40W);
- after failure of one radio station, replace the radio unit with the one from another vendor (ex. AW2S 4x40W, VHT 4x40W).
Achieving this use case is quite challenging considering the typical behavior of radio unit vendors. Even though standards such as CPRI exist, some radio unit vendors make sure interchangeability is impossible by:
- encrypting IQ samples exchanged between the BBU and the RU;
- controlling the init sequence of electronic components of the RU from the BBU rather than through a CPU or micro-controller onboard the RU.
The goal of some vendors is to prevent interchangeability of both BBU and RU as a trick maximise profits.
Achieving interchangeability is however possible with an Amarisoft BBU thanks to its trx_driver API. Anyone can extend Amarisoft enb process and support new ways to exchange IQ samples:
- through eCPRI instead of CPRI;
- through a variety CPRI PCIe adapters (Amarisoft, AW2S, etc.);
- through PCIe (Amarisoft SDR, Rapid.Space ORS);
- through yet-to-be defined protocols (ex. Ethernet).
Through its configuration file, Amarisoft BBU provides some kind of standardised way to configure the connection of a BBU and a RU, at least for two aspects:
- synchronisation (how the BBU and the RU synchronise each other);
- signal exchange (how the BBU and the RU exchange IQ samples).
However, management of the RU is partially or not taken into account by Amarisoft configuration file. Recent radio units will instead use a Netconf-based protocol with yang models dedicated to radio units. This is the case of all Lopcomm models as well as future models by AW2S.
In this context, interchangeability is mainly a matter of agreeing on a common set of parameters in yang models and in Amarisoft configuration file. This is what we have tried to capture in the JSON Schema used in all vRAN deployments of Rapid.Space.
For example, the bandwidth parameter is common to all types of radio units (it is implemented by Amarisoft configuration file):
"bandwidth": {
"title": "Bandwidth",
"description": "Downlink Bandwidth",
"type": "string",
"enum": [
"1.4 MHz",
"3 MHz",
"5 MHz",
"10 MHz",
"15 MHz",
"20 MHz"
],
"default": "20 MHz"
Let us now look at the center frequency parameter of Lopcomm RU:
"txa0cc00_center_frequency": {
"title": "Lopcomm ORAN DL Center Frequency in MHz (TXA0CC00)",
"description": "Lopcomm ORAN Center Frequency in MHz (TXA0CC00)",
"type": "number",
"default": 2140
},
What we can observe is that the TX/RX carrier is named conventionally according to ORAN's eAxC ID (The a0 indicates the DU port and the cc indicates the carrier.). It is however described for now as a Lopcomm specific specific parameter.
The same parameter for the ORS is more generic but is also defined in a dedicated JSON schema:
"tx_gain": {
"title": "Tx gain",
"description": "Tx gain (in dB)",
"type": "number"
},
The same concept (TX Gain) is thus implemented through different parameters for each model of RU, leading to the impossibility to interchange them without redefining all values.
The same problems can happen with Fault Management (FM) which is implemented through SlapOS promises. Unless a common set of promises is defined, with common interface and multiple implementations (one per RU model), interchangeability will not be possible.
There is however one case for which interchangeability is already achieved: Performance Management (PM). The xlog library, through indirection, can produce a common log format, can produce common log files that can be processed by generic code independently of the RU model.
Overall, more effort is needed to ensure that all models of radio units can share a larger set of common parameters and promises in order to achieve interchangeability. This work has already started (here and here) and will eventually lead to fully interchangeable radio units.
Roadmap
With the integratoin of more RU vendors into Rapid.Space NMS, we will offer increasingly universal parameter names. For example, in the next version that will be released in 2024, all parameter names with a vendor specific style will be replaced to TRX general parameters by pre-programming the endpoints of the RU's configuration:
{%- for ant in range(n_antenna_dl) %}
{%- set port = ant // 2 %}
{%- set chan = ant % 2 %}
{%- set txep = 'TXA0P%02dC%02d' % (port, chan) %}
Root password and m-plane source code
Achieving interchangeability of radio units requires access to root password and m-plane source code.
Unlike previous radio units such as those produced by Ericsson, recent radio units are autonomous Linux systems that need to be updated or modified to meet cybersecurity standards or “front-haul” network constraints. During pilot phase of a project, root access to the embedded Linux OS of the radio unit can be mandatory to make minor changes to the operating system configuration without having to wait for a new release from the radio unit vendor. In a recent deployment project involving Rapid.Space, access to root password of the radio unit was instrumental to meet all requirements of the front haul network. Without root password, the project would have failed. For similar reasons, interchanging one radio unit with another from a different vendor requires, most of the time, minor changes of the embedded Linux OS of the new radio unit model and thus, requires root password access.
During the commercial deployment phase, access to the source code of radio unit m-place is essential. As any other company, current radio unit vendors can face management changes or other major changers. In case of bankruptcy or poor cooperation of the radio unit provider, having access to the source code of the management plane can save an infrastructure. Conversely, not having this source code can lead to having to rip and replace radio heads whose embedded Linux OS is no longer evolving and therefore no longer complies with the legal cyber security requirements (e.g. CRA regulation in EU) or poses compatibility problems in case of evolution of the front-haul configuration (e.g. change of ssh key types for the m-plane, switch to IPv6, etc.). Some changes in front-haul configuration could be imposed for compatibility reasons with new radio units models introduced in the infrastructure. Without access to the source code, there is no way to guarantee that future radio units are interchangeable with current radio units.
Notes
There is one limitation in Amarisoft stack: only one single trx driver can be used at the same time (ex. only CPRI, only PCIe SDR, etc.). Supporting both SDR (PCIe) and CPRI at the same time is not planned currently by Amarisoft, although this could change in the future.
References