Post-5G Blueprint

What is Post-5G ?

5G has introduced the concept of modularization in its design. This ubiquitous modular architecture allows the telco and IT worlds to merge, enabling remarkable innovations through the so-called Post-5G propositions.

With this, researchers now have a rich platform for experimenting with new ideas at every level. Unfortunately, deploying a complete 5G infrastructure is complex, as every detail matters. Specialists are required to choose the correct combination of software, hardware, and infrastructure locations. This complexity can pull researchers away from their primary focus, as they may need to invest significant time and resources just to set up their experimental platform.

What is the Slices Post-5G Blueprint?

The Slices research infrastructure offers an ideal platform for experimenting with real hardware, ranging from low-end edge devices to high-end datacenter servers, distributed across multiple locations and interconnected by Layer 2 network links (with real or emulated network behavior).

The goal of the Post-5G blueprint is to provide the community with a replicable set of software, hardware, and methodologies for conducting experimental research in cutting-edge Post-5G environments.

This blueprint is designed with modularity in mind, allowing flexible deployment. For instance, those focusing solely on 5G can deploy the core and use a simulated RAN, while researchers only interested in the RAN can deploy just that, provided they have access to a core (e.g., via the SLICES central hub or a partner). Advanced users can deploy both a core and multiple RANs. The blueprint also outlines a workflow to ensure reproducible research.

By integrating data storage, radio hardware (such as Radio Units and User Equipment), and supporting tools, this setup provides an ideal environment for Post-5G experiments. You can either use our OpenAirInterface-based solution or develop your own custom solutions.

Built with increasing complexity, the blueprint is explained step-by-step and supported by an open-source reference implementation that serves as a baseline for researchers to conduct experimental research and for the SLICES community to build the SLICES infrastructure. The reference implementation can be found on the reference implementation git.

With the Post-5G blueprint service, we provide a step-by-step guide for defining a 5G environment and running experiments on it. This service automatically generates the necessary OpenAirInterface 1 configuration files, along with the POS scripts required to execute experiments on the SLICES-RI infrastructure. All experimental data and metadata are published in your personal SLICES DMI environment and can be easily found through the MRS.

Note: This blueprint assumes that readers are familiar with 5G. A primer on 5G can be found in 2. Reading the 3GPP TS 23.501 architecture is recommended [3] for engineers looking to deploy this blueprint in their infrastructure.

The Post-5G Blueprint offers templates and tutorials to assist researchers in utilizing this infrastructure for Post-5G research. It integrates essential components—such as the 5G core, RAN, data management, and radio resources—into streamlined, user-friendly experiments. This demonstrates how to effectively leverage the distributed Slices infrastructure for conducting Post-5G experiments.

What can I study with the Post-5G blueprint?

Type 1 studies: Vertical service integration and testing

Researchers can utilize the infrastructure as a layered architecture, treating it as a black box that provides a complete end-to-end service while still allowing them to understand the underlying components.

Example 1: Researchers use a Post-5G infrastructure to upload raw Lidar data from their drones to their ground station, enabling the creation of real-time 3D environment models. For these researchers, the scientific focus is on computer vision rather than telecom, so 5G serves merely as a commodity. Deploying such an infrastructure would be too costly and time-consuming for them.

Type 2 studies: Software Defined Networking

Researchers aim to modify the behavior of the network itself by adopting the Software Defined Networking (SDN) paradigm. They require complex environments to validate their findings.

SLICES provides access to well-defined network function interfaces (e.g., xAPP, P4, DPDK) and KPI collection.

Example 1: Researchers proposing AI-based dynamic placement of virtual network functions with performance guarantees must validate their algorithms on high-speed, operational-like networks. They require access to terabits-per-second backbones with programmable switches to test their implementations.

Type 3 studies: Low-level development on resources

Researchers focus on the lowest layers of the network stack (e.g., PHY/MAC) and must validate and measure their findings on actual hardware.

Example 1: Researchers developing a new low-energy MAC layer for high-density IoT locations with 5G gateways need access to real hardware to assess the performance of the new MAC and measure actual energy savings.

Type 4 studies: Novel hardware

Researchers explore new hardware technologies such as antennas, Reconfigurable Intelligent Surfaces (RIS), THz radio, cryptographic functions, packet processors, and TSN devices. This hardware is often not useful unless integrated into a complete system. Researchers can insert their hardware into the infrastructure and use their time slots for testing.

Example 1: Researchers have created a new Reconfigurable Intelligent Surface and must calibrate their model when integrated with 5G user equipment, where the 5G scheduler adapts communications based on real-time QCI feedback.

Type 5 studies: Cross-topics and resources

Researchers may require a combination of resources from various topics to succeed in their research.

Example 1: Researchers are creating a digital twin of a large interconnected radio network. Real-time 3D radio emulators operate on GPU farms, and the generated workload is interconnected over a Tbps P4 SDN core. The number of UEs in the radio networks makes it impractical to test with actual UEs, thus necessitating high processing capabilities linked directly to networking equipment.

Anatomy of an experiment

In the Post-5G blueprint, an experiment is organized into several key phases, each designed to ensure a smooth workflow. The first phase involves defining the experiment and its environment, which consists of a 5G core network, a 5G Radio Access Network (RAN), and user equipment (UE). The resources used can be either virtual or physical, such as a USRP acting as a gNB in the radio network. The SLICES-RI infrastructure supports this by providing a range of computing environments, including bare metal servers, Kubernetes clusters, and virtual machines, to meet diverse user needs.

Once the environment is established, the next step is generating the experiment code, which is essentially a bash script that integrates various components to define the complete lifecycle of the experiment. This script governs the experiment’s execution by means of the POS framework, managing the interactions between different elements.

Since SLICES is a shared infrastructure, resource allocation requires a fair scheduling system. A calendar-based reservation service is used to manage resource access, ensuring fair distribution among experimenters. This calendar is integrated into the POS framework, which orchestrates the entire experiment, coordinating the execution of the experiment code on the required resources.

Upon completion of the experiment, all relevant data and metadata are collected and published in the Meta Data Registry System (MRS). The MRS serves to index the experiment results, linking them to the experiment’s code, making it possible to retrieve both the experimental outcomes and the corresponding code used for the run. This process ensures transparency and reproducibility, enhancing the value of the collected data for future reference.

The Post-5G Dashboard

To streamline the creation and execution of experiments, the Post-5G service provides a user-friendly dashboard. This dashboard includes a webshell that grants direct access to the SLICES infrastructure, allowing you to utilize all available resources—tools, software, and hardware—without needing to install anything on your local machine. Through the dashboard, you can also access the Meta Data Registry (MRS) to retrieve experiment-related metadata and data from a single location.

The SLICES Post-5G dashboard enables you to create experiment scripts and run Post-5G experiments entirely online. With just a SLICES account and a web browser, you can log into the Post-5G dashboard and start your work immediately, without any need for local software installations.

The dashboard features an assistant to guide you through defining your experiment’s 5G core and RAN settings, ensuring that the infrastructure meets your specific requirements. You begin by reserving the necessary hardware resources, such as servers, networking devices, or radio units, using a calendar-based resource reservation system.

Next, you configure the 5G infrastructure, specifying critical details like DNNs, slices, and the 7.2 split. You also define where to retrieve the experiment code that will be deployed on the infrastructure. The system then generates the required OpenAirInterface configuration, along with a POS experiment script to manage the execution on the SLICES platform.

When your reserved time slot arrives, you simply connect to the POS frontend and execute the automatically generated experiment script. Once the experiment is completed, all the data and metadata are stored in the DMI and made accessible via the MRS for easy discovery and future analysis.

Environment Initialization

Prerequisites

• You have a Slices account

• You have a basic understanding of the slices CLI

Step 1 - register to the Post 5G beta program

Post-5G experiments are carried out within the SLICES framework, where resources are structured into projects and experiments. Each experiment is associated with a project. As an early adopter of the Post-5G Blueprint Service, you’ll need to join the Post-5G beta program to access this service. To do so, visit https://portal.slices-ri.eu/invite/post5g-beta and log in using your Slices account. Enrolling in the beta program is a manual process that may take up to 1 business day (remember that we are based in Europe), so be sure to check your email!

NOTE: The Post-5G beta program is part of an open data community initiative. By joining, all your actions, code, and data within the program will be shared openly with other members.

NOTE: Once the beta phase ends, you will have the option to create or use your own public or private projects.

Step 2 - setup your environment

After you’re enrolled, you can begin setting up your Post-5G experiment. Log in with your Slices account at the Post-5G Blueprint Service and chose the project on which you want to run the experiment, in this case, select post5g-beta that should appear in the project drop down menu. From there, go to the pos Webshell section. This will open a webshell window. The Webshell comes pre-installed with POS and the SLICES CLI, so no software installation is required on your local machine. We will use this webshell in all our experiments, so make sure to carefully configure it.

Note: There is also an expert mode that uses SSH instead of the web interface, but this is out of the scope of this document.

As you are using the pos Webshell for the first time, hence the Z Shell first-use wizard (ZSh-newuser-install) will prompt you to set up your Z Shell environment. Press 0 to select the default settings, or feel free to customize your environment as you wish.

As you are using the pos Webshell for the first time, you need to register the SLICES CLI by running the following command from the pos Webshell and following the provided instructions. This manual process ensures compliance with local regulations that often require two-factor authentication.

slices auth login

This initialization process is required only the first time you use the service.

You are now ready to run your experiment!

Making your first Post-5G experiment

Prerequisites

• You have a Slices account

• You successfully registered to the Post-5G Beta program and initilized your environment (see the procedure)

• You have a basic understanding of the slices CLI, the notions of projects and experiments

• You have a basic understanding of kubernetes and containers

• You have a good understanding of the 5G architecture

Important: It is NOT POSSIBLE run this experiment directly from your own machine. It is mandatory to use the Webshell we provide.

Step 0 - Create a SLICES experiment

Log in with your Slices account at the Post-5G Blueprint Service and chose from the drop down menu the project on which you want to run the experiment, e.g., post5g-beta. From there, go to the pos Webshell section. This will open a webshell window.

Instruct the webshell to use the selected project (e.g., post5g-beta) by running the following command:

slices project use post5g-beta

Your webshell is then configured to operate within the context of this project. You can proceed to initialize the SLICES experiment for the Post-5G test by running the following command. In this example, the experiment is named my_experiment, but feel free to adapt the name as needed.

slices experiment create  my_experiment --duration 4h

This command creates an experiment named my_experiment in the project post5g-beta, with a duration of 4 hours. Adjust the duration according to your requirements (e.g., 3h, 1d, 1w. Default duration is 1 day), you can also specify an expiration date instead (dates are of the form %Y-%m-%d | %Y-%m-%dT%H:%M:%S | %Y-%m-%d %H:%M:%S).

Now that we have a SLICES project and an experiment, we can define the Post-5G experiment we want to conduct.

Step 1 - Experiment definition

For this experiment, we use the Post-5G service to deploy a 5G core and a disaggregated RAN in the central SLICES-RI Kubernetes cluster. The gNB is divided into a CU-UP, CU-CP, and a DU. Interfaces N1, N2, N3, N4, N6, F1, and E1 are each assigned a dedicated network interface using Multus, with their own IP addresses. Figure below shows the logical interfaces of the various functions, multus interfaces are depicted in blue and interfaces using the kubernetes pod network are depicted in black. Additionally, the NRF is assigned an IP address to ensure it is accessible from any resource within the SLICES infrastructure.

The deployement in the kubernetes cluster is illustrated in the figure below.

A RIC is deployed in the core. The experiment consists of sending 4 ping probes from the UE to the UPF. The experiment is implemented using an Ansible playbook. The experiment can be found on simple ping example repository. Feel free to explore it for a better understanding of the overall approach.

The 5G network, consisting of a core, a RAN, and a UE connected to the RAN through a simulated radio, is implemented using the SLICES post-5G blueprint reference implementation. Currently, we are utilizing the develop branch, but it is expected to transition to a stable release soon. We recommend reviewing the SLICES Post-5G blueprint reference implementation code for a thorough understanding of what is being proposed.

The reference implementation uses OpenAirInterface, deployed via Helm charts. Consequently, each 5G function mentioned above is implemented with a Kubernetes deployment (essentially a pod and service). The RIC is implemented using FlexRIC, the RIC solution provided by OpenAirInterface. Read the official OpenAirInterface documentation for details about OpenAirInterface in Kubernetes.

As mentioned earlier, certain functions require IP addresses. Therefore, we need to first acquire an IP prefix for our 5G network functions that utilize Multus, as well as an IP address for the NRF. To obtain these, run the following command:

post5g experiment prefix my_experiment

It returns you a subnet and an LB IP address, remember these addresses as we will use them later on.

NOTES: IP addresses are limited resources, as soon as you don’t need them anymore, please release them so that other users can benefit from our pool of IP addresses (e.g., post5g experiment prefix my_experiment --release).

Experiments are managed from a deployment node, which can be any machine controlled by POS and is used to deploy the 5G network in the SLICES infrastructure (the 5G network is not run on the deployement node!) and execute the experiment script provided by the user. Experiment scripts should be packaged as a gzip-compressed tarball (i.e., a tar.gz file) that pos will retrieve via a public URL (see below). The entry point for the experiment must be the xp/xp.sh file, which POS will use to run the experiment on top of the 5G infrastructure. Ensure that your tarball includes this file and that it can be executed on the deployment node (e.g., AMD64 Ubuntu Jammy). You can find experiment script examples in the Post-5G blueprint example repository. Feel free to explore the examples for a better understanding of the overall approach.

The tarball file that you provide must respect the following structure:

my_xp/
├── dir_1
│   ├── file_1
│   ├── ...
│   ├── file_n
│   ├── dir_1
│   ├── ...
│   └── dir_n
├── ...
│   ├── ...
│   └── ...
│       └── ...
├── file_1
├── ...
├── file_n
└── xp.sh

You can include as many files and directories as needed, at any depth, but they must all be placed within a single root directory, which can have any name (e.g., my_xp). The xp.sh entrypoint must be located in this root directory.

IMPORTANT: The purpose of this tarball is not to hold data but to contain the experimentation scripts.

If your experiment relies on datasets, they should not be included in this tarball. Instead, your xp.sh script should handle retrieving them from their original source (e.g., using wget or git).

If your experiment generates files that you wish to publish, ensure they are placed in the ~/results directory of the deployment node. POS will then automatically retrieve and publish them with the MRS (see step 5). Meanwhile, POS collects the entire standard output and standard error streams and publishes them with the MRS, so there’s no need to redirect your command outputs to files in the ~/results directory (although you can do so if preferred but it’s redundant) (see step 5).

Choose the node based on your experiment’s processing, memory, and storage needs. In this example, since the experiment script is simple (run an ansible playbook executing the ping command on a kubernetes container running in the SLICES kubernetes cluster) and doesn’t require extensive processing or storage, we’ll use the standard-2-1 resource, a lightweight virtual machine.

To configure the 5G network, visit the Configure Post-5G BP section of the Post-5G Blueprint Service. Authenticated sessions are time limited, so it is possible that you have to authenticate yourself again when visitin this page, make sure that you select the same project as the one you used above (e.g., post5g-beta).

In the assistant, make sure the check the GCN FlexRIC is present, this will indicate to deploy the OpenAirInterface RIC in the network. To activate CU-DU split, check the F1 split. And to split the CU into CU-CP and CU-UP, check the E1 split. Indicate the load balancer IP received earlier in the NRF Load Balancer IP and the prefix in the Multus network field.

For this experiment, it is recommended to keep the remaining parameters at their default values, but specifically verify that the 5G core is configured with at least one DNN named oai, using IPv4 and the prefix 12.1.1.0/24. Provide the link https://gitlab.inria.fr/slices-ri/blueprints/post-5g/examples/-/archive/simple_ping/examples-simple_ping.tar.gz as experiment URL to tell the assistant how to retrieve the simple ping experiment script.

Step 2 - Experiment code generation

After configuring all the parameters in the assistant to suit your needs, click the Generate Experiment Code button. This will generate the OpenAirInterface configuration files along with the POS scripts, which will handle the provisioning of your experiment environment, including the 5G core infrastructure, the 5G RAN, and UE, and will execute the simple ping experiment.

Addresses for the N1, N2, N3, N4, N6, F1, and E1 interfaces are automatically taken from within the prefix you provided in the Multus network field.

You can verify that the experiment code was generated successfully by going to the My file IDs section of the Post-5G Blueprint Service, which logs the generation of experiment code.

In step 4, we will explain how to retrieve the generated code.

Step 3 - Book resources

Now that you have created an experiment and generated its code, you can book the necessary resources to run it. Navigate to the POS Calendar section of the Post-5G Blueprint Service and select a one-hour time slot that fits your schedule. To add an entry to the calendar, either double-click on the desired time or click, hold, and drag the mouse over the time slot you wish to select.

In this tutorial, we are using the SLICES-RI Kubernetes cluster along with a deployment node (e.g., standard-2-1). The cluster is shared and does not require a reservation, but the deployment node must be reserved. Therefore, be sure to include the standard-2-1 resources in your reservation (obviously if you selected a different deployment node, select the one you intend to use). If the resource is already reserved by someone else for your chosen timeslot, you won’t be able to book it. In that case, you will need to select a different timeslot when the resource is available.

Make sure the selected time slot ends at or before the expiration of the SLICES experiment my_experiment you created in step 1. If you’re unsure of the time, you can retrieve it by running the following command in the POS Webshell.

slices experiment show my_experiment

See you in step 4!

Step 4 - Experiment execution

When your time slot begins, connect to the POS Webshell of the Post-5G Blueprint Service. First, you need to retrieve the experiment code generated in step 2 using the following command. You have to provide the SLICES experiment name that was used to generate the experiment (remember, we named it my_experiment).

post5g experiment get my_experiment

As a result, all experiment scripts and configurations are fetched by the POS orchestrator and saved in the xp/post5g-beta/my_experiment/ directory (since the experiment was created under the post5g-beta project). This directory contains a zip file bundling all automatically generated files for the experiment, organized into two folders:

• oai-cn5g-fed: includes all automatically generated OpenAirInterface configuration files.

• pos: contains all the automatically generated files needed by pos.

Notably, the pos/deploy.sh script is used by POS to execute the experiment, and pos/params_dmi.yaml holds metadata for the experiment.

Next to this zip file is a directory named reference_implementation-develop, which holds the Post-5G blueprint reference implementation, in which the oai-cn5g-fed and pos directories presented above included.

Feel free to review the contents of the reference_implementation-develop folder and adjust the files as needed. If necessary, you can check the pos/params.5g.yaml file to see the IP addresses assigned to the various Multus interfaces. However, note that modifying these addresses in this file will not affect the OpenAirInterface configuration files, as the parameter file only reflects the settings used to generate those configuration files. If you wish to change them manually, be sure to update both the pos/params.5g.yaml file and the relevant configuration files in the oai-cn5g-fed directory.

Notes: For reproducibility reasons we made the choice of providing all the scripts and make them part of the experiment itself

Note: Experiments are potentially long processes during which you may lose (or pause) the connection to the webshell. We recommend protecting your work sessions within the webshell from disconnection by using tools like tmux.

When the experiment code generated data is fetched, you can launch the experiment by running the following command from the webshell.

post5g experiment launch my_experiment

In practice, this command calls the deploy.sh script that is located in xp/post5g-beta/my_experiment/reference_implementation-develop/pos/ that runs the experiment in the SLICES infrastructure.

The experiment will run, with progress displayed in the output as shown below and published to the MRS.

Step 5 - Results publication

Experimental data and metadata are published to the SLICES MRS and SLICES DMI only if the experiment completes successfully. In case of an error, the experiment is not published, and it is up to you to debug it. Although it might seem convenient to publish all experimental results, even partial ones, doing so would compromise methodological rigor. By publishing only successful experiments, we ensure that all experiments published by the service are, at a minimum, syntactically correct (though this does not guarantee the correctness of the results).

If the wall process is successful, the Dataset ID of the published data will appear in the output (e.g., 117 as shown above). To review the information published in the MRS. Go to the MRS section of the Post-5G Blueprint Service and provide the Dataset ID you just obtained you should obtain something similar to what is shown below.

Move in the different meta-data tabs to see various information about your experiment.

You can also connect directly to the MRS Portal to access this information. In this case, you can find your dataset in the MRS using the MRS search engine. For example, the dataset name is set to the experiment name (e.g., my_experiment); the Identifier is set to the SLICES experiment ID, which you can find in the My file IDs section of the Post-5G Blueprint Service; and the Internal Identifier matches the Dataset ID shown at the end of the experiment execution. If you want to know more about the MRS, visit the SLICES-RI documentation portal.

The MRS ensures that experiment results adhere to FAIR data principles 4, with the actual data stored in the SLICES DMI. To retrieve this data, simply click the Download Data button. The data is packaged as a tar.gz file, which you can verify through the format and compressionFormat metadata in the MRS. Depending on your browser, you may need to add the .tar.gz extension to the downloaded file.

You could also directly use the DMI API to access the dataset, but this is out of the scope of this tutorial.

Download the file and decompress it (e.g., using tar -xzf dataset.tar.gz). Assuming that your deployement node was standard-2-1, the tarball is structured as follows:

.
├── config
├── standard-2-1
├── energy
├── reference_implementation-develop
├── results
└── setup

The config, energy, and setup folders are related to the POS setup used. While they are not directly relevant to the experiment itself, they are very useful for reproducibility as they provide information about the POS environment in which the experiment was executed.

The results folder is a copy of the ~/results folder from the deployment node immediately after the successful execution of xp.sh (refer to step 1 for a reminder).

The reference_implementation-develop folder is a snapshot of the xp/post5g-beta/my_experiment/ (see step 4 for details) at the exact moment the experiment was launched (i.e., when you ran post5g experiment launch my_experiment). The reason for capturing this snapshot is that it ensures we have the exact scripts used to conduct the experiment, so you don’t need to worry about which scripts were used if you made changes or lost them later.

The standard-2-1 folder (replace the name with the actual deployment node you used) contains files with .status, .stderr, and .stdout extensions. These files represent the execution status as determined by POS (e.g., finished), the standard error output, and the standard output from the execution of the command, respectively. The prefix of each file indicates the date when the command was executed by POS. Each file corresponds to a command executed by POS during the experiment. Most of these files are not directly related to the experiment itself, except for the <date>_xp.sh.stderr and <date>_xp.sh.stdout files, which contain the full standard error and standard output of the execution of your xp.sh script. Check the <date>_xp.sh.stdout file to view the results of the ping. If everything went as expected, you should see a success rate of 100%, as shown below (refer to step 1 if you need a reminder of the experiment’s definition).

The SLICES platform is designed around open, reproducible experiments. The SLICES-RI infrastructure collects background data, which you can explore via a deployed Grafana instance. Visit the Blueprint Monitoring section in the Post-5G Blueprint Service to access it. The initial dashboard provides an overview of the entire system; feel free to adjust the time range to match your experiment. You can determine the relevant timing details from the metadata published in the MRS (see the previous paragraphs). Your view might resemble the example shown below.

We also gather detailed information on the workload deployed within the Kubernetes clusters. To access it, click the Load Log Data button. Select the namespaces used for deploying your core and RAN infrastructure (those defined during the step-by-step setup). You’ll see a view similar to the one below.

This dashboard allows us, for example, to view the AMF logs, providing insights into information about the gNB and UE, as shown below. Go and play around.

If you closely examine the experiment definition provided on the simple ping example repository and that we executed in this experiment, you’ll notice that only the output of the Ansible playbook was retained, which may be insufficient for reproducibility or debugging. The opportunistic data collection approach of SLICES, however, grants you much more detailed information about experiments at no additional cost.

Next steps

The experiment itself is complete (i.e., we’ve successfully performed the ping). However, if you’re interested in exploring further, you can connect to the deployment node and experiment with various components. From the pos Webshell, simply use SSH to access it:

ssh -i ~/.ssh/id_rsa standard-2-1

The goal here isn’t to provide a detailed explanation, but rather to spark your curiosity and encourage further exploration. If you’re familiar with OpenAirInterface, you’ll feel at home since we use this software suite for the Post-5G blueprint reference implementation.

The deployment node has access to the SLICES-RI cluster where your experiment is deployed. For instance, if you deployed your 5G network in the namespace called core, you can gather information about the deployment with the following command. Keep in mind that as a standard user, your namespaces are prefixed by your username (e.g., core would be <username>-core, where <username> is your SLICES preferred username):

root@standard-2-1:~# kubectl get -o wide -n core all

and obtain a result similar to

We can confirm that our NRF is accessible through the NRF Load Balancer IP provided earlier in the step-by-step guide. Now, let’s query the NRF API to retrieve information about the UPF, SMF, or AMF:

root@standard-2-1:~# curl http:/172.29.7.254/nnrf-nfm/v1/nf-instances?nf-type='UPF' --http2-prior-knowledge --silent
{"_links":{"item":[{"href":"172.29.6.229"}],"self":""}}root@standard-2-1:~# 
root@standard-2-1:~# curl http:/172.29.7.254/nnrf-nfm/v1/nf-instances?nf-type='SMF' --http2-prior-knowledge --silent
{"_links":{"item":[{"href":"10.244.135.23"}],"self":""}}root@standard-2-1:~# 
root@standard-2-1:~# curl http:/172.29.7.254/nnrf-nfm/v1/nf-instances?nf-type='AMF' --http2-prior-knowledge --silent
{"_links":{"item":[{"href":"10.244.135.20"}],"self":""}}root@standard-2-1:~# 

Additionally, we can observe that a FlexRIC instance has been deployed in the cluster. To check its logs, use the following command:

root@standard-2-1:~# kubectl logs -n core oai-flexric-74df96bd4b-ntnrf 
[UTIL]: Setting the config -c file to /usr/local/etc/flexric/flexric.conf
[UTIL]: Setting path -p for the shared libraries to /usr/local/lib/flexric/
[NEAR-RIC]: nearRT-RIC IP Address = 10.244.135.25, PORT = 36421
[NEAR-RIC]: Initializing 
[NEAR-RIC]: Loading SM ID = 145 with def = SLICE_STATS_V0 
[NEAR-RIC]: Loading SM ID = 144 with def = PDCP_STATS_V0 
[NEAR-RIC]: Loading SM ID = 2 with def = ORAN-E2SM-KPM 
[NEAR-RIC]: Loading SM ID = 3 with def = ORAN-E2SM-RC 
[NEAR-RIC]: Loading SM ID = 148 with def = GTP_STATS_V0 
[NEAR-RIC]: Loading SM ID = 143 with def = RLC_STATS_V0 
[NEAR-RIC]: Loading SM ID = 146 with def = TC_STATS_V0 
[NEAR-RIC]: Loading SM ID = 142 with def = MAC_STATS_V0 
[iApp]: Initializing ... 
[iApp]: nearRT-RIC IP Address = 10.244.135.25, PORT = 36422
[NEAR-RIC]: Initializing Task Manager with 2 threads 
[E2AP]: E2 SETUP-REQUEST rx from PLMN   1. 1 Node ID 3587 RAN type ngran_gNB
[NEAR-RIC]: Accepting RAN function ID 2 with def = ORAN-E2SM-KPM 
[NEAR-RIC]: Accepting RAN function ID 3 with def = ORAN-E2SM-RC 
[NEAR-RIC]: Accepting RAN function ID 142 with def = MAC_STATS_V0 
[NEAR-RIC]: Accepting RAN function ID 143 with def = RLC_STATS_V0 
[NEAR-RIC]: Accepting RAN function ID 144 with def = PDCP_STATS_V0 
[NEAR-RIC]: Accepting RAN function ID 145 with def = SLICE_STATS_V0 
[NEAR-RIC]: Accepting RAN function ID 146 with def = TC_STATS_V0 
[NEAR-RIC]: Accepting RAN function ID 148 with def = GTP_STATS_V0 

We haven’t run any specific xAPP, but as we can see, the gNB 3587 is connected to it. From the gNB logs, we can confirm that the same ID is being used and that it is connected to the RIC.

root@standard-2-1:~# kubectl logs  -n core oai-gnb-7b87fb4b9c-zvb22 | grep E2
After RCconfig_NR_E2agent /usr/local/lib/flexric/ 10.96.254.125 
[E2 NODE]: mcc = 1 mnc = 1 mnc_digit = 2 nb_id = 3587 
[E2 NODE]: Args 10.96.254.125 /usr/local/lib/flexric/ 
[E2 AGENT]: nearRT-RIC IP Address = 10.96.254.125, PORT = 36421, RAN type = ngran_gNB, nb_id = 3587
[E2 AGENT]: Initializing ... 
[E2 AGENT]: Opening plugin from path = /usr/local/lib/flexric/libslice_sm.so 
[E2 AGENT]: Opening plugin from path = /usr/local/lib/flexric/libpdcp_sm.so 
[E2 AGENT]: Opening plugin from path = /usr/local/lib/flexric/libkpm_sm.so 
[E2 AGENT]: Opening plugin from path = /usr/local/lib/flexric/libgtp_sm.so 
[E2 AGENT]: Opening plugin from path = /usr/local/lib/flexric/librlc_sm.so 
[E2 AGENT]: Opening plugin from path = /usr/local/lib/flexric/libtc_sm.so 
[E2 AGENT]: Opening plugin from path = /usr/local/lib/flexric/libmac_sm.so 
[E2-AGENT]: Sending setup request
[E2-AGENT]: E2 SETUP-RESPONSE received
[E2-AGENT]: stopping pending
[E2-AGENT]: Transaction ID E2 SETUP-REQUEST 0 E2 SETUP-RESPONSE 0 

When you’re finished, be sure to manually release the IP addresses you obtained for your experiment using the command below. In production phase, the addresses will be automatically released when the experiment ends, but for now, to give you more flexibility during testing, this task is left to you.

post5g experiment prefix my_experiment --release

Experiment with Hardware USRP Radio Units and a bare metal server

Prerequisites

• You have a Slices account

• you have a basic understanding of kubernetes and containers

• you have a good understanding of the 5G architecture

• you have a good understanding of radio units (e.g., USRP).

• you have a good understanding of OpenAirInterface and how to configure radio

The previous experiment used a simulated radio network. In this tutorial, we will work with a real radio network, utilizing a hardware radio unit and User Equipment (UE). To accomplish this, we will deploy the core network in the central SLICES-RI Kubernetes cluster, while the Radio Access Network (RAN) will operate on bare-metal resources.

For the hardware, we will use the R2LAB anechoic chamber, which provides both Radio Units and UEs. In this setup, the N320 USRP from R2LAB will serve as the radio unit, and the Quectel RM 500Q-GL module from R2LAB will act as the UE connecting to the 5G network. These devices are referred to as n320 and qhat03, respectively. We will also need a bare-metal server to function as the gNB, to which the radio unit (RU) will connect. R2LAB provides bare-metal servers with high-performance dedicated networks linked to the radio units, and we will use the node named sopnode-w3 for both the deployment and the gNB.

As in the previous tutorial, go to the Post-5G Blueprint Service and follow the step-by-step guide. Set the NRF Load Balancer IP and the Multus network prefix based on the prefix you receive with the command:

post5g experiment prefix my_experiment

Use the sopnode-w3 node for deployment and set GCN RAN Present and GCN UE Present to false to prevent the assistant from automatically deploying the RAN and UE. Instead, the RAN will be configured and run manually as part of your custom experiment. For a reference implementation, you can check the example at usrp_baremetal. Specify https://gitlab.inria.fr/slices-ri/blueprints/post-5g/examples/-/archive/usrp_baremetal/examples-usrp_baremetal.tar.gz as the experiment URL.

Next, reserve a time slot through the Calendar section of the Post-5G Blueprint Service and select the resources r2lab and sopnode-w3.

When your time slot begins, connect to the Webshell and retrieve the experiment information, just as you did in the previous case.

post5g experiment get my_experiment

Before starting the experiment, ensure that the radio resources in R2LAB are powered on. You can control them from the Webshell using the command post5g nodes [start|stop] {<node_name>}, where <node_name> is the name of the resource you want to turn on or off. In this case, we’ll start the Radio Unit with the following command:

post5g nodes start n320

After that, you can launch the experiment using the usual method from the webshell.

post5g experiment launch my_experiment

This will deploy the 5G core network in the SLICES-RI k8s cluster, a bare metal gNB on the sopnode-w3 server and connect the n320 USRP to this gNB.

References

[1] OpenAirInterface | 5G software alliance for democratizing wireless innovation, [https://openairinterface.org/], accessed October 8, 2024.

[2] (1, 2) Peterson, L., Sunay, O., Davie, B., 2023. Private 5G: A Systems Approach, [https://5g.systemsapproach.org/], accessed December 12, 2023.

[3] ETSI, T., 123 501 V16. 6.0 (Oct. 2020). System architecture for the 5G System (5GS)

[4] Wilkinson, M., Dumontier, M., Aalbersberg, I. et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci Data 3, 160018 (2016). [https://doi.org/10.1038/sdata.2016.18]