re 6.4.12 provide an example of such proximity-based classification maintained at the MEO; it should be noted that the cost values and the number of MEC hosts in a zone are selected in arbitrary fashion in this example to illustrate the concept. As shown in Figure 6.4.12, only MEC host 1 belongs to proximity zone 1, whereas prox- limity zones 2 and 3 incorporate MEC hosts, the hosted MEC services which can be reached at a higher cost (from the MEC app-to-service latency performance standpoint). It should be noted that the construction of the MEC proximity zones should be updated each time the MEC system deployment (topology) is altered; for example, when more MEC hosts are deployed in a given area, and/or, when the physical interfaces inter-connecting the MEC servers are upgraded. Proximity zone 2 Proximity zone 1 MEC Host 4 MEC Host 1 MEC App MEC Host 2 MEC Host 3 Proximity zone 3 Figure 6.4.12 Visualization of MEC host proximity zones (as seen by the MEC application), according to the utility-based classification of Table 6.4.1. 6 Enabling Technologies Based on such utility-based classification, the MEO can then make a decision on whether to recommend the relocation of a MEC application instance, or not. The decision would be affected by E2E QoS/cost requirements and the need to consume specific MEC services. To this end a signaling protocol (FSR19) can be defined among the various MEC system entities with the aim of achieving QoS-aware/cost-efficient service consumption by a given MEC application instantiated at a host of a given MEC system. The procedure should allow the MEO to evaluate whether a MEC application instance relocation would satisfy the E2E performance/cost requirements as the MEC service consumption delay is only a fraction of the E2E delay. An exemplary version of the potential protocol to support the functionality described above is shown in Figure 6.4.13. 1. The MEC application triggers the procedure by requesting the MEC host deployment parameters from the MEO. The request should contain the