Towards realistic simulation of MEC-based Collective Perception: an initial edge service design for the Artery/Simu5G framework

Abstract

Day 2 V2X applications are the next step in vehicular communications, as they aim to extend the scope of shared information. In addition to status data, traffic participants are also aware of each other's sensory capabilities and the data deriving from those sensors. Collective Perception (CP), one of the flagship Day 2 services, enables vehicles and infrastructural elements, like roadside units or smart intersection controllers, to provide information about detected objects, significantly increasing the level of cooperative awareness V2X can grant for the communicating entities. However, with the escalation in the amount of data to be sent over the vehicular or mobile networks and the need for more processing power to enable real-time safety applications based on CP, some form of infrastructural aid is needed. The traditional central cloud-based approach might fall short of meeting the latency requirements. To keep latency within an acceptable range and solve the computational tasks locally, leveraging the capabilities of 5G Multi-access Edge Computing (MEC) could be a potential solution, thus ensuring a minimum impact on the core network. The architectural design and the modular approach of service implementation in the MEC specification by ETSI enable quick service deployment. This paper focuses on advanced Collective Perception-based V2X applications and the potential positive impact on their performance when operating with the support of edge computing. We also present the descriptionincluding the design considerationsof an initial, Artery/Simu5G-based edge service model working as a network-side intelligence extending the functionality of applications hosted on the vehicles.

Implementation of MEC-Assisted Collective Perception in an Integrated Artery/Simu5G Simulation Framework

“…In summary, our model, for now, consists of vehicles propagating CPMs over IP/UDP to an application instance hosted on the local MEC server responsible for the dissection and processing of the messages. This is a minimal working network setup, and the model is planned to be further extended later with the implementation of higher-level applications (e.g., for an object fusion service or different use cases described in Section 2.5) within the MEC host's service registry that is accessible for the app instances via REST API [67], where the now simplified processes could be replaced with actual extended functionality.…”