The following picture is an overview of the currently chosen architecture.
Note that in the previous picture, the term node is used in the Jenkins terminology as a remote server where the processing is "farmed out". It is not related to the 4G eNB / 5G gNB terminology.
The name of the server are generic to describe their function. Typing ssh nodea.eurecom.fr will result in an error.
The Jenkins service is hosted on oailab.eurecom.fr server. The requirements for such a service:
The remote node where the Jenkins Declarative Pipeline will be executed is selected in 2 ways:
def pythonExecutor = params.pythonExecutor
The first method is fundamental for the master CI job since it requires a remote note with:
uvt-simplestreams-libvirt sync arch=amd64 release=xenial
The second method is fundamental for the slave jobs since scripts are template and most of the job information are parameters of the Jenkins job. It allows us to have a modular approach.
This server is dedicated to eNB continuous integration effort. Developers SHALL be using another server for development work since CI can be triggered at anytime and can start/stop EPC functions.
In our eNB CI environment, usually we connect only one eNB at once and only a few COTS-UE. So the processing requirement is not that high.
We are using 2 variants of EPC:
When testing with real COTS-UE, these servers are connected with Hard-ware Radio equipment. These have important requirements for real-time and CPU processing.
Currently they are all under Ubuntu 16.04 LTS OS.
Each server is dedicated to a given RF configuration:
Currently on 4G LTE COTS-UE, we are using Android 7+ smartphones. Given that choice we are enabling the developer's option in order to be able to control them through the ADB interface.
CPU load is negligeable.
We are planning to have several Faraday Cages with different kinds of UEs when available (nbIOT, catM, 5G-NR...)