Task Ofﬂoading in Mobile Edge Computing Networks · Mobile Edge Computing (MEC) is an envisioned paradigm to solve the contradiction between the growing delay-sensitive and computation-intensive

Task Offloading in Mobile EdgeComputing Networks

Hua Guo

A thesis submitted for the courseCOMP8755 Individual Computing Project

Supervised by: Prof. Weifa LiangThe Australian National University

June 2020

Draft Copy – 12 June 2020

c© Hua Guo 2011


Except where otherwise indicated, this thesis is my own original work.

Hua Guo12 June 2020


Acknowledgments

Firstly, I am sincerely grateful for my supervisor, Prof. Weifa Liang, for providingme with the chance to study this research project. His patient guidance and advicesupport me to accomplish this project. He also gives me instructive suggestions onthesis writing and presentation. Secondly, I want to thank Jing Li and Yu Ma, fortheir kindly help during this project. Finally, I want to show my gratitude for theencouragement of my parents and friends, which supports me a lot.

iv


Abstract

Mobile Edge Computing (MEC) is an envisioned paradigm to solve the contradictionbetween the growing delay-sensitive and computation-intensive applications withresource-constrained mobile devices. Network services demanded by user requestsare implemented as Virtualized Network Function (VNF) instances on cloudlets inMEC networks by the implementation of Network Functions Virtualization (NFV),which reduces the capital cost and operation cost of network service providers. Inthis thesis, we aims to devise algorithms to optimize the profit collected by networkservice providers.

We first devise a novel task offloading problem to maximize the accumulated profitof admitted requests, assuming that user requests with the same type of VNF canshare VNF instances in one cloudlet in MEC networks. We then prove the problemis NP-hard. We propose an exact ILP solution and an efficient heuristic algorithmfor the problem. Furthermore, we devise an approximation algorithm for one specialcase of the problem where delay constrains and sharing VNF instances are neglected.Finally, the performance of the proposed algorithms is evaluated by empirical anal-ysis. The experimental results demonstrate that ILP takes significantly high runningtime to return optimal solutions, which is only applicable to small-scale problems.On the other hand, the proposed algorithms outperform the benchmark and achievea near-optimal accumulated profit in a scalable and efficient way.

v


Contents

Acknowledgments iv

Abstract v

1 Introduction 11.1 Problem Statement and Motivations . . . . . . . . . . . . . . . . . . . . . 11.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Project Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background and Related Work 42.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Fundamentals of MEC . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Network Function Virtualization . . . . . . . . . . . . . . . . . . . 6

2.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Preliminaries 93.1 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 User Requests and Shared VNF Instances . . . . . . . . . . . . . . . . . . 113.3 Offloading Request Delay Modeling . . . . . . . . . . . . . . . . . . . . . 113.4 Cost and Profit by Admitted Requests . . . . . . . . . . . . . . . . . . . . 123.5 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Algorithms for the task offloading profit maximization problem 154.1 ILP Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Greedy algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.3 Algorithm analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Algorithms for special task offloading profit maximization problems 205.1 Task offloading profit maximization problem without sharing VNF in-

stances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.1.1 Integer Linear Programming Formulation . . . . . . . . . . . . . 205.1.2 Greedy algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Task offloading profit maximization problem without delay and shar-ing VNF instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2.1 ILP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

vi


Contents vii

5.2.2 Approximation algorithm . . . . . . . . . . . . . . . . . . . . . . . 235.2.3 Algorithm analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Evaluation 256.1 Experiment settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.2 Algorithm performance for the task offloading profit maximization

problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.3 Algorithm evaluation for two special cases task of offloading profit

maximization problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.3.1 The special case without sharing VNF instances . . . . . . . . . . 276.3.2 The special case without delay and sharing VNF instances . . . . 30

6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7 Conclusions and Future Work 327.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Appendix 36.1 Independent Study Contract . . . . . . . . . . . . . . . . . . . . . . . . . 36.2 Software/Artefacts Description . . . . . . . . . . . . . . . . . . . . . . . . 39.3 Readme File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42


List of Figures

2.1 General architecture of the MEC network [Pham et al., 2019] . . . . . . . 52.2 NFV environment [Herrera and Botero, 2016] . . . . . . . . . . . . . . . 62.3 NFV environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 An instance of an MEC network . . . . . . . . . . . . . . . . . . . . . . . 11

6.1 Performance of algorithms Greedyprofit and algorithm ILP for taskoffloading profit maximization problem by changing the amount ofrequests from 100 to 1,000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2 Performance of algorithms Greedyprofit and algorithm Baselinefor task offloading profit maximization problem for 3000 requests bychanging the amount of APs from 10 to 300 . . . . . . . . . . . . . . . . 27

6.3 Performance of algorithm Greedyprofit and algorithm ILP for taskoffloading profit maximization problem without sharing VNF instancesby changing the amount of requests from 100 to 1,000 . . . . . . . . . . 28

6.4 Performance of algorithm Greedyprofit and algorithm Baseline fortask offloading profit maximization problem without sharing VNF in-stances for 3000 requests by changing the amount of APs from 10 to300 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.5 Performance of algorithm Greedyprofit for offloading profit maxi-mization problem when sharing and not sharing VNF instances for3000 requests by changing the amount of APs from 10 to 300 . . . . . . 29

6.6 Performance of different algorithms for the special case of the taskoffloading profit maximization problem where delay requirements andsharing VNF instances are neglected . . . . . . . . . . . . . . . . . . . . . 30

6.7 Performance of algorithm Appro and algorithm Baseline for the spe-cial case of the task offloading profit maximization problem by chang-ing the network size from 10 to 300 . . . . . . . . . . . . . . . . . . . . . 31

1 Code artefact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 an example of simulation experiment . . . . . . . . . . . . . . . . . . . . 43

viii


List of Tables

3.1 Notations in the system model . . . . . . . . . . . . . . . . . . . . . . . . 10

ix


Chapter 1

Introduction

In this chapter, we first present the motivations of this project and the problem state-ment. We then describe the main contributions of this project. We finally state theoutline for this project.

1.1 Problem Statement and Motivations

The traditional 4G network is facing challenges with the exponential increase of datatraffic and a growing diversification of service scenarios, which promotes the arrivalof 5G era. The end-users of mobile network services are not only mobile phonesbut also tablet computers, mobile vehicles and various sensors in the 5G era. Be-sides, the emergence of 5G flourishes extensive new computing intensive applica-tions, including augmented reality (AR), virtual reality (VR), and Internet of Things(loT) scenarios, which require low latency [Pham et al., 2019]. However, limitedby computing and battery capacities, mobile devices are still cannot execute theseresource-intensive and latency-sensitive applications locally, which requires them tooffload the tasks to cloud servers for processing. However, the long distance betweenthe mobile device and the centralized cloud server leads to high transmission delay,which restricts the development of cloud computing on the mobile end [Sheng et al.,2015]. Cloud computing also has the drawbacks of high overhead, bandwidth short-age and lack of data privacy guarantee [Xiao et al., 2019].

Mobile Edge Computing (MEC) has emerged as a promising paradigm by combiningtelecommunication with cloud computing services at the edge of mobile networks toprovide computing and communication resources within radio access networks inthe close vicinity of mobile users [Patel et al., 2014]. Portable mobile devices of-fload intensive-computing tasks to nearby MEC servers via RAN, guaranteeing ashorter transmission delay compared with cloud computing. Therefore, MEC has awide application prospect in smart cities and smart connected vehicles [Taleb et al.,2017; Grewe et al., 2017]. The implementation of MEC is based on a virtualizedplatform which takes advantage of the latest advancements in Network FunctionsVirtualization (NFV). NFV enables network functions to be decoupled with dedi-cated hardware appliances and then deploys them as virtualized network function

1


2 Introduction

(VNF) instances on top of cloudlets, which saves the capital cost of service providers.In addition, NFV enables a single cloudlet to simultaneously provide different net-work function services to multiple mobile devices through consolidation of differentVirtualization Network Functions (VNFs) types in the MEC server [Hu et al., 2015].Besides, frequently demanded VNF instances usually are deployed on cloudlets inadvance to meet the needs of users with stringent QoS. And these existing idle VNFinstances can save time in the process of admitting a request.

However, due to the resource limitations of edge servers, the MEC servers can-not execute a massive amount of user requests synchronously. Network serviceproviders should determine how to assign user requests to cloudlets to maximizethe total profit of admitted requests with different latency requirements [Othmanet al., 2013]. This involves how to deploy demanded VNFs in cloudlets to ensurethe delay of admitted requests is within their corresponding delay requirements. Forexample, because of stringent latency requirements, required VNF instances of VRapplications should be implemented on nearby cloudlet. In contrast, VNFs of thelatency-tolerant applications, like social-chat applications, can be instantiated on aslightly remote server. Besides, considering that the energy cost and transmissioncost differs among cloudlets, the profit collected by the admission of a request isdependent on the assigned cloudlet. Moreover, when admitting a request, utilizingexisting VNF instances saves the time and cost since there is no need to create newVNF instances. Therefore, it is vital for network service providers to determine howto allocate computing resources of MEC servers to instantiate requested VNFs suchthat the accumulated profit of admitted requests is maximum.

1.2 Contributions

This project focus on the task offloading problem in MEC networks to maximize thetotal profit of network service providers. Firstly, we devise a novel task offloadingoptimization problem where each request needs one specific type of VNF and canshare existing VNF instances with other requests with the same type of VNF in onecloudlet within data processing capacity constraints. We formulate an Integer LinearProgramming (ILP) solution for the problem. As the proposed ILP solution is notscalable, we device an efficient heuristic algorithm for the problem. We further studytwo special cases of the problem and propose an approximation algorithm for thespecial case which neglects delay requirements and sharing VNF instances. Finally,the performance of the proposed algorithms is evaluated by empirical analysis.

1.3 Project Outline

The outline of this report is organised as follows. Chapter 2 introduces basic back-ground of Mobile Edge Computing and reviews the related work. Chapter 3 intro-duces notations, problem model and problem definition. Chapter 4 proposes an ILP


§1.3 Project Outline 3

formulation and an efficient heuristic algorithm for the problem. Chapter 5 stud-ies two special cases of the problem and proposes ILP solutions for the two specialcases, respectively. This chapter also devises an approximation algorithm for thespecial case without considering delay constraints and sharing VNF. Chapter 6 ana-lyzes the performance of the proposed algorithms by empirical analysis. Chapter 7summarizes the report and puts forward some future work directions.


Chapter 2

Background and Related Work

In this chapter, we first introduce the fundamental background of MEC, includingbasic architecture of MEC, advantages of MEC, main application scenarios for MECand Network Function Virtualization(NFV). Then we review the state-of-the-art re-lated works of task offloading problems in MEC networks.

2.1 Background

2.1.1 Fundamentals of MEC

The concept of MEC was proposed by the European Telecommunications StandardInstitute (ETSI) Industry Specification Group (ISG) as a new platform that extends thecloud-computing capabilities to the edge of network, within the radio access networkin the close vicinity of mobile users [Hu et al., 2015]. As shown in figure XX, thegeneral architecture of MEC can be mainly divided into three components, includingmobile devices, MEC servers and centralized cloud. MEC provides various typesof applications (such as video monitoring and analysis, customised applications andIoT-related services) to all kinds of mobile devices (including smartphones, tabletsand IoT devices) [Pham et al., 2019]. Satyanarayan et al. put forward the concept ofcloudlet in the three-tier architecture of MEC networks [Satyanarayanan et al., 2009].Cloudlet provides computing resources for nearby end-devices. Cloudlets can bedeployed at various locations collocated with the edge of RAN, such as base sta-tions (BS), radio network controller sites, and WiFi access points [Liu et al., 2018].Based on Virtual Machines (VM) technology, mobile users customize service soft-ware on nearby cloudlets and then use those cloudlet services througn WiFi to of-fload computation-intensive tasks [Satyanarayanan et al., 2009]. Because the MECserver has limited resources, some tasks can be sent to the cloud service center forprocessing.

Compared with cloud computing, MEC brings the following performance improve-ments:

4


§2.1 Background 5

Figure 2.1: General architecture of the MEC network [Pham et al., 2019]

1) Lower transmission latency: Compared with data centres in Cloud Computingnetwork that are tens of kilometres away from users, MEC servers are generally de-ployed within 1km of users. User requests are offloaded to the local MEC serversfor cloud processing, thereby reducing the time delay caused by data transmission,which meets the stringent Quality-of-Service (QoS) requirements of applications, likeAR and interactive online gaming.

2) Security enhancement: The centralized cloud server is more vulnerable to at-tack due to the high concentration of users’ data. Due to the high concentrationof user data, centralized cloud servers are more vulnerable to attacks. In contrast,MEC servers are not susceptible to attack because of distributed deployment andlow concentration of valuable data, which significantly reduces the risk of privacyinformation disclosure. MEC servers are less likely to be attacked due to distributeddeployment and low concentration of valuable data, which significantly reduces therisk of privacy information leakage [Mao et al., 2017].

By deploying cloud resources at the edge of the RAN, MEC is a promising technologyto support the innovative applications with stringent QoS requirements. In the fol-lowing section, we introduce the main applications of MEC, and analyzes their appli-cation value in these scenarios. Computation-intensive applications: Computation-intensive applications require massive calculations in a short period of time, so the


6 Background and Related Work

resource-limited mobile devices cannot execute these applications by themselves. Byways of offloading computation tasks, end users can use computation resources ofMEC servers to execute computation-intensive applications. For instance, Both ARand VR need heavy computation resources to process real-time data about user po-sition and orientation within low latency time. However, executing AR/VR appli-cations is restricted by computation capability and battery power of mobile devices.MEC is an ideal solution to support AR / VR application that combines computerproduced data with physical reality [Al-Shuwaili and Simeone, 2017]. When the VRcontrol centre is deployed on cloudlets, tracking accuracy can be improved, withthe 1-ms round trip delay and high reliability. [Chen et al., 2018]. Thus, offloadingcomputation-intensive tasks to cloudlets in MEC networks can leverage the compu-tation capacity of VR devices significantly, as well as extending their battery life.

2.1.2 Network Function Virtualization

NFV is a new network architecture framework where network functions that wereexecuted by specialized hardware (middleboxes or network appliances) are now im-plemented in software that runs on commodity servers [Herrera and Botero, 2016].The traditional deployment of a network function requires to install dedicated hard-ware, which is time-consuming and costly. Moreover, the use of middleboxes doesnot support adding new functionality; therefore, new specialized hardware shouldbe designed when adding new functions. NFV is an envisioned paradigm to solvethe shortcomings of hardware appliances because hardware appliances are replacedby software running in virtualized machines. NFV significantly reduces capital ex-penditures and operating expenditures of network service providers as it avoids thephysical deployment and update of network hardware. Thus, NFV facilitates therapid development and flexible deployment of new network service to meet rapid-changing user requests. Through virtualization technology, NFV decouples network

Figure 2.2: NFV environment [Herrera and Botero, 2016]


§2.2 Related work 7

functions (e.g. firewall, load balancer, and packet inspector) from proprietary hard-ware and deploys them as VNFs into servers, which may be located in data centresand network nodes (see Fig 2.2) [ETSI, 2013]. Under the NFV paradigm, a networkservice (NS) is composed of chained VNFs (see Fig 2.3).

In the MEC network, NFV is a vital technology for deploying the virtualized in-stances corresponding to certain network services. Upon receiving an NS request,Telecom Service Provider(TSP) allocates computation resources to implement re-quested VNFs instances on top of MEC cloudlets to handle the QoS of the end-users’requests. One MEC cloudlet can supply network services to many users by creatingvarious Virtual Machines (VMs) for operating network functions as instances of VNFin NFV environment [Zhang et al., 2017a]. Moreover, NFV enables flexibility, scala-bility and migration of network services [Mijumbi et al., 2016]. For example, withinthe MEC platform, we can easily increase the resources of popular applications bycreating another VFN instance.

Figure 2.3: NFV environment

2.2 Related work

There are extensive works conducted on NFV-enabled task offloading in MEC net-works [Wu, 2018; Zhang et al., 2016]. Jia et al. studied the cloudlet workload bal-ancing problem and devised a scalable algorithm to minimize the maximum aver-age response times of tasks at cloudlets in MEC networks [Jia et al., 2016]. Yanget al. investigated the placement and scheduling problem of VNF with delay andresiliency concerns in the MEC network [Yang et al., 2019]. They proposed an ex-act INLP soluition and a near-optimal heuristic algorithm for the problem. Li et al.proposed two efficient online algorithms for the reliability-aware VNF provisioningproblem under onsite and offsite schemes, aiming to maximize the revenue of admit-ted requests [Li et al., 2020]. Li et al. studied a delay-sensitive service chain routingproblem that maximizes the throughput in the NFV environment. Specifically, theydevised a scalable heuristic algorithm by relaxing the LP model [Li et al., 2016].However, these work allocated dedicated VNF instances to user requests and did notconsider sharing computing resources in VNF instances, resulting in the underuti-lization of computing resources. Xu et al. explored a novel throughput maximization


8 Background and Related Work

problem, considering the sharing of existing VNF instances [Xu et al., 2019]. Theyproposed an online algorithm by the reduction to a series of minimum weight maxi-mum matching problems.

And several recent studies have focused on profit maximization problem in the NFVenvironment. Zhang et al. designed the online stochastic auction mechanism tohandle the issues of VNF service provisioning and pricing [Zhang et al., 2017b].They proposed a learning-based online primal-dual algorithm to achieve the opti-mal public welfare among customers and NFV service providers. Ma et al. ex-plored a dynamic task offloading problem with delay-aware service function chainfor distributed data centres to maximize the accumulated profit of network serviceproviders [Ma et al., 2019]. They considered the difference in electricity prices amongdata centres and devised an online heuristic algorithm. Racheg et al. investigatedfor VNF chains routing problem to maximize the total profit of admitted requests.A heuristic algorithm is devised to enumerate all possible paths of admitting userrequests. Thus, in the real world, their algorithm is not applicable to large-scaleproblems. [Racheg et al., 2017]. However, these studies did not consider that re-quests share the computing resources of VNF instances in MEC networks. And theydid not attempt to utilise existing VNF instances in MEC networks. In the real world,frequently demanded VNF instances usually are deployed on cloudlets in advanceto meet the needs of users with stringent QoS. In our project, we investigate theprofit optimization problem with sharing VNF instances in the MEC network wherecloudlets have existing VNF instances.

2.3 Summary

This chapter introduced the general background of the project, including componentsin MEC networks, benefits of MEC and NFV. This chapter also presented severalrelated studies and mentioned the distinction of our project.


Chapter 3

Preliminaries

In this chapter, we first introduce the system model and notations of the MEC net-work. We then describe the definition of sharing VNF instances. We propose thedelay model and cost model of admitted requests in the MEC network, respectively.Finallywe give a precise definition of the problem.

3.1 System Model

We use an undirected graph G = (V ∪ C, E) to represent a MEC network, where Vis the set of APs deployed at multiple sites, C is the set of cloudlets, and E is theset of links that connect APs. Each cloudlet is next to an AP, but some APs have noco-located cloudlets.

Each cloudlet is co-located with an AP, and not all APs have co-located cloudlets.Each cloudlet in the MEC network is co-located with an, but not every AP is co-located with an cloudlet. Each cloudlet cj ∈ C has a computing capability capj forimplementing VNF instances with 1 ≤ j ≤ |C|, where |C| is the cardinality of set C.Each link e ∈ E is associated bandwidth Be. We assume users access MEC networksthrough adjacent AP nodes.

The MEC network provides network function services by creating multiple instancesof VNFs in cloudlets. We use F = { f1, f2, ..., f|F|} to denote the set of VNFs offeredby the MEC network G, e.g., firewall or load balancer, with 1 ≤ k ≤ |F|. fk refers toa type-k of VNF in F. We assume the computing resources for instantiating differentVNFs are different in cloudlets. Without loss of generality, we use c( fk,j) to denotethe computing capacity demanded to create an instance of VNF fk in the cloudletcj, which ensures the maximal packet processing rate µk,j in the cloudlet cj. We useCunit to represent the computing resource of unit packet rate, then c( fk,j) is calculatedby µk,j × Cunit. If the remaining computing capacity in one cloudlet cj is larger thanc( fk,j), the cloudlet cj can initialize a new instance of VNF fk. Furthermore, wesuppose that cloudlets have instantiated several VNF instances of some VNF types.We use inik,j to represent the number of existing instances of VNF fk in cloudlet cj.Fig 3.1 is a schematic diagram of the MEC network.

9


10 Preliminaries

Notation Description

G = (V∪ C, E)An MEC network G with AP node set V, cloudletnode set Cand link set E

F The set of VNFs offered by the MEC network Gcapj Computing capacity of the cloudlet cj

c( fk,j)Computing capacity demand of an instance ofVNF fkin the cloudlet cj

µk,j Maximal packet processing rate of a fk VNF instanceQ A set of user requests

inik,jThe number of existing instances of VNF fk incloudlet cj

ri = (vi, ρi, bi, fi, τi, di, payi)

A request r, where vi represents the user’s closestAP, ρi denotes data packet rate, bi means therequested network transmitting rate, fi meansthe requested type of VNF, τi denotes the duration ofrequest, di indicates the requested end-to-end delay,payi is the revenue

pi,jProcessing delay if request ri is processed bycloudlet cj

ti,jTransmission delay if request ri is processed bycloudlet cj

ok Instantiation delay of VNF fk

cproc(i, j)Processing cost if request ri is processed bycloudlet cj

ctrans(i, j)Packet routing cost if request ri is processed bycloudlet cj

cins(i) Cost of instantiating a new instance of VNF fi

Xi,jA binary variable, where Xi,j implies that request riis admitted to be assigned to cloudlet cj

mi,j

A binary variable, where mi,j implies that theadmission of request ri requires to create VNFinstances of fi on the cloudlet cj

Yi,j

An integer variable, where Yi,j the number of newcreated VNF instances to admit the request ri onthe cloudlet cj

Table 3.1: Notations in the system model


§3.2 User Requests and Shared VNF Instances 11

Figure 3.1: An instance of an MEC network

3.2 User Requests and Shared VNF Instances

Let Q = {r1, r2, ..., r|Q|} represent a set of user requests in the MEC network G. Weassume that a user request demands unique type of VNF. And each request ri isdenoted by a tuple (vi, ρi, bi, fi, τi, di, payi), where vi represents the user’s closest AP,ρi denotes the data packet rate, bi means the requested network transmitting rate, fistands for the requested type of VNF, τi denotes the duration of request, di indicatesthe requested end-to-end delay, payi is the revenue by implementing the request. Weassume data packet of each request is assigned to a single cloudlet.

We consider that multiple user requests with the same VNF type can share the pro-cessing capacity of VNF instances if the total occupied packet rate is within the maxi-mum processing capacity of the VNF instances without violating the delay constraintof any admitted request. If the remaining processing capacity of the existing VNFinstance is less than ρi for the request ri, ri cannot join in the existing VNF instance.And if the available computing capacity in one cloudlet cj is larger than c( fi,j), thecloudlet can initialize new instances of VNF fi to admit the request ri.

3.3 Offloading Request Delay Modeling

The total end-to-end delay of a request ri(vi, ρi, bi, fi, τi, di, payi) includes three parts:network transmission delay, VNF processing delay and instantiation delay for creat-ing new VNF instances. pi,j denotes the required time for processing the request ri


12 Preliminaries

on cloudlet cj ∈ C, calculated as:

pk,j =1

µi,j(3.1)

The delay on a link e ∈ E for a request ri is calculated as:

ρi

bi× θ(e) (3.2)

where θ(e) reflects the factors that influence transmission delay, such as link distance.We assume the routing path between the user request ri and the cloudlet cj processingthe request is the shortest path between them, denoted by pvi ,cj . Then the networktransmission delay for ri, denoted by ti,j is calculated as:

ti,j = ∑e∈spvi ,cj

ρi

bi× θ(e) (3.3)

Without loss of generality, we assume the instantiation delays of different VNFs aredifferent and the instantiation delay of VNF fk is same among all cloudlets cj ∈ C.We use ok to represent instantiation delay of VNF fk. If offloading request ri requirescreate new instances of VNF fi in the cloudlet cj, the delay for the offloading requestri is calculated as follows:

Di,j = pi,j + ti,j + oi (3.4)

If the request ri joins in other admitted requests to share existing VNF instance, thetotal end-to-end delay for ri is calculated as follows:

Di,j = pi,j + ti,j (3.5)

To admit a user request ri processed by the cloudlet cj, the delay of ri should be nomore than di.

Di,j ≤ di (3.6)

3.4 Cost and Profit by Admitted Requests

The admission cost of a request ri = (vi, ρi, bi, fi, τi, di, payi) is composed of threeparts: VNF instance processing cost, packet routing cost and VNF instance instan-tiation cost. We use ηk,j to denote the cost of processing a unit packet rate by aninstance of VNF fk in the cloudlet cj. The processing cost of the request ri is denotedby cproc(i, j), calculated as:

cproc(i, j) = τi × ρi × ηi,j (3.7)

We denote the packet routing cost of the request ri as ctrans(i, j), calculated as:

ctrans(i, j) = τi × ρi × ∑e∈spvi ,cj

ce (3.8)


§3.5 Problem definition 13

where ce represents the unit transmission cost on link e ∈ E, and spvi ,cj is the shortestdelay path between the cloudlet cj and the access point location of request ri. Whenwe ignore the delay requirement of the request, the shortest path spvi ,cj is calculatedby taking ce as the path side length. We use cins(i) to indicate the cost of instantiatinga new instance of VNF fi. If the admission of request ri is implemented by creatingYi,j new instances of VNF fi in the cloudlet cj, the admission cost of ri is calculated:

costi,j = cproc(i, j) + ctrans(i, j) + cins(i)×Yi,j (3.9)

If the admission of request ri is implemented by only using existing VNF instancesof fi in a cloudlet cj, the admission cost ofri is calculated as follows:

costi,j = cproc(i, j) + ctrans(i, j) (3.10)

We assume the revenue obtained by admitting the request ri is directly proportionalto its demanded bandwidth and computing resources, calculated as follows:

paymenti = λ1 × ρi ×U( fi) + λ2 × bi (3.11)

where λ1 and λ2 denote the weight coefficients in computing and bandwidth prices,U( fi) is the demanded computing resource of the unit packet rate for type-i VNFfi ∈ F.Then the profit obtained by admitting a request ri in the cloudlet cj is calculated asfollows:

pro f iti,j = paymenti − costi,j (3.12)

Thus, the total profit p(A) obtained by accepting a set of requests A is the sum ofprofit of each request ri in A, which is defined:

p(A) = ∑ri∈A

pro f iti,j (3.13)

where the request ri ∈ A is admitted to be assigned on cloudlet cj.

3.5 Problem definition

Given a MEC network G = (V ∪ C, E), a set of network functions F, a set of userrequests Q = {r1, r2, ..., r|Q|}, and several instances of VNF fk ∈ F have been createdin each cloudlet cj ∈ C. We assume that each request ri demands a specific networkfunction fk ∈ F and has a data packet rate ρi, network transmitting rate bi, delayrequirement di and a payment payi. The admission of a request ri can occur whenthere is one cloudlet that can provide enough computing resource to implement itsrequired VNF instances within its delay constraint. We assume requests can sharethe VNF instances in one cloudlet with other requests requiring the same VNF if thetotal packet rate of admitted requests is within the maximal processing capacity ofVNF instances. The task offloading profit maximization problem is to maximize the


14 Preliminaries

total profit of the admitted requests, subject to computing capacity on each cloudletin G.

Theorem 1. The task offloading profit maximization problem in the MEC network G = (V ∪C, E) is NP-hard.

Proof. We prove the NP-hardness of the task offloading profit maximization problemby reducing the problem to the knapsack problem. Given a set of items I and a binwith a weight capacity W, and each item i ∈ I has a profit pi and a weight wi,the knapsack problem is to determine a collection of items with the maximum totalprofit and the total weight does not exceed W. We suppose one special case of thetask offloading profit maximization problem where there is only one cloudlet cj inthe network, and each request ri ∈ Q demands a distinct network function withoutdelay requirement. If the request ri is assigned to the cloudlet cj, we need to created ρi

µi,je VNF instances of fi at the cost of computing resource d ρi

µi,je · c( fi,j), and we

can obtain the profit pro f iti,j. The task offloading profit maximization problem is tomaximize the total profit of admitted requests, constrained by the cloudlet capacity.We can see that the special case of the task offloading profit maximization problem isequivalent to the knapsack problem. As the knapsack problem is NP-hard, the taskoffloading profit maximization problem is NP-hard, too.

3.6 Summary

Firstly, we illustrated the system model of the project, and then we described a delaymodel and cost model of admitted request. Finally, we defined the task offloadingprofit maximization problem precisely.


Chapter 4

Algorithms for the task offloadingprofit maximization problem

In this chapter, we investigate the task offloading profit maximization problem whererequests requiring the same type of VNF can share VNF instances in the MEC net-work with existing VNF instances. In the following we first formulate an integerlinear programming (ILP) for the problem. We then propose an heuristic algorithmfor the problem.

4.1 ILP Formulation

The task offloading profit maximization problem can be formulated as an ILP. LetQ, C, F denote a set of user requests, cloudlets and network functions offered by theMEC network G, respectively. For each request ri ∈ Q and each cloudlet cj ∈ C with1 ≤ i ≤ |Q|, and 1 ≤ j ≤ |C|, there is binary variable Xi,j where Xi,j returns 1 if therequest ri is admitted to be assigned to the cloudlet cj; and 0 otherwise. Auxiliaryvariable mi,j ∈ 0, 1 returns 1 if the admission of request ri requires to create VNFinstances of fi on the cloudlet cj, and 0 otherwise. Furthermore, integer variable Yi,jindicates the number of new created VNF instances to admit the request ri on thecloudlet cj, and the value range of Yi,j is in {0, 1, .., d ρi

µi,je}. Recall that inik,j indicates

the existing instances of VNF fk in cloudlet cj; c( fi,j) denotes the computing resourceof implement an instance of VNF fi on the cloudlet cj; µi,j denotes the processingpacket of an instance of VNF fi on the cloudlet cj; and oi represents the instantiationdelay of VNF fi. The admit of request ri can occupy existing VNF instances if thepacket rate ρi is no greater than the remaining processing capacity of existing VNFinstances. Otherwise, the cloudlet cj can initialize Yi,j new instances of VNF fi toadmit the request ri if the available computing capacity of the cloudlet cj is no lessthan Yi,j · c( fi,j). The objective of the ILP thus is

max ∑ri∈Q

∑cj∈C

pro f iti,jXi,j (4.1)

15


16 Algorithms for the task offloading profit maximization problem

subject to∑

ri∈QρiXi,j ≤ ∑

ri∈Qµi,jYi,j + µk,jinik,j, ∀cj ∈ C, ∀ fk ∈ F (4.2)

∑ri∈Q

c( fi,j)Yi,j ≤ capj − ∑fk∈F

c( fk,j)inik,j, ∀cj ∈ C (4.3)

∑cj∈C

Xi,j ≤ 1, ∀ri ∈ Q (4.4)

(pi,j + ti,j)Xi,j + oimi,j ≤ di, ∀ri ∈ Q, cj ∈ C (4.5)

mi,j ≥1d ρi

µi,je

Yi,j, ∀cj ∈ C, ∀ri ∈ Q (4.6)

Xi,j ≥1d ρi

µi,je

Yi,j, ∀cj ∈ C, ∀ri ∈ Q (4.7)

Xi,j ≥ mi,j ∀cj ∈ C, ∀ri ∈ Q (4.8)

Xi,j ∈ {0, 1}, ∀cj ∈ C, ∀ri ∈ Q (4.9)

mi,j ∈ {0, 1}, ∀cj ∈ C, ∀ri ∈ Q (4.10)

Yi,j ∈ {0, 1, .., d ρi

µi,je}, ∀cj ∈ C, ∀ri ∈ Q (4.11)

• Constraint 4.2 ensures that aggregate packet rate of the requests with sameVNF type assigned to an cloudlet does not exceed the total packet rate of thistype of VNF instances.

• Constraint 4.3 guarantees that total computing resource allocated to VNF in-stances is no greater than the computing capacity of each cloudlet.

• Constraint 4.4 indicates that each user request is assigned to at most one cloudlet.

• Constraint 4.5 ensures that the delay of each admited request does not violateits delay constraint.

• Constraint 4.6 ensures if the number of newly created VNF instance of fi on thethe cloudlet cj is larger than 0, the admission of the request ri on the cloudlet cjrequires the instantiation of VNF instance.

• Constraint 4.7 ensures if the number of newly created VNF instance of fi onthe the cloudlet cj is larger than 0, the request ri is assigned to the cloudlet cj.

• Constraint 4.8 ensures if the admission of the request ri on the cloudlet cjrequires the instantiation of VNF instance, the request ri is assigned to thecloudlet cj.


§4.2 Greedy algorithm 17

• Constraint 4.9 and Constraint 4.10 restrict the ranges of boolean variables Xi,j,mi,j to {0, 1}.

• Constraint 4.11 restricts the ranges of integer variables Yi,j to {0, 1, .., d ρiµi,je}.

4.2 Greedy algorithm

We then propose a greedy algorithm for the task offloading profit maximization prob-lem, which proceeds iteratively. The definition of the profit-resource ratio is the ratioof the profit of admitting the request to the amount of computing resource occupiedby the request in the MEC network. Because the required computing resource toimplementing an instance of the same type of VNF varies in different cloudlets, theprofit-resource ratio also differs among cloudlets. The basic idea of this proposedalgorithm is to sort the requests in decreasing order of the profit-resource ratio andthen assign each request to the corresponding cloudlet that obtains the maximumprofit-resource ratio until there is no available computing resource on each cloudlet.We denote A as the set of requests that have not been admitted in previous iterations.While there are requests that may be admitted, for each request ri ∈ A, we calculatethe profit of assigning ri to each cloudlet cj under its delay requirement and recordthe maximum profit-resource ratio p(ri) and corresponding cloudlet cmax. When cal-culating the cost of request ri, we give priority to sharing existing VNF instances inthe cloudlets. We then identify the highest-rank request in A by the profit-resourceratio, demoted by r1. We examine the highest-rank request r1 to determine if therequest can be admitted. The request is admitted if the profit of the request is greaterthan 0 and there are enough computing resource in the corresponding cloudlet withthe maximum profit-resource ratio. Then we update the residual computing capacityof the corresponding cloudlet and remove the requestr1 from A. When the profit ofhighest-rank request r1 is no greater than 0, the algorithm terminates. Further detailof the algorithm can be found in Algorithm 1.

4.3 Algorithm analysis

Theorem 2. Given a MEC network G = (V ∪ C, E), a set of network functions F, a setof user requests Q = {r1, r2, ..., r|Q|}, there is an algorithm, Algorithm 1, for the taskoffloading profit maximization problem, which delivers a feasible solution. And Algorithm 1takes O(|Q|2 · |C|) time.

Proof. Algorithm 1 delivers a feasible solution because every admitted request rimeets its delay requirement and the accumulated packet rate of all admitted requestswith the VNF type fi is within the maximal processing capacity of the VNF instancesfi. Besides, the assigned cloudlet cj has adequate computing resource to deploy therequired VNF instances for the request ri. Hence, the solution of Algorithm 1 isfeasible.


18 Algorithms for the task offloading profit maximization problem

Algorithm 1 Greedy algorithm for the task offloading profit maximization problemInput: a MEC network G = (V ∪ C, E), a set of network functions F, a set of user

requests Q, for ri ∈ Q, ri = (vi, ρi, bi, fi, τi, di, payi)Output: Admit a subset of requests in Q that maximizes the total profit of admitted

requests1: A← Q /* the set of to be admitted requests */;2: pro f it← 0;3: while A! = ∅ do4: for all each request ri ∈ A do5: Calculate the profit of assigning the request ri to each cloudlet cj ∈ C by

Eq 3.13 and identify the cloudlet cmax with the maximum profit-resourceratio without violating its delay constraint, and record the correspondingprofit p(ri);

6: end for7: Identify the highest-rank request r1 in A by the maximum profit-resource ratio.

8: if p(r1) > 0 then9: if There is enough computing resource in the corresponding cloudlet cmax

with the max profit to admit the request r1 then10: Allocate VNF instances of the request r1 to the cloudlet cmax , update the

residual computing capacity of the cloudlet cmax;11: pro f it← pro f it + p(r1); A← A\{r1};12: end if13: else

break14: end if15: for all each request ri ∈ A do16: if each cloudlet cj ∈ C has no enough computing resource to admit ri then17: A← A\{ri};18: end if19: end for20: end while21: return pro f it is the total profit of admitted requests.


§4.4 Summary 19

The time complexity of Algorithm 1 is analyzed as follows. In each iteration, therunning time of admitting a request is dominated by calculating the profit of assign-ing each unadmitted request ri to each cloudlet cj ∈ C under the delay constraint,which takes O(|Q| · |C|) time. Recording the request with the maximum profit takesO(|Q|) time. The updating of variables takes O(1) time. Because there are at most|Q| iterations, Algorithm 1 takes O(|Q|2 · |C|) time.

4.4 Summary

This chapter first devised an ILP solution and an efficient heuristic algorithm forthe task offloading profit maximization problem. Then the analysis of the heuristicalgorithm was presented.


Chapter 5

Algorithms for special taskoffloading profit maximizationproblems

In this charper, We further study two special cases of the task offloading profit max-imization problem, one is the problem without sharing VNF instances, and anotheris the problem without delay and sharing VNF instances.

5.1 Task offloading profit maximization problem without shar-ing VNF instances

Considering that sharing VNF instances may lead to the disclosure of privacy data,user requests with high privacy security prefer to be processed by dedicated VNFinstances without sharing with others. We investigate the task offloading profit max-imization problem without sharing VNF instances. We first formulate an ILP for theproblem. We then propose an heuristic algorithm for the problem.

5.1.1 Integer Linear Programming Formulation

The task offloading profit maximization problem without sharing VNF instances canbe formulated as an ILP as follows. Let binary variable Xi,j indicate whether therequest ri is assigned to the cloudlet cj, Xi,j returns 1 if the request ri is admittedto be assigned to the cloudlet cj; and 0 otherwise. Let auxiliary variable mi,j ∈ 0, 1returns 1 if the admission of request ri requires to create VNF instances of fi on thecloudlet cj, and 0 otherwise. Furthermore, integer variable Yi,j indicates the numberof new created VNF instances to admit the request ri on the cloudlet cj, and the valuerange of Yi,j is in {0, 1, .., d ρi

µi,je}. As each admitted request ri occupies dedicated VNF

instances, the cloudlet cj needs to implement d ρiµi,je VNF instances of fi to process

request ri. If the existing idle instances of VNF fi on the cloudlet cj is no less thand ρi

µi,je, there is no need to create new VNF instances to assign the request ri on the

cloudlet cj. Otherwise, if the available computing capacity of the cloudlet cj is no

20


§5.1 Task offloading profit maximization problem without sharing VNF instances 21

less than Yi,j · c( fi,j), we can instantiate Yi,j instances of VNF fi to admit the requestri. The objective of the ILP thus is

max ∑ri∈Q

∑cj∈C


subject to

∑ri∈Q

c( fi,j)dρi

µi,jeXi,j − ∑

ri∈Qc( fi,j)Yi,j ≤ c( fk,j)inik,j, ∀cj ∈ C, ∀ fk ∈ F (5.2)

∑ri∈Q

c( fi,j)dρi

µi,jeXi,j ≤ capj, ∀cj ∈ C (5.3)

∑cj∈C

Xi,j ≤ 1, ∀ri ∈ Q (5.4)

(pi,j + ti,j)Xi,j + oimi,j ≤ di, ∀ri ∈ Q, cj ∈ C (5.5)

mi,j ≥1d ρi

µi,je

Yi,j, ∀cj ∈ C, ∀ri ∈ Q (5.6)

Xi,j ≥1d ρi

µi,je

Yi,j, ∀cj ∈ C, ∀ri ∈ Q (5.7)

Xi,j ≥ mi,j ∀cj ∈ C, ∀ri ∈ Q (5.8)

Xi,j ∈ {0, 1}, ∀cj ∈ C, ∀ri ∈ Q (5.9)

mi,j ∈ {0, 1}, ∀cj ∈ C, ∀ri ∈ Q (5.10)

Yi,j ∈ {0, 1, .., d ρi

µi,je}, ∀cj ∈ C, ∀ri ∈ Q (5.11)

• Constraint 5.2 ensures that total computing resource allocated to one type ofVNF instances is equal to the sum of computing resource occupied by the ex-isting VNF instances and newly created VNF instances in each cloudlet.

• Constraint 5.3 indicates that total computing resource allocated to VNF in-stances is no greater than the computing capacity of each cloudlet.

• Constraint 5.4 guarantees that each user request is assigned to at most onecloudlet.

• Constraint 5.5 guarantees the delay of each admited request does not violate itsdelay constraint.

• Constraint 5.6 ensures if the number of newly created VNF instance of fi on the


22 Algorithms for special task offloading profit maximization problems

the cloudlet cj is larger than 0, the admission of the request ri on the cloudlet cjrequires the instantiation of VNF instance.

• Constraint 5.7 ensures if the number of newly created VNF instance of fi onthe the cloudlet cj is larger than 0, the request ri is assigned to the cloudlet cj.

• Constraint 5.9 and Constraint 5.10 restrict the ranges of boolean variables Xi,j,mi,j to {0, 1}.

• Constraint 5.11 limits the ranges of integer variables Yi,j to {0, 1, .., d ρiµi,je}.

5.1.2 Greedy algorithm

We use Algorithm 1 proposed in 4.2 for the task offloading profit maximizationproblem without sharing VNF instances. The only modification is that the admissionof request ri needs to implement dedicated d ρi

µi,je instances of VNF fi on the cloudlet.

Hence, when calculating the cost of each request, the VNF instance instantiation costis larger.

5.2 Task offloading profit maximization problem without de-lay and sharing VNF instances

We explore one special case of the problem, which neglects the delay constraints anddo not share VNF instances among user requests. And no existing VNF instances arecreated in cloudlets. We propose an ILP solution and an approximation algorithmfor the problem.

5.2.1 ILP

The task offloading profit maximization problem without delay and sharing VNFinstances can be formulated as an ILP. We assume binary variable Xi,j, where Xi,jreturns 1 if the request ri is admitted to be assigned on cloudlet cj, and 0 otherwise.Besides, the admission of request ri requires that the cloudlet cj has the availablecomputing resource to create d ρi

µi,je instances of VNF fi. The optimization objective is

max ∑ri∈Q

∑cj∈C


subject to

∑ri∈Q

c( fi,j)dρi

µi,jeXi,j ≤ capj, ∀cj ∈ C (5.13)

∑cj∈C

Xi,j ≤ 1, ∀ri ∈ Q (5.14)

Xi,j ∈ {0, 1}, ∀cj ∈ C, ∀ri ∈ Q (5.15)


§5.2 Task offloading profit maximization problem without delay and sharing VNF instances23

• Constraint 5.13 ensures that total computing resource allocated to VNF in-stances does not exceed the computing capacity of each cloudlet.

• Constraint 5.14 ensures that each user request is assigned to at most one cloudlet.

• Constraint 5.15 restricts the ranges of boolean variables Xi,j to to {0, 1}.

5.2.2 Approximation algorithm

We devise an approximation algorithm by reducing the problem to the generalizedassignment problem (GAP). The definition of GAP is introduced in the following. Band M denote a set of bins and a set of items respectively. Each bin Bj ∈ B has thecapacity cap(Bj). For each item Ii ∈ S, a profit p(Ii, Bj) is gained if we pack the itemIi in bin Bj with a size s(Ii, Bj). The objective of GAP is to find a subset of items in Spacked in B with the maximal total profit, subject to the capacity of each bin.

Given an instance of the special case of the problem, we construct an instance ofthe GAP. Each request ri ∈ Q corresponds to an item Ii and each cloudlet cj ∈ Ccorresponds to a bin Bj. And each bin has the bin capacity cap(Bj) = capj. For eachIi ∈ S and each Bj ∈ B, the size of placing item Ii in bin Bj is s(Ii, Bj), calculated asfollows:

s(Ii, Bj) = c( fi,j)× dρi

µi,je (5.16)

representing the demanded computing resource to assign the VNF instances of re-quest ri on the cloudlet cj. If this placement is feasible, the profit of this placement isdenoted by p(Ii, Bj), calculated as follows:

p(Ii, Bj) =

{0 i f pro f iti,j ≤ 0pro f iti,j else

(5.17)

where pro f iti,j is calculated by Eq 3.13.Then we can solve the constructed GAP instance by using the approximation algo-rithm proposed by Cohen et al [Cohen et al., 2006]. The algorithm detail is given inAlgorithm 2.

5.2.3 Algorithm analysis

Theorem 3. Given a MEC network G = (V ∪ C, E), a set of network functions F, a set ofuser requests Q = {r1, r2, ..., r|Q|}, there is an approximation algorithm, Algorithm 2, withan approximation ratio of (2+ ε) for the task offloading profit maximization problem withoutdelay and sharing VNF instances. And Algorithm 2 takes O(|Q| · |C| log 1

ε +|C|ε4 ) time,

where ε is a constant with 0 ≤ ε ≤ 1.


24 Algorithms for special task offloading profit maximization problems

Algorithm 2 Approximation algorithm for the special case of the problem whichneglects delay constrains and sharing VNF instancesInput: a MEC network G = (V ∪ C, E), a set of network functions F, a set of user

requests Q, for ri ∈ Q, ri = (vi, ρi, bi, fi, τi, payi)Output: Admit a subset of requests in Q that maximizes the total profit of admitted

requests1: A← Q /* the set of to be admitted requests */;2: pro f it← 0;3: Construct an instance of the GAP, where each request ri ∈ Q corresponds to an

item Ii and each cloudlet cj ∈ C corresponds to a bin Bj, and each bin has the bincapacity cap(Bj) = capj;

4: Get an approximate solution L to the GAP problem by using the approximationalgorithm proposed by Cohen et al. [Cohen et al., 2006];

5: return the total profit of admitted requests in the approximate solution L.

Proof. We first show Algorithm 2 delivers a feasible solution. The capacity of eachbin corresponds to the computing capacity of each cloudlet, and the size s(Ii, Bj) ofpacking item Ii in bin Bj is equal to the required computing resource c( fi,j)× d ρi

µi,je.

Thus, the solution of the GAP problem will not violate the capacity constraint oneach cloudlet.

The running time of Algorithm 2 is analyzed in the following. It takes O(|Q| · |C|)time to construct the GAP instance. And using the (2 + ε)-approximation algorithmtakes O(|Q| · |C| log 1

ε +|C|ε4 ) time [Cohen et al., 2006]. Hence, the running time of

Algorithm 2 is O(|Q| · |C| log 1ε +

|C|ε4 ).

5.3 Summary

In summary, we devised ILP solutions for two special cases of task offloading profitmaximization problem. Then we proposed an approximation algorithm for the spe-cial case of task offloading problem where the delay constraints and sharing VNFinstances are neglected.


Chapter 6

Evaluation

This chapter presents the performance of the proposed algorithms for the task of-floading profit maximization problem by experimental simulations.

6.1 Experiment settings

We consider an MEC network G = (V ∪ C, E) consisting of from 10 to 300 APs. Andwe assume only 10% of APs have an co-located cloudlet. The computing capacity ofeach cloudlet varies from 3,000 MHz to 6,000 MHz [Jia et al., 2017]. The processingcost of unit packet rate of each cloudlet is randomly drawn from [0.1, 10] Ma et al.[2019]. We assume that the network service provider offers 10 types of VNFs in theMEC network, i.e., |F| = 10. The computing resource demanded implementationone type of VNF instance on one cloudlet is randomly generated from 60 MHz to600 MHz, while the processing rate of one type of VNF on one cloudlet is randomlygenerated from 2 to 100 data packets per millisecond. And the cost of instantiatingan instance of each type of VNF on one cloudlet is randomly drawn from [2, 5]. Thetransmission delay of each link is set from 3 milliseconds to 5 milliseconds, and thetransmission cost of the unit packet rate along each link is randomly drawn from[0.05, 0.12]. For each request ri = (vi, ρi, bi, fi, τi, payi) ∈ Q, one node vi ∈ V inG is randomly selected as its closest AP, and its required VNF type fi ∈ F is ran-domly generated from the provided 10 types of VNFs. The data packet rate ρi ofeach request ri is randomly generated from 2 to 20 packets per millisecond while itsrequested network transmitting rate is in the range of [50, 100] Li et al. [2016]. Thedelay requirement of each request varies from 50 milliseconds to 200 milliseconds.The range of two constant weights for computing λ1 and bandwidth pricesλ2 is [0.7,0.8] and [0.3, 0.4] respectively The value in each graph is the average of the resultsof 20 MEC network with the same size. The running time of the algorithm is accom-plished by a computer with a 1.9 GHz Intel i7 quad-core CPU and 16GB RAM.

In the following analysis, we compare the performance of proposed Algorithm 1,Algorithm 2 against the correspondingILP solution when the problem scale is small,and against a Baseline heuristic algorithm when the size of the problem is scalable.Baseline heuristic algorithm examines requests one by one. The admission condi-

25


26 Evaluation

tions of a request are: 1) there is a cloudlet that has available computing resource todeploy its required VNF instances without violating its delay constraint; 2) the corre-sponding profit of assigning the request to the cloudlet is greater than 0. And if thereare multiple cloudlets satisfy the admission conditions, we choose the cloudlet wherethe admission of the request obtains the maximum profit. We refer to Algorithm 1,Algorithm 2, ILP solution and the Baseline heuristic algorithm as Greedyprofit,Appro, ILP, and Baseline, respectively.

6.2 Algorithm performance for the task offloading profit max-imization problem

Firstly, we present the performance analysis for the proposed heuristic algorithmGreedyprofit and the optimal solution of theILP by setting the the amount of APs at50 and changing the number of requests from 100 to 1,000. And in each cloudlet, wecreate a random number of VNF instances for the offered VNFs. Because algorithmILP takes long running time and cannot get the exact solution within a reasonabletime, we use the upper bound of ILP solution within 0.5% gap to compare with theresult delivered by algorithm Greedyprofit. Fig 6.1 depicts the accumulated profitof algorithm Greedyprofit and the upper bound of algorithm ILP. We can see theaccumulated profit delivered by algorithm Greedyprofit achieves 92.9 percent ofthe upper bound of the optimal solution by algorithm ILP when the amount of re-quest is 600. As the upper bound is greater than the exact solution, the gap betweenthe solution obtained by algorithm Greedyprofit and the exact solution of ILP issmaller.

Figure 6.1: Performance of algorithms Greedyprofit and algorithm ILP for taskoffloading profit maximization problem by changing the amount of requests from

100 to 1,000

Next, we make an evaluation of the algorithms Greedyprofit against algorithmBaseline for large-scale problems. The network size varies 10 to 300 and the re-quest number is fixed at 3000. Fig 6.2 demonstrates performance curves of algo-rithm Greedyprofit and algorithm Baseline. Fig 6.2a illustrates that algorithm


§6.3 Algorithm evaluation for two special cases task of offloading profit maximization problem27

Greedyprofit outperforms algorithm Baseline in all network sizes, and algorithmGreedyprofit obtains 32.8% more accumulated profit when the network size is 150.We can also see that the accumulated profit grows with growth of the networksize. Fig 6.2b shows that algorithm Baseline consumes less time than algorithmGreedyprofit. The reason is that algorithm Greedyprofit calculates the profit ofassigning each request that has not been admitted to each cloudlet in each iterationto identify the request which the ratio of profit to its occupied computing resource isthe maximum one; while algorithm Baseline allocates greedily each request to thecloudlet with the maximal admission profit.

Figure 6.2: Performance of algorithms Greedyprofit and algorithm Baseline fortask offloading profit maximization problem for 3000 requests by changing the

amount of APs from 10 to 300

6.3 Algorithm evaluation for two special cases task of offload-ing profit maximization problem

6.3.1 The special case without sharing VNF instances

We first study the performance of the proposed heuristic algorithm Greedyprofitagainst the optimal solution of the ILP by varying the number of requests from 100to 1,000, fixing the number of APs at 100 and the number of cloudlets at 10. Fig6.3 shows the total profit and running time delivered by algorithm Greedyprofitand algorithm ILP. Fig 6.3a shows that the accumulated profit delivered by algo-rithm Greedyprofit no less than 92% of the optimal solution by algorithm ILP.From Fig 6.3b, we can see that algorithm ILP is time-consuming while algorithmGreedyprofit runs considerably faster. When there are 1,000 requests in the MECnetwork, algorith ILP takes more 110 seconds than algorithm Greedyprofit. As therunning time of algorithm Greedyprofit increases exponentially with the growth inthe number of requests, algorithm ILP cannot be applicable when the problem size


28 Evaluation

is big.

Figure 6.3: Performance of algorithm Greedyprofit and algorithm ILP for task of-floading profit maximization problem without sharing VNF instances by changing

the amount of requests from 100 to 1,000

What follows is the performance analysis of algorithms Greedyprofit against al-

Figure 6.4: Performance of algorithm Greedyprofit and algorithm Baseline fortask offloading profit maximization problem without sharing VNF instances for 3000

requests by changing the amount of APs from 10 to 300

gorithm Baseline_Alg by changing network size from 10 to 300 for 3000 requests.From Fig 6.4a, we can observe that algorithms Greedyprofit outperforms algorithmBaseline significantly. And the performance gap between the two algorithms growssynchronously with the network size. In particular, algorithms Greedyprofit ob-tains 68% and 82% more accumulated profit than algorithm Baseline when the


§6.3 Algorithm evaluation for two special cases task of offloading profit maximization problem29

network size is 50 and 200, respectively. Fig 6.4b shows algorithm Baseline takesless time in all network sizes.

Figure 6.5: Performance of algorithm Greedyprofit for offloading profit maximiza-tion problem when sharing and not sharing VNF instances for 3000 requests by

changing the amount of APs from 10 to 300

We thirdly study the operation difference of algorithm Greedyprofit for the task of-floading profit maximization problem when sharing and not sharing VNF instances,denoted by Greedyshare and Greedynoshare, respectively. Keeping the requestsnumber constant at 3000, we vary the network size from 10 to 300. Fig 6.5 demon-strates the accumulated profit, running time, the number of admitted requests ofalgorithms Greedyshare and Greedynoshare. From Fig 6.5a, we can find that theaccumulated profit collected by algorithm Greedyshare is significantly higher thanthat of algorithm Greedynoshare. And from Fig 6.5c, it is obvious that algorithmGreedyshare admits more requests than algorithm Greedynoshare in all networksizes. Specifically, the accepted requests delivered by algorithm Greedyshare is 145%


30 Evaluation

more than that of algorithm Greedynoshare when the network size set as 200. Thereasonable explanation is that algorithm Greedyshare admits requests with the sametype of VNF to share VNF instances in one cloudlet, so the processing capacity ofVNF instances can be fully utilised. In contrast, algorithm Greedynoshare requireseach admitted request to occupy dedicated VNF instances; thus instantiation costof request admission is increased by creating more VNF instances, resulting in adecrease in profit.

6.3.2 The special case without delay and sharing VNF instances

We first investigate the performance of the proposed approximation algorithm Approagainst algorithm Greedyprofit and the optimal solution of the ILP for the specialcase of the problem where sharing VNF instances and delay constraints of requestsare ignored. We vary the number of requests from 100 to 1000, when the numbers ofAPs and cloudlets are 50 and 5. Fig 6.6 shows the accumulated profit and runningtime of different algorithms. Fig 6.6a illustates that algorithm Appro can achieve anearly optimal accumulated profit. More specifically, Appro offers at least 96.3% ofthe optimal solution by algorithm ILP. And algorithm Appro outperforms algorithmGreedyprofit.

Figure 6.6: Performance of different algorithms for the special case of the task of-floading profit maximization problem where delay requirements and sharing VNF

instances are neglected

It can be seen from Fig 6.6b that the running time of algorithm ILP increases expo-nentially with the growth of request number, while the running time of algorithmAppro follows a linear growth. Therefore, as the scale of the problem continues toincrease, algorithm ILP can not get the optimal solution in a reasonable amount oftime, which limits its application. Compared with algorithm ILP, algorithm Approtakes less running time and gets a result comparable to the optimal solution.


§6.4 Summary 31

Figure 6.7: Performance of algorithm Appro and algorithm Baseline for the specialcase of the task offloading profit maximization problem by changing the network

size from 10 to 300

Then we evaluate the performance of approximation algorithm Appro against algo-rithm Baseline for a set of 3000 requests, changing the network size from 10 to 300.Fig 6.7 demonstrates the performance curves of the two algorithms. Fig 6.7a showsthat algorithm Appro outperforms significantly algorithm Baseline. The accumu-lated profit of both algorithms grow with the increase in the network size. The algo-rithm Appro has 143% and 122% more than algorithm Baseline respectively whenthe network size set as 100 and 300. Fig 6.7b illustrates the algorithm Baselineconsumes less than algorithm Appro in all network sizes.

6.4 Summary

In this chapter, we analyzed the performance of the proposed algorithms by experi-ment. The experimental results indicated that the proposed algorithms outperformthe benchmark algorithm. Besides, sharing VNF instances significantly increased theaccumulated profit of network service providers.


Chapter 7

Conclusions and Future Work

7.1 Conclusions

In this thesis, we investigated the task offloading profit maximization problem in anMEC network, where each cloudlet has a random number of VNF instances. Wefirst devised a novel task offloading problem to maximize the accumulated profit ofadmitted requests, assuming that user requests with the same type of VNF can shareVNF instances in one cloudlet. We proposed an exact ILP solution and an efficientheuristic algorithm for the problem. Furthermore, we devised an approximationalgorithm for one special case of the problem where delay constrains and sharingVNF instances are neglected. Finally, the performance of the proposed algorithmswas evaluated by empirical analysis. Experimental results indicated that ILP takessignificantly high running time to return optimal solutions, which is only applicableto small-scale problems. On the other hand, the proposed algorithms outperformedthe benchmark and achieved a near-optimal accumulated profit in a scalable andefficient way.

7.2 Future Work

In the current system model, we assume that each request needs only one type ofVNF instances and only consider request admissions in a single time slot. However,in the real-world MEC networks, user requests are usually implemented by a chain-ordered set of placed VNFs, requiring more than one type of VNFs. And requestsarrive and leave dynamically without knowing the arrival of future requests. Theresources occupied by the currently admitted requests will affect the decision-makingof the admissions of future requests. In future work, we plan to propose onlinealgorithms for the online version of the task offloading profit maximization problemwhere dynamic requests arrive for a given time horizon. Besides, we will study theproblem where each request needs more than one type of VNFs.

32


Bibliography

Al-Shuwaili, A. and Simeone, O., 2017. Energy-efficient resource allocation formobile edge computing-based augmented reality applications. IEEE Wireless Com-munications Letters, 6, 3 (jun 2017), 398–401. doi:10.1109/lwc.2017.2696539. (citedon page 6)

Chen, M.; Saad, W.; and Yin, C., 2018. Virtual reality over wireless networks:Quality-of-service model and learning-based resource management. IEEE Trans-actions on Communications, 66, 11 (nov 2018), 5621–5635. doi:10.1109/tcomm.2018.2850303. (cited on page 6)

Cohen, R.; Katzir, L.; and Raz, D., 2006. An efficient approximation for the general-ized assignment problem. Information Processing Letters, 100, 4 (nov 2006), 162–166.doi:10.1016/j.ipl.2006.06.003. (cited on pages 23 and 24)

ETSI, G., 2013. Network functions virtualisation (nfv): Architectural framework. ETsIGs NFV, 2, 2 (2013), V1. (cited on page 7)

Grewe, D.; Wagner, M.; Arumaithurai, M.; Psaras, I.; and Kutscher, D., 2017.Information-centric mobile edge computing for connected vehicle environments.In Proceedings of the Workshop on Mobile Edge Communications - MECOMM 17. ACMPress. doi:10.1145/3098208.3098210. (cited on page 1)

Herrera, J. G. and Botero, J. F., 2016. Resource allocation in NFV: A comprehensivesurvey. IEEE Transactions on Network and Service Management, 13, 3 (sep 2016), 518–532. doi:10.1109/tnsm.2016.2598420. (cited on pages viii and 6)

Hu, Y. C.; Patel, M.; Sabella, D.; Sprecher, N.; and Young, V., 2015. Mobile edgecomputing—a key technology towards 5g. ETSI white paper, 11, 11 (2015), 1–16.(cited on pages 2 and 4)

Jia, M.; Liang, W.; and Xu, Z., 2017. QoS-aware task offloading in distributedcloudlets with virtual network function services. In Proceedings of the 20th ACMInternational Conference on Modelling, Analysis and Simulation of Wireless and MobileSystems. ACM. doi:10.1145/3127540.3127561. (cited on page 25)

Jia, M.; Liang, W.; Xu, Z.; and Huang, M., 2016. Cloudlet load balancing in wirelessmetropolitan area networks. In IEEE INFOCOM 2016 - The 35th Annual IEEE In-ternational Conference on Computer Communications. IEEE. doi:10.1109/infocom.2016.7524411. (cited on page 7)

33


http://dx.doi.org/10.1109/lwc.2017.2696539

http://dx.doi.org/10.1109/tcomm.2018.2850303

http://dx.doi.org/10.1109/tcomm.2018.2850303

http://dx.doi.org/10.1016/j.ipl.2006.06.003

http://dx.doi.org/10.1145/3098208.3098210

http://dx.doi.org/10.1109/tnsm.2016.2598420

http://dx.doi.org/10.1145/3127540.3127561

http://dx.doi.org/10.1109/infocom.2016.7524411


34 BIBLIOGRAPHY

Li, J.; Liang, W.; Huang, M.; and Jia, X., 2020. Reliability-aware network serviceprovisioning in mobile edge-cloud networks. IEEE Transactions on Parallel and Dis-tributed Systems, 31, 7 (jul 2020), 1545–1558. doi:10.1109/tpds.2020.2970048. (citedon page 7)

Li, Y.; Phan, L. T. X.; and Loo, B. T., 2016. Network functions virtualization with softreal-time guarantees. In IEEE INFOCOM 2016 - The 35th Annual IEEE InternationalConference on Computer Communications. IEEE. doi:10.1109/infocom.2016.7524563.(cited on pages 7 and 25)

Liu, H.; Eldarrat, F.; Alqahtani, H.; Reznik, A.; de Foy, X.; and Zhang, Y., 2018.Mobile edge cloud system: Architectures, challenges, and approaches. IEEE Sys-tems Journal, 12, 3 (sep 2018), 2495–2508. doi:10.1109/jsyst.2017.2654119. (cited onpage 4)

Ma, Y.; Liang, W.; Xu, Z.; and Guo, S., 2019. Profit maximization for admittingrequests with network function services in distributed clouds. IEEE Transactions onParallel and Distributed Systems, 30, 5 (may 2019), 1143–1157. doi:10.1109/tpds.2018.2874257. (cited on pages 8 and 25)

Mao, Y.; You, C.; Zhang, J.; Huang, K.; and Letaief, K. B., 2017. A survey on mobileedge computing: The communication perspective. IEEE Communications Surveys &Tutorials, 19, 4 (2017), 2322–2358. doi:10.1109/comst.2017.2745201. (cited on page5)

Mijumbi, R.; Serrat, J.; Gorricho, J.-L.; Bouten, N.; Turck, F. D.; and Boutaba,R., 2016. Network function virtualization: State-of-the-art and research challenges.IEEE Communications Surveys & Tutorials, 18, 1 (2016), 236–262. doi:10.1109/comst.2015.2477041. (cited on page 7)

Othman, M.; Madani, S. A.; Khan, S. U.; et al., 2013. A survey of mobile cloudcomputing application models. IEEE communications surveys & tutorials, 16, 1(2013), 393–413. (cited on page 2)

Patel, M.; Naughton, B.; Chan, C.; Sprecher, N.; Abeta, S.; Neal, A.; et al.,2014. Mobile-edge computing introductory technical white paper. White paper,mobile-edge computing (MEC) industry initiative, (2014), 1089–7801. (cited on page 1)

Pham, Q.-V.; Fang, F.; Ha, V. N.; Le, M.; Ding, Z.; Le, L. B.; and Hwang, W.-J.,2019. A survey of multi-access edge computing in 5g and beyond: Fundamentals,technology integration, and state-of-the-art. arXiv preprint arXiv:1906.08452, (2019).(cited on pages viii, 1, 4, and 5)

Racheg, W.; Ghrada, N.; and Zhani, M. F., 2017. Profit-driven resource provision-ing in NFV-based environments. In 2017 IEEE International Conference on Commu-nications (ICC). IEEE. doi:10.1109/icc.2017.7997163. (cited on page 8)


http://dx.doi.org/10.1109/tpds.2020.2970048


http://dx.doi.org/10.1109/jsyst.2017.2654119



http://dx.doi.org/10.1109/comst.2017.2745201



http://dx.doi.org/10.1109/icc.2017.7997163

BIBLIOGRAPHY 35

Satyanarayanan, M.; Bahl, P.; Caceres, R.; and Davies, N., 2009. The case for VM-based cloudlets in mobile computing. IEEE Pervasive Computing, 8, 4 (oct 2009),14–23. doi:10.1109/mprv.2009.82. (cited on page 4)

Sheng, Z.; Mahapatra, C.; Zhu, C.; and Leung, V. C. M., 2015. Recent advancesin industrial wireless sensor networks toward efficient management in IoT. IEEEAccess, 3 (2015), 622–637. doi:10.1109/access.2015.2435000. (cited on page 1)

Taleb, T.; Dutta, S.; Ksentini, A.; Iqbal, M.; and Flinck, H., 2017. Mobile edgecomputing potential in making cities smarter. IEEE Communications Magazine, 55,3 (mar 2017), 38–43. doi:10.1109/mcom.2017.1600249cm. (cited on page 1)

Wu, H., 2018. Multi-objective decision-making for mobile cloud offloading: A survey.IEEE Access, 6 (2018), 3962–3976. doi:10.1109/access.2018.2791504. (cited on page7)

Xiao, Y.; Jia, Y.; Liu, C.; Cheng, X.; Yu, J.; and Lv, W., 2019. Edge computingsecurity: State of the art and challenges. Proceedings of the IEEE, 107, 8 (2019),1608–1631. doi:10.1109/jproc.2019.2918437. (cited on page 1)

Xu, Z.; Liang, W.; Jia, M.; Huang, M.; and Mao, G., 2019. Task offloading withnetwork function requirements in a mobile edge-cloud network. IEEE Transactionson Mobile Computing, 18, 11 (nov 2019), 2672–2685. doi:10.1109/tmc.2018.2877623.(cited on page 8)

Yang, S.; Li, F.; Yahyapour, R.; and Fu, X., 2019. Delay-sensitive and availability-aware virtual network function scheduling for nfv. IEEE Transactions on ServicesComputing, (2019). doi:10.1109/tsc.2019.2927339. (cited on page 7)

Zhang, J.; Zeng, D.; Gu, L.; Yao, H.; and Xiong, M., 2017a. Joint optimizationof virtual function migration and rule update in software defined nfv networks.In GLOBECOM 2017-2017 IEEE Global Communications Conference, 1–5. IEEE. doi:10.1109/glocom.2017.8254083. (cited on page 7)

Zhang, K.; Mao, Y.; Leng, S.; Zhao, Q.; Li, L.; Peng, X.; Pan, L.; Maharjan, S.;and Zhang, Y., 2016. Energy-efficient offloading for mobile edge computing in 5gheterogeneous networks. IEEE access, 4 (2016), 5896–5907. doi:10.1109/access.2016.2597169. (cited on page 7)

Zhang, X.; Huang, Z.; Wu, C.; Li, Z.; and Lau, F. C. M., 2017b. Online stochasticbuy-sell mechanism for VNF chains in the NFV market. IEEE Journal on SelectedAreas in Communications, 35, 2 (feb 2017), 392–406. doi:10.1109/jsac.2017.2659259.(cited on page 8)


http://dx.doi.org/10.1109/mprv.2009.82

http://dx.doi.org/10.1109/access.2015.2435000

http://dx.doi.org/10.1109/mcom.2017.1600249cm


http://dx.doi.org/10.1109/jproc.2019.2918437

http://dx.doi.org/10.1109/tmc.2018.2877623

http://dx.doi.org/10.1109/tsc.2019.2927339

http://dx.doi.org/10.1109/glocom.2017.8254083

http://dx.doi.org/10.1109/glocom.2017.8254083



http://dx.doi.org/10.1109/jsac.2017.2659259

Chapter 7

Appendix

.1 Independent Study Contract

36


§.1 Independent Study Contract 37


38 Appendix


§.2 Software/Artefacts Description 39

.2 Software/Artefacts Description

The simulation experiments are conducted in Java. There are six code folders in ourproject. Code files in "algorithm", "appro", "simulation" folders are created by me.Codes in "graph", "network", "utils" folders are modified based on the previous workby Dr Xu. And "data" folder contains the simulated network structure data, includ-ing APs location, link location.

Algorithm code files:

• Benchmark algorithm:

greedybench.java: for the profit maximization problem

greedybenchnoshare.java: for the special case without sharing VNF

bench3.java: for the special case without sharing VNF and delay constraints

• ILP solution:

ILPCase1.java: for the profit maximization problem

ILPCase2existing.java: for the special case without sharing VNF

ILPCase3.java: for the special case without sharing VNF and delay constraints

• heuristic algorithm:

Greedyshare1.java: for the profit maximization problem

Greedynoshare2.java: for the special case without sharing VNF

GreedyBase.java: for the special case without sharing VNF and delay con-straints

• approximation algorithm:

Approximation.java: for the special case without sharing VNF and delay con-straints

"simulation" folders:

CloudletSimulator.java: the main class to simulate experiments in our project


40 Appendix

"network" folders:

Cloudlet.java: simulate the function of cloudlets in MEC networks

AccessPoint.java: simulate the function of APs in MEC networks

Queue.java: each type of NFV function instances in a cloudlet has a queue

InternetLink.java: simulate the edge connected APs in MEC networks

Request.java: simulate function of user request in MEC networks

NetworkGenerator.java: construct an undirected graph


§.2 Software/Artefacts Description 41

Figure 1: Code artefact


42 Appendix

.3 Readme File

Java library:

The generation of MEC networks are implemented on undirected graphs using jgraphtlibrary: jgrapht-core-1.1.0.jar.

The construction of GAP instance uses guava library: guava-25.1-jre.jar, annotations-15.0.jar.

The ILP formulation is implemented by using cplex library: cplex.jar.

How to run the simulation experiments:

CloudletSimulator.java is the main class to simulate experiments in our project. Aswe study three cases of the task offloading profit maximization problem, the runningstep is shown in fig 2:

1) input the problem case index:

the task offloading profit problem: 1

special case without sharing VNF: 2

special case without delay constraints and sharing VNF: 3

2) input the request number: can enter any natural number

3) input the network size: select from {10,50,100,150,200,300}

4) then the simulation experiment is conducted


§.3 Readme File 43

Figure 2: an example of simulation experiment


Documents

Task Ofﬂoading in Mobile Edge Computing Networks · Mobile Edge Computing (MEC) is an envisioned paradigm to solve the contradiction between the growing delay-sensitive and computation-intensive