Results and Discussions

Our system was tested on the infrastructure of one of the largest telecommunications service providers. As a result, we collected data from the providers' 5G network intrusion detection process in real time. The reviewed dataset has thirty-two network connections that were checked. Every connection object consists of thirty-nine functions, divided into three categories. Therefore, the system takes into account network connectivity-based features, data traffic-based functions, and content-based features. In addition, each unit of data transfer is flagged as a unit of suspicious or normal traffic. Suspicious traffic is collected into four groups: remote to local, test, denial of service, and user-root. The following metrics are considered when evaluating performance: accuracy (A), tradeoff (Tr), reliability (Rb), precision (Pr), and false alarm rate (FR). Accuracy is calculated as the percentage of correct predictions of malicious data traffic according to the total number of predictions made by the IDS. Reliability is measured by the ratio of strong intrusion attempts to the total number of intrusions. The tradeoff is a hybrid of accuracy and reliability that provides greater accuracy in classifying data using the following equation:

Tr = 2/((1/Pr) + (1/Rb))

Accuracy is calculated by adding the number of correctly identified benign and malicious packages to the ratio of the sum of accurately detected legitimate and malicious packages and the number of incorrectly identified benign and malicious packages. The number of false positives can be calculated as the ratio of incorrectly classified legitimate packets to the total number of correctly classified benign packets and incorrectly classified benign traffic. Table 1 shows the performance score that defines the five columns of the table. In addition, performance metrics are calculated based on several parts of the input dataset, specified in the first column of the table. As we mentioned above, the dataset contains 32 000 000 network connections that were checked by the offered IDS. Furthermore, each connection object has thirty-nine functions, which are assessed by the intrusion detection system's machine learning core, which uses CNN.

The performance evaluation setup considers six fractions of the entire dataset, which were analyzed and are mentioned in the first column. Furthermore, the five considered metrics are evaluated through their defining percentages. The first four metrics indicate that the system can accurately detect malicious data traffic patterns that flow through the network operator's core. The values, which were computed relative to the false alarm rate (FR) metric, further justify the integrated system's capability to accurately process the data traffic patterns. Additionally, the consistent system's behavior in the case of all six fractions of the dataset demonstrates the scalability of the proposed solution. These features have also been fully demonstrated during the integrated system's deployment on the provider's infrastructure. In fact, the uniform behavior of the integrated system, which considers both its intrusion detection and intrusion prevention components, represents one of the key features. Thus, the system is simply deployed on the target infrastructure, and it is demonstrated to work reliably regardless of the particular configuration parameters, which pertain to the particular deployment infrastructure.

The performance appraisal scores confirm that the system is well-scalable relative to the size of the dataset being analyzed, and that the system can accurately detect malicious traffic patterns and minimize false positives. The behavior of the mentioned system in practice is principally important when using 5G data networks for commercial purposes that transfer and analyze a large number of data connections that need to be checked proactively. Moreover, it is also relevant to note that the dedicated 5G network cores, which process the related data traffic, pose unique challenges that are determined by several practical aspects. First, a sensibly larger number of concurrent data sessions should be processed, as compared to other types of mobile networks. Furthermore, this induces a greater variability in the logical structure of the respective data patterns, which should therefore be processed using efficient algorithmic detection cores. The results of the real-world performance assessment process demonstrate that the system is capable of satisfying all these essential requirements, which individualizes it in the context of similar intrusion detection systems that are deployed in 5G data networks cores (5GC). This also implies that the processing time, in the case of all assessed data samples, is in the millisecond range, which fully ensures the real-time nature of the system. Furthermore, although we did not have access to the experimental data concerning the execution times of other similar software platforms, to the best of our knowledge, this represents one of the very few approaches that determines real-time data processing in the range of milliseconds. This further constitutes proof of the system's real-world relevance.

We have also tested our system with Google Colab and have produced the following results, which are showed on Table 2.

Table 2. Experiment results.

Data Size Accuracy Average Detection Time
10% 94.14% 200 milliseconds
20% 94.10% 180 milliseconds
40% 94.05% 240 milliseconds
60% 93.80% 350 milliseconds
80% 93.40% 294 milliseconds
100% 92.90% 320 milliseconds

Comparing the system to the related approaches such as [48,49], the processing delay of ours is approximately four times decreased, the false alarm rate has only decreased a by a small amount, but it must be emphasized that the accuracy score has decreased, please see Table 3.

Table 3. Comparison.

Approaches Average Detection Time A FR
Our approach 200 milliseconds 94.14% 0.81%
Full set filter 2760 milliseconds 99.55% 1.02%
Info gain 840 milliseconds 99.64% 1.2%
Gain ratio 1310 milliseconds 99.64% 1.4%
Chi-squared 920 milliseconds 99.65% 1.6%
Relief 930 milliseconds 99% 0.98%


Callback before_footer in local_aigrade component should be migrated to new hook callback for core\hook\output\before_footer_html_generation
  • line 7225 of /lib/moodlelib.php: call to debugging()
  • line 7292 of /lib/moodlelib.php: call to {closure}()
  • line 71 of /lib/classes/hook/output/before_footer_html_generation.php: call to get_plugins_with_function()
  • line 987 of /lib/classes/output/core_renderer.php: call to core\hook\output\before_footer_html_generation->process_legacy_callbacks()
  • line 154 of /mod/book/view.php: call to core\output\core_renderer->footer()