User Equipment Classification in the 5G Core

UNIVERSIDADE FEDERAL DE JUIZ DE FORA INSTITUTO DE CIÊNCIAS EXATAS PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO Leonardo Azalim de Oliveira User Equipment Traffic Classification in the 5G Core Juiz de Fora 2025 Leonardo Azalim de Oliveira User Equipment Traffic Classification in the 5G Core Dissertação apresentada ao Programa de PósGraduação em Ciência da Computação da Universidade Federal de Juiz de Fora como requisito parcial à obtenção do título de Mestre em Ciência da Computação. Área de concentração: Redes de Computadores. Orientador: Prof. Dr. Edelberto Franco Silva Coorientador: Prof. Dr. Luciano Jerez Chaves Juiz de Fora 2025 Ficha catalográfica elaborada através do Modelo Latex do CDC da UFJF com os dados fornecidos pelo(a) autor(a) Oliveira, Leonardo Azalim de. User Equipment Traffic Classification in the 5G Core / Leonardo Azalim de Oliveira. – 2025. 217 f. : il. Orientador: Edelberto Franco Silva Coorientador: Luciano Jerez Chaves Dissertação (Mestrado) – Universidade Federal de Juiz de Fora, Instituto de Ciências Exatas. Programa de Pós-Graduação em Ciência da Computação, 2025. 1. 5G. 2. Tráfego de rede. 3. Classificação. I. Silva, Edelberto Franco, orient. II. Chaves, Luciano Jerez, coorient. III. Título. Leonardo Azalim de Oliveira User Equipment Traffic Classifica�on in the 5G Core Dissertação apresentada ao Programa de Pósgraduação em Ciência da Computação da Universidade Federal de Juiz de Fora como requisito parcial à obtenção do �tulo de Mestre em Ciência da Computação. Área de concentração: Ciência da Computação. Aprovada em 11 de junho de 2025. BANCA EXAMINADORA Prof. Dr. Edelberto Franco Silva - Orientador Universidade Federal de Juiz de Fora Prof. Dr. Luciano Jerez Chaves - Coorientador Universidade Federal de Juiz de Fora Prof. Dr. Alex Borges Vieira Universidade Federal de Juiz de Fora Prof. Dr. Michele Nogueira Lima Universidade Federal de Minas Gerais Prof. Dr. Diogo Menezes Ferrazani Ma�os Universidade Federal Fluminense Juiz de Fora, 28/05/2025. Documento assinado eletronicamente por Alex Borges Vieira, Coordenador(a), em 24/07/2025, às 09:22, conforme horário oficial de Brasília, com fundamento no § 3º do art. 4º do Decreto nº 10.543, de 13 de novembro de 2020. Documento assinado eletronicamente por Edelberto Franco Silva, Professor(a), em 24/07/2025, às 09:23, conforme horário oficial de Brasília, com fundamento no § 3º do art. 4º do Decreto nº 10.543, de 13 de novembro de 2020. Documento assinado eletronicamente por Luciano Jerez Chaves, Professor(a), em 28/07/2025, às 13:18, conforme horário oficial de Brasília, com fundamento no § 3º do art. 4º do Decreto nº 10.543, de 13 de novembro de 2020. Documento assinado eletronicamente por Diogo Menezes Ferrazani Ma�os, Usuário Externo, em 29/07/2025, às 14:39, conforme horário oficial de Brasília, com fundamento no § 3º do art. 4º do Decreto nº 10.543, de 13 de novembro de 2020. Documento assinado eletronicamente por Michele Nogueira Lima, Usuário Externo, em 29/07/2025, às 15:04, conforme horário oficial de Brasília, com fundamento no § 3º do art. 4º do Decreto nº 10.543, de 13 de novembro de 2020. A auten�cidade deste documento pode ser conferida no Portal do SEI-U�f (www2.u�f.br/SEI) através do ícone Conferência de Documentos, informando o código verificador 2422797 e o código CRC 69C1E830. To Ana Luce, whose support has always been with me through the hardest moments of my life. ACKNOWLEDGMENT My work would have been impossible to accomplish without the help of countless individuals, as achieving great things is rarely done alone. During my Master’s course, my family provided unwavering encouragement, which was vital to my success. I would like to express my gratitude to my parents Ana Luce and José Geraldo for always supporting me in my endeavors; to my sister Cecília for being the greatest example of resilience I know and a source of inspiration; and to my aunt Anayse for always believing in me and my work. I also wish to thank my advisors, Professor Edelberto Franco Silva and Professor Luciano Jerez Chaves, for their invaluable guidance and partnership throughout my course. The time I spent at the university allowed me to cultivate many friendships. I extend my thanks to Frederico Sales and Rodrigo Silva for everything they shared with me; to Khalid Usman for the memorable moments we shared during the course; to Yago Pereira for his assistance in revising the mathematical definitions used in this work; and to Rômulo Mello and his laboratory colleagues for their friendliness during our time in PGCC. I am grateful to the professors of the Postgraduate program in Computer Science for their shared knowledge and expertise. I specially thank Professor Alex Borges Vieira for the invaluable lessons learned as a member of the Networks and Distributed Systems Laboratory (NetLab); Professor Mário Antônio Ribeiro Dantas for the enjoyable experience of working together while being his student; and Professor Marcelo Bernardes Vieira for the insights gained during his research methodology course. I also received support from various individuals and organizations that enabled my research. I acknowledge the the Núcleo de Recursos Computacionais (NRC), coordinated by Professor Eduardo Pagani Julio for the technical support and equipment utilized during my research; the Centro de Gestão do Conhecimento Organizacional (CGCO), coordinated by Mrs. Patrícia Curvelo Rodrigues Stroele for the connectivity support during my defense; and Coordenação de Aperfeiçoamento de Pessoal de Nível Superior ( CAPES ), Rede Nacional de Pesquisa (RNP), Fundação de Apoio e Desenvolvimento ao Ensino, Pesquisa e Extensão (Fadepe), and Fundação de Amparo à Pesquisa do Estado de Minas Gerais (FAPEMIG) for funding my research. I also thank the free5GC development team from National Yang Ming Chiao Tung University (NYCU) helpfulness during my collaboration on their project; and Mr Ali Güngör and all the contributors of the UERANSIM project for publicly releasing their state-of-the-art 5G UE simulator. Finally, I would like to acknowledge the anonymous reviewers who evaluated the papers I published during my course, as well as the members of my defense committee for their insightful comments. I also extend my gratitude to every scientist who came before me and, in some way, laid the foundations that enabled my work to reach its current state. “Science is an attempt, largely successful, to understand the world, to get a grip on things, to get hold of ourselves, to steer a safe course.” (Carl Sagan, 1997, p. 29) RESUMO A quinta geração de redes celulares ( 5G ), que é especificada pelo 3 rd Generation Partnership Program ( 3GPP ), se distingue das gerações anteriores de redes móveis principalmente pela adoção de uma arquitetura baseada em serviços (do inglês, Service Based Architecture ( SBA )). Ao aproveitar da flexibilidade desse novo paradigma arquitetural, este trabalho investiga a viabilidade da implementação de um mecanismo de Network Data Analytics Function ( NWDAF ) para a classificação de dispositivos 5G . Consoante com a normatização do 3GPP , o International Telecommunication Union ( ITU ) define três eixos de serviço 5G :Enhanced Mobile Broadband ( eMBB ), Ultra Reliable and Low Latency Communications ( URLLC ) e Massive Machine-Type Communications ( mMTC ). Esses eixos concentram principalmente aplicações que necessitam de altas taxas de vazão, baixa latência com alta disponibilidade e transmissões de baixo gasto energético com milhares de dispositivos de Internet of Things ( IoT ) conectados, respectivamente. Então, a classificação de diferentes tipos de dispositivos é crucial, uma vez que cada eixo do 5G está associado a restrições distintas, que influenciam a alocação de recursos no Núcleo 5G (do inglês, 5G Core ( 5GC )). Definido pelo 3GPP na Release 15 como responsável pela análise de dados em redes 5G , o NWDAF permanece subexplorado na literatura. Então, para explorar essa lacuna, este trabalho utiliza um ambiente 5G simulado que emprega Software Livre (SL). Este ambiente engloba o UERANSIM, que é um simulador de Radio Access Network ( RAN ) e User Equipment ( UE ); o free5GC, que é uma implementação de 5GC ; e um gerador de tráfego de rede customizável. Dois conjuntos de dados 5G reais, foram utilizados para treinar onze diferentes modelos de Machine Learning ( ML ) — Linear Regression ( LR ), Histogram-based Gradient Boosting ( HGB ), Light Gradient Boosting Machine ( LGBM ), Multilayer Perceptron ( MLP ), Random Forest ( RF ), Linear Support Vector Classification ( SVC ), eXtreme Gradient Boosting ( XGB ), Decision Tree ( DT ), AdaBoost, Stacking, e Voting — com o objetivo de classificar os UE s nos eixos a partir do tráfego de rede observado. No pipeline de ML implementado, os modelos alcançaram até 99.91% de F1-score para a classe eMBB ao utilizar RF , LGBM e XGB . Para a classe URLLC , os melhores resultados foram de 99.99% de F1-score com o SVC . Em contraste, devido à natureza esparsa dos dados da classe mMTC , enquanto o AdaBoost alcançou 99.99% de F1-score no cenário de burst, a performance ficou limitada em 2.74% no cenário probabilístico. Mesmo após empregar técnicas que incluíram o balanceamento dos dados de treinamento, os modelos sofreram de overfitting. Inspirado pelo movimento de ciência aberta, tanto o software utilizado quanto o conjunto de dados criado para a inferência estão acessíveis publicamente. Essa abordagem garante a reprodutibilidade e estabelece bases para investigações futuras sobre análise de dados conforme especificado pelo 3GPP . Palavras-chave: 5G; tráfego de rede; classificação. FAD free5GC Auto Deploy FLOSS Free/Libre and Open Source Software FN False Negative FP False Positive FPR False Positive Rate GNS3 Graphical Network Simulator 3 gNB gNodeB GPRS General Packet Radio Service GQUIC Google Quick UDP Internet Connections GSM Global System for Mobile Communications GTP General Packet Radio Service Tunneling Protocol GTP-C GTP Control Plane GTP-U GTP User Plane GTP’ GTP charging HAC Hierarchical Agglomerative Clustering HD High-definition HGB Histogram-based Gradient Boosting HSPA High Speed Packet Access HTTP Hypertext Transport Protocol HTTPS Hypertext Transport Protocol Secure ICMP Internet Control Message Protocol IEEE Institute of Electrical and Electronics Engineers iid independent and identically distributed IMT International Mobile Telecommunications IoT Internet of Things IP Internet Protocol ISSN International Standard Serial Number ITU International Telecommunication Union JSON JavaScript Object Notation kB Kilobyte KPI Key Performance Indicator KNN K-Nearest Neighbors LAN Local Area Network LGBM Light Gradient Boosting Machine LR Linear Regression LSTM Long Short Term Memory M2M Machine to Machine MANO Management and Orchestration MB Megabyte MCDM Multiple-Criteria Decision Making ML Machine Learning MLP Multilayer Perceptron MMS Multimedia Messaging Service mMTC Massive Machine-Type Communications MNO Mobile Network Operator ms Millisecond MTLF Model Training Logical Function MTU Maximum Transfer Unit NEF Network Exposure Function NF Network Function NFV Network Function Virtualization NGMN Next Generation Mobile Networks Alliance NMT Nordic Mobile Telephone NN Neural Network NR New Radio NRF Network Repository Function NS-3 Network Simulator 3 NSSF Network Slice Selection Function NTN Non-Terrestrial Network NWDAF Network Data Analytics Function OAM Operations, Administration, and Maintenance OCSP Online Certificate Status Protocol OS Operating System OvO One-vs-One PCAP packet capture PCF Policy Control Function PDU Protocol Data Unit PLC Programmable Logic Controller PNIO PROFINET IO PoP Publish or Perish PPS Packets per Second QoE Quality of Experience QoS Quality of Service QUIC Quick UDP Internet Connections RAM Random Access Memory RAN Radio Access Network RAT Radio Access Technology RF Random Forest RMSE Root Mean Square Error RNN Recurrent Neural Network ROC Receiver Operating Characteristic RTT Round-Trip Time SA Stand-Alone SBA Service Based Architecture SBI Service Based Interface SDN Software-Defined Networking SLR Systematic Literature Review SMF Session Management Function SMS Short Message Service SSL Secure Sockets Layer SVM Support Vector Machine SVC Support Vector Classification TCP Transmission Control Protocol TEID Tunnel Endpoint Identifier TLS Transport Layer Security TN True Negative TP True Positive TPR True Positive Rate TR Technical Report TS Technical Specification TSG Technical Specification Group TTL Time To Live TV Television UAV Unmanned Aerial Vehicle UDM Unified Data Management UDP User Datagram Protocol UDR Unified Data Repository UE User Equipment UMTS Universal Mobile Telecommunications System UN United Nations UP User Plane UPF User Plane Function URL Uniform Resource Locator URLLC Ultra Reliable and Low Latency Communications VM Virtual Machine VoIP Voice over Internet Protocol WoS Web of Science XGB eXtreme Gradient Boosting XR Extended Reality ZSM Zero-touch network and Service Management ZTN Zero-Touch Network TABLE OF CONTENTS 1 INTRODUCTION .......................... 20 1.1 MOTIVATION................................ 20 1.2 RESEARCHGOAL............................. 21 1.3 MAINCONTRIBUTIONS ......................... 21 1.4 RESEARCHOUTPUT........................... 22 1.5 OUTLINE .................................. 24 2 BACKGROUND........................... 25 2.1 MOBILENETWORKS........................... 25 2.1.1 Standards Organizations ........................ 25 2.1.2 Previous Generations .......................... 26 2.1.3 Fifth Generation of Cellular Network ................ 28 2.1.3.1 5G Service Axes ............................... 29 2.1.3.2 5G Core ................................... 30 2.1.3.3 Data Storage and Analytics ......................... 32 2.1.4 Beyond 5G ................................. 34 2.2 MACHINELEARNING .......................... 35 2.2.1 Model Life Cycle Terminology ..................... 35 2.2.2 Performance Metrics ........................... 36 2.2.2.1 Accuracy ................................... 36 2.2.2.2 Precision ................................... 36 2.2.2.3 Recall ..................................... 37 2.2.2.4 F1-score ................................... 37 2.3 SUMMARY ................................. 37 3 LITERATUREREVIEW...................... 38 3.1 SYSTEMATIC LITERATURE REVIEW . . . . . . . . . . . . . . . . . 38 3.2 RELATEDWORK ............................. 42 3.3 COMPARISON ............................... 47 3.4 SUMMARY ................................. 54 4 METHODOLOGY.......................... 55 4.1 MLPIPELINE................................ 55 4.2 5G SIMULATION ENVIRONMENT . . . . . . . . . . . . . . . . . . . 56 4.3 5G NETWORKS TRAFFIC DATASETS . . . . . . . . . . . . . . . . . 57 4.4 FREE5GC AUTO DEPLOY . . . . . . . . . . . . . . . . . . . . . . . . 59 4.5 NWDAF FUNCTIONALITY IMPLEMENTATION . . . . . . . . . . . 61 4.5.1 Data Preparation ............................. 61 4.5.2 Implementation Details and Execution ............... 62 4.5.3 Traffic Generator ............................. 63 4.6 SUMMARY ................................. 64 5 RESULTS AND DISCUSSION . . . . . . . . . . . . . . . . . . 65 5.1 NETWORKDATASET........................... 65 5.1.1 Packet Capture Dataset ......................... 65 5.1.2 Frequency Analysis ............................ 66 5.1.2.1 Protocol Label ................................ 66 5.1.2.2 Frame Length ................................ 71 5.1.3 Hypothesis Tests ............................. 74 5.2 MACHINE LEARNING MODELS FOR CLASSIFICATION . . . . . . 76 5.2.1 Model Tuning ............................... 77 5.2.2 Feature Importance ........................... 77 5.2.3 Model Performance ........................... 79 5.2.3.1 Training ................................... 79 5.2.3.2 Inference ................................... 81 5.2.3.3 Cross Validation ............................... 86 5.3 DISCUSSION ................................ 87 5.4 SUMMARY ................................. 89 6 CONCLUSION............................ 90 6.1 CONTRIBUTIONS............................. 90 6.2 LIMITATIONS ............................... 91 6.3 FUTUREWORK.............................. 91 REFERENCES............................ 93 APPENDIX A – Source of the install-go.sh script . . . . . . . 105 APPENDIX B – Source of the deploy-free5gc.sh script . . . . 106 APPENDIX C – Source of the deploy-UERANSIM.sh script . 117 APPENDIX D – Source of the deploy-n3iwue.sh script . . . . 121 APPENDIX E – Source of the deploy-tngfue.sh script . . . . . 126 APPENDIX F – Source of the pcap_extract.sh script . . . . . 128 APPENDIX G – Source of the dataset_CSV_characterization.py script.................................. 132 APPENDIX H – Source of the stat-plotter.py script . . . . . . 135 APPENDIX I – Source of the export_JSON.py script . . . . 140 APPENDIX J – Source of the json2csv.py script . . . . . . . . 142 APPENDIX K – Source of the box-plotter.py script . . . . . . 150 APPENDIX L – Source of the add_label_to_name.sh script 152 APPENDIX M – Source of the ml.py script . . . . . . . . . . . 154 APPENDIX N – Source of the inference.py script . . . . . . . 165 APPENDIX O – Source of the traffic generator scripts . . . . 170 APPENDIX P – Source of the model_tuning.py script . . . . 175 APPENDIX Q – Source of the dt_visualization.py script . . . 184 APPENDIX R – Test phase confusion matrices . . . . . . . . . 187 APPENDIX S – Test phase raw performance metrics . . . . . 191 APPENDIX T – eMBB inference confusion matrices . . . . . 195 APPENDIX U – URLLC inference confusion matrices . . . . 199 APPENDIX V – mMTC burst inference confusion matrices . 203 APPENDIX W – mMTC probabilistic inference confusion matrices.................................... 207 APPENDIX X – Weighted recall definition and example . . . 211 APPENDIX Y – Receiver Operating Characteristic Area Under the Curve.................................. 216 20 1 INTRODUCTION In the context of fifth generation of cellular network ( 5G ), Brazil has reached over 20.5 million 5G connections as of 2023, with a total 40 million 5G connections registered in 2024 ( 2 ), while worldwide 1.6 billion 5G connections were established in 2023 ( 3 ). As the number of connected devices continues to rise, the efficiency and reliability of 5G networks become increasingly crucial to ensure seamless user experiences, support emerging use cases, and mitigate congestion and latency issues. 5G introduces a paradigm shift in mobile network architecture, leveraging a Service Based Architecture ( SBA ) for the first time. This approach marks a significant shift from previous generations, which were characterized by a more rigid and centralized reference-based architecture. A SBA is based on a service-oriented concept, where components are designed to be coherent and loosely coupled. This enables the integration of diverse network elements and services. Network Function Virtualization ( NFV ) principles are also applied, where multiple entities from previous generations are virtualized as distinct Network Functions ( NF s). Each NF is exposed through a standardized Service Based Interface ( SBI ) bus ( 4 ). Key benefits of the SBA include improved flexibility, scalability, and interoperability. The service-oriented approach enables seamless communication among network components. The SBI bus and interfaces are part of the SBA design of the 5G Core ( 5GC ). An 5GC is a conceptual element of the 5G network that contains most of the NF s and the main SBI bus. The 5GC architecture also adopts the concepts of Software-Defined Networking ( SDN ), which means that there is a separation between the Control Plane ( CP ) and the User Plane ( UP ) — that could be also referred as Data Plane ( DP ). This Control and User Plane Separation ( CUPS ) enables isolating the network traffic from the internal 5GC NF communication, thus allowing for the setup of multiple UP s controlled by the same CP NF s. Key functionalities of the CP NF s include UP packet processing management, policy configuration and enforcement, User Equipment ( UE ) charging, and general traffic monitoring, while the UP NFs forward user traffic (5, 6). 1.1 MOTIVATION Experimenting with real equipment remains a costly endeavor. Therefore, specially when considering 5G and Beyond 5G ( B5G ) networks, simulated environments become critical for increasing efficiency and reducing the costs of experimentation and planning ( 7 ), even though these may have some limitations relative to real-world scenarios. One approach to enhance the characteristics of 5G cellular networks is to leverage their NF s’ flexibility and perform reconfigurations during run time. These reconfigurations may be automated and based on data collected within the network. According to the 3 rd 21 Generation Partnership Program ( 3GPP ) specifications ( 8 ), a NF that is responsible for collecting data and providing insights is the Network Data Analytics Function ( NWDAF ). As defined by 3GPP ( 9 ), the NWDAF can utilize Machine Learning ( ML ) models on data to automate analytics information generation, including NF load analytics. Furthermore, 3GPP specifies that the NWDAF may be employed in ML -assisted operations within the 5G System ( 5GS ), which includes tasks such as Base Station ( BS ) frequency ( 10 ) or slice — an end-to-end logical network including network, computing, and storage resources — reconfiguration ( 11 , 12 ), or even User Plane Function ( UPF ) selection as in ( 13 ). Consequently, evaluating model performance is essential for achieving accurate classifications in use cases focused on the correct grouping of UEs. In this context, the 5G services can be separated in axes or vertical groups ( 14 ). According to ( 15 ), there are 3 main ways of classifying them: 3 axes by International Telecommunication Union ( ITU ), 5 axes by 3GPP and 14 axes by Next Generation Mobile Networks Alliance ( NGMN ). Considering the concepts and Key Performance Indicators ( KPI s) presented by ( 15 ) and ( 16 ) on the 5G services, it is possible to deduce that the classification of each service to a given axis depends on the context and a given use case may fit in more than one group. Thereby, the methodology that utilizes the network traffic to classify UE s in the service classes, presented in Chapter 4, was designed based on ITU ’s ( 16 ) 3-type classification: Enhanced Mobile Broadband ( eMBB ), Massive Machine-Type Communications ( mMTC ), and Ultra Reliable and Low Latency Communications ( URLLC ) defined in Subsection 2.1.3.1 . The classifier is intended to be integrated into an NWDAF instance, enabling the NWDAF to share classification results with any consumer NF s, as detailed in Subsection 2.1.3.3. 1.2 RESEARCH GOAL The main research problem is device classification based on observed traffic. Given the motivation presented in Subsection 1.1, the research goal is defined as follows: to create and use an open-source simulated 5G network environment to experiment with and assess the performance of employing ML models and data analysis techniques to classify UE s in the 5G service axes based on their network traffic, providing useful information for 5G Mobile Network Operators ( MNO s) to support network operation decisions that improve reliability and efficiency. 1.3 MAIN CONTRIBUTIONS The main scientific and technical contributions of this work are summarized below: •Implementation and evaluation of ensemble learning methods for UE classification 22 Based on the findings from the literature review in Section 3.2, there is a notable absence of studies investigating the application of ensemble learning models for UE classification. Therefore, as outlined in Section 3.3, in addition to training ML models, the training of models based on ensemble methods was also conducted, with the results evaluated in Section 5.2. •Generation of a 5G simulated traffic capture dataset Considering the absence of real world 5G publicly available datasets and some similarities shared by cellular and Wi-Fi ( 17 ), quite frequently, the work found in the literature utilizes Wi-Fi datasets for experimentation — e.g., as in ( 18 , 19 , 20 , 21 ) — while another alternative approach involves the use of simulated data — e.g., ( 22 , 23 ). This lack of 5G datasets is further supported by the literature mapping results discussed in Section 3.3 and the dataset survey described in Section 4.3. Therefore, the generation of new 5G traffic capture datasets is required, especially in the packet capture ( PCAP ) format. The created traffic dataset introduced in Subsection 5.1.1 was released in PCAP format, which is designed to store network traces ( 24 , 25 ) and provides detailed packet information (e.g., flags and payloads), allowing for in-depth analysis, feature extraction, and traffic replay. 1.4 RESEARCH OUTPUT Throughout the research conducted for this master’s thesis, several papers were published at national and international conferences, a mini course was developed, and contributions to Free/Libre and Open Source Software (FLOSS) were made. The short paper titled “Estudo e Avaliação de Métodos de Autenticação EAP na Infraestrutura de Redes de Telecomunicação 5G” ( 26 ) was presented at “XIII Workshop de Gestão de Identidades Digitais (WGID)” and published in September 2023 in the conference proceedings of “XXIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais”. This paper includes a survey conducted to identify opensource tools that facilitate the simulation of 5G networks, leading to valuable experience with free5GC ( 27 ) and UERANSIM ( 28 ) — projects that would later contribute to the development of the free5GC Auto Deploy ( FAD ) tool ( 29 ) presented in Section 4.4 and integrate the environment presented in Section 4.2. The paper titled “Análise da Funcionalidade da NWDAF no Core 5G Sobre um Conjunto de Dados” ( 30 ) was presented in the main track of “XLII Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC)” and published in May 2024 which holds a Qualis A4 rating. The findings from this work laid the foundation for the design and development of the ML pipeline detailed in Section 4.1, paving the way for practical applications of models, while representing the initial outcomes of this master’s thesis. 23 A second paper that contributes to the same line of inquiry titled “A NWDAF Study Employing Machine Learning Models on a Simulated 5G Network Dataset” ( 31 ) was presented at “IV International Workshop on Distributed Intelligent Systems (DistInSys)” and published in June 2024 in the conference proceedings of “XXIX IEEE Symposium on Computers and Communications (ISCC)”. This paper refined the techniques employed in the previous work and highlighted the limitations of the previously created dataset, particularly regarding the quantity of packets. Notably, the experience gained was invaluable in implementing the NWDAF -based functionality detailed in Section 4.5 and the traffic generator and dataset outlined in Subsection 5.1.1. Another short paper titled “Eduroam e 5G: autenticação integrada via redes móveis e Wi-Fi no core 5G” ( 32 ) was presented at “XIV Workshop de Gestão de Identidades Digitais (WGID)” and published in September 2024 in the conference proceedings of “XXIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais”. This paper built upon the previous work and was significant for refining the 5G simulation environment, with the implementation of the FAD tool emerging as one of its outcomes, achieving a production-ready development status. Additionally, the knowledge acquired and the details of the simulation environment, including the 5G network concepts underlying the FAD tool and its application in creating a testbed, were transformed into a mini course titled “Introdução a ambientes de experimentação 5G” ( 33 ), which was delivered during the “XXVI Semana da Computação do Departamento de Ciência da Computação da UFJF” in November 2024. Part of the outputs of this work are related to supporting open science ( 34 ) in the computer networks field. Consequently, as part of the implementation efforts described in Sections 4.4 and 4.5, several code patches ( 35 ) and documentation enhancements ( 36 ) were submitted to the official repositories of free5GC and UERANSIM tools, being available to the community. Alongside the implemented patches, it was possible to actively participate in issue ( 37 ) and forum discussions ( 38 ) contributing to the improvement of the aforementioned tools. FAD , a tool to automate the deployment of the simulation environment presented in Section 4.2, was released under a FLOSS compatible license, being publicly available on GitHub (29). Furthermore, the artifacts generated during the research are publicly available. The literature review records and the raw results of the conducted experiments (including model feature importance and model performance results – of the training, inference, and cross validation) and directory structure listing examples were published on Zenodo ( 39 ). The dataset utilized on the experimental phase was also published on Zenodo ( 40 ). The source code of the traffic generator and the NWDAF-based functionality implemented, including their documentation were also made available on GitHub (41). 30 Figure 2 – 5G service axes and usage scenarios of IMT for 2020 and beyond Enhanced Mobile Broadband (eMBB) Massive Machine Type Communications (mMTC) Ultra-reliable and Low Latency Communications (URLLC) Smart city Voice Smart home/building Gigabytes per second (or Big Data) 3D video, UHD screens Work and play in the cloud Augmented Reality (AR) Industry Automation Mission critical application Self driving car Future IMT Source: Created by the author (2025). Based on (16). of non-delay-sensitive data. It emphasizes low device cost and extended battery life to support the proliferation of connected assets. These axis definitions provided the foundation for selecting the applications utilized in the environment described in Section 4.2, as well as the class labels employed in the model performance evaluation presented in Subsection 5.2.3. 2.1.3.2 5G Core The 5G Core ( 5GC ) is a crucial component of 5G networks, comprising multiple NF s that can be divided into two SDN planes, forming the CUPS : the UP and the CP . This separation enables efficiency because, for instance, the network traffic from the UE can be routed directly from the Radio Access Network ( RAN ) to the UPF ( 54 ). Figure 3 provides an overview of the 5GC architecture, according to the CUPS paradigm. The NF s within the blue and green rectangles comprise the 5GC . It is designed using a SBA , wherein network functions provide modular and reusable services through standardized interfaces (depicted in blue), thereby enhancing agility and scalability in service provisioning (14). From a logical perspective, the 5GC interfaces with the RAN via the N2 interface, with the UE via the N1 interface, and with the UPF via the N4 interface ( 53 ). Further details regarding the UPF interfaces will be provided in Subsection 2.1.3.3 . In a production environment, the RAN refers to a network infrastructure component consisting of radio BS s equipped with large antennas ( 55 ). Its primary function is to establish physical and logical connections between UE s and the 5GC ( 14 ). Conceptually ( 53 ), it may also be defied as a generic 5G AN . In contrast, the Radio Access Technology 31 Figure 3 – 5GS CUPS overview Source: CHAI; LIN (54) (2021). (RAT) pertains specifically to the physical layer communication protocols and standards employed in the RAN, which, in the context of 5G, corresponds to the NR standard. A User Equipment ( UE ) can be defined as any equipment that allows a user to access network services. In the context of 5G ( 56 ), the interface between the UE and the network is the radio interface. Following the ITU definition in ( 57 ), a UE is a equipment that provides the functions necessary for the operation of the access protocols by the user. Examples of 5G UE s include smartphones, laptops, and any device capable of using a 5G wireless network interface to connect to a NR/gNB BS. The General Packet Radio Service Tunneling Protocol (GTP) is an indispensable protocol of the 5G network architecture, enabling efficient communication between UE , gNB , and other NF s. As a tunneling protocol, GTP facilitates the delivery of GPRS packets within a mobile network, allowing for transmission over IP networks via User Datagram Protocol (UDP) as path protocol (58, 59). The GTP protocol consists of GTP Control Plane ( GTP-C ), GTP User Plane ( GTP-U ), and GTP charging ( GTP’ ) components, each responsible for specific functions. The tunneling mechanism involves encapsulation of GPRS packets within a custom header structure, enabling efficient transmission. Key parameters in the GTP-U header include message type, packet length, sequence number, Tunnel Endpoint Identifier ( TEID ), and next extension header type. In 5G networks, GTP-U tunnels are employed to transmit user data between the gNB and the UPF (59). The 3GPP specification ( 53 ) defines the role of User Plane Function ( UPF ) in 32 implementing the UP of the CUPS scheme, where it acts as a router for data traffic from and to the UE . The arrangement of the N3 , N4 , and N6 interfaces, as depicted in Figure 3, facilitates direct connectivity between UE data and the Data Network (DN) (5, 6). In more detail, the UPF encompasses a wide range of functionalities, including intraand interRAT mobility anchoring, external Protocol Data Unit ( PDU ) session points of interconnect to DN s, packet routing and forwarding, inspection, policy rule enforcement, lawful intercept, traffic usage reporting, QoS handling, uplink traffic verification, transportlevel packet marking, downlink buffering and notification triggering, end marker sending and forwarding, and response to Address Resolution Protocol ( ARP ) and IP v6 Neighbor Solicitation requests. These functionalities are designed to ensure efficient and secure management of UP data traffic, while also supporting the requirements of various network slices and service scenarios. Notably, not all functionalities are necessarily supported in a single instance of the UPF , because the N9 interface enables the deployment of multiple customized UPF instances within the same 5GC domain ( 14 ), allowing for flexibility and customization in accordance with specific network slice requirements. Apart from the UPF , the specified ( 53 ) NF s for the 5GC include the Session Management Function ( SMF ), which oversees UPF selection, session management — e.g., between AN and UPF — IP address allocation, traffic steering, policy enforcement, and QoS ; the Access and Mobility Function ( AMF ), responsible for mobility management, access authentication and authorization, security anchoring, and context management; the Policy Control Function ( PCF ), which establishes the policy framework governing network behavior and the CP NF s; the Authentication Server Function ( AUSF ) which provides authentication and authorization for UE s via the AMF and informs the authentication status to the Unified Data Management ( UDM ); the Network Repository Function ( NRF ), which facilitates the discovery of network function instances for inter-function communication; the Network Exposure Function ( NEF ), which supports third party independent functionalities — e.g., by exposing network function capabilities and events to Application Functions ( AF s); the Network Slice Selection Function ( NSSF ), which selects the appropriate network slice instances and the optimal AMF for the UE ; and the Unified Data Repository ( UDR ), which serves as the database for UE -related information — e.g., subscription data — complemented by the UDM , which supports the subscription management — e.g., the generation of authentication credentials — and acts as a front-end for the UDR . 2.1.3.3 Data Storage and Analytics The Analytics Data Repository Function ( ADRF ) was introduced on Release 17 ( 60 ) and is specifically designed to provide a centralized repository for data or analytics. The ADRF enables consumer NF s to interact with its repository through functions that include 33 storing, retrieving, and removing data. These capabilities enable consumer NF s to leverage the ADRF as a trusted repository for their data. For instance, the NWDAF is expected to support the aforementioned key functionalities which means the ADRF can be used to support NWDAF operations, in particular while analyzing network performance, traffic patterns, and some relevant metrics, ultimately facilitating data-driven decision-making and optimized network operations. The Network Data Analytics Function ( NWDAF ) is a component of 5G networks that collects, processes, and analyzes data from various sources to extract insights and trends, enabling informed decision-making and optimized network performance. As specified by 3GPP ( 61 ), it may gather data from UE , BS , or any other 5GC NF s, storing, processing, and analyzing it to identify patterns, anomalies, and trends. The NWDAF provides useful information on aspects such as NF load, network performance, observed service experience (e.g., Quality of Experience ( QoE )), and UE -related analytics. It also typically integrates with other NF s like the UPF and the ADRF in a way that its analytics provide intelligence that can be leveraged to optimize network performance, enhance security, and increase operational efficiency. The 3GPP Release 17 ( 9 ) specified that this NF could be functionally split in two other logical functions: Analytics Logical Function ( AnLF ) and Model Training Logical Function (MTLF) (62). The AnLF is a component within the NWDAF tasked with processing and analyzing network data to yield insights. Its primary responsibilities encompass inference on collected data, statistical analysis of past events, and predictive analytics for future network behavior. The AnLF serves as the primary analytics engine, providing a gateway for analytics services through its service interfaces thereby facilitating the exchange of analytics and insights between various NF s and stakeholders. Its capabilities may be extend to the implementation with both statistical and ML models provided by the MTLF. The MTLF is the other logical component of the NWDAF, which is specifically designed to train ML models utilizing collected network data. In essence, MTLF ’s primary functions revolve around the development and management of ML models. It serves as a enabler for other components within the 5GS by providing trained ML models to the AnLF or other NF s. This enables the seamless integration of ML -based analytics with other NF s of the 5GC (or even other NWDAF instances), thereby enhancing overall network performance measurement and decision-making capabilities with the timely update and provisioning of trained models. Notably, the specification ( 63 ) allows analytics and collected data to be stored and retrieved from ADRF . As of Release 18 ( 61 ), trained models can also be stored on and retrieved from ADRF . Furthermore, UPF can serve as a data source for obtaining or calculating various metrics, including packet delay, bit rate, number of transmitted 34 packets, and packet retransmission rate. As discussed in Subsection 5.1.1, the potential to utilize the UPF as a data source significantly influenced the decision to collect network traffic in this NF. Figure 4 – Functional overview of the NWDAF 5GC / 5GS Consumer NF 1 Consumer NF 2 Consumer NF N Producer NF 1 Producer NF 2 Producer NF N 5GC / 5GS Analytical data feed AnLF MTLF NWDAF ADRF OAM DCCF OR Data transfer Analytics response Analytics request Analytics response Analytics request Source: Created by the author (2025). Based on (64) and (65). Figure 4 provides an overview of how a NWDAF , integrating both AnLF and MTLF logical functions, interacts with other NF s. As specified in ( 61 ), a NWDAF integrated into the 5GC SBI bus facilitates CP interactions as illustrated in Figure 4. Producer NF s, such as the UPF , transfer data to the NWDAF , which can store and retrieve analytical data from the ADRF (if implemented), thereby establishing an analytical data feed. Consumer NF s, including the AMF and PCF , subscribe to receive information through analytics requests, which are answered with analytics responses that can support slice selection ( 11 ). Additionally, the Operations, Administration, and Maintenance ( OAM ) components, designed to enhance the management and monitoring of 5G transport networks, may utilize information from NWDAF to perform orchestration tasks, including BS frequency reconfiguration (10). 2.1.4 Beyond 5G Future cellular networks are classified as Beyond 5G ( B5G ), representing an evolution built upon the foundation of 4G technologies ( 10 ). In addition, the definition of B5G encompasses both the evolution of 5G (such as 5G Advanced) and the emerging sixth generation of cellular network ( 6G ) networks, which extend established 4G innovations while integrating new technologies to address the evolving demands of wireless communications (66, 67). 35 B5G / 6G is expected to integrate AI at its core, enabling advanced air interfaces and network functionalities such as optimized symbol detection, channel estimation, and dynamic resource management ( 10 ). These networks will leverage on-demand and distributed machine learning for automated, intelligent operation, ensuring real-time responses with significantly reduced latency. Furthermore, these systems will combine sensing and communication to enhance overall performance, reduce costs, and lower power consumption. Enhanced edge computing, efficient spectrum utilization, and novel security measures will support a diverse range of applications and services, positioning B5G / 6G as an accumulative evolution over current technologies (68, 66, 67). Although academia and standardization bodies such as 3GPP and ITU are already working on research developments and standards for B5G networks, 6G is notably still in its early stages (69). 2.2 MACHINE LEARNING Machine Learning ( ML ) is a branch of the AI research field focused on the development and analysis of statistical algorithms that enable computer systems to learn from data and generalize to previously unseen data, thereby performing tasks without requiring explicit instructions ( 70 ). As explained in Subsection 2.1.3.3 , ML models may be used by 5G networks to perform analytics-related tasks. Therefore, it is important to define the pertinent terminology (Subsection 2.2.1) and evaluation metrics (Subsection 2.2.2). 2.2.1 Model Life Cycle Terminology Machine Learning models undergo a structured life cycle that encompasses four main stages: experimentation, training, testing, and inference. It is essential to delineate these stages explicitly to ensure clarity and precision in the development and application of ML models. The experimentation phase involves testing different algorithms and choosing which model architectures and training methods will be used within the life cycle. For instance, this could involve testing various models like Linear Regression ( LR ) or Decision Tree ( DT ) and exploring different hyperparameters to increase robustness (71). Then, the supervised learning models training phase involves providing the selected ML algorithms with labeled or categorized data so it can iteratively process large, featurerich datasets and recognize its patterns. Notably, the quality of the training dataset significantly influences model’s performance (72). It is crucial to evaluate an ML algorithm using a suitable dataset after training, accessing its performance by exposing it to previously unseen test data. This evaluation 36 process, known as data testing, entails comparing the model’s output against actual results (also referred to as ground truth) for each example within the test set, thereby assessing the model’s accuracy and reliability ( 72 ). It is worth mentioning that the results from this phase can be leveraged to improve model performance via hyperparameter optimization. Following successful completion of the previous phases, models transition into the inference phase, where they are deployed to perform tasks without human intervention ( 71 ), such as classification tasks like object, image or packet classification. 2.2.2 Performance Metrics In light of the potential variations in terminology and usage, which may lead to differing performance metrics for evaluating a ML model, this section explicitly defines each metric employed. The definitions displayed on Subsections 2.2.2.1 to 2.2.2.4 are based on ( 73 ) and ( 74 ). In classification problems, four key concepts are essential: True Positive ( TP ), where a correct prediction is made for a sample that belongs to the positive class; True Negative ( TN ), where a correct prediction is made for a sample that does not belong to the positive class; False Positive ( FP ), where an incorrect prediction is made for a sample that does not belong to the positive class; and False Negative ( FN ), where an incorrect prediction is made for a sample that belongs to the positive class. Consider the multivariate Bernoulli variable definition from ( 75 ) and that a given n -th class Cn can be either positive/target (i.e., Cn = 1) or negative/background (i.e., Cn = 0). In multi-class classification problems, the target class is designated as the positive class, while the remaining classes are collectively regarded as the negative class. For example, let C1 be the positive class and C2 and C3 the negative ones. Given a sample that belongs to the positive class (e.g., C1 = 1) input to the classifier, if the output vector is Ci = (1 , 0 , 0) then the result is correct and it will be considered as a TP , otherwise (e.g., Ci= (0,1,0) or Ci= (0,0,1)) the result is not correct and it will be considered as a FN. 2.2.2.1 Accuracy Let ˆyi be the predicted value of the i-th sample and yi the corresponding true value, then the fraction of correct predictions over nsamples is defined in Equation 2.1, where 1( x ) is called the indicator function. accuracy(y, ˆy) = 1 nsamples nsamples−1 X i=0 1(ˆyi=yi)(2.1) 2.2.2.2 Precision Intuitively, the precision of a classifier is the ratio of TP s to all positive samples, i.e., it measures how well the classifier avoids labeling positive samples that are actually 37 negative. The precision can be calculated as defined in Equation 2.2. precision =TP (TP +FP)(2.2) 2.2.2.3 Recall Recall, intuitively, refers to the proportion of actual positive samples that are correctly identified by the classifier. In other words, it measures the classifier’s ability to detect and retrieve all relevant instances of the positive class from the dataset. The recall reaches its optimal value at 1, while its lowest score of 0 signifies the worst case scenario. This value can be calculated using the formula defined in Equation 2.3. recall =TP (TP +F N)(2.3) 2.2.2.4 F1-score The F-measure can be interpreted as a weighted harmonic mean of the precision and recall. A Fβ measure reaches its best value at 1 and its worst score at 0. With β = 1, Fβ and F1 are equivalent, and the recall and the precision are equally important as shown on Equation 2.4. F1 =2×TP 2×TP +FP +FN = 2 ×precision ×recall precision +recall (2.4) 2.3 SUMMARY This chapter provides a clear overview of the foundational concepts essential to the research subject. It has defined the roles of key telecommunication organizations and discussed the architectural evolution across different generations of mobile networks — with an in-depth coverage of the 5G architecture. Furthermore, the chapter outlined the life cycle terminology and the performance metrics applied for evaluating ML models. This comprehensive background is important for the remainder of the master’s thesis, providing the necessary context for the literature review in Chapter 3, the methodology presented in Chapter 4, and the analyses and discussions that will follow in Chapter 5. 38 3 LITERATURE REVIEW This chapter provides an overview of the literature review conducted before the experimental phase of the research. Section 3.1 defines the literature review and delineates the methodology employed during the review process. The findings of the literature review were utilized in selecting the relevant works discussed in Section 3.2. The main points of the reviewed work are recapitulated in Section 3.3, while Section 3.4 offers a brief outline of the chapter’s contents. 3.1 SYSTEMATIC LITERATURE REVIEW A Systematic Literature Review ( SLR ) is “a systematic way of collecting, critically evaluating, integrating, and presenting findings from across multiple research studies on a research question or topic of interest.” ( 78 ). Considering this definition, a literature review concerning the research topic was conducted. Figure 5 illustrates the main activities involved in the literature review, which will be elaborated upon in the subsequent paragraphs. Notably, it was not a complete secondary study or survey; rather, it was designed as a literature mapping aimed at investigating the relevant literature concerning this research topic. This approach serves to establish a theoretical foundation for this master’s thesis and is structured to be reproducible, thereby facilitating its utility for other researchers interested in conducting SLRs. According to ( 79 ), the selection of the databases is essential for the review process because the selection of a limited number of sources limits the literature explored. Following the three stages — Input, Processing and Output — of a literature review by ( 79 ) and the SLR methodology described on ( 80 ), the first two steps (present in the area I of Figure 5) consisted of identifying source databases and determining the query to apply. For the purposes of this study, the selected databases comprise Scopus, Web of Science ( WoS ), Crossref, Google Scholar, Semantic Scholar, Springer Link, Science Direct and IEEE Xplore. The first two databases are recognized as reliable sources ( 80 ), while the next three are accessible via the Publish or Perish ( PoP ) software ( 81 ). The remaining databases were accessed through an institutional subscription. To enhance the breadth of literature reviewed, the search query utilized the keyword “ NWDAF ” and applied filters to exclude citations and patents where applicable. This query yielded 1,180 results across the selected databases, which were exported from the databases both manually or through the built-in export function of PoP (first two steps of the area II of Figure 5). The distribution of results from each database is illustrated in Figure 6. It is possible to observe that more than 71% of the records came from Google Scholar, while the other databases share between 5.5 and 1.4% of the records. 39 Figure 5 – Literature review main steps Database Query Save Results Locally Convert to BIB formatImport to Parsifal Reject duplicates automatically Update missing metadata (e.g., abstract) Reject all with title or abstract in another language Reject all with content in another language Reject all that could not be accessed Reject all from other research fields Reject all that are not full papers Accept QUALIS superior Reject all not from QUALIS superior Accept CiteScore 1st Quartile Reject all surveys Update preprints that have been peer reviewed Reject based on title and abstract 2 Reject QUALIS A4 Look for the word "classification" Database Selection Query Selection Look for the word "testbed" Reject based on title and abstract 1 Export from Parsifal 2 Look for the word "unsupervised" Reject all unclassified Export from Parsifal 1 (I) (II) (III) (IV) (V) Source: Created by the author (2025). The final step of the area II of Figure 5 was to convert the results to the widely used BibTeX ( 82 ) reference management format which is compatible with Parsifal ( 83 ), an online tool that was designed to help managing the considerable amount of data created during a SLR work more easily. As represented in the area III of Figure 5, after loading the results to Parsifal, the first action taken was to use its built-in function to remove all the duplicate entries, which resulted in 834 entries left. Parsifal contains multiple metadata fields: title, abstract, year, author, keywords, author keywords, BibTex key, journal, document type, pages, volume, Digital Object Identifier ( DOI ), Uniform Resource Locator ( URL ), affiliation, publisher, International Standard Serial Number ( ISSN ), language and note. After removing the duplicates, all remaining entries were manually updated to add missing metadata (specially the abstract). While updating the ISSN , for the publications that had multiple entries the Electronic/Online ISSN had precedence over Print ISSN . After the metadata update, 10 new duplicate entries were removed, resulting in 824 entries left. One interesting finding 46 packet lengths per device in the same interval. For the training phase of the first stage (classifying IoT, nonIoT , and router), the performance metrics achieved up to 97.6% accuracy and 92.4% F1-score for RF . For the testing phase of the second stage (multiclass classification per device type), the best result of accuracy was 82.6% and 86.8% for the LSTM + CNN model on the two datasets tested. The dataset contained 141,654 total packets with class imbalance. The authors conclude that the proposed method effectively classifies IoT devices by analyzing packet header statistics in the first stage. In the second stage, the system was able to classify a wider range of IoT device types, with the combined LSTM + CNN model achieving 12% higher accuracy with a training time that was 40 times shorter than ResNet 1D model. The method is expected to facilitate traffic classification by device type for capacity planning in networks with a massive number of dynamically connected devices. In ( 101 ), a NWDAF prototype compatible with Open5GS ( 102 ) was implemented to monitor NF traffic within the 5GC and assist MANO systems. Although the source code is unavailable, the dataset — comprising 138 minutes of captured traffic and 171,821 packets — was shared. The environment used Open5GS as the 5GC and UERANSIM as the UE simulator. To develop the models, seven features were extracted from each packet: No., Time, Source IP , Destination IP , Protocol, Length, and Info; packets not belonging to interNF traffic were excluded. A K-means clustering algorithm was then applied to group NF s based on source and destination NF , average and maximum packet length, standard deviation of packet length, and total number of transmitted packets for each NF pair. Through clustering and unsupervised learning, the authors demonstrate the ability to identify similarities in NF interactions and apply NWDAF insights to Intelligent Networks and NFV MANO , highlighting NWDAF ’s potential to support efficient network management in B5G networks. The authors emphasize that NWDAF is crucial for intelligent networks and MANO tasks, assisting in resource allocation and anomaly detection. Finally, a conditional packet classifier was implemented to classify 5G traffic by service in ( 103 ). The traffic generation environment comprised free5GC as the 5GC and three UERANSIM instances. Without relying on ML models, the author implemented three conditional techniques: The first technique evaluates whether the protocol is Transmission Control Protocol ( TCP ); if so, it analyzes the payload size, assigning small payloads to mMTC and larger ones to eMBB , while UDP packets are classified as URLLC . The second technique matches the source or destination port against a predefined service list for classification; if no match is found, the first technique is applied. The third technique assigns 18 weights (six per class) to various parameters, with the classification result determined by the highest total score. As reported in the work, the best performance was achieved with the third technique, which reported an average accuracy of 99.8% (per class: 100% for eMBB , 79.15% for mMTC , and 99.84% for URLLC ). The source code 47 was provided as code listings, and the approach offers a greater level of explainability compared to black-box ML models. The packet dataset was heavily imbalanced (5.15% eMBB , 0.45% mMTC , and 94.40% URLLC ), likely due to the characteristics of the traffic streams. On the one hand, URLLC traffic contained a capture of a remote-controlled Unmanned Aerial Vehicle ( UAV ) coupled with a camera, thus generating a high number of packets. On the other hand, eMBB and mMTC traffic were respectively generated by a smartphone browsing web pages and an IoT sensor sending periodic data. This study offers an analysis of traffic classification in 5G networks, demonstrating the effective use of simulators such as free5GC and UERANSIM to emulate network topologies and behaviors. It also discusses the advantages and limitations of using high-level languages such as Python for packet classification, with particular emphasis on practical considerations for QoS -critical applications. Future work includes applying ML models to enhance the weighting approach used in the third technique. 3.3 COMPARISON Research efforts are underway to explore how the NWDAF can be used on current 5G networks ( 62 ) and serve as an enabler for future closed-loop network architectures without human intervention ( 104 ), including Zero-Touch Network ( ZTN ) and Zero-touch network and Service Management ( ZSM ) networks ( 93 , 105 ). These advancements represent a crucial step towards the development of proactive networks driven by AI ( 88 ), which will contribute to the emergence of the 6G . Within this context, the investigation of the state of the art is an important step that serves as a reference to direct the current research. The 12 studies listed in this master’s thesis have contributed to the advancement of 5G network traffic classification and related areas, frequently utilizing ML models. For instance, in ( 87 ) the effect of user interaction in the classification performance of models is investigated. Moreover, ( 59 ) and ( 88 ) focus on enhancing the security of 5G networks by, detecting DoS and IoT botnet attacks, respectively. A prototype for the NWDAF to monitor NF s traffic within the 5GC is proposed in ( 101 ), which can address anomaly issues, alongside UE anomaly classification discussed in ( 91 ). The NWDAF serves as a data source for the configuration and selection of 5G slices, as proposed by ( 92 ). Additionally, ( 93 ) emphasizes the classification of cells and the identification of those with low performance. The development of a network traffic classifier for detecting voice and video streams is presented in ( 94 ), while ( 90 ) explores UE predictive classification into profiles. Furthermore, ( 97 ) introduces a ML -based classifier designed to differentiate device types based on their network traffic, and ( 100 ) examines the classification of device types by analyzing encrypted traffic behavior through statistical analysis. Finally, ( 103 ) presents a conditional packet classifier aimed at classifying 5G traffic by service without relying on ML algorithms. 48 Table 3 delineates the key characteristics of each reference cited in this chapter, with an emphasis on ML aspects. It should be noted that, with the exception of ( 103 ), the references were obtained through the literature review described in Section 3.1. In contrast to the available literature, ( 103 ) proposes a ML -independent and straightforward yet efficient approach to traffic classification that utilizes only conditionals for classifying network packets. As elaborated in the following Chapter 4, the approach taken in this study aligns with several existing studies in the literature. Similar to the work presented in ( 94 ), IFELSE structures were employed for feature extraction, with YouTube utilized as a traffic source. Features were extracted from PCAP files, in line with the methodology in ( 59 ). Additionally, feature encoding and K-fold cross validation were implemented. Based on the findings in ( 59 ) and prior experience ( 31 ), IP addresses were excluded from the feature set during ML model training. In contrast to ( 97 ), resource allocation is not involved in the current implementation. Similar to ( 100 ), the classification technique described in Chapter 4 does not rely on payload data, and class imbalance within the dataset was faced. Furthermore, protocol-specific packets were incorporated without aggregating them into windows. Table 3 – Comparison of classification techniques Reference ML models ML performance metrics Number of features Extracted features (87) DT RF Accuracy Precision Recall 10 pckt_count pckt_size throughput iat pckt_size_gt100 pckt_count_gt100 (88) Custom-CNN ResNet-V2 MobileNet-V2 EfficientNet-V2S DenseNet-201 Inception-V3 Xception F1-score 9 Timestamp Length TTL Highest layer IP flags Protocol TCP features UDP length ICMP type (90) DT RF KNN SVM Accuracy F1-score 3Packet Size(b) Downlink Delay(s) 49 Table 3 (continued) – Comparison of classification techniques Reference ML models ML performance metrics Number of features Extracted features (91) LR XGB Accuracy Precision AUC ROC 9 last2_mean last4_mean last8_mean per_change_last2 per_change_last3 per_change_last4 change_last2 change_last3 change_last4 (92) K-means (to help multicriteria methods) RMSE (clustering) 9 Latency Jitter Loss Bandwidth (Mbps) Transfer UE Experiment (id) Distance Reliability (93) Custom SVM Accuracy 7 (cell related) Date Time Traffic Volume Call Count Number of SMS (94) SVM MLP CNN LSTM RNN Accuracy 6 Packet Length (6 range functions) 50 Table 3 (continued) – Comparison of classification techniques Reference ML models ML performance metrics Number of features Extracted features (59) KNN SVM RF meta-model (stacking ensemble) Accuracy Precision Recall F1-score AUC ROC 18 10 28 (experiment dependent) eth.src eth.dst arp.src.proto ipv4 arp.dst.proto ipv4 arp.src.hw mac arp.dst.hw mac arp.opcode ip.src ip.dst ipv6.src ipv6.dst icmp.type icmp.code tcp.srcport tcp.dstport udp.srcport udp.dstport frame.len gtp.flags gtp.message gtp.length gtp.teid gtp.ext_hdr.next 51 Table 3 (continued) – Comparison of classification techniques Reference ML models ML performance metrics Number of features Extracted features (97) Tree-based: Fine Medium Coarse Optimizable SVM-based: Linear Quadratic Boosted Trees Ensemble-based: Bagged Trees RUSBoosted Trees NN-based: Medium Wide Bilayered Trilayered Accuracy 6 traffic time source IP destination IP protocol name packet length packet information (100) 1st stage: LR RF SVM 2nd stage: MLP LSTM+CNN ResNet 1D Accuracy F1-score 4 # packets sum packet lengths avg packet lengths # dst addresses (101) K-means (to cluster traffic) N/A 7 No. Time Source Destination Protocol Length Info (103) N/A N/A N/A N/A 52 Table 3 (continued) – Comparison of classification techniques Reference ML models ML performance metrics Number of features Extracted features Ours LR HGB RF DT MLP Linear SVM LGBM XGB AdaBoost Stacking Ensemble Voting Ensemble Accuracy Precision Recall F1-score AUC ROC Score 33 Packet_no Timestamp Time_delta Source_IP Destination_IP Frame_type Frame_total_length Frame_header_length Frame_payload_length Source_port Destination_port TCP_completeness TCP_compl_reset TCP_compl_fin TCP_compl_data TCP_compl_ack TCP_compl_syn_ack TCP_compl_syn TCP_compl_str TCP_flags_bin TCP_flags_str TCP_window_size TCP_window_size_scale Frame_protocols IP_protocols IP_flag_reserved_bit IP_flag_dont_fragment IP_flag_more_fragments TTL TCP_header_length Data_length QUIC_packet_length QUIC_length Source: Created by the author (2025). In the context of open science characteristics, Table 4 compares the works cited in this chapter. Among the references examined, only five ( 59 , 87 , 91 , 88 , 101 ) utilized or released public datasets, with just three available in PCAP format. Notably, only one work (88) fully released the implemented source code. 53 Table 4 – Comparison of open science characteristics Reference Year Dataset is Public Source Code is Public Aim (91) 2020 ✓(csv) Anomaly detection (93) 2021 Pseudocode Cell classification (94) 2021 Voice and video stream detection (59) 2022 ✓Attack detection (87) 2022 ✓(csv) User interaction detection (90) 2022 UE classification (92) 2022 Pseudocode Slice selection (101) 2022 ✓Anomaly detection (103) 2022 Listings UE classification (97) 2023 UE classification (88) 2024 ✓ ✓ Attack detection (100) 2024 UE classification Ours 2025 ✓ ✓ UE classification Source: Created by the author (2025). Consequently, a network traffic dataset was created following the method in ( 101 ), as detailed in Subsection 5.1.1. In contrast to the references focused on classifying UE s, this work not only released the utilized dataset but also provided full access to the source code, as elaborated in Sections 4.4 and 4.5. Unlike reference ( 97 ), which employed MATLAB, the code was published using the FLOSS programming languages Python and Bash. Furthermore, consistent with ( 97 ), ( 101 ), and ( 103 ), the experimental setup utilized the free5GC and UERANSIM open-source projects, as described in Subsection 5.1.1. Building on the results found on the literature, which are characterized in Tables 3 and 4, the experiments conducted in this study, outlined in Chapter 4, include the inference phase that tests the models on unseen data, as detailed in Section 4.1. The 5G simulated environment (discussed in Section 4.2) was implemented using FAD , a FLOSS tool (described in Section 4.4) that automates the delivery of the software stack necessary to execute the packet capture experiment executed to create the dataset presented in Subsection 5.1.1. Additionally, as highlighted in Table 3, the evaluation of eleven supervised learning models, including AdaBoost and two custom ensemble learning models (Stacking and Voting) identified in the literature is performed, with results contained in Subsection 5.2.3. Supporting the open science characteristics verified in Table 4, the synthetic 5G network traffic capture dataset ( 40 ) created for this study was released in PCAP format, facilitating further experimentation and analysis. The source code is also available (29, 41) enabling future study and reuse. 54 3.4 SUMMARY This chapter delineated the methodology employed during the literature review process, detailed the relevant work, and encapsulated the main points discussed in the reviewed literature. To improve the reproducibility and reuse of the literature mapping results, the extracted records and its corresponding metadata are accessible on Zenodo ( 39 ). Following a comprehensive review, twelve papers were identified as pertinent to this study, and a comparative analysis of these works and the current research is presented from two distinct perspectives: ML and open science characteristics, as indicated in Tables 3 and 4. 55 4 METHODOLOGY The methodology outlined in this chapter is organized into two primary components: the ML pipeline, presented in Section 4.1, and the simulation environment, which will be detailed in Section 4.2. The datasets utilized during the training phase of the pipeline are introduced in Section 4.3. Section 4.4 introduces free5GC Auto Deploy, the FLOSS tool that facilitates the installation and configuration of the 5G simulation environment. The steps involved in implementing the NWDAF -based functionality are detailed in Section 4.5. 4.1 ML PIPELINE In accordance with the NWDAF definition and specification outlined in Subsection 2.1.3.3, a ML pipeline was developed to facilitate the study and effective utilization of ML techniques and network data within the context of 5G . This pipeline, illustrated in Figure 7, is divided into three primary stages: dataset processing, training, and inference. Figure 7 – Outline of the designed ML pipeline Model training Preprocessing Model performance evaluation Training dataset selection Data slicing Training stage Target files extraction Stratified K-fold Cross Validation Save pretrained model Dataset processing stage Feature extraction Feature encoding Data balancing and splitting Load pretrained model Inference dataset input Model inference Model performance evaluation Inference stage Data preparation Machine Learning phaseData phase (I) (II) (III) (IV) (V) Data labeling Source: Created by the author (2025). The first stage, dataset processing (depicted in area I), is initiated with the selection of datasets that will be utilized for model training in the subsequent phase. It may be performed manually by domain specialists to ensure relevance and alignment with the training objectives. An example of datasets suitable for selection in this step is presented in Section 4.3. Following this selection, relevant files that align with the training objectives are extracted from the datasets. The data slicing step is then performed to identify packet flows of interest and/or to reduce the volume of packets available for the next phase. If 62 4.5.2 Implementation Details and Execution As the primary programming language used for implementing the proposal is Python, the scikit-learn ( 73 ) libraries were selected to ensure seamless integration and efficient computation of performance metrics. In addition to the accuracy metric specified by the 3GPP ’s Release 18 ( 61 ), the implementation also evaluates precision, recall, F1-score, and ROC AUC score, as defined in Subsection 2.2.2 and in Appendix Y, respectively. The primary functionality based on the NWDAF specifications presented in Subsection 2.1.3.3 has been implemented in the ml.py and inference.py scripts. These scripts — archived in Appendices M and N — incorporate, respectively, the MTLF and AnLF logical functions detailed in Subsection 2.1.3.3. From the pipeline perspective, ml.py and inference.py scripts implement the training and inference stages, as discussed in Section 4.1. Figure 11 depicts the execution order of the aforementioned scripts. The solid arrows indicate the relationships between the scripts, illustrating how the output of one script serves as the input for the subsequent script, while the dashed lines denote optional steps that produce the statistical graphs presented in Subsection 5.1.2. Figure 11 – Implemented functionality workflow pcap_extract.sh dataset_CSV_characterization.py add_label_to_name.sh ml.py inference.py Basic execution flow Alternative flow stat-plotter.py box-plotter.py export_JSON.py Legend Source: Created by the author (2025). Drawing on prior experience ( 30 , 31 ), features with known low variability — due to their close association with stream characteristics, such as Hypertext Transport Protocol Secure ( HTTPS ) servers operating on port 443 by default — were excluded from the ml.py preprocessing step, as detailed in Table 6. Table 6 – Features removed prior to model training Packet_no Source_IP Destination_IP Frame_protocols IP_protocols Source_port Destination_port Source: Created by the author (2025). 63 Table 7 – Features utilized in model training Timestamp TCP_compl_data IP_flag_reserved_bit Time_delta TCP_compl_ack IP_flag_dont_fragment Frame_type TCP_compl_syn_ack IP_flag_more_fragments Frame_total_length TCP_compl_str Time To Live (TTL) Frame_header_length TCP_flags_bin TCP_header_length Frame_payload_length TCP_window_size Data_length TCP_completeness TCP_compl_syn QUIC_packet_length TCP_compl_reset TCP_flags_str QUIC_packet TCP_compl_fin TCP_window_size_scale Source: Created by the author (2025). Furthermore, based on the literature review results presented in Section 3.2, the impact of including not only features such as packet timestamp and its total length but also window lengths and several flags on model performance was assessed in the evaluation analyzed in Chapter 5. Consequently, the 27 features listed in Table 7 were employed in the model training implemented in the ml.py script, which also includes a data balancing function that utilizes SMOTE (141) to balance the training data. Finally, it is important to note that the current implementation of the NWDAF functionality is not fully integrated into the SBA as a NF . Therefore, the packet capture to create the PCAP files must be performed prior to inputting the data into the pipeline, and the classification results were not utilized by any other NF s. The source code for the implemented functionality has been made available on GitHub ( 41 ) under a copyleft license, allowing for study and reuse. Instructions for reproducing the implementation with alternative datasets are also provided. 4.5.3 Traffic Generator As part of the implementation detailed in Subsection 4.5.2 and the traffic generator proposed in Section 4.2, a simple traffic generator has been implemented. This generator consists of three scripts available in Appendix O: play-video.sh , udp-server.sh , and udp-client.sh. The play-video.sh script is capable of playing a playlist of stored YouTube videos or streaming a live broadcast from a Korean news channel on Naver TV (formerly Naver NOW), depending on the selected mode. The udp-client.sh script should be executed on the UE , while the udp-server.sh can be executed on the 5GC or on another server on the internet. The two UDP scripts facilitate the transmission of UDP packets in two configurations: at a fixed rate or within a probability-based interval range. In the fixed rate, it is possible to send packets in 100 Packets per Second ( PPS ) or a custom rate, as suggested in ( 106 ). The interval range configuration is implemented based on the behavior 64 of IoT devices, as described in ( 123 ). Additional details, including the source code and usage instructions for the traffic generator, are available in the GitHub repository (41). Due to the necessity, as highlighted in Subsection 4.5.2, of generating the PCAP files prior to pipeline execution, the traffic generator was run in an instance of the simulation environment described in Section 4.2. The packet capture experiments, conducted using the generator, to create the inference dataset presented in Subsection 5.1.1 were based on the dataset descriptions provided in Section 4.3. Notably, the generator simulates network behavior and enables not only creating PCAP datasets, but also using the traffic in tasks such as network performance tests. 4.6 SUMMARY This chapter presented the methodology containing a ML pipeline and a 5G simulation environment, forming the basis for the experimental results in Chapter 5. The dataset survey conducted to help selecting the datasets used in the model training was outlined. The two datasets “5G Traffic Datasets” and “5G Campus Networks: Measurement Traces” selected for the model training were presented. Finally, the implementation of the environment, NWDAF-based functionality, and traffic generator were also detailed. 65 5 RESULTS AND DISCUSSION This chapter presents the results obtained from the research and its corresponding discussions. Initially, Section 5.1 provides an overview of the outcomes associated with the created network dataset. Subsequently, Section 5.2 introduces the ML model experimental results along with relevant analyses. Finally, Section 5.3 includes discussions focused on the evaluation of model performance. 5.1 NETWORK DATASET Based on the analyses that underscore the necessity of a PCAP dataset for UE classification, as presented in Section 3.3, the pipeline requirements for training and inference datasets outlined in Section 4.1, and the findings of the dataset survey presented in Section 4.3, a network packet capture dataset has been created, as detailed in Subsection 5.1.1. Furthermore, Subsection 5.1.2 contains the frequency analyses of two characteristics — Protocol Label and Frame Length — of both training and inference datasets. Additionally, Section 5.1.3 presents the results of statistical hypothesis tests executed to compare the training and inference datasets. These datasets correspond to the dataset introduced in Section 4.3 and the newly created PCAP dataset detailed in Subsection 5.1.1, respectively. 5.1.1 Packet Capture Dataset The results in ( 59 ) indicate that using only GTP-U packets for multi-class classification can reduce model performance by up to 36.7% compared to using actual IP packets. In their work, the MedBIoT dataset ( 96 ), which contains captures of both Wi-Fi and Ethernet traffic, was replayed in a simulated 5G network to generate new network traffic, including the IP traffic captured in the UPF. Consequently, by drawing on prior experience ( 30 , 31 ), the convenience of having a virtual network interface readily available for packet capture, and the capturing methodology outlined in ( 59 ), the capture was conducted within the UPF . This UPF instance operated within a 5GC instance deployed in a simulated setup using the FAD tool, as described in Section 4.4. The simulated environment adhered to the configuration suggested in Section 4.2, utilizing UERANSIM as the UE and RAN simulator, and free5GC for the 5GC , with internet access to execute the traffic generator presented in Subsection 4.5.3 for the packet capture experiment. The packet capture was performed by executing Wireshark’s command-line utility, tshark ( 124 ), on the UPF ’s interface while the virtual UE executed tasks that replicated the experimental conditions described by the creators of the training datasets ( 110 ) and ( 114 ) regarding the data selected on the dataset processing stage for model trai- 66 ning. This process resulted in a PCAP dataset of simulated 5G traffic comprised by four PCAP files: youtube-1M-1080p.pcap , naver-tv-1M.pcap , udp-100pps.pcap , and udp-nc-traffic-1k.pcap. The files youtube-1M-1080p.pcap and naver-tv-1M.pcap were created using the play-video.sh script from the traffic generator, representing the eMBB and URLLC service classes, respectively, with each containing approximately 1 million packets. The files udp-100pps.pcap and udp-nc-traffic-1k.pcap were created using the udp-server.sh and udp-client.sh scripts from the traffic generator presented in Subsection 4.5.3. The server operated on the same Virtual Machine ( VM ) as free5GC, with the first file containing approximately 1 million packets generated by simulating an UDP burst traffic of 100 PPS — as described in ( 106 ) — and the second containing approximately 1 thousand UDP packets generated by a probabilistic interval range — as detailed in (123). The dataset described above, used in the experimental inference phase, along with the data slices from the datasets ( 110 ) and ( 114 ) utilized to construct the training dataset, are publicly accessible on Zenodo ( 40 ). Additional details and reproduction instructions for the traffic generation experiment are available in the GitHub repository (41). 5.1.2 Frequency Analysis To improve the understanding of the created inference dataset, facilitate comparisons with the training dataset, and establish a foundation for the discussion in Section 5.3, a univariate analysis was conducted as part of the Exploratory Data Analysis ( EDA ) process, as recommended in ( 75 ). This analysis focused on two features from the PCAP files: Protocol Label (Section 5.1.2.1) and Frame Length (Section 5.1.2.2), which were selected due to their significant capacity of describing network streams. 5.1.2.1 Protocol Label One analyzed feature concerns the protocol labels ( _ws.col.protocol ) assigned to each captured packet, which reflect the highest layer protocol detected by Wireshark. Their frequency of occurrence is illustrated in Figures 12–17. In the eMBB traffic, depicted in Figures 12 and 13, the QUIC protocol predominates, comprising 98.8% of the training dataset and 86.4% of the inference dataset. This prevalence is anticipated, as QUIC is the primary video transmission protocol utilized by YouTube, the platform generating the traffic. The video content itself constitutes the majority of the traffic due to its larger size compared to other web elements on a video-sharing platform. Other protocols, such as TCP , TLS v1.3, TLS v1.2, Secure Sockets Layer ( SSL ), Hypertext Transport Protocol ( HTTP ), and TLS v1, exhibit similar occurrence rates in both datasets. Notably, the training dataset includes 0.1% of Domain Name System ( DNS ) packets, likely due to the methodology employed by its authors in ( 110 ), which involved capturing packets 67 Figure 12 – Protocol label occurrence frequency in eMBB training dataset QUIC TCP TLSv1.3 DNS TLSv1.2 SSL HTTP TLSv1 Protocol Label 101 102 103 104 105 106 107 Frequency (Logarithmic Scale) 10640048 (98.8%) 107363 (1.0%) 15004 (0.1%) 11777 (0.1%) 442 (0.0%) 50 (0.0%) 4 (0.0%) 4 (0.0%) Youtube_cellular_training._ws.col.protocol Source: Created by the author (2025). Figure 13 – Protocol label occurrence frequency in eMBB inference dataset QUIC PNIO TCP TLSv1.3 TLSv1.2 SSL OCSP HTTP TLSv1 Protocol Label 101 102 103 104 105 106 Frequency (Logarithmic Scale) 867859 (86.4%) 132505 (13.2%) 2601 (0.3%) 837 (0.1%) 441 (0.0%) 117 (0.0%) 86 (0.0%) 10 (0.0%) 8 (0.0%) youtube-1M-1080p_inference._ws.col.protocol Source: Created by the author (2025). from the UE using PCAPdroid. This may have facilitated the capture of DNS queries that were mostly aimed at resolving Google domains, consistent with the behavior of an Android Operating System ( OS ) device streaming YouTube videos. The absence of this 68 Figure 14 – Protocol label occurrence frequency in URLLC training dataset TCP TLSv1.3 TLSv1.2 HTTP TLSv1 HTTP/JSON DNS SSL SSLv2 Protocol Label 101 102 103 104 105 106 107 Frequency (Logarithmic Scale) 7775179 (75.9%) 2403918 (23.5%) 61043 (0.6%) 3970 (0.0%) 2071 (0.0%) 1973 (0.0%) 640 (0.0%) 160 (0.0%) 4 (0.0%) naver5g3-10M_training._ws.col.protocol Source: Created by the author (2025). Figure 15 – Protocol label occurrence frequency in URLLC inference dataset TCP TLSv1.3 TLSv1.2 SSLv2 SSL TCP, HiPerConTracer H1 ICMPv6 Protocol Label 100 101 102 103 104 105 106 Frequency (Logarithmic Scale) 589802 (56.6%) 437222 (41.9%) 13400 (1.3%) 2167 (0.2%) 323 (0.0%) 2 (0.0%) 1 (0.0%) 1 (0.0%) naver-tv-1M_inference._ws.col.protocol Source: Created by the author (2025). traffic in the inference dataset may be attributed to differences in the capture environment, as the inference capture was conducted in the 5GC with the UE being simulated in a Ubuntu Linux OS VM . Consequently, this traffic may have been encapsulated by other 69 protocols (e.g., DNS over TLS ( DoT ) or DNS over HTTPS ( DoH )), leaked through the VM ’s other network interface, or not captured due to the relative limited capture duration of approximately 32 minutes, which was sufficient to generate 1 million packets while the video was played and the queries were cached. A combination of these factors is also plausible. In the inference dataset, notable labels include Online Certificate Status Protocol ( OCSP ) and PROFINET IO ( PNIO ). OCSP is utilized to verify the revocation status of X.509 HTTPS -related certificates and is enabled by default in Mozilla Firefox, the browser used for the eMBB experiment. PNIO facilitates data exchange between Ethernet-based field devices in IP -based protocols designed for Programmable Logic Controller ( PLC ) communication ( 125 ). The packets associated with this protocol were likely encrypted and used for communication with a Google-owned IP address, suggesting potential control synchronization, fingerprinting, or reporting activities. As illustrated in Figures 14 and 15, the predominant protocol labels in the URLLC traffic for both training and inference datasets were TCP (75.9%/56.6%), Transport Layer Security ( TLS )v1.3 (23.5%/41.9%), and TLS v1.2 (0.6%/1.3%). This distribution may be attributed to the operational characteristics of the Naver TV live stream player, which transmits its live video content via a combination of TCP and TLS v1.3. The absolute number of SSL packets increased in the inference dataset compared to the training dataset (323 vs. 160 packets), although it still accounted for less than 0.1% of the total share. Conversely, SSL v2 was captured only 4 times in the training dataset but reached 2167 packets (0.2%) in the inference dataset. Comparing the counts of SSL and SSL v2 with those of HTTP and HTTP / JSON in the training dataset suggests that some clear-text HTTP traffic may have been encrypted using SSL / SSL v2, as one method of securing HTTP payloads is through SSL . The higher proportions of TLS v1.3 and TLS v1.2 may also relate to HTTP protection. These patterns may have arisen from the capture environment (in UE vs. in the 5GC ), as capturing unencrypted traffic is generally more feasible on the transmitting device. Similar to the eMBB experiment, the absence of DNS traffic in the inference dataset is believed to be due to analogous factors. Lastly, the inference dataset highlights three additional protocols: HiPerConTracer, H1, and ICMP v6. HiPerConTracer is associated with a tool that analyzes and diagnoses network connectivity issues with high precision and efficiency ( 126 ). H1 represents the SINEC H1 protocol, which is related to PLC communication for controlling Siemens industrial devices ( 127 ). The three packets corresponding to these protocols originated from a South Korean IP , likely linked to the Naver TV service. The ICMP v6 packet was a router solicitation unicast transmission sent to all routers within the Local Area Network ( LAN ), likely generated automatically by network devices, as the environment included a switch connecting the host to the internet. According to the description in ( 114 ) and the corresponding PCAP s, the predominant packet protocol label in the mMTC traffic was UDP , which accounted for 100% of the share in the training dataset. In the inference dataset, as illustrated in Figures 16 and 17, 70 Figure 16 – Protocol label occurrence frequency in mMTC inference dataset (probabilistic) UDP ICMPv6 Protocol Label 101 102 103 Frequency (Logarithmic Scale) 996 (98.9%) 11 (1.1%) udp-nc-traffic-1k_inference._ws.col.protocol Source: Created by the author (2025). Figure 17 – Protocol label occurrence frequency in mMTC inference dataset (burst) UDP ICMPv6 Protocol Label 101 102 103 104 105 106 Frequency (Logarithmic Scale) 1069967 (100.0%) 6 (0.0%) udp-100pps_inference._ws.col.protocol Source: Created by the author (2025). besides the prevalence of UDP packets, a small number (11 packets in the probabilistic capture and 6 packets in the 100 PPS capture) of ICMP v6 unicast packets were observed, likely generated automatically by the network switch present in the capture environment. 71 The observed differences in label occurrence between the training and inference datasets can be attributed to the distinct environments in which they were generated. The training dataset, as detailed in Section 4.3, comprised captures from physical network interfaces, whereas the inference dataset, outlined in Subsection 5.1.1, collected packets from the UPF virtual network interface within a 5GC deployed in a simulated environment. 5.1.2.2 Frame Length The second feature analyzed was packet length ( frame.len ). As indicated by the varying protocol types identified in Subsection 5.1.2.1 and given that the PCAP files contain various length measurements, including payload length, header length, and total packet length, the total packet length was selected for analysis to facilitate comparisons among the different captures. The results of this analysis are presented in Figures 18–21. In the eMBB traffic, the majority of captured packets measured 1278 and 1280 bytes, accounting for approximately 87% of the training dataset and 96% of the inference dataset. This observation is further corroborated by the mode, which is highlighted in purple in both Figures 18 and 19. This pattern can be attributed to the video content being transmitted via YouTube, which aligns with the predominance of the QUIC protocol in both datasets (as discussed in Subsection 5.1.2.1 ). Only a small fraction of packets exceeded 1280 bytes (0.8% in the training dataset and 0.1% in the inference dataset), and none of these utilized QUIC . This limitation may stem from the nature of QUIC , which cannot be fragmented ( 128 ) and thus adheres to a conservative Maximum Transfer Unit ( MTU ) value, as suggested in ( 129 ). In the inference dataset, the global MTU was 1400 bytes due to constraints on the simulated 5G NR interface, explaining the absence of larger packets in Figure 19, which contrasts with the training dataset. Additionally, the overall distribution of packet lengths differs between the two sets. As illustrated in Figure 18 – Frame length distribution in eMBB training dataset 0 50 100150200250300350400450500550600650700750800850900950 1000 1050 1100 1150 1200 1250 1300 1350 1400 1450 1500 Packet Length (bytes) 100 101 102 103 104 105 106 107 Frequency (Logarithmic Scale) Mean: 713.44 Median: 708.50 Mode: 1278 Youtube_cellular_training.frame.len Source: Created by the author (2025). 78 and 20.89% for RF . This prominence is supported by the fact that, among the available features, Time_delta exhibited the highest variability compared to the features with statistically significant variations in their distribution, as seen in Subsection 5.1.3. Table 10 – Average feature importance for DT Feature Name Weight Time_delta 0.5111874 TCP_window_size 0.4868625 Frame_total_length 0.0009336 Frame_payload_length 0.0005355 TCP_header_length 0.0000103 TCP_completeness 0.0000050 Source: Created by the author (2025). Table 10 indicates that the next significant feature for DT was TCP_window_size with 48.69%. The remaining features — Frame_total_length , Frame_payload_length , TCP_header_length , and TCP_completeness — accounted for just approximately 0.15% of the weight, while 20 features were excluded by the model. This outcome is consistent with the available features outlined in Subsection 4.5.1 and the hyperparameter tuning discussed in Subsection 5.2.1. As noted in Subsection 5.2.1, the limited depth of the DT directly affected the weight distribution, as each decision or node split relies on a feature, and the number of splits correlates with the branch depth. Table 11 – Average feature importance for RF Feature Name Weight Time_delta 0.2088668 QUIC_packet_length 0.1620190 TCP_window_size 0.1387653 Frame_total_length 0.1321380 TCP_completeness 0.0986426 TCP_header_length 0.0903932 Frame_payload_length 0.0834209 TCP_window_size_scale 0.0808604 Timestamp 0.0048154 Source: Created by the author (2025). As shown in Table 11, the RF model selected a greater number of features (9 compared to 6 in DT ). The top three features included Time_delta (20.89%), QUIC_packet_len gth (16.20%) and TCP_window_size (13.88%), time and length-related packet features. Additionally, Frame_total_length (13.21%), TCP_completeness (9.86%), TCP_header_len gth (9.04%), Frame_payload_length (8.34%), and TCP_window_size_scale (8.09%) received a similar importance demonstrating the prevalence of length-related features. 79 Compared to the mentioned features, Timestamp (0.48%) received considerably less importance, probably due to the weight assigned to Time_delta , with the other 17 features discarded by the model. This more distributed weight allocation aligns with the RF model algorithm, which employs multiple DT s and feature bagging to mitigate bias and overfitting (139, 140). 5.2.3 Model Performance The experimental step can be simplified by testing various ML algorithms through their libraries, with the evaluation of the most suitable options left to domain specialists or based on the results achieved during the experimentation. Effective model performance evaluation is a crucial component of ML pipelines, as it serves as a benchmarking mechanism and helps in determining the reliability and generalization levels of developed models in real-world applications. The specification ( 61 ) only requires model accuracy as a performance metric, which is measured by comparing inference results against ground truth data. Following the pipeline of Section 4.1, accuracy and the extra four metrics described in Subsection 2.2.2 were used to evaluate the performance of the trained models in the training (Subsection 5.2.3.1 ) and inference (Subsection 5.2.3.2) stages. The raw model performance results detailed on the following sections are archived in Appendix S and on Zenodo (39). 5.2.3.1 Training Out of a total of 22,023,650 samples in the training dataset outlined in Section 4.3, 70% (15,416,555 samples) were utilized for model training, while the remaining 30% (6,607,095 samples) were reserved for testing. The results of the F1-score metric of the testing are detailed in Table 12. The “average” metric refers to the average of all classes, with classes 0, 1 and 2 representing eMBB, URLLC, and mMTC, respectively. Considering the average performance of three executions, all models achieved performance metrics exceeding 99%. These high performance results were anticipated due to the substantial volume of training data available. LR is commonly used as a baseline model, so it was included in the implementation. However, when compared to the other linear model (Linear SVC ), it exhibited the lowest performance results. Concerning the average F1-score displayed on Table 12, the manually calibrated and ensemble models closely surpassed the linear models with F1-scores between 99.61% (Voting and DT ) and approximately 99.8% (AdaBoost and Stacking). MLP and HGB exhibited 99.96% and 99.98% F1-score performance, while the remaining models ( XGB , LGBM and RF ) achieved more than 99.99%. Based on these results, along with those derived from the Inference presented in Section 5.2.3.2 , it is evident that the models manifested signs of overfitting in relation to the training data. The Appendix R contains the confusion matrices of the test 80 Table 12 – Training average F1-score performance results per class Model Class 0 F1-score Class 1 F1-score Class 2 F1-score Average F1-score RF 0.99999374 0.99999342 1.0 0.99999576 LGBM 0.99999337 0.99999287 0.99999985 0.99999541 XGB 0.99998299 0.99998203 0.99999993 0.99998842 HGB 0.99983398 0.99982529 0.99999985 0.99988738 MLP 0.99948346 0.99946733 0.99999035 0.99965001 Stacking 0.99707863 0.99694395 0.99999690 0.99802409 AdaBoost 0.99695374 0.99685454 0.99994667 0.99793582 DT 0.99424371 0.99402167 0.99999529 0.99612089 Voting 0.99421445 0.99403070 0.99995764 0.99610113 SVC 0.99419067 0.99399588 0.99996766 0.99608524 LR 0.99363267 0.99399833 0.99940700 0.99570696 Source: Created by the author (2025). step and illustrate that the majority of FP s and FN s occur between eMBB and URLLC samples. This phenomenon may be attributed to the similarities in the characteristics of the network services generating these types of traffic, as described in Subsection 4.5.3, and further discussed in Subsection 5.1.2. Additionally, the Appendix S contains the tables with the all the results from the performance metrics detailed in Subsection 2.2.2. Another evaluation perspective is the performance of various models based on their training times, as presented in Table 13. The table includes three key measurements for each of the eleven models: training time, disk write time, and total training time. Training time refers to the duration required to train each model, while disk write time indicates the time spent to save the trained model to disk. The total time is the sum of these two measurements, providing insight into the overall efficiency of model deployment, particularly concerning in dynamic environments that necessitate frequent retraining. Among the models analyzed in three runs, DT exhibited the best training time at approximately 23 seconds, and a disk write time of 0.28 Milliseconds (ms). LR followed with the second-best training time of around 31 seconds and a disk write time of 0.49 ms . LGBM ranked third, requiring approximately 40 seconds for training and 4.6 ms for disk writing. Notably, SVC demonstrated the highest efficiency in disk write time, yet it ranked sixth in training time. In contrast, DT , a more complex model than LR , exhibited superior training efficiency due to the parameter tuning described in Subsection 5.2.1, which limited tree depth and resulted in a smaller model occupying only 3.0 Kilobytes (kB) on disk. Linear SVC and LR also had minimal disk space requirements, at 1.8 kB and 1.9 kB , respectively. Conversely, RF required over 9 seconds for disk writing, consuming 9.5 Megabytes (MB). The training time correlated with model complexity, with ensemble models being the slowest; RF ’s prolonged duration stemmed from insufficient hyperparameter tuning, based 81 Table 13 – Model average training time Model Average Training Time (ms) Average Disk Write Time (ms) Total Average Training Time (ms) DT 22984.7205 0.2799 22985.0003 LR 31293.6348 0.4580 31294.0927 LGBM 39541.0260 4.5923 39545.6183 XGB 89135.0785 3.4888 89138.5673 HGB 115260.8451 3.7594 115264.6045 SVC 128639.4635 0.2562 128639.7197 MLP 431639.5728 0.5431 431640.1159 AdaBoost 487523.4267 1.0677 487524.4944 Voting 523247.1393 1.1789 523248.3183 RF 719960.1841 9.2561 719969.4402 Stacking 3366891.2883 1.4558 3366892.7441 Source: Created by the author (2025). on the tree visualizations available in ( 41 ), which revealed considerably deeper trees. This contrast highlights the trade-offs between training efficiency and disk performance across different models. 5.2.3.2 Inference To further validate the trained models, the inference step was executed to assess their performance in a real-world scenario using previously unseen data. The results of the inference process, including accuracy, weighted recall (as defined in Appendix X), and F1-score, are presented in Tables 14–17. Precision was consistently 100% across all inferences and is therefore omitted to conserve space. The number of samples used for inference was 1,004,464 for eMBB , 1,042,918 for URLLC , 1,069,973 for mMTC (burst), and 1,007 for mMTC (probabilistic) classes. The dataset used for this process was created as described in Subsection 5.1.1. In the eMBB class (results shown in Table 14), all models, as illustrated in the confusion matrices in Appendix T, achieved accuracy, recall, and F1-scores exceeding 99%. This performance aligns with expectations based on the results presented in Subsection 5.2.3.1 , which indicated overfitting to the training data. As shown in Table 15, the URLLC class, the SVC , LR , and DT models achieved the highest F1-scores in the URLLC class, exceeding 99%. The Voting model scored approximately 98.87%, while the other models exhibited subpar performance due to the overfitting. Despite this overfitting, the linear models effectively identified URLLC packets, whereas DT and Voting models benefited from the tuning described in Subsection 5.2.1. Given the experimental context outlined in Subsection 5.1.1 and the results in Subsec- 82 Table 14 – eMBB inference performance results Model Accuracy Recall F1-score RF 0.99839616 0.99839616 0.99919744 LGBM 0.99829660 0.99829660 0.99914758 XGB 0.99821497 0.99821497 0.99910669 HGB 0.99817614 0.99817614 0.99908724 MLP 0.99770027 0.99770027 0.99884881 AdaBoost 0.99750613 0.99750613 0.99875151 Stacking 0.99653845 0.99653845 0.99826623 Voting 0.99598891 0.99598891 0.99799042 DT 0.99598194 0.99598194 0.99798692 SVC 0.99591822 0.99591822 0.99795494 LR 0.99591723 0.99591723 0.99795444 Source: Created by the author (2025). Table 15 – URLLC inference performance results Model Accuracy Recall F1-score SVC 0.99999041 0.99999041 0.99999521 LR 0.99524891 0.99524891 0.99761880 DT 0.99421335 0.99421335 0.99709828 Voting 0.97760035 0.97760035 0.98867332 Stacking 0.27436193 0.27436193 0.43058715 MLP 0.13418696 0.13418696 0.23662230 LGBM 0.13289731 0.13289731 0.23461493 HGB 0.13191449 0.13191449 0.23308208 XGB 0.11727768 0.11727768 0.20993470 RF 0.01483722 0.01483722 0.02924058 AdaBoost 0.00000096 0.00000096 0.00000192 Source: Created by the author (2025). tion 5.2.3.1, it can be inferred that SVC , LR , DT , and Voting demonstrated superior generalization of the features learned compared to the other models. The matrices in Appendix U confirm that the majority of misclassifications were associated with the eMBB class, which is attributed to the operational similarities in the services generating network traffic for theses classes, as discussed in Subsections 5.1.2.2 and 5.2.2. The results in Tables 16 and 17 indicate that even when the mMTC traffic similar to the training data (i.e., burst UDP traffic) was applied during inference, most models still failed to accurately classify packets. Notably, AdaBoost achieved an F1-score exceeding 99.99% for classifying mMTC burst packets. However, due to its subpar performance in the URLLC class (as shown in Table 15), it can be concluded that, compared to the other models, AdaBoost overfitted on the eMBB and mMTC data rather than on the eMBB and URLLC classes. As discussed in Subsection 5.1.3, this limitation arises from 83 Table 16 – mMTC probabilistic inference performance results Model Accuracy Recall F1-score AdaBoost 0.01390268 0.01390268 0.02742409 Voting 0.01290963 0.01290963 0.02549020 DT 0.01092354 0.01092354 0.02161100 HGB 0.01092354 0.01092354 0.02161100 LGBM 0.01092354 0.01092354 0.02161100 RF 0.01092354 0.01092354 0.02161100 XGB 0.01092354 0.01092354 0.02161100 MLP 0.01092354 0.01092354 0.02161100 Stacking 0.01092354 0.01092354 0.02161100 SVC 0.01092354 0.01092354 0.02161100 LR 0.00297915 0.00297915 0.00594059 Source: Created by the author (2025). Table 17 – mMTC burst inference performance results Model Accuracy Recall F1-score AdaBoost 0.99998878 0.99998878 0.99999439 LR 0.00003830 0.00003830 0.00007660 Voting 0.00002990 0.00002990 0.00005980 RF 0.00000561 0.00000561 0.00001120 XGB 0.00000561 0.00000561 0.00001120 DT 0.00000561 0.00000561 0.00001120 HGB 0.00000561 0.00000561 0.00001120 LGBM 0.00000561 0.00000561 0.00001120 SVC 0.00000561 0.00000561 0.00001120 MLP 0.00000561 0.00000561 0.00001120 Stacking 0.00000561 0.00000561 0.00001120 Source: Created by the author (2025). significant differences between the mMTC data in the training and inference datasets. The confusion matrices in Appendices V and W reveal that, with the exception of the Linear SVC and Stacking models — both of which misclassified a substantial number of mMTC packets as URLLC — other models incorrectly classified mMTC packets as eMBB traffic in both burst and probabilistic scenarios. This misclassification persisted despite findings in Subsection 5.1.2.2 , which demonstrated that mMTC traffic substantially differentiated itself based on packet length variation, and Subsection 5.2.2, which highlights the models’ focus on the length-related features. Additionally, Appendix X complements the definitions in Subsection 2.2.2 and validates the results in this subsection by comparing not only different metrics of a given model but also the metrics of different models, explaining how they might converge to similar values. 84 Another aspect of the inference process is the time required for classification. Measuring this metric is crucial in environments with a high number of devices, where numerous classifications must be performed. The inference time was measured, with the average results from three runs displayed in Tables 18 and 19. These tables include classification time, which refers to the duration needed to classify the inference data, and total inference time, which encompasses the entire process of generating an inference response (loading the model from disk, preparing the data for classification — such as storing and then removing labels from the actual data — executing the classification, and calculating performance results). Table 18 – eMBB, URLLC, and mMTC burst average 3 runs inference time Model Average Classification Time (ms) Model Total Average Inference Time (ms) DT 29.1556 DT 382.5519 LR 43.7871 SVC 421.5565 SVC 45.9439 LR 443.8588 XGB 262.5967 MLP 844.9059 MLP 470.9609 XGB 1085.5019 LGBM 751.0224 LGBM 1212.5192 RF 1148.6976 RF 1528.0171 AdaBoost 1666.1416 AdaBoost 2020.9529 Stacking 1803.3771 Stacking 2180.9692 Voting 1850.9546 Voting 2208.9829 HGB 2003.1748 HGB 2376.4723 Source: Created by the author (2025). Table 18 contains the inference time results for the classes with approximately 1 million packets. These classes were grouped due to their similar scale. On average, DT was the fastest model, achieving approximately 29 ms for classification and 383 ms for total inference time. It was followed by the linear models, LR and SVC , with classification times of approximately 44/444 ms and 46/422 ms , respectively. Other models required significantly more time for packet classification: XGB took approximately 263 ms for classification and 1,086 ms in total; MLP required about 471/845 ms ; LGBM approximately 751/1,213 ms ; RF approximately 1,148/1,528 ms ; AdaBoost approximately 1,666/2,021 ms ; Stacking approximately 1,803/2,181 ms ; Voting approximately 1,850/2,209 ms ; and HGB approximately 2,003/2,376 ms . These results align with the ones observed during model training (Section 5.2.3.1 ), indicating that more complex models require more time for classification and related tasks. The custom ensemble models (Stacking and Voting), exhibited poorer time performance due to the combination of multiple models. DT outperformed the linear models ( SVC and LR ) due to the parameter tuning described in Subsection 5.2.1, which limited tree size. 85 Table 19 – mMTC probabilistic average 3 runs inference time Model Average Classification Time (ms) Model Total Average Inference Time (ms) DT 0.7357 DT 1.7479 LR 0.7566 SVC 1.8929 SVC 0.7627 LR 2.0565 MLP 1.0639 MLP 3.1155 LGBM 1.9073 LGBM 5.1222 HGB 4.5908 HGB 7.9354 XGB 5.2582 AdaBoost 8.8221 RF 5.8492 XGB 10.1210 AdaBoost 7.0638 Voting 10.4994 Stacking 8.5395 Stacking 10.5768 Voting 8.6442 RF 11.3975 Source: Created by the author (2025). In the mMTC class with probabilistic traffic, Table 19 indicates that as the number of packets to be classified decreased, the performance ranking shifted, and the time differences among the models were significantly reduced. The fastest model in this scenario was DT , with approximately 0.74 ms for classification and 1.75 ms in total, closely followed by LR at approximately 0.76 ms for classification and 2.06 ms in total. Linear SVC ranked third with approximately 0.76 ms for classification and 1.89 ms in total. The other models performed as follows: MLP (approximately 1.06/3.12 ms ), LGBM (approximately 1.90/5.12 ms ), HGB (approximately 4.59/7.94 ms ), XGB (approximately 5.26/10.12 ms ), RF (approximately 5.85/11.40 ms ), AdaBoost (approximately 7.06/8.82 ms ), Stacking (approximately 8.54/10.58 ms ), and Voting (approximately 8.64/10.50 ms ). Despite the changes in ranking, the trend of DT being followed by the linear models, with ensemble models occupying the last positions, remained consistent. Notably, total inference time was influenced by the implementation of statistical measurements, as detailed in Appendix N. In terms of measured times, DT consistently emerged as the fastest model for classification, outperforming the linear models ( LR and SVC ), which ranked among the top three classification models. XGB maintained a consistent fourth place in classification time during the inferences with a larger number of packets. In contrast, HGB exhibited the poorest classification and total inference times across all inferences with 1 million packets, while the ensemble models (AdaBoost, Stacking and Voting) ranked last due to the added complexity of combining multiple models. 86 5.2.3.3 Cross Validation To deeply evaluate the results from the test phase displayed in Subsection 5.2.3.1 and create extra data to compare with the inference results in Subsection 5.2.3.2, a cross validation was performed. The cross validation was implemented using the Stratified K-fold method. Table 20 contains the average performance (including precision, recall, and F1-score) and standard deviation results obtained using 10 folds (i.e., K = 10 with 90/10% train/test splits). Table 20 – Cross validation average performance results of the test phase Model Precision Recall F1-score LGBM 0.99892292 (±0.00148) 0.99893171 (±0.00146) 0.99845948 (±0.00212) RF 0.99855035 (±0.00228) 0.99852330 (±0.00239) 0.99789003 (±0.00337) XGB 0.99754671 (±0.00442) 0.99753637 (±0.00442) 0.99642809 (±0.00646) AdaBoost 0.99698574 (±0.00429) 0.99664981 (±0.00461) 0.99631914 (±0.00632) HGB 0.99704642 (±0.00449) 0.99707358 (±0.00450) 0.99577591 (±0.00659) MLP 0.99621339 (±0.00634) 0.99628071 (±0.00636) 0.99455854 (±0.00935) DT 0.99613499 (±0.00493) 0.99617142 (±0.00490) 0.99444911 (±0.00720) SVC 0.99596533 (±0.00658) 0.99594951 (±0.00653) 0.99433717 (±0.00968) LR 0.99554671 (±0.00645) 0.99358971 (±0.00669) 0.99402424 (±0.00954) Voting 0.99568200 (±0.00641) 0.99558635 (±0.00633) 0.99389705 (±0.00945) Stacking 0.99544737 (±0.00629) 0.99527674 (±0.00619) 0.99341005 (±0.00923) Source: Created by the author (2025). Contrasting the results from the test phase (outlined in Subsection 5.2.3.1 ), the Voting and Stacking models exhibited the lowest performance, achieving F1-scores of approximately 99.34% and 99.39%, respectively. Consistent with the test phase results, the linear models ( LR and SVC ) achieved F1-scores of approximately 99.40% and 99.44%, respectively. Furthermore, LGBM , RF and XGB maintained their position as the top three best models, attaining F1-scores of approximately 99.85%, 99.79%, and 99.64%, respectively. It is noteworthy that all models consistently demonstrated performance levels exceeding 99% across cross validation, with with standard deviations below 1%. This behavior along with the results previously analyzed in Subsections 5.2.3.1 (Training) and 5.2.3.2 (Inference), indicates a model overfitting to the training data. To further elaborate on the results of the training phase presented in Subsection 5.2.3.1 , the training and classification times of each model were also measured during the cross validation, with their average and standard deviation summarized in Table 21. The ranking remained fairly consistent with the training results, with DT and LR identified as the fastest models, while Stacking was the slowest. In comparison to the inference results discussed in Subsection 5.2.3.2, the classifier ranking also remained consistent, with DT again recognized as the fastest model, followed by the linear models, while Voting was the slowest. Thus, even though the amount of data used to train and test the models 87 Table 21 – Cross validation average time results of the test phase Model Average Train Time (s) Model Average Classification Time (s) DT 41.7879 (±4.1971) DT 0.5090 (±0.4237) LR 125.7473 (±7.2257) LR 0.5838 (±0.3461) SVC 340.4176 (±57.1157) SVC 0.5946 (±0.4041) XGB 616.3800 (±22.4426) MLP 1.7114 (±18.1521) HGB 752.7511 (±80.6718) XGB 5.4557 (±4.9903) MLP 885.5553 (±183.9418) RF 5.9906 (±4.7568) LGBM 1310.9774 (±13.6833) Stacking 12.7450 (±10.2109) AdaBoost 1335.3539 (±109.4027) LGBM 14.2706 (±12.1558) Voting 1462.3592 (±71.7484) HGB 18.7169 (±24.1268) RF 1719.6241 (±85.3389) AdaBoost 23.5223 (±0.9397) Stacking 9078.8962 (±361.6314) Voting 24.6726 (±25.0216) Source: Created by the author (2025). has changed (90%/10% in the cross validation compared to 70%/30% in the training), the results from the cross validation are relatively consistent with those obtained from both the training and inference phases, corroborating that the models suffered overfitting. 5.3 DISCUSSION The literature review presented in Section 3.2 indicates that classification techniques are prevalent in the context of 5G networks. However, as noted in ( 103 ) and the reviewed literature, the application of classifiers to categorize devices across various 5G service axes remains an unresolved issue. Furthermore, as demonstrated in ( 90 ) and ( 100 ), classification tasks — such as identifying the appropriate service axis for a given UE — may be too complex for a single ML model to handle effectively. In this context, following the suggestion of the authors of ( 90 ) to employ four models in a HAC and a voting system could enhance classification performance, and the supervised learning models found on the literature review, the ensemble models AdaBoost, Stacking and Voting were implemented and tested. The findings in Subsection 5.2.3, particularly those from Subsection 5.2.3.2, support the notion that a model may excel in detecting one class while struggling with others. Despite the application of multiple models, the mMTC class could not be accurately detected. This highlights the necessity for further exploration of feature selection methods that specifically target the identification of sparse data patterns in mMTC scenarios. This necessity is reinforced by the results in Subsections 5.1.3 and 5.2.3, which indicate that the eMBB and URLLC datasets exhibit statistically different distributions, while the mMTC dataset does not; nevertheless, the models successfully identified eMBB and URLLC packets. Additionally, ( 100 ) suggests investigating time series data generated 94 12 LIMANI, Xhulio; TROCH, Arno; CHEN, Chieh-Chun; CHANG, Chia-Yu; GAVRIELIDES, Andreas; CAMELO, Miguel; MARQUEZ-BARJA, Johann M.; SLAMNIK-KRIJEŁTORAC, Nina. Optimizing 5G Network Slicing: an end-to-end approach with isolation principles. 2024 Ieee Conference On Network Function Virtualization And Software Defined Networks (Nfv-Sdn), Natal, p. 1-6, 5 nov. 2024. 13 FREE5GC. Influence Traffic Routing. 2025. Available from: https://free5gc.org/guide/8-traffic-influence/. Accessed on: 08 may 2025. 14 SULTAN, Alain. In: 3GPP Technologies. 5G System Overview. 3GPP, 2022. Available from: https://www.3gpp.org/technologies/5g-system-overview. Accessed on: 19 dec. 2024. 15 YU, Heejung; LEE, Howon; JEON, Hongbeom. What is 5G? Emerging 5G Mobile Services and Network Requirements. Sustainability v. 9, n. 10, p. 1848 , 15 oct. 2017. 16 SERIES, M. IMT Vision — Framework and overall objectives of the future development of IMT for 2020 and beyond. Recommendation ITU v. 2083, n. 0, p. 1-22, 2015. 17 ROSIC, Adem. Evaluating Machine Learning Classifier Approaches, and their Accuracy for the Detection of Cyberattacks on 5G IoT Systems. [S.l.]: arXiv, 2023. Available from: https://arxiv.org/abs/2311.02317. Accessed on: 13 jan. 2025. 18 THULASIRAMAN, Preetha; HACKETT, Michael; MUSGRAVE, Preston; EDMOND, Ashley; SEVILLE, Jared. Anomaly Detection in a Smart Microgrid System Using Cyber-Analytics: a case study. Energies, [S.L.], v. 16, n. 20, p. 7151, 19 oct. 2023. 19 ALQURA’N, Rabee; ALJAMAL, Mahmoud; AL-AIASH, Issa; ALSARHAN, Ayoub; KHASSAWNEH, Bashar; ALJAIDI, Mohammad; ALANAZI, Rakan. Advancing XSS Detection in IoT over 5G: a cutting-edge artificial neural network approach. Iot, [S.L.], v. 5, n. 3, p. 478-508, 25 jul. 2024. 20 KIM, Ye-Eun; KIM, Yea-Sul; KIM, Hwankuk. Effective Feature Selection Methods to Detect IoT DDoS Attack in 5G Core Network. Sensors, [S.L.], v. 22, n. 10, p. 3819, 18 may 2022. 21 BORGESEN, Michael. Evaluating Variant Deep Learning and Machine Learning Approaches for the Detection of Cyberattacks on the Next Generation 5G Systems. 2020. 49 f. Dissertação (Mestrado) - Curso de Network And Computer Security, College Of Engineering, Suny Polytechnic Institute, New York, 2020. 22 FARRERAS, Miquel; PAILLISSÉ, Jordi; FÀBREGA, Lluís; VILÀ, Pere. Generation of a network slicing dataset: the foundations for ai-based b5g resource management. Data In Brief, [S.L.], v. 55, p. 110738, ago. 2024. 23 RADOGLOU-GRAMMATIKIS, Panagiotis; NAKAS, George; AMPONIS, George; GIANNAKIDOU, Sofia; LAGKAS, Thomas; ARGYRIOU, Vasileios; GOUDOS, Sotirios; SARIGIANNIDIS, Panagiotis. 5GCIDS: an intrusion detection system for 5g core with ai and explainability mechanisms. 2023 Ieee Globecom Workshops (Gc Wkshps), [S.L.], p. 353-358, 4 dez. 2023 95 24 INTERNET ENGINEERING TASK FORCE. DRAFT-IETF-OPSAWG-PCAP-05: PCAP Capture File Format. 5 ed. [S. L.]: Ietf, 2025. 5 p. Available from: https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcap/05/. Accessed on: 22 may 2025. 25 WIRESHARK. Libpcap File Format. 2020. Available from: https://wiki.wireshark.org/Development/LibpcapFileFormat. Accessed on: 22 may 2025. 26 OLIVEIRA, Leonardo Azalim de; SILVA, Edelberto Franco. Estudo e Avaliação de Métodos de Autenticação EAP na Infraestrutura de Redes de Telecomunicação 5G. Anais Estendidos do XXIII Simpósio Brasileiro de Segurança da Informação e de Sistemas Computacionais (Sbseg Estendido 2023), [Juiz de Fora], p. 97-100, 18 sep. 2023. 27 FREE5GC (Taiwan). free5GC: open source 5g core network based on 3gpp r15 . Open source 5G core network based on 3GPP R15. 2025. Available from: https://free5gc.org/. Accessed on: 19 mar. 2025. 28 GÜNGÖR, Ali. UERANSIM: open source 5g ue and ran (gnodeb) implementation. Open source 5G UE and RAN (gNodeB) implementation. 2025. Available from: https://github.com/aligungr/UERANSIM. Accessed on: 17 mar. 2025. 29 OLIVEIRA, Leonardo Azalim de. FAD: free5gc auto deploy. free5GC Auto Deploy. 2024. Available from: https://github.com/oliveiraleo/free5gc-auto-deploy. Accessed on: 02 apr. 2025. 30 OLIVEIRA, Leonardo Azalim de; SILVA, Rodrigo Oliveira; LIMA, Pedro Campos; PEREIRA, Antônio Marcos Souza; VALADARES, Júlia Almeida; SILVA, Edelberto Franco; DANTAS, Mário Antônio Ribeiro. Análise da Funcionalidade da NWDAF no Core 5G Sobre um Conjunto de Dados. Anais do Xlii Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (Sbrc 2024), [Niteroi], p. 798-811, 20 may 2024. 31 OLIVEIRA, Leonardo Azalim de; SILVA, Edelberto Franco; DANTAS, Mário Antônio Ribeiro. A NWDAF Study Employing Machine Learning Models on a Simulated 5G Network Dataset. 2024 Ieee Symposium On Computers And Communications (Iscc), [Paris], p. 1-6, 26 jun. 2024 32 OLIVEIRA, Leonardo Azalim de; SILVA, Edelberto Franco. Eduroam e 5G: autenticação integrada via redes móveis e wi-fi no core 5g. Anais Estendidos do XXIV Simpósio Brasileiro de Segurança da Informação e de Sistemas Computacionais (Sbseg Estendido 2024), [S.L.], p. 189-192, 16 sep. 2024. 33 OLIVEIRA, Leonardo Azalim de; SILVA JUNIOR, Antônio Marcos da; PINTO, Mariana Siano. Introdução à ambientes de experimentação 5G. 2024. XXVI Semana da Computação DCC/UFJF. Available from: https://netlab.ice.ufjf.br/courses/5g-practical/. Accessed on: 20 jan. 2025. 34 UNESCO. UNESCO Recommendation on Open Science. Paris: United Nations Educational, Scientific And Cultural Organization, 2021. Available from: https://doi.org/10.54677/MNMH8546. Accessed on: 19 jun. 2025. 96 35 OLIVEIRA, Leonardo. Free5gc/free5gc - Contributions by oliveiraleo. 2025. Available from: https://github.com/free5gc/free5gc/issues?q=author:oliveiraleo. Accessed on: 10 jul. 2025. 36 OLIVEIRA, Leonardo. Pull requests by oliveiraleo - free5gc/free5gc.github.io. 2025. Available from: https://github.com/free5gc/free5gc.github.io/pulls?q=author:oliveiraleo. Accessed on: 10 jul. 2025. 37 ZHENG, Kaiyuan. Order of the EAP AKA’ attributes. 2022. Available from: https://github.com/aligungr/UERANSIM/issues/592. Accessed on: 01 jul. 2025. 38 OLIVEIRA, Leonardo. Running TNGFUE on another subnet. 2024. Available from: https://forum.free5gc.org/t/running-tngfue-on-another-subnet/2571. Accessed on: 01 jul. 2025. 39 OLIVEIRA, Leonardo. Archive of Master Thesis Artifacts: user equipment classification in the 5G core. Traffic Characterization for User Equipment Classification in the 5G Core. 2025. Zenodo. Available from: https://doi.org/10.5281/zenodo.15473395. Accessed on: 20 may 2025. 40 OLIVEIRA, Leonardo Azalim de; SILVA, Edelberto Franco; CHAVES, Luciano Jerez. 5G Traffic Capture Dataset: user equipment classification in the 5G core. Traffic Characterization for User Equipment Classification in the 5G Core. 2025. Zenodo. Available from: https://doi.org/10.5281/zenodo.15064129. Accessed on: 20 may 2025. 41 OLIVEIRA, Leonardo Azalim de. NWDAF ML. 2025. Available from: https://github.com/netlabufjf/nwdaf_ml. Accessed on: 02 apr. 2025. 42 3GPP. In: 3GPP Technologies. Introducing 3GPP. 3GPP, 2024. Available from: https://www.3gpp.org/about-us/introducing-3gpp. Accessed on: 06 mar. 2025. 43 ITU. About International Telecommunication Union (ITU). ITU, 2025. Available from: https://www.itu.int/en/about/Pages/default.aspx. Accessed on: 10 mar. 2025. 44 ROMANO, Giovanni. In: 3GPP Technologies. 3GPP meets IMT-2020. 3GPP, 2020. Available from: https://www.3gpp.org/technologies/3gpp-meets-imt-2020. Accessed on: 10 mar. 2025. 45 ITU. IMT-2020. ITU, 2025. Available from: https://www.itu.int/en/ITU-R/studygroups/rsg5/rwp5d/imt-2020/Pages/default.aspx. Accessed on: 06 mar. 2025. 46 AL-DUJAILI, Mohammed Jawad; AL-DULAIMI, Mohammed Abdulzahra. Fifth-Generation Telecommunications Technologies: Features, Architecture, Challenges and Solutions. Wireless Personal Communications v. 128, n. 1, p. 447–469 , jan. 2023. 47 WIKIPEDIA. 1G. Wikipedia, 2025. Available from: https://en.wikipedia.org/wiki/1G. Accessed on: 06 mar. 2025. 48 WIKIPEDIA. 2G. Wikipedia, 2025. Available from: https://en.wikipedia.org/wiki/2G. Accessed on: 06 mar. 2025. 97 49 WIKIPEDIA. 3G. Wikipedia, 2025. Available from: https://en.wikipedia.org/wiki/3G. Accessed on: 06 mar. 2025. 50 WIKIPEDIA. 4G. Wikipedia, 2025. Available from: https://en.wikipedia.org/wiki/4G. Accessed on: 06 mar. 2025. 51 3GPP. In: 3GPP Specifications & Technologies. Release 15. 3GPP, 2019. Available from: https://www.3gpp.org/specifications-technologies/releases/release-15. Accessed on: 06 mar. 2025. 52 WIKIPEDIA. 5G. Wikipedia, 2025. Available from: https://en.wikipedia.org/wiki/5G. Accessed on: 06 mar. 2025. 53 3RD GENERATION PARTNERSHIP PROGRAM. 3GPP TS 23.501 version 15.13.0 Release 15: System architecture for the 5G System (5GS). Sophia Antipolis: Etsi, 2022. 253 p. 54 CHAI, Yu-Herng; LIN, Fuchun Joseph. Evaluating Dedicated Slices of Different Configurations in 5G Core. Journal Of Computer And Communications, [S.L.], v. 09, n. 07, p. 55-72, 2021. 55 SDXCENTRAL STUDIOS. What Is the Radio Access Network (RAN)?. SDxCentral Studios, 2025. Available from: https://www.sdxcentral.com/5g/ran/definitions/radio-access-network/. Accessed on: 07 mar. 2025. 56 3RD GENERATION PARTNERSHIP PROGRAM. 3GPP TR 21.905 version 18.0.0 Release 18: Vocabulary for 3GPP Specifications. Sophia Antipolis: Etsi, 2024. 69 p. 57 SERIES, I. Integrated Services Digital Network (ISDN) — General Structure — Vocabulary of terms for ISDNs. Recommendation ITU v. 112, p. 1-20, 1993. 58 3RD GENERATION PARTNERSHIP PROGRAM. 3GPP TS 29.060 version 17.4.0 Release 17: GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface. Sophia Antipolis: Etsi, 2022. 199 p. 59 KIM, Ye-Eun; KIM, Min-Gyu; KIM, Hwankuk. Detecting IoT Botnet in 5G Core Network Using Machine Learning. Computers, Materials & Continua v. 72, n. 3, p. 4467–4488 , 2022. 60 3RD GENERATION PARTNERSHIP PROGRAM. 3GPP TS 29.575 version 17.3.0 Release 17: Analytics Data Repository Services — Stage 3. Sophia Antipolis: Etsi, 2023. 51 p. 61 3RD GENERATION PARTNERSHIP PROGRAM. 3GPP TS 23.288 version 18.9.0 Release 18: Architecture enhancements for 5G System (5GS) to support network data analytics services. Sophia Antipolis: Etsi, 2025. 329 p. 62 NIU, Yuxia; ZHAO, Song; SHE, Xiaoming; CHEN, Peng. A Survey of 3GPP Release 18 on Network Data Analytics Function Management. In: IEEE/CIC INTERNATIONAL CONFERENCE ON COMMUNICATIONS IN CHINA (ICCC 98 WORKSHOPS), 2022., 2022, Sanshui. Proceedings [...] . Sanshui: Ieee, 2022. p. 146-151. 63 3RD GENERATION PARTNERSHIP PROGRAM. 3GPP TS 23.502 version 17.13.0 Release 17: Procedures for the 5G System (5GS). Sophia Antipolis: Etsi, 2024. 755 p. 64 RUPANAGUNTA, Sriram. NWDAF Rel 17 Explained — Architecture, Features and Use Cases. Aarna, 2021. Available from: https://www.aarna.ml/post/nwdaf-rel-17-explained-architecture-features-and-usecases. Accessed on: 10 mar. 2025. 65 KUAN, Liu H. NWDAF introduction. Free5GC, 2024. Available from: https://free5gc.org/blog/20241127/20241127/. Accessed on: 10 mar. 2025. 66 5G AMERICAS. Becoming 5G-Advanced: the 3gpp 2025 roadmap. the 3GPP 2025 Roadmap. 2022. Available from: https://www.5gamericas.org/becoming-5g-advanced-the-3gpp-roadmap/. Accessed on: 18 mar. 2025 67 ERICSSON. 5G Advanced: evolution towards 6g. Evolution towards 6G. 2023. Available from: https://www.ericsson.com/en/reports-and-papers/white-papers/5gadvanced-evolution-towards-6g. Accessed on: 18 mar. 2025. 68 SERIES, M. Framework and overall objectives of the future development of IMT for 2030 and beyond. Recommendation ITU v. 2160, n. 0, p. 1-21, 2023. 69 WIKIPEDIA. 6G. Wikipedia, 2025. Available from: https://en.wikipedia.org/wiki/6G. Accessed on: 18 mar. 2025. 70 WIKIPEDIA. Machine learning. Wikipedia, 2025. Available from: https://en.wikipedia.org/wiki/Machine_learning. Accessed on: 20 may 2025. 71 MAVROMATIS, Ioannis; KATSAROS, Kostas; KHAN, Aftab. Computing Within Limits: an empirical study of energy consumption in ml training and inference. Arxiv Preprint Arxiv:2406.14328, [S.L.], p. 1-15, 20 jun. 2024. ArXiv. http://dx.doi.org/10.48550/ARXIV.2406.14328. 72 MAAYAN, Gilad David. A Practical Guide to Working with Testing and Training Data in ML Projects. 2023. Available from: https://www.computer.org/publications/tech-news/trends/machine-learningprojects-training-testing. Accessed on: 20 mar. 2025. 73 PEDREGOSA, F. et al. Scikit-learn: Machine Learning in Python. Journal of Machine Learning Research v. 12, p. 2825-2830 , 2011. 74 LEARN, Scikit. Metrics and scoring: quantifying the quality of predictions. Website, 2024. Available from: https://scikit-learn.org/stable/modules/model_evaluation.html#accuracy-score. Accessed on: 06 mar. 2025 75 ZAKI, Mohammed J.; MEIRA JUNIOR, Wagner. Data Mining and Machine Learning: fundamental concepts and algorithms. 2. ed. Cambridge: Cambridge University Press, 2020. 777 p. 99 76 WIKIPEDIA. Receiver operating characteristic. Wikipedia, 2025. Available from: https://en.wikipedia.org/wiki/Receiver_operating_characteristic. Accessed on: 20 mar. 2025. 77 SCIKIT-LEARN. Multiclass Receiver Operating Characteristic (ROC): one-vs-one multiclass roc. One-vs-One multiclass ROC. 2007. Available from: https://scikit-learn.org/stable/auto_examples/model_selection/plot_roc.html#onevs-one-multiclass-roc. Accessed on: 20 mar. 2025. 78 PATI, D.; LORUSSO, L. N. How to Write a Systematic Review of the Literature. HERD: Health Environments Research & Design Journal, v. 11, n. 1, p. 15–30, 28 dec. 2018. 79 LEVY, Yair; J. ELLIS, Timothy. A Systems Approach to Conduct an Effective Literature Review in Support of Information Systems Research. Informing Science: The International Journal of an Emerging Transdiscipline v. 9, p. 181–212 , 2006. 80 CARRERA-RIVERA, Angela et al. How-to conduct a systematic literature review: A quick guide for computer science research. MethodsX v. 9, p. 101895 , 2022. 81 HARZING, Anne-Wil. Publish or Perish. Software, 2007. Available from: https://harzing.com/resources/publish-or-perish. Accessed on: 29 oct. 2024 82 FEDER, Alexander. BibTeX. Software, 2006. Available from: https://www.bibtex.org/. Accessed on: 26 feb. 2025 83 FREITAS, V.; SEGATTO, W. Parsifal. Software, 2018. Available from: https://parsif.al. Accessed on: 29 oct. 2024 84 Wikipedia. Qualis (CAPES). Website, 2024. Available from: https://en.wikipedia.org/wiki/Qualis_(CAPES). Accessed on: 08 nov. 2024 85 Elsevier. CiteScore metrics you can verify and trust. Website, 2024. Available from: https://www.elsevier.com/products/scopus/metrics/citescore. Accessed on: 08 nov. 2024 86 EUROPEAN ORGANIZATION FOR NUCLEAR RESEARCH ([Switzerland]). Cern (org.). Zenodo. 2013. Available from: https://www.zenodo.org/. Accessed on: 07 apr. 2025. 87 BARTOLEC, Ivan; ORSOLIC, Irena; SKORIN-KAPOV, Lea. Impact of User Playback Interactions on In-Network Estimation of Video Streaming Performance. IEEE Transactions on Network and Service Management v. 19, n. 3, p. 3547–3561 , set. 2022. 88 PAOLINI, Emilio et al. Real-Time Network Packet Classification Exploiting Computer Vision Architectures. IEEE Open Journal of the Communications Society v. 5, p. 1155–1166 , 2024. 89 SAMARAKOON, Sehan et al. 5G-NIDD: A Comprehensive Network Intrusion Detection Dataset Generated over 5G Wireless Network. IEEE DataPort, 2022. DOI:10.21227/xtep-hv36. 100 90 KOURSIOUMPAS, Nikolaos et al. AI-driven, Context-Aware Profiling for 5G and Beyond Networks. IEEE Transactions on Network and Service Management v. 19, n. 2, p. 1036–1048 , jun. 2022. 91 SEVGICAN, Salih et al. Intelligent network data analytics function in 5G cellular networks using machine learning. Journal of Communications and Networks v. 22, n. 3, p. 269–280 , jun. 2020. 92 DA SILVA, Douglas Chagas et al. A Novel Approach to Multi-Provider Network Slice Selector for 5G and Future Communication Systems. Sensors v. 22, n. 16, p. 6066 , 13 ago. 2022. 93 RIZWAN, Ali et al. A Zero-Touch Network Service Management Approach Using AI-Enabled CDR Analysis. IEEE Access v. 9, p. 157699–157714 , 2021. 94 ANFAR, Mohamad Rimas Mohamad; MWANGAMA, Joyce. Machine Learning-Based Service Differentiation in the 5G Core Network. In: 2021 INTERNATIONAL CONFERENCE ON ARTIFICIAL INTELLIGENCE IN INFORMATION AND COMMUNICATION (ICAIIC), 13 abr. 2021, Jeju Island, Korea (South). IEEE, 13 abr. 2021. p.144–149. 978-1-72817-638-3. . 95 FRAUNHOFER FOKUS (Germany). Open5GCore. Available from: https://www.open5gcore.org/. Accessed on: 15 mar. 2025. 96 GUERRA-MANZANARES, Alejandro; MEDINA-GALINDO, Jorge; BAHSI, Hayretdin; NÕMM, Sven. MedBIoT: generation of an iot botnet dataset in a medium-sized iot network. Proceedings Of The 6th International Conference On Information Systems Security And Privacy, Valletta, v. 1, p. 207-218, 2020. 97 MOHAMMEDALI, Noor Abdalkarem et al. Enhancing Service Classification for Network Slicing in 5G Using Machine Learning Algorithms. In: AL-BAKRY, Abbas M. et al. (Orgs.). . New Trends in Information and Communications Technology Applications. Communications in Computer and Information Science. Cham: Springer Nature Switzerland, 2023. 1764 v. p. 25–37. 978-3-031-35441-0. 98 MATHWORKS (United States). MATLAB. 2025. Available from: https://www.mathworks.com/products/matlab.html. Accessed on: 19 mar. 2025. 99 WIRESHARK FOUNDATION (United States). Wireshark: the world’s most popular network protocol analyzer. The world’s most popular network protocol analyzer. 1998. Available from: https://www.wireshark.org/. Accessed on: 19 mar. 2025. 100 TAKASAKI, Chikako et al. Device Type Classification Based on Two-Stage Traffic Behavior Analysis. IEICE Transactions on Communications v. E107.B, n. 1, p. 117–125 , 1 jan. 2024. 101 MANIAS, Dimitrios Michael; CHOUMAN, Ali; SHAMI, Abdallah. An NWDAF Approach to 5G Core Network Signaling Traffic: Analysis and Characterization. In: GLOBECOM 2022 - 2022 IEEE GLOBAL COMMUNICATIONS CONFERENCE, 4 dez. 2022, Rio de Janeiro, Brazil. IEEE, 4 dec. 2022. p.6001–6006. 978-1-66543-540-6. . 101 102 SUKCHAN LEE (South Korea). Open5GS: open source implementation for 5g core and epc. Open Source implementation for 5G Core and EPC. 2024. Available from: https://open5gs.org/. Accessed on: 17 mar. 2025. 103 SILVA, Gabriel Henrique Davanço. Classificação de tráfego por classes de serviço no núcleo 5G. 2022. 104 DAHMEN-LHUISSIER, Sabine. Zero touch network & Service Management (ZSM). 2025. Available from: https://www.etsi.org/technologies/zero-touch-network-service-management. Accessed on: 15 jul. 2025. 105 SOUZA NETO, Natal V. et al. Evolved NWDAF Towards a Fully Distributed Artificial Intelligence in the 6G Network Architecture. Anais do IV Workshop de Redes 6G, p. 15-25 , 2024. 106 RISCHKE, Justus; SOSSALLA, Peter; ITTING, Sebastian; FITZEK, Frank H. P.; REISSLEIN, Martin. 5G Campus Networks: a first measurement study. Ieee Access, [S.L.], v. 9, p. 121786-121803, 2021. 107 MQTT. MQTT: the standard for iot messaging. The Standard for IoT Messaging. 2024. Available from: https://mqtt.org/. Accessed on: 01 jul. 2025. 108 ENGLISH, John. Service Assurance Questions in the Time of 5G Standalone: how does service assurance change with the movement to 5g standalone?. How does service assurance change with the movement to 5G standalone?. 2023. Available from: https://www.netscout.com/blog/service-assurance-questions-time-5g-standalone. Accessed on: 02 apr. 2025. 109 IEEE (United States Of America). IEEE DataPort: dataset storage and dataset search platform. Dataset Storage and Dataset Search Platform. 2025. Available from: https://ieee-dataport.org/. Accessed on: 28 mar. 2025. 110 CHOI, Yong-Hoon; KIM, Daegyeom; KO, Myeongjin. 5G traffic datasets. IEEE DataPort, 2023. DOI:10.21227/ewhk-n061. 111 GOOGLE (United States Of America). Google Scholar. 2025. Available from: https://scholar.google.com/. Accessed on: 28 may. 2025. 112 KAGGLE (United States Of America). Kaggle: your machine learning and data science community. Your Machine Learning and Data Science Community. 2025. Available from: https://www.kaggle.com/. Accessed on: 28 mar. 2025. 113 DATA. [Basel], 2016. Available from: https://www.mdpi.com/journal/data. Accessed on: 28 mar. 2025. 114 RISCHKE, Justus. 5G campus networks: measurement traces. IEEE DataPort, 2021. DOI:10.21227/xe3c-e968. 115 EMMERICH, Paul; GALLENMÜLLER, Sebastian; RAUMER, Daniel; WOHLFART, Florian; CARLE, Georg. MoonGen. Proceedings Of The 2015 Internet Measurement Conference, [Tokyo], p. 275-287, 28 oct. 2015. 102 116 STACK OVERFLOW (United States). Stack Overflow Developer Survey 2022. 2022. Available from: https://survey.stackoverflow.co/2022/#section-version-controlversion-control-platforms. Accessed on: 01 jul. 2025. 117 FREE5GC (Taiwan). User Guide. [2020]. Available from: https://free5gc.org/guide/. Accessed on: 02 apr. 2024. 118 OLIVEIRA, Leonardo. Running TNGFUE on another subnet. 2024. Available from: https://forum.free5gc.org/t/running-tngfue-on-another-subnet/2571. Accessed on: 01 jul. 2025. 119 OLIVEIRA, Leonardo. Free5gc/free5gc: contributions by oliveiraleo. Contributions by oliveiraleo. 2024. Available from: https://github.com/free5gc/free5gc/issues?q=author:oliveiraleo. Accessed on: 01 jul. 2025. 120 OLIVEIRA, Leonardo. Feat: Improve TNGFUE execution flow by oliveiraleo - Pull Request #2 - free5gc/tngfue. 2024. Available from: https://github.com/free5gc/tngfue/pull/2. Accessed on: 01 jul. 2025. 121 OLIVEIRA, Leonardo. Pull requests by oliveiraleo - free5gc/free5gc.github.io. 2024. Available from: https://github.com/free5gc/free5gc.github.io/pulls?q=is:pr+author:oliveiraleo. Accessed on: 01 jul. 2025. 122 OLIVEIRA, Leonardo Azalim de. PCAP-dataExtractor: Python code to parse JSON network traffic data to CSV file. 2025. Available from: https://github.com/oliveiraleo/PCAP-dataExtractor. Accessed on: 02 apr. 2025. 123 SIVANATHAN, Arunan et al. Characterizing and classifying IoT traffic in smart cities and campuses. In: 2017 IEEE CONFERENCE ON COMPUTER COMMUNICATIONS: WORKSHOPS (INFOCOM WKSHPS), maio 2017, Atlanta, GA. Anais... Atlanta, GA: IEEE, maio 2017. p.559–564. 978-1-5386-2784-6. 2017. 124 WIRESHARK. Tshark: dump and analyze network traffic. Dump and analyze network traffic. [2025]. Available from: https://www.wireshark.org/docs/man-pages/tshark.html. Accessed on: 02 apr. 2025. 125 WIRESHARK. PROFINET IO (PN-IO). 2020. Available from: https://wiki.wireshark.org/PROFINET/IO. Accessed on: 09 apr. 2025. 126 DREIBHOLZ, Thomas. High-Precision Round-Trip Time Measurements in the Internet with HiPerConTracer. 2023 International Conference On Software, Telecommunications And Computer Networks (Softcom), [S.L.], p. 1-7, 21 sep. 2023. 127 WIRESHARK. SINEC H1 (H1). 2020. Available from: https://wiki.wireshark.org/H1. Accessed on: 09 apr. 2025. 128 INTERNET ENGINEERING TASK FORCE. RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport. [S. L.], 2021. Available from: https://datatracker.ietf.org/doc/html/rfc9000. Accessed on: 10 apr. 2025. 103 129 RIKITAKE, Kenji. Do not enable QUIC on 1280-byte MTU IPv6 networks. 2024. Available from: https://gist.github.com/jj1bdx/1adac3e305d0fb6dee90dd5b909513ed. Accessed on: 10 apr. 2025. 130 BROWNLEE, Jason. A Gentle Introduction to the Chi-Squared Test for Machine Learning. 2019. Available from: https://machinelearningmastery.com/chi-squared-test-for-machine-learning/. Accessed on: 01 jul. 2025. 131 CORDER, Gregory W.; FOREMAN, Dale I.. Nonparametric statistics: a step-by-step approach. 2. ed. Nashville: John Wiley & Sons, 2014. 283 p. ISBN: 978-1-118-84031-3. 132 MANN, H. B.; WHITNEY, D. R.. On a Test of Whether one of Two Random Variables is Stochastically Larger than the Other. The Annals Of Mathematical Statistics, [S.L.], v. 18, n. 1, p. 50-60, mar. 1947. 133 BROWNLEE, Jason. Machine learning mastery with Python: understand your data, create accurate models, and work projects end-to-end. 1.4 [S. L.]: Machine Learning Mastery, 2016. 179 p. 134 PEARSON, Karl. X. On the criterion that a given system of deviations from the probable in the case of a correlated system of variables is such that it can be reasonably supposed to have arisen from random sampling. The London, Edinburgh, And Dublin Philosophical Magazine And Journal Of Science, [S.L.], v. 50, n. 302, p. 157-175, jul. 1900. 135 KALIYADAN, Feroze; KULKARNI, Vinay. Types of variables, descriptive statistics, and sample size. Indian Dermatology Online Journal, [S.L.], v. 10, n. 1, p. 82, 2019. 136 SUKUMAR, Hamsini. Continuous vs. discrete vs. categorical axis: what is the difference?. What is the difference?. 2025. Available from: https://inforiver.com/insights/continuous-discrete-categorical-axis-difference/. Accessed on: 01 jul. 2025 137 HOSSAIN, Md. Riyad; TIMMER, Douglas. Machine Learning Model Optimization with Hyper Parameter Tuning Approach. Global Journal Of Computer Science And Technology: D, [S.L.], v. 21, n. 2, p. 31, 2021. Monthly. 138 STORN, Rainer; PRICE, Kenneth. Differential Evolution: a simple and efficient heuristic for global optimization over continuous spaces. Journal Of Global Optimization, [S.L.], v. 11, n. 4, p. 341-359, dez. 1997. 139 IBM ([United States Of America]). What is random forest? 2025. Available from: https://www.ibm.com/think/topics/random-forest. Accessed on: 16 apr. 2025. 140 WIKIPEDIA. Random forest. Wikipedia, 2025. Available from: https://en.wikipedia.org/wiki/Random_forest. Accessed on: 16 abr. 2025. 141 CHAWLA, N. V.; BOWYER, K. W.; HALL, L. O.; KEGELMEYER, W. P.. SMOTE: synthetic minority over-sampling technique. Journal Of Artificial Intelligence Research, [S.L.], v. 16, p. 321-357, 1 jun. 2002. 110 148 fi 149 150 # Install UPF supporting packages 151 echo "[ INFO ] Installing UPF prerequisites " 152 sudo apt -y install gcc g++ cmake autoconf libtool pkg - config libmnl - dev libyaml - dev 153 echo "[ INFO ] Done" 154 155 ##################### 156 # Configure host OS # 157 ##################### 158 echo "[ INFO ] Configuring host OS" 159 ip a 160 echo "" 161 echo "Please , enter the 5GC ’s DN interface name (e.g. the interface that has internet access )" 162 echo -n "> " 163 read IFACENAME 164 165 echo "[ INFO ] Using $IFACENAME as interface name " 166 167 # warn the user before deleting the rules 168 if [ $FIREWALL_RULES_CONTROL -eq 1 ]; then 169 # start to delete old rules 170 echo -n "[ INFO] Removing all iptables rules , if any ... " 171 sudo iptables -P INPUT ACCEPT 172 sudo iptables -P FORWARD ACCEPT 173 sudo iptables -P OUTPUT ACCEPT 174 sudo iptables -t nat -F 175 sudo iptables -t mangle -F 176 sudo iptables -F 177 sudo iptables -X 178 echo "[OK]" 179 fi 180 echo -n "[ INFO] Applying free5GC iptables rules ... " 181 sudo iptables -t nat -A POSTROUTING -o $IFACENAME -j MASQUERADE 182 sudo iptables -A FORWARD -p tcp -m tcp --tcp - flags SYN ,RST SYN -j TCPMSS --setmss 1400 183 sudo iptables -I FORWARD 1 -j ACCEPT 184 echo "[OK]" 185 echo -n "[ INFO] Setting kernel net. ipv4. ip_forward flag ... " 186 sudo sysctl -w net .ipv4 . ip_forward =1 >/ dev /null 187 echo "[OK]" 188 echo -n "[ INFO] Stopping and disabling the ufw firewall ... " 189 sudo systemctl stop ufw 190 sudo systemctl disable ufw >/ dev/ null 2 >&1 191 echo "[OK]" 111 192 193 ######################## 194 # Install free5GC ’s CP # 195 ######################## 196 echo "[ INFO ] Installing the 5GC" 197 if [ $FREE5GC_STABLE_BRANCH_CONTROL -eq 1 ]; then 198 echo "[ INFO ] Cloning free5GC stable branch " 199 echo "[ INFO ] Tag / release : $FREE5GC_VERSION " 200 if [[ $FREE5GC_VERSION = "v3 .3.0" ]]; then 201 echo "[ WARN ] Using an older release should be avoided " 202 # v3 .3.0 203 git clone -c advice . detachedHead = false -- recursive -b $FREE5GC_VERSION -j ‘nproc ‘ https :// github . com / free5gc / free5gc . git # clones the previous stable build 204 cd free5gc 205 sudo corepack enable # necessary to build webconsole on free5GC v3 .3.0 206 # Useful script 207 echo "[ INFO ] Downloading reload_host_config script from source " 208 curl -LOSs https :// raw . githubusercontent . com / free5gc / free5gc / main/ reload_host_config . sh 209 210 elif [[ $FREE5GC_VERSION = "v3 .4.1" || $FREE5GC_VERSION = "v3 .4.2 " || $FREE5GC_VERSION = "v3 .4.3" || $FREE5GC_VERSION = "v3 .4.4 " ]]; then 211 # v3 .4. x 212 git clone -c advice . detachedHead = false -- recursive -b $FREE5GC_VERSION -j ‘nproc ‘ https :// github . com / free5gc / free5gc . git # clones the stable build 213 cd free5gc 214 else 215 echo "[ ERROR ] Script failed to set FREE5GC_VERSION variable " # check your spelling , you must keep the "v" (e.g. v .3.4.1 and up) 216 exit 1 217 fi 218 elif [ $FREE5GC_STABLE_BRANCH_CONTROL -eq 0 ]; then 219 echo "[ INFO ] Cloning free5GC nightly branch " 220 echo "[ INFO ] Commit : $FREE5GC_NIGHTLY_COMMIT " 221 echo "[ WARN ] Unless you know what you are doing , using the nightly branch should be avoided " 222 git clone -- recursive -j ‘nproc ‘ https :// github . com / free5gc / free5gc . git # clones the nightly build 223 cd free5gc 224 git -c advice . detachedHead = false checkout $FREE5GC_NIGHTLY_COMMIT # commit with the webconsole build and kill script fixes ( among other updates) 225 else 112 226 echo "[ ERROR ] Script failed to set FREE5GC_STABLE_BRANCH_CONTROL variable" 227 exit 1 228 fi 229 230 if [ $N3IWF_STABLE_BRANCH_CONTROL -eq 0 ]; then 231 echo "[ INFO ] Installing N3IWF nightly " 232 echo "[ INFO ] Cloning N3IWF nightly branch " 233 echo "[ INFO ] Commit : $N3IWF_NIGHTLY_COMMIT " 234 cd NFs / n3iwf / 235 git -c advice . detachedHead = false checkout $N3IWF_NIGHTLY_COMMIT 236 cd ../../ 237 fi 238 239 make # builds all the NFs 240 cd .. 241 242 ######################################## 243 # Install UPF / GTP -U 5G kernel module # 244 ######################################## 245 echo "[ INFO ] Configuring the GTP kernel module " 246 echo "[ INFO ] Removing GTP ’s previous versions , if any" 247 rm -rf gtp5g # removes previous versions 248 echo "[ INFO ] Installing the GTP kernel module " 249 echo "[ INFO ] Release : $GTP5G_VERSION " 250 git clone -c advice . detachedHead = false -b $GTP5G_VERSION https :// github . com/ free5gc / gtp5g . git 251 cd gtp5g 252 make 253 sudo make install 254 cd .. 255 256 # Install the WebConsole 257 curl -fsSL https :// deb. nodesource .com/ setup_20 .x | sudo -E bash - 258 sudo apt update 259 sudo apt install -y nodejs 260 261 cd free5gc 262 make webconsole 263 cd .. 264 265 ############################### 266 # Update the 5GC config files # 267 ############################### 268 echo "[ INFO ] Updating configuration files " 269 ip address show $IFACENAME | grep "\ binet \b" 270 # Reads the data network interface IP 113 271 echo " Please , type the 5GC ’s DN interface IP address " 272 echo -n "> " 273 read IP 274 275 # Prepare the IPSec inner tunnel IP address for N3IWF or TNGF 276 if [ $N3IWF_CONFIGURATION_CONTROL -eq 1 ] || [ $TNGF_CONFIGURATION_CONTROL -eq 1 ]; then 277 # Get the first octet of the free5GC machine IP 278 IP_FIRST_OCTET=${IP%%.*} 279 echo "[ DEBUG ] free5GC machine DN interface IP 1 st octet : $IP_FIRST_OCTET " 280 281 IP_IPSEC_INNER=" 10.0.0.1 " # default IP is 10.0.0.1 ( Check it here : https :// github . com / free5gc / free5gc / blob / main / config / n3iwfcfg . yaml # L36 or https :// github . com / free5gc / free5gc / blob /main / config / tngfcfg . yaml # L36) 282 IP_IPSEC_INNER_NET_ADDR="10.0.0.0/24" 283 284 # If the UE IP belongs to the 10. x.x.x range , it will conflict with the IPSec tunnel address that will be added as the default route 285 if [ ${IP_FIRST_OCTET} -eq 10 ]; then 286 echo "[ WARN ] A conflicting IP address range for Nwu interface was detected " 287 echo "[ INFO ] Using 172.16. x.x as IPSec tunnel address space instead of 10.x.x.x" 288 289 IP_IPSEC_INNER=" 172.16.0.1 " # update the IP address 290 291 IP_NET_OCTETS =‘ echo " $IP_IPSEC_INNER " | cut -d . -f 1-3‘ 292 IP_IPSEC_INNER_NET_ADDR="$IP_NET_OCTETS"".0/24" # update the network address 293 294 echo "[ DEBUG ] New IPSec tunnel inner IP address : $IP_IPSEC_INNER " 295 echo "[ DEBUG ] New IPSec tunnel IP addresses pool : $IP_IPSEC_INNER_NET_ADDR" 296 else 297 echo "[ DEBUG ] No conflicting IP address found " 298 fi 299 fi 300 301 CONFIG_FOLDER =" ./ free5gc / config /" 302 303 # The vars below aim to find the correct line to replace the IP address . The commands get the line right above the one where the IP must be changed 304 AMF_LINE =$( grep -n ’ ngapIpList : # the IP list of N2 interfaces on this 114 AMF ’ ${ CONFIG_FOLDER } amfcfg . yaml | awk -F: ’{ print $1 }’ -) 305 SMF_LINE =$( grep -n ’ endpoints : # the IP address of this N3/N9 interface on this UPF ’ ${ CONFIG_FOLDER } smfcfg . yaml | awk -F: ’{ print $1}’ -) 306 UPF_LINE =$( grep -n ’ifList:’ ${ CONFIG_FOLDER } upfcfg . yaml | awk -F: ’{ print $1}’ -) 307 # Increment the counters to point to the next line ( where the IP is located) 308 AMF_LINE =$ (( AMF_LINE +1)) 309 SMF_LINE =$ (( SMF_LINE +1)) 310 UPF_LINE =$ (( UPF_LINE +1)) 311 312 # Update the IP on the config files 313 sed -i "" $AMF_LINE "s/.*/ - $IP /" ${ CONFIG_FOLDER } amfcfg . yaml 314 sed -i "" $SMF_LINE "s/.*/ - $IP/" ${ CONFIG_FOLDER } smfcfg . yaml 315 sed -i "" $UPF_LINE "s/.*/ - addr: $IP /" ${ CONFIG_FOLDER } upfcfg . yaml 316 317 # N3IWF config 318 if [ $N3IWF_CONFIGURATION_CONTROL -eq 1 ]; then 319 N3IWF_LINE =$( grep -n ’# --- N2 Interfaces ---’ ${ CONFIG_FOLDER } n3iwfcfg . yaml | awk -F: ’{ print $1}’ -) 320 N3IWF_LINE =$ (( N3IWF_LINE +3) ) 321 sed -i "" $N3IWF_LINE"s /.*/ - $IP/" ${ CONFIG_FOLDER } n3iwfcfg . yaml 322 N3IWF_LINE =$ (( N3IWF_LINE +5) ) 323 if [[ $FREE5GC_VERSION = "v3 .4.4" ]]; then # if new N3IWF version is being used 324 sed -i "" $N3IWF_LINE"s /.*/ ikeBindAddress : $IP # Nwu interface IP address ( IKE ) on this N3IWF /" ${ CONFIG_FOLDER } n3iwfcfg . yaml 325 N3IWF_LINE =$ (( N3IWF_LINE +1) ) 326 sed -i "" $N3IWF_LINE"s /.*/ ipSecTunnelAddress : $IP_IPSEC_INNER # Tunnel IP address of XFRM interface on this N3IWF /" ${ CONFIG_FOLDER } n3iwfcfg . yaml 327 N3IWF_LINE =$ (( N3IWF_LINE +1) ) 328 # using @ as the delimiter on the line below as $IP_IPSEC_INNER_NET_ADDR contains a slash that will break sed functionality 329 sed -i "" $N3IWF_LINE"s@.*@ ueIpAddressRange: $IP_IPSEC_INNER_NET_ADDR # IP address pool allocated to UE in IPSec tunnel@" ${ CONFIG_FOLDER } n3iwfcfg . yaml 330 else # or continue using old writing style 331 sed -i "" $N3IWF_LINE"s /.*/ IKEBindAddress : $IP # Nwu interface IP address ( IKE ) on this N3IWF /" ${ CONFIG_FOLDER } n3iwfcfg . yaml 332 N3IWF_LINE =$ (( N3IWF_LINE +1) ) 333 sed -i "" $N3IWF_LINE"s /.*/ IPSecTunnelAddress : $IP_IPSEC_INNER # Tunnel IP address of XFRM interface on this N3IWF /" ${ CONFIG_FOLDER } n3iwfcfg . yaml 115 334 N3IWF_LINE =$ (( N3IWF_LINE +1) ) 335 # using @ as the delimiter on the line below as $IP_IPSEC_INNER_NET_ADDR contains a slash that will break sed functionality 336 sed -i "" $N3IWF_LINE"s@.*@ UEIPAddressRange: $IP_IPSEC_INNER_NET_ADDR # IP address pool allocated to UE in IPSec tunnel@" ${ CONFIG_FOLDER } n3iwfcfg . yaml 337 echo "[ INFO ] N3IWF configuration applied " 338 fi 339 fi 340 341 # TNGF config 342 if [ $TNGF_CONFIGURATION_CONTROL -eq 1 ]; then 343 TNGF_LINE =$( grep -n ’AMFSCTPAddresses:’ ${ CONFIG_FOLDER } tngfcfg . yaml |awk -F: ’{ print $1}’ -) 344 TNGF_LINE =$ (( TNGF_LINE +2)) 345 sed -i "" $TNGF_LINE "s/.*/ - $IP/" ${ CONFIG_FOLDER } tngfcfg . yaml 346 # TNGF_LINE =$( grep -n ’# --- Bind Interfaces ---’ ${ CONFIG_FOLDER } tngfcfg . yaml | awk -F: ’{ print $1}’ -) 347 TNGF_LINE =$ (( TNGF_LINE +5)) 348 sed -i "" $TNGF_LINE "s/.*/ IKEBindAddress : $IP # IP address of Nwu interface ( IKE) on this TNGF /" ${ CONFIG_FOLDER } tngfcfg .yaml 349 TNGF_LINE =$ (( TNGF_LINE +1)) 350 sed -i "" $TNGF_LINE "s/.*/ RadiusBindAddress : $IP # IP address of Nwu interface ( IKE) on this TNGF /" ${ CONFIG_FOLDER } tngfcfg . yaml 351 TNGF_LINE =$ (( TNGF_LINE +1)) 352 sed -i "" $TNGF_LINE "s/.*/ IPSecInterfaceAddress : $IP_IPSEC_INNER # IP address of IPSec virtual interface (IPsec tunnel enpoint on this TNGF)/" ${ CONFIG_FOLDER } tngfcfg . yaml 353 TNGF_LINE =$ (( TNGF_LINE +1)) 354 sed -i "" $TNGF_LINE "s/.*/ IPSecTunnelAddress : $IP_IPSEC_INNER # Tunnel IP address of XFRM interface on this TNGF /" ${ CONFIG_FOLDER } tngfcfg . yaml 355 TNGF_LINE =$ (( TNGF_LINE +1)) 356 # using @ as the delimiter on the line below as $IP_IPSEC_INNER_NET_ADDR contains a slash that will break sed functionality 357 sed -i "" $TNGF_LINE "s@.*@ UEIPAddressRange: $IP_IPSEC_INNER_NET_ADDR # IP address allocated to UE in IPSec tunnel@" ${ CONFIG_FOLDER } tngfcfg . yaml 358 echo "[ INFO ] TNGF configuration applied " 359 fi 360 361 echo "[ INFO] Reboot the machine to apply the new hostname " 362 if [ $FREE5GC_STABLE_BRANCH_CONTROL -eq 1 ]; then 363 echo "[ INFO ] Don ’t forget to configure UERANSIM using the stable 116 flag" 364 elif [ $FREE5GC_STABLE_BRANCH_CONTROL -eq 0 ]; then 365 echo "[ INFO ] Don ’t forget to configure UERANSIM using the nightly flag" 366 fi 367 echo "[ INFO ] Auto deploy script done " Source: Created by the author (2025). 117 APPENDIX C – Source of the deploy-UERANSIM.sh script As indicated in Section 4.4, this script is part of the FAD tool. The ready-to-use source code and documentation are available in a public GitHub repository (29). 1#!/ usr/ bin /env bash 2 3echo " Welcome to the UERANSIM auto deploy script " 4 5sudo -v # caches credentials 6if [ $? == 1 ] 7then 8echo "[ ERROR ] Without root permission , you cannot install the tools and the updates " 9exit 1 10 fi 11 echo "[ INFO ] Execution started " 12 13 # Control variables (1 = true , 0 = false ) 14 CONTROL_HOSTNAME=1 # switch between updating of not the hostname 15 CONTROL_STABLE=0 # switch between using the free5GC stable branch or latest nightly 16 UERANSIM_VERSION=v3.2.6 # select the stable branch tag that will be used by the script 17 UERANSIM_NIGHTLY_COMMIT=’’ # to be used to select which commit hash will be used by the script 18 19 # check the number of parameters 20 if [ $# -gt 2 ]; then 21 echo "[ ERROR ] Too many parameters given ! Check your input and try again " 22 exit 2 23 fi 24 if [ $# -lt 1 ]; then 25 echo "[ ERROR ] No parameter was given ! Check your input and try again " 26 exit 2 27 fi 28 # check the parameters and set the control vars accordingly 29 if [ $# -ne 0 ]; then 30 while [ $# -gt 0 ]; do 31 case $1 in 32 -stable) 33 CONTROL_STABLE=1 34 echo "[ INFO ] The stable branch will be cloned " 35 ;; 36 -nightly33 ) 118 37 CONTROL_STABLE=0 38 UERANSIM_NIGHTLY_COMMIT =392 b714 # last commit before new SUPI / IMSI fix one ( useful to be used with free5GC v3 .3.0) 39 echo "[ INFO ] The nightly branch to be used with free5GC v3 .3.0 or below will be cloned " 40 ;; 41 -nightly) 42 CONTROL_STABLE=0 43 # UERANSIM_NIGHTLY_COMMIT = e4c492d # commit with the new SUPI/ IMSI fix ( useful to be used with free5GC v3 .4.0 or later ) 44 # UERANSIM_NIGHTLY_COMMIT =2134 f6b # commit with the EAP - AKA ’ fix 45 UERANSIM_NIGHTLY_COMMIT =01 e3785 # commit with the Rel -17 ASN and NGAP files 46 echo "[ INFO ] The nightly branch to be used with free5GC v3 .4.0 or later will be cloned " 47 ;; 48 -keep - hostname ) 49 echo "[ INFO ] The script will not change the machine ’s hostname" 50 CONTROL_HOSTNAME=0 51 esac 52 shift 53 done 54 fi 55 56 # Hostname update 57 if [ $CONTROL_HOSTNAME -eq 1 ]; then 58 echo "[ INFO] Updating the hostname " 59 sudo sed -i "1s /.*/ ueransim /" / etc/ hostname 60 HOSTS_LINE =$( grep -n ’ 127.0.1.1 ’ / etc / hosts | awk -F: ’{ print $1} ’ -) 61 sudo sed -i "" $HOSTS_LINE"s /.*/127.0.1.1 ueransim /" / etc/ hosts 62 elif [ $CONTROL_HOSTNAME -eq 0 ]; then 63 echo "[ INFO ] Hostname update skipped this time " 64 else 65 echo "[ ERROR ] Script failed to set CONTROL_HOSTNAME variable " 66 exit 1 67 fi 68 69 ##################### 70 # Download UERANSIM # 71 ##################### 72 echo "[ INFO] Downloading UERANSIM " 73 if [ $CONTROL_STABLE -eq 1 ]; then 74 echo "[ INFO ] Cloning UERANSIM stable branch " 75 echo "[ INFO ] Tag / release : $UERANSIM_VERSION " 119 76 git clone -c advice . detachedHead = false -b $UERANSIM_VERSION https :// github . com / aligungr / UERANSIM # clones the stable build 77 cd UERANSIM 78 elif [ $CONTROL_STABLE -eq 0 ]; then 79 # first check if commit was correctly set 80 if [ -z "$UERANSIM_NIGHTLY_COMMIT" ]; then 81 echo "[ ERROR ] Script failed to set UERANSIM_NIGHTLY_COMMIT variable" 82 exit 1 83 fi 84 echo "[ INFO ] Cloning UERANSIM nightly branch " 85 echo "[ INFO ] Commit : $UERANSIM_NIGHTLY_COMMIT " 86 git clone https :// github . com / aligungr / UERANSIM 87 cd UERANSIM 88 git -c advice . detachedHead = false checkout $UERANSIM_NIGHTLY_COMMIT # clones the nightly build 89 else 90 echo "[ ERROR ] Script failed to set CONTROL_STABLE variable " 91 exit 1 92 fi 93 94 ########################## 95 # Install required tools # 96 ########################## 97 echo "[ INFO ] Downloading and installing UERANSIM prerequisites " 98 sudo apt update && sudo apt upgrade -y 99 sudo apt install -y make g ++ libsctp - dev lksctp - tools iproute2 100 sudo snap install cmake -- classic 101 102 ################## 103 # Build UERANSIM # 104 ################## 105 echo "[ INFO] Building UERANSIM " 106 make 107 cd .. 108 109 ################################ 110 # Update UERANSIM config files # 111 ################################ 112 echo "[ INFO ] Updating configuration files " 113 # Reads the data network interface IP 114 echo " Please , type the 5GC ’s DN interface IP address " 115 echo -n "> " 116 read IP_5GC 117 ip a 118 echo "Please , now enter the UERANSIM ’s N2/N3 interface IP address (e.g. IP that communicates with 5GC)" 126 APPENDIX E – Source of the deploy-tngfue.sh script As indicated in Section 4.4, this script is part of the FAD tool. The ready-to-use source code and documentation are available in a public GitHub repository (29). 1#!/ usr/ bin /env bash 2WLAN_IFACE_NAME ="wlp3s0" 3 4echo " Welcome to the TNGFUE auto deploy script " 5sudo -v # caches credentials 6if [ $? == 1 ] 7then 8echo "[ ERROR ] Without root permission , you cannot install the tools and the updates " 9exit 1 10 fi 11 echo "[ INFO ] Execution started " 12 13 # Control variables (1 = true , 0 = false ) 14 CONTROL_HOSTNAME=1 # switch between updating or not the hostname 15 CONTROL_STABLE=0 # switch between using the TNGFUE stable branch or latest nightly 16 # TNGFUE_VERSION = TODO # select the stable branch tag that will be used by the script 17 TNGFUE_NIGHTLY_COMMIT=’’ # to be used to select which commit hash will be used by the script 18 19 # check the number of parameters 20 if [ $# -gt 2 ]; then 21 echo "[ ERROR ] Too many parameters given ! Check your input and try again " 22 exit 2 23 elif [ $# -lt 1 ]; then 24 echo "[ ERROR ] No parameter was given ! Check your input and try again " 25 exit 2 26 fi 27 # check the parameters and set the control vars accordingly 28 if [ $# -ne 0 ]; then 29 while [ $# -gt 0 ]; do 30 case $1 in 31 -stable) 32 CONTROL_STABLE=1 33 # echo "[ INFO ] The stable branch will be cloned " 34 echo "[ ERROR ] No stable branch / tag available !" 35 ;; 36 -nightly) 127 37 CONTROL_STABLE=0 38 TNGFUE_NIGHTLY_COMMIT=63823f7 # commit with the new execution flow ( automated scripts ) 39 echo "[ INFO ] The nightly branch will be cloned " 40 ;; 41 -keep - hostname ) 42 echo "[ INFO ] The script will not change the machine ’s hostname" 43 CONTROL_HOSTNAME=0 44 esac 45 shift 46 done 47 fi 48 49 # Hostname update 50 if [ $CONTROL_HOSTNAME -eq 1 ]; then 51 echo "[ INFO] Updating the hostname " 52 sudo sed -i "1s /.*/ ueransim /" / etc/ hostname 53 HOSTS_LINE =$( grep -n ’ 127.0.1.1 ’ / etc / hosts | awk -F: ’{ print $1} ’ -) 54 sudo sed -i "" $HOSTS_LINE"s /.*/127.0.1.1 ueransim /" / etc/ hosts 55 elif [ $CONTROL_HOSTNAME -eq 0 ]; then 56 echo "[ INFO ] Hostname update skipped this time " 57 else 58 echo "[ ERROR ] Script failed to set CONTROL_HOSTNAME variable " 59 exit 1 60 fi 61 ####################### 62 # TNGFUE Installation # 63 ####################### 64 echo "[ INFO ] Downloading TNGFUE " 65 git clone https :// github . com / free5gc / tngfue . git 66 cd tngfue 67 git -c advice . detachedHead = false checkout $TNGFUE_NIGHTLY_COMMIT # clones the nightly build 68 echo "[ INFO ] Running the prepare .sh script " 69 ./ prepare . sh 70 71 if [ $CONTROL_HOSTNAME -eq 1 ]; then 72 echo "[ INFO] Reboot the machine to apply the new hostname " 73 fi 74 echo "[ INFO ] Don ’t forget to add the TNGFUE to free5GC via WebConsole " 75 echo "[ INFO ] See : https :// free5gc . org / guide / TNGF / tngfue - installation /#2 - use - webconsole -to -add -ue" 76 echo "[ INFO ] Auto deploy script done " Source: Created by the author (2025). 128 APPENDIX F – Source of the pcap_extract.sh script As indicated in Subsection 4.5.1, this script is part of the NWDAF_ml module. The ready-to-use source code and documentation are available in a GitHub repository (41). 1#!/ usr/ bin /env bash 2 3TRAINING_PCAP_FOLDER =./ pcap / input / training_data / # read training raw PCAP files from here 4INFERENCE_PCAP_FOLDER =./ pcap / input / inference_data / # read inference raw PCAP files from here 5OUT_FOLDER =./ pcap / output /1PCAP - export/# save the output there 6 7# set IFS to break only on new line (so the input files can have white space on their names ) 8# for more info : https :// www. linuxquestions . org / questions / programming -9/ bash -put - output - from -%60 ls %60 - into -an - array -346719/# post1765355 9IFS=’ 10 ’ 11 12 TRAINING_PCAP_LIST =("$TRAINING_PCAP_FOLDER"*. pcap) 13 INFERENCE_PCAP_LIST=(" $INFERENCE_PCAP_FOLDER "*. pcap ) 14 15 # Check if folder is empty , if yes , delete the related var to avoid " file not found " errors 16 if [[ "$TRAINING_PCAP_LIST" == *"*"* ]]; then 17 # TRAINING_PCAP_LIST ="" 18 unset TRAINING_PCAP_LIST 19 elif [[ "$INFERENCE_PCAP_LIST" == *"*"* ]]; then 20 # INFERENCE_PCAP_LIST="" 21 unset INFERENCE_PCAP_LIST 22 fi 23 24 # Then calculate these sizes after that 25 TRAINING_PCAP_LIST_SIZE=${# TRAINING_PCAP_LIST [@]} 26 INFERENCE_PCAP_LIST_SIZE=${#INFERENCE_PCAP_LIST[@]} 27 TOTAL_LIST_SIZE =$(( TRAINING_PCAP_LIST_SIZE + INFERENCE_PCAP_LIST_SIZE )) 28 29 # TIME_START =$( date +%s) # record start time 30 31 # PCAP to JSON and CSV 32 extract_JSON_and_CSV () { 33 local FILE_NAME =$1 34 local PCAP_FOLDER=$2 35 local OUT_FOLDER =$3 36 local SET_SPLIT_TAG =$4 37 129 38 echo "[ INFO] Extracting data from $FILE_NAME " 39 40 tshark -r $PCAP_FOLDER$FILE_NAME -T json > $OUT_FOLDER /"${ FILE_NAME %.*} _$SET_SPLIT_TAG . json" && \ 41 tshark -r $PCAP_FOLDER$FILE_NAME -T fields \ 42 -e frame . number -e frame . time_relative -e ip. src -e ip. dst -e _ws . col. protocol -e frame . len -e _ws .col . info \ 43 -E header =y -E separator =, -E quote =d -E occurrence =f \ 44 > $OUT_FOLDER/"${ FILE_NAME %.*} _$SET_SPLIT_TAG . csv " 45 # To customize the "-e flags " ( display filters ) , see https :// www . wireshark . org / docs / dfref / 46 # For more information : https :// manpages . ubuntu . com / manpages / jammy / man1 / tshark .1. html 47 } 48 49 # JSON field remover 50 field_remover () { 51 local FILE_NAME =$1 52 local OUT_FOLDER =$2 53 54 echo "[ INFO ] Removing unused fields from $FILE_NAME " 55 # GNU AWK ( gawk) was used instead of AWK because of this regex support 56 gawk -i inplace ’/\[/ || /\]/ || /\{/ || /\}/ || /" _source ":/ || 57 /" frame . number ":/ || /" frame . time_delta ":/ || /" frame . time_relative ":/ || 58 /" ip. src ":/ || /" ip .dst ":/ || /" frame . encap_type ":/ || /" frame . len ":/ || 59 /" ip. hdr_len ":/ || /" udp . length ":/ || /" tcp. len ":/ || /" udp . srcport ":/ || 60 /" tcp . srcport ":/ || /" udp . dstport ":/ || /" tcp . dstport ":/ || 61 /" tcp . completeness *"/ || /" tcp .flags ":/ || /" tcp .str ":/ || 62 /" tcp . window_size ":/ || /" tcp . window_size_scalefactor ":/ || 63 /" frame . protocols ":/ || /" ip . proto ":/ || /" ip . flags ...":/ || /" ip . ttl ":/ || 64 /" tcp. hdr_len ":/ || /" data .len ":/ || /" quic . packet_length ":/ || /" quic . length ":/ 65 ’$OUT_FOLDER$FILE_NAME 66 # Some regex pattern explanation 67 # first line of the pattern matches the JSON structure header that must be kept 68 # all the other pattern lines match lines that contain data to be used on next steps 69 # everything else that is not matched , will be deleted to free disk space 70 } 71 130 72 # JSON parser to reconstruct its structure 73 json_parser () { 74 local FILE_NAME =$1 75 local OUT_FOLDER =$2 76 FILE_NAME_TMP = $FILE_NAME " _tmp" 77 78 echo "[ INFO] Parsing fields from $FILE_NAME " 79 # Parses the JSON using the Perl module to remove illegal trailing commas and to reformat it 80 perl -MJSON -e ’ @text =( <>); print to_json ( from_json (" @text ", { relaxed = >1}) , { pretty = >1}) ’ $OUT_FOLDER$FILE_NAME > $OUT_FOLDER$FILE_NAME_TMP 81 # the Perl source code above was based on this StackOverflow answer : https :// unix . stackexchange . com /a /485011 82 # As I couldn ’t find an easy way to process the file in place , I’ve added a tem file to save the result then used mv to overwrite the original 83 mv $OUT_FOLDER$FILE_NAME_TMP $OUT_FOLDER$FILE_NAME 84 } 85 86 time { # track execution time 87 echo "[ INFO ] Exporting $TRAINING_PCAP_LIST_SIZE training and $INFERENCE_PCAP_LIST_SIZE inference PCAP files" 88 if [ $TRAINING_PCAP_LIST_SIZE -ne 0 ]; then 89 for iin "${ TRAINING_PCAP_LIST [@]} ";do 90 extract_JSON_and_CSV "${i ##*/} " $TRAINING_PCAP_FOLDER $OUT_FOLDER " training " & 91 done 92 fi 93 if [ $INFERENCE_PCAP_LIST_SIZE -ne 0 ]; then 94 for jin "${INFERENCE_PCAP_LIST[@]}";do 95 extract_JSON_and_CSV "${j ##*/} " $INFERENCE_PCAP_FOLDER $OUT_FOLDER " inference " & 96 done 97 fi 98 wait 99 unset TRAINING_PCAP_LIST # clean up after usage 100 unset INFERENCE_PCAP_LIST_SIZE # clean up after usage 101 echo "[ INFO] All $TOTAL_LIST_SIZE files have been successfully exported " 102 103 JSON_LIST =("$OUT_FOLDER"*. json ) 104 JSON_LIST_SIZE=${# JSON_LIST [@ ]} 105 106 # Drop duplicated fields on JSON 107 echo "[ INFO ] Preprocessing entries from $JSON_LIST_SIZE JSON files " 108 if [ $JSON_LIST_SIZE -ne 0 ]; then 109 for iin "${ JSON_LIST [@ ]}";do 131 110 field_remover "${i ##*/} " $OUT_FOLDER & 111 done 112 wait 113 for iin "${ JSON_LIST [@ ]}";do 114 # this step uses a lot of RAM , that ’s why it ins ’t run in parallel 115 json_parser "${i ##*/} " $OUT_FOLDER 116 done 117 else 118 echo "[ ERRO ] No JSON files found in the directory : $OUT_FOLDER " 119 exit 1 120 fi 121 unset JSON_LIST # clean up after usage 122 echo "[ INFO] All $TOTAL_LIST_SIZE files have been processed " 123 124 echo "[ DEBU ] Execution time :" 125 } 126 127 # TIME_END =$( date +%s) # record end time 128 # echo "[ DEBU ] Execution time : $(( TIME_END - TIME_START )) seconds " Source: Created by the author (2025). 132 APPENDIX G – Source of the dataset_CSV_characterization.py script As indicated in Subsection 4.5.1, this script is part of the NWDAF_ml module. The ready-to-use source code and documentation are available in a GitHub repository (41). 1import csv 2import traceback 3import sys 4import pandas as pd 5import os 6import glob 7import time 8 9from util import read_csv 10 11 def extract_frequency_info ( data_frames , column_names ): 12 freq_data_list = [] 13 14 for df in data_frames: 15 try: 16 # Use value_counts to get the frequency of each unique value in the specified columns 17 frequency_info = { column : df[ column ]. value_counts () for column in column_names} 18 freq_data_list.append(frequency_info) 19 except KeyError as ke: 20 missing_columns = [col for col in column_names if col not in df . columns ] 21 print (f" Error : Columns { missing_columns } not found in the DataFrame .") 22 exit () 23 except Exception as e: 24 # printing stack trace 25 traceback . print_exception (* sys. exc_info () ) 26 print ("[ ERROR ]" ,type(e).__name__ , e) 27 exit () 28 29 return freq_data_list 30 31 def print_and_save_frequency_data ( freq_data_list ): 32 for counter , item in enumerate ( freq_data_list , start =1) : 33 # print ("[ DEBU ] Frequency data extracted from data frame number ", counter ) # DEBUG 34 for column_name , freq_series in item . items (): 35 file_name_without_format = os. path . splitext ( input_files_names [ counter - 1]) [0] # remove ’. csv ’ from old file name 36 freq_series . to_csv (os . path . join ( output_files_path , 133 file_name_without_format + "." + column_name + ". csv ")) 37 # print (f "[ DEBU ] Frequency information for { column_name } of { file_name_without_format }:\ n { freq_series }") # DEBUG 38 # print ("[ DEBU ] Finished printing data frame ", counter ) # DEBUG 39 40 def save_time_data(df_list): 41 # Extract the two columns related to time from each DataFrame 42 for counter , time_df in enumerate (df_list): 43 extracted_cols = pd. DataFrame () 44 extracted_cols = (time_df[[" frame . number " ," frame . time_relative " ]]) 45 file_name_without_format = os. path . splitext ( input_files_names [ counter - 1]) [0] # remove ’.csv ’ from old file name 46 extracted_cols . to_csv ( os. path .join ( output_files_path , file_name_without_format + ". time_series . csv ") , index = False ) 47 48 # File paths 49 input_files_path = " ./ pcap / output /1 -PCAP - export /" # read CSV files from here 50 output_files_path = "./ pcap / output /2 - stats /" # save the output there 51 52 print ("[ INFO] Creating statistical data ") 53 start_time = time. time () # record the start of execution 54 55 # get the list of all CSV files in the input directory 56 input_files_names = [f for fin os. listdir ( input_files_path ) if f. endswith(’. csv ’)] 57 # input_files_names = [f for f in os. listdir ( input_files_path ) if f. endswith (’ test .csv ’) | f. endswith ( ’5 g1.csv ’)] # initial tests 58 # create a list of file paths by joining the input directory path with each file name 59 input_file_paths = [os. path. join( input_files_path , f) for fin input_files_names] 60 61 # Read CSV files 62 input_dfs = [ read_csv ( path) for path in input_file_paths] 63 64 # check if at least one file was found 65 if len( input_dfs ) == 0: 66 print (f"[ ERROR ] No CSV file found on { input_files_path }") 67 exit () 68 69 # Extract frequency information 70 # as the features are the same on all files , no need to do that for all of them 71 column_names = input_dfs [0]. columns . tolist () 72 # removes some columns from the frequency calculation because they 134 almost always have only unique values 73 columns_to_remove = [" frame . number " ," frame . time_relative " ,"_ws.col. info"] 74 75 for col in columns_to_remove: 76 column_names . remove ( col ) 77 78 input_freq_data_list = extract_frequency_info ( input_dfs , column_names ) 79 80 # Print frequency information 81 print_and_save_frequency_data ( input_freq_data_list ) 82 save_time_data(input_dfs) 83 print ("[ INFO] Creating statistical data successfully finished ") 84 end_time = time. time () # record the end of execution 85 print (f"[ DEBU ] Execution time : {( end_time - start_time )} s") Source: Created by the author (2025). 135 APPENDIX H – Source of the stat-plotter.py script As indicated in Subsection 4.5.1, this script is part of the NWDAF_ml module. The ready-to-use source code and documentation are available in a GitHub repository (41). 1import csv 2import pandas as pd 3import numpy as np 4import os 5import matplotlib . pyplot as plt 6import time 7 8from util import read_csv 9 10 def update_font_size(f_size): 11 font_size = f_size # base font size 12 # Update rcParams to make fonts larger 13 plt. rcParams [’font.size’] = font_size 14 plt. rcParams [’axes . labelsize ’] = font_size + 2 15 plt. rcParams [’axes . titlesize ’] = font_size + 4 16 plt. rcParams [’ xtick . labelsize ’] = font_size 17 plt. rcParams [’ ytick . labelsize ’] = font_size 18 19 # Create chart for each DataFrame 20 def plot_graph ( df_to_plot , input_file_name , column_label , x_label , y_label , plt_type ): 21 for i, df in enumerate ( df_to_plot ): 22 23 # Adjust plot parameters according to each plot type 24 if ( plt_type == ’dozens -of - bars ’): 25 plt. figure ( figsize =(15 , 6)) # Set figure size 26 update_font_size(15) 27 sorted_df = df. sort_values (by= column_label ) # sort data before plotting 28 # plt .plot ( sorted_df [ column_label ], sorted_df [’ count ’], marker =’.’, linestyle = ’: ’) # line plot 29 plt.bar( sorted_df [ column_label ], sorted_df [’count ’]) # bar plot 30 31 # Calculate mean , median and mode 32 mean_value = df[ ’ frame . len ’]. mean () 33 median_value = df[’ frame . len ’]. median () 34 mode_value = df[ ’ frame . len ’][0] 35 36 # Statistical bars configuration 37 bar_max_height = sorted_df[’count ’]. max() # get the highest height value on the plot 142 APPENDIX J – Source of the json2csv.py script As indicated in Subsection 4.5.1, this script is part of the PCAP-dataExtractor module. The ready-to-use source code is available in a GitHub repository (122). 1import json 2import pandas as pd 3import os 4import sys 5 6def swap_special_chars_to_underscore(input_string): 7result = ’’ # to store the output 8 9# Check if the character is alphanumeric 10 # If alphanumeric , add the character to the result string 11 # If not alphanumeric , add an underscore to the result string 12 for char in input_string: 13 if char . isalnum (): 14 result += char 15 else: 16 result += ’_’ 17 18 return result 19 20 def progressBar ( count_value , total , slow_print , suffix = ’’): 21 """ 22 A simple and tidy progress bar to track status 23 """ 24 # Adapted from : https :// www . geeksforgeeks . org /progress -bars -in - python/ 25 bar_length = 25 26 filled_up_Length = int(round ( bar_length * count_value / float ( total )) ) 27 percentage = round (100.0 * count_value / float ( total ) ,1) 28 bar = ’=’ * filled_up_Length + ’ ’ * ( bar_length - filled_up_Length ) 29 30 # This new way of printing improves when using parallelization 31 # if on slow mode and file is large , update for each 1k packets 32 # if on slow mode and file is medium sized , update for each 100 packets 33 # else if on slow mode and file is small , update for each 10 packets 34 # else if not on slow mode , update at every packet (the original way ) 35 # else don ’t do anything (i.e. skip ) 36 if ( slow_print and total >= 10000 and count_value % 1000 == 0): 37 sys. stdout . write ( ’[%s] %s%s: %s\n’ %(bar , percentage , ’%’, suffix)) 143 38 elif ( slow_print and total > 1000 and total < 10000 and count_value % 100 == 0): 39 sys. stdout . write ( ’[%s] %s%s: %s\n’ %(bar , percentage , ’%’, suffix)) 40 elif ( slow_print and total <= 1000 and count_value % 10 == 0): 41 sys. stdout . write ( ’[%s] %s%s: %s\n’ %(bar , percentage , ’%’, suffix)) 42 elif (not slow_print ): 43 sys. stdout . write ( ’[%s] %s%s: %s\r’ %(bar , percentage , ’%’, suffix)) 44 45 def parse ( input_file_path , output_folder , print_control = False ): 46 """ 47 A function to parse JSON PCAP - style files to a CSV format 48 """ 49 # check if path is empty then ask user to provide it 50 if (not input_file_path ): 51 print ("[ ERRO] The file path was not provided !") 52 print ("[ INFO] Please , provide the file path below ") 53 input_file_path = input ("> ") 54 55 file_path_without_format = os. path . splitext ( input_file_path ) [0] # remove ’. json ’ from old file name 56 file_name_without_format = file_path_without_format.split("/") 57 file_name_without_format = file_name_without_format[len( file_name_without_format)-1] # get the clean file name only 58 new_file_name = file_name_without_format + ’. csv ’ 59 new_file_with_path = output_folder + new_file_name 60 61 JSON_data = open( input_file_path ). read () 62 print (f"[ INFO] JSON file { file_name_without_format } opened successfully") 63 JSONArray = json . loads ( JSON_data ) 64 print ("[ INFO ] JSON data imported successfully ") 65 66 length = len( JSONArray ) 67 print ("[ DEBU]", length , " data frames to be converted from ", file_name_without_format) # DEBUG 68 69 labels = [’ Packet_no ’,’Timestamp ’,’Time_delta ’,’Source_IP ’,’ Destination_IP’,’Frame_type ’,’ Frame_total_length ’,’ Frame_header_length’, 70 ’Frame_payload_length’,’Source_port’,’Destination_port’,’ TCP_completeness’,’ TCP_compl_reset ’,’TCP_compl_fin ’,’TCP_compl_data’, 71 ’TCP_compl_ack ’,’TCP_compl_syn_ack’,’TCP_compl_syn ’,’ TCP_compl_str ’,’ TCP_flags_bin ’,’ TCP_flags_str ’,’ TCP_window_size ’, 72 ’TCP_window_size_scale’,’Frame_protocols ’,’IP_protocols’,’ 144 IP_flag_reserved_bit’,’IP_flag_dont_fragment’,’IP_flag_more_fragments ’, 73 ’TTL ’,’TCP_header_length’,’Data_length’,’ QUIC_packet_length ’,’QUIC_length’] 74 75 df = pd. DataFrame ( columns = labels ) 76 df. to_csv ( new_file_with_path , header = True , index = False ) 77 for obj in range (length): 78 79 try: 80 pkt_number = JSONArray [ obj ][ ’_source’][ ’layers’][ ’frame ’][ ’ frame . number ’] 81 except Exception : 82 timestamp = None 83 84 try: 85 timestamp = JSONArray [obj ][ ’_source’][ ’layers’][ ’frame ’][ ’ frame . time_relative ’] 86 except Exception : 87 timestamp = None 88 89 try: 90 time_since_last_pkt = JSONArray [ obj ][ ’_source’][ ’layers’][ ’ frame ’][ ’frame . time_delta ’] 91 except Exception : 92 time_since_last_pkt = None 93 94 try: 95 ipv4_ip_src = JSONArray [ obj ][ ’_source’][ ’layers’][ ’ip ’][ ’ip .src ’] 96 except Exception : 97 ipv4_ip_src = None 98 99 try: 100 ipv4_ip_dst = JSONArray [ obj ][ ’_source’][ ’layers’][ ’ip ’][ ’ip. dst ’] 101 except Exception : 102 ipv4_ip_dst = None 103 104 try: 105 frame_type = JSONArray [ obj ][ ’_source’][ ’layers’][ ’frame ’][ ’ frame . encap_type ’] 106 except Exception : 107 frame_type = None 108 # more info on that : https :// gitlab . com / wireshark / wireshark / -/ blob / master / wiretap / wtap .h# L87 109 145 110 try: 111 frame_len = JSONArray [obj ][ ’_source’][ ’layers’][ ’frame ’][ ’ frame . len ’] 112 except Exception : 113 frame_len = None 114 115 try: 116 header_len = JSONArray [ obj ][ ’_source’][ ’layers’][ ’ip ’][ ’ip. hdr_len’] 117 except Exception : 118 header_len = None 119 120 try: 121 payload_len = JSONArray [ obj ][ ’_source’][ ’layers’][ ’udp ’][ ’ udp. length ’] 122 except Exception : 123 try: 124 payload_len = JSONArray [ obj ][ ’_source’][ ’layers’][ ’tcp ’ ][ ’tcp.len ’] 125 except Exception : 126 payload_len = None 127 128 try: 129 src_port = JSONArray [ obj ][ ’_source’][ ’layers’][ ’udp ’][ ’udp. srcport’] 130 except Exception : 131 try: 132 src_port = JSONArray [ obj ][ ’_source’][ ’layers’][ ’tcp ’][ ’ tcp. srcport ’] 133 except Exception : 134 src_port = None 135 136 try: 137 dst_port = JSONArray [ obj ][ ’_source’][ ’layers’][ ’udp ’][ ’udp. dstport’] 138 except Exception : 139 try: 140 dst_port = JSONArray [ obj ][ ’_source’][ ’layers’][ ’tcp ’][ ’ tcp. dstport ’] 141 except Exception : 142 dst_port = None 143 144 # TCP only begin # 145 try: 146 tcp_completeness = JSONArray [ obj ][ ’_source’][ ’layers’][ ’tcp ’ ][ ’tcp.completeness’] 147 except Exception : 146 148 tcp_completeness = None 149 150 # TODO forcibly convert these " completeness flags " to int or bool 151 try: 152 tcp_completeness_reset = JSONArray [ obj ][ ’_source’][ ’layers’ ][ ’tcp ’][ ’tcp.completeness_tree’][ ’tcp. completeness . rst ’] 153 except Exception : 154 tcp_completeness_reset = None 155 156 try: 157 tcp_completeness_fin = JSONArray[obj][’_source’][ ’layers’][ ’ tcp ’][ ’tcp.completeness_tree’][ ’tcp. completeness . fin ’] 158 except Exception : 159 tcp_completeness_fin = None 160 161 try: 162 tcp_completeness_data = JSONArray [ obj ][ ’_source’][ ’layers’][ ’tcp ’][ ’tcp.completeness_tree’][ ’tcp. completeness . data ’] 163 except Exception : 164 tcp_completeness_data = None 165 166 try: 167 tcp_completeness_ack = JSONArray[obj][’_source’][ ’layers’][ ’ tcp ’][ ’tcp.completeness_tree’][ ’tcp. completeness . ack ’] 168 except Exception : 169 tcp_completeness_ack = None 170 171 try: 172 tcp_completeness_syn_ack = JSONArray [ obj ][ ’_source’][ ’layers ’][ ’tcp ’][ ’tcp.completeness_tree’][ ’tcp. completeness .syn - ack ’] 173 except Exception : 174 tcp_completeness_syn_ack = None 175 176 try: 177 tcp_completeness_syn = JSONArray[obj][’_source’][ ’layers’][ ’ tcp ’][ ’tcp.completeness_tree’][ ’tcp. completeness . syn ’] 178 except Exception : 179 tcp_completeness_syn = None 180 181 try: 182 tcp_completeness_str = JSONArray[obj][’_source’][ ’layers’][ ’ tcp ’][ ’tcp.completeness_tree’][ ’tcp. completeness . str ’] 183 # if ( tcp_completeness_str == "[ Null ]") : # TODO check if this won ’t break anything 184 # tcp_completeness_str = None 185 tcp_completeness_str = ’’. join ( filter(str. isalnum , 147 tcp_completeness_str)) 186 except Exception : 187 tcp_completeness_str = None 188 189 try: 190 tcp_flags_hex = JSONArray [ obj ][ ’_source’][ ’layers’][ ’tcp ’][ ’ tcp. flags ’] 191 # if needed , adjust 010 b and 10 to the desired length below 192 # see alternatives here : https :// www. geeksforgeeks . org / python -ways -to - convert -hex -into - binary / 193 tcp_flags_bin = " {0:010 b}".format(int(str( tcp_flags_hex ) , 10)) 194 except Exception : 195 tcp_flags_bin = None 196 197 try: 198 tcp_flags_str = JSONArray [ obj ][ ’_source’][ ’layers’][ ’tcp ’][ ’ tcp. flags_tree ’][ ’tcp. flags . str ’] 199 tcp_flags_str = ’’. join ( filter(str.isalnum , tcp_flags_str )) 200 except Exception : 201 tcp_flags_str = None 202 203 try: 204 tcp_window_size = JSONArray [ obj ][ ’_source’][ ’layers’][ ’tcp ’ ][ ’tcp. window_size ’] 205 except Exception : 206 tcp_window_size = None 207 208 try: 209 tcp_window_size_scalefactor = JSONArray [ obj ][ ’_source’][ ’ layers’][ ’tcp ’][ ’tcp. window_size_scalefactor ’] 210 except Exception : 211 tcp_window_size_scalefactor = None 212 # TCP only end # 213 214 try: 215 frame_protocols = JSONArray [ obj ][ ’_source’][ ’layers’][ ’frame ’][ ’ frame . protocols ’] 216 frame_protocols = ’’. join ( filter(str.isalnum, frame_protocols )) 217 # filter just erases all special chars , to keep the strings human readable , it ’s better to swap the chars instead 218 # frame_protocols = swap_special_chars_to_underscore( frame_protocols ) # TODO test the performance of using this function 219 except Exception : 220 frame_protocols = None 221 148 222 try: 223 ip_protocols = JSONArray [ obj ][ ’_source’][ ’ layers ’][ ’ip ’][ ’ip . proto ’] 224 except Exception : 225 ip_protocols = None 226 227 try: 228 ip_flag_reserved_bit = JSONArray[obj][’_source’][ ’layers’][ ’ ip ’][ ’ip. flags_tree ’][ ’ip. flags . rb ’] 229 except Exception : 230 ip_flag_reserved_bit = None 231 232 try: 233 ip_flag_dont_fragment = JSONArray [ obj ][ ’_source’][ ’layers’][ ’ip ’][ ’ip. flags_tree ’][ ’ip. flags . df ’] 234 except Exception : 235 ip_flag_dont_fragment = None 236 237 try: 238 ip_flag_more_fragments = JSONArray [ obj ][ ’_source’][ ’layers’ ][ ’ip ’][ ’ip. flags_tree ’][ ’ip . flags . mf ’] 239 except Exception : 240 ip_flag_more_fragments = None 241 242 try: 243 ip_ttl = JSONArray [ obj ][ ’_source’][ ’layers’][ ’ip ’][ ’ip. ttl ’] 244 except Exception : 245 ip_ttl = None 246 247 # TCP only begin # 248 try: 249 tcp_header_length = JSONArray [ obj ][ ’_source’][ ’layers’][ ’tcp ’][ ’ tcp . hdr_len ’] 250 except Exception : 251 tcp_header_length = None 252 # TCP only end # 253 254 # UDP only begin # 255 try: 256 data_length = JSONArray [ obj ][ ’_source’][ ’layers’][ ’data ’][ ’ data .len ’] 257 except Exception : 258 data_length = None 259 # UDP only end # 260 261 # QUIC only begin # 262 try: 149 263 quic_packet_length = JSONArray [ obj ][ ’_source’][ ’layers’][ ’ quic’][ ’ quic . packet_length ’] 264 except Exception : 265 quic_packet_length = None 266 267 try: 268 quic_length = JSONArray [ obj ][ ’_source’][ ’layers’][ ’quic ’][ ’ quic . length ’] 269 except Exception : 270 quic_length = None 271 # QUIC only end # 272 273 record = [( pkt_number , timestamp , time_since_last_pkt , ipv4_ip_src , ipv4_ip_dst , frame_type , frame_len , 274 header_len , payload_len , src_port , dst_port , tcp_completeness , tcp_completeness_reset , 275 tcp_completeness_fin , tcp_completeness_data , tcp_completeness_ack , tcp_completeness_syn_ack , 276 tcp_completeness_syn , tcp_completeness_str , tcp_flags_bin , tcp_flags_str , tcp_window_size , 277 tcp_window_size_scalefactor , frame_protocols , ip_protocols , ip_flag_reserved_bit , 278 ip_flag_dont_fragment , ip_flag_more_fragments , ip_ttl, tcp_header_length , data_length , 279 quic_packet_length , quic_length )] 280 281 df = pd. DataFrame . from_records ( record , columns = labels ) 282 with open( new_file_with_path , ’a’, encoding =’utf -8 ’) as f: 283 # old way of reporting status , commented to avoiding flooding the stdout 284 # print ("[ INFO ] Writing dataframe ", obj , " of", length , "(" , round (obj *100/ length , 1) ,"% ) to CSV ") 285 progressBar (obj , length , print_control , f"Writing { new_file_name }") 286 df. to_csv (f, header =False , index = False ) 287 288 print ("\n[ INFO] All", length , " records from " , new_file_name , "were successfully written ") 289 # print ("[ DEBU ] Columns of CSV are", list (df)) # DEBUG 290 # parse ("" , "./") # Enable this line to run in " stand alone " mode (e.g. not importing as python module ) Source: Created by the author (2025). 150 APPENDIX K – Source of the box-plotter.py script As indicated in Subsection 4.5.1, this script is part of the NWDAF_ml module. The ready-to-use source code and documentation are available in a GitHub repository (41). 1import pandas as pd 2import matplotlib . pyplot as plt 3import time 4import os 5 6from util import glob_get_files_list 7 8# File paths 9input_files_path = " ./ pcap / output /3 -JSON - export /" # read CSV files from here 10 output_files_path = "./ pcap / output /3 - JSON - export /box - plots /" # save the output there 11 12 def plot_box_plot ( file_path ): 13 # Read the CSV file 14 df = pd. read_csv ( file_path ) 15 input_file_name = os . path . splitext ( file_path . split ( ’/’) [ -1]) [0] 16 17 # If needed , drop some columns 18 # df . drop ( columns =[" TCP_window_size "] , axis =1, inplace = True ) # drop TCP window size because of its size 19 20 df . boxplot ( vert =False , figsize =(6 ,8) ) 21 plt. title ( input_file_name + ’ box plot ’) 22 plt. xscale ("symlog") 23 # plt. subplots_adjust ( left =0.28) 24 plt.tight_layout() 25 # Reference for the layout adjustment : https :// stackoverflow . com /a /18500068 26 27 full_output_path = output_files_path + input_file_name + ’. pdf ’ 28 plt. savefig ( full_output_path , bbox_inches = ’tight ’, pad_inches =0, dpi =120) 29 print ("[ INFO] Box plot sucessfully saved on", full_output_path) 30 31 # plt. show () # DEBUG 32 plt. close () # close each figure after finishing to enable multiple runs 33 34 start_time = time. time () # record the start of execution 35 36 # List of CSV files 151 37 csv_files = glob_get_files_list ( input_files_path , "csv") 38 39 for iin csv_files : 40 try: 41 plot_box_plot (i) 42 except AssertionError as e: 43 print ("[ ERRO] Could not parse ", i, "due to", e) 44 end_time = time. time () # record the end of execution 45 print (f"[ DEBU] Execution time : { end_time - start_time } s") Source: Created by the author (2025).