in Barcelona

General experimentation capabilities

The CTTC 5G testbed allows creating multiple testbed instances (TI). Each TI is a Network Function Virtualisation (NFV) ecosystem. This allows sharing the same testbed physical infrastructure and building different subtestbeds according to the experimentation needs of each use case (UC). A testbed instance may include:

  • Computing capabilities (CPU, GPU, edge, cloud)
  • 5G network capabilities (including UEs, RAN, and core)
  • Other devices

A global view of the CTTC testbed is presented in the following figure.

The 5G CTTC Testbed

The left part corresponds to generic purpose servers over which the testbed instances deploy their VMs or containers. Though the configuration of this part is flexible, this component can be seen as the cloud datacenter of the scenario under evaluation.

The lower part corresponds to edge servers which may be either generic purpose servers or those equipped with GPUs for offering services to demanding URLLC applications (e.g., VR).

Since the goal is to create testbed instances on top of the shared infrastructure, LXD is exploited to create system containers and virtual machines that are part of the NFVI infrastructure of the testbed instance. Inside each testbed instance, the user can decide the management and orchestration stack to deploy, which may include, for instance, OSM, Kubernetes or Openstack.

There are multiple flavors of 5G mobile network that can be used consisting of combinations of commercial and open-source hardware and software. Multiple real and emulated 5G devices can also be used in each testbed instance. The following sections describe in more detail each component.

Computing capabilities

The basic computing capabilities consist of 10 servers with a total of 456 central processing unit (CPU) cores, 2632 GB memory, 58 TB storage, and 6 graphic processing units (GPUs) distributed in two servers.

For edge computing, there are 10 machines with a total of 40 cores, 147 GB memory, and 2.5 TB storage.

It should be noted that the available GPUs can be virtualized for containers/VMs.

The following picture shows the CTTC testbed including the 5G network equipment.

Part of the CTTC 5G Testbed showing some of the servers and the Amarisoft 5G equipment
Part of the CTTC 5G Testbed. EXTREME Testbed ®

Additionally, more servers, networking, and measurement equipment can be made available from another testbed of the Services as networkS (SaS) group, namely the EXTREME Testbed®, shown in the following picture.

5G Core capabilities

The 5GC (and RAN) can be deployed either through commercial products, i.e., the Amarisoft CallBox, or through open-source solutions integrated with Universal Software Radio Peripherals (USRPs).

More specifically, the CTTC testbed consists of a variety of 5GC, namely

  • Amarisoft 5GC, as part of the Callbox
  • Containerized Open5GS
  • Containerized OpenAirInterface

The main characteristics of the Amarisoft 5GC are:

  • Network Elements: AMS, AUSF, SMF, UPF, UDM and 5G-EIR (all integrated within the same software component)
  • 3GPP Release 16
  • NAS encryption and integrity protection: AES, SNOW3G and ZUC
  • Configurable QoS flows
  • Support of multi PDU sessions
  • Support of NR, LTE, NB-IoT and non-3GPP RAT
  • Slices are supported in the 5GC (and gNB) of the Callbox but operate in best effort mode

For more information, you can check the Amarisoft Callbox datasheet:


The main characteristics for the Open5GS are:

  • Open Source implementation for 5G Core and EPC
  • 3GPP Release 16
  • 4G/5G NSA Core and 5G SA Core
  • AES, Snow3G, ZUC algorithms for encryption
  • Support of USIM cards using Milenage
  • Support of multi PDU sessions

You can find more information about Open5GS at https://open5gs.org/

Additionally, other 4G cores have been used previously and could as well be deployed for comparison purposes if needed:

  • Containerized Magma

This offers a lot of flexibility in the deployments to be capable to better adapt to the requirements of any UC and for comparison purposes.

Additionally, srsRAN can be used for 4G scenarios, and soon will offer 5G.

5G RAN capabilities

The FR1 band is supported in NSA and SA scenarios. Additionally, 4G scenarios can as well be deployed.

The testbed features come from the Amarisoft RAN, as part of the Callbox equipment:

  • One Amarisoft Callbox Ultimate
  • Two Amarisoft Callbox Mini

The main characteristics of the Amarisoft gNodeB are:

  • 3GPP Release 16
  • FDD/TDD FR1 (< 6GHz)
  • Bandwidth up to 100 MHz
  • Up to MIMO 4×4 in UL and DL
  • Subcarrier spacing. Data: 15, 30, 60 or 120 KHz; SSB: 15, 30, 120 or 240 KHz
  • Modulation schemes up to 256QAM in DL and UL
  • Supported modes: NSA and SA
  • Network interfaces: NG interface (NGAP and GTP-U) to 5GC and XnAP between gNodeBs
  • Carrier Aggregation up to 8 DL carriers in SA and NSA
  • Max number of 5G cells: 8
  • 5QI support
  • Slices are supported in the gNB (and 5GC) of the Callbox but operate in best effort mode
  • APIs for monitoring several metrics that could feed the monitoring system
  • APIs for configuring some parameters of the RAN

For more information, you can check the Amarisoft Callbox datasheets:



Additionally, srsRAN can be used for 4G scenarios, and soon will offer 5G.

5G Devices

The UE in the testbed is either:

  • 5G SA CPE (Huawei 5G CPE Pro 2), which enables connecting WiFi-only devices to the 5G network
  • 5G NSA smartphones (Two iPhone 12 Pro Max and One OnePlus 8)
  • 5G emulated UE through Amarisoft SimBox (able to emulate up to 64 UEs), and
  • Other (for the moment) non-5G equipment, e.g., MS HoloLens, which may be connected to the 5G network in different ways (e.g., 5G CPE that provides WiFi connectivity).

The Amarisoft Simbox also includes a channel simulator. The main configuration options of this channel simulator include:

  • Position, speed, and direction of the UEs
  • Channel type
  • Number of antennas
  • Noise spectral density
  • Reference signal power
  • UL power attenuation

Monitoring capabilities

For monitoring the physical/virtual resources, Netdata and/or Prometheus can be used. Custom-made monitoring systems developed in other projects may as well be used. This enables monitoring any metric from the RAN to the core and application and visualizing it. An instance of RabbitMQ supports a message-passing service.

Management and orchestration capabilities

This infrastructure is shared among multiple projects and researchers; therefore, virtualisation is essential. LXD is the main virtualisation technology that allows CTTC to create a virtualisation experimental environment called Testbed Instance. In general, the Virtual Network Functions (VNFs) are orchestrated by Open Source MANO (OSM), which uses Kubernetes and/or OpenStack as the Virtualised Infrastructure Manager (VIM), but this can be adapted depending on the testing needs. The computing resources managed by these VIMs are either VMs or Docker containers. Karmada is used to implement the multi-domain Kubernetes clusters.