Difference between revisions of "5G srsRAN End-to-End Reference Architecture with USRP"

Revision as of 05:56, 7 November 2025

Application Note Number and Authors

AN-599

Authors

Bharat Agarwal and Neel Pandeya

Executive Summary

This Application Note presents a comprehensive reference design for deploying 5G NR Standalone (SA) systems using a hybrid open-source software stack: the srsRAN radio access network components and the OpenAirInterface (OAI) Core Network. This setup runs on NI/Ettus USRP radios, including the B210, enabling practical, low-cost, end-to-end 5G experimentation.

This configuration supports full 5G SA mode and enables complete end-to-end evaluation of the entire protocol stack, from the physical layer up to the core network.

Core Network Deployment Options

The OAI Core Network can be deployed in two modes:

• Single-machine deployment: CN and gNB run on the same machine — ideal for compact or portable test setups.
• Multi-machine deployment: CN is hosted on a separate machine — ideal for performance scaling or distributed 5G architecture evaluation.

UE Configuration Options

This reference architecture supports the following UE configurations:

• A software-defined UE implemented using srsUE with a USRP B210.
• A modem-based UE, such as Quectel or Sierra Wireless modules.
• A COTS 5G handset (e.g., Google Pixel 9) for interoperability and benchmarking.

Overview of the OpenAirInterface (OAI) Software Stack

The OAI) software provides a fully open-source and standards-compliant implementation of the 3GPP 5G New Radio (NR) protocol stack. It is designed to run in real time on commodity x86 hardware and interoperate with USRP software-defined radios.

Initially developed by Eurecom, a leading research institute in France, the project is now actively maintained by the OpenAirInterface Software Alliance (OSA) — a non-profit organization that promotes open wireless innovation and collaborative research.

OAI enables complete 5G system prototyping and research with implementations of:

• The gNB (next-generation base station)
• The UE (user equipment)
• The 5G Core Network (5GCN)

The OAI 5G NR stack is designed to:

• Operate in real time with USRP radios
• Support interoperability with commercial 5G NR handsets (e.g., COTS devices)
• Enable academic, experimental, and pre-commercial deployments

The OAI software stack is organized into multiple Git repositories, allowing modularity and collaborative development:

• OAI 5G Radio Access Network (RAN) Project:

 gitlab.eurecom.fr/oai/openairinterface5g

• OAI 5G Core Network (OAI-CN):

 gitlab.eurecom.fr/oai/cn5g

OAI source code is freely available for non-commercial and academic research use. Licensing details and additional documentation are available on the OpenAirInterface website.

Overview of srsRAN

srsRAN (Software Radio Systems Radio Access Network) is an open-source 4G and 5G software suite developed by Software Radio Systems Ltd. (SRS). It enables researchers, developers, and network engineers to deploy and experiment with end-to-end wireless communication systems. The suite provides modular components for building complete Radio Access Networks (RANs) and supports both 4G LTE and 5G NR (New Radio).

Key Components of srsRAN 5G

The srsRAN 5G stack is composed of several main components:

• srsRAN gNB: Implements the 5G NR base station (gNodeB), including PHY, MAC, RLC, PDCP, and NGAP layers. Supports standalone (SA) mode and connects to a 5G Core Network via NG interfaces.
• srsUE: A 4G LTE software user equipment used primarily for legacy LTE research. The 5G UE is under active development and partially supported.
• srsEPC (for LTE): The Evolved Packet Core for 4G LTE deployments. In 5G, this is replaced by external 5G Core Network solutions such as OAI-CN5G or commercial alternatives.
• srsGUI and nrscope: Tools for real-time visualization and debugging of signal and protocol layer performance.

Supported Features

• 5G NR Standalone (SA) mode operation (Release 15+)
• Configurable numerology, bandwidth, and frame structure
• Support for USRP hardware (e.g., B210, N3xx, X410)
• Dynamic scheduling, HARQ, and experimental beamforming
• Compatibility with open-source 5G Core solutions (e.g., OAI-CN5G)

Use Cases

srsRAN is widely used for:

• Academic research and prototyping
• 5G network testing and benchmarking
• Private network deployments
• SDR-based teaching and training environments

Licensing and Community

srsRAN is released under the AGPLv3 license, making it freely available for modification and redistribution under open-source terms. The project is actively maintained and supported by a growing developer community on platforms such as GitHub and GitLab.

Overall, srsRAN provides a robust and flexible platform for 4G/5G experimentation and serves as a valuable resource for researchers working in wireless communications.

Overview of the Reference Architecture

The OAI USRP Reference Architecture enables researchers, developers, and system integrators to build complete 5G NR systems using open-source software and commercial SDR hardware. This section outlines two typical deployment modes of the architecture:

• A compact, single-host configuration for integrated lab setups
• A modular, distributed configuration for scalable experimentation

Each mode supports connectivity to a diverse range of User Equipment (UE), including Quectel 5G modules, USRP-based UEs, and commercial handsets such as the Google Pixel 9 with an open SIM.

Deployment 1: OAI gNB and CN on the Same Machine

In this setup, both the OAI Core Network (CN) and the OAI NR gNB are hosted on the same physical machine. This configuration is typically used for:

• Lab-based research and teaching environments
• Portable demos and proof-of-concept systems
• Quick-start testbeds for 5G protocol stack development

Architecture Highlights:

• Compute Node: High-core-count x86 server (e.g., Intel Xeon w7-2495X, 24 cores)
• Operating System: Ubuntu 22.04
• Software Stack: OpenAirInterface gNB (monolithic) and 5G Core (AMF, SMF, UPF, NRF, etc.)
• UHD Version: 4.8
• RF Front-End: USRP X410 with SFP+ (10/100 Gbps) link

Advantages:

• Simple setup with fewer network dependencies
• Easy to debug and deploy
• Lower hardware requirements

Limitations:

• Less suitable for high-throughput traffic testing
• Shared CPU and I/O resources may limit performance

Deployment 2: OAI gNB and CN on Separate Machines

This configuration separates the OAI gNB and CN onto two dedicated physical systems connected via an Ethernet switch. It is ideal for:

• Research involving modular network slicing, edge cloud integration, or realistic RAN-Core interface behavior
• Scalable testbeds with high-throughput and isolated workloads
• Large MIMO, beamforming, or MEC-based deployments

Architecture Highlights:

• gNB Node: Intel Xeon w7-2495X, 24 cores, Ubuntu 22.04
• CN Node: Separate x86 server, also running Ubuntu 22.04
• Interconnect: High-speed Ethernet via managed switch
• RF Front-End: USRP X410 with dual SFP+ for IQ data

Advantages:

• Higher reliability and scalability
• Easier to simulate real-world latency, routing, and interface constraints
• Better performance profiling of CN and gNB independently

Considerations:

• Requires correct IP addressing, routing, and DNS setup
• More complex to configure and monitor

Cable and Connectivity Setup

This section describes the physical connectivity between the USRP hardware and various types of UE. The cabling requirements are independent of whether the gNB and CN are deployed on the same machine or on separate systems.

Quectel Wireless Module UE Cable Setup

The diagram in Figure below illustrates the cabling and RF signal routing between the UE system running a Quectel RM520N wireless module and the USRP X410 connected to the OAI gNB. This setup enables direct RF loopback in a controlled lab environment using coaxial connections.

• USB Connection: The Quectel RM520N is connected to the UE system via a USB 3.0 interface. The host PC runs Windows and interacts with the module through Qualcomm QMI or MBIM drivers.
• RF Antennas: The module has 4 RF ports (ANT 0–3), which are routed to a 4-way power splitter (ZN4PD1-63HP-S+) to combine the signals.
• Attenuation: A fixed 40 dB attenuator is inserted after the splitter to protect the downstream USRP RF front end and ensure signal levels remain within a safe operating range.
• Downstream RF Splitting: The combined RF signal is routed to a 2-way splitter (ZN2PD2-50-S+), which separates it into TX/RX and RX-only paths.
• USRP Connection: These RF paths are connected to the USRP X410, which is linked to the OAI gNB system over dual SFP+ (10/25 G) links for baseband data transfer and synchronization.

Cable and RF splitter/attenuator setup for Quectel Wireless Module UE with USRP X410 and OAI gNB.

USRP-Based srsUE Cable Setup

Figure below illustrates the RF cabling setup used when both the srsRAN gNB and srsUE are implemented using separate USRP X410 and B210 devices. This setup enables full bidirectional communication in a lab environment without the need for over-the-air (OTA) transmission.

• Dual SFP+ Connection: Each USRP is connected to its respective host PC via dual SFP+ ports (Port 0 and Port 1) and USB 3.0, providing high-throughput data and synchronization channels.
• SMA Cabling and RF Splitting: RF ports from the USRP gNB are connected via SMA cables to a 2:1 power splitter, enabling simultaneous TX/RX operation.
• 40 dB Attenuator: To ensure RF power levels are safe. Within operational range for the lab setup, a fixed 40 dB attenuator is inserted before the splitter connecting to the UE-side USRP.
• Bidirectional Lab Setup: This configuration mimics over-the-air conditions by enabling a fully enclosed cable-based signal path between the USRP radios representing the gNB and UE, ensuring interference-free testing.

USRP-Based OAI-UE Cable Setup

A similar RF cabling setup applies when both the srsRAN gNB and OAI-UE are implemented using separate USRP B210 devices. This configuration also enables full bidirectional communication in a lab environment without OTA transmission.

• USB 3.0 Connection: Each USRP B210 is connected to its respective host PC via USB 3.0, providing high-throughput data and synchronization channels.
• SMA Cabling and RF Splitting: RF ports from the USRP gNB are connected via SMA cables to a 2:1 power splitter, enabling simultaneous TX/RX operation.
• 40 dB Attenuator: A fixed 40 dB attenuator is inserted before the splitter connecting to the UE-side USRP.
• Bidirectional Lab Setup: The cable-based signal path ensures controlled, interference-free bidirectional testing.

Cable setup between srsRAN gNB and srsUE or OAI-UE using USRP X410, B210 devices and RF splitters.

Commercial UE Setup: Google Pixel 9 Over-the-Air (OTA)

Figure below illustrates the setup for using a commercial 5G smartphone (Google Pixel 9) as the UE in conjunction with the srsRAN NR gNB running on a USRP X410.

• gNB Host System: The gNB stack (OAI NR Monolithic) runs on an Ubuntu 22.04 server equipped with an Intel Xeon w7-2495X processor (24 cores, 2.5 GHz) and interfaces with a USRP X410 via two SFP+ ports.
• OTA Link: The RF connection between the USRP and the Pixel 9 is established over the air, eliminating the need for RF splitters or coaxial cabling.
• SIM Card: The Pixel 9 uses a programmable Open Cell SIM card provisioned with the correct PLMN and network parameters to allow registration with the OAI Core Network.
• Use Case: This setup is ideal for validating interoperability with COTS 5G devices and ensuring compatibility with commercially available UEs under real-world radio conditions.

Bill of Materials

The full Bill of Materials (BoM) for the OAI Reference Architecture is provided below. This comprehensive list includes all necessary hardware components required to support a variety of deployment configurations for 5G and 6G research.

The design supports multiple flexible system architectures, where the gNB (base station) and UE can each be implemented using any combination of the following USRP Software Defined Radios: N300, N310, N320, N321, or X410.

This BoM covers all shared components (host machines, network interfaces, RF cabling, timing/sync equipment, antennas, attenuators, and splitters) required for various testbed configurations. The system design is modular and scalable — users can co-locate or distribute gNB and Core Network (CN) components and switch between different UE types depending on the research focus (PHY-level tuning, link testing, or full-stack validation).

Hardware Components

• Three or Two Desktop Computers:

  Intel Core i9 CPU (10th–12th Gen) @ ≥4.0 GHz, with ≥10 physical cores and NVMe disk drives.  
  (See the Hardware Requirements section for further details.)

• Two 10 Gbps Ethernet Network Cards:

  * Recommended: Intel 810-XXVDA2  
  * Recommended: NVIDIA/Mellanox ConnectX-6 Lx (MCX631102A-ACAT)

• Two USRP Devices:

  The gNB and UE each require one USRP. Supported devices include N300, N310, N320, N321, and X410.  
  Mixed configurations are also supported (e.g., X410 for gNB and N310 for UE).

  * USRP X410: High-performance, 4 TX/RX channels, suitable for advanced 5G/6G R&D.  
    Documentation | Product Page

  * USRP N320 / N321: Wideband 2 TX/RX MIMO SDR with high dynamic range and onboard GPSDO (N321 only).  
    Documentation | N320 Product | N321 Product

  * USRP N300 / N310: Compact 4-channel SDR supporting distributed systems.  
    Documentation | N300 Product | N310 Product

• One QSFP28-to-SFP28 Breakout Cable (required for X410):

  * NVIDIA MCP7F00-A003R26N – 100 GbE to 4×25 GbE, 3 m, 26 AWG  
  * NVIDIA MCP7F00-A003R30L – 100 GbE to 4×25 GbE, 3 m, 30 AWG

• One OctoClock-G:

  Provides synchronization for gNB and UE USRPs.  
  Must be the “-G” model (with GPSDO).  
  * Ettus KB – OctoClock CDA-2990  
  * Product Page

• Four 10 Gbps Ethernet Cables with SFP+ terminations:

  Required for N3xx and N32x devices; not needed for X410.  
  * DAC Cable Listing  
  * 1 m SFP+ DAC  
  * 3 m SFP+ DAC

• Four VERT900 and/or VERT2450 Antennas:

  * VERT900 (824–960 MHz)  
  * VERT2450 (2.4–2.5 GHz / 4.9–5.9 GHz)

• One Quectel RM500Q-GL 5G Wireless Modem Module:

  Used as a UE option in the reference architecture.  
  * Quectel 5G Modules  
  * RM520N Series

• One Google Pixel 9 5G Handset:

  Used as a COTS UE; ensure it is unlocked.  
  * GSMArena Specs  
  * Amazon Listing

• Two 5G SIM Cards + One USB UICC/SIM Reader-Writer:

  * Open Cells – SIM Cards

• One Mini-Circuits 4-way DC-Pass SMA Splitter (ZN4PD1-63HP-S+): 250–6000 MHz / 50 Ω

  * Splitters Catalog  
  * Product Page

• Two Mini-Circuits 2-way DC-Pass SMA Splitters (ZN2PD2-50-S+): 500–5000 MHz / 50 Ω

  * Splitters Catalog  
  * Product Page

• Four Mini-Circuits VAT-10+ Attenuators (10 dB, DC–6000 MHz, 50 Ω):

  * Product Page

• Four Mini-Circuits VAT-20+ Attenuators (20 dB, DC–6000 MHz, 50 Ω):

  * Product Page

• Four Mini-Circuits VAT-30+ Attenuators (30 dB, DC–6000 MHz, 50 Ω):

  * Product Page

• Fourteen Mini-Circuits Hand-Flex SMA Coax Cables (086-36SM+, 36", 18 GHz):

  * Product Page  
  * Datasheet PDF

• One NETGEAR GS108 8-Port Gigabit Ethernet Switch:

  * Product Page  
  * Amazon Listing

• Three USB 3.0-to-1 Gbps Ethernet Adapters:

  * USB-A Adapter  
  * USB-C Adapter

Hardware Requirements

Host Computers

Three or two host computers are needed — one for the gNB, one for the UE, and one for the CN — with the specifications discussed in this section. The requirements for the host running the CN are not as high as for the gNB and UE, but it is recommended that all three hosts meet the requirements described here. It is also strongly recommended that each of the gNB, UE, and CN be implemented on their own dedicated system. A single host computer should only run the gNB, or the UE, or the CN.

CPU

• We recommend using an Intel Core i9 or Intel Xeon CPU from the 10^th, 11^th, or 12^th Generation, with:
  • Minimum clock speed of 4.0 GHz
  • Minimum 10 physical cores
  • At least 40 PCIe lanes (or enough to support GPU and 10 Gbps Ethernet)
  • PCIe Gen 4 support (preferred)
• Recommended examples include:
  • Intel Core i9-10940X: 14 physical cores, up to 4.60 GHz, 10^th Gen
  • Intel Core i9-12900K: 16 physical cores, up to 5.20 GHz, 12^th Gen
  • Intel Xeon Platinum 8351N

Disk

• We strongly recommend using only NVMe SSDs, ideally with a PCIe Gen-4 interface for maximum throughput.
• Do not use SATA disks — they are not sufficient for the data rates required in this application.
• Recommended model:
  • Samsung 980 PRO PCIe 4.0 NVMe SSD
  • Samsung 980 PRO on Amazon
  • Tom’s Hardware Review of Samsung 980 PRO
• RAID configurations with multiple NVMe drives are generally not required, but can be explored to further enhance throughput.

Memory

The system should have either dual-channel or quad-channel DDR4 or DDR5 (preferred) memory, with the highest clock speed available. A minimum of 16 GB or 32 GB should be sufficient. Larger amounts of memory are typically unnecessary, as no virtualization, RAM disk, or other large in-memory buffering is being used.

GPU

The GPU does not matter for the purposes of running UHD and OAI. If you plan to perform AI/ML processing on the GPU, select an appropriate accelerator. The OAI 5G stack does not currently leverage the GPU.

10 Gbps Ethernet Network Card

• Both the gNB and UE systems require a two-port 10 Gbps Ethernet network card for connecting to the USRP radios.
• The Core Network (CN) system does not interface with USRPs directly and therefore does not require a 10G NIC.
• Ensure the computer chassis has adequate space and airflow to accommodate the network card.
• Recommended options:
  • Intel E810-XXVDA2 (25GbE capable, backward compatible with 10GbE) — Works well with Ubuntu 20.04+ and supports DPDK. Ideal for advanced research requiring high throughput.
    • Product Page (Intel)
    • Amazon
  • NVIDIA ConnectX-6 Lx (MCX631102A-ACAT) — Dual-port SFP28, PCIe Gen4, excellent compatibility with Linux and DPDK.
    • Product Page (NVIDIA)
    • Amazon

QSFP28-to-SFP28 Breakout Cable for USRP X410

The USRP X410 features a QSFP28 port (100 Gbps Ethernet). To interface with a host computer equipped with 10 Gbps Ethernet, a QSFP28-to-SFP28 breakout cable is required. This is essential for X410 deployments, but is not necessary for USRP N300, N310, N320, or N321 devices.

Recommended Breakout Cables:

• NVIDIA MCP7F00-A003R26N – 100 GbE to 4×25 GbE, 3 m, 26 AWG
• NVIDIA MCP7F00-A003R30L – 100 GbE to 4×25 GbE, 3 m, 30 AWG
• NVIDIA MCP7F00-A001R30N – 100 GbE to 4×25 GbE, 1 m, 30 AWG

Alternative: Direct 100 Gbps Connection to Host Direct connectivity to the 100 Gbps QSFP28 port is possible using a compatible 100 GbE NIC. Recommended options:

• NVIDIA Mellanox MCX516A-CCAT – ConnectX-5 EN, PCIe Gen3
• NVIDIA Mellanox MCX516A-CDAT – ConnectX-5 Ex, PCIe Gen4
• NVIDIA MCP1600-C003E26N – 100 GbE QSFP28, 3 m, 26 AWG
• NVIDIA MCP1600-C003E30L – 100 GbE QSFP28, 3 m, 30 AWG

Intel Alternative:

• Intel E810 Series (QSFP28 and SFP28 cards)

Note: This reference architecture release does not yet require full 100 Gbps Ethernet. The dual 10 Gbps configuration is sufficient unless testing FR2 200/400 MHz bandwidth or 2×2 MIMO.

Example Host Systems:

• System76 Thelio Mira
• Dell Precision 5820

USRP Devices

Two USRP devices are required: one for the gNB and one for the UE. The devices can be any combination of the following:

• USRP N300 — KB Page | Product Page
• USRP N310 — KB Page | Product Page
• USRP N320 — KB Page | Product Page
• USRP N321 — KB Page | Product Page
• USRP X410 — KB Page | Product Page

These devices are fully interchangeable across the gNB and UE systems. For instance, the gNB may use a USRP X410, while the UE may use a USRP N310.

Supported Bandwidths:

• FR1 (Sub-6 GHz): All listed USRP models support up to 100 MHz channel bandwidths.
• FR2 (mmWave):
  • USRP N320: Supports 50, 100, 200 MHz
  • USRP X410: Supports 50, 100, 200, 400 MHz

OctoClock-G

One OctoClock-G device is required to synchronize the gNB USRP and the UE USRP.

• Ensure the device is the “-G” model, which includes an internal GPSDO (GPS Disciplined Oscillator) module.
• This synchronization device is only necessary when the UE is implemented using a USRP radio.

More Information:

• Product Page on Ettus
• OctoClock-G Knowledge Base

Installing and Configuring the UHD Software

This section explains how to build and install the USRP Hardware Driver (UHD) from source code. At the time of this writing, we recommend using UHD version 4.8.

• UHD is the open-source driver for all USRP radios and is required on both the gNB and UE systems. It is not required on the CN system.
• We strongly recommend building UHD from source rather than installing from binary packages to ensure compatibility and access to the latest updates.

Before building UHD, install all the required dependencies (for Ubuntu 22.04):

sudo apt update && sudo apt install -y \
    cmake g++ libboost-all-dev libusb-1.0-0-dev \
    libuhd-dev python3 python3-mako python3-numpy \
    python3-requests python3-ruamel.yaml libfftw3-dev \
    libqt5opengl5-dev qtbase5-dev qtchooser qt5-qmake \
    qtbase5-dev-tools doxygen

Then, clone the UHD repository and check out the v4.8.0.0 tag:

git clone https://github.com/EttusResearch/uhd.git
cd uhd
git checkout v4.8.0.0

Build and install UHD:

mkdir build
cd build
cmake ../
make -j$(nproc)
sudo make install
sudo ldconfig

Verify the installation:

uhd_usrp_probe
uhd_find_devices

For more details, see the official UHD GitHub page: https://github.com/EttusResearch/uhd

Example output of `uhd_usrp_probe` for USRP B210

Example output of `uhd_find_devices` for N310 and X410

Installing and Configuring the USRP Radio

The USRP N300, N310, N320, N321, and X410 can all be used as either the gNB or the UE in this reference design.

USRP N300 and N310

• For setup and configuration, refer to the USRP N300/N310/N320/N321 Getting Started Guide.
• These devices support all the channel bandwidths in FR1.

USRP N320 and N321

• Setup is also covered in the USRP N300/N310/N320/N321 Getting Started Guide.
• These devices support all the channel bandwidths in FR1, and all except 400 MHz in FR2.

USRP X410

• Refer to the USRP X410 Getting Started Guide for detailed setup instructions.
• The X410 supports all channel bandwidths in both FR1 and FR2.

Configuring the Ubuntu Linux Operating System

For optimal system performance, refer to the article USRP Host Performance Tuning Tips and Tricks, which outlines specific settings and configuration procedures. These include:

• Setting the CPU governors
• Enabling thread priority scheduling
• Configuring socket buffer sizes
• Adjusting Ethernet MTU values
• Configuring network card ring buffer sizes

Note: The use of the Data Plane Development Kit (DPDK) (DPDK) is not required for running any of the FR1 channel bandwidths. As of this writing, DPDK is not used in this reference architecture.

Installing, Configuring, and Running the CN System

OAI Core Network Deployment Architecture

The figure above illustrates the deployment architecture of the OpenAirInterface (OAI) 5G Core Network. The core network is implemented using several containerized Network Functions (NFs), each mapped to a specific IP address within the subnet 192.168.70.128/26. The following components are shown:

• OAI-NRF (Network Repository Function) at 192.168.70.130 handles service registration and discovery.
• OAI-AMF (Access and Mobility Function) at 192.168.70.132 manages UE registration, connection, and mobility.
• OAI-SMF (Session Management Function) at 192.168.70.133 manages sessions and IP address allocation.
• OAI-UPF (User Plane Function) at 192.168.70.134 routes user data traffic and connects to the external data network via N3 interface.
• OAI-EXT-DN (External Data Network) at 192.168.70.135 provides Internet or service access for UEs.
• OAI-AUSF (Authentication Server Function) at 192.168.70.138 handles UE authentication.
• OAI-UDM (Unified Data Management) at 192.168.70.137 and OAI-UDR (Unified Data Repository) at 192.168.70.136 manage subscription and policy data.
• A MySQL Server is connected to 192.168.70.132 for database services required by AMF and UDM.

This architecture demonstrates a standard service-based interface (SBI) deployment with N3 and N4 interfaces clearly marked between UPF and SMF. Each component is deployed in a containerized environment, typically using Docker Compose.

Core Network (CN) Deployment Scenarios

The OAI CN5G can be deployed in two different configurations depending on the system requirements and testbed constraints. Both setups follow the same installation process, differing only in whether the CN is hosted on a separate machine or collocated with the gNB.

Scenario 1: CN and gNB on the Same Machine

This configuration runs both the Core Network and the gNB stack on a single physical machine. It is suitable for development, testing, and lab-scale demonstrations.

Installation Commands

sudo apt install -y git net-tools putty sudo apt update sudo apt install -y ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc sudo chmod a+r /etc/apt/keyrings/docker.asc echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \ https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" \ | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io \ docker-buildx-plugin docker-compose-plugin sudo usermod -a -G docker $(whoami) reboot

wget -O ~/oai-cn5g.zip "https://gitlab.eurecom.fr/oai/openairinterface5g/-/archive/develop/openairinterface5g-develop.zip?path=doc/tutorial_resources/oai-cn5g" unzip ~/oai-cn5g.zip mv ~/openairinterface5g-develop-doc-tutorial_resources-oai-cn5g/doc/tutorial_resources/oai-cn5g ~/oai-cn5g rm -r ~/openairinterface5g-develop-doc-tutorial_resources-oai-cn5g ~/oai-cn5g.zip

cd ~/oai-cn5g docker compose pull docker compose up -d

cd ~/oai-cn5g docker compose down

Scenario 2: CN and gNB on Separate Machines

In this setup, the Core Network is deployed on a dedicated host while the gNB runs on a separate system. This architecture is closer to real-world 5G deployments and helps isolate network functions for performance analysis.

Hardware Requirements

• Ubuntu 22.04 LTS
• CPU: 8 cores, x86_64 @ 3.5 GHz
• RAM: 32 GB

Additional Requirement

• A second physical machine with the hardware requirements
• Proper IP routing between CN and gNB machines

Installation Instructions

The same installation steps listed above should be executed on the second machine allocated for CN. Ensure that Docker and all dependencies are installed, and the docker compose up -d command is executed on the CN machine.

Core Network Database Configuration

To configure the OAI CN5G with a valid UE profile, manually insert subscriber information into the MySQL database by editing oai_db.sql.

Navigate to DB scripts

cd ~/oai-cn5g/database

Insert subscriber entry (AuthenticationSubscription)

INSERT INTO `AuthenticationSubscription` 
(`ueid`, `authenticationMethod`, `encPermanentKey`, `protectionParameterId`, 
 `sequenceNumber`, `authenticationManagementField`, `algorithmId`, `encOpcKey`, 
 `encTopcKey`, `vectorGenerationInHss`, `n5gcAuthMethod`, `rgAuthenticationInd`, `supi`) 
VALUES
('208950000000032', '5G_AKA', 
 'fec86ba6eb707ed08905757b1bb44b8f', 
 'fec86ba6eb707ed08905757b1bb44b8f', 
 '{\"sqn\": \"000000000000\", \"sqnScheme\": \"NON_TIME_BASED\", \"lastIndexes\": {\"ausf\": 0}}', 
 '8000', 
 'milenage', 
 'C42449363BBAD02B66D16BC975D77CC1', 
 NULL, NULL, NULL, NULL, 
 '001010000000001');

Important Notes

• IMSI (International Mobile Subscriber Identity): The ueid and supi must match the IMSI used by your UE. Example IMSI: 208950000000032.
• KEY: Permanent key shared between the UE and the core network. Example: fec86ba6eb707ed08905757b1bb44b8f
• OPC: Operator Code for milenage: C42449363BBAD02B66D16BC975D77CC1
• Authentication Method: Use 5G_AKA for standard 5G UE authentication.

Update PLMN Configuration in config.yaml

To ensure proper PLMN configuration for the UE registration, update the config.yaml file to reflect the correct MCC, MNC, and SST.

cd ~/oai-cn5g/config nano config.yaml

plmn:
  mcc: "208"
  mnc: "95"
  tac: 1
  nssai:
    - sst: 1

• mcc: Set to 208 (France)
• mnc: Set to 95
• sst: Set to 1 (default data slice)

Restart the CN stack: cd ~/oai-cn5g docker compose down docker compose up -d

Install Wireshark on Ubuntu

Wireshark is a widely used packet analyzer for monitoring network traffic.

• Update packages

sudo apt update sudo apt upgrade -y

• Install Wireshark

sudo apt install -y wireshark

• Allow non-root capture (choose Yes when prompted)

If not prompted: sudo dpkg-reconfigure wireshark-common sudo usermod -aG wireshark $(whoami)

• Launch Wireshark

sudo wireshark

After launch, select the desired interface (e.g., eth0, enp1s0, lo, oai-cn) to start capturing packets.

Successful Launch of OAI CN5G Containers

Run: sudo docker-compose up -d

You should see output similar to the following, confirming container startup:

Successful startup of OAI CN5G containers using Docker Compose

Each core network function such as oai-amf, oai-smf, oai-upf, oai-nrf, and supporting services like mysql, oai-udm, oai-ausf, etc., is instantiated as a Docker container. The message "... done" indicates successful creation and start.

Verification of Running CN5G Containers

Check container health: sudo docker ps -a

Expected view:

Docker containers for OAI CN5G core components running successfully

This confirms healthy status for oai-amf, oai-smf, oai-upf, oai-nrf, oai-ausf, oai-udm, oai-udr, mysql, ims, and oai-ext-dn.

Wireshark Monitoring of OAI CN5G

Selecting the Interface

Choose the internal Docker network (e.g., oai-cn5g) to monitor inter-container traffic.

Selecting the oai-cn5g interface in Wireshark to monitor 5G core container traffic

Capturing Inter-Container Traffic

Live capture shows HTTP/2, TCP, and PFCP traffic among AMF, SMF, NRF, AUSF, etc.

Live capture view showing HTTP/2, TCP, and PFCP traffic between CN5G Docker containers

Build Instructions for srsRAN

Follow the steps below to clone and build the srsRAN_Project from source.

Clone the Repository

git clone https://github.com/srsRAN/srsRAN_Project.git

Build the Codebase

cd srsRAN_Project mkdir build cd build cmake ../ make -j $(nproc) sudo make test sudo make install

Run the gNB

After a successful build, you can run the gNB from: /srsRAN_Project/build/apps/gnb/

Network Configuration for Separate CN Deployment

When the Core Network (CN) is deployed on a separate machine from the gNB, the following network configurations are required to ensure connectivity between the gNB and CN:

Add Static Route on gNB Machine

A static route must be added to the gNB machine so it can reach the CN container subnet.

sudo ip route add 192.168.70.128/26 via 10.89.14.119 dev eno1

• 192.168.70.128/26 is the subnet used by the CN Docker bridge network.
• 10.89.14.119 is the IP address of the CN host machine.
• eno1 is the interface on the gNB machine connected to the CN machine. Replace with your actual interface name (e.g., enp1s0).

Note: This route is not persistent and will be lost after a reboot.

Enable IP Forwarding and Adjust iptables on CN Machine

To allow the CN machine to forward packets between the gNB and the containerized core network functions, configure:

sudo sysctl net.ipv4.conf.all.forwarding=1 sudo iptables -P FORWARD ACCEPT

• net.ipv4.conf.all.forwarding=1 enables IPv4 forwarding in the Linux kernel.
• iptables -P FORWARD ACCEPT allows forwarded packets through the default filter chain.

These settings are temporary and will reset after reboot unless added to permanent configs such as:

• /etc/sysctl.conf (for forwarding)
• iptables-persistent or a systemd service (for iptables rules)

Note: This configuration is not needed if the CN is deployed on the same machine as the gNB.

Invoking the gNB

After configuring the gNB, invoke it using the following procedure.

Copy the Configuration File

First, copy the edited gNB configuration file to the build directory: cp /srsRAN_Project/configs/gnb_rf_b200_fdd_srsUE.yml /srsRAN_Project/build/apps/gnb/

gNB Configuration File for srsRAN

Below is an excerpt of the customized gnb.yaml used to configure the srsRAN gNB for interoperability with the OAI Core Network. Key parameters: AMF address, bind address, PLMN, TAC, and network slice information.

Modified Fields

• amf.addr: 192.168.70.132 – IP address of the OAI AMF.
• bind_addr: 10.88.136.29 – IP address of the host running the gNB software.
• tac: 1 – Tracking Area Code; must match the OAI CN.
• plmn: 20895 – PLMN (MCC = 208, MNC = 95), consistent across CN and RAN.
• sst: 1 – Slice/Service Type for the configured PLMN.

YAML Snippet

cu_cp:
  amf:
    addr: 192.168.70.132
    port: 38412
    bind_addr: 10.88.136.29
    supported_tracking_areas:
      - tac: 1
        plmn_list:
          - plmn: "20895"
            tai_slice_support_list:
              - sst: 1

Make sure these parameters are consistent with your config.yaml in the OAI Core Network (PLMN, TAC, SST) to ensure successful NGAP registration and PDU session establishment.

Launch the gNB

After configuring gnb_rf_b210_fdd_srsUE.yml, launch the gNB: cd ~/srsRAN_Project/build/apps/gnb sudo ./gnb -c gnb_rf_b210_fdd_srsUE.yml

This initializes the gNB using the specified YAML configuration file. Ensure the file includes correct values for amf.addr, bind_addr, plmn, tac, and RF parameters suitable for your USRP B210 and deployment scenario.

Verifying with Wireshark

Wireshark capture showing successful NGSetupRequest and NGSetupResponse between gNB and AMF.

Wireshark can verify NGAP signaling between the gNB and the Core Network (CN). The interface to monitor depends on your deployment setup:

• Scenario A: CN and gNB on Separate Machines
  • On the CN machine, start Wireshark and select the oai-cn5g network interface.
  • On the gNB machine, start Wireshark and select the Ethernet interface (e.g., eno1) connected to the CN machine.
  • Start capturing on both to monitor NGAP and related 5G signaling traffic.

• Scenario B: CN and gNB on Same Machine
  • Start Wireshark and select only the oai-cn5g interface.
  • All internal signaling between gNB and CN containers will be visible on this interface.

Expected Behavior:

• After the gNB launches, it should initiate an NGAP Setup Request to the AMF.
• The AMF should respond with an NGAP Setup Response if MCC, MNC, and TAC match.

Troubleshooting Tips:

• Ensure MCC, MNC, and SST are consistent in the gNB config and CN YAML.
• Verify the TAC (Tracking Area Code) matches on both sides.
• Check that the static route (if used) is set correctly and that Ethernet connectivity between gNB and CN is functional.

Installing, Configuring, and Running the srs UE System

srsUE is a software-defined UE implementation using SDR (e.g., USRP B210). Limitations: The current 5G SA srsUE application has several constraints that impact gNB and core configuration:

• Limited to 15 kHz SCS → FDD bands only
• Supported bandwidths: 5, 10, 15, 20 MHz

Building and Installing srs UE (4G)

To set up the srsRAN 4G UE software stack, follow the steps below.

• Clone the repository:

git clone https://github.com/srsRAN/srsRAN_4G.git cd srsRAN_4G

• Create a build directory and compile:

mkdir build cd build cmake ../ make make test

• Install binaries and default configs:

sudo make install srsran_install_configs.sh user

This installs the necessary binaries and default configuration files for srsUE. You can now configure UE parameters and launch the UE application.

Configuring srs UE for OAI Core Network

Key settings for interoperability:

• USIM Parameters: IMSI, K, and OPC must match the entries in the Core Network DB.
• APN: Typically oai to match core configuration.
• Device: device_args = type=b200 for USRP B210.

[rf]
freq_offset = 0
tx_gain = 50
rx_gain = 80
srate = 23.04e6
nof_antennas = 1

device_name = uhd
device_args = type=b200
clock = internal
time_adv_nsamples = 300

[usim]
mode = soft
algo = milenage
opc  = C42449363BBAD02B66D16BC975D77CC1
k    = fec86ba6eb707ed08905757b1bb44b8f
imsi = 208950000000032
imei = 353490069873319

[nas]
apn = oai
apn_protocol = ipv4

[rrc]
release = 15
ue_category = 4

[pcap]
enable = none
mac_filename = /tmp/ue_mac.pcap
mac_nr_filename = /tmp/ue_mac_nr.pcap
nas_filename = /tmp/ue_nas.pcap

[log]
all_level = info
filename = /tmp/ue.log

[rat.nr]
bands = 3
nof_carriers = 1
nof_prb = 106
max_nof_prb = 106

Invoking the srs UE with USRP B210

Run from the build directory: ~/srsRAN_4G/build/srsue/src$ sudo ./srsue ue_rf.conf

Verifying srs UE IP Assignment

After PDU session establishment, verify the tunnel interface (e.g., tun_srsue):

ifconfig tun_srsue

Example output:

tun_srsue: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
    inet 10.0.0.12  netmask 255.255.255.0  destination 10.0.0.12
    RX packets 0  bytes 0 (0.0 B)
    TX packets 40 bytes 6920 (6.9 KB)

In this example, the UE received IP 10.0.0.12 from the OAI 5G Core.

srsRAN Log Interpretation for srsUE Attachment and PDU Session Setup

Annotated logs showing RA, RRC, NGAP, and PDU session setup:

[NR_PHY] [RAPROC] Initiating RA procedure with preamble 0 ...
[NR_MAC] UE RA-RNTI 010f TC-RNTI 55aa: Activating RA process index 0
...
[NR_RRC] RRCSetupComplete received — UE is now RRC_CONNECTED ✅
[NGAP] UE 1: Chose AMF 'OAI-AMF' (PLMN MCC 208, MNC 95)
...
[PDU SESSION SETUP INITIATED]
[GTPU] Tunnel Created: TEID: bf57e042 ↔ 192.168.70.134
...
[NR_RRC] RRCReconfigurationComplete received ✅

Legend

• RA procedure succeeded – Msg4 ACK received
• RRC_CONNECTED – UE has RRC connection
• SecurityModeComplete – Security context active
• PDU Session Setup – Bearer/tunnel configured

srsUE Log Interpretation for Initial Access and Registration

Launch UE: cd ~/srsRAN_4G/build/srsue/src sudo ./srsue ue_rf.conf

Typical successful trace:

[INFO] [UHD] ... UHD_4.8.0 ...
[INFO] [B200] Detected Device: B210 (USB 3)
...
Random Access Complete. c-rnti=0x4601, ta=4
RRC Connected
PDU Session Establishment successful. IP: 10.0.0.8
RF status: O=2, U=0, L=0

Verifying srsUE Attach and Registration via Wireshark

A Wireshark capture of NGAP and NAS signaling confirms:

• NG Setup (NGSetupRequest/Response)
• NAS Registration (InitialUEMessage → Registration Request)
• Authentication and Security Mode procedures
• UE Capability exchange
• Initial Context Setup
• PDU Session Resource Setup

NGAP and NAS signaling during UE attach and registration.

End-to-End Connectivity Verification via Ping

From the external DN container: sudo docker exec -it oai-ext-dn ping 10.0.0.5

Expected:

64 bytes from 10.0.0.5: icmp_seq=1 ttl=63 time=35.0 ms
...
7 packets transmitted, 7 received, 0% packet loss

Confirms UE registration, PDU session, and correct UPF forwarding.

iPerf Downlink (DL) Testing

Server on UE (bind to UE tunnel IP)

sudo iperf -s -i 1 -u -B 10.0.0.5

Client on CN/gNB

sudo docker exec -it oai-ext-dn iperf -c 10.0.0.5 -u -b 10M --bind 192.168.70.135

Example results show ~10.5 Mbit/s, 0% loss, sub-1 ms jitter.

iPerf Uplink (UL) Testing

Server on CN

sudo docker exec -it oai-ext-dn iperf -s -i 1 -u -B 192.168.70.135

Client on UE

iperf -c 192.168.70.135 -u -b 10M --bind 10.0.0.5

Expected: stable UL throughput, low jitter, no loss.

Installing, Configuring, and Running the COTS UE System

Quectel RM520N Series — 5G NR Sub-6 GHz Module

Key Features

• 5G SA/NSA (3GPP Rel-16), M.2 30×52×2.3mm
• Migration compatible with RM50xQ/EM06/EM12/EM160R-GL

Performance

• SA: DL up to 2.4 Gbps / UL up to 900 Mbps
• NSA: DL up to 3.4 Gbps / UL ~550–600 Mbps

Environment

• –40°C…+85°C (extended), global carrier support

GNSS

• Qualcomm IZat Gen9C Lite: GPS/GLONASS/BDS/Galileo/QZSS

Configuring the SIM Card

If using a modem or COTS handset, a SIM is required (OAI UE softmodem on USRP does not require one).

Open-Cells SIM (ADM code printed on SIM). Read current data: sudo ./program_uicc --adm 1

Example (failure due to wrong ADM length):

No ADM code of 8 figures, cannot program the UICC

Use the correct 8-digit ADM (example): sudo ./program_uicc --adm 0C008080

Successful programming and authentication example: sudo ./program_uicc --adm QC008080 \ --key 8C6A145D419B107F93501CC02255D4C6 \ --opc 1DB7A0E55282194FC145F9B9F184979D \ --authenticate

UICC programming failure due to incorrect ADM length.

Successful UICC programming and 5G AKA authentication.

Ensure SIM values match the CN SQL database. Primary parameters:

Serial Connection to the Module via Minicom

Attach antennas, insert the module (M.2), connect via USB 3.0.

Install and start Minicom: sudo apt-get install minicom sudo minicom /dev/ttyUSB0 Exit: Ctrl-A, then X.

Quectel Module Configuration via AT Commands

Execute in Minicom (order):

1. AT+GMR – Firmware version
2. AT+CIMI – IMSI
3. AT+GSN – IMEI
4. AT+QMBNCFG="select","ROW_Commercial" – Enable commercial profile
5. AT+QNWPREFCFG="nr5g_band" – Show NR bands
6. AT+QNWPREFCFG="mode_pref" – Show mode
7. AT+QNWPREFCFG="mode_pref",nr5g – Prefer NR SA
8. AT+QNWPREFCFG="nr5g_disable_mode",0 – Enable NR
9. AT+CGDCONT=1,"IP","oai","0.0.0.0",0,0 – PDP context
10. AT+CFUN=0 then AT+CFUN=1 – Cycle functionality

Verifying Operation with AT Commands

AT+COPS? – Operator & registration

Expected:

+COPS: 0,0,"208 92 open cells",11

AT+C5GREG? – 5G registration

Expected:

+C5GREG: 2,1,"1","0",11,16,"01.00007B;00.000000:01.00000C;00.000000"

Connectivity testing of COTS UE with OAI gNB/CN via ping and iperf follows the same steps as above.

Example OOKLA Speedtest (COTS UE)

• Downlink: 48.93 Mbps
• Uplink: 4 Mbps
• Latency: ~50 ms