# Machine Learning-based Early Attack Detection Using Open RAN Intelligent
Controller

Bruno Missi Xavier23, Merim Dzaferagic3, Diarmuid Collins3, Giovanni
Comarela2,
Magnos Martinello2 and Marco Ruffini3  2 Federal University of Espírito Santo,
Espírito Santo, Brazil  3 Trinity College Dublin, Ireland  Email:
<EMAIL_ADDRESS>
###### Abstract

We design and demonstrate a method for early detection of Denial-of-Service
attacks. The proposed approach takes advantage of the OpenRAN framework to
collect measurements from the air interface (for attack detection) and to
dynamically control the operation of the Radio Access Network (RAN). For that
purpose, we developed our near-Real Time (RT) RAN Intelligent Controller (RIC)
interface. We apply and analyze a wide range of Machine Learning algorithms to
data traffic analysis that satisfy the accuracy and latency requirements set
by the near-RT RIC. Our results show that the proposed framework is able to
correctly classify genuine vs. malicious traffic with high accuracy (i.e.,
$95\%$) in a realistic testbed environment, allowing us to detect attacks
already at the Distributed Unit (DU), before malicious traffic even enters the
Centralized Unit (CU).

###### Index Terms:

machine learning; mobile networks; 4G and 5G

##  I Introduction

The growing number of services that run on top of cellular networks pose new
challenges in ensuring service availability. The common approach to service
availability improvement involves network planning, resource allocation
optimization, and network densification. However, the source of service
outages is often not related to the network configuration but originates from
different types of malicious service attacks [1, 2, 3, 4]. These security
threats affect user satisfaction and result in financial losses.

As highlighted by the authors of [5], security and privacy in cellular
networks can be achieved at the air interface, the operator’s internal
network, and the inter-operator links. Depending on the type of attack (e.g.,
passive in which the attacker only listens to the traffic, active in which
traffic is being modified or injected into the communication), detecting the
threat can be a challenge. Passive attacks often result in privacy breaches
[6], while active attacks result in service disruptions [7]. The focus of our
work is on the early detection of active attacks in cellular networks.

Recent publications have taken advantage of the processing power and
programmability available in the new generation of switches to introduce new
Intrusion Detection System (IDS) and Deep Packet Inspection (DPI) paradigms.
Both approaches heavily rely on the use of Machine Learning (ML) techniques to
allow the identification of the traffic [8, 9, 10, 11], to detect and to
mitigate the volumetric Distributed Denial-of-Service (DDoS) attacks [12, 13,
14] inside communication networks. In cellular networks, it is very important
to identify the malicious flow as early as possible to prevent it from
reaching the Software-Defined Networking (SDN) architecture [15] or
interrupting services on the edge of the network (e.g., mobile base station).

As highlighted by the authors of [16], the volumetric DDoS attacks cannot be
handled by the victim alone, and require help from the network. In terms of
cellular networks, the traditional approach relies on the core network to deal
with the malicious flows [17]. However, the fifth (5G) and sixth (6G)
generations of cellular networks will move from inflexible and monolithic
networks to agile and disaggregated architectures based on softwarization
[18]. These changes provide a range of new and efficient methods for early
detection and localization of the source of an attack, allowing the operator
to cut off the malicious flow before it spreads through the network.

Besides the softwarization and disaggregation, the OpenRAN Alliance [18]
introduces openness and, more importantly, intelligence that reaches the edge
of the network. The research in this area mainly focuses on optimizing radio
resources and the dynamic reconfiguration of network entities to match the
communication requirements [18, 19]. However, security implications will play
a major role in making the architecture a future-proof alternative to
traditional Radio Access Network (RAN) deployments [19].

Instead of the common approach of using the core network for DPI, we are
carrying out early active attack detection in the RAN. For that purpose, we
leverage the new OpenRAN architecture to collect air interface measurements
and ML to perform traffic classification (i.e., attack detection). This allows
us to detect the attack early on and stop it before it progresses through the
network. Our main contributions include:

  * •

We developed a near- Real Time (RT) RAN Intelligent Controller (RIC) that
allows us to collect measurements from open-source base stations (i.e.,
_srsRAN_) and dynamically adjust their configuration;

  * •

We identify the most important features on the physical and Medium Access
Control (MAC) layer for detecting different types of Denial-of-Service (DoS)
attacks;

  * •

We designed a ML model that allows us to classify different types of DoS
attacks with high accuracy based on the air interface measurements collected
by the near-RT RIC (i.e., physical and MAC layer measurements).

##  II Architecture / Framework

Figure 1: Data collection and ML model training and inference framework. TABLE I: Physical and MAC layer features used in our experiments. Layer |  | Down
---
link
| Up
---
link
Feature | Short Description
PHY | ✓ |  | cqi | Channel Quality Indicator
✓ | ✓ | mcs |  | Modulation and Coding
---
Scheme
| ✓ |  | pusch
---
sinr
| Noise ration interference
---
in the Physical Uplink
Shared Channel
| ✓ |  | pucch
---
sinr
| Noise ration interference
---
in the Physical Uplink
Control Channel
MAC | ✓ | ✓ | brate | Bitrate (bits/unit measure)
✓ | ✓ | pkt ok |  | Number of packets
---
successfully sent
✓ | ✓ | pkt nok | Number of packets dropped

Our traffic classification framework was built around two main constraints:
(1) latency requirement imposed by the near-RT RIC; and (2) low resolution of
the features from the physical and MAC layers needed to describe the network
traffic. Both constraints limit the choice of the ML classifiers, i.e., the
goal is to train a model that can accurately classify the traffic within the
defined latency requirements based on a limited set of features available in
the physical and MAC layers. We have developed our own control plane (i.e.,
near-RT RIC) that allows us to collect measurements and to control the
_srsRAN_ virtual Base Station (BS). The framework is implemented as an xApp
running on the near-RT RIC. Fig. 1 shows the required steps to deploy an
online ML classifier within the proposed architecture.

The first step in the process is to identify the frequency of the measurement
collection and the type of measurements needed to perform the traffic
classification. These steps are implemented in the _Learning Plane_.
Additionally, the _Learning Plane_ is responsible for storing the data from
the _Operational Plane_. The training of the initial ML model is done offline
once enough data is collected from the _Operational Plane_. The first step in
the training process is feature extraction. The _Feature Extractor_ component
identifies the useful measurements and performs the data pre-processing before
the training starts. Then, the _ML Model Training_ component trains the new
model on the same time scale that was chosen for the measurement collection.
The _ML Model Training_ component also ensures that the new model conforms to
the processing requirements set by the near-RT RIC. Once the model is trained,
and the target accuracy is achieved, the model can be deployed on the
_Prediction Plane_.

The _Prediction Plane_ performs multiple tasks: (i) pulls measurements from
the _Operational Plane_ ; (ii) shares the collected measurements with the
_Learning Plane_ for further model refinement; (iii) feeds data to the _Online
ML Classifier_ for traffic classification; and (iv) depending on the traffic
class sends commands to the BS in order to continue or terminate the service.
The communication between the various components in our architecture is done
through the _Databus_ of our control plane. The _Databus_ is implemented as a
_ZMQ_ broker111https://zeromq.org.

The _Operational Plane_ consists of the _srsRAN_ BS, the core network and our
custom built RIC agent. The RIC agent allows us to share data and read
commands with/from the _Databus_ of the near-RT RIC. Once the User Equipment
(UE) connects to the BS, the RIC agent starts collecting measurements and
sending them as asynchronous messages via the _Databus_ to the _Prediction
Plane_. The _Prediction Plane_ performs the traffic classification and, if
needed, sends control messages to the RIC agent. The RIC agent interprets
these control messages and controls the operation of the BS accordingly (e.g.,
forward, prioritize, or drop packets from the UE).

As highlighted earlier, only the initial model is trained offline. The
_Learning Plane_ continuously collects data during the prediction phase and
refines the initial model. In terms of ML, attacks are rare events, and as
such they are hard to predict. Therefore, as we will present in Section IV,
besides inference time, we mainly rely on the $F1$-Score to express the model
performance. As a reminder the $F1$-Score is computed as:

$\displaystyle F1=\frac{2RP}{R+P}$ (1)

where $R$ represents recall and $P$ represents precision. This allows us to
ensure that the model is penalised equally for being biased towards positive
predictions as well as missing predictions. Once the $F1$-Score improves
significantly, the new model gets deployed to the _Prediction Plane_.

###  II-A Feature Extraction

The traditional approach to identify malicious data flows is to extract
features from packet headers. In cellular networks, this is usually performed
in the core network. However, our goal is to identify and stop these data
flows at the source, i.e., the edge of the network. This introduces additional
challenges related to the features being less expressive (i.e., measurements
collected from the physical and MAC layers don’t contain packet headers).
During the initial ML model training phase, the data collected from the BS
gets labeled, and the feature extraction process starts. Table I describes the
features used in the classification process. All presented features are used
to describe the quality of the signal and the traffic volume.

The channel quality is measured by the UE and reported back to the BS as the
Channel Quality Indicator (CQI). The CQI index is a scalar value from $0$ to
$15$ measured on the physical layer. The Modulation and Coding Scheme (MCS) is
also a scalar that is determined based on the reported CQI. However, the
mapping also depends on the amount of information that is being sent between
the UE and BS. The range of values for the _MCS_ is between $0$ and $28$,
meaning that there is no direct mapping between the _CQI_ and _MCS_. The
Physical Uplink Shared Channel (PUSCH) Signal-to-Interference-plus-Noise Ratio
(SINR) and Physical Uplink Control Channel (PUCCH) SINR metrics indicate how
much the desired signal is stronger compared to the noise and interference in
the two channels, i.e., PUSCH and PUCCH. These metrics provide information
about the relationship between the channel conditions and the achieved
throughput.

Unlike the physical layer measurements mentioned above, the MAC layer
statistics contain the amount of data and packets exchanged between the UE and
BS, providing information about the traffic patterns of the services
exchanging information through the network. These measurements include data
rate (_brate_), the number of delivered packets (_pkts ok_) and the number of
dropped packets (_pkts nok_).

###  II-B ML Model Training

Once a large enough dataset is collected and the features extracted, we start
the ML model training phase. Unlike the work presented in [8, 11, 10], in
which the authors focus on traffic classification with limited computational
resources, we do not struggle with those limitations. However, unlike the
models presented in those papers, our model does not have access to the
intrinsic (i.e., packet headers) and extrinsic features (i.e., inter-packet
arrival time). It restricts us to works under the limitations highlighted in
Section II (i.e., low latency and low resolution of the available features).

The near-RT RIC imposes a $1s$ latency threshold. In other words, the overall
latency, including measurement collection, network delay between the BS and
the controller, and the processing delay on the _databus_ and the _xApp_ has
to be lower than $1s$. Please notice that the latency requirement is for the
whole control loop, i.e., both ways: measurements traveling from the BS to the
RIC and control messages traveling in the other direction. Even though the
scope of the paper does not include a detailed analysis of best traffic
classification models, in Section IV, we included an analysis of the accuracy
and performance of the most popular ML models that provide a suitable choice
for the online classification under the mentioned restrictions.

###  II-C Online ML Classifier

The traffic classification starts once the _ML Model Training_ Component
converges to a state which achieves the required accuracy within the defined
latency bounds. The _Online ML Classifier_ pulls measurements from the
_Databus_ and performs the traffic classification for each UE connected to the
BS. Once the traffic class is identified, a command is being sent to the BS
based on predefined policies (e.g., forward, prioritize, or drop packets from
the UE). Additionally, it shares the measurements with the _Learning Plane_
for further model refinement.

##  III Proposed Approach

This section describes the implementation decisions and the interaction
between the control components with the _srsRAN_ architecture (Section III-A).
Sections III-B and III-C provide details about the traffic categories and the
experimental setup.

Figure 2: Experimental setup architecture describing the interfaces and
communication between all components.

###  III-A Experimental Setup

As shown in Fig. 2, our experimental setup consists of three main components:
(1) RAN and core network; (2) near-RT RIC; and (3) non-RT RIC. The system is
implemented in the OpenIreland research testbed infrastructure [20].

####  III-A1 RAN and Core Network

For the purpose of our experiments we used Ettus Research Universal Software
Radio Peripherals and the _srsRAN_ open-source 4G and 5G software radio
library. The _srsRAN_ software was modified, and we developed our own library,
i.e., _RIC Agent_, that is compiled with the _srsRAN_ software allowing us to
share measurements with the _Databus_ in the control plane and read/execute
commands coming from the _xApps_.

Our experimental network consists of $3$ USRPs \- $2$ acting as UEs and $1$
acting as a BS. These USRPs are connected to Virtual Machines running on a
Dell PowerEdge R440 server. One additional VM acts as the core network.

####  III-A2 Near-RT RIC

We developed a near-RT RIC, that communicates with the RAN, allowing us to
read measurements from the BSs and send commands based on the algorithms
implemented in the _xApps_. The implementation consists of three main
components: (1) the previously mentioned _RIC Agent_ that is compiled with the
_srsRAN_ software; (2) a _Databus_ that is implemented as a _ZMQ_ broker,
allowing us to exchange measurements and commands between the _xApps_ and BSs;
and (3) the _xApps_ that allow us to implement control mechanisms that take
measurements as inputs and make decisions based on optimization algorithms, ML
models or predefined policies.

####  III-A3 Non-RT RIC

Unlike the near-RT RIC, we did not develop a non-RT RIC. For the purpose of
our experiments the non-RT aspects were performed through offline learning and
hyperparameter tuning. Once the accuracy and classification delay of the ML
model fell within the requirements set by the near-RT RIC, we deployed the
model as an _xApp_.

A closer look at Fig. 2 reveals that the total delay of the control loop
$T_{d}$ depends on the round trip transmission delay (i.e., network delay)
between all nodes hosting different parts of the architecture $t_{n}$, the
processing time at the _Databus_ $\delta_{d}$, and the inference time on the
near-RT RIC $\delta_{i}$. This can be expressed with Equation 2:

$\displaystyle T_{d}=t_{n}+2\delta_{d}+\delta_{i}$ (2)

The round trip network delay $t_{n}$ can be expressed as:

$\displaystyle t_{n}=2\delta_{bd}+2\delta_{dr}$ (3)

where $\delta_{bd}$ is the transmission delay between the BS and the _Databus_
, and $\delta_{dr}$ is the tranmsision delay between the _Databus_ and the
near-RT RIC.

To understand the control loop delay margins required to satisfy the near-RT
control requirements, we provide delays for all involved components. The delay
of the _Databus_ is $\delta_{d}=45\mu s$ and the round trip network delay of
our setup is $t_{n}=670\mu s$. This results in a total control loop delay
$T_{d}=760\mu s+\delta_{i}$. Please notice that our round trip network delay
is very low (i.e., $<1ms$) due to the setup being physically collocated. In
Section IV, we will further investigate the inference time $\delta_{i}$ to
compute the margin for the overall round trip network delay.

###  III-B Traffic Categories

In order to collect a realistic dataset, we used well known tools to generate
traffic in our network. We considered two traffic categories, i.e. _Benign_
and _Attack_. Each traffic category was represented by the following network
applications:

  * •

_Benign_ : _Web Browsing_ and _ Voice over IP (VoIP)_;

  * •

_Attack_ : _DDoS Ripper_, _DoS Hulk_ and _Slowloris_.

####  III-B1 Web Browsing

Web Browsing is characterized by the variable amount of data transmitted to
the web server and received by the client. Since the majority of internet
applications use Transmission Control Protocol (TCP), in order to generate
_Web Browsing_ traffic, we access the most visited websites
online222https://en.wikipedia.org/wiki/List_of_most_visited_websites, and
navigate through them randomly.

####  III-B2 VoIP

VoIP traffic has strict Quality of Service (QoS) requirements. It relies on
User Datagram Protocol (UDP) due to the lower tolerance to delays than packet
drops. A typical voice call requires between $20$ kbps and $170$ kbps
guaranteed priority bandwidth. To simulate the voice application, we rely on
_SIPp_ 333http://sipp.sourceforge.net/, which is an open-source traffic
generator widely used to test VoIP services in the real environment.

####  III-B3 DDoS Ripper

_DDoS Ripper_ explores the webserver vulnerability flooding it with requests
that result in cutting off targets or surrounding infrastructure. It opens as
many connections with the server as possible and keeps them alive, sending a
high volume of trash headers. This packet flooding causes an unexpected
traffic jam preventing legitimate traffic from reaching its destination. Our
code is based on the _PyPI DDoS Ripper_444https://pypi.org/project/ddos-
ripper/.

####  III-B4 DoS Hulk

This attack relies on obfuscating the traffic as a benign request. However, it
sends an unbearable load of TCP SYN messages and a flood of HTTP GET requests
through a multi-thread agent. Therefore, this attack requires a considerable
throughput. Our DoS Hulk script relies on _PyPI_
555https://pypi.org/project/hulk/.

####  III-B5 Slowloris

_Slowloris_ is a type of attack that opens multiple connections to the
webserver and keeps it open as long as possible. It requires a very low
bandwidth to periodically send subsequent HTTP headers for each opened
connection. This traffic pattern resembles benign communication by using the
legitimate packet headers to keep connections alive. We based our _Slowloris_
Python script on the _PySloloris_ 666https://pypi.org/project/pyslowloris/
development.

To ensure that the network traffic behaves according to real world patterns,
our approach is based on the techniques recommended by [21].

###  III-C Dataset Collection

In order to train and validate our traffic classification _xApp_ , we
collected two datasets. The first was collected by running the traffic
generator scripts on one UE, randomly switching between the different types of
traffic patterns. These experiments require only $2$ USRPs were used, i.e.,
one UE and one BS. The dataset was collected by the near-RT RIC.

The second dataset was collected by randomly switching between different types
of traffic on two different UEs. This setup involves $3$ USRPs, i.e., two UEs
and one BS. Again, the near-RT RIC was used to collect the measurements on the
BS. In this case, the dataset includes the BS measurements, the traffic label
and the label predicted by the _Online Classifier_.

Table II shows the number of samples collected for the abovementioned
scenarios. Section IV provides details about fitting and evaluating the ML
models in the training phase, and details about the performance of the _Online
ML Classifier_.

##  IV Experimental Results

In this section, we investigate the possibility to perform attack detection
based on the limited features available in the RAN. The performance of the
_xApps_ is evaluated based on the classification accuracy and the inference
delay for the most popular ML algorithms used for traffic classification.

TABLE II: Number of samples per traffic class for both datasets. Class | 1 UE | 2 UEs
---|---|---
Web Browsing | 32,135 | 300,798
VoIP | 69,802 | 121,975
DDoS Ripper | 33,083 | 86,246
DoS Hulk | 34,980 | 78,339
Slowloris | 26,078 | 492,145
Benign | 101,937 | 422,773
Atack | 94,141 | 656,730
TABLE III: Accuracy, Fitting and Inference time for all tested models. | Accuracy |  | Fitting
---
(sec)
| Inference
---
(ms)
SVM | 0.64 | 1,952.220 | 3.02
$k$-NN | 0.90 | 0.793 | 2.10
Decision Tree | 0.93 | 0.627 | 1.25
Random Forest | 0.95 | 0.783 | 2.86
AdaBoost | 0.87 | 19.615 | 3.05
MLP | 0.56 | 15.720 | 1.29

As previously highlighted, the _xApp_ has to identify the traffic class within
the acceptable delay constraints defined by the near-RT RIC, while still
maintaining a high level of accuracy. Our evaluation considers six different
ML classifiers, i.e., Support Vector Machine (SVM), k-Nearest Neighbors
(k-NN), Decision Tree, Random Forest, Adaptive Boosting (AdaBoost) and
Multilayer Perceptron (MLP). We use the dataset collected by connecting one UE
to the BS for training. Therefore, the first column of Table II shows the
number of samples used for the training of the classifiers for each traffic
class. We use the second dataset (i.e., second column in Table II) for
validation and testing purposes.

TABLE IV: Summary of the online classification results. Application | Precision | Recall | F1-score
---|---|---|---
Web Browsing | 0.93 | 0.96 | 0.94
VoIP | 0.97 | 0.95 | 0.96
DDoS Ripper | 0.94 | 0.87 | 0.90
DoS Hulk | 0.87 | 0.95 | 0.91
Slowloris | 0.97 | 0.95 | 0.96
Benign | 0.94 | 0.96 | 0.95
Attack | 0.98 | 0.96 | 0.97

Figure 3: Confusion matrices for the individual classes (left), and the binary
problem (right).

Due to the nature of real network traffic, different traffic classes can
exhibit similar properties during short periods of time. Our analysis showed
that in such scenarios, traffic classification models based on decision rules
have an advantage due to the higher tolerance to outliers. Additionally, they
have a lower inference delay - $\delta_{i}$ due to lower computational
requirements. Table III shows the classification accuracy achieved by
different ML algorithms. The Random Forest and Decision Tree algorithms
outperformed the others with an accuracy of $0.95$ and $0.93$, respectively.
As shown in Table III, the accuracy of the the other algorithms is
considerably lower with the minimum being $0.56$ for MLP.

A closer inspection of Table III reveals that the inference time -
$\delta_{i}$ of all tested classifiers falls within the acceptable bound set
by the near-RT RIC. It ranges from $1.25ms$ for the Decision Three to $3.05ms$
for the AdaBoost classifier. Due to the high accuracy discussed above and the
fact that the inference time of all tested classifiers is acceptable, the
Random Forest is the best choice for our use-case. We argue that the Decision
Tree classifier would be the second choice considering that its inference time
is much lower, with the accuracy being lower by $2\%$.

Considering the analysis presented above, we deployed the Random Forest
classifier as an _xApp_ to the near-RT RIC. The chosen model consists of $100$
decision trees with a maximum depth of $15$. The minimum number of samples
required to split an internal node is $5$, and the minimum number of samples
required to reach a leaf node is $1$. The experiments were executed in our
testbed with the setup described in Section III-A. Even though the real
testbed setup exhibits variations in the channel quality, and therefore
achievable throughput, the deployed classifier was able to achieve the same
classification accuracy that was achieved during the offline training and
testing phase, i.e., $0.95$.

Table IV provides details about the precision, recall and $F1$-Score for all
traffic classes used in our experiments. These metrics show that the proposed
model can predict different traffic classes based on measurements taken from
the physical and MAC layer. Fig. 3 provides further evidence of the network
traffic classification quality. For the individual traffic classes the model
achieves a $0.93$ $F1$-Score (Fig. 3, left).

So far, we focused on identifying the individual traffic classes. However, in
many applications, the goal is to distinguish between _Benign_ traffic and an
_Attack_. The right hand side of Fig. 3 shows the confusion matrix for these
two categories. It clearly shows that our classifier correctly identifies
$96\%$ of the _Attacks_ while achieving a very high $0.96$ $F1$-Score. Due to
the lack of comparable solutions in the RAN, we compare these results to IDS
solutions deployed in the core network. Even though IDS solutions have an
advantage due to the availability of packet headers, our Open-RAN approach
achieves results comparable to the work in [8] and [11] in which the authors
report 97% $F1$-Score and 93% accuracy, respectively. The authors of [8]
report that their IDS solution introduces additional $3.7\mu s$ of delay per
packet. In contrast, the near-RT RIC does not interfere with the traffic flow,
meaning that no additional delay is introduced to the network.

Fig. 4 shows that after $500ms$, more than $90\%$ of the service executions
will be classified correctly. This delay is due to the time needed for the
traffic to normalize its behavior, i.e., all analyzed traffic patterns exhibit
an initial transition phase in which they can’t be correctly classified.
Please note that in our experiments we collect measurements every $100ms$.
This means that after $5$ measurements and a negligible network - $t_{n}$ and
_Databus_ processing delay - $\delta_{d}$ (see Section III-A), we correctly
classify more than $90\%$ of the traffic executions.

As highlighted throughout the paper, real-time traffic classification is
important for on-demand resource allocation, dynamic network reconfiguration
and, in case of the detection of potential network attacks, it is useful for
IDSs. Motivated by the idea of real-time traffic classification, we measured
the time needed to correctly label each traffic type. Table III shows that the
inference time is $\delta_{i}=2.86ms$. Once this value is added to the
previously computed control loop delay, we get to a total of $T_{d}=760\mu
s+2.86ms=3.62ms$, meaning that there is a high margin for the network delay
(i.e., $996ms$) that still allows us to operate within the $1s$ control loop
delay as defined by the Open-RAN Alliance. In terms of detecting network
attacks it allows us to terminate the service for the malicious UE before any
damage is made. Based on the proposed architecture and the availability of
measurements, the detection of the attacks can be done at the Distributed Unit
(DU), while the attack could be stopped at the Centralized Unit (CU). The BS
can indicate the _ Radio Resource Control (RRC) Connection Release_ procedure
to the UE, which will effectively terminate the service for the malicious
user, by moving the UE from _RRC_Connected_ to _RRC_Idle_ state.

Figure 4: Cumulative Distribution Function showing that the network traffic is
in a transition state for the first 500ms, after which we can correctly
classify all analyzed traffic classes.

##  V Conclusions and Future Work

We developed a near-RT RIC and modified the open-source base station
implementation from _srsRAN_ to perform early DoS attack detection. This
framework allows us to collect measurements and control the RAN configuration
with delays between $10ms$ and $1s$. In order to comply with these delay
requirements, we developed a fast _Databus_ with a delay of $45\mu$s and
tested the inference delay of various ML algorithms.

In our experiments, we also extract the most important air interface
measurements/features required to correctly classify the analysed network
traffic. It is important to notice that these measurements don’t provide
details about the packet headers. For the purpose of testing the proposed
architecture, we collected a realistic dataset in our testbed. The real setup
allowed us to validate the performance of our ML model in an environment with
varying channel conditions. Our results show that the proposed model
generalizes well and it was able to correctly classify the traffic with high
accuracy.

The results indicate that early DoS attack detection is possible at the edge
of the network, allowing us to isolate the malicious users and stop the attack
before it does any damage to the rest of the network. Future work on this
topic would include the implementation of the Real Time RIC, which operates on
even lower delay requirements (i.e. up to $10ms$). This would also affect the
type of ML model that could perform the inference.

DDoS

    Distributed Denial-of-Service
SDN

    Software-Defined Networking
ML

    Machine Learning
MIMO

    Multiple-Input and Multiple-Output
RAN

    Radio Access Network
RT

    Real Time
RIC

    RAN Intelligent Controller
MAC

    Medium Access Control
BS

    Base Station
UE

    User Equipment
CQI

    Channel Quality Indicator
MCS

    Modulation and Coding Scheme
PUSCH

    Physical Uplink Shared Channel
PUCCH

    Physical Uplink Control Channel
SINR

    Signal-to-Interference-plus-Noise Ratio
USRP

    Universal Software Radio Peripheral
VM

    Virtual Machine
VoIP

    Voice over IP
DoS

    Denial-of-Service
TCP

    Transmission Control Protocol
QoS

    Quality of Service
UDP

    User Datagram Protocol
SVM

    Support Vector Machine
k-NN

    k-Nearest Neighbors
AdaBoost

    Adaptive Boosting
MLP

    Multilayer Perceptron
IDS

    Intrusion Detection System
DU

    Distributed Unit
CU

    Centralized Unit
RRC

    Radio Resource Control
DPI

    Deep Packet Inspection

## Acknowledgment

Financial support from Science Foundation Ireland 17/CDA/4760, 18/RI/5721 and
13/RC/2077_p2 is acknowledged. Financial support from Brazilian agencies:
CNPq, CAPES, FAPESP/MCTI/CGI.br (PORVIR-5G 20/05182-3, and SAWI 20/05174-0),
FAPES (94/2017, 281/2019, 515/2021, 284/2021, 1026/2022). CNPq fellows Dr.
Martinello 306225/2020-4.

## References

  * [1] L. F. Eliyan and R. Di Pietro, “DoS and DDoS attacks in software defined networks: A survey of existing solutions and research challenges,” _Future Generation Computer Systems_ , vol. 122, pp. 149–171, 2021.
  * [2] M. Zoure, T. Ahmed, and L. Réveillére, “Network services anomalies in nfv: Survey, taxonomy, and verification methods,” _IEEE Transactions on Network and Service Management_ , 2022.
  * [3] S. Wang, J. F. Balarezo, S. Kandeepan, A. Al-Hourani, K. G. Chavez, and B. Rubinstein, “Machine learning in network anomaly detection: A survey,” _IEEE Access_ , vol. 9, pp. 152 379–152 396, 2021.
  * [4] J. R. Rose _et al._ , “Intrusion detection using network traffic profiling and machine learning for IoT,” in _2021 IEEE 7th International Conference on Network Softwarization (NetSoft)_. IEEE, 2021, pp. 409–415.
  * [5] I. Bilogrevic, M. Jadliwala, and J.-P. Hubaux, “Security issues in next generation mobile networks: LTE and femtocells,” in _2nd international femtocell workshop_ , no. POST_TALK, 2010.
  * [6] M. Nasr, R. Shokri, and A. Houmansadr, “Comprehensive privacy analysis of deep learning: Passive and active white-box inference attacks against centralized and federated learning,” in _2019 IEEE symposium on security and privacy (SP)_. IEEE, 2019, pp. 739–753.
  * [7] J. A. Khan and M. M. Chowdhury, “Security analysis of 5G network,” in _2021 IEEE International Conference on Electro Information Technology (EIT)_. IEEE, 2021, pp. 001–006.
  * [8] B. M. Xavier, R. S. Guimarães, G. Comarela, and M. Martinello, “Map4: A pragmatic framework for in-network machine learning traffic classification,” _IEEE Transactions on Network and Service Management_ , pp. 1–1, 2022.
  * [9] F. Paolucci, L. Marinis, P. Castoldi, and F. Cugini, “Demonstration of p4 neural network switch,” in _2021 Optical Fiber Communications Conference and Exhibition (OFC)_. IEEE, 2021, pp. 1–3.
  * [10] J.-H. Lee _et al._ , “Switchtree: in-network computing and traffic analyses with random forests,” _Neural Computing and Applications_ , p. 1, 2020.
  * [11] D. Barradas, N. Santos, L. Rodrigues, S. Signorello, F. M. Ramos, and A. Madeira, “Flowlens: Enabling efficient flow classification for ml-based network security applications,” in _Proceedings of the Network and Distributed Systems Security (NDSS) Symposium_ , 2021.
  * [12] D. Ding, M. Savi, F. Pederzolli, M. Campanella, and D. Siracusa, “In-network volumetric DDoS victim identification using programmable commodity switches,” _IEEE Transactions on Network and Service Management_ , vol. 18, no. 2, pp. 1191–1202, 2021.
  * [13] M. Zhang, G. Li, S. Wang, C. Liu, A. Chen, H. Hu, G. Gu, Q. Li, M. Xu, and J. Wu, “Poseidon: Mitigating volumetric DDoS attacks with programmable switches,” in _Proceedings of NDSS_ , 2020.
  * [14] Z. Liu _et al._ , “Jaqen: A high-performance switch-native approach for detecting and mitigating volumetric DDoS attacks with programmable switches,” in _$\\{$ USENIX$\\}$ Security Symposium_, 2021.
  * [15] M. P. Novaes _et al._ , “Adversarial deep learning approach detection and defense against DDoS attacks in SDN environments,” _Future Generation Computer Systems_ , vol. 125, pp. 156–167, 2021.
  * [16] S. Ramanathan _et al._ , “SENSS against volumetric DDoS attacks,” in _Annual Computer Security Applications Conference_ , 2018, pp. 266–277.
  * [17] M. Iavich _et al._ , “The novel system of attacks detection in 5g,” in _International Conference on Advanced Information Networking and Applications_. Springer, 2021, pp. 580–591.
  * [18] L. Bonati, S. D’Oro, M. Polese, S. Basagni, and T. Melodia, “Intelligence and learning in O-RAN for data-driven nextg cellular networks,” _IEEE Communications Magazine_ , vol. 59, no. 10, pp. 21–27, 2021.
  * [19] M. Polese _et al._ , “Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges,” _arXiv:2202.01032_ , 2022\.
  * [20] OpenIreland testbed (CONNECT research centre), funded by Science Foundation Ireland, www.openireland.eu, accessed on 2022-10-17.
  * [21] I. Sharafaldin _et al._ , “Toward generating a new intrusion detection dataset and intrusion traffic characterization.” in _ICISSP_ , 2018, p. 108\.

  *[IDS]: Intrusion Detection System
  *[DPI]: Deep Packet Inspection
  *[ML]: Machine Learning
  *[DDoS]: Distributed Denial-of-Service
  *[SDN]: Software-Defined Networking
  *[RAN]: Radio Access Network
  *[RT]: Real Time
  *[RIC]: RAN Intelligent Controller
  *[MAC]: Medium Access Control
  *[DoS]: Denial-of-Service
  *[BS]: Base Station
  *[UE]: User Equipment
  *[CQI]: Channel Quality Indicator
  *[MCS]: Modulation and Coding Scheme
  *[PUSCH]: Physical Uplink Shared Channel
  *[SINR]: Signal-to-Interference-plus-Noise Ratio
  *[PUCCH]: Physical Uplink Control Channel
  *[ ML]: Machine Learning
  *[USRPs]: Universal Software Radio Peripheral
  *[UEs]: User Equipment
  *[VM]: Virtual Machine
  *[BSs]: Base Station
  *[VoIP]: Voice over IP
  *[TCP]: Transmission Control Protocol
  *[QoS]: Quality of Service
  *[UDP]: User Datagram Protocol
  *[ DDoS]: Distributed Denial-of-Service
  *[SVM]: Support Vector Machine
  *[k-NN]: k-Nearest Neighbors
  *[AdaBoost]: Adaptive Boosting
  *[MLP]: Multilayer Perceptron
  *[IDSs]: Intrusion Detection System
  *[DU]: Distributed Unit
  *[CU]: Centralized Unit
  *[RRC]: Radio Resource Control