Perception Offloading for Autonomous Mobility in a Beyond-5G Edge-enabled Environment

Perception Offloading for Autonomous Mobility in a Beyond-5G Edge-enabled Environment Tiago Mostardinha∗†, João Gameiro∗†, Pedro Valente∗†, Pedro Rito∗†, Duarte Raposo∗, Susana Sargento∗†, Carlos Marques‡, Miguel Mesquita‡, Filipe Pinto‡ ∗Instituto de Telecomunicações, 3810-193 Aveiro, Portugal †Departamento de Eletrónica, Telecomunicações e Informática, Universidade de Aveiro, 3810-193 Aveiro, Portugal ‡Altice Labs, 3810-106 Aveiro, Portugal Abstract—In this paper, we propose an architecture integrating Multi-access Edge Computing (MEC) nodes into 5G base stations and roadside units to enable dynamic service orchestration for on-demand perception offloading. In this approach, computeintensive perception tasks, such as object detection, are instantiated as services on nearby edge nodes, with resources being allocated adaptively based on the locations and trajectories of the vehicles. The system was designed to support user mobility through service replication and seamless handovers between perception service instances in different edge nodes as vehicles move across coverage areas, ensuring continuous service delivery and Quality of Service (QoS) guarantees. We evaluate the proposed architecture in a real-world 5G edge-enabled testbed using an autonomous vehicle running an object detection service. The results demonstrate that offloading perception via 5G and MEC yields substantially lower processing latency, and that smart orchestration mechanisms are able to react to user mobility and platform stress situations, avoiding service degradation, thus validating the approach for Cooperative, Connected, and Automated Mobility (CCAM) use cases. Index Terms—Edge Offloading, 5G Networks, Vehicular Services, Autonomous Mobility I. INTRODUCTION The growing number of sensing devices in smart cities, ranging from roadside cameras to vehicle sensors, has generated a wide variety of mobility and sensing data that, when processed in real-time, can be leveraged to optimize urban traffic management, enhance road safety, and support datadriven decision-making for city planning. However, traditional cloud solutions are not well-suited for these applications. They struggle to meet the strict ultra-low latency and reliability requirements of vehicular systems, since accessing remote processing facilities that host cloud services inherently involves higher latency [1]. This makes them unsuitable for critical vehicular applications that demand real-time or near-real-time processing [1]. To address this limitation, 5G systems integrated with MEC have emerged as powerful enablers of mobility-aware services. MEC reduces latency and backhaul traffic by bringing the computation closer to the network edge [2]. 5G provides seamless mobility support and QoS guarantees through network slicing and programmable interfaces for resource control. These concepts are crucial to deliver smart city services capable of adapting to user mobility and the conditions of the city’s infrastructure, while maintaining appropriate QoS levels and ensuring efficient resource management [2]. Examples of smart city services include tasks in connected and autonomous vehicles (CAVs) that rely on object detection, tracking, and other perception-related computations. Often, these tasks require substantial processing power that exceeds the capabilities of individual vehicles which are crucial in the Cooperative, Connected, and Automated Mobility (CCAM) scenarios that involve connected Onboard Units (OBUs) offering critical services in the areas of road safety and autonomous operation [3]. By offloading these computing-intensive and latency-sensitive tasks to more capable edge devices, CAVs can access richer, more accurate environmental information while maintaining real-time performance [4]. However, one of the challenges of offloading these CCAM applications for 5G-Edge enabled infrastructures is addressing the mobility challenge of ensuring service continuity [2]. Several studies have explored 5G and edge-enabled architectures to support CCAM applications, with a focus on task offloading and latency reduction [5]–[9]. Specifically, offloading object detection tasks to the network edge has been shown to reduce latency and alleviate onboard resource constraints by leveraging computational resources closer to vehicles. However, many existing solutions for object detection and video processing have limitations. These solutions often employ monolithic designs that lack modularity, hindering scalability and adaptability [10]. For instance, the offloading algorithm proposed in [5] considers cell resources and vehicle distance but is evaluated only through simulations, lacking real-world deployment. Similarly, the work in [6] highlights the benefits of offloading computer vision applications to the edge, improving latency, response time, and throughput; however, it does not address dynamic platform status, system overload, or mobility management. In [7], a digital twin and reinforcement learning approach was designed to optimize offloading decisions based on mobility and bandwidth awareness, but service continuity and handover management remain unaddressed. Lastly, [9] proposed a mobility and resourceaware offloading strategy for vehicular edge computing networks, also evaluated through simulations. Collectively, previous works highlight the potential of MEC and 5G slicing for CCAM applications. However, they reveal a lack of comprehensive solutions tested in real-world deployments with autonomous vehicles, integrating edge coordination and urban platforms. In contrast, this paper proposes a CCAM-based architecture enabled by 5G and MEC platforms that supports real-time video analytics and intelligent service orchestration capable of adapting to user mobility and dynamic platform status. The system was validated with a use case based on an object detection pipeline deployed on the edge. The system demonstrates how live video streams can be captured, pre-processed, and transmitted via Real-Time Transport Protocol (RTP)/User Datagram Protocol (UDP) to be processed with a YOLO-based service at the edge,while smart orchestration decisions take into account real-time mobility data, radio network status, and platform metrics to perform service replication and scaling across edge nodes in response to user movement or resource overload, providing an important support structure capable of maintaining service continuity for critical CCAM services coupled with dynamic network management to provide endto-end service orchestration spanning edge processing and network infrastructures. The remainder of this work is organized as follows. Section II details the 5G-MEC architecture, emphasizing on its mobility-based architecture, metrics acquisition, and how it can accommodate smart city services. Then, section III presents the perception service and the support for edge offloading. Section IV depicts the validation results of the use case and edge offloading. Finally, section V concludes the work and presents future directions. II. EDGE-ENABLED ARCHITECTURE FOR AUTONOMOUS MOBILITY In our previous work [11], we extended 5G MEC orchestration to include mobility, but with some constraints. Users could request the instantiation of infotainment or emergency services and the allocation of network resources by specifying their route in advance. This reliance on predefined paths, however, prevented the system from proactively adapting to sudden trajectory changes and limited its ability to exploit advanced 5G capabilities beyond network slicing. As such, in this paper, a new architecture is proposed that extends the previous work to support unplanned route changes, with the development of new orchestration mechanisms that leverage real-time vehicle position data, performance metrics from the Radio Access Network (RAN) and edge platforms. A. 5G-Edge enabled Architecture The core idea of the proposed system represented in Figure 1 is to reduce end-to-end latency by optimizing the offloading of tasks to the most appropriate MEC node for the moving user. To accomplish this, the system comprises distributed components that collaborate to deploy and relocate the service to the optimal edge zone as the user moves. The MEC architecture, presented in Figure 1, comprises a 5G-edge enabled deployment. This means that the 5G core network follows a Control and User Plane Separation (CUPS) Fig. 1: Beyond-5G and Edge Offloading Architecture. architecture, with User Plane Function (UPF) disaggregated from the core network and placed at the edge. The presented concept is already a tested architecture in our smart city deployment, as detailed in [12]. Along the edge architecture, there is also a metrics’ platform that monitors and collects data from the network. The data, in form of Key Performance Indicators (KPIs), can be collected from the core, the antennas or the user equipments (whether being smartphones or modems). The Experiment Lifecycle Manager (ELCM), a common module used across the 6G-PATH project, collects these KPIs to aggregate metrics from data processors and collectors, such as Kafka and MQTT Brokers, MongoDB and other sources. This enables the use of metrics for KPIs visualization. The system proposed in this work utilizes the data from the platform to make decisions, based on several KPI families. Lastly, besides providing information, the 5G system also provides an API for QoS and RAN control. The control over the RAN allows for handover management, which provides a handover, not only aware of the network resources, but also based on the state of the service and edge nodes. B. Orchestration and Intelligence Components An orchestration through Kubernetes k3s1cluster, with nodes distributed on different sites, serves as the foundational layer for instantiating services, which is subsequently extended with components responsible for coordinating edge intelligence according to the mobility. These components collectively act as the orchestrator that determines the most appropriate actions for the system. It is comprised of four main components: Service Management Monitor (SMM), Actions Proxy (AP), Edge Application Manager (EAM), and Edge Coordinator (EC). 1https://k3s.io/ Algorithm 1 Orchestration Workflow Require: User Equipment (UE), EC, MEC, SMM, Aveiro Tech City Living Lab (ATCLL), AP, EAM, 5G API, RAN 1: UE →EC: REQSERV 2: EC →MEC: INSTSERV(Zones) 3: MEC →EC: READY 4: EC →UE: MECREADY 5: while MECREADY = false do 6: wait 7: end while 8: Init: wm, we, wr, θ ▷ Weights, threshold 9: while onTrip do 10: (m, e, r)←SMM ↔ATCLL: GETDATA 11: (sm, se, sr)←SMM.SCORES(m, e, r) 12: s←wmsm+wese+wrsr 13: if s > θ then 14: SMM →AP: MIGRSERV(Zone) 15: AP →EAM: EXECMIGR(Zone) 16: SMM →AP: TRIGHAND 17: AP →5G API: HANDOVER(gNB) 18: end if 19: end while The SMM is a service-specific monitoring component. It utilizes the locations of 5G gNodeBs (gNBs) attached to the MEC infrastructure and tracks Cooperative Awareness Messages (CAMs) originating from CAVs to determine their positions. Using this data, the SMM identifies when a vehicle is approaching a different coverage area and decides whether to initiate a service migration for that vehicle’s service instance. Thus, the SMM serves as the trigger for provisioning mobility-aware services. The AP is a service that forwards action messages from multiple applications that monitor the replicas associated with the services. It was designed with interoperability in mind, enabling seamless incorporation of SMM from other services. It serves as a relay for validating the action messages of the monitors. For example, when a SMM decides to enable a service in MEC, it sends a message to the AP, which forwards it to the EAM. This component also ensures that only legitimate actions are passed through the actuators while decoupling the monitoring logic from the MEC and 5G system orchestration logic. The EAM is responsible for interacting directly with the MEC infrastructure. This component interfaces with the underlying k3s cluster to manage the actions requested by the pods. In this system, it can enable or disable pod instances and perform the aforementioned actions on pods belonging to specific zones. In addition, it can be requested to show which pods are enabled, disabled, or healthy. The EC manages the resource allocation of the MEC infrastructure for services requested by users. When needed a REST API post is used to instantiate services to process their data. If the service is already available on the MEC, it will respond that the infrastructure is ready. If it is not ready, it will select the optimal edge zones for instantiation on the k3s cluster. When the pods are ready, EC returns that the infrastructure is ready. Algorithm 1 outlines the orchestration workflow for MEC intelligence orchestration. It illustrates how the orchestrator’s components interact to implement mobility-aware service logic. In this workflow, the EC receives a service instantiation request from the UE to deploy a service on the MEC k3s cluster. The SMM continuously monitors vehicle mobility, RAN conditions, and edge node status to determine whether the vehicle should be reassigned to a new edge node and gNB. The decision to instantiate or migrate a service is based on the vehicle’s location and proximity to the nearest gNB along its trajectory. When the SMM determines that a vehicle should transition to a new zone, it initiates service migration and requests a handover of the vehicle’s modem to another gNB. The AP forwards these requests to the relevant actuators, including the EAM and the 5G API, to execute the necessary actions seamlessly. In conclusion, the proposed mobility-aware edge offloading architecture offers a significantly more adaptive and robust solution than the previous approach [11]. It overcomes the limitation of relying on fixed user routes by leveraging realtime mobility data and tightly integrating with the 5G control plane, allowing the system to relocate services to the nearest edge node as a vehicle’s trajectory changes. This deep coupling of 5G network intelligence with MEC operations ensures continuous low-latency service delivery and optimal resource usage even under dynamic conditions. III. MOBILITY-AWARE OBJECT DETECTION SERVICE In CCAM scenarios, autonomous vehicles must accurately and promptly detect objects in order to perceive their surroundings and make safe decisions in real-time. However, performing this task solely on the vehicle demands significant resources, whereas offloading to cloud infrastructures results in latency incompatible with safety-critical requirements. The proposed solution introduces a scalable, mobility-aware pipeline for object detection explicitly designed for CCAM contexts. This modular pipeline of microservices manages the object detection task, encompassing acquisition, detection, and visualization of objects. The acquisition and processing microservices are designed to be stateless, facilitating seamless handover between replicas to support user mobility. The frame acquisition task is deployed in vehicles, while the object detection and visualization processes are handled on edge nodes. This stack of microservices is scalable, allowing multiple streams to be fed to one or more object detection services. The components for object detection tasks are Frame Acquirer and Frame Ingestor. The architecture is depicted in Figure 2. Each Frame Acquirer instance, running on a vehicle, handles one camera stream. Upon startup, it opens a network socket to announce its presence to the Frame Ingestor service by broadcasting, periodically, a unique identifier. Then, it uses a GStreamer2framework to capture the live video feed from the camera. The Frame Acquirer also performs frame scaling by encoding each frame in the H.264 format 2https://gstreamer.freedesktop.org/ Fig. 2: Object detection service architecture. to improve efficiency. The outgoing frames are transmitted through RTP, with unique identifiers using RTP header. In mobility scenarios, RTP stateless nature, which uses UDP as the transport layer protocol, supports fast transport across dynamic paths. Even with packet loss, the system benefits from the most recent available data, which aligns with real-time detection use cases for which edge computing was designed. It enables seamless handovers without session interruption, and consequently ensures uninterrupted service consumption. The Frame Ingestor service, deployed on edge nodes and used on available edge computing resources, comprises two tightly coupled components: the Receiver and the Detection Service. The receiver handles the received streams and broadcasted announcements, identifying each Frame Acquirer and registering their unique identifier and stream details as they become available. Once registered, the receiver continuously monitors a designated UDP port for incoming RTP streams. All cameras transmit their H.264-encoded video to this shared port. The receiver then demultiplexes the frames and correlates them with the announcement data by examining the embedded Frame Acquirer identifier in the RTP headers. As packets arrive, the receiver removes the RTP headers, associates each packet with the correct camera, and reconstructs complete frames from the stream. Since a single video frame may span multiple RTP packets, the receiver buffers the data until a full frame is assembled and sent to the object detector. The object detector processes each frame using the YOLO model3, a state-of-the-art algorithm widely adopted for realtime object detection. YOLO identifies objects such as vehicles, pedestrians, and bicycles, annotating them with bounding boxes directly on the image. The generated metadata provides valuable information about the vehicle’s surroundings, supporting the creation of the World Model—a fundamental component for enhancing road safety and enabling autonomous mobility. The modular design of the service simplifies deployment and maintenance. Each component is containerized, enabling rapid deployment on edge nodes and facilitating easy scaling and updates compared to monolithic systems. In summary, this design allows each component to be dynamically instantiated or relocated across moving vehicles and edge nodes without retaining previous state. These features yield a scalable, resilient object detection service that is prepared for moving vehicle environments. 3https://docs.ultralytics.com/models/yolo11/ IV. USE CASE VALIDATION To validate the system, a CCAM-based use case of an autonomous vehicle equipped with a camera was devised for the object detection service described in the previous section. It was incorporated in the objectives of the European project 6G-PATH4. Besides its development and validation, there were open demonstrations of edge offloading with a real autonomous vehicle to the public. This section presents the use case, its results, and their impact on the service. A. Description In this use case, the autonomous vehicle is equipped with a camera that streamed video over the cellular network to the edge infrastructure, where the previously presented object detection service processed the footage. The results of the object detection task, processed by the offloaded service at the edge, can provide valuable insights for the autonomous vehicle and other cloud services. For example, detecting road signs and traffic lights increases the vehicle’s awareness of its surroundings, while identifying other vehicles and pedestrians can help prevent accidents and improve traffic efficiency. Other cloud services can use these data to optimize traffic flow and update maps with congestion information, contributing to an improved perception awareness of other entities in the CCAM environment. The stream processing service was replicated on demand in suitable edge nodes along the vehicle’s path. Given the ultra-low latency and high reliability requirements of this use case, a key goal of the demonstration was to showcase smart orchestration capabilities and dynamic network management in a CCAM scenario, and as such, one of the node’s memory and CPU were stressed to showcase the action of those orchestration and network management mechanisms. The demonstration flow started when the vehicle began the trip accessing the service from an overloaded edge node. Its mobility and platform status information reflected the situation, and smart orchestration mechanisms triggered a replica activation on a healthy node alongside a network handover to the nearest antenna (gNB) to offload the service and the network connection, ensuring that the QoS would not be degraded. The results evidence the importance of a system and application like this in a CCAM environment with an autonomous car. (a) PIXKIT Autonomous vehicle (b) Edge Node with gNB Fig. 3: Equipment used in public trials for the use case. 4https://6gpath.eu B. Experimental Setup and KPIs The setup for the use case combined an autonomous vehicle, a non-public 5G network, and an edge computing cluster. The autonomous vehicle is a PIXKIT5(Figure 3a) which had onboard a processing device, a camera, and a SIMCom modem to provide a 5G upstream link. In the processing device, PIXKIT the following instantiated services: the GPS location service, the vehicular network stack (Vanetza-NAP [13]), and the Frame Acquirer service described in the previous section. The 5G infrastructure includes two CableFree gNBs located along the predetermined demonstration path, and Open5GS as the core network. The edge computing infrastructure required the creation of a k3s cluster, where one Virtual Machine (VM) served as the master node and two Nvidia Jetson boards served as edge nodes, each with a corresponding gNB, representing separate edge zones (Figure 3b). Frame Ingestor instances were distributed between the edge nodes, where they performed the object detection task and worked in cooperation with the vehicle. In this setup, one of the replicas was stressed, while the other was healthy. When the network handover occurred, the service was offloaded to the healthier and closer edge node, thus improving not only Quality of Experience (QoE), specially in the processed video stream, but also the safety of everyone on the road. This use case provided KPIs from both infrastructure (RAN) and service, gathered in the client visualization application. Frames per second and the number of frames dropped were also representative of the quality of the stream, thus indicating the perception of the quality by users. The KPIs are represented in table I, and their definition follows the specification by the 6G Smart Networks and Services Joint Undertaking (SNS JU) [14]. Fig. 4: Bitrate measured inside the service replicas. fi-0: frame-ingestor 0, fi-1: frame-ingestor 1. C. Results dissemination Figure 4 illustrates one of the previously mentioned KPIs, offering insights into how the orchestration mechanisms responded to the node overload scenario. The bitrate was initially high, but once the overload process started, it dropped to values below 10 Mbps. The orchestration mechanisms detected the situation and activated replica frame-ingestor-0 (fi-0 in Figure 4) in the healthy node, which caused a slight increase in bitrate, that rose to values higher than 12 Mbps. It is clear that, although performance is slightly better on the healthy node, it does not reach the level observed on the first node before and after the overload period. This is due to the fact that the autonomous vehicle was moving away from the gNB, thus degrading the network connection with its movement, despite the edge infrastructure correctly identifying the overloaded node. Figure 5 (lower chart) shows a greater improvement in the number of processed frames per minute on the healthy node compared to the overloaded one. On the stressed node, where CPU and RAM were under heavy load, the object detection service experienced delays and performance issues. However, the situation improved significantly once the replica on the healthy node was activated and frame processing was redirected to it. The healthy node demonstrated higher performance than the other one, even before the overload process started, because it was more powerful. This further highlights the importance of intelligent orchestration mechanisms for effectively managing service loads across heterogeneous nodes. The final service-specific metric under analysis is the number of frames dropped by each one of the replicas (represented in Figure 5, in the upper chart). It also demonstrates the importance of the smart orchestration mechanisms, because as soon as the overload processes started, the number of frames dropped, and then started to rise, causing performance degradation. However, once the second replica is activated and it starts receiving frames, it is clear that the number of frames dropped suffers an improvement, with only a residual number of frames being dropped in the replica switch moment. Afterward, the application’s performance stabilized, with no additional frame loss until the frame processing was redirected back to the first replica. The results of this demonstration validate the correct operation of the system and its importance in a CCAM environment. Service interruptions were avoided through the application’s stateless design, which enabled seamless handling of user mobility by redirecting traffic to the nearest antenna that prevented service degradation. Furthermore, intelligent orchestration mechanisms detected a critical overload situation and took action to prevent complete service interruption that would compromise the operation of this critical service. Offloading perception applications for autonomous vehicles to the edge offers significant benefits but demands ultra-high reliability and low latency. The provision of proactive resources based on mobility was a crucial addition to the infrastructure enabled 5https://www.pixmoving.com/pixkit3 Family KPI Description Target Value Compute container_memory_usage_bytes Total memory usage of a container (Prometheus default). ≥minimum required for frame processing. node_load1 1-minute load average on a node (Prometheus default). ≥minimum required for frame processing. cpu_utilization Percentage of CPU used by containers. ≤80% to avoid bottlenecks. scale_out_latency Time to deploy additional containers. ≤500 ms. Coverage cqi Channel quality indicator reported by UE to gNB. Target 15, ≥13 optimal. ri Rank Indicator for MIMO (2x2). Target 2 (no antenna correlation). pusch_snr Last received PUSCH SNR. ≥15 (good quality). rsrp Reference-Signal Received Power (dBm). ≥ −85 dBm. Data Rate dl_bitrate, ul_bitrate Downlink, Uplink bitrate in bits/s. ≥required by service (e.g., 10 Mbps). peak_dl_bitrate Max achievable downlink bitrate under ideal conditions. ≥100 Mbps. Reliability dl_retx Number of downlink retransmitted blocks. Ideally 0, some acceptable. ul_retx Number of uplink blocks with CRC errors. Ideally 0, some acceptable. dl_tx, ul_tx Number of downlink, uplink blocks transmitted without retransmissions. >dl_retx. Positioning cam_longitude, cam_latitude Longitude, latitude of the vehicle. Accurate position tracking. Mobility handover_success_rate Percentage of successful handovers. ≥99%. handover_latency Time to complete a handover (ms). ≤50 ms. Latency orchestration_latency Time to migrate a service to another node (ms). ≤100 ms. Service Quality num_processed_frames Number of frames processed by service replicas. ≥minimum required FPS, else migrate service. TABLE I: KPI Definition for the Use Case. Fig. 5: Frames dropped and frames per minute analysis fi-0: frame-ingestor 0, fi-1: frame-ingestor 1. by the 5G-edge, and the integration of all of these platforms was shown to be a first research effort to build a cooperative awareness platform capable of adapting to the dynamic nature of the 5G-edge platforms and the user mobility inherent to this environment. The results of this demonstration yielded two datasets, which include the extracted KPIs and KVIs and are available for public consultation [15] [16]. A demonstration of the use case is also available in this video6. V. CONCLUSIONS This paper proposed and validated an edge offloading approach in 5G Edge-enabled environments, with an autonomous vehicle and object detection service. In a complete integration of 5G networks, MEC services, and vehicular services, this study delivers: an architecture, a definition of retrievable KPIs, an orchestration workflow, system validation, results and a public demonstration. The results validate the correct operation of the system and its importance in a CCAM environment. Service interruptions were avoided through the application’s stateless design, which enabled seamless handling of user mobility by redirecting traffic to the nearest antenna that prevented service degradation. Furthermore, intelligent orchestration mechanisms detected a critical overload situation and took action to prevent complete service interruption that would compromise the operation of this critical service. As future lines of work, we aim to further improve the integration with the 5G network, mainly through the use of 3GPP defined APIs in the core network and RAN. In the orchestration side, descriptors for an easier deployment of services can allow for scalability. While the work presented is mainly focused on an object detection service, a future research direction more focused on the edge infrastructure would include the 6https://youtu.be/-4GHgNh4D6I, accessed 10 September 2025 extension of this architecture and its validation with new use cases in more complex scenarios involving a large number of users consuming different types of services hosted on the edge platform. VI. ACKNOWLEDGMENT This work was supported by the EU’s HE research and innovation programme HORIZON-JU-SNS-2023 under the 6GPATH project (Grant No. 101139172), and by the European Union/Next Generation EU, through Programa de Recuperação e Resiliência (PRR) [Project Nr. 29: Route 25 (02/C05i01.01/2022.PC645463824-00000063)]. REFERENCES [1] B. R. Cherukuri, “Edge computing vs. cloud computing: A comparative analysis for real-time ai applications,” International Journal For Multidisciplinary Research, vol. 6, pp. 1–17, 10 2024. [2] S. M. H. Hosseini, M. J. Jooriah, D. Rocha, J. A. Almeida, P. Bartolomeu, J. Ferreira, . Rosales, and M. M. Miranda, “Cooperative, connected and automated mobility service continuity in a cross-border multi-access edge computing federation scenario,” frontiers in future transportation, vol. 3, no. 911923, pp. 1–16, July 2022. [3] J. Ortiz, P. J. Fernández, R. Sanchez-Iborra, J. B. Bernabe, J. Santa, and A. Skarmeta, “Enforcing gdpr regulation to vehicular 5g communications using edge virtual counterparts,” in 2020 IEEE 3rd 5G World Forum (5GWF), 2020, pp. 121–126. [4] E. Coronado, G. Cebrián-Márquez, and R. Riggio, “Enabling autonomous and connected vehicles at the 5g network edge,” in 2020 6th IEEE Conference on Network Softwarization (NetSoft), 2020, pp. 350–352. [5] S. B. Devagiri and M. Vijayalakshmi, “Enhancing 5g mobility and performance through multi-access edge computing integration and cooperative computing offloading,” in 2024 Second International Conference on Networks, Multimedia and Information Technology (NMITCON), 2024, pp. 1–7. [6] M. V. B. Da Silva, M. Barbosa, A. Queiroz, and K. L. Dias, “A 5gedge architecture for computational offloading of computer vision applications,” in 2025 International Conference on Information Networking (ICOIN), 2025, pp. 93–98. [7] X. Chen, J. Cao, Y. Sahni, M. Zhang, Z. Liang, and L. Yang, “Mobilityaware dependent task offloading in edge computing: A digital twinassisted reinforcement learning approach,” IEEE Transactions on Mobile Computing, vol. 24, no. 4, pp. 2979–2994, 2025. [8] P. F. Moshiri, M. Simsek, and B. Kantarci, “On the interplay between network metrics and performance of mobile edge offloading,” in ICC 2024 - IEEE International Conference on Communications, 2024, pp. 4018–4023. [9] Y. Li, C. Yang, X. Chen, and Y. Liu, “Mobility and dependency-aware task offloading for intelligent assisted driving in vehicular edge computing networks,” Vehicular Communications, vol. 45, p. 100720, 2024. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S221420962300150X [10] R. Xu et al., “Edge video analytics: A survey on applications, systems and challenges,” IEEE Communications Surveys & Tutorials, 2023. [11] J. Gameiro, R. Rosmaninho, G. Perna, P. Rito, S. Sargento, C. Marques, and F. Pinto, “Edge computing and 5g network integration for mobilityaware service deployments,” Pervasive and Mobile Computing, 2025, Submitted. [12] P. Valente, D. Raposo, P. Rito, and S. Sargento, “Disaggregated mobile core for edge city services,” in 2023 IEEE 24th International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2023, pp. 157–166. [13] R. Rosmaninho et al., “Vanetza-nap: Vehicular communications and services in microservices architectures,” in 2024 IEEE Vehicular Networking Conference (VNC), 2024, pp. 297–304. [14] I. Mesogiti, A. Gavras, K. Trichias, A. Kaloxylos, F. Fontes, A. Charemis, M. Ghoraishi, M. Mollà Roselló, P. Yadranjee Aghdam, G. Agapiou, A. Sgambelluri, M. Al-Rawi, C. Marques, and W. Mohr, “6g kpis - definitions and target values,” Mar. 2025. [Online]. Available: https://doi.org/10.5281/zenodo.15011631 [15] I. de Telecomunicações and A. Labs, “6g-path_wp1_dataset_uccities1_experimental_edge_performance_it,” Sep. 2025. [Online]. Available: https://doi.org/10.5281/zenodo.17092093 [16] ——, “6g-path_wp1_dataset_uccities-1_experimental_ran_traffic_it,” Sep. 2025. [Online]. Available: https://doi.org/10.5281/zenodo.17092369