Simulation on ns3 to exhaust FAP resources directly by consuming RAN

13 views
Skip to first unread message

Aman Pratap Singh

unread,
Oct 28, 2025, 2:43:02 AM (3 days ago) Oct 28
to ns-3-users

Hello everyone,

I’m designing a research experiment to study detection and mitigation of DDoS attacks targeting femto access points (FAPs) in 5G NR. The attack scenario I want to reproduce is this:

  • A legitimate UE is attached to a femto/gNodeB (FAP) and needs normal downlink throughput.

  • A group of attacker nodes (bot UEs or remote hosts) aim to exhaust the downlink RAN resources (RBs i.e. Resource Blocks /scheduler capacity) of that FAP by generating traffic destined to the legitimate UE, thereby denying service to the real user.

I plan to implement this in ns-3 (nr module / LENA / 5G stack)

My goals:

  1. Realistically model how RAN downlink Resource Block allocation gets saturated (i.e., RB utilization, RLC/PDCP buffer saturation, increased latency/loss).

  2. Measure and detect the attack with FlowMonitor

  3. I would like to know what could be the best approach in ns-3 to generate the attack traffic so it consumes downlink RBs of one FAP ? (Should attacker nodes be attached to the same FAP, or should the backend network in the core redirects the DownLink flows to the victim UE ?

What I’ve tried:

  • Basic approach: create many attacker UEs that continuously receive downlink traffic (packets addressed to the victim UE’s IP) to force the scheduler to allocate many RBs to the victim’s downlink — but I’m unsure how to do this correctly.

I am attaching and sharing two testbed codes that I’m using. One for direct attack on RAN and the second on some remotehost (This setup has been implemented by one of my fellow teammate & now I want to test the attack scenario on RAN directly instead of towards remotehost).

Thanks in advance. Any example scripts, pointers to relevant modules, scheduler hooks, or notes on scaling/ns-3 performance would be much appreciated.

ddos_attack_on_ran.cc
ddos_attack_on_remotehost.cc
Reply all
Reply to author
Forward
0 new messages