 This set of available MEC hosts can then be communicated to the other system's MEPM, e.g. by means of a dedicated reference point. This enables the establishment of a direct communication interface between the two MEC platforms. The frequency of the inter-MEPM discovery message exchange may vary, depending on the frequency with which the availability of a MEC host changes (e.g. based on MEC load fluctuations caused by changes in vehicle spatial densification over time). Communication among MEC platforms: After MEC system and MEC platform discovery and establishment of the communication interfaces described above, every MEC platform may indicate for each service it supports whether it can be shared with other systems, e.g. by using a "public"/"private" tag. In this manner, services that should only be consumed locally (at the same host, or only within an intra-system "zone," e.g. due to privacy issues) will be excluded from inter-system inter-platform sharing. Therefore, only a subset of the supported services will be exposed to other MEC systems. The set of sharable services can be then directly communicated to the other accessible systems' MEC platforms, e.g. by means of a dedicated reference point. 6.4.6 Flexible MEC Service Consumption In this section, we discuss the impact of MEC topology on the MEC service consumption and how it affects E2E performance. As mentioned above, a MEC application can consume MEC services, which can be running on the same or a different MEC host. A MEC application decision about selecting the best MEC host for a certain service can be affected by different KPIs, for example, achievable communication round-trip time (RTT). Additionally, once the MEC application has selected the MEC host, the MEO may relocate the MEC application instance closer to the needed service, which may affect the KPIs used by the application in the initial selection decision. Efficient MEC application relocation may only be possible if the MEO has up-to-date performance measurements (e.g. delay), which is in