# Deploying CPU-Intensive Applications on MEC in NFV Systems: The Immersive Video Use Case
## Overall Architecture of the Proposed ME System
### ME App On-Boarding and Instantior Example in Crowded Event Scenarios
#### 3.2.1 ME App On-Boarding  
To on-board their ME apps to an ME system, developers must create an MEC Application Package (MAP), and upload it through the CFS portal.  
The package structure used in this study complies with the Cloud Service Archive (CSAR) format [34], a well-known format commonly used in cloud applications, and also adopted in NFV.  
As shown in Figure 5, the MAP must contain the specific ME app VNF package required by NFV, and an additional ME App Descriptor (AppD) file, as envisioned by MEC [10]. Since ME apps appear like VNFs included in an NS towards the NFVO, developers must on-board their MAP together with a corresponding NSD, to provide the NFV-related information [10].  
The AppD file contains information about the ME app, which is relevant for the ME system, but cannot be included in a standard VNFD. Typically, the AppD includes DNS rules, traffic rules, or latency parameters. Interested readers can find a detailed comparison of AppD and VNFD in Reference ([10], page 25).  
In this study, we will restrict the discussion to DNS and traffic routing rules, and we will not consider latency or other parameters. Nonetheless, the extension of the analysis to a wider set of parameters is straightforward. Moreover, in the example in question, a DNS rule will be expressed as a single record, consisting of a Fully Qualified Domain Name (FQDN), indicating a host running the ME app, and its corresponding IP address [8]. Thus, the AppD must only contain the information necessary for defining the appropriate DNS and traffic routing rules, which will properly steer the consumer data traffic.  
In most cases, the FQDN associated to an ME app is known a priori, and can be straightforwardly included into the ME AppD by the developer. Conversely, the corresponding IP address could be unknown at the on-boarding time, as it could be dynamically assigned by the NFV MANO to the virtual machine running the ME app VNF only after its instantiation.  
To overcome this problem, in this study we have extended the AppD structure to also contain a reference to the specific Connection Point of the ME app VNF, to which the IP address of interest will be assigned. Such a Connection Point is defined in the ME app VNFD and is therefore available a priori to the developer.  
In this way, at the end of the instantiation process, the MEAO can query the NFVO to retrieve the Connection Point IP address, and finally create the required DNS rule for any instance of the ME app.  
In the i-EVS on-boarding example considered, the FQDN associated with the ME app is \"db.ievs.italtel.com\" (as will be described below), and the Connection Point of interest is the one assigned to one VNFC of the i-EVS VNF (i.e., the db VNFC). We will describe in detail the mechanism used by the MEAO to retrieve the IP address of the referenced Connection Point in the next paragraph.  
The on-boarding process continues with the OSS on-boarding the validated MAP to the MEAO through Mm1. The MEAO must be able to analyze the MAP, and separate the NFV-related components used by the NFVO from the ME AppD file that will be stored in the MEAO itself.  
The MEAO on-boards the i-EVS VNF package and the corresponding NSD to the NFVO according to the operations associated with the standard NFV reference point Os-Ma-nfvo [40; 41]. In fact, the \"NSD Management\" and \"VNF Package Management\" interfaces of the Os-Ma-nfvo reference point can specifically perform such tasks.  
The MEAO maintains the information that is not pertinent to NFV in the AppD file. Moreover, it creates and maintains the relationship between AppD, the VNF Package and NSD for each on-board ME app.  
Figure 5: MEC Application Package (MAP) structure.