ETSI-Compliant Protection of Connected Vulnerable Road Users: Simulation and Field Trial

According to the latest statistics, a consistent share of road accidents involves Vulnerable Road Users (VRUs). This calls for the adoption of urgent measures to guarantee their safety while sharing the road with other vehicles. Thanks to the technological advantages of wireless networks, Vehicle-to-Everything communication (V2X) have been proposed as a solution to improve not only the safety, but also the environmental impact and effectiveness of road transport systems. To this aim, the European Telecommunication Standards Institute (ETSI) has defined a set of standards dedicated to VRUs, with the definition of the so-called VRU Basic Service (VBS) defining a dedicated V2X message (VAM, VRU Awareness Message) and several rules for the transmission of such messages. This work proposes an open implementation of the VBS, aimed at evaluating V2X scenarios with connected VRUs. Our implementation targets both simulations and field tests, and has been used to extensively assess the effectiveness and the critical points of the VBS. Our work also explores advanced features like proximity triggering and redundancy mitigation, under different simulated and real-world scenarios, thanks to a setup with a connected vehicle and an equipped stroller.


I. INTRODUCTION
According to the "Statistics of Road Traffic Accidents" report [1] from the United Nations Economic Commission for Europe, 20.5% of the total number of persons killed in road traffic accidents in 2019 in Europe and North America were pedestrians.The equivalent share of this statistic in the two study areas, North America and Europe, is 17.2% and up to 23.2%, respectively.These surprisingly high numbers highlight the relevance of Vulnerable Road Users (VRUs) in road scenarios.
An effective way to address the problem comes from the technological advances in the telecommunications field applied to the vehicular environment, which have given birth to the concept of vehicular networks (also called Vehicleto-Everything, V2X).In V2X, different road users exchange data through a dedicated wireless network, enabling advanced safety use cases and an improved perception of the surrounding environment [2].Among the standardization efforts for V2X, the European Telecommunications Standards Institute (ETSI) included in its C-ITS (Cooperative Intelligent Transportation System) stack a set of standards dedicated to VRUs, namely ETSI TR 103 300-1 [3], ETSI TS 103 300-2 [4] and ETSI TS 103 300-3 [5].In the mentioned standards, four VRU profiles are defined (pedestrians, bicycles, motorcycles, and animals).ETSI also describes a consistent number of use cases involving VRUs, the functional characteristics of a VRU Basic Service (VBS), and a new V2X message dedicated to VRUs, i.e., the VRU Awareness Message (VAM).VAMs are periodic messages with similar features as vehicular Cooperative Awareness Messages (CAMs), but entirely dedicated to VRUs.
While scenarios with vehicles exchanging CAMs have been extensively studied, there are still very few studies evaluating the proposed VBS facility and its features in a simulated environment and on the field.This is due to several reasons.First, the set of ETSI standards mentioned earlier was released just recently.Second, there is no existing smartphone today supporting the dedicated frequencies for direct communication between vehicles and pedestrians [6], making it fairly complex to equip pedestrians for field tests.Third, there is currently a lack of open and customizable frameworks for testing V2X use cases with both vehicles and pedestrians in simulation and in the field.
To tackle this issue, in this paper we present an open implementation of the ETSI VRU Basic Service (VBS) with the aim of testing its capabilities both in a simulated environment and with dedicated field tests, using IEEE 802.11p (i.e., the direct "vehicular WiFi") as communication technology.Specifically, our work improves the existing literature by several aspects, namely: (i) it extends both the existing open ms-van3t simulator [7] and its corresponding framework for field tests with an ETSI-compliant VRU Basic Service (VBS) instance, following the ETSI standards; (ii) it provides extensive results from simulation analysis and from field tests, considering advanced features such as proximity triggering; (iii) following the discussion in [8], it discusses the issue of the heading triggering condition with a consistent field test analysis.
The rest of the paper is organized as follows: Section II describes the state of the art of existing literature on V2X scenarios with VRUs, considering both simulated and realworld environments.Section III provides a brief insight into the ETSI standards defining the VBS, and it discusses the methodology followed for the implementation of the service both in simulation and on a real hardware board for field tests.Finally, Section IV shows the obtained results from our simulations and field test campaigns, while Section V summarizes and concludes the paper.

II. RELATED WORK
Several works in the literature have focused on connected VRUs, starting with the work of Anaya et al. [9] which shows how efforts to connect VRUs in vehicular networks were already being made a few years before ETSI tackled the issues with VAMs that are leveraged by our implementation.
The authors of [10] study different possible network architectures to improve VRU safety on the road with both passive (detected) and active (connected) pedestrians.The analysis is performed in simulation by combining two ns-3 models for LTE-V2X and NR-V2X with the commercial 4DV-SIM simulator, and it focuses on a collision warning use case.While their focus is mainly on application-layer metrics, we concentrate instead on the underlying ETSI stack and how it can enable applications like collision avoidance.We also take a further step over the simulations, thanks to an extensive set of field trials.
Similarly to [11], the authors of [12] implement a VBS service for OMNeT++, extending Artery [13] and evaluating the impact of connected VRUs on their safety in a roundabout scenario, leveraging VAMs and CPMs.In contrast, we focus more on Facilities and Network Layer-metrics, to analyze how VAMs are disseminated according to the latest ETSI standards and the effects of techniques such as redundancy mitigation.Furthermore, we aim to provide a simulation framework based on ns-3 (thanks to an extension of the ms-van3t simulation and emulation framework [7]) that enables easy porting of the developed features to real On-Board Units (OBUs).
Indeed, the great majority of works encompassing the usage of VAMs, according to ETSI, are simulation-based.Concerning real-world tests in the field, instead, there is currently a scarcity of results collected by equipping vehicles and VRUs with proper hardware for ETSI-compliant V2X communications.While for pedestrians it can be challenging to deploy a device small enough and supporting the European frequency bands at 5.9 GHz [14], this operation can be much more easily performed by cyclists, motorcycles, and even "smart strollers", as in our evaluation.
The most relevant example of field tests with VRUs is the work by Lusvarghi et al. [8], in which the dissemination of VAMs is analyzed in the field using Quectel AG15 devices supporting Release 14 LTE-V2X and equipping both a bicycle and an e-scooter.Besides the LTE-V2X Packet Delivery Ratio (PDR), the authors analyze the effect of the different triggering thresholds foreseen by ETSI on the number of VAMs transmitted.Among their results, they highlight how a threshold of 4 degrees for the heading appears to be too low, causing the generation of an excessive number of VAMs due to heading drifts, caused in turn by the accuracy of real-world GNSS positioning systems.To address this issue, they suggest that a threshold of 10 degrees leads to more significant results.Thus, in our work, we test both 4 and 10 degrees accordingly.The work in [8] provides interesting insights on connected VRUs in the field; however, the authors focus exclusively on field trials and do not consider standardized services.On the contrary, we propose an exhaustive implementation of the VBS and performance evaluation, first in simulation and then in the field.We also propose an enhancement to a simulation framework [7] and an open-source tool for testing V2X applications with VRUs in the field.These tools closely follow the latest ETSI standards, leaving, at the same time, a large room for customization.
Besides simulations, field tests face several challenges, partly due to the limited availability of open solutions for research and experimentation.While commercial solutions exist from OBU producers such as Cohda Wireless or Commsignia, these commercial units come with expensive SDKs (Software Development Kits), with few customization opportunities.
On the other hand, very few open ETSI C-ITS stacks are currently available.Among them, the most relevant example supporting VAMs is NAP-Vanetza [15], a framework that extends the Vanetza project [16].NAP-Vanetza supports a wide set of ETSI C-ITS messages, including VAMs, and it provides additional MQTT and JSON capabilities.However, at the time of writing, it only includes the features to encode and decode messages without a full-fledged VBS implementation to test the standard-compliant dissemination of VAMs and to experiment with techniques such as VAM redundancy mitigation.
To the best of our knowledge, this is the first paper presenting at the same time: (i) the implementation of a full VBS for the dissemination of VAMs, integrated with a CA Basic Service and a Local Dynamic Map (LDM) [17] for both simulations and field tests, released under an open-source license; (ii) the simulation of realistic scenarios thanks to the enhancement of an open simulation and emulation framework for V2X; (iii) the evaluation of the ETSI Facilities Layer for VRUs in the field, comparing the results with simulation and analyzing the triggering of VAMs due to advanced conditions (e.g., the proximity triggering condition, by receiving CAMs and gathering real-time information from the LDM).

III. ETSI VRU BASIC SERVICE IMPLEMENTATION
According to the ETSI standards, VRUs are defined as nonmotorized road users as well as users of light, non-powered vehicles, and they can be divided into four VRU profiles: pedestrians, bicycles, motorcycles, and animals.It is worth highlighting that not all the VRUs are able to transmit and receive ITS messages (e.g., pedestrians without a smartphone or animals), but they are still treated as VRUs when detected by other equipped ITS-Stations (ITS-S), i.e., through sensors mounted on a vehicle.On the other hand, VRUs with transmission and reception capabilities are the ones primarily considered in the ETSI standards for the implementation of the so-called VRU Basic Service (VBS).
The main functionalities defined for the VBS are related to the management of the VRU Awareness Messages (VAMs), comprising their generation and transmission rules, their encoding/decoding, the VAM redundancy mitigation, and the VRU cluster management, where the last two functionalities are devised to reduce channel congestion.VAM redundancy mitigation targets individual VRUs located very close to each other and moving with coherent velocities and directions with respect to another VRU in close proximity.The VRU cluster management focuses instead on consistent groups of VRUs that move all together.

A. Implementation on simulated environment
The simulation framework we used for our model is ms-van3t [7].ms-van3t is a V2X simulation and emulation framework based on ns-3 and SUMO for modeling the transmission channel and vehicle mobility, respectively, with an optional interface to the CARLA autonomous driving simulator.It supports several ETSI C-ITS messages (i.e., CAMs, DENMs, IVIMs, and CPMs), the related Basic Services, and a number of access technologies (i.e., IEEE 802.11p,LTE-V2X, NR-V2X, and infrastructured LTE).In the context of this work, we extended the current ms-van3t framework with a full implementation of a VRU Basic Service (VBS).
As a first step, we implemented the ETSI-standardized message dedicated to VRUs, i.e., the VRU Awareness Message (VAM).A VAM includes all the motion status (e.g., generation time, position, heading, speed, etc.) and the attribute information (e.g., VRU type, device usage, cluster information, etc.) related to the originating VRU ITS-S.According to the Fig. 1.A VRU or a vehicle violates the minimum safe distances of another VRU when it finds itself inside the purple 3D shape in the figure.Specifically, the rectangular shape is defined with a longitudinal distance in blue, a lateral distance in red, which are both depending on the speed of the ego-VRU, and a fixed vertical distance of 5 m in green.
ETSI standards, a VRU should broadcast VAMs periodically, which are then disseminated through access technologies such as IEEE 802.11p or C-V2X, working in the 5.9 GHz frequency band (i.e., the standard frequencies for transmitting ITS messages in Europe).Depending on the motion pattern of the originating VRU, a VAM should be sent with a periodicity between 100 ms and 5 s, following a set of standardized triggering conditions.
VAM triggering conditions are the core of the VBS and, thus, of our implementation.Following the standards, there are seven triggering conditions that shall be checked every 100 ms [5].Specifically, a VAM should be sent by a given VRU (i.e., the ego-VRU) when: 1) the time elapsed since the last VAM transmission exceeds 5 s; 2) the Euclidean absolute distance between the current position of the ego-VRU and the position included in the last VAM transmitted is greater than 4 m; 3) the absolute difference between the current speed of the ego-VRU and the speed included in the last VAM transmitted is greater than 0.5 m/s; 4) the absolute difference between the orientation of the current velocity vector (i.e., the heading) of the ego-VRU and the orientation of the velocity vector included in the last VAM transmitted is greater than 4 degrees; 5) the absolute difference between the current trajectory interception probability with other VRUs or vehicles and the trajectory interception probability included in the last VAM transmitted is greater than 10%; 6) the ego-VRU decides to join a VRU cluster; 7) the ego-VRU has determined that one or more VRUs or vehicles are in his close proximity, i.e., are inside a dynamic 3D-shape, as described in Fig. 1, and thus they violate the minimum safe distances of the ego-VRU.
Since the VRU clustering and the VRU motion prediction containers were left for future development, we decided to focus on conditions 1 to 4, and 7.It is worth underlining how the thresholds for conditions 2 to 4, related to the variation of position, speed, and heading, respectively, are meant to be recommended lower bounds and not hard constraints as in the case of vehicular CAMs [18].This permits us to conduct, in the next Section, a study on possible variations of condition 4, with different thresholds, while still being compliant to the ETSI standards.An important feature foreseen by the standards and implemented in our VBS is the VAM redundancy mitigation.The VAM redundancy mitigation is critical for preventing channel congestion caused by messages that are duplicated or provide low-information content.Indeed, when two or more VRUs are close to each other and they have similar motion patterns (e.g., similar positions, speeds, and headings), it is much less effective to let all VRUs send their VAMs periodically, as only a few messages may be enough to enable the great majority of safety use cases.As a matter of fact, in this specific case, the VAMs transmitted by different VRUs will have very similar information stored therein.In such a situation, the VAM redundancy mitigation is activated, and every involved VRU picks a random number between 2 and 10.The selected number represents the number of times a VAM transmission is skipped by the corresponding VRU (the selection of random values, for each VRU, can help in avoiding synchronized transmissions).While the aim of the VAM redundancy mitigation is similar to that of VRU clustering, it is important to notice that the redundancy mitigation, unlike clustering, is also applied to groups of VRUs formed by only two members.
Once we implemented all the VBS functionalities described above, we prepared a set of simulation models to perform our study.Our reference model considers the area around Corso Castelfidardo, a main avenue in Turin, Italy, passing through the Politecnico di Torino campus.This area is particularly interesting for our analysis since consistent flows of students cross the avenue daily at the traffic light junction, while the intersecting road is characterized by heavy vehicular traffic, especially at peak hours.
As can be seen from the modeled map in Fig. 2, our study considers 45 simulated vehicles, in yellow, and 25 simulated pedestrians, in blue, moving in the scenario in a 250 s span.Pedestrians in the model can send VAMs according to their motion pattern and the generation rules of the VBS described earlier, while vehicles transmit CAMs according to the corresponding ETSI standard [18].All messages are broadcasted in the 5.9 GHz frequency band using IEEE 802.11p and can be received by any entity (i.e., vehicle or pedestrian) configured to use the same channel, i.e., the CCH (Control CHannel, as per ETSI definition).Thanks to ms-van3t, messages transmitted and received by any entity can be logged in a pcapng packet trace file format.These files can be easily parsed by the Wireshark packet analysis software, and they represent one of the outputs of our simulations, from which we were able to extract several metrics as reported in Section IV.

B. Setup for field tests
Once the VBS was analyzed in a simulated environment, we ported our implementation from the ms-van3t simulator to a hardware board dedicated to field tests, with the aim of evaluating the effectiveness and performance of the VBS in a realworld scenario.The hardware board we selected is an APU2C4 embedded board running the latest version of OpenWrt-V2X (21.02.1).The latter is a tailored adaptation of the OpenWrt Linux operating system, designed to enable communication through IEEE 802.11p over the 5.9 GHz frequency band, with additional features dedicated to V2X communications [19], [20].Furthermore, we coupled our board with an ArduSimple simpleRTK2B Fusion board.These devices are high-accuracy GNSS receivers that are able to reach up to centimeter-level accuracy thanks to Real Time Kinematic (RTK).Furthermore, they include an Inertial Measurement Unit (IMU) to perform dead-reckoning and provide reliable localization even in the absence of direct satellite visibility.Finally, an external 12 V power supply and two dedicated GNSS and DRSC antennas were connected to our setup.The latter are optimized, respectively, for the GNSS bands supported by the ArduSimple receiver and for V2X communication at 5.9 GHz.
Concerning the porting of the code from ms-van3t to our hardware board, we enhanced our OScar (Open Stack for car) framework 1 , an ongoing open-source implementation of the ETSI C-ITS stack for Linux-based operating systems, designed to be deployed both on commercial solutions and on customizable open hardware for field tests.It is designed to include the full ETSI Basic Services and to enable the dissemination of ETSI C-ITS messages over any wireless or wired interface, while support for Qualcomm and Autotalks C-V2X SDKs is currently under development.In OScar we implemented additional VAM and VBS functionalities, besides the already available CA Basic Service.Since OScar was developed starting from the same codebase as ms-van3t, it was possible to port our VBS code from the simulator to it with a few steps.
To perform our field test experiments with VAMs, a dedicated setup with a stroller was employed, as shown in Fig. 3, due to the difficulty in making a pedestrian carry all the experimental equipment [14].This is a sensible solution, as strollers for kids can indeed be considered VRUs that must be protected against collisions and other accidents may happen on the road.For these reasons, our final choice was to mount our equipment on a stroller, as depicted in Fig. 3a and in Fig. 3b.This "smart stroller" is provided with a spacious bag where our hardware can be placed (see Fig. 3c).In addition, being unable to perform very sharp turns, it has a more stable, predictable motion pattern.Thanks to this special setup, we were able to drive our "V2X equipped stroller" through the city of Turin, as shown in Fig. 3d, gathering the field test results detailed in Section IV.

IV. RESULTS
The main goal of the results presented in this Section is to evaluate the effectiveness of our VRU Basic Service (VBS) by analyzing the VAM dissemination, to assess the standardized triggering conditions against VAM transmission frequency in both simulations and field tests.

A. Simulation results
We present here the most relevant simulations results with ms-van3t.Starting from the results shown in Fig. 4, we inspected how VAMs are disseminated based on their triggering conditions and their transmission frequencies, taking a single VRU as a reference.Every colored point in Fig. 4a illustrates the position where a VAM has been sent, while the simulated VRU moves throughout the scenario.Their colors, representing the different triggering conditions, match the ones in Fig. 4b, where the percentages of VAMs sent with respect to their transmission frequencies are shown.It is possible to see how the simulated pedestrian starts its trip in a static position (i.e., the purple point at the right of Fig. 4a), sending VAMs every 5 s due to the time triggering condition.After a few seconds, the VRU starts moving along the sidewalk, and it disseminates VAMs with a higher frequency when proceeding straight, in cyan, and when turning, in yellow, due to position and heading triggering conditions, respectively.It is worth mentioning that, in our simulation, all pedestrians move at a constant speed of 5 km/h.This results in a quite predictable transmission pattern, where most of the messages that are sent due to the position triggering condition have a transmission periodicity close to 3 s, as clearly shown by the cyan bars in Fig. 4b.The only VAMs sent due to the speed triggering condition, in red, are close to the traffic lights at the intersection when the VRU halts and restarts, causing noticeable differences in speed.In the same area, we can also see a few VAMs sent due to the proximity triggering condition, colored dark blue, and sent with a maximum frequency of 10 Hz.In such a situation, we can find other VRUs in close proximity to the ego-VRU since they are all halted at the red traffic light.It is clear how this does not constitute a critical situation for VRU safety, but the channel is nevertheless loaded with a number of VAMs greater than what would be really needed.This is a significant case in which the VAM redundancy mitigation should be activated, reducing the number of VAMs sent by each VRU and reducing the load on the channel.
Concerning the VAM redundancy mitigation, a separate analysis was conducted considering a simulated scenario with two VRUs moving together with the same motion pattern at close distances from each other.Among the most interesting results, we obtained an average reduction of 78% of VAM transmissions thanks to the redundancy mitigation effect.On the other hand, it is clear how a VRU transmitting VAMs at a lower frequency, due to redundancy mitigation, may advertise the wrong position to cars around it.Therefore, in the same scenario, we analyzed the average distance traveled by a VRU between two consecutive VAM transmissions.We observed that a pedestrian travels on average 0.78 m between two consecutive VAM transmissions when the redundancy mitigation is turned off, while it can reach an average of 1.42 m with the redundancy mitigation effect.Even if the distance traveled is almost doubled, we can still claim that this is small enough to make sure that safety services can be promptly informed about the presence of users.Indeed, considering an average walking speed of 5 km/h, a VRU can travel 1.42 m in about 1 s.

B. Field tests results
After validating our VBS in a simulated environment, we conducted a series of field tests using our equipped stroller.Our main aim was to assess the performance of the VBS in real-world conditions, with a focus on how VAMs are triggered.It should be noted how the selected hardware, designed primarily for automotive settings, poses some challenges for providing accurate pedestrian positioning, despite our efforts to optimize it with a dedicated pedestrian model for the GNSS receiver.Indeed, the GNSS positioning errors and drifts come now into play and may cause the triggering of VAMs even if the real values of position and heading change slightly.This proves how field trials are essential as they reveal unforeseen problems that are often not captured in simulations.Furthermore, to the best of our knowledge, no GNSS receiver currently available is specifically tailored for pedestrian scenarios.To wit, by comparing our results to smartphone-generated traces, we can claim that we achieved notably higher accuracy levels in our tests.
Fig. 5 shows a field test conducted by walking with our equipped stroller around a block in Turin.As depicted in Fig. 5a, a number of VAMs are sent due to the heading triggering condition even when we were proceeding straight.A corresponding yellow peak at a low transmission periodicity can also be seen in Fig. 5b, highlighting that the majority of VAMs sent in this test were caused by the heading threshold of 4 degrees, as suggested by the standards.The cause of this behaviour is twofold: firstly, GNSS errors and drifts cause the heading to oscillate; secondly, a VRU has a much more unpredictable motion than a vehicle, as also proved in [8].
To better analyze this issue, we repeated the same test by raising the heading threshold to 10 degrees, obtaining the results shown in Fig. 6.Notably, VAMs are now sent due to the heading triggering condition only while turning at corners, as expected.This is clear when looking at the yellow points in Fig. 6a.Indeed, the share of messages transmitted due to the heading condition has decreased significantly between the two tests from 61% down to 28%.The transmission periodicity histogram in Fig. 6b now reports a peak around 3 s mainly caused by position triggering, corresponding to a walking speed slightly below 5 km/h.This shows how a triggering condition of 10 degrees could represent a better choice to mitigate the spurious VAM transmissions due to GNSS drifts and unpredictable mobility, and it is in line with the conclusions of [8].Note that the green color signals a mixed triggering condition, which is mainly caused by heading and position conditions occurring together.
It is important to notice that, despite the change in one of the VAM triggering conditions, we can still claim to be standard-compliant.Indeed, unlike vehicular CAMs, the standards for VAMs do not define strict thresholds for the triggering conditions but rather lower bounds that might be fine-tuned to enhance the performance of the service.
In the same spirit as the previous field tests, we also performed a set of experiments on a longer path all around the Politecnico di Torino campus.Fig. 7 shows the results of the field test conducted using the heading threshold of 4 degrees.As depicted in Fig. 7a, a high number of heading triggering conditions occurred also when no turnings were performed.This is also highlighted by the yellow peak at a low periodicity in Fig. 7b.Note that the non-straight path in Fig. 7a was due to a reduced GNSS accuracy caused by the urban canyon in that area.As expected, when increasing the heading threshold from 4 to 10 degrees, the number of VAMs sent due to the corresponding condition decreases from 35% to 20%, as demonstrated by the results in Fig. 8. Specifically, Fig. 8a shows how VAMs are triggered due to heading variation only when turning, while Fig. 8c highlights a cyan peak due to position triggering at around 2.5 s.Finally, we also performed a simulation of a pedestrian strolling around the campus with a heading threshold of 10 degrees, following the same path as in field tests.The corresponding VAM dissemination trace is shown in Fig. 8b.By comparing the simulated and field test traces, we can see how overall comparable results are obtained, but for the greater number of VAMs triggered by heading variations on the field.This is due to the much more predictable pedestrian motion pattern in ms-van3t, which is of course less realistic that a real-world test.
These tests not only allowed us to perform an evaluation of the VBS in real-world conditions, but also to evaluate our implementation in the field, showing consistent results with respect both to the standards and to the simulations.
Finally, we analyzed a situation where VAMs are sent due to a proximity triggering condition.To this aim, we equipped a vehicle with similar hardware as the one leveraged for the stroller.The results are depicted in Fig. 9.The white car icon in Fig. 9a shows the parking position of the equipped vehicle, which remains static and transmits CAMs at a frequency of 1 Hz.As in the previous results, the colored points in the trace represent the positions at which VAMs are broadcasted by the equipped stroller.As two road users are now communicating together, the vehicle and the pedestrian both populate their respective Local Dynamic Maps (LDMs) using the information from the received messages.This makes them aware of the presence of the other user in their proximity.With this approach, the pedestrian is able to recognize when the vehicle is close enough, and thus it can react by increasing the VAM transmission frequency due to the proximity triggering condition.Indeed, Fig. 9a shows that the VRU sends VAMs due to the proximity condition (colored dark blue) when passing next to the vehicle.frequency is increased to the maximum (i.e., 10 Hz), since this could represent a potential safety-critical situation.

V. CONCLUSIONS
We have presented in this paper a novel open implementation of the ETSI VRU Basic Service (VBS), targeted at both field tests and simulation campaigns.We have used our VBS to perform both simulation and field tests to evaluate the effectiveness of the service proposed by ETSI.Results highlight the consistency of the implemented VBS and the effectiveness of the main VBS functionalities, showing also how a higher heading threshold of 10 degrees, with respect to the standard one, may be needed to mitigate the effect of GNSS drifts and unpredictable motion patterns.As a future work, we plan to extend our VBS implementation to include clustering and interception probability features and to compare different clustering strategies both in simulation and in the field.We are also working on integrating VAMs into a smartphone for centralized safety services by following the C-Roads standards that foresee the transmission of messages to a central broker via the AMQP 1.0 protocol.

Fig. 3 .
Fig. 3. Field test setup.(a) The equipped stroller, side view.(b) The equipped stroller, front view, with our "VRU" and the DSRC and GNSS antenna.(c) Our hardware boards in the bottom bag of the stroller.(d) A field test example.

Fig. 5 .
Fig. 5. VAM dissemination in a field test scenario.The test was conducted around a block with a heading threshold of 4 degrees.(a) VAM dissemination trace.(b) Percentages of VAMs sent with a different periodicity.

Fig. 6 .
Fig. 6.VAM dissemination in a field test scenario.The test was conducted around a block with a heading threshold of 10 degrees.(a) VAM dissemination trace.(b) Percentages of VAMs sent with a different periodicity.

Fig. 7 .
Fig. 7. VAM dissemination in a field test scenario.The test was conducted around the Politecnico di Torino campus with a heading threshold of 4 degrees.(a) VAM dissemination trace.(b) Percentages of VAMs sent with a different periodicity.

Fig. 8 .
Fig. 8. VAM dissemination around the Politecnico di Torino campus with a heading threshold of 10 degrees.(a) VAM dissemination trace, field test.(b) VAM dissemination trace along the same path, simulation (c) Percentages of VAMs sent with different frequencies.

Fig. 9 .
Fig. 9. VAM dissemination in a field test scenario.(a) VAMs and CAMs traces sent.(b) Percentages of VAMs sent with different frequencies.