# 5G V2X System-Level Architecture of 5 GCAR Project
## 3 Overall 5 GCAR Architecture Design
### Network Orchestration and Management
For instance, examples of information that the NEF can expose to be used for network orchestration might include channel quality info, UE Location, Cell-ID, cell load, average network latency at access, core level, and target Cell-ID (before handover execution). From this point of view, the knowledge in advance of the target Cell-ID will be useful for instance at AF to correlate car trajectory with \"network trajectory\", to be able to anticipate the fading situation in particular area (tunnel, building shadowing). The AF could be also able to organise in advance switching from one edge server to another if the target cell is attached to a different edge server. The information exposed by the NEF can be collected from several sources. For instance, the next generation NodeB (gNB) could send information (radio layer info) towards the UDR, which could be then exposed by the NEF. The gateway mobile location centre (GMLC) defined in 3 GPP Release 15 will also push location information towards the UDR. Some network information to be exposed could be generated by NWDAF, which could provide slice-granularity information in its current 3 GPP specification. Furthermore, APIs could be set between NEF and business support system (BSS) and/or operating support system (OSS), which will be in charge of pushing information towards the service orchestration framework in order to manage network components in an optimal way. In a similar way, APIs between AF and 3 rd party applications can be used in order to push information towards 3 rd party application orchestration framework. One example of a use case where we can apply the above-mentioned alignment of orchestration capabilities with 3 GPP exposure framework is the lane merge scenario. In this case, a specific traffic orchestrator running in a regional data centre can be instantiated. If the virtual infrastructure manager (VIM) [14] detects that the resource allocation for the orchestrator does not allow the ability to meet the service latency requirement (time for message processing is too high for instance) due to server high occupancy, it can then decide to redeploy the application component of the traffic orchestrator  
Figure 5: Impact over 3 GPP interfaces and functional entities of aligning orchestration with data analytics and exposure framework. to an edge cloud location also considering network performance information. Such a scenario can be obtained, for instance, by considering information exposed by the mobile network given by NEF, for instance, in terms of achievable QoS such as estimated or predicted latency, bitrate, etc. In this scenario, the service orchestration can take into consideration information about estimated QoS exposed by the NEF, and jointly use such information with other information from the VIM to estimate in advance whether, for instance, end-to-end latency for a given service topology (service component placement) can be met. In this scenario, the service orchestrator will then be able to select the best edge server to perform the vehicle traffic orchestration for a given set of cross-roads in accordance with the service level requirements of lane merge, also considering network performance measurements and/or information in addition to cloud-based information. The network orchestration can be further enhanced by considering latency and reliability driven service orchestration. A similar approach has been used in [15], where to improve both the reliability and latency performance, a new network slicing solution that extends from resource slicing to service and function slicing is presented for 5G autonomous vehicular networks.