utomotive domain) also recognize the importance of edge computing as a natural solution for interoperability of the data exchange in multi-MNO domains. In fact, considering the case of the automotive market, car makers need to offer V2X services where the connectivity is not limited to a single operator, but also capable of including cars connected to different networks, or moving between areas covered by different MNOs (e.g. country boundaries). Finally, the possibility to host an edge computing environment comes with the advantage of the ability to collect and process local data and context information, and offer them as added-value services that could be exposed as edge APIs to application developers, service providers, and end users. 6.4.3 MEC Standard The MEC reference system architecture is defined by ETSI in a couple of "flavors": Standalone architecture that does not require NFV-based infrastructure. "MEC-in-NFV" architecture, where all MEC entities are placed together with their respective NFV elements, according to the ETSI NFV framework. Below we explain both MEC architecture variants as defined in the ETSI MEC specifications (including standards related to the MEC platform and to MEC APIs). 6.4.3.1 ETSI MEC System Architecture The "standalone" variant of the ETSI MEC reference architecture is depicted in Figure 6.4.1. This architecture is divided into two layers: the MEC host level and the MEC system level. The first one is composed of several MEC hosts connected via the Mp3 reference point. In the upper (MEC system) level an orchestrator and OSS are connected to the external world (and device applications) through a proxy. Every MEC system consists of the following three functional elements: 6 Enabling Technologies portal Operations Support System Device proxy Multi-access edge orchestrator Other platform service Service registry platform element rules & lifecycle Service reqts Traffic rules handling control MEC platform manager MEC platform Data plane Virtualization infrastructure Virtualization inf