Power Monitoring for Energy Efficient 5G/6G with OAI and USRP

Application Note Number and Authors

AN-844

Authors

Bharat Agarwal, Neel Pandeya, Abdo Gaber and Michael Löhning

Executive Summary

To holistically measure and optimize the energy consumption of a wireless system, synchronized multi-component power measurements are needed. Measuring a single component in isolation — such as the RF Power Amplifier or the baseband processor — is insufficient to understand and optimize the system-level energy consumption, as the interactions and trade-offs between components can only be observed when all relevant power domains are measured simultaneously and aligned to a common time reference.

This Application Note describes how to implement synchronized real-time power monitoring in a 5G/6G wireless testbed using NI measurement hardware and software tools. The framework simultaneously captures power and energy consumption across multiple heterogeneous system components — including the baseband processing server, RF front-end, external Power Amplifier, and AI accelerator — and aligns all measurements to the 500 µs slot grid of the 5G NR radio frame, enabling slot-level correlation between radio activity and component-level power consumption.

Energy efficiency is a key performance indicator for 5G-Advanced and 6G systems — not only in research testbeds but also in commercial network deployments — particularly in the context of Open RAN architectures, AI-native PHY processing, and Integrated Sensing and Communication (ISAC). The synchronized power monitoring framework described here directly addresses this need by providing:

• Slot-level correlation between MAC scheduling decisions and RF PA energy consumption
• Fine-grained energy profiling of baseband processing, RF transmission, and AI inference workloads
• Quantitative measurement of energy savings achieved by cell sleep mechanisms and AI-driven schedulers
• Comparative energy profiling of AI-native vs. traditional receiver implementations

The capabilities of the framework are demonstrated on two specific use cases:

1. 3GPP-Aligned Use Case — Enhanced Cell Sleep Mechanisms: Measuring PA energy savings achieved by dynamically switching the PA off during inactive DL slots, enabled by optimized MAC resource allocation
2. AI-RAN Use Case — Neural Receiver Energy Profiling: Measuring and comparing the compute energy cost of an AI-native Neural Receiver running on a GPU against a traditional CPU-based receiver implementation

While these two use cases serve as concrete demonstrations, we are convinced that the synchronized power monitoring framework described here can be applied to a much broader range of holistic energy consumption measurements and studies, including for example:

• Energy profiling of massive MIMO and beamforming configurations across different antenna array sizes and layer counts
• Measurement of energy-per-bit as a function of modulation order, coding rate, and channel bandwidth
• Comparative energy studies of different fronthaul compression schemes in O-RAN split architectures
• Real-time energy monitoring for AI-driven MAC schedulers optimizing the trade-off between throughput, latency, and PA energy consumption
• System-level energy impact assessment of new 6G waveforms and numerologies
• Energy profiling of ISAC dual-function waveforms combining sensing and communication workloads
• Multi-cell and multi-node energy studies in open RAN deployments with disaggregated CU/DU/RU architectures

We are very interested in learning about your specific use cases and requirements for such a framework and welcome collaboration and extensions beyond the two demonstration scenarios presented here.

Overview and Demonstrator Scope

This demonstrator presents a synchronized power and energy measurement framework designed to holistically monitor instantaneous power consumption across multiple heterogeneous components of a wireless base station system. The framework addresses a critical gap in current wireless research infrastructure: the ability to correlate radio activity with component-level power consumption at the granularity of individual 5G NR transmission slots.

Synchronized Power Monitoring for Wireless Systems using Open-Air-Interface with NI USRP and NI cRIO. (*Note: For the demo, the base station prototype is connected to a 5G prototype user terminal, which is not shown in the block diagram.)

Device Under Test (DUT)

The system under test is an open, software-defined 5G base station prototype, constructed from the following components:

• Linux server — serving as the baseband processing platform
• OpenAirInterface (OAI) — open-source 5G NR base station stack
• NI USRP X410 — software-defined radio acting as the RF front-end and transceiver
• External switchable Power Amplifier (PA) — controllable in real time from the base station stack via the USRP GPIO interface

This prototype architecture is representative of emerging open RAN deployments and provides full software-level observability and modifiability of the base station's MAC, PHY, and RF layers — a prerequisite for the energy optimization use cases demonstrated here.

Measurement Framework Architecture

The measurement framework consists of two principal subsystems:

1. NI CompactRIO (cRIO) Scalable Acquisition System

The cRIO platform provides high-fidelity, multi-channel acquisition of voltage and current at each major power domain of the base station DUT. Sensor connectivity is realized as follows:

• AC voltage and current sensors are connected via a breakout box to the power supplies of the base station server and the NI USRP
• DC voltage and current sensors are connected to the power supply of the external PA

Instantaneous component power is derived continuously from these sensor readings, enabling time-resolved power profiling at each subsystem boundary.

2. Central Data Recording and Synchronization Entity

A dedicated Linux server acts as the central data recording entity. It aggregates power measurements from the cRIO acquisition system and from embedded power sensors within the base station components — including GPU and CPU power monitors in the base station server, and an onboard power sensor within the USRP.

A key capability of this entity is multi-source time synchronization: all power measurements, regardless of sensor origin, are timestamped and aligned to a common time grid corresponding to the 500 µs slot boundary of the 5G NR radio frame. This slot-aligned synchronization enables direct correlation between MAC-layer scheduling decisions and the resulting power consumption at each hardware component.

Key Features of the Measurement Framework

Feature	Description
Slot-synchronised acquisition	All measurements aligned to the 500 µs 5G NR slot grid
Multi-domain coverage	Simultaneous AC mains, DC supply, GPU, and CPU power monitoring
Real-time PA control	PA switching driven directly by OAI MAC scheduler via USRP GPIO
Scalable sensor interface	Extensible cRIO platform supports additional sensor channels
Open and modifiable DUT	Full OAI source-level access enables custom PHY/MAC energy optimization experiments

This combination of slot-level temporal resolution, multi-domain sensor coverage, and a fully open and modifiable base station prototype positions the framework as a flexible research instrument for studying energy efficiency across a broad range of future wireless system configurations.

Demo Use Cases

Use Case 1 — 3GPP-Aligned: Energy Savings via Enhanced Cell Sleep Mechanisms

This use case demonstrates measurable power amplifier energy savings through dynamic slot-level PA gating, motivated by enhanced cell sleep mechanism studies actively discussed in 3GPP standardization and investigated by research partners including TU Dresden and the Barkhausen Institute.

The core principle is to optimize MAC-layer DL resource allocation for a given mean target throughput such that the number of actively transmitted DL slots is minimized. The PA is switched on exclusively during actively scheduled DL slots and switched off otherwise, thereby drastically reducing PA power consumption during idle DL transmission periods.

3GPP Demo Use Case — Increased Cell Sleep Opportunities. The diagram illustrates the impact of MAC resource allocation on PA energy consumption (Gearbox PHY). Baseline Config 1 activates the PA across all 7 DL slots per half-frame, while Optimized Config 2 restricts transmission to a single DL slot per half-frame using a wider bandwidth and higher MCS. The PA power consumption plot (right) shows the resulting ~7× reduction in average PA power per radio frame when switching from Config 1 to Config 2.

The DL and UL transmission parameters used in this experiment are configured in two places:

• gNB Configuration File: gnb.sa.band78.fr1.106PRB.usrpx410_3300.conf — defines the carrier-level radio parameters (106 PRB carrier bandwidth, Band n78, 30 kHz SCS, TDD pattern)
• PHY Test Scheduler: openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_phytest.c — contains the hardcoded slot-level scheduling parameters including PRB allocation, MCS, slot bitmaps, and frame switching period, within the functions nr_preprocessor_phytest() (DL) and nr_ul_preprocessor_phytest() (UL)

Two DL transmission configurations are alternated every 10 radio frames to enable direct comparative measurement:

Parameter	Baseline Configuration	Optimized Configuration
Active DL slots per radio frame	14 (7 per half-frame)	2 (1 per half-frame)
Transmission bandwidth	20 PRBs	80 PRBs
Modulation and Coding Scheme	MCS 15	MCS 23
gNB TX PA behavior when no active DL slot is present	Off (not exercised for inactive DL slots in this configuration)	Off

Measurement results show that the average PA power consumption per radio frame is reduced by approximately 7× under the optimized configuration — consistent with the theoretical reduction factor derived from the ratio of active DL slots between the two configurations.

Use Case 2 — AI-RAN: Energy Profiling of AI-Native vs. Traditional Receiver

This use case quantifies the compute energy cost of integrating AI-native signal processing into the base station Physical layer. A real-time Neural Receiver is integrated into the OAI PHY layer and can be toggled at runtime against the traditional receiver implementation.

The Neural Receiver executes on an NVIDIA GPU co-located with the base station server to meet real-time latency constraints, while the traditional receiver runs on the multi-core CPU of the Linux server. The measurement framework captures total server input power, GPU power, and CPU power simultaneously, yielding the following representative measurements:

Metric	Neural RX (GPU)	Traditional RX (CPU-only)
Total server input power	~250 W	~200 W
GPU power consumption	~60 W	~10 W (idle)
CPU power consumption	~130 W	~130 W (unchanged)

The ~50 W reduction in GPU power when switching to the traditional receiver is directly reflected in the total server input power, confirming the framework's ability to accurately attribute component-level power contributions. The CPU power remaining approximately constant across both configurations is consistent with the OAI stack's default behavior of not applying dynamic compute power management.

Demonstrator System Architecture

The diagram presents a Demonstrator System Architecture used for power‑aware testing of a 5G/6G Base Station Prototype (gNB) and NI USRP. ​

5G/6G Base Station Prototype (gNB)

The Device Under Test (DUT) consists of a baseband processing platform (CPU/GPU), power supply, and an OpenAirInterface-based 5G/6G stack, connected to NI USRP hardware and an external power amplifier. AC and DC power channels are instrumented to support synchronized power and energy measurements across system components.

NI CompactRIO Power Measurement System

• cRIO Controller 9047 for power calculation and data aggregation
• Measurement modules:
  • NI-9244 — AC voltage (400 Vrms)
  • NI-9238 — AC current (±500 mV)
  • NI-9229 — DC voltage (±60 V)
  • NI-9227 — DC current (5 Arms)
• The scalable NI CompactRIO measurement system captures voltage and current across base station components and derives their instantaneous power consumption over time. Via a break-out box, AC voltage and current sensors are connected to the power supplies of the base station server and USRP. DC voltage and current sensors are connected to the power supply of the external PA.

NI Data Recording Entity / Server

The data recording entity collects power measurements from the NI CompactRIO system as well as from embedded sensors within base station components, including the USRP, GPU, and CPU. A key feature of this entity is the synchronization of all measurements to a common time grid, specifically the 500 µs slot duration of the 5G NR system. This synchronization is enabled by timestamps and additional metadata that are added to all power measurements.

5G User Terminal (UE)

The UE runs an open-source 5G stack from OpenAirInterface and communicates with the gNB via NI USRP hardware over a wired or wireless RF channel.

5G Sub‑System Demo Configuration (gNB + UE)

The following radio and scheduling parameters define the baseline 5G NR air interface configuration used across both demonstration use cases. Carrier-level parameters are sourced from the gNB configuration file gnb.sa.band78.fr1.106PRB.usrpx410_3300.conf, while slot-level scheduling parameters are hardcoded in the PHY test scheduler at openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_phytest.c.

Wireless Scenario

• Single link between one gNB and one UE
• Wired RF connection
• No interference from:
  • Neighboring cells
  • Other UEs

Radio Configuration

Operating Band

• NR Band: n78

Waveform & Numerology

• Subcarrier Spacing (SCS): 30 kHz
• Waveform: CP‑OFDM
• Channel Bandwidth: 40 MHz
• Maximum PRBs: 106

Downlink (DL) Scheduling

The DL scheduling parameters are hardcoded in nr_preprocessor_phytest() within gNB_scheduler_phytest.c. Two configurations alternate every 10 radio frames (frame_switch_period = 10):

Parameter	Baseline Config 1	Optimized Config 2	Variable in Code
Scheduled DL PRBs	20	80	target_dl_bws[] = {20, 80}
MCS	15	23	target_dl_mcss[] = {15, 23}
DL Slot Bitmap	130175	2050	target_dl_bitmaps[] = {130175, 2050}
Active DL slots per frame	14 (7 per half-frame)	2 (1 per half-frame)	derived from bitmap
Switching interval	Every 10 frames		frame_switch_period = 10

The DL slot bitmap encodes the scheduling pattern across slots, where each bit represents one slot and a value of ‘1’ indicates an active DL transmission. For example, the baseline configuration bitmap (130175) corresponds to 14 active DL slots, while the optimized configuration (2050) results in only 2 active DL slots (DL case 1: 00011 11111 00011 11111 = 130,175 and DL Case 2: 00000 00010 00000 00010 = 2050). This sparse scheduling in the optimized case introduces extended idle periods, enabling power amplifier deactivation and improved energy efficiency.

Uplink (UL) Scheduling

The UL scheduling parameters are hardcoded in nr_ul_preprocessor_phytest() within gNB_scheduler_phytest.c:

• Scheduled UL PRBs: 6 — kept intentionally low to ensure gNB Neural Receiver real‑time performance (target_ul_bws[] = {6, 6})
• UL MCS: 23 (target_ul_mcss[] = {23, 23})
• UL Slot Bitmap: 256 (ulsch_slot_bitmaps[] = {256, 256})
• UL transmission bandwidth: ~2.16 MHz

TDD Configuration

The TDD frame structure is defined in gnb.sa.band78.fr1.106PRB.usrpx410.conf with a DL/UL periodicity of 5 ms.

Parameter	Value	Config File Variable
nrofDownlinkSlots	7	nrofDownlinkSlots = 7
nrofDownlinkSymbols	6	nrofDownlinkSymbols = 6
nrofUplinkSlots	2	nrofUplinkSlots = 2
nrofUplinkSymbols	4	nrofUplinkSymbols = 4

Power Monitoring Demonstrator – Bill of Materials

The Power Monitoring Demonstrator integrates high‑performance servers, SDR radios, RF components, and an NI CompactRIO measurement system to evaluate and monitor the power consumption of various wireless 5G/6G components. The following table lists all required hardware components. Where a specific model is listed, it reflects the configuration used in the demonstrator; equivalent hardware meeting the stated requirements may be substituted.

Equipment	Requirements / Specifications	Model Used in Demo	Quantity
Server (gNB + UE + Data Recording)	Multi-core x86-64 processor, minimum 20 cores / 40 threads Base clock ≥ 2.5 GHz, Turbo ≥ 4.5 GHz TDP ≥ 200 W (high-performance workstation class) Minimum 64 GB DDR5 ECC RAM PCIe Gen 4 x16 slot (for GPU) Minimum 2× PCIe x8 slots (for dual-port 25 GbE NICs) Ubuntu 22.04 LTS compatible	Dell Precision 5860 Tower Intel Xeon W7-2495X (45 MB cache, 24 cores, 48 threads, 2.5 GHz to 4.8 GHz Turbo, 225 W)	3
Network Card (10GbE SFP+)	Quad-port 10GbE SFP+, Linux driver support (i40e)	Intel X710 Quad Port 10GbE SFP+ Adapter	1
Ethernet Cable (SFP+)	10G SFP+ DAC or optical, ≥ 2 m	10G Ethernet Cable SFP+ 2 m	2
SFP-to-RJ45 Adapter	1GbE SFP copper transceiver	FCLF8522P2BTL	1
Network Card (25GbE SFP28)	Dual-port 1/10/25GbE SFP28, Linux MLNX_OFED driver support	Mellanox MCX512A-ACAT	4
QSFP28 → 4×SFP28 Breakout Cable	100GbE QSFP28 to 4×25GbE SFP28, ≥ 3 m	NVIDIA MCP7F00-A003R26N or NI PN 788214-01	2
NVIDIA GPU (Neural Receiver)	NVIDIA GPU, CUDA 12.x compatible, ≥ 16 GB VRAM, PCIe Gen 4 x16	NVIDIA GeForce RTX 4090 Founders Edition	1
Extra GPU Power Cable	10‑pin to 8‑pin PCIe adapter (not required for Dell Precision 5860 — onboard PCIe power sufficient)	COMeap 10‑pin to 8‑pin PCIe Cable	1
NI USRP	NI USRP X410 (copper SFP28 interface, not fiber-optic variant)	USRP X410	2
External Clock + PPS Source	10 MHz REF + PPS output, GPSDO or equivalent	OctoClock‑G CDA‑2990	1
cRIO Power Measurement System	NI CompactRIO chassis + AC voltage, AC current, DC voltage, DC current modules	cRIO 9047 + NI‑9238, NI‑9244, NI‑9229, NI‑9227	1
RF Cables	SMA(M)‑to‑SMA(M), 50 Ω, ≥ 1 m	Standard SMA(M)‑to‑SMA(M) RF Cables (1 m)	7
20 dB RF Attenuators	SMA‑F to SMA‑M, 20 dB fixed, 50 Ω, ≥ 2 W	SMA‑F to SMA‑M Fixed Attenuators	2
10 dB RF Attenuators	SMA‑F to SMA‑M, 10 dB fixed, 50 Ω, ≥ 2 W	SMA‑F to SMA‑M Fixed Attenuators	2
Switchable Power Amplifier	Fast-switching RF PA, GPIO-controllable enable pin, n78 band compatible	Skyworks SKY67154	1
AC Current Clamps	Split-core AC current transformer, ≥ 20 A range, cRIO compatible	Magnelab SCT‑0750‑020	2
HDMI Breakout Connector	19‑pin HDMI Type A terminal block adapter (GPIO signal routing only)	19‑pin HDMI Terminal Block Adapter	1
USB‑C to USB‑A Cable	Standard USB 2.0 or above, ≥ 1 m	Standard	1
Network Switch (Optional)	≥ 4 × 1GbE ports, unmanaged or managed (for demo / remote access)	Any compatible 4+ port switch	1
1G Ethernet Cables	Standard Cat5e or above, RJ45	Standard	4

Hardware System Block Diagram Explanation

The diagram shows a full hardware setup for a 5G/6G research testbed.

The following sections describe the hardware setup component by component, followed by step-by-step connection instructions for each subsystem.

OAI Base Station (gNB) – Linux Server 1

This server runs the OpenAirInterface gNB software stack and hosts an NVIDIA RTX 4000 GPU for Neural Receiver processing. The following connections are required:

1. Connect the NI USRP X410 to the NIC of the gNB server using a QSFP28 to 4×SFP28 breakout cable (NVIDIA MCP7F00-A003R26N or NI PN 788214-01).
2. Connect GPIO0 of the NI USRP X410 to the external switchable PA via the HDMI breakout connector and associated wiring (Details of the associated wiring are described in a later section):
   • Pin 16 [Data 10] — PA control signal
   • Pin 17 — Ground reference
3. Create the RF connections in the following order:
   1. Connect an SMA RF cable to RF0/TX1 of the NI USRP X410.
   2. Connect the other end of the cable to the input of a 20 dB SMA attenuator.
   3. Connect the output of the 20 dB attenuator to the RF input of the switchable PA (Skyworks SKY67154).
   4. Connect the RF output of the PA to a second 20 dB SMA attenuator.
   5. Connect the output of the second attenuator to RF0/RX2 of the UE USRP X410.

OAI Soft User Terminal (UE) – Linux Server 2

This server runs the OAI software UE stack. The following connections are required:

1. Connect the NI USRP X410 (UE side) to the NIC of the UE server using a QSFP28 to 4×SFP28 breakout cable.
2. Create the UL RF return path connections:
   1. Connect an SMA RF cable to RF0/TX1 of the UE USRP X410.
   2. Connect the other end to a 20 dB SMA attenuator.
   3. Connect the output of the attenuator to RF0/RX2 of the gNB USRP X410.

USRP X410 Radios

Two NI USRP X410 SDR units are used — one for the gNB and one for the UE. Note that the copper SFP28 electrical interface is used in this setup; the fiber-optic USRP variant is not used. Each USRP connects to its respective host server via a QSFP28 to 4×SFP28 breakout cable over a 4×25 GbE link. RF connections are routed through SMA cables, fixed attenuators, and the external switchable PA.

Data Recording – Linux Server 3

This server functions as the central data recording entity. Connect it as follows:

1. Connect Linux Server 3 to the NI cRIO 9047 via a 1 GbE Ethernet cable — this is the only connection that uses 1 GbE and is dedicated exclusively to cRIO power measurement data transfer.
2. Connect Linux Server 3 to the gNB server (Linux Server 1) via a 10 GbE SFP+ cable using the Intel X710 quad-port NIC for log and control data exchange.
3. Connect Linux Server 3 to the UE server (Linux Server 2) via a 10 GbE SFP+ cable for log synchronization.
4. The USB-A to USB-C cable connects Linux Server 3 → NI USRP X410 (gNB side) for reading USRP power consumption via the embedded onboard sensor. It does not connect to the PA control board.The PA is powered separately — either via a dedicated USB power supply or directly from the data recording server.

Fast Switching Power Amplifier (Skyworks SKY67154)

The Skyworks SKY67154 is a fast-switching PA placed between the two 20 dB RF attenuator stages in the RF chain. Important: this PA provides no RF gain control — it is used exclusively to emulate RF switching on/off for the cell sleep mechanism demonstration. Connect it as follows:

1. Mount the PA between the two 20 dB SMA attenuators in the RF chain.
2. Connect the DC power supply to the PA board power input.
3. Connect DC voltage and current sensors to the PA power supply lines and route them to the NI cRIO DC input modules:
   • NI-9238 — DC voltage
   • NI-9229 — DC current
4. Verify the HDMI breakout connector wiring (Pin 16 control, Pin 17 ground) matches the PA enable logic before powering on.

RF Attenuators and Breakout Hardware

The RF path uses fixed 20 dB SMA attenuators on both sides of the PA to protect the USRP ports and the PA itself from excessive signal levels.

On the uplink (UL) return path from the UE USRP to the gNB USRP, a fixed attenuator in the range of 20–30 dB is used. The exact value should be selected based on the measured path loss and the desired received signal level at the gNB USRP RX input.

The HDMI breakout connector (19-pin terminal block adapter) is used solely to carry the GPIO PA control signal from the NI USRP to the PA enable pin. It is not used for RF signal routing or measurement.

Summary of RF Connections and Control Connections

The RF connections between the two NI USRP X410 units are routed through fixed attenuators and the Fast Switching PA. The PA is present in the downlink path only. The uplink path uses a direct attenuated connection with no PA.

Downlink (gNB TX → UE RX)

NI USRP X410 — RF0/TX1 (gNB, Server 1)
    │
    └──► SMA cable
              │
              └──► 20 dB Attenuator
                        │
                        └──► Fast Switching PA (Skyworks SKY67154)
                        │    [PA enable controlled via GPIO0 over HDMI breakout — see Section 2.3]
                             │
                             └──► 20 dB Attenuator
                                       │
                                       └──► NI USRP X410 — RF0/RX2 (UE, Server 2)

Uplink (UE TX → gNB RX)

NI USRP X410 — RF0/TX1 (UE, Server 2)
    │
    └──► SMA cable
              │
              └──► 20~30 dB Attenuator
                        │
                        └──► NI USRP X410 — RF0/RX2 (gNB, Server 1)

External Clock and Synchronization

1. Connect the OctoClock-G CDA-2990 10 MHz REF output to the REF IN port of both USRP X410 units.
2. Connect the PPS output of the OctoClock-G to the PPS IN port of both USRP X410 units.
3. Verify both USRPs report clock lock before launching the OAI software stack.

Network connection and IP configurations

This section describes the Ethernet connections and IP address configurations required to bring up the testbed. It focuses on network and control interfaces and does not include power or RF cabling. It covers:

System Network and High-Speed Links

USRP to Server Links

1. gNB USRP X410 → Linux Server 1: QSFP28 to 4×SFP28 breakout cable, 4×25 GbE (Mellanox MCX512A-ACAT NIC on server side).
2. UE USRP X410 → Linux Server 2: QSFP28 to 4×SFP28 breakout cable, 4×25 GbE (Mellanox MCX512A-ACAT NIC on server side).

Data Recording Server Links

1. Linux Server 3 → NI cRIO 9047: 1 GbE Ethernet (dedicated power measurement data only).
2. Linux Server 3 → Linux Server 1 (gNB): 10 GbE SFP+ (Intel X710 quad-port NIC).
3. Linux Server 3 → Linux Server 2 (UE): 10 GbE SFP+ (Intel X710 quad-port NIC).
4. Linux Server 3 → PA control board: USB-A to USB-C serial cable.

Network Interfaces

Server 1 ↔ Server 3 (Management / Data)

Parameter	Value
Server 1 IP	192.168.100.2
Server 3 IP	192.168.100.1
Link Type	10/25GbE SFP28 or 10GbE SFP+

Server 2 ↔ Server 3 (Management / Data)

Parameter	Value
Server 2 IP	192.168.110.2
Server 3 IP	192.168.110.1
Link Type	10/25GbE SFP28 or 10GbE SFP+

Server 1 ↔ USRP X410 (Fronthaul)

Parameter	Value
Server 1 IPs	192.168.10.2 / 192.168.11.2
USRP X410 IPs	192.168.10.1 / 192.168.11.1
Link Type	4×25GbE QSFP28 → 4×SFP28

Server 2 ↔ USRP X410 (Fronthaul)

Parameter	Value
Server 2 IPs	192.168.10.2 / 192.168.11.2
USRP X410 IPs	192.168.10.1 / 192.168.11.1
Link Type	4×25GbE QSFP28 → 4×SFP28

Server 3 ↔ NI cRIO

Parameter	Value
Server 3 IP	192.168.120.1
NI cRIO IP	192.168.120.2
Link Type	1GbE + USB-A → USB-C Serial

Power Measurement Setup and PA Control Wiring

Notes

• Note: Refer to the instrument-level documentation for information about the instruments referenced in this application note, including proper use, I/O connections, and pinouts. All I/O must be connected per the ratings of the individual components included in the product.

Cautions

• Caution: The safety of the setup is the responsibility of the installer/user. Refer to the instrument-level documentation for cautions and safe use of equipment.
• Caution: The safety and compliance of any devices or custom assemblies created by the installer/user per this application note is the responsibility of the installer/user per local codes, safety standards, and workplace safety laws. The installation must follow electrical safety rules, laws, and standards in the country of use.
• Caution: The AC branch must be installed and used in accordance with local electrical codes, including considerations for GFCI, RCD, or other safety monitors.
• Caution: Setup, installation, operation, and maintenance must be performed by qualified service persons.
• Caution: Observe all instructions and cautions in the user documentation. Using the product in a manner not specified can damage the product and compromise the built-in safety protection.

Warnings

⚠ WARNING — RISK OF ELECTRIC SHOCK: Ensure that hazardous voltage wiring is performed only by qualified personnel adhering to local electrical standards.

⚠ WARNING — RISK OF ELECTRIC SHOCK: Do not mix hazardous voltage circuits and human-accessible circuits on the same product. All wiring must be insulated for the highest voltage used.

Applicability: The cautions and warnings above apply in particular to the AC power measurement wiring described in this application note, specifically the connections of the Magnelab SCT-0750-020 AC current clamps and the NI-9244 AC voltage module to the 230V AC mains supply. All AC wiring must be performed by a qualified electrician in accordance with local electrical codes before the testbed is powered on.

The diagram shows the Power Measurement and PA Control Connections.

This section describes the power supply connections, measurement wiring, and PA control signal connections for the Power Monitoring Testbed. System component descriptions are covered in the Hardware Components section above — this section focuses exclusively on the connections and additional power supply details required to realize the measurements.

1. Power Supply Connections

Each testbed subsystem is powered independently. The table below lists the power supply type and ratings for each subsystem and identifies which are included in the measurement chain.

Subsystem	Supply Type	Voltage / Current Rating	Included in Measurement?
Base Station Server (gNB)	AC Mains	230V AC	Yes
NI USRP X410 (RU)	AC Mains	230V AC	Yes
Fast Switching PA Fixture (Skyworks SKY67154)	USB Power Supply (DC)	5V DC	Yes
NI cRIO 9047 Chassis	Dedicated DC Power Supply	24V / 5A DC	No — power connection only
UE Server + UE USRP X410	AC Mains	230V AC	No — not monitored in this configuration

Note: The NI cRIO chassis and UE subsystem are powered independently from the measurement chain. Their power consumption is not captured by the measurement framework in this configuration.

2. Power Measurement Connections

2.1 AC Current and Voltage Measurement — gNB Server and NI USRP X410

AC current is measured indirectly using Magnelab SCT-0750-020 split-core current transformer clamps (current clamps). Each clamp is placed around the AC supply cable of the device to be measured and converts the AC line current to a low-level voltage signal that is connected to the NI-9238 AC current input module in the cRIO chassis.

AC voltage is measured directly across the L1 (Live) and N (Neutral) terminals of the main AC supply and connected to the NI-9244 AC voltage input module.

Make the following connections:

1. Clamp a Magnelab SCT-0750-020 current clamp around the AC supply cable of the gNB Base Station Server.
   Connect the clamp output to NI-9238 Ch0: White → 0+ / Black → 0−.
   Ensure the clamp is oriented in the correct direction relative to current flow to obtain a positive reading.
2. Clamp a second Magnelab SCT-0750-020 current clamp around the AC supply cable of the NI USRP X410 (RU).
   Connect the clamp output to NI-9238 Ch1: White → 0+ / Black → 0−.
3. Connect the L1 (Live) and N (Neutral) terminals of the main AC supply directly to the NI-9244 input terminals for AC voltage measurement.

Important: The NI-9238 does not connect directly to the AC power line. It measures only the low-level output signal of the Magnelab current clamp. Never connect the AC power line directly to the NI-9238 input terminals.

2.2 DC Current and Voltage Measurement — Fast Switching PA Fixture

DC current and voltage are measured directly on the 5V PA supply lines using inline connections to the NI-9227 and NI-9229 modules. No external transducer is required.

Make the following connections:

1. Connect the 5V USB power supply output inline through NI-9227 Ch0 for DC current measurement.
   Orient the connection according to current flow direction: 0+ to 0−.
2. Connect the PA board supply voltage to NI-9229 Ch0 for DC voltage measurement.
   Red → 0+ / Black → 0−.

2.3 NI cRIO Measurement Module Connection Summary

Slot	Module	Measurement	Connected To	Transducer
1	NI-9227	DC current — PA supply (Ch0)	5V PA supply line (inline)	None — direct connection
2	NI-9229	DC voltage — PA supply (Ch0)	5V PA supply terminals	None — direct connection
3	NI-9238	AC current — gNB server (Ch0) AC current — USRP X410 RU (Ch1)	Output of Magnelab SCT-0750-020 current clamp (one per channel)	Magnelab SCT-0750-020 split-core current clamp
4	NI-9244	AC voltage — main supply (L1, N)	AC mains L1 and Neutral terminals	None — direct connection

3. PA Control Signal Connections

The Fast Switching PA is controlled in real time by GPIO0 of the NI USRP X410 (RU), routed via the HDMI breakout connector. The signal is synchronized to the 5G NR TDD frame timing, switching the PA on/off in alignment with gNB DL transmission slots.

Figure: Fast Switching PA Fixture (Skyworks SKY67154) mounted on top of the NI USRP X410. PA control signal routed via GPIO0 over HDMI breakout connector (left arrow). DC power supply connected directly to the PA board (right arrow).

Make the following connections:

1. Connect the HDMI breakout connector to the GPIO header of the NI USRP X410.
2. Connect Pin 16 of the HDMI breakout to the V_EN (PA enable) input of the PA board using a red wire.
3. Connect Pin 17 of the HDMI breakout to the GND of the PA board using a black wire.

HDMI Pin	Signal	Wire Color	Description
Pin 16	V_EN (GPIO0)	Red	3.3V PA enable signal — logic low = PA on / logic high = PA off (active-low enable)
Pin 17	GND	Black	Ground reference for the GPIO enable signal

Important: The HDMI connector is used purely as a convenient multi-pin breakout for GPIO signal routing. It carries no video or audio signals.

Software Installation

This section covers the software installation for all four entities in the testbed. For OAI gNB with Neural Rx and OAI UE, the installation follows the existing Application Note AN-829.

⚠ IMPORTANT NOTE — Source Code Repository

Do NOT clone the OAI gNB, Neural Receiver, or OAI UE source code directly from the public GitHub repository for this testbed setup, as described in Application Note AN-829.

For the Power Monitoring implementation described in this Application Note, the source code must be cloned from the dedicated branch specific to this AppNote. Using the incorrect branch will result in missing power monitoring features and incompatible software configurations.

The sections below provide direct references to the relevant steps in that document, along with the additional installation procedures for the NI cRIO and the Data Recording Server.

#	Entity	Host	Reference
1	OAI gNB with Neural Rx	Linux Server 1	AN-829 — Ettus KB
2	OAI UE	Linux Server 2	AN-829 — Ettus KB
3	NI cRIO	CompactRIO Chassis	See Section 3.3 below
4	Data Recording Server	Linux Server 3	See Section 3.4 below

Software Installation Summary

Entity	Server	OS	Key SW Components	GPU Required
OAI gNB + Neural Rx	Server 1	Ubuntu 22.04.5	UHD 4.8, CUDA 12.2, TF 2.14, OAI gNB, FlexRIC, xApp	Yes — RTX 4090
OAI UE	Server 2	Ubuntu 22.04.5	UHD 4.8, OAI nrUE	Optional
NI cRIO	cRIO Chassis	NI Linux Real-Time	NI-RIO, NI-DAQmx, LabVIEW RT App	No
Data Recording	Server 3	Ubuntu 22.04.5	Python 3, Wireshark (optional), tcpdump, SSH	No

OAI gNB with Neural Rx (Linux Server 1)

The OAI gNB software installation on Server 1 follows the procedure described in the existing Ettus Knowledge Base Application Note AN-829: 5G OAI Neural Receiver Testbed with USRP X410.

The relevant sections to follow are listed below in order.

Step	Section in AN-829	Description
1	Power Management and BIOS Settings	Disable C-states, Hyper-Threading; enable SpeedStep and Turbo Boost
2	High-Speed Ethernet Configuration	Set MTU=9000, socket buffers, ring buffers for SFP28 interfaces
3	NVIDIA CUDA Drivers	Install Nvidia driver 535 + CUDA 12.2 on Ubuntu 22.04
4	TensorFlow 2.14 + TensorRT + TF C-API	Install TF 2.14 in Python venv, install TF C-API to /usr/local/lib
5	UHD 4.8.0.0	Build and install UHD from source; download USRP images
6	OAI gNB Source Code	Clone NI repository branch; comment out UHD re-install in build script
7	Neural Receiver Library	Build libtest_inference.a and call_test_inference.o
8	gNB and USRP Configuration	Set USRP IP addresses and clock source in .conf file
9	FlexRIC	Build FlexRIC with SWIG 4.1 and GCC 10/12
10	xApp gRPC Service	Build xAppTechDemo library and gRPC server interface

Note: Server 1 requires the Nvidia RTX 4090 GPU. Ensure the GPU is installed before beginning the CUDA driver installation step.

On this server, install the following additional packages to enable CPU and GPU power reading by the data recording application:

To read CPU Power:

sudo apt-get install msr-tools

To read GPU Power:

sudo pip install nvidia-ml-py3

OAI UE (Linux Server 2)

The OAI Soft UE software installation on Server 2 also follows AN-829. Server 2 does not require GPU acceleration or the Neural Receiver library.

The relevant sections to follow are listed below in order.

Step	Section in AN-829	Description
1	Power Management and BIOS Settings	Same BIOS optimizations as Server 1
2	High-Speed Ethernet Configuration	MTU=9000 and socket buffer tuning for SFP28 interfaces
3	UHD 4.8.0.0	Build and install UHD from source (same as gNB side)
4	OAI UE Source Code	Clone NI UE repository; comment out UHD re-install in build script
5	Build OAI Soft UE	Build with --nrUE -w USRP flags
6	OAI UE Configuration	Set IMSI, key, OPC, DNN in ue.conf

Note: Server 2 does not require TensorFlow, CUDA, or the Neural Receiver library. A lower-performance GPU (e.g., RTX 4060) may be installed but is not required for UE operation.

Data Recording Server Installation (Linux Server 3)

Server 3 acts as the central data recording and experiment orchestration node. It requires network configuration, data capture tools, and connection management for both the compute servers and the NI cRIO.

Operating System

Parameter	Value
OS	Ubuntu 22.04.5 LTS
Kernel	6.5.0-44-generic or later
Installation type	Bare-metal (no VM)

Network Interface Configuration

Configure all network interfaces on each Linux server with static IP addresses corresponding to the system block diagram. Two methods are available depending on whether the user has local (physical) or remote (terminal-only) access to the machine.

Important: Pay attention to the NIC port number and its corresponding IP address. For multi-port NICs, Ubuntu Desktop GUI lists ports from top (port 1) to bottom (port N). On the physical NIC card, ports are typically numbered right to left. Confirm correct IP settings after configuration by running:

ifconfig

Option A — Ubuntu Desktop GUI (Network Manager)

This is the recommended method when a screen, keyboard, and mouse are available. The user must connect peripherals to each machine at least once to complete initial network configuration.

1. Open Settings → Network on the Ubuntu Desktop.
2. Select the network interface to configure and click the gear icon (settings).
3. Navigate to the IPv4 tab.
4. Set the method to Manual.
5. Enter the static IP address, subnet mask, and gateway as listed in the system block diagram for that interface.
6. Click Apply and toggle the interface off and on to activate the new settings.
7. Verify the configuration:

   ifconfig
   

Note: The Network Manager GUI method is straightforward and does not require command-line editing. No further explanation of the GUI itself is provided here.

Option B — Netplan via Terminal (Remote or Headless Access)

Use this method if the machine cannot be accessed locally (e.g., no screen available) or if a terminal-based configuration is preferred. Netplan is the default network configuration tool on Ubuntu 20.04 and later. Ensure the Netplan renderer is set to NetworkManager or networkd as appropriate for the system.

Step 1 — Identify the Netplan configuration file:

ls /etc/netplan/

The default file is typically named 01-network-manager-all.yaml.

Step 2 — Back up the current configuration:

sudo cp /etc/netplan/01-network-manager-all.yaml \
        /etc/netplan/01-network-manager-all_backup.yaml

Step 3 — Open the configuration file for editing:

sudo nano /etc/netplan/01-network-manager-all.yaml

Step 4 — Update the Netplan configuration.
The example below shows the static IP configuration for the Base Station Server (Linux Server 1). Adapt interface names and IP addresses for each server according to the system block diagram:

network:
  version: 2
  renderer: NetworkManager
  ethernets:
    enp<usrp_iface>:                  # Interface connected to gNB USRP X410
      dhcp4: no
      addresses:
        - 192.168.10.1/24             # Adapt per system block diagram

    enp<ue_server_iface>:             # Interface connected to UE server / data network
      dhcp4: no
      addresses:
        - 192.168.11.1/24            # Adapt per system block diagram

    enp<crio_iface>:                  # Interface connected to NI cRIO 9047
      dhcp4: no
      addresses:
        - 192.168.100.2/24            # Adapt per system block diagram

Note: Netplan YAML files are sensitive to indentation and formatting. Use spaces (not tabs) for indentation. Incorrect formatting will prevent the configuration from being applied.

Step 5 — Save and close the file (Ctrl+O to save, Ctrl+X to exit nano).

Step 6 — Apply the new configuration:

sudo netplan apply

Step 7 — Verify the IP settings:

ifconfig

Step 8 — Confirm connectivity to all nodes:

ping 192.168.10.2      # gNB USRP X410
ping 192.168.11.2     # UE Server (Linux Server 2)
ping 192.168.100.1     # NI cRIO 9047

Packet Capture Setup

Verify that Wireshark or tcpdump can capture on the relevant interfaces:

sudo tcpdump -i enp<server1_iface> -w /data/capture_gnb.pcap

Ensure the /data directory has sufficient storage for experiment recordings.

SSH Access Configuration

Enable passwordless SSH from Server 3 to Server 1 and Server 2 for automated experiment orchestration:

ssh-keygen -t rsa -b 4096
ssh-copy-id [email protected]   # Server 1
ssh-copy-id [email protected]   # Server 2

NI cRIO Software Installation

The NI CompactRIO (cRIO-9047) supports two installation methods for the Python-based gRPC server software: an automated deployment script (recommended) and a manual installation procedure. Both methods are described below.

For more details on general cRIO hardware setup, refer to the Getting Started with CompactRIO Hardware and LabVIEW guide.

cRIO Initial System Bring-Up — Prerequisites

Important: The initial NI cRIO system bring-up requires a Windows PC. NI MAX (Measurement & Automation Explorer) and the NI CompactRIO driver are Windows-only tools and must be installed and run on a Windows PC. Linux is not supported for this step.

The Windows PC must be connected to the cRIO via Ethernet for the initial setup. Use one of the following connection options:

• Direct connection: Connect the Windows PC directly to the cRIO Eth0 (Primary) port using a standard Ethernet cable
• Network connection: Connect both the Windows PC and the cRIO to the same local network switch — ensure they are on the same subnet

Windows PC — Required Software Installation

Perform the following installations on the Windows PC before proceeding. All software is available from the NI website.

1. Download and install NI CompactRIO driver version 2025 Q1 on the Windows PC:
   [https://www.ni.com/en/support/downloads/drivers/download.compactrio.html NI CompactRIO Driver Download Page]

   This installs NI MAX (Measurement & Automation Explorer) automatically as part of the driver package. NI MAX is the primary tool used for all subsequent cRIO configuration steps and runs on the Windows PC only.

2. Download the NI Linux Real-Time System Image 2025 Q1 on the Windows PC:
   [https://www.ni.com/en/support/downloads/software-products/download.ni-linux-real-time-system-image.html NI Linux RT System Image Download Page]

   This image will be deployed to the cRIO chassis in the next step via NI MAX running on the Windows PC.

cRIO Base Image Installation via NI MAX (Windows PC)

All steps in this section are performed in NI MAX running on the Windows PC.

1. Open NI MAX on the Windows PC (Start → National Instruments → NI MAX).
2. In the left panel, expand Remote Systems. The cRIO should appear automatically if connected to the same network. If it does not appear:
   • Verify the Ethernet cable connection between the Windows PC and the cRIO
   • Ensure both devices are on the same subnet
   • Click F5 to refresh the device list
3. Select the cRIO target in the left panel (e.g., NI-cRIO-9047).
4. Click Format Target or navigate to Software → Add/Remove Software to begin the base image installation.
5. Select Linux RT System Image 2025 Q1 (Version 25.0.0) from the available image list and click Next.
6. NI MAX will deploy the image to the cRIO and trigger an automatic cRIO reboot. Wait for the reboot to complete before proceeding.
7. After the reboot, NI MAX will prompt you to select a programming environment. Select:

   Other (…, Python, etc.)

8. Keep the default software selections and click Continue.
9. Wait for NI MAX to complete the software installation on the cRIO. After completion, verify the following software components appear under the Software tab of the cRIO target in NI MAX:

   Software Component	Version
   Linux RT System Image 2025 Q1	25.0.0
   CompactRIO Support	25.0.0
   NI System Configuration	25.0.0
   NI-DAQmx	25.0.0
   NI-RIO Server	25.0.0
   NI-VISA	25.0.0
   NI Sync	25.0.0
   SystemLink Client	25.0.0

Note on password setup: If you encounter issues setting the administrator password during this step, finalize the software installation first and set the password afterwards via NI MAX → System Settings → Set Permissions on the Windows PC.

Note on subsequent steps: After the base image installation is complete, all remaining cRIO configuration steps (module renaming, network settings, firmware update) are also performed via NI MAX on the Windows PC. The Python software deployment steps that follow (Sections 3.3.5 onwards) are performed from Linux Server 3 via SSH.

And the following C Series modules should appear under the cRIO chassis:

Slot	Module	Assigned Name
1	NI 9227	NI-9227
2	NI 9229	NI-9229
3	NI 9238	NI-9238
4	NI 9244	NI-9244

Output of NI MAX. ​

Firmware Update

If a firmware update is required, update to version 24.5.0f133-x64.

The firmware file is located at:

Firmware File Location : C:\Program Files (x86)\National Instruments\Shared\Firmware\cRIO\78E9

To update via NI MAX:

1. Select the cRIO target in the left panel (e.g., NI-cRIO-9047-Dev1).
2. In the System Settings panel on the right, verify the current Firmware Version.
3. Click Update Firmware and follow the on-screen instructions.
4. Verify the Operating System shows: NI Linux Real-Time x64 6.1.119-rt45
5. Verify Status shows: Connected - Running

Firmware Update. ​

Rename C Series Modules in NI MAX

The module names are used by the Python RT implementation to identify modules based on a JSON configuration file. Rename each module in NI MAX as follows:

1. In NI MAX, expand the cRIO chassis node to show the installed modules.
2. Right-click each module → Rename.
3. Set the names exactly as shown in the table below.

Slot	Module	Required Name
1	NI 9227	NI-9227
2	NI 9229	NI-9229
3	NI 9238	NI-9238
4	NI 9244	NI-9244

To verify the module settings, click on each module in NI MAX and confirm:

• Program Mode: Real-Time (NI-DAQmx)
• Status: Present

NI MAX — cRIO-9047 C Series Module Rename (NI 9244 in Slot 4, Program Mode: Real-Time NI-DAQmx). ​

NI cRIO Network Configuration (NI MAX)

The NI cRIO 9047 has two Ethernet interfaces that must be configured differently based on their role in the testbed:

• Eth0 (Primary) — set to DHCP to allow the cRIO to reach the internet for driver updates and NI software deployment
• Eth1 (Secondary) — set to a static IP for reliable communication with the Data Recording Server (Linux Server 3) on the testbed internal network

To configure both interfaces in NI MAX:

1. Open NI MAX (Measurement & Automation Explorer) on the host PC.
2. Expand Remote Systems and select the cRIO 9047 target.
3. Navigate to the Network Settings tab.

Eth0 — Primary Interface (DHCP / Internet Access)

Parameter	Value
Adapter	Ethernet Adapter eth0 (Primary)
Adapter Mode	TCP/IP Network
Configure IPv4 Address	DHCP
IPv4 Address	Assigned automatically by DHCP server
Purpose	Internet access — NI software updates, driver deployment

Note: Eth0 must be connected to a network with internet access (e.g., via a lab router or managed switch with DHCP). This interface is not used for testbed internal communication.

Eth1 — Secondary Interface (Static / Testbed Internal Network)

Parameter	Value
Adapter	Ethernet Adapter eth1 (Secondary)
Adapter Mode	TCP/IP Network
Configure IPv4 Address	Static
IPv4 Address	192.168.120.2
Subnet Mask	255.255.255.0
Gateway	192.168.120.1
DNS Server	172.22.86.10 (or as required by local network)
Purpose	Testbed internal network — power measurement data transfer to Data Recording Server (Linux Server 3)

Note: Eth1 must be connected directly to the Data Recording Server (Linux Server 3) as shown in the system block diagram. The static IP 192.168.120.2 must match the corresponding interface IP configured on Linux Server 3 (see Section 3.4.2 — Network Interface Configuration).

4. Click Apply in NI MAX after configuring both interfaces.
5. Restart the cRIO if prompted to apply the network changes.
6. Verify connectivity from Linux Server 3:

   ping 192.168.120.2    # NI cRIO Eth1 — testbed internal network
   

NI MAX — cRIO-9047 Network Adapter Settings showing eth0 (Primary) configured with IPv4 address 10.94.17.30, eth1 and usb0 set to DHCP or Link Local

User / Password Settings

To set the administrator password, click Set Permissions in NI MAX toolbar:

Field	Value
Old password	<keep empty>
New password	admin
Confirm password	admin

Click OK and reboot the cRIO to apply.

NI MAX — cRIO-9047 User Settings: Change Administrator Password via "Set Permissions" (Leave Old Password Empty, Set New Password to "admin")

Clone Source Code

On each server, create the working directory and clone the source code repository specific to this Application Note. Do NOT clone from the public OAI GitHub repository — use only the dedicated branch listed below, which contains the Power Monitoring implementation described in this AppNote.

Step 1 — Create the working directory:

mkdir -p /home/user/workarea/oai/
cd /home/user/workarea/oai/

Step 2 — Clone the repository:

git clone --branch <appnote-branch-name> <repository-url> .

Prepare cRIO Python Environment

Before installing the Python software, prepare the directory structure and locale settings on the cRIO.

Get the Software Packages

The Python wheel files for the cRIO software are built directly from the repository source code on the Data Recording Server (Linux Server 3). No separate download is required — all packages are part of the repository cloned in Server 3.

The relevant source directories within the repository are:

Package	Repository Source Path	Used On
crio_grpc_shared	support_lti_6g_sw/power_monitoring/crio/python/crio_grpc_shared/	Both cRIO and Data Recording Server (Linux Server 3)
crio_grpc_server	support_lti_6g_sw/power_monitoring/crio/python/crio_grpc_server/	cRIO only
crio_grpc_client	support_lti_6g_sw/power_monitoring/crio/python/crio_grpc_client/	Data Recording Server (Linux Server 3) only

The wheel files are built from these source directories as part of the deployment process. If using the automated deployment script (Method A — recommended), the script handles building and copying the wheel files automatically. If using manual installation (Method B), build the wheel files on Linux Server 3 before copying them to the cRIO:

# Navigate to the shared package and build
cd /home/user/workarea/oai/<repository-name>/support_lti_6g_sw/power_monitoring/crio/python/crio_grpc_shared/
pip install build
python3 -m build --wheel

# Navigate to the server package and build
cd /home/user/workarea/oai/<repository-name>/support_lti_6g_sw/power_monitoring/crio/python/crio_grpc_server/
python3 -m build --wheel

The built .whl files will be located in the dist/ subdirectory of each package folder. Use these paths in the scp commands described in Method B — Manual Installation below.

Note: The crio_grpc_client package is used exclusively on the Data Recording Server (Linux Server 3) and is not copied to the cRIO.

Create Directory Structure on cRIO

SSH into the cRIO and create the required directories:

ssh admin@<ip address of crio>
mkdir crio_python
mkdir crio_python/installers
exit

Fix Locale Settings

Incorrect locale settings can cause DAQmx errors. Fix this as follows.

Optionally install nano on the cRIO:

opkg update
opkg install nano

Edit the bashrc file:

nano ~/.bashrc

Add the following two lines at the bottom:

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Save with Ctrl+S, exit with Ctrl+X, then restart the shell or reboot the cRIO.

Note: VS Code can be used to connect via SSH for file editing and copying. However, VS Code versions above 1.98.2 may have issues with SSH connections to the cRIO. See the Remote Development FAQ for details.

Install cRIO Python Software

Two installation methods are available: automated script (recommended) or manual.

Method A: Automated Deployment Script (Recommended)

Open the deployment script on the Server 3:

support_lti_6g_sw/power_monitoring/crio/python/deploy_crio_server.sh

Edit the configuration section at the top of the script to match your setup:

# Configuration
CRIO_HOST="192.168.120.2"   # Update with your cRIO's IP address or hostname
CRIO_USER="admin"
CRIO_INSTALL_DIR="/home/admin/crio_python/installers"
CRIO_VENV="/home/admin/crio_python/.venv"

# Directories
BASE_DIR="/home/user/workarea/oai/lti-6g-sw_oai-5g-ran/support_lti_6g_sw/power_monitoring/crio/python"
SHARED_DIR="${BASE_DIR}/crio_grpc_shared"
SERVER_DIR="${BASE_DIR}/crio_grpc_server"

Run the script:

./deploy_crio_server.sh

The script will automatically:

• Build the Python packages
• Connect to the cRIO via SSH
• Install all required packages into the virtual environment

deploy_crio_server.sh — Script Configuration Variables (CRIO_HOST, CRIO_USER, CRIO_INSTALL_DIR, CRIO_VENV, BASE_DIR, SHARED_DIR, SERVER_DIR)

Method B: Manual Installation

Step 1: Copy the Python wheel files from the server 3 to the cRIO via SCP:

scp -r <path>\crio_grpc_shared-1.0.0-py3-none-any.whl admin@<IP-address>:~/crio_python/installers
scp -r <path>\crio_grpc_server-1.0.0-py3-none-any.whl admin@<IP-address>:~/crio_python/installers

Step 2: SSH into the cRIO:

ssh admin@<ip address of crio>

Step 3: Install dependencies and Python packages:

opkg install python3-pip
python3 -m venv ~/crio_python/.venv
cd crio_python/
source .venv/bin/activate
python3 -m pip install installers/crio_grpc_shared-1.0.0-py3-none-any.whl
python3 -m pip install installers/crio_grpc_server-1.0.0-py3-none-any.whl

Run the gRPC Server on the cRIO

Two options are available to start the gRPC server on the cRIO.

Option 1: Run Manually from Virtual Environment

ssh admin@<ip address of crio>
cd /home/admin/crio_python
source .venv/bin/activate
python3 .venv/lib/python3.12/site-packages/crio_grpc_server/energy_efficiency_grpc_server.py --device_type CRIO --log_level INFO

Option 2: Startup Script

The startup script is located in the repository on the Data Recording Server (Linux Server 3) at:

/home/user/workarea/oai/<repository-name>/support_lti_6g_sw/power_monitoring/crio/python/startup_crio.sh

Copy the startup script from the repository on Linux Server 3 to the cRIO:

scp /home/user/workarea/oai/<repository-name>/support_lti_6g_sw/power_monitoring/crio/python/startup_crio.sh \
    [email protected]:~/

scp -r <path>\startup_crio.sh admin@<IP-address>:~/

The startup script content is as follows:

#!/bin/bash
cd /home/admin/crio_python
source .venv/bin/activate
exec python3 .venv/lib/python3.12/site-packages/crio_grpc_server/energy_efficiency_grpc_server.py --device_type CRIO --log_level INFO

Run the startup script:

cd /home/admin/
./startup_crio.sh

A successful startup will show the following log output:

INFO - Initializing CRIO gRPC server...
INFO - Establishing connection to CRIO device...
INFO - Initializing CRIO gRPC server...
INFO - Configuring...
INFO - Finished processing state IDLE exit callbacks.
INFO - Finished processing state IDLE enter callbacks.
INFO - Configuring...
INFO - Executed callback '__reset_and_configure_measurement__'
INFO - Server started, listening on 2032

Install gRPC Client on Server 3

The gRPC client runs on the Host PC (Server 3) and communicates with the cRIO gRPC server.

Prerequisites: Python 3.11 or later (verified with 3.12).

Step 1: Prepare the Python virtual environment on the Host PC:

python -m venv  <path>\crio\.venv
cd <path>\crio\.venv
.\.venv\Scripts\activate
python -m pip install .\crio_grpc_shared-0.1.1-py3-none-any.whl
python -m pip install .\crio_grpc_client-0.1.1-py3-none-any.whl

Step 2: Copy the installed example scripts to your project folder:

.venv\Lib\site-packages\crio_grpc_client\energy_efficiency_grpc_client_basicExample.py
.venv\Lib\site-packages\crio_grpc_client\energy_efficiency_grpc_client_basicVisualizationExample.ipynb

Step 3: Set the cRIO IP address in the example scripts:

grpc_target = "192.168.120.2:2032"

Verify: Run Example Measurement gRPC Client

With the gRPC server running on the cRIO, run the Jupyter notebook example on the Host PC:

energy_efficiency_grpc_client_basicVisualizationExample.ipynb

This can be opened using:

• Visual Studio Code with the Python virtual environment activated
• Jupyter web server

A successful run will produce a real-time power measurement plot showing:

Trace	Color	Measured Entity
rf_pa_power (mW)	Blue	Power Amplifier (PA)
server_power_total	Red	gNB Server
ru_power_total	Green	USRP (RU)

The plot displays power in Watts over time (seconds), with the PA showing TDD burst patterns and the server and USRP showing stable DC power consumption levels. ​

Data Recording Application — Installation and Bring-Up

The following steps describe how to install and bring up the Data Recording Application on Linux Server 3 from scratch. Follow all steps in order.

Step 1 — Navigate to the Application Directory

cd /home/user/workarea/oai/<repository-name>/support_lti_6g_sw/data_recording_app

Step 2 — Install Poetry (Python Dependency Manager)

The Data Recording Application uses Poetry for Python dependency management (Python 3.12). For full Poetry installation instructions, refer to the README included in the repository:

cat /home/user/workarea/oai/<repository-name>/support_lti_6g_sw/data_recording_app/README_INSTALL_Poetry.md

Step 3 — Generate the Combined Dependency File

The Data Recording Application merges dependencies from two sources:

• cRIO gRPC client: support_lti_6g_sw/power_monitoring/crio/python/crio_grpc_client/pyproject.toml
• Data Recording application: support_lti_6g_sw/data_recording_app/data_recording_pyproject.toml

Before installing dependencies, run the merge script to generate the combined pyproject.toml:

python3 support_lti_6g_sw/data_recording_app/create_common_toml_file_DR.py

Note: If the repository has been cloned to a non-default path, update the default_sources and default_output paths inside create_common_toml_file_DR.py before running the script:

default_sources = [
    "/home/user/workarea/oai/<repository-name>/support_lti_6g_sw/power_monitoring"
    "/crio/python/crio_grpc_client/pyproject.toml",
    "/home/user/workarea/oai/<repository-name>/support_lti_6g_sw"
    "/data_recording_app/data_recording_pyproject.toml",
]

default_output = (
    "/home/user/workarea/oai/<repository-name>/support_lti_6g_sw"
    "/data_recording_app/pyproject.toml"
)

Step 4 — Update the Poetry Lock File

After generating the combined pyproject.toml, update the Poetry lock file to resolve all dependencies:

cd support_lti_6g_sw/data_recording_app/
poetry lock

Step 5 — Install All Dependencies

poetry install

Note: Run poetry lock followed by poetry install again whenever a new package has been added to either the cRIO gRPC client or the Data Recording application. This ensures the combined environment stays consistent.

Step 6 — Verify the Installation

Confirm that all packages were installed correctly and the Poetry environment is active:

poetry env info
poetry show

The output should list all installed packages including the cRIO gRPC client dependencies and the Data Recording application dependencies without any errors.

Get the USRP Serial Connection ID

The data recording application reads power measurements from the USRP X410 embedded sensor via a USB serial connection. Follow the steps below to identify the correct serial connection ID.

Prerequisites:

• Ensure the base station USRP X410 and the Data Recording Server are both powered on.
• Ensure the USB-C to USB-A cable between the USRP X410 and Server 3 is connected

as described in the Network Connections section.

Step 1: Log in to the Data Recording Server and open a terminal.

Step 2: Run the following command to list USB serial devices:

ls /dev/serial/by-id

The output will look similar to this (exact names may differ by OS version):

usb-Digilent_Digilent_USB_Device_2516353B3AD9-ifO0-port0
usb-Digilent_Digilent_USB_Device_2516353B3AD9-ifO2-port0
usb-Digilent_Digilent_USB_Device_2516353B3AD9-ifO1-port0
usb-Digilent_Digilent_USB_Device_2516353B3AD9-ifO3-port0

Step 3: Identify the entry with postfix if03. The alphanumeric string before the postfix is the required serial connection ID.

In the example above, the serial connection ID is: 2516353B3AD9

Step 4: Copy this ID into the JSON data recording configuration file under power_measurement_service_addresses → usrp_sensors: The configuration file is located at:

data_recording_app/config/config_data_recording_local_mode_pow_meas.json

"power_measurement_service_addresses": {
    "base_station": {
        "server_internal_sensors": "192.168.100.2:2031",
        "crio_sensors": "192.168.120.2:2032",
        "usrp_sensors": "2516353B3AD9"
    }
}

Troubleshooting: USB Port Busy

If the USB port is busy and cannot be accessed by the data recording application, use one of the following methods to free it:

Option 1: Find and kill the process using the USB port:

lsof | grep /dev/ttyUSB

Kill the process:

fuser -k /dev/ttyUSB0

Replace ttyUSB0 with the actual device name shown in the output.

Option 2: Use lsusb to find the USB device UID:PID and reset it:

lsusb

Identify the USRP entry (e.g., 0403:6011 Future Technology Devices International), then run:

sudo usbreset 0403:6011

This resets the USB device without requiring a system reboot.

Synchronized Data Recording Configuration

The data recording application uses a JSON configuration file to control synchronized 5G NR data capture and power monitoring.

The config file is located at:

/home/user/workarea/oai/ni-internal-oai-5g-ran/support_lti_6g_sw/data_recording_app/config/config_data_recording_local_mode_5g_nr_and_pow_meas.json

Key Features of the Measurement Framework

As described earlier, the synchronized data recording framework can collect and align measurements from multiple sources, including:

• power measurements from the cRIO system,
• CPU and GPU power and utilization measurements from the base station server,
• measurements from internal USRP sensors, and
• 5G NR messages and data traced from the real-time OAI gNB and UE stacks.

The related configuration parameters are described below.

Configuration Parameters

Parameter	Description
enable_power_monitoring	Enable the power monitoring service
enable_nr_messages_power_meas_data_sync	Enable sync between 5G NR messages/traces and power measurements (based on slot and frame IDs). Requires at least one server internal sensor — CPU or GPU — to be enabled
enable_multi_sources_power_meas_data_sync	Enable sync between server internal power measurements and external cRIO power measurements based on timestamps. Note: USRP sensor measurements are not synchronized due to high latency (~160 ms per measurement request)
data	Path to directory for data storage
data_file_format	File format for saved data (Only SigMF supported)
enable_saving_tracer_messages_sigmf	Enable saving OAI trace messages (5G NR data + metadata) in SigMF format
enable_saving_power_meas_json	Enable saving power measurements in JSON file
num_records	Number of requested data records (slots)
power_supply_frequency	Power network frequency in Hz (50.0 or 60.0)
t_tracer_message_definition_file	Path to T-Tracer message definition file
parameter_map_file	Parameter mapping dictionary (OAI params → standardized SigMF metadata)
start_frame_number	Starting 5G NR frame number for recording (Note: It is not used in this Application Note)

Base Station Configuration

Parameter	Description
requested_tracer_messages	Requested base station PHY layer data traces logged via the OAI T-Tracer interface: GNB_PHY_UL_FD_PUSCH_IQ — Uplink PUSCH IQ samples (frequency domain) GNB_PHY_UL_FD_DMRS — Uplink DMRS IQ samples (frequency domain) GNB_PHY_UL_FD_CHAN_EST_DMRS_POS — Channel estimate at DMRS positions GNB_PHY_UL_PAYLOAD_RX_BITS — Received UL payload bits
server_internal_sensors	Base station server internal measurement sources. Note that cpu_usage and cpu_usage:nr-softmodem are compute utilization metrics, not power sensors: Power sensors: gpu_power — GPU power consumption (W), read from NVIDIA GPU internal sensor cpu_power — CPU power consumption (W), read from server internal CPU power sensor Compute utilization metrics: cpu_usage — Overall CPU utilization (%) across all cores cpu_usage:nr-softmodem — CPU utilization (%) of the nr-softmodem process specifically, enabling isolation of baseband processing load from total system CPU usage
crio_sensors	Power measurements acquired by the NI cRIO measurement system via external voltage and current sensors: rf_pa_power — DC power consumption of the external switchable PA (Skyworks SKY67154), derived from NI-9227 (current) and NI-9229 (voltage) server_power_total — Total AC input power of the base station server, derived from NI-9238 (current) and NI-9244 (voltage) ru_power_total — Total AC input power of the NI USRP X410 (RU), derived from NI-9238 (current) and NI-9244 (voltage)
usrp_sensors	Power measurement read from the NI USRP X410 embedded internal power sensor via USB serial connection: usrp_power_total — Total DC power consumption of the USRP X410, as reported by the onboard sensor Note: USRP sensor measurements are received approximately every 160 ms and are not slot-synchronized. They are provided as asynchronous auxiliary measurements only.
meta_data	Fixed base station parameters included as metadata in the SigMF output file. These values do not change during a recording session: num_tx_antennas — Number of transmit antennas tx_gain — Configured TX gain (dB) hw_type: "USRP X410" — Radio hardware type identifier seid — Session or entity identifier

User Equipment (UE) Configuration

Parameter	Description
requested_tracer_messages	Requested UE data traces: UE_PHY_UL_SCRAMBLED_TX_BITS, UE_PHY_UL_PAYLOAD_TX_BITS
server_internal_sensors	UE-side server internal sensors (empty by default) (Will be used in Updated Power Monitoring)
crio_sensors	UE-side cRIO sensors (empty by default) (Will be used in Updated Power Monitoring)
usrp_sensors	UE-side USRP sensors (empty by default) (Will be used in Updated Power Monitoring)
meta_data	Additional fixed UE parameters for SigMF metadata (e.g., num_rx_antennas, rx_gain, hw_type: "USRP X410", seid)

Common Metadata and Network Configuration

Parameter	Description
common_meta_data	Shared metadata: sample_rate: 61440000.0, bandwidth: 40000000.0, clock_reference: "external"
ricAddress	RIC address: 192.168.100.2:5000
tracer_service_baseStation_address	T-Tracer address for base station: 192.168.100.2:2031
tracer_service_userEquipment_address	T-Tracer address for UE: 192.168.110.2:2031
power_measurement_service_addresses → base_station → server_internal_sensors	192.168.100.2:2031
power_measurement_service_addresses → base_station → crio_sensors	192.168.120.2:2032
power_measurement_service_addresses → base_station → usrp_sensors	USRP serial connection ID (e.g., 2516353274B01) — see Section 3.4.5

Note: The mapping between power measurements and cRIO channels is currently hardcoded. Configurable channel selection will be added in a future release.

Sync Service: Configuration Explanation

The Data Recording application uses a Data Sync Service to align 5G NR trace messages with power measurements across multiple sources. The diagram below explains the two sync stages and how they are controlled by the config file parameters.

Sync Service: Config Explanation. ​

Sync Architecture Overview

The Data Sync Service has two independent sync stages, both feeding into a Final Sync Info that is used to read slot-synchronized data sets from buffers.

Sync Stage	Config Parameter	Description
Power Measurement Multi-Source Sync	enable_multi_sources_power_meas_data_sync	Synchronizes Server Power Reader and NI cRIO Power Reader based on system timestamps (with time offset compensation)
Sync 5G NR Messages (UE and gNB)	Always enabled	Synchronizes gNB T-Tracer and UE T-Tracer data streams based on common SFN (System Frame Number) and Slot IDs
Sync 5G NR MSGs with Power Measurements	enable_nr_messages_power_meas_data_sync	Aligns the synchronized 5G NR messages with server internal power measurements based on SFN and slot metadata

Note: The slot-based sync process is not applied to USRP power sensor measurements. USRP measurements are received via serial connection only approximately every 160 ms, which is not compatible with the 500 µs slot periodicity.

Sync Info Example 1: First Common SFN and Slot IDs (gNB and UE Traces)

The sync service identifies the first common SFN and slot ID across gNB and UE T-Tracer streams. Rows highlighted in yellow are discarded; the first matching row (green) becomes the sync point.

gNB Traces	UE Traces
SFN3, slot 3	SFN3, slot 6
SFN3, slot 2	SFN3, slot 5
SNF3, slot 1	SFN3, slot 4
SNF3, slot 0	SFN3, slot 3
SNF2, slot 19	SFN3, slot 2

Sync Info Example 2: First Common SFN and Slot IDs (gNB & UE Traces vs Internal Server POW MEAS)

After synchronizing gNB and UE traces, the result is further aligned with internal server power measurements based on SFN and slot metadata.

gNB & UE Traces	POW MEAS based on Internal Server Metadata
SFN3, slot 7	SFN3, slot 10
SFN3, slot 6	SFN3, slot 9
SFN3, slot 5	SFN3, slot 8
SFN3, slot 4	SFN3, slot 7
SFN3, slot 3	SFN3, slot 6

Sync Info Example 3: First Common Timestamp (Internal Server vs cRIO POW MEAS)

The multi-source power measurement sync aligns internal server measurements with NI cRIO measurements using system timestamps (with time offset compensation). Highlighted rows are discarded until the first common timestamp is found.

Internal Server POW MEAS	cRIO POW MEAS
SFN3, slot 7, t_INTR_xx+500us, data	t_cRIO_xx+2000us, data
SFN3, slot 6, t_INTR_xx, data	t_cRIO_xx+1500us, data
SNF3, slot 5, t_INTR_xx-500us, data	t_cRIO_xx+1000us, data
SNF3, slot 4, t_INTR_xx-1000us, data	t_cRIO_xx+500us, data
SNF2, slot 3, t_INTR_xx-1500us, data	t_cRIO_xx, data

Legend: Green = First common sync point (kept) Yellow = Discarded data subsets per Sync Info

Running the System Manually

This section describes the step-by-step procedure to bring up the complete testbed manually. All steps are executed from the Data Recording Server (Server 3) using SSH terminals to the remote machines.

Preparation

Turn on all machines and both USRP X410 units.

From the Data Recording Server, open the following SSH terminals:

Terminal	Target	IP Address	Purpose
gNB Terminal 1	Base Station Server	192.168.100.2	Run gNB (nr-softmodem)
gNB Terminal 2	Base Station Server	192.168.100.2	Run FlexRIC
gNB Terminal 3	Base Station Server	192.168.100.2	Run gRPC APP
gNB Terminal 4	Base Station Server	192.168.100.2	Run Power sub-service
UE Terminal 1	UE Server	192.168.110.2	Run OAI UE (nr-uesoftmodem)
cRIO Terminal	NI cRIO	192.168.120.2	Run cRIO gRPC server

Run Base Station (gNB)

On gNB Terminal 1, run the machine initialization script once after each system reboot:

cd workarea
sudo ./machine_init.sh
cd ..

Navigate to the OAI directory:

cd workarea/oai/ni-internal-oai-5g-ran/

Run the gNB:

sudo ./cmake_targets/ran_build/build/nr-softmodem \
  -O ./targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.band78.sa.fr1.106PRB.1x1.usrpx410_3300MHz.conf \
  --gNBs.[0].min_rxtxtime 6 \
  --usrp-tx-thread-config 1 \
  --parallel-config PARALLEL_SINGLE_THREAD \
  --phy-test -T 6 -d \
  --MACRLCs.[0].ul_harq_round_max 1 \
  --MACRLCs.[0].dl_harq_round_max 1 \
  --T_stdout 2 \
  --T_nowait \
  --T_port 2021

Run UE

IMPORTANT: For PHY test mode, all RRC configuration must be provided to the OAI Soft UE. Copy the two RRC files from the gNB Server to the UE Server via WinSCP or terminal commands:

File	Source (gNB Server)	Destination (UE Server)
reconfig.raw	.../workarea/oai/ni-internal-oai-5g-ran/	/home/user/workarea/rrc_files/
rbconfig.raw	.../workarea/oai/ni-internal-oai-5g-ran/	/home/user/workarea/rrc_files/

Note: If you use a different destination path, adjust the --reconfig-file and --rbconfig-file arguments in the UE command below accordingly.

On UE Terminal 1, run the machine initialization script once after each system reboot:

cd workarea
sudo ./machine_init.sh
cd ..

Navigate to the OAI UE directory:

cd workarea/oai/ni-internal-oai-5g-ran-UE/

Run the UE:

sudo ./cmake_targets/ran_build/build/nr-uesoftmodem \
  --usrp-args "type=x4xx,addr=192.168.10.2,second_addr=192.168.11.2,clock_source=external,time_source=external" \
  --phy-test \
  -O ./targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.conf \
  --reconfig-file /home/user/workarea/rrc_files/reconfig.raw \
  --rbconfig-file /home/user/workarea/rrc_files/rbconfig.raw \
  --ue-rxgain 20 \
  --ue-txgain 12 \
  --T_stdout 2 \
  --T_nowait \
  --T_port 2023

Run cRIO System

On the cRIO Terminal, start the cRIO gRPC server using either method:

Option A — Startup script:

./startup_crio.sh

Option B — Manual:

cd /home/admin/crio_python
source .venv/bin/activate
python3 .venv/lib/python3.12/site-packages/crio_grpc_server/energy_efficiency_grpc_server.py --device_type CRIO --log_level INFO

Run FlexRIC (gNB Server)

On gNB Terminal 2, run the FlexRIC nearRT-RIC (used to switch between traditional and neural Rx from GUI):

./workarea/oai/ni-internal-oai-5g-ran/openair2/E2AP/flexric/build/examples/ric/nearRT-RIC

Run gRPC APP (gNB Server)

On gNB Terminal 3, run the gRPC RIC server (used to switch between traditional and neural Rx from GUI):

./workarea/oai/ni-internal-oai-5g-ran/openair2/E2AP/flexric/xapp_grpc_api/cmake/build/grpc_ric_srv

Run Power Sub-Service (gNB Server)

On gNB Terminal 4, run the power monitoring sub-service:

cd workarea/oai/ni-internal-oai-5g-ran/support_lti_6g_sw/power_monitoring/
sudo python3 power_monitoring_sub_service.py

Run T-Tracer Data Collection (Data Recording Server)

Required only if capturing 5G NR messages.

Navigate to the T-Tracer directory:

cd workarea/oai/ni-internal-oai-5g-ran/common/utils/T/tracer

Run the gNB Data Collection service on one terminal:

./t_tracer_app_gnb -d ../T_messages.txt

Run the UE Data Collection service on a separate terminal:

./t_tracer_app_ue -d ../T_messages.txt

Start Data Recording App (Data Recording Server)

Navigate to the data recording application directory:

cd workarea/oai/ni-internal-oai-5g-ran/support_lti_6g_sw/data_recording_app/

Run the data recording application:

python3 data_recording_app_w_pow_monitoring.py

Start GUI and Open Browser (Data Recording Server)

Navigate to the GUI directory:

cd workarea/oai/ni-internal-oai-5g-ran/support_lti_6g_sw/power_monitoring/gui/src/pm_gui/

Run the GUI application:

python3 gui_app.py

Open the GUI in a web browser at:

http://127.0.0.1:5000/

Note: The URL is printed in the terminal after the command executes. You can click on it directly to open it in the browser.

Manual Startup Summary

Step	Machine	Terminal	Command / Action
1	All	—	Power on all machines and USRPs; open SSH terminals
2	gNB Server	Terminal 1	machine_init.sh then run nr-softmodem
3	UE Server	Terminal 1	Copy RRC files; machine_init.sh then run nr-uesoftmodem
4	NI cRIO	cRIO Terminal	Run startup_crio.sh or gRPC server manually
5	gNB Server	Terminal 2	Run nearRT-RIC (FlexRIC)
6	gNB Server	Terminal 3	Run grpc_ric_srv (gRPC APP)
7	gNB Server	Terminal 4	Run power_monitoring_sub_service.py
8	Data Recording Server	Terminal(s)	Run t_tracer_app_gnb and t_tracer_app_ue
9	Data Recording Server	Terminal	Run data_recording_app_w_pow_monitoring.py
10	Data Recording Server	Terminal	Run gui_app.py → open http://127.0.0.1:5000/

Power Monitoring GUI

Power Monitoring GUI — Demo Use Cases

The Power Monitoring GUI provides real-time visualization of power and energy consumption across all monitored hardware components of the testbed. The following subsections describe the expected GUI behaviour and power measurements for each of the two demonstration use cases. Both use cases operate using the customized OAI PHY Test MAC scheduler (gNB_scheduler_phytest.c), which alternates between two DL transmission configurations every 10 radio frames.

Use Case 1 — Energy Savings via Enhanced Cell Sleep Mechanisms

The first use case demonstrates the power savings achievable at the base station Power Amplifier by exploiting increased cell sleep opportunities — specifically by dynamically switching the PA off during slots where no DL transmission is required.

The PHY Test MAC scheduler alternates between the following two configurations every 10 radio frames:

Parameter	Baseline Config 1	Optimized Config 2
Scheduled DL PRBs	20 PRBs	80 PRBs
MCS	15	23
Active DL slots per radio frame	14 (7 per half-frame)	2 (1 per half-frame)
PA state during inactive slots	Off	Off
Slot bitmap	130175	2050

In the Power Monitoring GUI, the following behaviour is expected during this use case:

• The PA power trace (blue curve in the right plot) clearly shows two alternating patterns:
  • Config 1: PA switches on/off 14 times per radio frame (7 per half-frame)
  • Config 2: PA switches on/off only 2 times per radio frame (1 per half-frame)
• The average PA power per frame (red curve) drops by approximately 7× when switching from Config 1 to Config 2 — directly quantifying the energy saving achieved
• The Base Station Server and RU (USRP X410) power traces remain largely unchanged between the two configurations, confirming that the energy saving is localized to the PA

Figure: Power Monitoring GUI during Use Case 1 — Enhanced Cell Sleep Mechanisms. The blue curve shows instantaneous PA power per 500 µs slot. The red curve shows average PA power per 10 ms radio frame. The transition from Baseline Config 1 (14 active DL slots per frame) to Optimized Config 2 (2 active DL slots per frame) produces an approximately 7× reduction in average PA power consumption.

Use Case 2 — Energy Profiling of AI-Native vs. Traditional Receiver

The second use case measures and compares the compute processing energy required by the AI-native Neural Receiver running on the NVIDIA GPU against the traditional receiver running on the CPU. The PHY Test MAC scheduler remains active during this use case with fixed DL/UL parameters.

In the Power Monitoring GUI, the following behaviour is expected when toggling between the two receiver implementations at runtime:

Monitored Component	Neural RX Active (GPU)	Traditional RX Active (CPU only)
Total Server Input Power	~250 W	~200 W
GPU Power	~60 W	~10 W (idle baseline)
CPU Power	~130 W	~130 W (unchanged)
PA Power	Unchanged	Unchanged

• When the Neural Receiver is active, the GUI shows elevated GPU power (~60 W) reflected directly in the total server input power (~250 W)
• When switching to the traditional receiver, GPU power drops by ~50 W to its idle baseline (~10 W), and total server input power reduces by the same amount to ~200 W
• CPU power remains approximately constant across both configurations — consistent with the OAI stack not applying dynamic CPU power management
• PA and RU power traces are unaffected by the receiver switch, confirming that the power delta is attributable solely to GPU compute workload

Note: The Neural Receiver is enabled by default at system startup. In the demonstration, the system may automatically revert to the Neural Receiver to maintain the GPU in a warmed-up state. Switching to the traditional receiver at runtime can be performed using the demo control script described in the next section.

Base Station Server Panel

The Base Station Server panel displays five traces:

Trace	Color	Description	Observed Behavior
Mean Server Input Power (AC, cRIO)	Blue	Total AC input power to server measured by cRIO	Stable ~250–300 W with slight variation
CPU Power Usage	Orange	CPU power draw from server internal sensor	High variability ~100–250 W, spiky pattern due to active real-time baseband processing
GPU Power Usage	Green	GPU power draw (Neural Rx inference)	Stable low level ~50–60 W
GPU Usage	Purple	GPU utilization percentage (%)	Stable low percentage
CPU Usage: nr-softmodem	Light Orange	CPU utilization specifically from the nr-softmodem process	High and variable, reflecting real-time PHY processing load

Key observation: The CPU power and usage traces show high variability and sustained load across the full measurement window, reflecting continuous real-time 5G NR physical layer processing by the nr-softmodem process.

RU Front-End Panel

Trace	Color	Description	Observed Behavior
Mean USRP Input Power (AC, cRIO)	Blue	Total AC input power to USRP X410 measured by cRIO	90 W
Mean USRP Input Power (DC, internal)	Red	DC power measured internally by USRP	88 W

Key observation: The USRP X410 power consumption is constant and stable, independent of the MAC scheduling activity, as the radio hardware remains continuously powered during operation.

RF PA Panel

Trace	Color	Description	Observed Behavior
PA Input Power per Slot (DC, cRIO)	Blue	Per-slot power consumption of the Skyworks SKY67154 PA measured by cRIO	Dense high-frequency bursts up to ~0.38–0.40 W across nearly all DL slots
Average PA Input Power per Radio Frame	Red	Rolling average PA power per 10 ms radio frame	Sustained high average ~0.25–0.27 W with only brief dips

System Architecture Display

The GUI bottom panel shows the active signal chain and indicates which receiver implementation is currently running:

[ O-RAN DU / RU on COTS Server ]
  ├── GPU  →  Neural UL PHY Receiver
  └── CPU  →  Traditional UL PHY Receiver
        ⇄
  [ NI USRP (X410) ]
        ⇄
  [ External Switchable Power Amplifier ]
        ⇢ (switched on for actively used DL slots only)

Receiver Toggle Button — Neural RX / Traditional RX

The GUI provides a Receiver Toggle button to switch at runtime between the two receiver implementations used in Use Case 2 — AI-RAN Energy Profiling:

• Neural RX (GPU) — activates the AI-native Neural Receiver running on the NVIDIA GPU. When active, the GPU power trace in the GUI rises to approximately ~60 W and total server input power increases to approximately ~250 W.
• Traditional RX (CPU) — switches to the conventional receiver running on the multi-core CPU. When active, GPU power drops to its idle baseline of approximately ~10 W and total server input power reduces to approximately ~200 W.

Important — GUI Refresh Buttons: The Start and Stop buttons visible in the GUI control only the live graph refresh (driven by the 500 ms dcc.Interval timer). Pressing Start resumes periodic plot updates; pressing Stop pauses them. These buttons do not trigger data recording, connect to hardware, or launch any background process. They are effectively a play/pause control for the dashboard plots only.

GUI Observation: Power Monitoring with Averaged/Filtered Data

The figure below shows the Power Monitoring GUI, but with averaging/filtering applied to smooth the base station server power and utilization measurement curves.

Power Monitoring GUI — Same operation as a baseline but with filtering/averaging applied to smooth the power measurement traces

Base Station Server Panel

Trace	Color	Observed Behavior (After Filtering)
Mean Server Input Power (AC, cRIO)	Blue	Smooth stable line ~265–280 W — variability removed by averaging
CPU Power Usage	Orange/Red	Smoother trace ~100–150 W — peaks and spikes reduced compared to raw data
GPU Power Usage	Green	Stable flat line ~50 W — unchanged, already smooth in raw data
GPU Usage	Purple	Stable low percentage — unchanged
CPU Usage: nr-softmodem	Light Orange	Smoother and more readable compared to raw — underlying load pattern now clearly visible

Key observation: The filtering makes the underlying power consumption trends are clearly visible by removing high-frequency noise and short-duration spikes from the raw measurement data, while preserving the overall power level behavior.

Effect of Filtering — Summary

Panel	Raw Data (Section 6.5)	Filtered Data (This Section)
Base Station Server	High-frequency spiky CPU traces	Smooth trend lines — underlying power level clearly readable
RU Front-End	Already flat	No change
RF PA — per slot (blue)	Dense burst pattern	Unchanged — slot-level detail preserved
RF PA — per frame avg (red)	Noisy average line	Smooth stepped pattern clearly showing frame-level PA power envelope

Applying Moving Average Filter to Power Measurements

The data recording application supports an optional moving average filter for smoothing server internal power measurement traces. This is controlled in the following file:

support_lti_6g_sw/power_monitoring/power_monitoring_service.py

Filter Configuration Parameters

Locate the following configuration block at the top of the file:

# Apply moving average filter to server internal sensors
# Set to True to enable batch filtering that matches cRIO processing
# Each sensor has an independent filter window size
# To disable filtering for a specific sensor, set its window size to None
ENABLE_SERVER_INTERNAL_FILTERING = True
CPU_POWER_FILTER_WINDOW = None  # 40 samples @ 2kHz = 20ms window, group delay = 19 samples (9.5ms)
GPU_POWER_FILTER_WINDOW = None
GPU_USAGE_FILTER_WINDOW = None
CPU_USAGE_FILTER_WINDOW = None  # 40 samples @ 2kHz = 20ms window, group delay = 19 samples (9.5ms)

Parameter Description

Parameter	Type	Description
ENABLE_SERVER_INTERNAL_FILTERING	Boolean	Master switch to enable or disable batch filtering for all server internal sensors. Set to True to enable, False to disable.
CPU_POWER_FILTER_WINDOW	Integer or None	Moving average window size in samples for CPU power trace. Set to None to disable filtering for this sensor.
GPU_POWER_FILTER_WINDOW	Integer or None	Moving average window size in samples for GPU power trace. Set to None to disable filtering for this sensor.
GPU_USAGE_FILTER_WINDOW	Integer or None	Moving average window size in samples for GPU usage trace. Set to None to disable filtering for this sensor.
CPU_USAGE_FILTER_WINDOW	Integer or None	Moving average window size in samples for CPU usage trace. Set to None to disable filtering for this sensor.

Window Size Guidelines

Window Size	Sampling Rate	Time Window	Group Delay
40 samples	2 kHz	20 ms	19 samples (9.5 ms)
20 samples	2 kHz	10 ms	9.5 samples (4.75 ms)
None	—	Filtering disabled	No delay introduced

Note: A larger window size produces smoother curves but introduces a larger group delay. Set the window size according to the time resolution required for your measurement.

Example: Enable Filtering for CPU and GPU Power

To enable smoothing for CPU power and GPU power traces with a 20 ms window:

ENABLE_SERVER_INTERNAL_FILTERING = True
CPU_POWER_FILTER_WINDOW = 40   # 40 samples @ 2kHz = 20ms window
GPU_POWER_FILTER_WINDOW = 40   # 40 samples @ 2kHz = 20ms window
GPU_USAGE_FILTER_WINDOW = None # filtering disabled
CPU_USAGE_FILTER_WINDOW = 40   # 40 samples @ 2kHz = 20ms window

Example: Disable All Filtering

To run with raw unfiltered data for all sensors:

ENABLE_SERVER_INTERNAL_FILTERING = False
CPU_POWER_FILTER_WINDOW = None
GPU_POWER_FILTER_WINDOW = None
GPU_USAGE_FILTER_WINDOW = None
CPU_USAGE_FILTER_WINDOW = None

Note: The ENABLE_SERVER_INTERNAL_FILTERING flag must be set to True for any individual sensor filter window to take effect. Setting it to False disables all filtering regardless of the individual window size values.

Use Case: AI-Driven PA Energy Optimization (Yonsei University)

Overview

This section demonstrates the capabilities of the power measurement framework on an example AI RAN use case developed in collaboration with Yonsei University.

Yonsei University integrated an optimized Reinforcement Learning (RL)-based MAC scheduler into the base station stack. The scheduler optimizes resource allocation and with it usage and energy consumption of the base station power amplifier. The power measurement framework is used to measure and demonstrate the energy savings that can be obtained with this approach.

Use Case Description

Core Idea

The RL-based MAC scheduler addresses a fundamental energy efficiency challenge in base station operation: the RF Power Amplifier (PA) consumes significant power whenever it is active, regardless of how much data is actually being transmitted in a given slot.

The scheduler tackles this by optimizing MAC-layer DL resource allocation to minimize the number of actively used downlink (DL) slots for a given traffic profile. The PA is then:

• Switched ON exclusively for slots carrying active DL transmissions
• Switched OFF for all remaining slots — directly eliminating idle PA power consumption

Resource Allocation Strategy

Rather than transmitting packets immediately as they arrive — which activates the PA for every individual slot — the RL scheduler waits and accumulates packets before transmitting them together in a single DL slot.

This batching strategy reduces the total number of slots that require PA activation, concentrating transmissions into fewer, fuller slots and creating longer PA-off periods between them.

Trade-off: Latency vs. Energy

Batching transmissions inevitably introduces additional packet delay at the user side — packets must wait until enough data has accumulated before transmission begins. The RL approach is specifically designed to dynamically balance these two competing objectives based on the current traffic profile:

• Minimizing active DL slots → reduces PA on-time → lower energy consumption
• Minimizing packet delay → improves user experience → lower latency

Neither objective is fixed — the RL scheduler continuously adapts the transmission batching strategy in real time, trading off latency against energy savings according to the observed traffic load.

Observable Results

The effect of the RL-based MAC scheduler can be clearly observed in the Power Monitoring GUI (see Section 5) through three complementary plots. The GUI additionally allows the user to select different traffic profiles and, for each selected profile, to switch at runtime between the baseline MAC scheduler policy and the Reinforcement Learning MAC scheduling policy. By observing the PA power trend plot and the packet delay plot when toggling between the two scheduling policies, the respective PA energy savings and the associated packet delay differences can be directly derived and compared.

Power Monitoring GUI — AI-Driven PA Energy Optimization Use Case (Yonsei University / IEEE Globecom 2025). The GUI displays three plots: (1) PA power consumption per slot showing the switching pattern for the active scheduler policy and traffic profile, (2) PA power trend showing average PA energy consumption over longer time periods, and (3) packet delay distribution over time quantifying the latency trade-off. By switching between the baseline and RL MAC scheduling policies, PA energy savings and packet delay differences can be directly compared.

Plot	What It Shows	How to Use It
PA Power Consumption per Slot	Shows the instantaneous PA power per 500 µs slot over time. The burst pattern reveals how long and how often the PA is switched on for the selected traffic profile and scheduler policy. With the baseline scheduler, PA bursts are frequent and densely distributed. With the RL scheduler, bursts are fewer and shorter — reflecting the batching of transmissions into fewer, fuller slots.	Compare burst density and gap duration between the baseline and RL scheduler policies to visualize the reduction in PA active time.
PA Power Trend	Shows the average PA power consumption over longer time periods — smoothing out individual slot bursts to reveal the overall PA energy consumption across multiple radio frames. This plot makes the sustained energy saving effect of the RL scheduler directly readable as a reduction in the mean PA power level.	Switch between scheduler policies and observe the shift in the average PA power trend line — the magnitude of the drop quantifies the PA energy saving achieved by the RL scheduler for the selected traffic profile.
Packet Delay Distribution over Time	Shows the effective packet delay distribution as a function of time. Delay increases when the RL scheduler accumulates packets before transmitting them in batches. The plot quantifies the latency trade-off that is the direct counterpart of the PA energy saving.	Compare the packet delay profile between the baseline and RL scheduler policies — the difference in delay distributions quantifies the latency cost of the energy saving achieved by the RL scheduler.

By selecting a traffic profile in the GUI and toggling between the baseline MAC scheduler and the RL MAC scheduler, the user can directly read off from the PA power trend plot and the packet delay plot:

• The PA energy saving achieved by the RL scheduler for that traffic profile — visible as a reduction in average PA power
• The associated packet delay trade-off — visible as an increase in the packet delay distribution
• The dynamic balance between both objectives as the RL scheduler adapts to the observed traffic load in real time

Demo Video

The video was created by the team of Prof. Chae at Yonsei University and is available on their official YouTube demonstration channel. A recorded demonstration of the AI-driven PA energy optimization use case, presented at IEEE Globecom 2025 (Taipei), can be accessed at the following link:

▶ [[https://www.youtube.com/watch?v=jehh81Y4mPU IEEE Globecom 2025 — Energy-Efficient AI-RAN: Algorithms and Prototype Validation (NI and Yonsei University)]]

The video demonstrates the Power Monitoring GUI in live operation, showing real-time PA power consumption traces and packet delay measurements as the RL-based MAC scheduler dynamically adjusts DL slot usage to balance energy savings against packet latency.

Limitations and Remarks

Measurement Scope Limitations

• UE power monitoring not supported in this release. The current implementation supports power monitoring for the base station subsystem only (gNB server, NI USRP X410 RU, and external PA). UE-side server internal sensors, cRIO sensors, and USRP sensors are defined in the configuration file but are not supported in this version. Support is planned for a future release of the Power Monitoring framework.
• USRP power measurements are not slot-synchronized. USRP X410 embedded power sensor measurements are received via USB serial connection approximately every 160 ms, which is incompatible with the 500 µs 5G NR slot grid. As a result, USRP power measurements are not included in the slot-synchronized data recording pipeline and are provided as asynchronous auxiliary measurements only.
• cRIO and UE subsystem power connections are not measured. The NI cRIO 9047 chassis power supply (24V / 5A) and the UE subsystem (OAI UE server + UE USRP X410) are powered independently and are not monitored by the measurement framework in this configuration. Total system energy consumption figures therefore do not include these components.
• cRIO channel mapping is hardcoded. The mapping between power measurements and NI cRIO module channels is currently hardcoded in the software. Configurable channel selection will be added in a future release.
• Only SigMF file format is supported for saving 5G NR trace messages and power measurement data. Additional file format options are planned for future releases.
• start_frame_number parameter is not used. This configuration parameter is defined in the JSON configuration file but is not actively used in the current implementation.

Hardware and Platform Limitations

• Single UE only. The PHY test MAC scheduler (gNB_scheduler_phytest.c) supports one UE only. Multi-UE scenarios are not supported in PHY test mode.
• PA provides no gain control. The Skyworks SKY67154 fast-switching PA used in this demonstrator has no RF gain control. It is used exclusively to emulate RF switching on/off for cell sleep mechanism demonstration and is not representative of a production-grade base station PA with variable gain.
• Wired RF connection only. The testbed uses a wired back-to-back RF connection between the gNB and UE USRPs through fixed attenuators. Over-the-air propagation effects, interference from neighboring cells, and multi-UE scenarios are not modelled.
• VS Code SSH compatibility. VS Code versions above 1.98.2 may have issues with SSH connections to the NI cRIO. It is recommended to use VS Code ≤ 1.98.2 for remote development on the cRIO target.

Software and Configuration Limitations

• PHY test mode only. The DL and UL scheduling parameters demonstrated in this AppNote are hardcoded in the OAI PHY test MAC scheduler (gNB_scheduler_phytest.c) and are not configurable via the standard OAI configuration file at runtime. Modifying these parameters requires editing and recompiling the source code.
• OAI compute power management disabled by default. The OAI stack does not apply dynamic CPU power management schemes and actively recommends disabling them for real-time stability. As a result, CPU power consumption remains approximately constant regardless of baseband processing load — this is expected behaviour and not a measurement artefact.
• cRIO is not used for system timing synchronization. The NI cRIO 9047 does not provide timing synchronization for the 5G NR air interface. Its role is limited to power measurement acquisition and multi-source measurement alignment via timestamps. The 5G NR timing reference is provided by the OctoClock-G CDA-2990 external clock.
• Moving average filter applies to server internal sensors only. The configurable moving average filter in power_monitoring_service.py applies exclusively to server internal sensor measurements (CPU power, GPU power, CPU/GPU usage). It does not apply to cRIO or USRP measurements directly. Required filtering for alignment between cRIO and internal sensors is handled separately by the synchronization pipeline.
• Synchronization jitter between cRIO power measurements and gNB server internal power measurements. Due to the use of a manual synchronization procedure between different servers and the inherent jitter in OAI slot processing — which can vary from approximately 80 µs to 800 µs — the cRIO power measurements and the gNB server internal power measurements may not always be perfectly aligned in time. This can result in occasional misalignment between externally measured cRIO power traces and internally measured server power traces at the slot level. Synchronization between different servers is planned to be significantly improved in the next Power Monitoring release via Linux PTP (Precision Time Protocol) support, which will provide hardware-level time synchronization across all measurement nodes.

General Remarks

• This AppNote describes a technology demonstrator and research testbed. The power measurement framework and associated software are not intended for deployment in production networks without further validation and hardening.
• The NI CompactRIO measurement system is not limited to testbed use. The cRIO-based power monitoring approach described here can in principle be applied to commercial network deployments where component-level power observability is required.
• The two demonstration use cases (3GPP-aligned cell sleep and AI-RAN energy profiling) represent a subset of possible energy efficiency studies. The framework is designed to be extensible to a broad range of additional use cases including MIMO energy profiling, beamforming energy analysis, and RL/AI-driven scheduler optimization.
• For collaboration inquiries, additional use cases, or extensions to this framework, contact the authors via the Application Note feedback channel.