ORAN-Aegis — Operator Console

◎

Set the cell up, then run

The console runs the Stage 1 optimizer and the Stage 2 controller, then reports what happened to every user on both RATs.

New here? Open About & Guide above for a two-minute orientation.

The setting

One 4G cell and one 5G cell sit at the same site and share a single 20 MHz band. That band is modelled as 100 PRB-equivalent units. A split ratio decides how those units are divided between the two radio access technologies.

Under a PRB-exhaustion attack, compromised handsets request capacity using entirely standard 3GPP procedures. Nothing they send is invalid, so packet inspection and traffic classification cannot separate them from a genuine crowd. Legitimate users on the attacked RAT fall below the throughput their applications need, while the other RAT often still has capacity to spare.

What α means

the fraction of the shared band given to 5G. The remaining 1 − α goes to 4G.

α = 0.6060 PRB to 5G, 40 PRB to 4G

α = 0.7575 PRB to 5G, 25 PRB to 4G

α = 0.3030 PRB to 5G, 70 PRB to 4G

Raising α moves capacity to 5G and away from 4G. There is no free capacity in the system, so every change helps one RAT at the other's expense. That is exactly why the gate exists.

The two stages

Stage 1 · Non-RT RIC, offline

Initial Spectrum Optimization

Runs on normal-operation user counts, before any attack. It picks the split that gives both RATs equal per-user throughput while keeping each above the 2.6 Mbps service floor. With the paper's default cell (50 5G UEs, 20 4G UEs) this gives α₀ = 0.60.

This is the provisioned split, and it is the baseline every result is compared against.

Stage 2 · Near-RT RIC, runtime

Dynamic Spectrum Adjustment

Runs while the attack is under way. It proposes candidate splits in steps of 0.05, translates each one into per-user throughput using where the users actually are, then applies the gate and keeps the best split that passes.

If no candidate improves service, the provisioned split stays. The tool reports no improvement rather than a false one.

How to use it

Pick a scenario. Stadium, metro station, or urban outdoor. This decides where users stand relative to the base station, which decides how much throughput each one actually receives.

Set the cell up. Active UE counts per RAT and the spectral efficiency of each RAT. Defaults are the paper's values. The provisioned split α₀ updates automatically as you change them, because Stage 1 recomputes.

Choose the attack. Which RAT is targeted, and how many attacker UEs join the cell.

Set the policy. The satisfaction target is the throughput a user needs to count as served. The protection mode decides how strongly the RAT that is not attacked is defended.

Run. Everything below is recomputed.

How to read the results

Panel	What it tells you
Users served overall	Share of all UEs on both RATs receiving at least the satisfaction target, before and after. This is the headline number.
Spectrum split α	What the controller decided, and the PRB counts that follow from it. If it did not move, the gate found nothing better.
User map	Every UE in 3-D. Green is served, red is below target. Toggle between the provisioned split and the ORAN-Aegis split to see who changed state.
Users served, by RAT	The trade-off in plain terms. Watch the RAT that is not attacked: under the gate it should not fall.
Why this split was chosen	Service level across every candidate split. Shaded regions were rejected by the gate; the marker is the split that was applied.
Per-user throughput	The full distribution, not just the average. The vertical line is the satisfaction target.
Latency	The three stages a plan passes through, in order. First the controller computes the split, then the plan is distributed from the rApp to the xApp over A1, then the xApp enforces it at the O-DU over E2. Stage 1 is measured in this tool; the A1 and E2 figures are medians from the O-RAN testbed.

Panel

What it tells you

Users served overall

Share of all UEs on both RATs receiving at least the satisfaction target, before and after. This is the headline number.

Spectrum split α

What the controller decided, and the PRB counts that follow from it. If it did not move, the gate found nothing better.

User map

Every UE in 3-D. Green is served, red is below target. Toggle between the provisioned split and the ORAN-Aegis split to see who changed state.

Users served, by RAT

The trade-off in plain terms. Watch the RAT that is not attacked: under the gate it should not fall.

Why this split was chosen

Service level across every candidate split. Shaded regions were rejected by the gate; the marker is the split that was applied.

Per-user throughput

The full distribution, not just the average. The vertical line is the satisfaction target.

Latency

The three stages a plan passes through, in order. First the controller computes the split, then the plan is distributed from the rApp to the xApp over A1, then the xApp enforces it at the O-DU over E2. Stage 1 is measured in this tool; the A1 and E2 figures are medians from the O-RAN testbed.

Reading the outcome

Split adjusted

A candidate passed the gate and improved service. The split moved and more users are being served.

Split held

The gate found no candidate that improves service without harming the other RAT, so nothing changed. This is the intended behaviour, not a failure.

Action withheld

The cell cannot serve both RATs above the service floor at this load. Beyond this point, spectrum reallocation must be paired with admission control or load shedding.

What the numbers rest on

Throughput per user is the RAT's PRB share multiplied by the PRB bandwidth and the spectral efficiency, divided by the number of active UEs on that RAT, then scaled by a distance-based multiplier for each user's position. Service floor is 2.6 Mbps, the GSMA figure for sustained 720p video. Latency figures are medians measured on a Kubernetes O-RAN testbed running OpenAirInterface, the O-RAN-SC Non-RT RIC, and FlexRIC.