The CNIT S2N testbed is a multi-layered hardware and software facility for the advanced experimentation and demonstration of 5G, Edge and Cloud Computing technologies. The testbed is specifically conceived to host multiple isolated trials, and to manage and to configure hardware and (virtual) software resources through a Metal-as-a-Service (MaaS) approach.

At hardware level, the testbed is composed of:

• more than 20 high-end servers providing more than 600 physical CPU cores, 1.7 TB of RAM and 100TB of high-speed SAS and SSD storage. Each server is provided of high-speed Network Interface Cards (NICs) with dual 10/40/56Gbps Ethernet ports, supporting hardware acceleration, SR-IoV, and high-performance time synchronization (IEEE 1588).
• 10 SDN switches, for a total of more than 1000 ports, with a speed spanning from 1 to 100 Gb Ethernet, and a total L2/L3 forwarding speed of more than 10 Tbps.
• A hardware firewall to isolate the experimentation domains, capable of handling the traffic at 20Gbps.
• 2x professional network traffic hardware generators, able to collect latency measures with a 10ns precision.
• 5x smart Power Distribution Units (PDUs), able to collect the energy consumption of any hardware elements in the testbed.
• 2x Amari LTE CallBox Pro, a SDR device that can be programmed as a 5G New Radio (NR) base-station (i.e., gNodeB) or as 6x LTE eNodeBs; and further 3x eNodeBs based on commercial Amarisoft products or on open-source projects (e.g., SRS LTE) and USRP B210 boards from National Instruments.
• 10+ heterogeneous User Equipment (UE), including connected drones, NB-IoT devices, smartphones/tablets, and high-speed customer premises equipment.
• 1x Precision Time Protocol v2 Gran Master Clock to synchronize the local devices against the GPS time reference with a maximum lag of 200 ns.

A central testbed management application is in charge of providing server, network and radio resources as-a-Service to all the experimentation domain, and properly install and configure (the entire or part of) the CNIT S2N 5G software framework in less than 15 minutes (this time includes also the re-installation of the Operating Systems in the servers).

The CNIT S2N 5G software framework is composed of:

• Virtual Infrastructures Managers, i.e., OpenStack instances to control pools of servers. Each OpenStack instance is meant to represent a datacenter within the Telecom Operator Network, and it is used to host both virtual network functions and edge-computing/5G vertical applications.
• One or more SDN Controllers, mainly ONOS and OpenDaylight to manage the SDN switches in the infrastructure.
• A complete monitoring system based on the Prometheus database, able to export metrics from any resources in the infrastructures and also for the 4/5G virtual/physical network functions.
• One or more instances of Open Source MANO (OSM), an ETSI-driven NFV Orchestrator.
• More than 15 Virtual Network Functions to setup 4G/5G mobile radio networks, network slices, and other services, already on-boarded and controllable by OSM.
• A 5G-ready Operations Support System, developed by the CNIT S2N Lab within the context of the 5G-PPP MATILDA Innovation Action, able to control and coordinate the work of all the elements previously cited in order to set-up 4/5G network services and related slices, provide computing resources to vertical applications at the network edge, etc. The OSS is easily extensible for research purposes, given its modular internal architecture based on microservices. For example, all the optimization algorithms have been implemented on a microservice running on the SageMath platform (a well-known open-source replacement for MatLab).

Experimenters can declare which elements they need, and how many instances. The testbed management application reserves the needed hardware, it installs a fresh operating system on the servers, and deploys and configures (through the Canonical JuJu platform) the needed software elements. When this process ends, a complete 5G/edge computing platform is made available to the Experimenter, that can decide to manually interact through the Web-based user interfaces of the various elements, or to use REST-based interfaces to automate her/his tests.