TY - JOUR
AU1 - Jararweh,, Yaser
AU2 - Alsmirat,, Mohammad
AU3 - Al-Ayyoub,, Mahmoud
AU4 - Benkhelifa,, Elhadj
AU5 - Darabseh,, Ala’
AU6 - Gupta,, Brij
AU7 - Doulat,, Ahmad
AB - Abstract Mobile Edge Computing (MEC) enables ubiquitous and efficient cloud services to mobile users which facilitates mobile cloud computing (MCC) more easily by providing storage and processing capacity within the access range of the mobile devices. To achieve the goals of MEC, Mobile Edge (ME) servers are co-placed with the mobile network base station (at the edge of the mobile network). This eliminates the need to move computation and storage intensive tasks from a mobile device to a centralized cloud server. This in turn reduces the network communication load and delay and it also enhances the quality of service provided for the mobile end users. Applications, such as smart grid applications, content delivery networks, crowed sourcing, traffic management and E-health, will greatly benefit from such deployment. Unfortunately, a large-scale deployment of ME servers that is needed to make hundreds of applications available to millions of users, comes with great management complexity. The emerging technique of Software-Defined Systems (SDSys) abstracts the management complexities of many systems at different layers by utilizing software components. In this paper, we build a software-defined based framework that enable efficient and ubiquitous MCC services by integrating different SDSys components with the MEC system. The integrated framework is implemented and it is evaluated for its feasibility, flexibility and potential superiority. 1. INTRODUCTION Despite the fact that current technologies in Mobile Cloud Computing (MCC) alleviate a large number of problems associated with workload offloading, resource allocation, utilization and management, MCC systems are still facing many challenges in their flexibility, coverage, dependability and security. To face these challenges, a paradigm shift in how MCC systems are constructed and managed is required. One of the main MCC changes is to enable ubiquitous MCC services for mobile end users. This includes providing the underlying networking and communication topologies, control of workload offloading, coverage of services, provenance and meta-data collection and many more. Lately, Mobile Edge Computing (MEC) technology came to solve some of the MCC problems by providing services that are in the access range of the mobile users [1–4]. The availability of MEC technologies provides mobile users with a resources-rich system and a high bandwidth network connection. MEC evolution from a decentralized cloud technology called cloudlet [5] was intuitive. Usually, cloudlets are considered to be small cloud in a box. It is used to provide cloud services to mobile users in a decentralized deployment where cloud servers are being brought closed to the end mobile users that usually use Wi-Fi connection. For cloudlets, as more and more mobile applications come with more and more demand for high computing and storage capacities with unrestricted user mobility, this made cloudlet an inefficient solution. This is because of the limited resource of the cloudlets and the short coverage range of the cloudlet Wi-Fi connection [2]. In MEC-based systems, the seamless mobile task offloading and execution is crucial to the application quality of services provided to the users [6]. Many new applications may utilize MEC systems because of this seamless task offloading. Examples of these applications are compute-intensive video encoding [7] and local streaming service [8]. With all these decentralizations of cloud services, many challenges arise in the construction and the management of these systems regarding their complexities. It is best to have a solution that eliminates or at least hides these system complexities while maintaining the system control, flexibility, dependability and security. Software-Defined Systems (SDSys) is a straightforward solution to achieve this goal. SDSys helps abstracting the actual hardware at different system layers with software components. Such abstraction provides system administrators with the ability to construct and handle all control and management decisions by a central decision maker, through flexible software layers. SDSys emerged to face the previously mentioned control and management challenges that exist in any platform. It is well known that the cost of management and administration of today's computing systems is very high [9]. As systems are becoming larger and more complex, the system control and management is also become more complex. This demands the adoption of a solution such as an SDSys paradigm. For example on the complexity of the management of cloud systems, one of the features needed from a cloud computing system is to provide ‘on-demand’ services such as mobile gaming or content sharing. However, the control over such system is highly challenging to achieve because it is decentralized in nature. Every component manages itself and has no information about other components. Making decisions for enhancing performance of the system requires knowing information about other components of the system. These information must be collected and analyzed by a single central control unit . Consequently, this information collection causes some delay in the system response, which contradicts with the need for real-time response. SDSys [10, 11] can be used to solve the problem of combining information about multiple objectives and achieving the required fast respond by the on-demand applications at the same time. Despite the fact that it is very well known in the research literature that using SDSys provide solutions for supporting cloud computing applications, the work exist currently is very fragmented and is still a growing research and development topic. The aim of this study is to build a fully integrated SDSys cloud computing support framework that takes into consideration all aspects in which SDSys can be used. This fully integrated target SDSys framework is referred to as Software-Defined Cloud (SDCloud)[12]. This concept was first introduced in [11]. The authors proposed to the integration and management of the main components, of any computing system into one platform that represents the SDCloud. The main components of a typical computing system can be the computing resources, storage resources and networks. The main attempt in the literature to address a practical implementation of SDCloud is reported in [10, 12] who presented an architecture for a data center SDCloud. They considered different cloud applications and services, focusing on mobile cloud applications. However, the proposed architecture focuses mainly on Software-Defined Networking (SDN), Software-Defined Middleboxes Networking and Network Virtualization. In this paper, we complete our framework initially proposed in [13]. We propose a framework that integrates SDSys and MEC system capabilities to build an ubiquitous MEC. This can be achieved by integrating several aspects of SDSys, working cohesively together within a MEC-based MCC system. The aspects of SDSys that we are utilizing here are SDN, Software-Defined Compute (SDCompute), Software-Defined Storage (SDStorage) and Software-Defined Security (SDSec). According to our knowledge, the proposed framework is the most complex implementation of SDCloud. It will be used in a small system scale represented by the ME servers [14–17]. The proposed SDSys enabled mobile edge framework is composed of two layers: local layer running on the ME servers and a global layer. These two layers serve different applications with different computing and storage requirements. Delay sensitive applications benefit from the local ME servers layer for local on-line data processing and decision-making. Examples of these applications include traffic monitoring, content sharing and mobile gaming. The global layer is used to handle applications that require large amount of data collected by number of local ME servers. These applications may include smart grid and pollution monitoring. The proposed system is implemented and evaluated by introducing major extensions to the Mininet simulation tool which is an open source tool introduced for SDN in [18]. The rest of this paper is organized as follows. Section 2 provides state-of-the-art work done on the utilized software-defined subsystems. Background information about MEC systems is presented in section 3. Section 4 presents and discusses the proposed software-defined MEC architecture design that integrates the aforementioned software defined subsystems. The experimental evaluation and the results are presented in Section 5. Finally, we conclude and present our future plans in Section 6. 2. SOFTWARE-DEFINED SYSTEMS SDSys is an umbrella for different software-defined subsystems including SDN, SDSec, SDStorage, Software-Defined Data Center (SDDC)[19], Software-Defined Infrastructure (SDI), Software-Defined Management, SDCompute, Software-Defined Server, Software-Defined Internet of Things (SDIoT) [20], Software-Defined Radio, SDCloud [12], Software-Defined Smart Grid [21] and Software-Defined Enterprise. The software layer can control different types of hardware devices in various contexts giving rise to the term of Software Defined everything or anything (SDx).1 Many advantages can be driven from SDSys such as increasing the system performance, scalability and security and facilitating resource management more easily. SDSys provide the ability to control a wide range of computing resources in a work-flow driven and dynamic fashion by separating the control layer from the data work flow layer, i.e. isolating the control from hardware devices and setting it in a software layer. The main idea behind the SDSys is to build an orchestrated system, controller, to handle the control for all independent devices by using standard and general protocols.2 This is achieved by means of virtualization. As virtualization is the key concept of cloud computing technology. It also plays an essential role in SDSys. Virtualization creates a virtual platform for different devices or system components (such as network, OS and storage devices) that emulates the characteristics of real devices. The transformation from hardware control to software control is, therefore, achieved through virtualization. With visualization, the functionalities of a single or multiple systems can be abstracted allowing the integration of the benefits of these systems. As an illustration, consider the SDDC example, which integrates a set of servers, storage devices and networks into a single comprehensive system or resource pools.3 The following subsection are detailing the SDSys subsystems. In the following subsections, we discuss the features and the basic structures of some software defined components that are essential for the newly proposed software-defined system. 2.1. Software-defined network (SDN) SDN is the most researched software-defined system of all. As with any other SDSys, SDN is also based on the virtualization of the network resources [22]. Network resources virtualization have been done for a while. As an example, consider different types of medium multiple access schemes. In these types, channels are virtualized to allow multiple users to share the same physical channel. Virtualization also can be found in the virtual local area network, where the physical LAN is virtualized to be shared among different parts of the company or even different companies. Virtualization in networks can be carried out on the level of the network functions where different network functions can be combined by using standard protocols. Network Function Virtualization is a European group that was established to provide standards for the virtualization of different network functions [22]. SDN, as any other SDSys, comes to simplify the management in the network. This is usually done by separating the control functionalities from the data-related functionalities to form two separate planes. The packets that are created and sent by the end user form the data plane. These packets need to reach a destination. The control plane is responsible for finding the best rout for these packets by using some kind of control messages. The result will be a forwarding table that stores the information of the different routs in the network. The control plane also maintains any information related to the network such as the congestion level. The data plane uses the forwarding tables prepared by the control plane in the controller to forward the packets over possibly multiple hops from a sender to a receiver [22]. In SDN, the control plane in is usually centralized while the data plane is kept distributed. The control plane is usually centralized to expedite the decision-making process. The policies that the control plane uses are dynamically updated while the system is running not only at the time of making decisions. In [22], the authors further propose a solution in the case of the failure of the centralized controller. They propose to have a duplicated controller in the system. Another advantage of using SDN is that as the control plane is a software, it is programmable by nature and it can be easily changed when needed. With a programmable control plane, it is very easy and possible to divide the network into several virtual networks over the the same shared physical hardware. With having different networks, different policies can be forced by different networks [22]. 2.2. Software-defined storage (SDStorage) In large data storage systems such as data centers, that store a huge amount of data and exploit virtualization to deploy the system, the data forwarding processing and the management of processes occur at the same place. This deployment option increases the load on the underlying devices and that subsequently reduces the system performance. This happens because virtualization is usually used to enhance the resources utilization of the system. Unfortunately, with virtualization, management overhead across the multiple layers is produced. SDStorage facilitates and simplifies system storage management while keeping an acceptable level of QoS [23]. As many companies realize the benefits of SDStorage, they apply it in their storage centers. Examples of such companies are EMC Corporation and IBM. EMC corporation have lunched ViPR which is a software that implements SDStorage [24]. IBM has Storwize software [25]. As in any other system, SDStorage is one of the most important subsystems in SDSys. As in any other SDSys, SDStorage manages the huge amount of data it stores by isolating the control layer from the data storage layer. The control layer is represented by the software component that manages the storage resources. The data layer is represented by the underlying infrastructure of the storage devices. Beside reducing the compixity of the management of the storage resources, the isolation of the control and data layers also reduces the cost of the infrastructure. This happens because SDStorage usually uses a single central control until to manage the storage elements regardless of their physical properties instead of installing the control software on each element [23]. 2.3. Software-defined security (SDSec) With SDSys, the security challenge is shifted to a whole new level which requires innovative solutions to deal with specifications of the SDSys [26]. In SDSys, all operations are supported by virtualization and classical security solutions that usually utilizes physical devices (as in the network for example) cannot detect the insecure virtual activities. SDN central [27] detailed the main security concerns that must be addressed when designing security solutions for SDN. The following are some of these concerns. (i) how the controller must be kept protected and secure to guarantee its availability all the time, (ii) how to protect the communication in the network, and (iii) how to make sure that the controller does its assigned tasks. Any suggested security solution must be simple and cost effective [27]. The work in [26] proposed a SDSec solution that can be utilized by any software-defined system. The new solution provides a new methodology to design, deploy and manage security by separating the data forwarding and processing plane from the security control plane. Such separation provides a distributed security solution. In SDSec, security functions, that are usually done by the network devices, such intrusion detection and firewalls are converted from hardware implementations to software. By doing so, security activities, such as firewall configuration, can be automate [26]. SDSec as an idea was first mentioned by the Cloud Security Alliance (csa).4 CSA launched a Software-Defined Perimeter (SDP) project to realize the SDSec idea [28]. SDP was initially designed as a complement for SDN to reduce the attacks on the network applications by keeping them unconnected until the authentication of the users and devices. 2.4. Software-defined cloud (SDCloud) SDSys design principles served as a motivation to propose a comprehensive system architecture framework for a SDCloud. We are most interested in the framework proposed in [12] as it is the most comprehensive SDCloud framework in the literature. This framework is composed of the software-defined subsystems previously discussed in this paper: SDStorage, SDN and SDSec. Many ideas are abstracted, integrated and extended inside the newly proposed framework model. As shown in Fig. 1, the general view of the SDCloud framework does not differ much from any software-defined system in its layered hierarchical design and the abstraction of the data plane from the control plane. However, the SDCloud framework is different in the internal organization of these layers and the extended functionalities that have been added. Figure 1 presents a detailed depiction of the SDCloud framework proposed in [12]. Figure 1. Open in new tabDownload slide A prototype reflects the future of any system architecture, SDSys design. Figure 1. Open in new tabDownload slide A prototype reflects the future of any system architecture, SDSys design. The framework is divided into three general layers: the infrastructure (the physical) layer, the middleware (control) layer and the application (infrastructure as a service (IaaS)) layer. The details of each layer are as follows. The infrastructure layer. It is the first layer and a cornerstone in the framework since the other layers build over it and the different physical resources (storage, security, network, compute, etc.) are combined inside it. The role of these devices is restricted to performing the tasks according to the formulated rules generated in the control layer such as forwarding messages, storing data and packaging security appliances. There is no control, management or any decision-making process inside these devices. Network assets and security assets are just two samples for the underlying hardware devices. A virtual machine manager (VMM) is installed at the top of these devices to achieve high levels of CPU and memory utilization. Several VMs are instantiated over the VMM to accommodate as many requests as possible, in addition to providing load balancing. These VMs can be organized into different pools where each one is dedicated for one type of physical devices like network, security, etc. This way, the overhead and time of switching will be reduced where there are different VMs need to communicate and collaborate with each other to accomplish a specific task. The middleware layer is the main layer in the SDCloud framework. It is divided into two sub-layers: the Hypervisor layer and the Agent Network Operating system (AgNOS), Autonomous control, layer. The hypervisor layer: This layer controls and manages the underlying hardware of the system. All rules and decisions are defined and taken by this layer. This layer monitors all the actions happening in the underlying hardware devices because it represents the centralized control unit in this SDSys. As the control unit is usually centralized in SDSys, it is vulnerable to the single point of failure problem. To avoid this problem, this layer is constructed to be logically centralized but physically distributed. By doing this, not only the fault-tolerance of the control is enhanced but also the control system performance is enhanced as well. The distribution of the control is realized as follows. A set of different controllers are assigned to different distributed nodes. These nodes can communicate with each other through the West and East APIs. These nodes may be assigned with different types of controllers. Controllers may differ in their implementations or their functionalities. Many commercial implementation types such as NOX, Beacon and McNettle can be supported. This is done to allow the system to handle heterogeneous devices that may exist in the physical layer. Controllers with different functionalists such as SDStorage-C, SDN-C and SDSec-C can be also supported. All the controllers in the system should coordinate with each other to optimize the performance of the system. This framework also implement the idea of abstracting the monitoring functionality from the controller. This is done to simplify the controller and to reduce its load. The communication between the controllers can be done by agents that are implemented on top the controller itself or on top of the node that the controller is working on. The AgNOS layer: This layer exists to help alleviate some of the cost of the management and the administration operations. An agent Network OS is implemented at the top of the controllers to provide a self-control, self-management, self-healing and self-X. A set of sensors that work between this sublayer and the hybervisor sublayer detect and transfer all the events occurring in the hypervisor and transfer them to the agent in this sublayer. The agent uses a knowledge base and runs different applications to decide the best actions to be taken in response for each event. The agent then sends the actions to the hypervisor through a set of actuators which also work between the two sub-layers as the sensors. Southbound APIs (OpenFlow is the most popular) are used for the communication between the control layer and the physical layer. The applications layer. This is the top layer in the SDCloud framework. The lower part of this layer is the orchestrator [29]. The orchestrator contains all the security applications to deal with various security attacks. The network monitor collector in the middleware layer detects any change in the network status or any suspension event and informs the orchestrator about it. The orchestrator then asks the SDSec-C through its agent to forward the traffic that caused the problem to the orchestrator to deal with it by applying the appropriate security mechanisms. The upper part of the application layer is the only visible layer for the end users. It consists of the applications that the system is designed to run. The application layer communicates with the middleware layer through the Northbound APIs. 3. MOBILE EDGE COMPUTING MEC comes to accelerate applications and data streaming in mobile networks through caching and/or providing the required processing power for the relevant data at the edge of the mobile network as near. Although MEC is not yet deployed in real-life systems, recent studies have discussed some technical details and concepts. In this section, we discuss the definition of MEC and some other related concepts. We also present typical application scenarios that may utilize MEC. Moreover, we provide scopes and limitations that may be encountered when implementing and deploying MEC. Improving network resource utilization is one of the most important needs in mobile network systems. The increasing number of mobile users as well as the increasing number of mobile applications contribute significantly in the increase of mobile network traffic. In traditional cloud computing systems, this increase in users and applications produces high load on the core cloud servers. Since these applications rely heavily on services hosted by the cloud servers, these services need data to be uploaded from mobile devices and downloaded from the core cloud servers. As a result, network bandwidth demands in these systems are continuously growing. Adding to that the bandwidth demands introduced by the introduction of the IoT. To cope with the growing bandwidth demands, current network resources need to be continuously improved on one hand. On the other hand, new advanced technologies should be adopted to enhance the QoS provided to end users. New technologies, such as LTE Advanced, are proposed in order to increase the network bandwidth capacities as well as to reduce processing latency. However, this affects the resource utilization within the network core and requires further investments which causes higher operational cost. Recently, MEC has been proposed as a promising paradigm to overcome this issue in certain scenarios. In MEC, instead of relying on a centralized platform to serve all mobile devices, a decentralization platform is suggested. This can be achieved by moving cloud servers to the edge of the mobile network. This platform was first proposed by Akamai [30] when they described their content delivery network topology. This topology was used to cache some of the frequently requested contents at the network edge. Recent studies propose integrating MEC with cloud computing principles to provide more complex services at the edge of the network. Aiming at (i) reduce the load on the centralized cloud and (ii) avoid bottlenecks and single points of failure. Traditionally, devices at the mobile edge merely represent mobile access points, which forward traffic coming from base stations, and do not respond or analyze user requests. MEC introduces new network elements at the network edge that provides computational power and storage capabilities. Therefore, these new devices can service user request locally instead just forward these requests. In the rest of this paper, these devices are referred to as MEC servers. 3.1. MEC similar platforms Several terms in MCC such as MEC, fog computing (FC) and mist computing have been introduced to refer to a platform, in which, a set of devices with limited capabilities can use some nearby resources within nearby devices to accomplish their work. In these platforms, the network edge is not well identified and, to distinguish between them, we illustrate each concept in details. MCC refers to a platform that provides computation, storage and applications as services to mobile users. These services are usually provided by a set of centralized datacenters that are managed and controlled by the centralized service provider. MCC represents the incorporation between the cloud computing and the mobile devices. MCC provides many benefits: (i) it overcomes the limited mobile devices capabilities such as the limited battery life, small memory and the limited bandwidth, (ii) it handles some environment difficulties such as heterogeneity and availability, and (iii) it improves mobile security, privacy and reliability [31]. Earliest cloud-oriented mobile applications were rely on a stable connection to some cloud servers. This problem has been resolved in the recent work in [32, 33] by implementing a code offloading technique. It migrates some of the MCC application code and state onto nearby devices in between the mobile device and the cloud server. This approach is called cloudlet [5]. Another concept that is similar to MEC is FC. FC can be seen as a middle layer between MCC and MEC and is defined as a virtualized platform which is not exclusively placed at the network edge and it can provide cloud services between end users and cloud computing datacenters [34]. MEC and FC can help reduce services latency and increase execution speed. Even that both MEC and FC seem very similar to grid computing, they differ in that the work distribution logic is implicitly handled by an underlying infrastructure layer, and not explicitly assigned into the applications. Means that there will be fog devices and mobile edge servers available whenever there are tasks need to be performed more quickly and locally. Mist Computing is another similar concept to MEC. Mist Computing is something that mixes FC and MEC. It extends the traditional client–server approach to a more peer-to-peer based approach. In the rest of this paper, we will use MEC to refer to all of the above concepts. 3.2. MEC characterization The following are the main characteristics of any MEC-based system: On-premises: Since the edge is local, this means that it can run in isolation from the rest of the overall network, while having the ability to access to local resources. Which is important for Machine-to-Machine scenarios. For example, when users need to deal with high level of security or safety systems. Proximity: As the users are close to the information source, Edge Computing is specifically useful to gather important information for analytics and big data, to be able to provide more enhanced services to end users. Edge servers may also have the ability to directly access connected devices, which can easily be leveraged by business-specific applications. Lower latency: Since edge services run as near as possible to end users, it significantly reduces latency. And can be utilized to respond faster, to enhance QoE, or to reduce congestion in the rest of the network. Location awareness: As the edge of the network is part of a wireless network, either it is cellular or Wi-Fi, a local service can leverage low-level signaling information to identify the location of each connected device. This allows new business-oriented use cases, including Location Based Services and Analytics. 3.3. MEC deployment scenarios As suggested by the Industry Specification group,5 MEC-based systems are going to support deployment options that going to have the MEC server installed with the a multi-technology (LTE/3G) base station. The base station can be deployed indoor in places such as hospitals and large corporate HQ, or indoor/outdoor for a mixed coverage scenarios such as in stadiums and shopping malls. The base station may control a number of local access points that can support multi-technology communication. Figure 2 shows a possible MEC deployment. Figure 2. Open in new tabDownload slide MEC Framework. Figure 2. Open in new tabDownload slide MEC Framework. Applications that may incorporate MEC include: Smart grids: This application aims at optimizing asset utilization and operating efficiency, accommodate all generation and storage options, provide power quality for the range of needs in a digital economy, anticipate and respond to system disturbances in a self-healing manner, Operate resiliently against physical and cyber attacks and natural disasters, enable active participation by consumers, and enable new products, services and markets. MEC can be a key enabler in order to achieve these goals, since it allows fast machine-to-machine (M2M) handshakes and human to machine interactions. This would work with both the cloud and edge devices. Take for example smart power grid. Based on the demand for energy and its obtainability and low cost, these smart devices can switch to other energies like solar and winds. The edge processes the data collected by edge collectors and generate control command to the actuators. The filtered data are consumed locally and the balance is forwarded to the higher tiers for visualization, real-time reports and transactional analytics. Network edge supports semi-permanent storage at the highest tier and momentary storage at the lowest tier [35]. Smart transportation or smart traffic: Incorporating MEC technology with the traffic system can provide a lot of useful functions such as enabling traffic signals to open paths when sensing ambulance flashing lights, detecting the existence of bikers and pedestrian, measuring the speed and distance of the close by cars, identifying movements of vehicles to take an action like turning on sensor lights on the streets. Also, the smart lights can be deployed as fog devices to broadcast warning signals to the approaching vehicles. On the other hand, smart traffic includes several requirements such as real time traffic map and on-demand travel route recommendation. Both archived and real-time data involved in these applications could potentially be very big, depending on the number of deployed sensors. MEC infrastructure which includes enhanced interactions between end users through enhanced Wi-Fi, 3G access points and road side units can elastically handle such big data and conveniently providing nearly unlimited computing and storage resources to hosted applications, to carry out analysis not only for long-term planning and decision-making but also analytics for near real-time decision support [36]. Video streaming: More than 50% of mobile data traffic is expected to be generated by video streaming in 2019 [1]. Subscribers all over the world searches through gigabytes of streaming video, music and social network every month. Mobile network owners are trying to stay ahead of data demand by enhancing their radio access networks by adding small cells. Therefore, caching content at the edge is a promising approach to reduce communication quantity and latency for core network providers. Mobile big data analytics: Applications these days are generating huge amount of data. These data are being generated faster. Using the services on MEC makes it easier to collect and analyze such an amount of data [34]. Wireless sensors and actuators networks: The original Wireless Sensor Nodes (WSNs) were designed to operate at extremely low power to extend battery life. Most of these WSNs involve large number of low bandwidth, low energy, low processing power and small memory nodes, operating as sources (collector) that collect data and send it to a sink in an unidirectional fashion. Sensing the environment, simple processing and forwarding data to the static sink are the duties of this class of sensor networks. The characteristics of MEC (proximity and location awareness, geo-distribution, hierarchical organization) make it the suitable platform to support both energy-constrained WSNs and WSANs [34]. Mobile gaming: Modern mobile game features include low latency, improved reliability and the need to deliver high-quality graphics to end users. MEC offers a suitable platform to handle the heavy, unpredictable traffic that can come from a new game. Mirror Images online gaming solution guarantees the delivery of video trailers, images and other dynamic content around the globe with the best performance available using MEC services. Edge healthcare: The cloud computing market for healthcare is expected to reach $5.4 billion by 2017, and FC would allow this on a more localized level. 3.4. Related work in the field of MEC In [37], the authors analyze a system called volley. It addresses the challenges arise from the rapidly growing cloud services across distributed datacenters. These challenges include (i) the need for automated mechanisms for placing application data among different datacenters, taking into account, the WAN bandwidth cost as well as the datacenters capacity limitations, and (ii) reducing end user latency considering, shared data, data inter-dependencies and application changes. Volley is used to automate the process of data placement among geographically distributed datacenters. The authors in [37] claimed that Volley reduces the oblique in datacenters load by more than two times. Also it reduces inter-datacenters traffic by more than 1.8 times. Moreover, it reduces latency. Dsouza et al. [38] proposes a policy-based management framework for FC resources, and extends the current FC system to make it possible for the users to have a secure communication and resource sharing across distributed environment when requesting resources. The proposed policy includes five modules: (i) Policy Decision Engine which is implemented to make decisions upon data received from all connected components. Based on the requested services and the end user. It also analyzes the rules specified in the Policy Repository and makes a decision which is then enforced, (ii) Application Administrator which is responsible for defining policies that provide a specific application to a particular user and ensure secure communication among multiple fog nodes, (iii) Policy Resolver which follows attribute-based security procedure in which users are authenticated and identified by a set of attributes which they present, and then these attributes are analyzed by attribute finder scheme and forwarded to the policy resolver for further accumulation, after that the user access is identified based on a set of attributes defined and stored in an attribute repository, (iv) Policy Repository which contains a set of rules needed by the Policy Decision Engine when making policy decisions, and (v) Policy Enforcer which resides either within a virtual instance such as fog node, fog instance or cloud datacenter, or within physical devices such as connected vehicle or mobile device. In [39], the authors propose a communication architecture called smart gateway and its integration with FC. The smart gateway refers to the scheme which is responsible for preprocessing and aggregating data before it can be transferred to the cloud in order to reduce the load on the core cloud. The authors then test their architecture in terms of different delay aspects, including upload and bulk-data upload, synchronization and bulk-data synchronization and jitter delays. They showed that using smart gateway-based communication with FC helps cloud to provide improved services and make it easier and faster to deliver services to applications that require low latency. In [40], the authors discuss the main advantages that can be achieved when deploying FC platform. They also provide an analysis of some application scenarios that can benefit from deploying such a platform. These scenarios include Smart Grid, smart traffic lights in vehicular networks and software-defined networks. Then, the authors discuss some security issues within FC and provide a case study to illustrate these issues. They studied the man-in-the-middle attack and how it can affect the performance of fog devices such as CPU utilization and memory consumption. Experiments show that man-in-the-middle attack can be very stealthy within FC since it has just a little increase in the CPU utilization and the memory consumption. 4. SDSYS SUPPORT FOR MEC In this paper, we propose a general Software-Defined System (SDS) framework that supports MEC. In this section, the proposed system architecture is to be detailed and explained. Further, the typical communication inside the proposed system is to be shown in an abstracted way. Mainly, we show how the system handle the global and the local requests in an smooth way. Moreover, the advantages behind adapting this architecture will be illustrated at the end of this section. 4.1. The proposed system architecture Figure 3 illustrates the general framework architecture of the proposed MEC SDS System. MEC network consists of several domain environments. Each domain is controlled by a local software-defined controller which is responsible for keeping smooth communication between the entities inside the same local domain. This local controller is also needed because all the local resources in the domain should be managed and a decision whether a local request should be services locally or should be forwarded to the cloud should be taken by this controller. Nevertheless, all the decisions which requires a higher level of control are enforced by a global software-defined controller. The main responsibility of the global centralized controller is the controlling of all the local controllers and ensuring that all the entities in the MEC network work in an efficient way. Moreover, any critical and unsolved issue faced by the local controller will be transferred to the global controller for it to take the proper action. Figure 3. Open in new tabDownload slide A prototype reflects the future architecture of MEC design based on SDSys. Figure 3. Open in new tabDownload slide A prototype reflects the future architecture of MEC design based on SDSys. 4.2. Control layers In the proposed system, there are two layers (levels) of control: centralized global control layer (upper layer) and Local control layer (lower level). Global controller layer: The global controller is considered as the engine for the whole MEC. All main controls and decisions are initialized and established at this level. This controller combines several unites. Each unit has its roles and functionalities. Figure 4 depicts these main units. SDN controller unit: The control and management of the network components are handle by the SDN controller unit. All the network switches are configured and set up by this unit. All the rules of traffic flows are generated inside this unit which are then pushed to the network switches as flow tables. These flow tables determine the proper action when a new packet is received by a network switch. SDStorage controller unit: This unit is mainly responsible for controlling and managing the storage resources in the system such as local databases and cloud storage. All the configurations of the storage resources are generated inside this unit. Moreover, this unit is responsible for monitoring the available storage resources. Furthermore, this unit creates a function table which stores the mandatory information for all storage hosts. More details about this type of controller have been explained in our previous work [41]. The abstracted architecture of the SDStorage unit consists of three sub-layers: infrastructure layer, control layer and application layer. The infrastructure layer combines various storage devices storing the raw data. The controller in the control layer is considered the most critical element in SDStorage systems. It is where the storage resources in the infrastructure layer interact with the application layer. The control layer converts different policies to different instructions inside the system. The last layer in this architecture is the application layer which holds different applications and allows the end user to interact with storage devices. SDSecurity controller unit: The SDSecurity unit takes the responsibility of monitoring and managing the security aspects of the underlying devices and hosts. Many security policies and mechanisms are established inside this controller unit. This unit is proposed to guarantee a high level of protection and safety of the network hosts by integrating several security techniques inside a single comprehensive unit. Such integration provides a single point of view for all the network devices which ensures that all the security holes are covered in an efficient manner. More details about this components can be found in out previous work in [26]. The general view of this architecture is organized into three main layers: the physical layer, the control layer and the application layer. The Physical layer: inside this layer, all the hardware devices are located, which may include database arrays, switches, routers or any other asset. This layer is also called the data layer and its role is limited to following the policies created by the control layer, which resides on top of this layer. The Control layer (Middleware layer): all the control and management operations are abstracted from the devices located in the physical layer and set inside this layer. This layer is considered the brain of any SDSys since it handles all the core control operations. The Application layer: it is the only one visible to the user. All applications are implemented inside this layer. Several applications can be created on the top of the control layer to help the users interact with the underling devices and data. The three layers can communicate with each other by a set of APIs, southbound and northbound. The former is used by the physical layer to interact with the control layer. The most famous example of such APIs is the OpenFlow protocol, which is used in SDN systems. As for the latter, it is used by the user's applications to interact with the control layer. To the best of our knowledge, there is no standard northbound APIs till now. SDCompute controller unit: Inside this unit, all controls and functions related to computation are generated. This unit handles all the aspects which are related to the computational resources and then push these information to the computational switches to update their stored tables. SDIoT controller unit: All the sensors, actuators and other MEC resources, which generate a large volume of data, require a dedicated unit to control and manage them and their generated data. One way to achieve this is to use an IoT controller unit. All the ‘things’ configuration procedures are established in this unit. Moreover, monitoring the movements and the health of these devices is the responsibility of this unit [20]. SDSG controller unit: Smart Grid network is considered to be one of the most common domains in any environment. The main role of this unit is the control and management of the smart grid network. Several control and management transactions are generated at this unit. Including the SDSG unit shows that the framework can be extended for other applications such as smart city. Aggregation unit: This unit is responsible to aggregate the data frequently from the underling control level which run several local controllers. It checks the network status to be notified to any up-normal flow. Figure 4. Open in new tabDownload slide The main unites for the Global SDSys Controller. Figure 4. Open in new tabDownload slide The main unites for the Global SDSys Controller. Local controller layer: All the edge resources-related control resides at this layer. Each local controller takes the responsibility to cover, check and control its domain and negotiate the main global controller when needed. Figure 5 shows the main units inside each local controller. The local controller has all the units that are in the global controller except the aggregation unit. These units play the same role in the local and the global controller except that the ones in the local controller works in a smaller scope. Figure 5. Open in new tabDownload slide The main unites for the Local SDSys Controllers. Figure 5. Open in new tabDownload slide The main unites for the Local SDSys Controllers. 4.3. The advantages of the Global/Local levels Reduce the overhead on the global controller: The overall overhead is distributed to the local controllers. Thereby, only the main critical issues are handled by the global controller. Take real-time decisions: When each local controller serve its nearby local entities, then the request does not need to go to the global controller and this increase the response time. Avoid single point of failure problem: The idea of the distribution of control to the local controllers reduces the risk of single point of failure. Reduce the delay: When the requests served locally this thing increase the system performance by reducing the delay. Scalability: Integrating several local controllers facilitate the process of expansion of the network and increase the number of supported domains. Reduce the global network traffic: The traffic is reduced through reducing global communication. This is achieved since only the main requests only is transferred to the global controller. 5. EXPERIMENTAL RESULTS AND EVALUATION We implemented the proposed framework in Mininet [18]. Mininet is the most popular SDSys simulator among researchers because it simulates OpenFlow-based SDN. Mininet has three main components: host, switch and a central controller. The host sends and receives packets over the network. The switch stores all the required rules for packets forwarding. The central controller handles the control and management operations in the network. Mininet supports different types of virtualized hosts, switches and controllers. Furthermore, it provides two essential tests, ping and iperf, to check the node reachability and the network bandwidth, respectively. We customize the main components of Mininet to implement the proposed framework. Host: The Mininet host element is a simple entity that can send or receive data traffic through the network. We extend this element in Mininet to make it implement our host functionality. We implemented different types of hosts: an SDStorage Host, an SDSecurity Host, an SDCompute Host, an SDIoT Host and other software-defined hosts. Switch: Switches are responsible for data and request forwarding in the system. Different types of switches are implemented in Mininet which are UserSwitch, KernelSwitch and OVSSwitch. We customized the UserSwitch to implement our framework switches. This switch have the functionalities of a network switch, a storage switch and a compute switch. It is a combination of all of these switches (this switch inherits all switches types). Controller: The controller that we build follows the specification described in Section 4.2. 5.1. Results and analysis Figure 6 shows the effect of increasing the number of local controllers on the number of requests. As we note, when the number of local controllers increased, the number of requests which are handled by the global controller will be reduced. Where, the total number of requests which handled by all the local controllers will be increase, since each local controller has limited resources to serve a limited number of requests, so when this limit exceed then the local controller forwards the request to the global controller to handle and process it. In case of increasing the number of local controllers then most of the requests will be handled in the local domains and only the critical requests forwarded to the global controller. Figure 6. Open in new tabDownload slide Total number of requests on Global/Local controllers when increase the number of local controllers. Figure 6. Open in new tabDownload slide Total number of requests on Global/Local controllers when increase the number of local controllers. On the other hand, Fig. 7 shows how the controllers resources consumption will be changed when increasing the number of local controllers. As we show, when we increase the number of local controllers then the resource consumption of the global controller will be reduced, since most of the overhead and the request processing occur at the local level control. It is important to mentioned that even the resources consumption in the local controller increased, nevertheless, this number reflects the total resources consumption on all local controllers not only one controller which makes a sense. Figure 7. Open in new tabDownload slide The total resource consumption on Global/Local controllers when the number of local controllers is increased. Figure 7. Open in new tabDownload slide The total resource consumption on Global/Local controllers when the number of local controllers is increased. To demonstrate the impact of our proposed model, we conduct a simple comparison between our approach (Software-Defined Distributed and hierarchical control) and traditional approach(Centralized). The results in Fig. 8 reflect the total requests handled by the global controller in both cases. As we note, in our approach (Not Centralized), the number of requests is much less compared with centralized controlling. Since most of the requests are processed by the local controllers. Figure 9 on the another side shows how the resource consumption of the global controller will be affected by the two approaches. If sure in decentralized approach, the resources of the global controller will not be used as in centralized one, since overhead also will be distributed as well. Figure 8. Open in new tabDownload slide The total number of requests served in global controller when centralized and decentralized approaches. Figure 8. Open in new tabDownload slide The total number of requests served in global controller when centralized and decentralized approaches. Figure 9. Open in new tabDownload slide The total resource consumption in global controller when centralized and decentralized approaches. Figure 9. Open in new tabDownload slide The total resource consumption in global controller when centralized and decentralized approaches. Figure 10 shows the overhead on Global/Local controllers over 30 seconds. You can notice how the overhead on the global controller is much less than the total local controllers. Figure 10. Open in new tabDownload slide The total overhead in the Global/Local controllers over the time. Figure 10. Open in new tabDownload slide The total overhead in the Global/Local controllers over the time. 6. CONCLUSION This paper suggested that MEC should be used for the shift from traditional MCC to ubiquitous MCC is required. MCC providers typically rely on direct offloading of task-intensive mobile applications to the the cloud or to a local cloudlet system to provide a seamless application execution on the cloud. MEC provides the ability to fulfill the computing and storage needs of mobile end users with a resource-rich ME servers available at the access point of the mobile networks, which allows a secure, efficient and low latency execution. SDSys can be integrated with the system to deal with the complexity of the management and control that comes from integrating MEC and MCC. This paper presented a framework that achieves the ultimate goal of building software-defined based MCC. The proposed system integrates several aspects of SDSys, including mainly SDN, SDCompute, SDStorage and SDSec, with the MEC system. The proposed system architecture is evaluated using Mininet simulation. FUNDING The Deanship of Research at the Jordan University of Science and Technology for funding this work grant nos. (20160081, 20150348). Also, they would like to thank IBM and IBM Cloud Academy for their support. REFERENCES 1 Beck , M.T. , Werner , M., Feld , S. and Schimper , S. ( 2014 ) Mobile edge computing: A taxonomy. 2 Ahmed , A. and Ahmed , E. ( 2016 ) A Survey on Mobile Edge Computing. In 10th IEEE Int. Conf. Intell. Syst. Control, (ISCO 2016). IEEE. 3 Alsmirat , M.A. , Jararweh , Y., Obaidat , I. and Gupta , B.B. ( 2016 ) Internet of surveillance: a cloud supported large-scale wireless surveillance system . J. Supercomput. , 1 – 20 . OpenURL Placeholder Text WorldCat 4 Jararweh , Y. , Doulat , A., AlQudah , O., Ahmed , E., Al-Ayyoub , M. and Benkhelifa , E. ( 2016 ) The Future of Mobile Cloud Computing: Integrating Cloudlets and Mobile Edge Computing. In 2016 23rd Int. Conf. Telecommun. (ICT), pp. 1–5. IEEE. 5 Satyanarayanan , M. , Bahl , P., Caceres , R. and Davies , N. ( 2009 ) The case for VM-based cloudlets in mobile computing . Pervasive Comput., IEEE , 8 , 14 – 23 . Google Scholar Crossref Search ADS WorldCat 6 Ahmed , E. , Gani , A., Khan , M.K., Buyya , R. and Khan , S.U.. ( 2015 ) Seamless application execution in mobile cloud computing: motivation, taxonomy, and open challenges . J. Netw. Comput. Appl. , 52 , 154 – 172 . Google Scholar Crossref Search ADS WorldCat 7 Beck , M. , Feld , S., Fichtner , A., Linnhoff-Popien , C. and Schimper , T. ( 2015 ) Me-volte: Network Functions for Energy-Efficient Video Transcoding at the Mobile Edge. In 2015 18th Int. Conf. Intell. Next Generation Networks (ICIN), February, pp. 38–44. 8 Makinen , O. ( 2015 ) Streaming at the Edge: Local Service Concepts Utilizing Mobile Edge Computing. In 2015 9th Int. Conf. Next Generation Mobile Applications, Services and Technologies, September, pp. 1–6. 9 Hariri , S. , Khargharia , B., Chen , H., Yang , J., Zhang , Y., Parashar , M. and Liu , H. ( 2006 ) The autonomic computing paradigm . Clust. Comput. , 9 , 5 – 17 . Google Scholar Crossref Search ADS WorldCat 10 Buyya , R. , Calheiros , R.N., Son , J., Dastjerdi , A.V. and Yoon , Y. ( 2014 ) Software-Defined Cloud Computing: Architectural Elements and Open Challenges. In 2014 Int. Conf. Advances in Computing, Commun. Inf., ICACCI 2014, Delhi, India, September 24–27, 2014, pp. 1–12. 11 Grandl , R. , Chen , Y., Khalid , J., Yang , S., Anand , A., Benson , T. and Akella , A. ( 2013 ) Harmony: Coordinating Network, Compute, and Storage in Software-Defined Clouds. In Proc. 4th Annual Symp. Cloud Comput., New York, NY, USA SOCC ‘13, pp. 53:1–53:2. ACM. 12 Jararweh , Y. , Al-Ayyoub , M., Darabseh , A., Benkhelifa , E., Vouk , M. and Rindos , A. ( 2016 ) Software defined cloud: survey, system and evaluation . Future Gener. Comput. Syst. , 58 , 56 – 74 . Google Scholar Crossref Search ADS WorldCat 13 Jararweh , Y. , Doulat , A., Darabseh , A., Alsmirat , M., AlAyyoub , M. and Benkhelifa , E. ( 2016 ) SDMEC: Software Defined System for Mobile Edge Computing. 2016 IEEE Int. Conf. Cloud Engineering Workshop (IC2EW), April, pp. 88–93. 14 Kandiraju , G. , Franke , H., Williams , M., Steinder , M. and Black , S. ( 2014 ) Software defined infrastructures . IBM J. Res. Dev. , 58 , 2 – 1 . Google Scholar Crossref Search ADS WorldCat 15 Jararweh , Y. , Jarrah , M., Alshara , Z., Alsaleh , M.N., Al-Ayyoub , M. et al. . ( 2014 ) Cloudexp: a comprehensive cloud computing experimental framework . Simul. Model. Pract. Theory , 49 , 180 – 192 . Google Scholar Crossref Search ADS WorldCat 16 Li , C. et al. . ( 2014 ) Software defined environments: an introduction . IBM J. Res. Dev. , 58 , 1 – 1 . Google Scholar Crossref Search ADS WorldCat 17 Al-Ayyoub , M. , Jararweh , Y., Daraghmeh , M. and Althebyan , Q. ( 2015 ) Multi-agent based dynamic resource provisioning and monitoring for cloud computing systems infrastructure . Clust. Comput. , 18 , 919 – 932 . Google Scholar Crossref Search ADS WorldCat 18 de Oliveira , R. , Shinoda , A., Schweitzer , C. and Rodrigues Prete , L. ( 2014 ) Using Mininet for Emulation and Prototyping Software-Defined Networks. In 2014 IEEE Colombian Conf. Communications and Computing (COLCOM), June, pp. 1–6. 19 Darabseh , A. , Al-Ayyoub , M., Jararweh , Y., Benkhelifa , E., Vouk , M. and Rindos , A. ( 2015 ) SDDC: a software defined datacenter experimental framework . FiCloud , 2015 , 189 – 194 . OpenURL Placeholder Text WorldCat 20 Jararweh , Y. , Al-Ayyoub , M., Darabseh , A., Benkhelifa , E., Vouk , M. and Rindos , A. (2015) SDIoT: a software defined based internet of things framework . J. Am. Intell. Hum. Comput. , 6 , 453 – 461 . Crossref Search ADS WorldCat 21 Jararweh , Y. , Darabseh , A., Al-Ayyoub , M., Bousselham , A. and Benkhelifa , E. ( 2015 ) Software Defined Based Smart Grid Architecture. In 2015 IEEE/ACS 12th Int. Conf. Comput. Syst. Appl. (AICCSA), November, pp. 1–7. 22 Jain , R. and Paul , S.. ( 2013 ) Network virtualization and software defined networking for cloud computing: a survey . IEEE Commun. Mag. , 51 , 24 – 31 . Google Scholar Crossref Search ADS WorldCat 23 Wu , F. and Sun , G. ( 2013 ) Software-Defined Storage. Report. University of Minnesota. 24 H11749.4 ( 2015 ) Transform Your Storage for the Software Defined Data Center with EMC ViPR Controller. White Paper. EMC Corporation. 25 TSS03158-USEN-01 ( 2014 ) Choose a Storage Platform that can Handle Big Data and Analytics. Solution Brief. IBM Corporation. 26 Darabseh , A. , Al-Ayyoub , M., Jararweh , Y., Benkhelifa , E., Vouk , M. and Rindos , A. ( 2015 ) SDSecurity: A Software Defined Security Experimental Framework. In Third Workshop on Cloud Computing Systems, Networks, and Applications (CCSNA-2015). 27 Security challenges in sdn (software-defined networks) . https://www.sdxcentral.com/resources/security/security-challenges-sdn-software-defined-networks/ (Online; accessed October, 2014). 28 ( 2013 ) Software Defined Perimeter. White Paper. Cloud Security Alliance. 29 Zaalouk , A. , Khondoker , R., Marx , R., and Bayarou , K. ( 2014 ) Orchsec: An Orchestrator-Based Architecture for Enhancing Network-Security Using Network Monitoring and SDN Control Functions. In 2014 IEEE Network Operations and Management Symposium (NOMS), May, pp. 1–9. 30 Davis , A. , Parikh , J., and Weihl , W.E. ( 2004 ) Edgecomputing: Extending Enterprise Applications to the Edge of the Internet. In Proc. 13th Int. World Wide Web Conf. Alternate Track Papers & Posters, pp. 180–187. ACM. 31 Wang , Y. , Chen , R. and Wang , D.-C.. ( 2015 ) A survey of mobile cloud computing applications: perspectives and challenges . Wirel. Pers. Commun. , 80 , 1607 – 1623 . Google Scholar Crossref Search ADS WorldCat 32 Cuervo , E. , Balasubramanian , A., Cho , D.-K., Wolman , A., Saroiu , S., Chandra , R. and Bahl , P. ( 2010 ) MAUI: Making Smartphones Last Longer with Code Offload. In Proc. 8th Int. Conf. Mobile Systems, Applications, and Services, pp. 49 – 62 . ACM . 33 Kemp , R. , Palmer , N., Kielmann , T. and Bal , H.. ( 2012 ) Cuckoo: A Computation Offloading Framework for Smartphones. In Mobile Computing, Applications, and Services , 59 – 79 . Springer . Google Scholar Crossref Search ADS Google Scholar Google Preview WorldCat COPAC 34 Bonomi , F. , Milito , R., Zhu , J. and Addepalli , S. ( 2012 ) Fog Computing and Its Role in the Internet of Things. In Proc. 1st Edition of the MCC Workshop on Mobile Cloud Computing, pp. 13–16. ACM. 35 Peter , N. . ( 2015 ) Fog computing and its real time applications . Int. J. Emerg. Technol. Adv. Eng. , 266 – 269 . IJETAE. OpenURL Placeholder Text WorldCat 36 Wang , W.Q. , Zhang , X., Zhang , J. and Lim , H.B. ( 2012 ) Smart Traffic Cloud: An Infrastructure for Traffic Applications. In 2012 IEEE 18th Int. Conf. Parall. Distrib. Systems (ICPADS), pp. 822–827. IEEE. 37 Agarwal , S. , Dunagan , J., Jain , N., Saroiu , S., Wolman , A. and Bhogan , H.. ( 2010 ) Volley: automated data placement for geo-distributed cloud services . NSDI , 17 – 32 . OpenURL Placeholder Text WorldCat 38 Dsouza , C. , Ahn , G.-J., and Taguinod , M. ( 2014 ) Policy-Driven Security Management for Fog Computing: Preliminary Framework and a Case Study. In 2014 IEEE 15th Int. Conf. Information Reuse and Integration (IRI), pp. 16–23. IEEE. 39 Aazam , M. and Huh , E.-N. ( 2014 ) Fog Computing and Smart Gateway Based Communication for Cloud of Things. In 2014 Int. Conf. Future Internet of Things and Cloud (FiCloud), pp. 464–470. IEEE. 40 Stojmenovic , I. and Wen , S. ( 2014 ) The Fog Computing Paradigm: Scenarios and Security Issues. In 2014 Federated Conf. Comput. Science and Inf. Syst. (FedCSIS), pp. 1–8. IEEE. 41 Darabseh , A. , Al-Ayyoub , M., Jararweh , Y., Benkhelifa , E., Vouk , M., and Rindos , A. ( 2015 ) SDstorage: A Software Defined Storage Experimental Framework. In IEEE Int. Conf. Cloud Eng. (IC2E 2015). Footnotes 1 " http://www.memorableurl.com/2013/12/software-defined-anything.html 2 " http://www.meetup.com/MESS-LA/events/147433842/ 3 " http://www.tvtechnology.com/fromthe-editors/0145/software-defined-systems–virtualization/216662 4 " https://cloudsecurityalliance.org/ 5 " https://portal.etsi.org/Portals/0/TBpages/MEC/Docs/ETSI%20ISG%20MEC%20ToR_final%20_2_.pdf Author notes Handling editor: Linghe Kong © The British Computer Society 2017. All rights reserved. For Permissions, please email: journals.permissions@oup.com
TI - Software-Defined System Support for Enabling Ubiquitous Mobile Edge Computing
JF - The Computer Journal
DO - 10.1093/comjnl/bxx019
DA - 2017-10-01
UR - https://www.deepdyve.com/lp/oxford-university-press/software-defined-system-support-for-enabling-ubiquitous-mobile-edge-cwdnXK2xz4
SP - 1443
VL - 60
IS - 10
DP - DeepDyve
ER -