 list of service(s) to be consumed. 2. The MEO requests the parameters (e.g. expected delay) from the different deployed MEC hosts (hosting various services) by the MEPM. 3. The MEO gathers all needed MEC host parameters and defines performance zones, with reference to the location of the instantiated MEC application. 4. The MEO provides a recommendation for service consumption to the MEC application (e.g. suggesting direct service consumption or MEC app instant relocation); it is then up to the MEC application to accept/reconsider the recommendation, while considering the E2E nature of the performance metric. The example shown above is not limited to a single MEC system and is applicable also in the case of consuming MEC services residing within different MEC systems (e.g. associated with different network operators). Network Edge (MEC) application MEC hosts parameters request Host #1 parameters request Host #1 report Host #2 parameters request Host #2 report Host #3 parameters request Host #3 report Host #4 parameters request Host #4 report decision Mm3 interface MEC application instant relocation Mx2/Mm9 interface Figure 6.4.13 Potential signaling protocol among functional entities of a MEC system to support proximity-based MEC service consumption. 6.4 Multi-Access Edge Computing 6.4.7 High Mobility Automotive Scenarios As we explained in the beginning of this section, the automotive sector is one of the key areas for edge computing applications. One particular difficulty of this application is the need for interoperability between multiple MNOs deploying ITS networks in the same area (MEC030). Below we describe a potential implementation of a MEC-based framework, where predicted QoS and related information can improve V2X services offered to drivers. The functionality described in the present subsection is not part of the MEC specifications yet. 6.4.7.1 MEC-Supported Cooperative Information While the issue of multi-MNO ITS deployment is bigger than just QoS, in this subsection we discuss the problem of effici