vated simultaneously by a single vehicle. For example, a driver starts her autonomous vehicle relying on a specifically designed autonomous driving slice, while passengers watch a movie offered as a vehicular infotainment slice. Besides the dedicated SST value already foreseen by 3GPP, a slice subtype may be required. The heterogeneity of the originating devices of a V2X slice asks for further slice customization. A V2X UE can be a smartphone in the case of a VRU, a transceiver unit embedded into the vehicle. The communication on the PC5 interface for example shall be optimized based on the type of UE: energy efficiency is critical for a smartphone UE engaged in V2P interactions for road safety purposes. Customization of slice on a per-device level should be enabled. 13.7.2 Multi-tenancy Management New players such as road authorities, municipalities, and car OEMs will enter the V2X scene in addition to traditional operators. For instance, the road municipality may offer a V2V-based safety data exchange; a vehicle manufacturer can offer a vehicle diagnostics ser- vice; a content provider a video streaming, which can be mapped onto different slices and facilitated over the infrastructure owned by different network operators. A proper set of flexible slice templates should be defined, which allow the vertical to properly describe the services to be supported and the desired key performance indicators (KPIs). Then, the assur- ance of requirements is tracked by the OSS/BSS with respect to the template specifications agreed in the form of SLAs. 13.7.3 Massive Communications The V2X slicing design shall enable multiple AMF instances to be flexibly deployed as VNFs and to be interconnected to meet the needs of the V2X slices with high density of mov- ing vehicles. This prevents the AMF from being overloaded, with consequent increase in latency, while ensuring isolation from other (non-V2X) slices that leverage the same func- tionalities, but less aggressively (e.g. pedestrian/indoor UEs in case of an mMTC slice). The in