5G Group Project · Internal Design Brief
v1 · 2026-07-13
For our 8-person team
Owner: Parham (Data Science)

What we're building

A modular AI that fixes the network one small tool at a time.

The system has two parts. First, a set of small tools, each trained to do one job in the network, like saving energy or raising throughput. Second, an AI on top, the orchestrator, that learns which tools to use and in what order, based on what the network needs at that moment.

01 · Background

We built this for photos first. Now we point it at networks.

One of us built a photo-restoration project last year. It used a set of small neural networks: one to remove noise, one to remove blur, one to sharpen. An AI decided the order to run them in, and that order changed depending on how the photo was damaged. This project takes the same setup and applies it to a 5G network.

Then Restoring a photo

A damaged photo, fixed by a sequence of small tools:

Damaged photo Denoise Deblur Sharpen Restored

Now Fixing a network

A congested or wasteful network, fixed the same way:

Wasteful / congested Steer Power Sleep Healthy
The pattern is the same in both cases: small tools, plus an AI that learns the order to use them in. The only difference is what the tools work on.

02 · The system

The whole thing is one loop.

The orchestrator looks at the current state of the network, picks one tool, applies it, and checks what happened. Then it repeats. That loop is the core of the design, and everything below sits inside it.

Operator goal “save energy, but never drop calls” what to optimize · A1-like THE ORCHESTRATOR reinforcement-learning agent + graph neural net reads the network → picks the next tool picks one tool FROZEN TOOLBOX · trained once, then reused Sleep cell Power ctrl Steer traffic Allocate RBs control action · E2-like THE NETWORK · cells & users measurements / KPIs · E2-like the control loop
The moving line is the network sending its measurements back to the orchestrator. That feedback is what “reactive” means here.

03 · The tools

The toolbox.

Each tool does one job and is trained on its own. We start with the first two, get the idea working, then add the others. Adding a tool does not mean retraining the ones already there, and showing that we can do this is one of the results we want.

Sleep / wake a cell

Turns a base station off when it isn't needed. Saves a lot of energy, but it can leave a coverage gap.

Action: on / off · energy · tool #1

Transmit-power control

Raises or lowers a cell's signal strength. More power means better coverage and throughput, and higher energy use.

Action: continuous · throughput · tool #2

Traffic steering

Moves users from one cell to a neighbour, either to balance load or to clear a cell before it sleeps.

Action: assignment · load balance · next up

Resource-block allocation

Assigns chunks of radio spectrum to users. This is the main control for throughput and fairness.

Action: allocation · throughput · later

No-op / hold

Do nothing this step. It matters more than it looks: letting the AI pick “wait” stops it from changing things constantly.

Action: none · stability · always on

The hard part

The tools work in different ways. One is a switch, one is a dial, one is an assignment. Getting a single AI to control all of them together is the part that existing work handles poorly.

04 · The orchestrator

How it decides, and why the decisions are readable.

The orchestrator is a reinforcement-learning agent. We give it the goal as a set of weights, say 70% energy and 30% throughput, and it learns which tool to use for a given network state. Since it works through named tools, each decision reads as a short sequence that an engineer can follow.

Example: a quiet cell at 2 a.m., goal set to save energy

Cell 3 lightly loaded Steer its users to Cell 2 Lower Cell 3 power Sleep Cell 3 18% less energy, calls kept

A single black-box model would just output something like “apply config #4471.” This tells you what it changed, and in what order.

The word frozen is doing a lot of work here. We train each tool once, then lock it. The orchestrator only learns how to combine the tools. That is what lets us reuse the same set for a new goal, or a new network layout, without retraining anything underneath.

05 · What we claim

Two claims, both measurable.

The claim is not about beating everyone on energy savings. Plenty of papers already do that. It is about two things that rarely show up together.

CLAIM 01

Reusability

Give the frozen tools a new goal, like prioritising throughput today, or a new network layout, like a denser set of cells, and the orchestrator adjusts without retraining any of the tools. We measure how much of the performance this keeps compared with rebuilding from scratch.

CLAIM 02

Readable decisions

Every action is a named tool in a sequence you can see. An operator can check it and debug it instead of trusting a black box. We will show this directly, for example a fault that the decision trace points straight to.

06 · For the telecom folks

Does this map to real 5G?

Yes. It lines up with O-RAN, the open 5G architecture operators are building now. Our tools are xApps. Our orchestrator sits in the coordination layer, and handling conflicts between xApps is a problem O-RAN itself lists as open. We build the simulator's interfaces to match the real ones, E2 and A1, so moving from the simulator to a real controller means replacing one adapter rather than rewriting the system.

Non-RT RIC / SMO · operator goalour goal weights live here
A1 · policy & intent
Near-RT RIC · the control layerour orchestrator + the tools (xApps) run here
E2 · measure & control
The RAN · cells & radiosour simulator today, a real network later
We copy the shape of E2 and A1, a light version rather than the full encoding. To check it holds up, the same orchestrator will run unchanged on ns-O-RAN, a standards-based simulator.

07 · What's new

Where this sits against existing work.

We read through the 2025 and 2026 papers carefully, partly because a close idea (co-trained hierarchies for O-RAN) came out in December 2025. Here is where our work differs from what already exists.

Already exists

  • One RL agent trained for a single goal, such as energy alone
  • Hierarchies trained end-to-end that can't be recombined
  • Conflict fixes that only work when tools are merged and look alike
  • Black-box policies that output an opaque config

What we add

  • A frozen toolbox you train once and recombine freely
  • Adapts to new goals and new layouts without retraining the tools
  • Controls tools that work differently, even from different vendors
  • Decisions come out as a sequence you can read

In one sentence: an orchestrator that handles conflicts between a fixed set of different tools, recombines them for new goals and network layouts without retraining, and explains what it did.

08 · Roadmap

The plan, ordered to lower the risk.

The scope is large, so the order matters. By M2 we already have a complete, publishable result. The harder parts, like the graph neural network for new layouts, come after that, once the safe result is done.

M0
Foundation
The simulator, the O-RAN-style interface, and the first 2 frozen tools (sleep and power).
M1
First orchestrator
Show the loop works end to end: combining 2 tools beats using either one alone.
M2
Adapts to new goals ✓ safe result by here
The orchestrator handles goal mixes it hasn't seen. This alone is a complete paper.
M3
Add tools 3 and 4
Steering and resource allocation. Plugging them in without retraining is the reusability result.
M4
Graph neural network ◆ the ambitious part
Adapt to network layouts it hasn't seen. This is the main new contribution.
M5
Test it and port it
Baselines, ablations, the readable-decision demo, and the same agent running on ns-O-RAN.

09 · The team (8 of us)

Where you fit.

Everyone owns one specific piece, so nothing falls through the cracks. Here is who does what.

Nour Al-BustaniTelecom

Owns the radio & KPI model

  • Path-loss, SINR, throughput, and the base-station energy model.
  • KPI names that match real 3GPP / O-RAN ones, so the sim reads like a real network.
Somayeh AshrafiTelecom

Owns the O-RAN mapping & traffic realism

  • The E2 / A1-style interface semantics, so each tool maps to a real xApp.
  • Real traffic traces mapped onto the cells, so demand rises and falls like a live network.
Francesco DonnarummaComputer Science

Owns the base orchestrator (RL agent)

  • The PPO agent, the reward shaping, and the training loop.
  • Gets the agent working end to end on a fixed setup (M1–M2).
Giulio ChiacchioComputer Eng

Owns the simulator core

  • The topology generator, the step loop, and the KPI pipeline.
  • Makes it fast enough to run thousands of training episodes.
Lorenzo NebbiosoComputer Eng

Owns the NetworkBackend seam & ns-O-RAN port

  • The clean interface (Gym env + E2 / A1-style messages) that separates the agent from the environment.
  • The ns-O-RAN version that proves sim→real is just an adapter swap.
Angelo CarrilloComputer Eng

Owns the tools

  • Builds, trains, and freezes each specialist: sleep and power first, then steering and RBs.
  • The shared tool contract, so the orchestrator treats every tool the same way.
Alessia AscoleseCyber Security

Owns robustness & security

  • Injects faulty or adversarial tools and checks the decision trace localises the fault.
  • Studies the backdoored-xApp threat model for third-party tools.
Parham (me)Data Science

Owns the graph neural network & the generalization study

  • Builds the GNN that lets one agent handle network layouts it has never seen (the M4 contribution).
  • Designs the preference-conditioning, so a single agent serves many goal mixes.
  • Codes the baselines and ablations and runs the experiments that prove reusability, our headline result.

10 · Risks

What could go wrong.

These are the things most likely to cause trouble, and how the plan handles them.

High
Noisy feedback. A network changes on its own as traffic rises and falls, unlike a photo. So it is hard to tell whether a tool helped or the load just dropped by itself. We handle this by comparing each step against a do-nothing baseline.
High
Modular does not automatically mean cheaper. Running several models has a cost. So the benefits we point to are reusability and readable decisions, not compute savings, which we can't promise.
High
Shared-network plumbing. Getting many tools to act on one shared network is the hardest engineering piece. That is why it is Milestone 0.
Med
Large scope for one term. The ordering handles it. M2 is a complete result, so if the graph network (M4) runs late, the project still stands.
Med
A simulator is not reality. We only claim results in simulation, not proven real-world performance. The ns-O-RAN version is how we make that gap smaller.