# Slicing on the Road: Enabling the Automotive Vertical through 5G Network Softwarization
## 4 V2X Slice Design  
On top of the described framework, different slices can be instantiated and orchestrated. Despite the heterogeneity of V2X services and applications (remote driving, vehicle platooning, infotainment, vehicle diagnostics, etc.), we identify a common set of minimum functionalities that should be provided, and possibly agreed by all operators, to a V2X slice to simplify the slice roaming management:  
* AMF instances should be available regardless of the specific offered V2X service, to support vehicle mobility. Multiple dedicated AMF instances need to be flexibly deployed to avoid the AMF to be overloaded with consequent increase in latency during slice selection/attachment procedures (being such procedures managed at the AMF), while ensuring isolation with other (non-V2X) slices leveraging the same functionalities but less aggressively (e.g., pedestrian/indoor UEs).
* AUSF, PCF and UDM should be deployed as NFs, which are common to all V2X slices.  
Besides such basic functionalities characterizing a _default_ V2X slice, different functions can be dynamically chained and different behaviors can be flexibly configured to meet the specific performance requirements of a given V2X service category. In this work, we focus on the instantiation of a V2X slice for cooperative driving services. Such a choice is due to the relevance of such services in the roadmap towards connected and automated vehicles, and its challenging connectivity and computing demands. In particular, the cooperative driving slice should guarantee:  
* Ultra-reliable and ultra-low latency V2V communications. V2V communications are leveraged to support the reciprocal exchange of vehicles' kinematics parameters, the perceived environment and intended maneuvers. Dedicated bandwidth can be allocated to V2V links (e.g., 10 MHz as assumed in [19]) to ensure the isolation from other non-V2X slices in the RAN. A common unlicensed spectrum, i.e., the 5.9 GHz Intelligent Transportation Systems (ITS) spectrum, should be used for V2V communications to ensure cross-operator availability.
* V2N communications with the V2X AS. The following data need to be exchanged via V2N links with high reliability and low-latency: (i) raw sensory data sent by vehicles to the infrastructure for the purpose of 3D-map processing of the surrounding area and buildings; and (ii) the computed result sent in the opposite direction to extend the spatial vehicle perception [39]. Therefore, processing shall be carried at an edge cloud level. Multiple RATs and high-throughput connectivity options (e.g., mmWave links) could be used to boost the RAN throughput.  
The resulting chaining of NFs for the cooperative driving slice is illustrated in Figure 2.  
Slice identification and attachment. The proposed framework is compliant with the guidelines under discussion within 3 GPP for what concerns the main operations related to the slice lifecycle. Granted the general slice configuration, for the sake of completeness, the slice attachment procedure [40] is shortly recalled here and customized to the specific case of a connected vehicle. A VUE, wishing to attach to a slice, provides the NSSAI to the network to enable the selection of a slice instance for it [23]. For the V2X slice of interest, the NSSAI parameters can be set as follows: the SST is set to _Cooperative driving_, the SD is set to the _Road Authority name_. On receiving a request from the On-Board Unit (OBU), the Network Slice Selection Function (NSSF), co-located with the AMF, performs the slice selection procedure by leveraging additional information, e.g., about the _Device type_, which in the most general case can be set as OBU, smartphone of pedestrians. Once the NSSF haschecked the subscriber information and the VUE is authenticated, through interactions with the AUSF and the UDM, the slice attachment procedures are performed and the services can be accessed.