# Smart Cities of the Future as Cyber Physical Systems: Challenges and Enabling Technologies
## 4 Mobile Edge Computing for the Internet of Things  
In this section, we present the main aspects that are examined considering the interplay between cloud and edge computing resources toward the development and management of IoT applications in a smart city. In most IoT applications, diverse computer, network,and storage requirements have to be satisfied to provide the required levels of Quality of Service (QoS) and Quality of Experience (QoE) for the end users. Such requirements have to be satisfied while taking into account a set of constraints that may be related to the existence of limited resources at the edge part of the infrastructure, the dynamic network topologies based on the activation and deactivation of IoT nodes and the fluctuations in the posed workload by the end users. The trade-off between the optimal usage of the available resources and the associated impact on the IoT applications performance has to be dynamically assessed and must lead to resource management actions at the edge and the core part of the infrastructure. To achieve this, part of the IoT functions that compose an IoT application graph may be executed at the edge part of the infrastructure, while another part may be executed at the cloud part. Decision making regarding the amount of resources to be allocated per part of the infrastructure (edge, cloud computing part or access, transport, and core network part) is usually made by centralized orchestration mechanisms that have a full and accurate view of the current status of both the available resources and the application performance. Various orchestration approaches have been developed in recent years under work realized within different working groups in the areas of Multi access Edge Computing (MEC), Network Function Virtualization (NFV) and--under a wider umbrella--5G technologies. One of the three main categories of 5G usage scenarios regards the Massive Machine Type Communications (mMTC) where very dense IoT deployments can take place, particularly in smart city environments. In the MEC approach, focus is given to the application part that is placed at the edge of the infrastructure. Use cases include applications offering video analytics, location-based services, augmented reality, optimized local content distribution, and data caching at the edge. MEC applications may be provided by application providers or telecom operators. In the latter case, a MEC application is part of a service offered by the telecom operator. In the NFV approach, focus is given to satisfying the network requirements posed by the application through the deployment of network services composed of a set of virtual network functions. Such network services are provided on behalf of telecom operators. Use cases include virtual firewalls, IP multimedia subsystem controllers, virtual Customer Premises Equipment (CPE), virtual authentication, authorization and accounting functions, and virtual content delivery networks (CDN). However, moving toward the next generation smart IoT applications, there is a need for convergence of MEC and NFV technologies and the support of the end-to-end management of IoT applications considering both application-oriented and network-oriented performance metrics. Radical new applications can be developed through the joint adoption of these technologies. Several 5G research activities are taking place toward this direction taking advantage of the evolution of 5G orchestration mechanisms and dynamic network slice management approaches [45]. 5G was designed to leverage network software technologies, such as NFV and MEC, to expose customized network instances and resources at the edge of the infrastructure to vertical stakeholders [45]. One approach proposed within the ETSI MEC ISG considers that edge computing applications can be considered as VNFs and embedded in 5G orchestration ecosystems [46]. In this case, the edge computing VNF is composed of multiple application components (each one hosted within a VM or a container).