Edge-V: Vehicular Edge Intelligence Through Multi-Band Unlicensed Spectrum Access

IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXX 2025 1 Edge-V : Vehicular Edge Intelligence Through Multi-Band Unlicensed Spectrum Access Francesco Raviglione, Claudio Casetti, Senior Member, IEEE, and Francesco Restuccia, Senior Member, IEEE Abstract—Technological advances in the automotive field are driving the development of smarter, greener, and more autonomous vehicles. These vehicles will need to communicate via Vehicle-to-Everything (V2X) wireless communications and perform advanced Deep Learning (DL) tasks while handling large data volumes with low latency and high reliability. Although 5G is frequently viewed as a comprehensive solution for addressing the demanding environment of next-generation autonomous vehicles and of Vehicular Edge Intelligence (VEI), relying solely on cellular networks poses challenges like spectrum congestion, delays in edge offloading, and poor coverage in certain areas. Current unlicensed spectrum technologies also fall short of the VEI requirements. On this basis, we propose Edge-V , a novel framework combining unlicensed spectrum technologies to provide low-latency, high-throughput connectivity with reliable task offloading. Edge-V uses a Dedicated Short-Range Communications (DSRC) link for exchanging standardized messages, traditional Wi-Fi for connecting on-board devices and sensors, and mmWave for high-speed, low-latency connectivity. With the aim of optimally allocating tasks, an Offloading Manager module is included, based on a system model which is mathematically formulated, and used to propose a sample greedy strategy within Edge-V . Our laboratory and field tests, thanks to an open and low-cost Proof-of-Concept, show that Edge-V can reduce latency by up to 65% when compared to cellular/cloud-based solutions. Index Terms—Vehicular Edge Computing, Vehicular Edge Intelligence, VEI, mmWave, Vehicular Networks, unlicensed spectrum I. INTRODUCTION AN essential step in making autonomous vehicles smarter is making them more aware of their surroundings. In addition to the exchange of standard-compliant messages for safety and non-safety applications, future vehicles are expected to share their on-board sensor data – coming from LiDARs, radars and especially cameras – to enable technologies such as advanced See-Through with high-quality video feedback, or real-time sharing of high-definition maps among self-driven vehicles for accurate localization [1], [2]. Furthermore, the next generation of connected vehicles are expected to support interactive entertainment systems for passengers based on V2V communication [3]. These crucial applications have stringent requirements, and they may need real-time multimedia transmission and execution of complex DL tasks, such as object detection or image segmentation starting from a raw camera input. This requires the execution of computationally F. Raviglione is with the Department of Electronics and Telecommunications, C. Casetti with the Department of Control and Computer Engineering, Politecnico di Torino, Italy. F. Restuccia is with the Institute for the Wireless Internet of Things, Northeastern University, United States. DSRC Safety and periodic messages mmWave High-throughput and low latency data See Through d V2V Entertainment Object detection Wi-Fi On board Wi-Fi access point Object detection MEC/Cloud Fig. 1. Vehicular Edge Intelligence (VEI) will enable transforming applications such as “See-Through” vehicular vision, real-time exchange of 3D maps and V2V entertainment. expensive tasks, with strict latency requirements and the need for high throughput links. Due to the limited resources available on vehicles, when compared to the computing power of Multi-Access Edge Computing or cloud servers, task offloading is often looked as a solution to enable complex applications while keeping the on-board resource usage and energy consumption within reasonable limits. This technique can be used to offload computation to the infrastructure and/or to other vehicles that provide free resources, and then receive a lightweight version of the results, containing only the relevant information (e.g., a vehicle can offload an entire frame from a camera output, and receive back the list of detected objects and their position in the frame). Task offloading requires ultra-low latency and very high throughput, and thus it faces several challenges. These challenges include the transmission of data from sensors, such as LIDARs that can generate up to Terabytes per hour of data [4]–[6], and the choice of a proper technology, or a combination of them, to guarantee at the same time high reliability, high throughput and low latency. Reliability is indeed crucial to guarantee that a sufficient number of tasks is properly executed and the results are properly delivered to the vehicles. With the aim of enabling the execution of such tasks, it may become pivotal to deploy the intelligence at the edge of vehicular networks (i.e., in the vehicles themselves and at infrastructure edge nodes), giving birth to the concept of Vehicular Edge Intelligence (VEI). 5G (and, in the future, 6G) is often considered as the solution to the challenges brought by VEI, as its deployment is progressing across Europe and North America. However, relying solely on 5G for this kind of V2X use cases would significantly stress already overloaded licensed spectrum bands, IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXX 2025 2 expected to support up to 64 billion subscribers by 2025 [7]. Furthermore, there is currently a lack of open frameworks combining different technologies for V2X to enable practical VEI and task offloading. We thus propose Edge-V , the first open framework combining different technologies (DSRC, mmWave and standard Wi-Fi) to enable VEI and on-board AI/ML by leveraging only unlicensed spectrum bands.Edge-V is designed to be open and it provides several advantages over the usage of 5G only: (i) reduces the usage of the expensive cellular spectrum; (ii) reduces task offloading latency thanks to nearby vehicle offloading and V2V cooperation; (iii) it could be crucial in areas where 5G coverage is scarce or unavailable [8], which, at the time of writing, is often the case in rural areas and small towns. Additionally, VEI requirements cannot be guaranteed by current vehicular technologies such as Cellular-V2X Mode 4 and IEEE 802.11p due to their limited peak data rates, which are typically below 30 Mbit/s [9]. Although mmWave vehicular networking has been proposed [9], [10], existing work is mostly based on simulations. Furthermore, due to relatively high path loss and potential blockages [11], mmWave technology may experience connectivity issues. Therefore, it is essential to integrate the capabilities of different wireless technologies, with different characteristics, to concretely realize the much-needed VEI. Summary of novel contributions •This paper introduces Edge-V , the first open framework enabling practical Vehicular Edge Intelligence (VEI) exclusively using unlicensed spectrum and combining the strengths of mmWave, 5.9 GHz ITS DSRC and Wi-Fi. •VEI includes an Offloading Manager (OM) which manages task offloading based on a formulation of the system model, i.e., the Vehicular Edge Intelligence Problem (VEIP). VEIP, proven NP-Hard, prioritizes offloading tasks to nearby vehicles, minimizing latency; to solve VEIP, we propose a polynomial-time greedy algorithm (DG-VEIP). •We present a full proof-of-concept using off-the-shelf hardware and open-source software, including an enhanced Local Dynamic Map (LDM) that integrates channel quality and computational load data for VEI. •Edge-V is evaluated via MATLAB simulations, laboratory tests, and on-road experiments. Key results include: significantly reduced latency (up to 65% lower than cloud-only methods) at the cost of a limited accuracy loss (18% mAP), and sub-5 ms end-to-end latency, proving the effectiveness of combined mmWave and sub-6 GHz connectivity. This is the first open-source experimental testbed for VEI in unlicensed spectrum. •This work significantly extends the previous work presented at VTC2023-Spring [12], by including: (i) a more comprehensive and detailed presentation of the background context, motivations, and up-to-date related works; (ii) a refined version of the POC, with a more complete description of its innovations and a discussion on the use cases that can be enabled by Edge-V ; (iii) a novel mathematical model of the system, with its NP-hardness proof and the proposal of a greedy scheme for optimizing offloading decisions; (iv) a new evaluation through MATLAB simulation with realworld traces [13]; and, finally (v) a practical experimental validation obtained through field tests and on-road experiments. II. RELATED WORK With the advent of dedicated access technologies like IEEE 802.11p and C-V2X, as referenced [14], V2X communications have undergone extensive research in recent years. On the contrary, VEI approaches are still at an early stage of development, given the swift advancement of DL-based algorithms and other use cases that are specifically tailored for vehicular applications [15], [16]. As mentioned earlier, VEI is characterized by the critical need of establishing high-bandwidth and low latency communication among vehicles, which can be potentially moving at high speed. This makes both VEI and task offloading particularly challenging in vehicular scenarios. Indeed, both IEEE 802.11p and C-V2X may be unable to satisfy their stringent requirements if employed alone [9]. Therefore, it becomes crucial to combine different protocols and consider promising high throughput technologies such as mmWave. Even though, with the advent of IEEE 802.11ax, the throughput gain achievable by mmWave may no longer be a decisive factor, the latter still provides several advantages. These include spatial reuse, as technologies working over the sub-6GHz spectrum do not provide a much higher aggregated throughput in a given location. The application of mmWave to vehicular networks is currently being investigated by a number of research works. Among them, some works focus on IEEE 802.11ad [17], working in the 60 GHz unlicensed spectrum. This technology uses beamforming and can provide ranges up to 100 to 200 m in Line-of-Sight conditions, and 30 to 40 m in Non-Lineof-Sight conditions, guaranteeing very low delays and high throughput, up to more than 1 Gbit/s [18]. Therefore, it appears to be very promising for the application in vehicular networks, although several challenges need to be faced, including beam management, beam blockage recovery [19] and impacting NLOS (Non-Line-of-Sight) conditions, that can reduce the mmWave range by more than 30 times [20]. In addition to mmWave, existing work has also proposed Terahertz-based communications to establish high-bandwidth links [9], [21]. Giordani et al. [22] analyzed the application of mmWave to V2X scenarios, while Molina-Galan et al. [10] propose to decouple the mmWave data and control plane in vehicular scenarios, and suggest the use of sub-6 GHz C-V2X Mode 4 as control plane to schedule the data transmission over mmWave. As opposed to our proposal, these works are fully simulation-based. Raviglione et al. [18] presented one of the first field-test campaigns with mmWave applied to Vehicle-to-Infrastructure (V2I) communications. However, a VEI scenario is not considered and the focus is only on wireless performance. The closest to our work is [9], where Li et al. propose a combination of Software-Defined Networks (SDN) and mmWave links, with backhauling based on IEEE 802.11ad and C-V2X, and DSRC to carry control plane IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXX 2025 3 signals. Edge-V focuses instead on unlicensed spectrum technologies, and does not involve cellular-based communications. From the point of view of task offloading, instead, a significant amount of work, e.g., [8], [23], [24] has focused on developing algorithms for offloading tasks in the vehicular edge. For instance, Tang et al. [25] proposed a cache enabled task offloading system, focusing on offloading tasks to nearby Road Side Units or base stations. Similarly, Higuchi et al. [26] define virtual edge servers composed by vehicles, to which jobs can be efficiently offloaded. This work is only evaluated through simulations, without considering the limitations of real hardware. A key contribution of Edge-V is the combination of different unlicensed spectrum technologies to enable advanced V2X use cases. As described in more detail in Section III, VEI cannot be enabled by single technologies, and it becomes thus fundamental to incorporate different technologies with different characteristics. Some works in literature propose systems that rely on a single technology, often considering only cellular connectivity. For instance, both [27] and [28] demonstrate the feasibility of real-time offloading with cellular networks. Edge-V , on the contrary, improves offloading by considering only unlicensed spectrum and overcoming the limited bandwidth of DSRC with the integration of 60 GHz mmWave, reducing dependence on the cellular network. Other works, like [29] explore offloading with DSRC only, taking traffic priority into account. A pure C-V2X alternative is instead the cluster-based offloading scheme by Bute et al. [30], which relies on PC5 sidelink transmissions to distribute tasks among vehicles, together with infrastructured communications to reach remote MEC servers. However, offloading to other vehicles solely over DSRC or Sidelink C-V2X works well only for smaller tasks that do not require a high bandwidth. To this aim Edge-V also integrates mmWave, and facilitates the connection of on-board devices thanks to internal standard Wi-Fi. Our work differs from existing literature as it does not focus exclusively on a specific task offloading architecture, but it aims at providing a complete, open and flexible framework to test VEI and advanced automotive use cases in the field. Indeed, Edge-V includes not only the Offloading Manager, but several other modules such as an enhanced wireless stack, for which we propose a novel container for Cooperative Awareness Messages (CAMs) [31], that are disseminated with a variable frequency between 1 Hz and 10 Hz depending on the vehicle dynamics, to share VEI-critical information between road users. Concerning task offloading, we also present our own solution and system model starting from the VEIP problem, which is evaluated on both trace-driven simulations as well as on-road experiments, and that can be integrated as a task offloading solution in the Offloading Manager. III. THE EDGE-V FRAMEWORK The Edge-V framework, with its different modules, is represented in Figure 2. As can be seen, Edge-V is designed to be deployed, with different modules, on both connected vehicles and infrastructure nodes (i.e., RSUs, with a connection to a MEC server or cloud data center). Edge-V , as a key advancement, combines computation and communication in unlicensed spectrum to deliver V2X and VEI capabilities to existing vehicular networks. The core of Edge-V are its three radio interfaces. Two of them are external for inter-vehicle communication (DRSC and directional mmWave), and one of them is internal to the vehicle (standard Wi-Fi). The latter comprises a Wi-Fi AP bridged with the mmWave interface (the green line represented in Figure 2), to provide the on-board devices with access to the Internet, through the RSU, or to centralized infrastructure services. This enables seamless communication between the on-board devices as well as between different vehicles equipped with mmWave. These devices may include: (i) cameras on-board of different vehicles, enabling use cases such as See-Through with high quality video feedback, (ii) laptops and smartphones for interactive entertainment, and (iii) HMI devices for the reception of warnings, for the provision of road signage information, and for displaying in real-time the position of other road users and/or obstacles (e.g., through the results of DL tasks offloaded to other nodes). Additionally, the DRSC slot may also host an alternative PC5 Sidelink C-V2X transceiver working in the unlicensed 5.9 GHz spectrum, as no change is required to the higher layers of the ITS stack. The aim of Edge-V is to combine these three radio technologies to realize use cases that would not be properly supported by single technologies, but which can benefit from the combined use of these technologies and their strengths. mmWave is ideal for short-range, high-throughput task offloading and multimedia data exchange. DSRC, specifically designed for automotive communications, is suited to safetycritical and standardized messages as defined by ETSI C-ITS standards, thanks to its longer range, but cannot provide data rates higher than 30 Mbit/s [9]. Guaranteeing a level of compliance and integration with standards, through technology specifically designed for the automotive domain, is indeed essential. IEEE 802.11ac/ax Wi-Fi operates in a typical Access Point-client configuration within vehicles, and it is therefore very well suited to connect onboard devices to Edge-V , being a commonly supported technology (e.g., by smartphones, unlike DSRC or mmWave). Furthermore, the presence of the RSU enables data exchange between the on-board devices through the RSU itself, realizing, if needed, a mmWave V2I2V (Vehicle-toInfrastructure-to-Vehicle) relayed communication. This approach enables the exchange of data between vehicles even in case of noticeable NLOS blockage or distances higher than a few hundred meters. For instance, as shown in [18], [20], mmWave can reach a range of just 30-40 m in NLOS. With a step through an RSU that is in LOS with two vehicles, the range can increase up to 200 to more than 400 m (double the single LOS range measured in [18]). Relayed communication is an approach that can help improving Vehicle-to-Vehicle communications in presence of NLOS and when far away nodes need to be reached. ETSI has foreseen, for its C-ITS stack, different approaches to perform multi-hop routing, thanks to information available at the GeoNetworking layer. Specifically, both area forwarding IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXX 2025 4 (for dissemination of messages inside a target area) and nonarea forwarding (for dissemination of messages that still need to reach a destination area) algorithm are foreseen and described in [32]. There are also a number of works in literature that investigate the applicability of multi-hop mmWave V2V communications, such as [33]. These algorithms, however, mostly focus on V2V communication. On the contrary, Edge-V proposes not only an enhanced stack supporting GeoNetworking with forwarding capabilities for the exchange of DSRC messages, but also a forwarding mechanism as part of the RSU, to increase the communication range through mmWave infrastructure nodes. This mechanism can exploit the information received through both dedicated messages and standard-compliant messages, such as the ETSI messages with the GeoNetworking layer. The combination of the three radio interfaces enables several demanding applications, including (i) DL-task offloading such as object detection from a camera input, as detailed in Section III-A, (ii) raw GNSS data and sensor data exchange with sensors transmitting their data via Wi-Fi to Edge-V , and both raw data being transmitted via mmWave, and standardcompliant messages via DSRC, (iii) interactive entertainment and See-Through, with multimedia streams being transmitted by the on-board devices via Wi-Fi and mmWave, and safety messages being broadcasted via DSRC, (iv) centralized and decentralized automated maneuvers, in which safety-critical maneuver management messages are exchanged via DSRC and raw sensor information via mmWave. It would be possible to argue that combined unlicensed spectrum bands, despite providing several advantages, are also affected by security considerations and possibly additional interference. Nevertheless, Edge-V already considers these challenges in three complementary ways. First, two of our three radio interfaces (DSRC and internal Wi-Fi) either work in the ITS band at 5.9 GHz, that is dedicated to vehicular communications, or remain confined to the in-car environment, while the 60 GHz mmWave link combines a short propagation range with beamforming, which drastically limits interference. Second, as described later, Edge-V includes an enhanced wireless stack where security services can be implemented “on top” of Edge-V (e.g., standardized ETSI C-ITS security). Third, in the case of impaired links due to interference, Edge-V can take them into account and try to offload to other nodes, as explained in Section IV. In addition to the wireless technologies, the main modules and components of the framework can be summarized as follows: •Computing module. Each vehicle and RSU has computing resources in terms of RAM, CPU and GPU. These resources can be used to execute tasks and on-board services locally, or can be exploited by other nodes to offload their tasks. •Local Dynamic Map. Edge-V includes a standardcompliant LDM [34], which has been enhanced to store information about available resources on nearby vehicles (and, possibly, infrastructure/edge nodes), together with other VEI-specific information. These include computational load and channel load metrics for each vehicle stored in the map. Vehicles running Edge-V can exploit such (GJH9&RPSXWLQJ0RGXOH/RFDO'\QDPLF0DS/'0(QKDQFHG:LUHOHVV6WDFN3RVLWLRQLQJ0RGXOH2ĵRDGLQJ0DQDJHU5HOLDEOHORZODWHQF\9HKLFOHWR(YHU\WKLQJVSHFLıF6DIHW\,76OLQN#*+]+LJKWKURXJKSXWXOWUDORZODWHQF\ORZFRVWOLQN'LUHFWLRQDOPP:DYH#*+]6PDUWSKRQHV2Q%RDUG6HUYLFHV,QWHUQHW&ORXG&RPSXWLQJ0RGXOH5RDG6LGH8QLW&HQWUDO9(,0DQDJHU:LGHO\GHSOR\HG080,02:L)L$FFHVV3RLQW#*+]:L)L$3/DSWRSV&DPHUDV'65&OLQNPP:DYH:L)L7KLVSDUWLVNHSWMXVWIRUUHIHUHQFHDQGVKRXOGEHŗFXWDZD\ŘIURPWKHUHVXOWLQJLPDJHRU3') Fig. 2. High-level overview of the Edge-V framework. information to determine dangerous road conditions, or to optimize decisions such as where to offload data. The LDM is populated thanks to the exchange of standard-compliant vehicular messages, exchanged through the DSRC link, and it provides enhanced awareness to vehicles, also thanks to the storage of both real-time and historical data. Other than the direct reception via DSRC, the LDM can also receive messages from other vehicles through both multihop and from the RSU. This allows the Offloading Manager to have situational awareness, letting it compute the number of mmWave hops which may be needed to reach each node. As the LDM is mainly updated with standard-compliant vehicular messages, they are usually disseminated periodically at frequencies high enough to provide a real-time view over the road and other connected entities. •Enhanced Wireless Stack. Each vehicle is equipped with a standard compliant ITS wireless stack, i.e., an ETSI C-ITS stack for Europe or an IEEE WAVE stack for the US. This stack is enhanced to include an optional container in periodic messages (e.g., CAMs or BSMs) for the transmission and reception of channel and node load data. The broadcast exchange of standard-compliant messages occurs through the DSRC link. This stack should also support forwarding for multi-hop communication (e.g., area and non-area GeoNetworking if an ETSI C-ITS stack is employed). To guarantee QoS, the enhanced wireless stack may rely on MAC-layer traffic prioritization, depending on the needs of on-board services, that can request a given priority, and on the channel load. More specifically, when considering Wi-Fi-based technologies for DSRC and mmWave, 8 user priorities can be set, following the IEEE 802.11D standard. However, Edge-V is designed to support other kinds of prioritization mechanisms, that can be implemented depending on the selected versions of the radio technologies. •Positioning Module. Positioning represents one of the key enablers of vehicular networks. Each vehicle running Edge-V is thus equipped with an external or embedded GNSS receiver, providing localisation and kinematic data to the ITS stack for the generation of standard-compliant mes- IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXX 2025 5 sages, which are in turn used to populate the LDMs of the other vehicles. The positioning information is acted upon by the Offloading Manager to perform the decision process. As it represents a quite critical information for the performance of most V2X algorithms (including task offloading), RealTime Kinematics (RTK) Global Navigation Satellite System (GNSS) receivers can be used to reach lane-level accuracy, and corrections can be received through the DSRC link (using Radio Technical Commission for Maritime Services Extended Messages – RTCMEM – [35]), via raw GNSS data [13], or thanks to the mmWave link towards the RSU. It should be mentioned that future connected vehicles are likely all expected to integrate lane-level GNSS receivers, or at least devices with an accuracy lower than 1 m. Therefore, to consider a real-world scenario, a precise receiver has been used to perform the on-road tests presented in Section VI. •On-board Services. They represent the core on-board services and applications running on the vehicle OBU. They may include, for instance, collision avoidance, object detection through task offloading, See-Through, automated maneuver management, indication of nearby parking spots and road works, and many more. As depicted in Figure 2, these services can retrieve data from the enhanced LDM when needed, including dynamic, node and channel load and network data for each nearby connected vehicle. Additionally, they can also retrieve useful data from (i) the ITS stack, (ii) the on-board devices and sensors, (iii) the high capacity mmWave link, and (iv) the Offloading Manager output. Furthermore, they can use the on-board computing resources to perform computations. •Offloading Manager (OM). This component represents the core of Edge-V . It oversees selecting which are the best vehicles to perform task offloading and to communicate with, and deciding which is the best link to use. The decision can be based on the information available in the LDM and on mathematical optimization or AI-based algorithms. The main information used by the OM includes the channel quality towards the destination vehicles, their distance from the source, and their available computing resources. It should be noted how the channel quality, for instance measured via the received signal strength, already takes into account the vehicle’s mobility and speed. Indeed, a vehicle that is moving fast will be likely affected by a fast-varying channel quality, and by a distance that increases or decreases quickly and these are all factors that can be taken into account by the OM algorithm. This component is also in charge of managing the local computing resources and determining the best route towards any destination in case multiple mmWave hops are required. Indeed, when performing high-speed data exchange between on-board devices, it can determine which is the best route and provide it to the related On-Board Services. Even though it is flexible enough to accommodate any optimization algorithm, depending on the target scenario, we propose in Section IV a system model, which can be used as a baseline for the algorithm for task offloading and routing. •Road Side Unit (RSU). As mentioned earlier, Edge-V can be deployed on an RSU with a smaller and different set of components. As for vehicles, the RSU is equipped with two external interfaces, i.e., mmWave and DSRC, while it does not include any internal Wi-Fi interface. The RSU includes a Computing Module, and, optionally, a Central VEI Manager, and it is connected to the Internet. Indeed, the RSUs are used by Edge-V for connection to the broader Internet, enabling further offloading of DL-based tasks to cloud or MEC servers in case no vehicles have enough onboard resources to reach the desired results. They can also execute tasks locally, if needed, as they can host a MultiAccess Edge Computing (MEC) server and use the internal available resources (CPU, RAM and GPU). Furthermore, a Central VEI Manager can be optionally deployed, to centrally manage groups of vehicles in a centralized VEI approach. It should be highlighted that this component is optional, and Edge-V is designed to work independently of a centralized unit. A. An Edge-V Walk-Through After describing the modules and components of Edge-V , this Section presents a brief walk-through, in five steps, of the main operations performed by Edge-V , focusing on a low-latency, DL-task offloading use case in a VEI scenario. In our example, (1) multimedia sensors generate DL tasks (e.g., object recognition from the output of a HD camera), which are captured through the Wi-Fi interface. (2) At the same time, Edge-V is receiving enhanced ITS messages which are used to populate the enhanced LDM, thanks to the enhanced wireless stack. (3) As DL tasks are being generated, Edge-V checks the available on-board resources thanks to the OM, which directly gathers this information from the Computing Module. (4) If the on-board resources, on the vehicle, are not enough, the OM selects the best remote vehicles to offload the task to. If no vehicles with enough resources and stable enough connection are available, task offloading will occur in the MEC/cloud thanks to the communication to one or more RSUs. To compute the needed information, the OM uses the information available in the LDM, solves an optimization problem and provides the results to the On-board service which needs the results of the DL task execution. (5) Finally, the On-board service can offload the tasks thanks to the mmWave links. The procedure herein described is represented in the flow chart in Figure 3. IV. EDGE-V : THE VEIP PROBLEM To practically enable VEI, optimized task offloading to other vehicles and infrastructure nodes with free resources should be fully supported and integrated with DL-based and other innovative use cases. For this reason, the OM can employ a mathematical model of the whole system to perform optimal decisions on where and how to offload tasks, at each time slot. This problem is called Vehicular Edge Intelligence Problem (VEIP). The main features of our model for VEIP can be summarized as follows: first, our model prioritizes offloading to other vehicles to reduce the load on the remote edge or cloud servers. Second, it retains generality and does not make any strong IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXX 2025 6 DL task generated Data transmission to EdgeV via internal Wi-Fi Reception at Edge-V Enhanced Local Dynamic Map with channel and node load information Enhanced wireless stack V2X messages DSRC Navigation data GNSS Offloading manager On-board resources enough? Send decision to process task locally to on-board services Determine best remote vehicles to offload task Optimization algorithm Vehicles available for offloading? Send information on remote vehicles to on-board services Send decision to offload to cloud/MEC mmWave Internal Wi-Fi Yes Yes No No Fig. 3. Flow chart of the operations performed by Edge-V , focusing on a DL-task offloading use case. assumption on the underlying channel model, as opposed, for instance, to [36] which focuses only on IEEE 802.11p. Third, it considers the possibility of multi-hop routing via mmWave thanks to graph modeling. Finally, it is worth mentioning how energy constraints can be neglected, since a system like Edge-V is expected to have negligible power consumption when compared to the typical output capacity of a car battery. For instance, our Proof-of-Concept, described in Section V, has a maximum and worst-case power consumption of around 25 W [37]–[39] (less than halogen headlight bulbs), but it is expected to have a much lower average consumption during normal operations. Additionally, with dedicated hardware supporting both DSRC and mmWave, the required power would be even lower. Considering a fuel-powered car battery with a capacity of 50 Ah, providing 12 V and considering a moderate load on our Edge-V prototype, with a power consumption of around 10 W, it would require around 60 hours to fully consume the battery when the vehicle is turned off. Among the related works proposing VEI models and algorithms, it is worth mentioning again the one by Higuchi et al. [26]. The authors define task completion probabilities which are shared between vehicles. Tasks are then offloaded based on deadlines. Although this represents a very valid approach, their model differs from VEIP, as our model attempts to explicitly minimize the average task completion latency, keeping the available resources as constraints, considering that, in vehicular networks, most tasks are safety critical and should be executed as soon as possible. For each DL task, the OM needs to make three main decisions: (i) which location tasks should be offloaded to, i.e., either other vehicles or the cloud/MEC; (ii) how many resources should be reserved on the same vehicles (or requested to the cloud/MEC); (iii) only if the tasks are splittable, which fraction of each task should be assigned to each destination node. We define as sources all vehicles that may offload tasks to other nodes, i.e., other vehicles or the MEC/cloud. Through the shared knowledge built thanks to the DSRC link, each source is supposed to be aware of the full mmWave network topology. At a given time slot, several tasks may need to be fulfilled by each source i. We define as fithe number of computations needed for the tasks of each source iwith respect to a given reference system (e.g., a given platform with a certain CPU and GPU). Furthermore, we assume no constraints on the available RAM and disk in the destination nodes. Several input quantities are then defined, all referring to a single time slot: 1) N={1, ..., n, k},|N | =ν, set of all the available n connected nodes; beside the connected vehicles, kis a special node modelling the access to the cloud (or to a MEC server), which can be accessed from all the vehicles. 2) S ⊆ N, |S| =ξ, set of all the source vehicles generating (and possibly performing) tasks at a given rate. 3) E={(w, z) : dwz < dlim ∧RSSIwz ≥RSSIlim} ∪ {w, k},1≤w≤n, 1≤z≤n, set of edges between nodes, i.e., active mmWave links with a good-enough signal. Furthermore, dlim is the distance limit above which any mmWave link is considered unstable, while RSSIlim is the RSSI limit below which any mmWave is considered unstable. The RSSI also considers realtime fluctuations in the wireless channel, due to weather and blockage. Thanks to this, when a degraded channel quality occurs due to weather or blockage, the RSSI will decrease, and the OM will be able to select other nodes for offloading, if available, mitigating as much as possible the effect of channel quality variations. 4) G= (N, E), graph of the current network topology, whose edges are represented by valid and stable mmWave links. 5) C={c1, ..., cν}, set of the currently available computational capacity of each node, in terms of computations per second, with respect to a given reference system, as defined for fi. The computational capacity is a function of the available CPU and GPU for each node j: cj=α(CPUj, GPUj). 6) Rij ={(i, h1, ..., hz, j):(i, h1)∈E, (hz, j)∈ E, (hi, hi+1)∈E, 1≤i≤z−1}, set of all routes from each source ito any possible destination j∈ N in the network. 7) L(i, j), latency of the route from source ito destination j. Assuming a symmetric channel, the Round Trip Time (RTT) can be represented by 2·L(i, j). This term depends on the amount of data Dij which needs to be transmitted from each source vehicle to each destination node, on the MAC-layer priority of the traffic Pij , and on the average wireless channel data rate bij. In turn, Dij depends on the actual task fraction assignment to each destination node: Dij =β(τij), where βmaps the task fraction to each destination node to the data which needs to be sent to that node. IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXX 2025 7 8) oj, overhead time of each destination node j. This time accounts for the overhead due to the message reception in the target operating system, data encoding and decoding and all the operations which do not depend on the size of the actual task. We also define a set of output quantities for each time slot, coming from the solution to the optimization problem: 1) Y∗={y11, ..., yij, ...yνν }, set of binary variables equal to 1 if node jhas been selected as destination node by source node i, 0 otherwise. 2) A∗ i={ai1, ..., aiν }, set of optimal resource assignment to each destination node in the network for the current source i. All nodes jsuch that yij = 1 will be destination nodes towards which the tasks are offloaded, and are expected to have some resources assigned to perform the tasks (aij ≥amin, where amin is the minimum amount of resources than can be reserved). Each aij is defined in terms of computations per second. 3) T∗ i={τi1, ..., τiν }, set of optimal task subdivision to each node in the network for the current source i. Each τij represents the fraction of task fiassigned to the destination node j. Each destination node j∈ D should have at least one non-zero τij, while each non-destination node jshould have all its τij = 0. 4) D ⊆ N , set of selected destination nodes to which the tasks should be offloaded. Each node jthat have at least one yij = 1 is a destination node. 5) δ=|D|, cardinality of the set D, i.e., the total number of destination nodes. 6) R∗ ij, set of selected optimal routes from each source ito the chosen destinations j. The VEIP problem is then modelled as follows: Find A∗ i,1≤i≤ξ(1a) T∗ i,1≤i≤ξ(1b) Y∗ i,1≤i≤ξ(1c) D ⊆ N :{1≤j≤ν:yij = 1,1≤i≤ξ}(1d) R∗ ij ⊆Rij ,1≤i≤ξ(1e) such that: minimize i, j X i∈S ν X j=1 {2·L(i, j) + τij aij +oj} · yij δ(1f) subject to: δ=X i∈S ν X j=1 yij (1g) X i aij ·yij ≤cj,∀j(1h) aij ≥amin,∀i, j (1i) X j yij ≥1,∀i(1j) X j τij =fi,∀i(1k) τij ≤M·yij ,∀i, j (1l) τij ≥τmin ·yij ,∀i, j (1m) The selected destination nodes and routes from sources to destinations are defined by the sets (1d) and (1e). The objective function (1f), instead, aims at minimizing the overall average latency and it is composed of multiple terms: (i) the RTT of the path towards the destination node; (ii) the computation latency, defined as the ratio between the number of computations needed to fulfill tasks from source vehicle iand the resources (number of computations per second) assigned to the destination node jfor the tasks of source node i; (iii) the overhead time, as defined earlier. Each term of the sum is divided by δ, that, as defined by equality Constraint (1g), represents the total number of destination nodes. This allows us to consider the minimization of the average latency, and not of the sum of all the latency values, that would penalize solutions that split more to achieve a lower delay for each couple of nodes (i, j). Constraint (1h) is the capacity constraint, ensuring that we cannot assign to a destination node (i.e., a node jfor which at least one yij is 1) more capacity than its current availability, while Constraint (1j) forces each task to be executed. Constraint (1i), instead, forces each destination node to be assigned at least the minimum possible amount of resources that can be reserved (amin). This also ensures the positivity of aij, that appears at the denominator of the objective function. Constraint (1k) forces each task from source ito be completely fulfilled by the selected destination nodes j. Finally, Constraints (1l) and (1m) make each destination node jwith yij = 1 perform at least a fraction of task τij , and each nondestination node jwith yij = 0 perform no computations for the current task fi. In our notation, Mrepresents an upper bound to the value of each τij, while τlim is a lower bound to the value of each τij. After formulating VEIP and its mathematical optimization model, we demonstrate that it is NP-Hard and propose an efficient, lightweight greedy solution that can be employed by the OM thanks to the development of proper open source software. Finally, it should be noted that VEIP is a Mixed-Integer Quadratically Constrained Program (MIQCP), since it can be reduced to a problem with quadratic terms both in the objective function and in the constraints [40]. Theorem 1. The proposed problem (VEIP) is NP-Hard. Proof. We prove the result by showing that the Knapsack problem (0/1 KP), which is known to be NP-hard [41], can be reduced to an instance of VEIP. To simplify and reduce the problem, we can make the following assumptions: 1) one destination node only (e.g., the cloud) can be selected for all the source nodes, thus, this allows us to remove the double sum in the objective function and the jindex; furthermore, this allows us to remove Constraint (1g) and δfrom the objective function as it will always be δ= 1; 2) the problem is now supposed to be unsplittable (like in the case of some scenarios, such as single frame inference), enabling us to replace τij with fiand remove constraints from (1k) to (1m); 3) task are allowed to be unfulfilled (this removes Constraint (1j)); IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXX 2025 8 4) the resource allocation for each source task aiis now given as a positive number greater than amin, and it does not represent anymore a decision variable. Under these assumptions, the problem now has only one set of decision variables (yi,∀i), while the other values are known input quantities. The problem can be thus rewritten as: minimize i, j ξ X i=1 (2 ·L(i) + fi ai +o)·yi= ξ X i ki·yi (2a) subject to: ξ X i ai·yi≤c(2b) This is an instance of an NP-Hard 0/1 KP problem, thus also VEIP is NP-Hard. A. DG-VEIP: A Greedy Solution to VEIP As the VEIP problem proved to be NP-Hard, the OM can employ an efficient Greedy Algorithm to solve it. We thus propose a distributed VEIP algorithm, here referred to as DG-VEIP. As an assumption, we consider the cloud/MEC as always reachable and available. Furthermore, DG-VEIP requires L(i, j)to be properly set depending on the scenario and on the set of tasks, and it is designed to be executed for each source vehicle i. Finally, we assume that connected vehicles are equipped with lane-level accurate GNSS receivers, as discussed earlier. The algorithm pseudocode is reported in Algorithm 1. Algorithm 1 Distributed Greedy VEIP Algorithm (DG-VEIP) 1: Define an empty list of vehicles V 2: Define the remaining task fraction to be assigned τrem ←fi 3: for n∈ N :path between iand nexists in Rij do 4: if n=kthen 5: Compute dn cn 6: else 7: dn cn← ∞ 8: end if 9: Add node to list V. 10: end for 11: Sort list Vby ascending dn cn 12: for v∈Vand τrem >0do 13: if cv>0then 14: Request all available capacity to the node: aiv ←cv 15: if v=kthen 16: cv←0 17: end if 18: Assign task fraction τiv such that it is completed before or in a ti time 19: τrem ←τrem −τiv 20: end if 21: end for At each time step ti, each source vehicle igenerates a number of tasks to be executed. The number of total computations needed fiis used to represent these tasks. Thanks to the enhanced LDM, each vehicle can scan the list of the Nconnected nodes (which can include the vehicle itself at dn= 0), and add them to a new list V(line 9), which is sorted in ascending order by the ratio of the distance and the available node capacity (which can be referred to as cost). The cloud (or MEC) node is artificially assigned the highest ratio among all other nodes (ideally ∞), so that it will be selected last, only if needed (line 7). As mentioned earlier, the distance already takes into account the mobility pattern followed by the vehicles. Indeed, the speed of the vehicles will directly affect how the distance evolves at each time step tifor which DG-VEIP is executed, which in turn influences each cost term. The algorithm then loops over all the nodes in V(line 11) until all the ficomputations have been offloaded (or performed by itself or by the cloud). The variable τrem represents the number of remaining computations which need to be offloaded. If a node in Vis found with free computation resources (line 12), the source vehicle will require all its capacity (line 13), to try to minimize the latency, and assign a task fraction τiv such that the task is either completed in atitime, meeting the deadline of the next time frame, or before that time, if the node has more computation resources available (line 17). Finally, it should be mentioned that the cloud is supposed with no hard resource limits, and it can thus be always selected as last possibility when no other local vehicles can be selected. DG-VEIP has been implemented in a dedicated MATLAB function, which has been exploited to evaluate its usage within Edge-V and which is going to be become publicly available, on GitHub, under the GPLv2 license. DG-VEIP represents a sample, yet effective, greedy algorithm that can be integrated into the OM to provide solutions with a limited complexity of O(n·log(n)). Indeed, the first for loop has a complexity of O(n), and the second for loop O(v)with v≤n(thus, at worst it will also run in O(n)). The most complex operation from an algorithmic point of view is instead sorting (line 11), that can be implemented to be executed in O(n·log(n)). Combining the complexity of the different phases, we get O(n) + O(n) + O(n·log(n)), with the most significant term being O(n·log(n)). Therefore, the overall algorithm complexity is O(n·log(n)). It should be mentioned that DG-VEIP represents a baseline algorithm to efficiently offload tasks in Edge-V . More advanced versions can be easily implemented as part of the OM, and they are currently being developed, including an enhancement that considers the channel RSSI, in addition to dn cn . Finally, it should be mentioned that a simplified version of DG-VEIP has been employed to demonstrate the effectiveness of Edge-V in the field (Section VI-C2), as a possible Offloading Manager algorithm implementation. V. EDGE-V : PROTOTYPE DESIGN Figure 4 provides a high-level overview of our Proof-ofConcept. As can be seen, the Edge-V prototype is designed to be deployed inside an RSU Road Side Unit (RSU) and multiple OBUs. Specifically, we assembled three OBUs, to be deployed on up to three vehicles, and one RSU, which we then used to evaluate Edge-V on the field and in a laboratory environment. As mentioned, Edge-V is characterized by its openness. Therefore, all key features of our framework have been implemented using low-cost, commercially-available hardware IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXX 2025 9 and with well-documented open source software components. We selected three IEEE 802.11-based standard, i.e., IEEE 802.11ac for the 5 GHz Wi-Fi internal connectivity, IEEE 802.11p for the DSRC link, and IEEE 802.11ad for mmWave at 60 GHz. It should be mentioned how a commercial C-V2X module supporting Sidelink communication at 5.9 GHz could be possibly employed instead of IEEE 802.11p, yielding a similar performance with slightly higher network latency [42]. However, we focus on IEEE 802.11p due to the wider hardware availability and being it the most deployed technology in Europe. Fig. 4. The proof-of-concept prototype of Edge-V . A. Hardware Components The prototype hinges upon customizable embedded PC Engines APU2E4 hardware boards [37], equipped with a quadcore AMD GX-412TC 1 GHz embedded CPU and 4 GB of RAM, running the latest version of OpenWrt-V2X (21.02) and with a maximum power consumption of around 12 W. OpenWrt-V2X is a patched version of the OpenWrt embedded Linux distribution, enabling IEEE 802.11p communication and providing additional tools for automotive services [43]. This version of OpenWrt has been successfully evaluated in past research works, together with 5.9 GHz-enabled UNEX DHXA-222 wireless cards, in both static [44] and dynamic scenarios [18]. Each board has been enhanced with the installation of: •An Atheros AR5B22 mPCIe wireless module for the IEEE 802.11p interface. This module relies on the same chipset (AR9462) as the UNEX DHXA-222 cards, and it is characterized by the same performance and maximum selectable transmission power (18 dBm). •A Compex WLE1216V5-23 Multi-User Multiple-Input and Multiple-Output (MU-MIMO) 4x4 IEEE 802.11ac mPCIe card, providing a relatively high maximum transmission power (up to 29 dBm with MCS 0). As this module requires a 5V additional power supply, we used mini PCI express extender cards, which have been installed in one of the APU2E4 miniPCIe slots and on which we soldered a jumper cable. The cable has been soldered, in particular, to the reserved pins of the extender cards (45, 47, 49, 51), which can also be used to provide an additional power supply to the Compex chips. Each APU2 board (both OBUs and RSU) is connected to a MikroTik wAP 60G [39], through one of the available Ethernet ports. These devices are IEEE 802.11ad routers working in the 60 GHz unlicensed spectrum and equipped with 6x6 planar phased antenna arrays, covering an angular range of 60 degrees. According to [18], they are able to reach up to 300 m with an RSSI higher than -70 dBm, in nearly ideal Line-Of-Sight (LOS) conditions. Since these devices are still unable to establish direct peer-to-peer links, we deployed an additional MikroTik wAP 60Gx3 Access Point, to which all the devices in the testbed are connected and acting as relay node. This strategy makes the client devices appear as if they are directly connected together. Finally, since the APU2 boards do not embed a GPU for executing DL tasks, we interfaced each board (except the RSU one) with an Nvidia Jetson Nano Development Kit. The Nvidia Jetson Nano can be exploited for GPU computation and can be easily connected to an APU2 board through a Gigabit Ethernet point-to-point link. It should be mentioned how the Nvidia Jetson Nano employs an ARM Cortex-A57 MPCore CPU, a GPU with a performance up to 512 GFLOPS, and 4 GB of RAM. Due to the available resources, with a model such as MobileNet v3 [45], a Jetson Nano is typically able to perform inference on one frame at a time. B. Software Components The European ETSI ITS-G5 set of standards has been taken as reference for the implementation of the enhanced wireless stack. Therefore, CAM messages are used to periodically broadcast, via IEEE 802.11p, vehicle information such as speed, acceleration, position and heading. However, there are currently no standardized messages for the exchange of channel-related and load-related metrics, as required by Edge-V . This data is of utmost importance to enable the next generation edge intelligence use cases, which require, at the same time, offloading and local computation to reduce latency. Hence, we designed an additional, ETSI-compliant, optional container (the Channel and Node Status Container) that can be inserted inside standard CAM messages, enhancing them with the information needed to enable VEI and task offloading. Our proposed container has been defined by upgrading the standard CAM specifications, written in the ASN.1 description language [31]. Starting from the ASN.1 definition, it was then possible to generate the code for the encoding and decoding functions thanks to the asn1c tool [46]. The supplementary container1comprises various information, including (i) the load on CPU, GPU, and RAM of the OBU, (ii) available disk space, (iii) RSSI and data rate of both V2X-dedicated (e.g., DSRC) and additional (e.g., mmWave) 1The ASN.1 file is available here: https://github.com/francescoraves483/ EnhancedCAMs-asn1 IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXX 2025 16 [18] F. Raviglione, M. Malinverno, S. Feraco et al., “Experimental Assessment of IEEE 802.11-Based V2I Communications,” in 18th ACM Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, & Ubiquitous Networks. ACM, 2021, p. 33–40. [19] S. Wang, J. Huang, and X. Zhang, “Demystifying Millimeter-Wave V2X: Towards Robust and Efficient Directional Connectivity under High Mobility,” in Proceedings of the 26th Annual International Conference on Mobile Computing and Networking. ACM, 2020. [20] J. Senic, A. Bhardwaj, C. Gentile et al., “Challenges for 5g and beyond,” in 2022 16th European Conference on Antennas and Propagation (EuCAP), 2022, pp. 1–5. [21] S. Mumtaz, J. M. Jornet, J. Aulin et al., “Terahertz Communication for Vehicular Networks,” IEEE Transactions on Vehicular Technology, vol. 66, no. 7, 2017. [22] M. Giordani, A. Zanella, T. Higuchi et al., “On the Feasibility of Integrating mmWave and IEEE 802.11p for V2V Communications,” in 2018 IEEE 88th Vehicular Technology Conference (VTC-Fall), 2018, pp. 1–7. [23] B.-J. Qiu, C.-Y. Hsieh, J.-C. Chen et al., “DCOA: Double-Check Offloading Algorithm to Road-Side Unit and Vehicular Micro-Cloud in 5G Networks,” in GLOBECOM 2020, 2020, pp. 1–6. [24] E. Krijestorac, A. Memedi, T. Higuchi et al., “Hybrid Vehicular and Cloud Distributed Computing: A Case for Cooperative Perception,” in GLOBECOM 2020, 2020, pp. 1–6. [25] C. Tang, C. Zhu, X. Wei et al., “Task Caching in Vehicular Edge Computing,” in IEEE INFOCOM Workshops 2021, 2021, pp. 1–6. [26] T. Higuchi, S. Ucar, and O. Altintas, “Offloading tasks to vehicular virtual edge servers,” in 2019 IEEE 16th International Conference on Mobile Ad Hoc and Sensor Systems Workshops (MASSW), 2019, pp. 162–163. [27] I. Royuela, J. C. Aguado, I. de Miguel et al., “A testbed for ccam services supported by edge computing, and use case of computation offloading,” in NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, 2022, pp. 1–6. [28] B.-J. Qiu, C.-Y. Hsieh, J.-C. Chen et al., “Tcoa: Triple-check offloading algorithm for roadside units and vehicular microclouds in 5g networks and beyond,” IEEE Access, vol. 11, pp. 84 985–85 001, 2023. [29] Q. Wu, H. Ge, Q. Fan et al., “Efficient task offloading for 802.11p-based cloud-aware mobile fog computing system in vehicular networks,” Wireless Communications and Mobile Computing, vol. 2020, no. 1, p. 8816090, 2020. doi: https://onlinelibrary.wiley.com/doi/abs/10.1155/ 2020/8816090 [30] M. S. Bute, P. Fan, G. Liu et al., “A cluster-based cooperative computation offloading scheme for c-v2x networks,” Ad Hoc Networks, vol. 132, p. 102862, 2022. doi: https://www.sciencedirect.com/science/ article/pii/S1570870522000622 [31] ETSI, “ETSI EN 302 637-2 V1.4.1 (2019-04),” European Telecommunications Standards Institute, Standard, 2019. [32] ——, “ETSI EN 302 636-4-1 V1.4.1 (2020-01),” European Telecommunications Standards Institute, Standard ETSI EN 302 636-4-1, 2020. [33] Z. Li, Y. Guo, and X. Ge, “Performance analysis of urban mmwave multi-hop v2v communications with shifted-exponential distribution headway,” in 2019 IEEE International Conference on Communications Workshops (ICC Workshops), 2019, pp. 1–6. [34] ETSI, “ETSI EN 302 895 V1.1.1 (2014-09),” European Telecommunications Standards Institute, Standard, 2014. [35] ——, “ETSI TS 103 301 V2.1.1 (2021-03),” European Telecommunications Standards Institute, Standard ETSI TS 103 301 V2.1.1, 2021. [36] Y. He, D. Zhai, R. Zhang et al., “A Mobile Edge Computing Framework for Task Offloading and Resource Allocation in UAV-assisted VANETs,” in IEEE INFOCOM 2021 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), 2021, pp. 1–6. [37] PC Engines. (2025) PC Engines apu2 system boards [online]. https: //www.pcengines.ch/apu2.htm. [38] NVIDIA. (2025) NVIDIA Jetson Nano [online]. https: //www.nvidia.com/en-us/autonomous-machines/embedded-systems/ jetson-nano/product-development/#:∼:text=Other%20I%2FO%203x% 20UART%2C%202x,DIMM%20connector. [39] MiktroTik. (2025) MiktroTik Routers and Wireless - Products: wAP 60G [online]. https://mikrotik.com/product/wap\60g. [40] S. Burer and A. Saxena, “The MILP Road to MIQCP,” in Mixed Integer Nonlinear Programming, J. Lee and S. Leyffer, Eds. New York, NY: Springer New York, 2012, pp. 373–405. [41] V. V. Vazirani, Knapsack. Berlin, Heidelberg: Springer Berlin Heidelberg, 2003, pp. 68–73. doi: https://doi.org/10.1007/ 978-3-662-04565-7 8 [42] F. Raviglione, C. R. Carletti, M. Malinverno et al., “ms-van3t: An integrated multi-stack framework for virtual validation of v2x communication and services,” Computer Communications, vol. 217, pp. 70–86, 2024. doi: https://www.sciencedirect.com/science/article/pii/ S0140366424000227 [43] F. Raviglione. (2021) OpenWrt-V2X [online]. https://github.com/ francescoraves483/OpenWrt-V2X. [44] F. Raviglione, M. Malinverno, and C. Casetti, “Characterization and Performance Evaluation of IEEE 802.11p NICs,” in 1st ACM MobiHoc Workshop on Technologies, MOdels, and Protocols for Cooperative Connected Cars. ACM, 2019, p. 13–18. [45] A. Howard, M. Sandler, G. Chu et al., “Searching for MobileNetV3,” CoRR, vol. abs/1905.02244, 2019. doi: http://arxiv.org/abs/1905.02244 [46] L. Walkin. (2021) The ASN.1 Compiler [online]. https://github.com/vlm/ asn1c. [47] ETSI, “ETSI EN 302 636-5-1 V2.2.1 (2019-05),” European Telecommunications Standards Institute, Standard, 2019. [48] F. Raviglione. (2022) LTNT (Long Term Network Tester) [online]. https: //github.com/francescoraves483/LTNT. [49] T.-Y. Lin et al., “Microsoft coco: Common objects in context,” in Computer Vision – ECCV 2014. Cham: Springer International Publishing, 2014, pp. 740–755. [50] Z. Ge, S. Liu, F. Wang et al., “YOLOX: Exceeding YOLO Series in 2021,” arXiv preprint arXiv:2107.08430, 2021. [51] F. Raviglione, M. Malinverno, and C. Casetti, “A Flexible, ProtocolAgnostic Latency Measurement Platform,” in 2019 IEEE 90th Vehicular Technology Conference (VTC2019-Fall), 2019, pp. 1–5. [52] ETSI, “ETSI TS 101 539-2 V1.1.1 (2018-06),” European Telecommunications Standards Institute, Standard, 2018. [53] ——, “ETSI TS 101 539-2 V1.1.1 (2013-11),” European Telecommunications Standards Institute, Standard, 2013. [54] 5G-CARMEN. (2022) Home page - 5G-CARMEN [online]. https: //5gcarmen.eu/. [55] T. H. L. Dinh, M. Kaneko, and K. Fujii, “Device selection and beamforming optimization in large-scale mmwave iot networks,” IEEE Internet of Things Journal, vol. 9, no. 24, pp. 25 395–25 408, 2022. [56] ETSI, “ETSI TS 102 687 V1.2.1 (2018-04),” European Telecommunications Standards Institute, Standard, 2019. Francesco Raviglione is an assistant professor with time contract at the Department of Electronics and Telecommunications in Politecnico di Torino, after he completed his Ph.D. cum laude in 2022, with a thesis titled “Open Platforms for Connected Vehicles”. His research mainly focuses on services, applications and technologies for connected vehicles, with an emphasis on open hardware and software solutions. Claudio Casetti is a full professor at the Department of Control and Computer Engineering, Politecnico di Torino. He has published more than 200 papers in peer-refereed international journals and conferences on the following topics: vehicular networks, 5G networks, transport and network protocols in wired networks, and IEEE 802.11 WLAN. Francesco Restuccia [M’16, SM’21] is an Assistant Professor in the Department of Electrical and Computer Engineering at Northeastern University. His research interests lie in the design and experimental evaluation of next-generation edge-assisted data-driven mobile systems. Prof. Restuccia has published over 60 papers in top-tier venues in computer networking, as well as co-authoring 16+ U.S. patents and three book chapters. He regularly serves as a TPC member and reviewer for several top-tier ACM and IEEE conferences and journals.