# 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.2 ME App Instantiation  
After the on-boarding process has been completed, a service provider can instantiate an ME app of interest on a selected NFVI, by using the CFS portal and through the OSS. Upon receiving an ME app instantiation request, the MEAO invokes standard operations towards the NFVO through Mv1 (see Figure 4), which is assumed to be equivalent to the standard NFV Os-Ma-nfvo reference point [40; 41]. The MEAO also performs additional activities, to complete the ME app instantiation process for all those aspects falling outside the scope of NFV and that an ETSI-standard NFVO usually cannot deal with [10]. To focus on the interactions between MEAO and NFVO, we will make the simplifying assumption here (illustrated in Figure 6) that the SGWLBO VNF, with five related VLs--namely, S1-U-v1l2, S5-v14, LBO-v15, S11-v13, and OAM--is included in an NS, which is already in service when the ME app instantiation process starts. We will refer to this NS as SGWLBO NS. The dependency between the ME platform VNF and the ME app VNFs is still an open issue ([10], key issue #2), which the assumption adopted can simply overcome. This solution does not preclude the instantiation of a serving ME platform and multiple ME apps in the same NS. Nonetheless, the discussion of such a case and all its implications is fairly complex, and would go far beyond the scope of this paper; hence, it will not be analyzed here. Figure 6 shows the instantiated SGWLBO NS, as visualized by the OpenStack dashboard. The S1-U-v12 VL (represented as a vertical green bar, second from the left) delivers S1-User-Plane (S1-U) data, while S5-v14 carries S5 data; S11-v13 transports network control messages, while the OAM VL connects the SGWLBO VNF to its Element Management System. In LTE networks, the S1-U interface is between the eNodeB and the S-GW, while S5 is between the SGW and the Packet-data-network Gateway (PGW) functional blocks [42; 43]. Both S1-U and S5 make use of the General Packet Radio Service (GPRS) Tunneling Protocol (GTP) for the user plane, i.e., GTP-U [43]. GTP-U permits many tunnels between sets of endpoints. On S1-U and S5, the IP packets sent and received by end users travel within such specific tunnels, set up under the supervision of the network  
Figure 6: OpenStack Dashboard visualization of the network services, including SGWLBO and i-EVS. control plane; hence, they cannot be directly processed by ME apps, which typically do not have the necessary control information to deal with GTP-U [27]. Conversely, the SGWLBO VNF, which includes the MEC data plane and cooperates with the SGW functional block, can terminate GTP-U tunnels, and thus make available \"de-tunnelized\" plain IP user data on the LBO-vl5 link (leftmost blue bar in Figure 6). In this study, as suggested by Reference [10], ME app VNFs are included in NSs, consisting of one (or more) VNF, and a set of corresponding VLs, which, during the instantiation process, can be suitably connected to the ones offered by the SGWLBO NS. The final result of this process is summarized in Figure 6, which, besides the SGWLBO NS, also shows the instantiated NS, including the i-EVS ME VNF. The i-EVS VNF consists of three VNFCs, namely dB, VTU, and eSTORE. Besides two management VLs (the orange and pink bars in Figure 6), the corresponding NS also includes the LBOievs VL. From the previous discussion, one can easily verify that consumer data traveling through the S1 and S5 interfaces in the mobile network can be made available to the i-EVS ME VNF as plain IP data through the interconnection of LBO-vl5 with the LBOievs VL. In the proposed architecture, the MEAO requires the NFVO to set the NS including the ME app VNF through standard NFV operations [40; 41]. Specifically, the MEAO relies on the interface \"NS Life Cycle Management\" of the Os-Ma-nfvo reference point, which makes it possible to invoke NS lifecycle management operations towards the NFVO [40; 41].