In [14] an architectural framework is proposed to support V2X network slicing. There, the focus is on the procedures entailed to support the cooperative driving use case under roaming conditions. An evaluation study has been conducted as a proof-of-concept by lever- aging the Mininet network emulator coupled with an overhauled Ryu SDN controller in charge of managing interoperator handovers. In [19] an architecture is developed to sup- port traffic differentiation (through queuing and DSCP-packet marking) and flow isolation (through tunneling) for different network slices. The slices span from an MEC node to a remote end-server, hence emulating the traversal of a 5G CN and the main functions for slice identification, selection, and orchestration. The architecture has been realistically validated when considering different traffic generated by a vehicle and transmitted over dif- ferent RATs, i.e. 4G and LORAWAN. The work in [18] also advocates the need for end-to-end network slicing and proposes a framework leveraging SDN, fog, edge, and cloud comput- ing to manage resources offered over heterogeneous RATs on top of which autonomous driving services are delivered. Resources for the basic functions required by autonomous driving (i.e. localization, perception, planning, and system management) are virtualized and scheduled using distinct service slices. 13.7 Lessons Learnt and Guidelines 13.7 Lessons Learnt and Guidelines Owing to the high dynamicity of the reference V2X environment and the variety of V2X services and applications, the design of V2X slices unveils much more complexity than other verticals and services. In the following, we discuss how V2X peculiarities and demands can be translated into network slicing design choices and guidelines, by also treasuring the main findings of the scanned related works and standard specifications. 13.7.1 Slice Mapping and Identification V2X services do not easily allow straightforward mapping into ITU reference slices. Moreover, multiple slices may be required to be acti