 So, thank you for being present today for our presentation on 5G CNF observability based on EBPF. So I will start by presenting myself. I'm Abdaraouf Kishan, I'm PhD student in Orange Labs and Paris Sackley University. I specify that this presentation was prepared jointly with Ilhan Fajari who is a research project leader on cloud native network functions orchestration in Orange Labs. Unfortunately, she cannot be present today due to health conditions. Okay, so for the plan of this presentation, I will start by presenting the challenges and the objective of our work, then I will present our EBPF based solution for the observability of 5G cloud native network functions. Finally, I will describe the experimentations we did with our solution before concluding the presentation. Okay, so our work is mainly related to 5G and the observability of its network functions. So as you see, the 5G architecture is highly distributed. So that means that in order to provide an end-to-end functionality, multiple network functions will be involved. And so it is useful to, it is important to monitor the traffic, the network traffic between these network functions. First to ensure a good level of performance by tracking, for example, the error rate and request processing, but also to get information about the global state of the 5G system, like for example, the number of attached users and the number of created PDU sessions. So in order to provide functionalities, 5G network functions communicate with each order using a variety of protocols. So some of them are originating from IT, like HTTP, for example, while others are telco-specific and are defined by 3GPP specifications like NGAP and PFCP for scenic messages and GTPU to forward the end-users traffic. Okay, so around these context and challenges, the main objective of our work is to implement the framework for the observability of network traffic between 5G cloud-native network functions or 5G CNFs. The idea behind that is to sniff the traffic, perform protocol analysis and expose metrics. While designing our solution, we are considering the open source ecosystem. So our solution is designed to be deployed on top of the Kubernetes platform, which is used for the orchestration of cloud-native network functions in general. Besides, we are leveraging Prometheus and Grafana for collecting, storing and visualizing metrics. Finally, we are using EBPF. So EBPF is a technology which is originated from the Linux kernel, and it allows to run event-driven programs based on specific events. Okay, so now let's give an overview of our solution. So as already mentioned, our solution works on top of Kubernetes platform and allows to monitor the traffic between Kubernetes ports that belong to a 5G network service. To do so, we developed two components. First, the controller is managed by a Kubernetes deployment and is responsible of discovering Kubernetes ports by communicating with the IPI server. Secondly, the filter is managed by a Daemon set, Kubernetes Daemon set, and so it is present on each node within the Kubernetes cluster. I will give more details on each role, but all you have to know, for instance, is that it is responsible of monitoring the traffic between the discovered ports and exposing metrics. This metrics can be then scrapped by Prometheus and displayed on the Grafana dashboards. So now let's focus on our filter. So we used Python to develop it, and we are also using the BCC framework, which is providing a library allowing to manage eBPF programs. So I will call this our user space program. It will, based on the information provided by the controller, it will attach eBPF programs to network interfaces on the worker node and which are linked to network interfaces on the port. So I specify that also we can monitor the traffic. We can monitor ports with multiple network interfaces. These eBPF programs will continuously filter 5G network events and send them again to the user space program. The latter will perform protocol analysis to extract information dependent on the protocol, and then will display logs and expose metrics. So to test our solution, we made use of 5G open-source projects, including Free5GC and Open5GS for the core network part. And we are also using UNSIM, which is a project providing a simulation of 5G node B and UE to trigger the exchange of network messages. In this slide, we can see examples of metrics that we are exposing with our solution. So the first one is, in general, the metrics for request and response-based protocols. We are tracking the total number of requests, the total number of responses, and the response time. These metrics are labelled by the server and client context. So a context includes the name of the port, the name of the interface, the IP address, the name of the deployment, the port belonging to, and other labels which are related to the protocol itself. Like for example, for PFCP, the message, the type of the message, and also the codes which represent the state of the response. So it can be a success or the codes of errors, of the error in case of errors. For other protocols like GTPU, we are tracking the total number of messages, the total number of bytes, but also the forwarding time. So for the UPF, for example, it acts like a router which forward the messages from an interface to another one. And so we are tracking this time. To conclude this presentation, in this talk, I described our solution for the observability of 5GCNFs based on EBPF. There is an in-progress work to test our solution with a large amount of data by triggering the simulation of a large number of user equipments. And also to handle encrypted traffic, mainly the protocol, HTTPS. Later we aim to test our solution with data acceleration technologies for the UPF, like for example when SRUV is used for the UPF. And also to liberate the exposed metrics and logs using artificial intelligence. So by the end of this presentation, I would like to thank you for your attention, and I'm available for any question or remark.