Q: What are the key success factors in any vRAN operator project?

Organisations that deploy a few plug-and-play vRAN cells, such as the Open Radio Station (ORS), are outside the scope of this FAQ.

A: We define a vRAN operator as an organisation that deploys vRAN infrastructure used by third parties. Public vRAN infrastructure is used by consumers in public areas such as streets or roads. Private vRAN infrastructure is used by selected users in a private area, such as a factory. Both infrastructures consist of hundreds to hundred thousands cells.

In most public or private infrastructures, cell hardware and software is sourced from Ericsson, Huawei, Nokia or ZTE. However, with the tremendous progress of personal computing and open source software, an alternative approach based on software defined radio is increasingly adopted and known as "virtual radio access network" (vRAN). 

Based on 10-year observation of numerous vRAN operator projects, the four main success factors in any project to deploy a public or private vRAN operator are:

1. select Amarisoft virtual eNodeB/gNodeB technology;
2. acquire Amarisoft-based network simulator;
3. acquire support from Rapid.Space for SlapOS open source NMS/OSS/BSS;
4. (only for greenfield projects) deploy immediately a model infrastructure of dozens of Open Radio Station (ORS).

Let us explain each success factor.

The first success factor is to rely on Amarisoft virtual eNodeB/gNodeB. As of March 2026, other virtual eNodeB/gNodeB (OAI, SRS, Arraycomm, FlexRAN, etc.) either lack some important 3GPP features, or lack performance, flexibility, stability, efficiency, etc. in a context of commercial deployment. Amarisoft proprietary competitors still lack wide coverage of 3GPP features. Availability of commercial grade, open source, eNodeB/gNodeB is still years ahead, if ever, whereas Amarisoft source code licensing option provides a practical compromise for large scale deployments.

The second success factor is the ability to acquire ASAP a 4G/5G network simulator based on Amarisoft for test measurement tool. This can be one of:

• Rapid.Space TestPOD (CallPOD variant);
• Amarisoft Callbox.

A 4G/5G network simulator is mandatory for three purposes:

• optimise the eNodeB/gNodeB configuration of the network in the lab;
• debug buggy smartphones (sadly, many of them) before blaming the infrastructure;
• analyse spectrum, decode symbols on the field, and detect illegal occupation of the spectrum.

Test and measurement tools from other brands can be used, especially for UE simulation. However, even if such tools are already available, an Amarisoft-based 4G/5G network simulator will always be mandatory to optimise the configuration of an Amarisoft-based 4G/5G vRAN infrastructure.

The third success factor is to rely on existing NMS/OSS/BSS compatible with Amarisoft rather than trying to reinvent one, at least in a first phase.The only reliable, open source, NMS/OSS/BSS for Amarisoft is SlapOS. By using SlapOS, a vRAN operator project will save at least 2 years. Since NMS/OSS/BSS are rather complex systems, of similar complexity with an ERP, support is necessary, at least in first phase. 

The role of the NMS/OSS/BSS is to automate the lifecycle of a network (build, allocate, instantiate, etc.) in order to reach fully automated reproducibility, and thus proven stability. However, most project teams focus mainly on trying all possible configurations of the different components rather than on end-to-end automation; this is similar to software developers who write code but do not write tests, do not use continuous integration frameworks and endlessly fix regressions in the production environment. Some project teams understand the need for end-to-end automation but underestimate the effort that is required to achieve it and, therefore, realize too late that they will lack time to finalise it under strict deployment schedule and limited human resource constraints.

The lack of focus on the NMS/OSS as an essential tool for quality assurance is the No 1 factor of failure of commercial vRAN deployment projects.

Here are some examples of vRAN project failures we observed. Each project first acquired hardware and software components: BBU, RU, Amarisoft, etc. Then, the following happened:

1. the project team tried to configure components manually, upgraded one of them, got a failure from the other, repeated the process and, after two years failed to stabilise anything, before dropping everything and switching to traditional RAN; 
2. the project team used their existing NMS, which collects key performance indicators (KPI) and counters, but does not handle the 11 other mandatory facets (build, allocate, instantiate, etc.) required to reach reproducibility, and was thus unable to stabilise their network due to the ever evolving firmware or software of the different components;
3. the project team tried to develop their own NMS based on Kubernetes and, three years after, no product or service is being delivered, because a vRAN NMS is as complex as a cloud operation management system, because of Kubernetes technology (not portable, not reproducible, not complete, too complex for small teams) and because most mobile network operators have failed in the last twenty years to develop their own cloud software.

Among the commercial vRAN deployment projects, based on Amarisoft, that succeeded without SlapOS, we are aware of only two cases: a large team (100+ staff) that created in two years their own NMS/OSS through massive extensions of Kubernetes, and a one-person team that created in two years a limited-scope NMS/OSS based on configuration management frameworks. However, SlapOS vRAN did not exist at that time. Nowadays, it would not make much sense to wait two years and spend cash rather than adopting an existing, freely available, plug-and-play, open source solution which handles the 12 facets of network operation and can be integrated to umbrella NMS.

The fourth success factor is to start small with an Open Radio Station (ORS). This fourth success factor only applies to greenfield projects, that is projects that aim at creating a new infrastructure rather than extend an existing one. We observe that vRAN projects that start small with an Open Radio Station (ORS) have more success than projects that start with high-power radio units. The reason is simple: a small, all-in-one system is sufficient to conduct most tests, including range tests, handover tests, interoperability tests, pilots, etc. It is also sufficient to prepare and plan the business process of the future network. Because ORS is small and lighter, it is faster, easier and cheaper to install on the field.

Also, one should remember that power does not bring more range in 4G/5G networks. Power is only useful to bring more download speed whenever the number of active users is high. With few users (less than 20), a 2x1W system will provide the same performance as a 2x20W system. Therefore, Open Radio Station (ORS) is ideal in the design phase of a 4G/5G network with few users. This design phase includes both technical aspects (radio planning, core network, configuration) and business aspects (subscription, management panel).

Starting with ORS will save at least one year in a commercial greenfield vRAN deployment project. Then, once the network is designed, it is possible to complement Open Radio Station (ORS) with traditional, high-power radio units and macro-stations.