## 6 Interactions among MEC Domains  
This section describes at high level the interactions between domains of each of the foreseen architectural options when deploying an application in a multi-domain MEC system. For that, the following four phases described in [32] are assumed. * Phase 1, for the packaging and on-boarding of the MEC application. MEC applications will be packaged as a virtual machine or container for onboarding. Different MEC entities are involved in such process. Once the OSS grants a request (e.g., for onboarding, instantiating or terminating the application), it is sent to the MEO, which provides the MEPM with the location of the application image in case has not been yet on-boarded, and selects the VIMs for the instantiation of the application. The MEPM provides the configuration of the infrastructure to those VIMs, including the application images. * Phase 2, for its instantiation. Application initialization can be triggered either from a device or from the OSS. This implies that the external interfaces Mx1 and Mx2 are the participants of this instantiation triggering, being this transparent to any federation case. After that, the initialization is progressed to the MEC platform. It includes information needed to run the application (e.g., application rules). The MEPM will requests to the VIMs the allocation of resources and the subsequent instantiation of the application. Once instantiated, MEC application can interact with the MEP for the lifecycle of the application. The MEPM will receive fault and performance information from the VIMs to support the operation. * Phase 3, related to the communication between the client-side and the MEC-side of the applications. A client application should not be necessary aware of the edge deployment of the MEC application. The only action to consider is the proper update of the DNS entries by the MEP to support the discovery of the MEC application to connect to. * Phase 4, for the usage of the MEC platform and services. A MEC application will provide different kind of information or services, produced either by the MEP or by a set of other MEC applications. MEC applications will offer purpose-specific APIs typically to be consumed by client applications in the form of RESTful APIs. From this perspective, this phase is totally independent of the multi-domain fact. The interactions among domains are summarized in Table 4.  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Scenario**} & \multirow{2}{*}{**Existing Interfaces Going Multi-Domain**} & \multicolumn{2}{c}{**New Interfaces for Supporting Multi-Domain**} & \multirow{2}{*}{**Comments**} & \multirow{2}{*}{**Implications**} \\ \hline  & & & Resources allocated by Domain B to & Business—IaS model for Domain B; SLAs tight to resource \\  & & & Domain A have to be isolated (e.g., by & capabilities (compute, networking)). & \\ Integration at & & & means of a slice) to avoid conflicts in the & Technical–Domain B to provide monitoring information of \\ infrastructure level & & & & control of them. & resources abstraction data models for resources: \\  & & & VM could be instantiated on-demand by & multi-domain awareness extended to management and \\  & & & Domain A. & platform reference points. \\ \hline Integration at platform & & & & Business–PaS model for Domain B; SLAs related to \\ level (infrastructure & & & & \\ owned by Domain A) & & & MEP from Domain B can be instantiated & platform KPIs (e.g., provisioning delay). & \\  & & & as VM on Domain A. & Technical–Domain B to provide monitoring information of \\  & & & MEP from Domain B can interact with & the platform abstraction data models for MLP platform; \\  & & & other MEHs either from Domain A or B & multi-domain awareness extended to management and \\  & & & & platform reference points.