s of the flavor, a MEC host consists of virtualization infrastructure, a MEC platform, and a number of MEC applications. All entities in the MEC architecture are connected via standardized reference points. ETSI MEC defines a number of APIs, which can be categorized as: application enable- ment, service-related, and management- and orchestration-related Furthermore, a set of RESTful APIs provide access to radio network Information, location information, UE identity information, vehicular-to-everything (V2X) related information, and others. Even though the standard does not explicitly define how a MEC can be deployed in a 3GPP network, one can assume that the MEC data plane shall be connected to a UPF (and therefore, from a purely formal viewpoint, in such architecture MEC is not part of NG-RAN). Application function (AF) in 3GPP architecture can be mapped to the MEC platform in ETSI MEC architecture. Inter-MEC system information exchange can be beneficial, to enable for example V2X applications, as V2X services in a single area are likely to be provided by multiple oper- ators. A hierarchical framework is being considered for service discovery and consump- tion of inter-system communications at the following levels: between MEC orchestrators (used e.g. for MEC system discover), between MEC platform managers (used e.g. for MEC platform discovery), and between MEC platforms (used e.g. to exchange information between services running on different MEC systems). To ensure proper selection of the services to be consumed by a MEC application and to help the orchestrator to make decisions on the MEC application requesting said ser- vices relocation, a new message protocol is being considered. The proposed performance- centric design through edge host zoning enables flexible MEC service consumption in multi-vendor environments, including the case of inter-MEC system deployments. To facilitate MEC deployments in automotive scenarios, which are characterized by high mobility and hard-to-predict changes in network load and r