Post-5G Blueprint v3

What is Post-5G?

5G is an evolution of cellular infrastructure based on four key pillars: cloud-native design, softwarization, edge computing, and the separation of the control and data planes. Together, these pillars have a transformative impact on openness and innovation.

SLICES proposes a post-5G blueprint to provide researchers with the ability to explore thought experiments in this domain. However, to make this blueprint relatively easy to deploy, we recommend using a tested set of software and hardware components.

With this setup, researchers gain 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.

The Post-5G blueprint relies on the experiment-as-code paradigm, where entire experiments can be automated and integrated into CI/CD and AI workflows.

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 modularly, allowing users to deploy it fully or partially. For example, researchers interested only in the 5G core can deploy the core and use a simulated RAN, while those interested solely in the RAN can deploy just the RAN, assuming they have access to a core. 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 (RU) and User Equipment (UE)), and supporting tools, this setup provides an ideal environment for post-5G experiments.

The Post-5G blueprint follows a programmatic approach. Experimenters define their post-5G requirements using a declarative metamodel [1]. The metamodel is implementation-agnostic and fully compliant with 3GPP 5G standards. Within the metamodel, experimenters declare the various parameters of their post-5G network, such as network slices, DNNs, subscribers, radio settings (bands, TDD patterns, MIMO configurations…), and O-RAN split levels. To allow experimenters to focus on their primary research interests, parameters not explicitly provided by the user are automatically derived.

Experimenters then specialize the metamodel for specific deployments and implementations using a declarative deployment model. In the deployment model, experimenters specify the target infrastructure and implementation details for each function and piece of equipment. For example, supported core functions include Free5GC, Open5GS, and OAI; for the RAN, OpenAirInterface, OCU-DU, and UERANSIM are supported. For UEs, we support simulated UEs and RAN via UERANSIM, rfsim, and srsUE, as well as real radio links using COTS Quectel UEs and commercial smartphones paired with a wide range of RUs (e.g., USRP, AW2S, Benetel, LiteON). Both FlexRIC and the O-RAN SC Near-Real-Time RIC are supported.

Using their metamodel and deployment model, experimenters can use the Post-5G orchestrator 2 Python library to deploy, operate, and maintain 5G networks. Its role is to deploy the post-5G infrastructure and update it on demand—such as adding or removing UPFs or DUs in a running network or registering new subscribers. The library automatically generates all low-level configurations and populates them according to the experimenter’s needs.

Each stage of deployment and network operation is abstracted as a self-defined state within the orchestrator, enabling the construction of arbitrary workflows. All actions are idempotent, allowing for easy recovery in case of issues.

Built with progressive complexity, the blueprint is explained step-by-step through Python notebooks that experimenters can replicate and modify at will.

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

The Post-5G Blueprint offers templates and tutorials to assist researchers in utilizing this infrastructure. 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 research. Note that the metamodel, deployment model, and orchestration library are not specific to SLICES-RI and can easily be adapted for use in other infrastructures.

The documentation on how to run experiment can be found in http://doc.theblueprintfactory.org.

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 visibility into underlying components.

• Example 1: Researchers use a post-5G infrastructure to upload raw LiDAR data from drones to a ground station, enabling the creation of real-time 3D environment models. For these researchers, the scientific focus is computer vision rather than telecommunications, so 5G serves purely as a commodity. Deploying such custom infrastructure independently would be too costly and time-consuming.

Type 2 Studies: Software-Defined Networking (SDN)

Researchers aim to modify network behavior itself by adopting the SDN paradigm and require complex environments to validate their findings. SLICES provides access to well-defined network function interfaces (e.g., xApps, 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, production-like networks. They require access to terabits-per-second backbones equipped with programmable switches to test their implementations.

Type 3 Studies: Low-level resource development

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 deployments 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 emerging hardware technologies such as antennas, Reconfigurable Intelligent Surfaces (RIS), THz radio, cryptographic functions, packet processors, and TSN devices. Because such hardware is rarely useful in isolation, researchers can integrate it into the SLICES infrastructure and use allocated time slots for system-level 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-topic and resource integration

Researchers may require a combination of resources across multiple domains to achieve their research goals.

• 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 routed over a Tbps P4 SDN core. Because the scale of UEs in the radio network makes testing with physical devices impractical, high processing capabilities must be linked directly to networking equipment.

Anatomy of an Experiment

In the Post-5G blueprint, an experiment is defined as a code. It is organized into several key phases designed to ensure a smooth workflow. The first phase involves defining the 5G network and its environment, comprising a 5G Core Network, a 5G Radio Access Network, and User Equipment. Resources can be virtual or physical (e.g., a USRP acting as a gNB in the radio network). The SLICES-RI infrastructure supports this by providing a diverse range of computing environments, including bare-metal servers and virtual machines.

The infrastructure is then provisioned, and the desired network is deployed using workflows defined as Python code.

Because SLICES is a shared infrastructure, resource allocation relies on a fair scheduling system. A calendar-based reservation service manages physical resource access, ensuring fair distribution among experimenters. This calendar is integrated into the POS framework [5].

Upon completion of the experiment, all relevant data and metadata can be collected and published in the Metadata Registry System (MRS) [6]. The MRS indexes experiment results and links them to the experiment’s code, making it possible to retrieve both experimental outcomes and the exact code used for the run. This process guarantees transparency and reproducibility, enhancing the value of collected data for future reference.

Resources Available for Experimentation

SLICES provides a comprehensive range of software and hardware resources designed for post-5G experimentation. The central hub hosts essential services for managing experiments, such as authentication and data management. Across Europe, SLICES operates a network of nodes, each consisting of various sites offering hardware resources—including radio equipment (USRPs, RRUs, UEs), virtual machines, and bare-metal servers. These resources are interconnected via dedicated links over the GÉANT network, as shown in the diagram below.

        graph TD
    central_hub <--> geant[GÉANT]
    geant<--> n1
    geant<--> netc
    geant<--> nn

    subgraph central_hub [Central Hub]
        subgraph central_hub_s [Central Services]
            iam[Global IAM]
            ch_s_1[Service 1]
            ch_s_etc[...]
            ch_s_n[Service N]
        end
    end

    subgraph n1 [Node 1]
        subgraph n1_s1 [Site 1]
            liam_1_1[Local IAM]
            subgraph n1_s1_vms [Virtual machines]
                n1_s1_vm1[VM 1]
                n1_s1_vmetc[...]
                n1_s1_vmn[VM N]
            end
            subgraph n1_s1_bms [Baremetal machines]
                n1_s1_bm1[BM 1]
                n1_s1_bmetc[...]
                n1_s1_bmn[BM N]
            end
        end
        subgraph n1_setc [...]
        end
        subgraph n1_sn [Site N]
            liam_1_n[Local IAM]
            subgraph n1_sn_vms [Virtual machines]
                n1_sn_vm1[VM 1]
                n1_sn_vmetc[...]
                n1_sn_vmn[VM N]
            end
            subgraph n1_sn_bms [Baremetal machines]
                n1_sn_bm1[BM 1]
                n1_sn_bmetc[...]
                n1_sn_bmn[BM N]
            end
            subgraph n1_sn_radio [Radio hardware]
                n1_sn_rru1[Radio Unit 1]
                n1_sn_rruetc[...]
                n1_sn_rrun[Radio Unit N]
                n1_sn_ue1[User Equipment 1]
                n1_sn_ueetc[...]
                n1_sn_uen[User Equipment N]
            end
        end
    end

    subgraph netc [...]
    end

    subgraph nn [Node N]
        subgraph nn_s1 [Site 1]
            liam_n_1[Local IAM]
            subgraph nn_s1_vms [Virtual machines]
                nn_s1_vm1[VM 1]
                nn_s1_vmetc[...]
                nn_s1_vmn[VM N]
            end
            subgraph nn_s1_bms [Baremetal machines]
                nn_s1_bm1[BM 1]
                nn_s1_bmetc[...]
                nn_s1_bmn[BM N]
            end
            subgraph nn_s1_radio [Radio hardware]
                nn_s1_rru1[Radio Unit 1]
                nn_s1_rruetc[...]
                nn_s1_rrun[Radio Unit N]
                nn_s1_ue1[User Equipment 1]
                nn_s1_ueetc[...]
                nn_s1_uen[User Equipment N]
            end
        end
        subgraph nn_setc [...]
        end
        subgraph nn_sn [Site N]
            liam_n_n_[Local IAM]
            subgraph nn_sn_vms [Virtual machines]
                nn_sn_vm1[VM 1]
                nn_sn_vmetc[...]
                nn_sn_vmn[VM N]
            end
            subgraph nn_sn_bms [Baremetal machines]
                nn_sn_bm1[BM 1]
                nn_sn_bmetc[...]
                nn_sn_bmn[BM N]
            end
        end
    end
    

To conduct experiments, you can run code from any environment (your local laptop, a dedicated machine, or JupyterHub). You gain access to the infrastructure using your credentials, granting you private access to the required resources for the duration of your experiment. Virtual resources such as virtual machines and Kubernetes clusters are created dynamically on demand.

The exact resources provided by individual sites for the Post-5G blueprint can be found in the Post-5G blueprint resources repository.

Support and Helpdesk

If you have any questions or encounter issues, please contact p5g-support@slices-ri.eu.

Next steps

• Experiment-as-code
• Experiment with OAIBOX

References

[1] Metamodel, https://gitlab.inria.fr/slices-ri/blueprints/post-5g/meta-model.

[2] Post-5G Orchestrator, https://gitlab.inria.fr/slices-ri/blueprints/post-5g/orchestrator.

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

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

[5] Gallenmüller, S., Scholz, D., Stubbe, H. and Carle, G., 2021, December. The POS framework: a methodology and toolchain for reproducible network experiments. In Proceedings of the 17th International Conference on emerging Networking EXperiments and Technologies (pp. 259-266).

[6] MRS (Metadata Registry System), https://doc.slices-ri.eu/BasicServices/MRS/MRS.html.