Philippe Bertin

CAARS Context Aware-Augmented Reality System CC Cloud Computing CDF Cumulative Distribution Function

Keywords:

Computation offloading is a technique that allows resource-constrained mobile devices to fully or partially offload a computation-intensive application to a resourceful Cloud environment. Computation offloading is performed mostly to save energy, improve performance, or due to the inability of mobile devices to process a computationheavy task. There have been a numerous approaches and systems on offloading tasks in the classical Mobile Cloud Computing (MCC) environments such as, CloneCloud, MAUI, and Cyber Foraging. Most of these systems are offering a complete solution that deal with different objectives. Although these systems present in general good performance, one common issue between them is that they are not adapted to real-time applications such as mobile gaming, augmented reality, and virtual reality, which need a particular treatment.

Computation offloading is widely promoted especially with the advent of Mobile Edge Computing (MEC) and its evolution toward Multi-access Edge Computing which broaden its applicability to heterogeneous networks including WiFi and fixed access technologies. Combined with 5G mobile access, a plethora of novel mobile services will appear that include Ultra-Reliable Low-latency Communications (URLLC) and enhanced Vehicle-toeverything (eV2X). Such type of services requires low latency to access data and high resource capabilities to compute their behaviour.

To better find its position inside a 5G architecture and between the offered 5G services, computation offloading needs to overcome several challenges; the high network latency, resources heterogeneity, applications interoperability and portability, offloading frameworks overhead, power consumption, security, and mobility, to name a few.

In this thesis, we study the computation offloading paradigm for real-time applications including mobile gaming and image processing. The focus will be on the network latency, resource consumption, and accomplished performance.

The contributions of the thesis are organized on the following axes:

• Study game engines behaviour on different platforms regarding resource consumption (CPU/GPU) per frame and per game module.

là où je suis aujourd'hui. Ces gens que je voudrais remercier ici.

Tout d'abord, je remercie tout particulièrement mon directeur de thèse Adlen Ksentini et co-directeur Philippe Bertin, pour leurs conseils, leur disponibilité et dévouement, leur gentillesse, leur sympathie et surtout de m'avoir accordé leur confiance pour mener à bien ce travail; qu'ils puissent trouver ici l'expression de ma reconnaissance, de mon profond respect et de mes plus vifs remerciements.

Au terme de ce travail, il m'est agréable de remercier toutes les personnes qui, chacune à sa manière, m'ont permises de le mener à bien.

Tout d'abord, mon chef de laboratoire "Network Architecture" Mr Olivier Choisy.

Aussi, je remercie infiniment mon directeur du lab Mr Michel Corriou.

Un grand merci aux employés de B-COM pour leur disponibilité

• Study the possibility to offload game engine modules based on resource consumption, network latency, and code dependency.

• Propose a deployment strategy for Cloud gaming providers to better exploit their resources based on the variability of the resource demand of game engines and the QoE.

• Propose a static computation offloading-based solution for game engines by splitting 3D world scene into different game objects. Some of these objects are offloaded based on resource consumption, network latency, and code dependency.

• Propose a dynamic offloading solution for game engines based on an heuristic that compute for each game object, the offloading gain. Based on that gain, an object may be offloaded or not.

• Propose a novel approach to offload computation to MEC by deploying a mobile edge application that is responsible for driving the UE decision for offloading, as well as propose two algorithms to make best decision regarding offloading tasks on UE to a server hosted on the MEC. i

RÉSUMÉ

Le délestage de calcul ou de code est une technique qui permet à un appareil mobile avec une contrainte de ressources d'exécuter à distance, entièrement ou partiellement, une application intensive en calcul dans un environnement Cloud avec des ressources suffisantes. Le délestage de code est effectué principalement pour économiser de l'énergie, améliorer les performances, ou en raison de l'incapacité des appareils mobiles à traiter des calculs intensifs. Plusieurs approches et systèmes ont été proposés pour délester du code dans le Cloud tels que CloneCloud, MAUI et Cyber Foraging. La plupart de ces systèmes offrent une solution complète qui traite différents objectifs. Bien que ces systémes présentent en général de bonnes performances, un problème commun entre eux est qu'ils ne sont pas adaptés aux applications temps réel telles que les jeux vidéo, la réalité augmentée et la réalité virtuelle, qui nécessitent un traitement particulier.

Le délestage de code a connu un récent engouement avec l'avènement du MEC et son évolution vers le edge à multiple accès qui élargit son applicabilité à des réseaux hétérogènes comprenant le WiFi et les technologies d'accès fixe. Combiné avec l'accès mobile 5G, une pléthore de nouveaux services mobiles apparaîtront, notamment des service type URLLC et eV2X. De tels types de services nécessitent une faible latence pour accéder aux données et des capacités de ressources suffisantes pour les exécuter.

Pour mieux trouver sa position dans une architecture 5G et entre les services 5G proposés, le délestage de code doit surmonter plusieurs défis; la latence réseau élevée, hétérogénéité des ressources, interopérabilité des applications et leur portabilité, la consommation d'énergie, la sécurité, et la mobilité, pour citer quelques uns.

Dans cette thèse, nous étudions le paradigme du délestage de code pour des applications a temps rèel, par exemple; les jeux vidéo sur équipements mobiles et le traitement d'images. L'accent sera mis sur la latence réseau, la consommation de ressources, et les performances accomplies.

Les contributions de la thse sont organisées sous les axes suivants:

• Étudier le comportement des moteurs de jeu sur différentes plateformes en termes de consommation de ressources (CPU / GPU) par image et par module de jeu.

• Étudier la possibilité de distribuer les modules du moteur de jeu en fonction de la consommation de ressources, de la latence réseau, et de la dépendance du code.

• Proposer une stratégie de déploiement pour les fournisseurs de jeux dans le Cloud, afin de mieux exploiter les ressources, en fonction de la demande variable en ressource par des moteurs de jeu et de la QoE du joueur.

• Proposer une solution de délestage statique de code pour les moteurs de jeu en divisant la scène 3D en différents objets du jeu. Certains de ces objets sont distribués en fonction de la consommation de ressources, de la latence réseau et de la dépendance du code.

• Proposer une solution de délestage dynamique de code pour les moteurs de jeu basée sur une heuristique qui calcule pour chaque objet du jeu, le gain du délestage. En fonction de ce gain, un objet peut être distribué ou non. Smartphones are ubiquitous devices, offering "information at your fingertips" ranging from communications to computing services. These pervasive devices have created an acute dependency among mobile users, many of whom cannot leave home without taking their device. Mobile users expect to be able to run computationally intense, high quality applications on these devices, which include mobile-gaming (m-gaming), mobile-health (m-health), and mobile-learning (m-learning) applications. However, due to the lightness, handiness, and compactness of these devices, and due to users safety and mobility issues, mobile devices have some intrinsic limitations to their capabilities, which include low processing ability, short battery autonomy, small storage capacity, and limited screen size. These limitations impede the execution of resource-intensive applications. To make this feasible, industry and academia have two options;

• Hardware augmentation. This consists of enhancing the hardware capabilities of mobile devices, which include the CPU, GPU, battery, and storage.

• Software augmentation. This leverages remote infrastructure resources to offload the intensive computation in order to conserve local resources.

Several investigations have been carried out to increase the hardware capabilities of mobile devices.

Manufacturers are proposing multi-core processors with high clock speed, and the ARM industry offers various microprocessor cores that address performance, power and cost requirements, such as the Cortex-A processor, which integrates a Memory Management Unit (MMU), designed to execute complex operating systems, including Linux, Android, and Microsoft Windows 1 . Samsung2 and Qualcomm 3corporations have designed new generations of smartphones, which include GPU's, such as Mali and Adreno. In regards to battery autonomy, many efforts are being made to harvest energy from renewable resources, including human movement [START_REF] Donnell | Prolog to energy harvesting from human and machine motion for wireless electronic devices[END_REF], solar energy [START_REF] Bialic | Wysips® connect, the first solution for the indoor/outdoor vlc lighting saturation problematics[END_REF][START_REF] Liu | Autocharge: Automatically charge smartphones using a light beam[END_REF], and wireless radiation [START_REF] Huang | Enabling wireless power transfer in cellular networks: Architecture, modeling and deployment[END_REF]. These solutions are still under investigations and currently cannot noticeably enhance the energy source, as these resources are intermittent and not available on-demand. In parallel, researchers are attempting to reduce the energy overhead in different aspects of computing, including hardware, Operating Systems (OSs), applications, and networking interfaces. Dynamic Voltage Scaling (DVS) technology is a power management technique used to conserve energy, particularly in wearable devices, by increasing and decreasing the voltage as needed. The automatic screen shutdown is another attempt to save energy on mobile devices. For some companies, like Samsung, the removable battery is a good way to keep the smartphone working as long as possible by changing the spent battery out for another one.

Software augmentation has also attracted industrial and academic solutions, which conserve the local resources of mobile devices. Mobile Cloud Computing is envisioned as a promising solution for addressing the aforementioned challenges. By offloading computations to resourceful servers located in the Cloud, Mobile Cloud Computing can augment the capabilities of mobile devices for computationallyhungry applications. Several approaches have been proposed in the literature based on the Mobile Cloud Computing; we cite load sharing, remote execution, and computation offloading. Load sharing and remote execution have evolved to the concept of computation offloading, which is more general and mature. Computation offloading has become an attractive way to reduce the execution time required by mobile users. It consists of moving a portion of an application to the Cloud. Upon receiving the migration request, the server creates a dedicated virtual machine for the mobile device, loads the application, and starts its execution. In the mean time, the mobile device continues to run other tasks or waits for the results of the execution on the server. At the end, the migrated portion returns to the mobile device, and merges back into the original process. Computation offloading involves various stakeholders: mobile devices, network environment, mobile applications, remote servers, mobile users, and the framework performing the migration.

Accordingly, several challenges and issues have arisen from different stakeholder perspectives that need to be addressed, for example, response time, energy consumption, security, network communications, and network latency. Research has been done to address the computation offloading from these points of view. Some of these challenges have been solved, such as the network latency, wherein Mobile Edge Computing and Fog Computing have been widely used in computation offloading to address this issue. In terms of network communications, multi-Radio Access Technology (multi-RAT) and on-demand bandwidth have been used to improve the throughput and, therefore, improve the offloading performance.

Some other challenges are still open issues, such as the framework overhead, and decision-making 1.1. THESIS CONTRIBUTIONS regarding when and what to offload. This thesis will address some of these issues.

Thesis Contributions

The general thematic of the thesis concerns the computation offloading of real-time, resource-intensive, and complex mobile applications, including 3D game engines and facial recognition. The research topics are based on feasibility, performance, and network latency.

The contributions of the thesis are three-fold:

1. Game engines: Under this axis, there are two contributions [START_REF] Messaoudi | Performance analysis of game engines on mobile and fixed devices[END_REF][START_REF] Messaoudi | Dissecting games engines: The case of unity3d[END_REF]. This axis can split into three parts:

a) Deployment strategy: Game engines are studied in the Cloud gaming context in terms of resource variability. Different types of games have been tested, and the obtained performance are considered for server consolidation. Cloud gaming providers should find a trade-off between the user's Quality of Experience (QoE) and the number of hosted game engines per server. Currently, Cloud servers are being split among several game engines using virtualization technology. The higher the resource demand of a game engine, the more resourceful the virtual machine hosting this game engine will be, resulting in low server consolidation. If the resource demands of a game engine do not vary by much, a Cloud gaming provider can easily predict this demand, and, therefore, consolidate the server efficiently.

However, if the game engine varies widely in its demand for resources, then, in such a case, a

Cloud provider should accommodate the game engine with peaks. Therefore, a Cloud gaming provider should find a trade-off between high consolidation and high QoE, using the load variability study in [START_REF] Messaoudi | Performance analysis of game engines on mobile and fixed devices[END_REF].

b) Game engine dissection: Game engines, to our knowledge, have not being studied from the state-of-the-art internal architecture point of view. Game engines are considered as proprietary black boxes. Considering the recent trends, game players have become more mobile and are using their smartphones and tablets to play games. Compared to dedicated boxes, such as the XBox One, mobile devices do not perform well when running best-selling 3D games.

Solution leveraging remote resourceful infrastructure, such as Cloud gaming and computation offloading, represent the next step toward improving the gaming experience. Consequently, dissecting, testing, and analysing game engine behaviour is a step toward better understanding how to distribute game engines over a network. Therefore, this contribution aims to analyse the behaviour of different "genres" of games, test their performance, identify resource bottlenecks, and, most importantly, draw the internal call flows for inter-and intra-modules that compose a game. c) Offloading feasibility: For each module of the game engine, we represent the internal call flow in order to study the offloading case. Modules related to rendering, which represent the majority of the CPU consumption and most of the GPU consumption are all mixed by series of calls. This observation is a challenge for the implementation of code offloading since it reduces the gains in terms of performance, and it imposes to generate calls between distant machines. The physics family can be spread into three sub-families that communicate through one class. It would thus be relatively simple to distribute the computation of these three sub-families over separate computers. The scripting family is the only module that interacts directly with the physics engine. It would thus make sense to run this family of modules on the same computer as physics modules. The audio family has no interaction with the other main modules and only deals with the game thread. This module can thus be offloaded as an Application Programming Interface (API) to a remote machine. The communication between the client and the remote machine can be done either by Remote Procedure Call (RPC) or by streaming the audio data. The Artificial Intelligence (AI) family can be computationally intensive. It is difficult or even impossible to simulate the game on constrained-resource devices without reducing the complexity of the AI. Since this family is also mostly independent, the module family as a whole can be offloaded without introducing much complexity.

2. Game engine offloading: Under this axis, there are two contributions [START_REF] Messaoudi | Toward a mobile gaming based-computation offloading[END_REF][START_REF] Messaoudi | Performance analysis of game engines on mobile and fixed devices[END_REF]. In [START_REF] Messaoudi | Performance analysis of game engines on mobile and fixed devices[END_REF], a static offloading of game engine modules based on game engine objects has been proposed. We decomposed a game world into several game objects; these include the player character, non-player character, and the environment. We set several criteria regarding these objects. The criteria are based on resource consumption, code dependency constraints, network latency, and bandwidth consumption. According to these criteria, each game object is placed on a mobile device or a remote server. In [START_REF] Messaoudi | Toward a mobile gaming based-computation offloading[END_REF] a dynamic offloading of the game engine modules has been proposed. This contribution is an enhancement of our work done in [START_REF] Messaoudi | Performance analysis of game engines on mobile and fixed devices[END_REF], wherein we proposed an heuristic to schedule module placement using the same criteria.

MEC oriented offloading contribution:

We have a contribution under this axis [START_REF]On using edge computing for computation offloading in mobile network[END_REF]. One of the big concerns in computation offloading is the network latency between the mobile device and server, which limits computation offloading applicability to delay-tolerant applications. For delay-sensitive applications such as gaming, high latency is intolerable and degrades the quality as perceived by users. Hopefully, with Mobile Edge Computing (MEC) and the transition toward 5G, network latency will be drastically reduced. Our contribution was to leverage MEC architecture to drive computation offloading. We want to use MEC as an enabler for low-latency, computation offloading-based applications, such as facial recognition. To this aim, we designed a framework to orchestrate the offloading process. The framework runs on three different entities: (i) mobile edge application hosted on the mobile edge, which is able to access mobile user-related radio information, (ii) mobile user, and (iii) a server hosted in the mobile edge. The mobile edge application is responsible for driving a decision to accept or reject offloading requests coming 1.2. MANUSCRIPT ORGANIZATION from mobile devices and predicting, using low-level API, the latency value. The mobile device makes the decision to offload application modules or not according to the estimated latency value obtained from the mobile edge application. Finally, the server, hosted on the mobile edge side, computes the offloaded code and sends back the results to the mobile device. As a proof of concept,

We have run a facial recognition application on a mobile device which offloads computation to the server hosted in the mobile edge.

Manuscript Organization

Chapter 2 introduces the reader to computation offloading. We provide a definition of computation offloading in the frame of past studies. We identify the main steps for performing a computation offloading request based on past studies. Then we match these steps in a use case based on Google glasses. Next, we classify the state-of-the-art computation offloading into three approaches based on timescale decision making. We also provide an evolutionary history of computation offloading according to the literature. Further, we introduce the metrics that impact computation offloading performance, which will become the research topic in chapter 3. We finish this chapter by describing the advantages and disadvantages of computation offloading.

Chapter 3 presents, comprehensively and qualitatively, an exhaustive state-of-the-art computation offloading from six points of view. From the mobile user perspective, we focus on the objective function behind computation offloading desired by the mobile user. Mobile users are particularly interested in the performance and energy consumption of their mobile applications. We classified several frameworks according to the objective function into mono-objective, bi-objective, and multi-objective optimizationbased frameworks. Then we discuss user mobility from a computation offloading context, and we finish with some user concerns regarding computation offloading. From the mobile device perspective, we present the various platforms used in the literature for computation offloading and the mobile device's hardware evolution. Next, from the server side, we describe each of the server types, platform types, improvements, and issues regarding computation offloading. All of these axes are based on past studies.

A section of this chapter is also dedicated to describe computation offloading from an application point of view. We describe the taxonomy regarding the "genre" of applications, the programming languages used to develop these applications, the requirements, and the dependency of the applications code on the underlying platform and hardware. Computation offloading relies on network communication, therefore, it seems adequate to describe computation offloading from the network perspective, especially the metrics, communications support, and network models. We then highlight the steps involved in offloading a computation, data availability, framework location, framework scale, application annotations, offloading types, and the models and algorithms devised to steer computation offloading decision making.

Chapter 4 focuses on game engines from a computation offloading perspective. In this chapter, a background of game engines that describes the architecture with the associated modules, and the process of generating frames done under the graphic pipeline is presented. The background also introduces three game engine solutions that eliminate the powerless capabilities of mobile gamers. The solutions are Cloud gaming, computation offloading, and client-server architecture, each of which presents some challenges regarding the "genre" of games, such as First Person Shooter (FPS), Real-Time Strategy (RTS), or Massively Multi-player Online Games (MMOG). Once the game engine's landscape is drawn, we present our methodology for classifying game engines under the three solutions cited above. The classification is based on the variability and playability of game engines, for which we define predicates.

The chosen criteria are central to the Cloud gaming provider being able to manage the Quality of Service/Quality of Experience (QoS/QoE) and consolidation, but also to mobile user immersion and interactivity. Next, we dissect the internal architecture and call flow in the different modules. The aim is to study the possibility of offloading software components of these modules. We finish the chapter by demonstrating our classification via use cases of running games under the three solutions.

Chapter 5 describes a novel solution for mobile gaming based computation offloading. We begin this chapter by reviewing past studies of game engines-oriented computation offloading. Almost all of this research presents the same challenges; the real-time constraints and high-resource consumption of 3D best-selling FPS games. Our solution resolves these problems. We described how a 3D scene is represented in a game engine and what the patterns and objects are in a game world. Then, we present a vision and methodology to design the 3D-based Unity Computation Offloading Framework. We propose an heuristic based on network communications to select the objects with the associated modules that should be offloaded. We close the chapter by testing our framework from the resource consumption, network communications, responsiveness, and frame rate perspectives.

Chapter 6 mainly focuses on the MEC. We saw in previous chapters that latency is central in computation offloading, particularly for real-time applications. For this aim, we bring computation resources closer to mobile users. In particular, we leverage MEC to perform computation offloading for facial recognition using a case study. This chapter begins by presenting the MEC, its architecture, and describing the technical terms used throughout the chapter, particularly those related to the MEC and LTE communications. Next, we review state-of-the-art, MEC-oriented computation offloading.

After that, we propose our framework, which relies on MEC, its services, and APIs to derive the user's equipment offloading decision. The framework is composed of three entities: middleware on both user equipment and the MEC server, and a mobile edge application that is responsible for the decision making in terms of computation offloading. The framework is then tested in a facial recognition use case.

Finally, concluding remarks are made in Chapter 7, and future directions and perspectives are discussed.

C H A P T E R 2 COMPUTATION OFFLOADING: CONTEXT

Introduction

Nowadays, mobile devices, such as smartphones and tablets, have become ubiquitous. Due to the incorporation of various captors and hardware functionality in one small box, they have become a constant fixture in many lives. This has increased the demand on the part of mobile users for computationally intensive applications, such as m-gaming, m-health, and m-learning. However, as far as we know, the capabilities of these mobile devices are very much constrained, creating a gap between performance and application requirements. A promising solution with which to extend the capabilities of these mobile devices is to leverage Cloud infrastructure or any resourceful platform to perform the computation, fully or partially, for the said applications. This solution is known as computation offloading.

Computation offloading not only saves energy and improves performance, it also makes execution of heavy-complex applications on powerless devices possible. A great deal of research has been done on computation offloading, such that of Mobile Assistance Using Infrastructure (MAUI in short) [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF],

Scavenger [START_REF] Kristensen | Scavenger: Transparent development of efficient cyber foraging applications[END_REF], and Spectra [START_REF] Flinn | Balancing performance, energy, and quality in pervasive computing[END_REF]. These examples, and others that we will review in this manuscript, seem to diverge on some criteria and converge on others. To better understand these works and the computation offloading concept, in general, we propose to review state-of-the-art computation offloading to understand the concept. In this chapter, we define the concept of computation offloading in the frame of the related work (e.g., [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF]), and extract some keystone similarities between most offloading frameworks, which are organized into several steps; profiling, modelling, partitioning, and communications. The aim is to propose a template to follow in order to design applications with certain elasticity and to improve the offloading performance via enhancement of these keystones. Then, we classify the computation offloading approaches into three types depending on when the aforementioned keystones are performed.

We also provide the historic evolution of the computation offloading concept. Afterwards, we focus on CHAPTER 2. COMPUTATION OFFLOADING: CONTEXT the relevance of several metrics in terms of computation offloading feasibility, performance, and gain.

Above all, we present the main advantages and disadvantages of computation offloading, and finally, we summarize, and introduce the next chapter.

Principals

The concept of computation offloading has been introduced in many forms over the years. Accelerated by the emergence of Cloud computing, virtualization technology advances, and wireless network technology improvements (including, mobile broadband), computation offloading attracted a tremendous amount of research to make it a reality. Besides reducing energy consumption [START_REF] Li | Computation offloading to save energy on handheld devices: a partition scheme[END_REF][START_REF] Li | Energy impact of secure computation on a handheld device[END_REF], computation offloading allows powerless devices (e.g., smartphones) to run CPU-intensive applications, such as 3D gaming [START_REF] Messaoudi | Dissecting games engines: The case of unity3d[END_REF], facial recognition [START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF], and 3D rendering [START_REF] Narayanan | Using history to improve mobile application adaptation[END_REF]. To clearly cover the topic, we present hereafter the decomposition of the concept into different steps followed by the offloading types according to timescale, and then, the history of the computation offloading concept.

Definition

Usually, computation offloading refers to the transfer of certain [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF] Giurgiu | Calling the cloud: Enabling mobile phones as interfaces to cloud applications[END_REF] or all [START_REF] Huerta-Canepa | A virtual cloud computing provider for mobile devices[END_REF][START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF] computing tasks of an application to an external platform, which includes clusters [START_REF] Begum | A dht-based process migration policy for mobile clusters[END_REF], grids [START_REF] Guan | A grid service infrastructure for mobile devices[END_REF] or the Cloud [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF],

in order for these to be executed there. The purpose behind this transfer is to extend the capabilities of today's powerless mobile devices and increase their batteries' autonomy. Upon successful execution, the results are sent back to the mobile device to be reintegrated with the application. To ensure a better harnessing of the computation offloading concept, it is necessary to design algorithms that decide which tasks of an application should be offloaded and when. Overall, most computation offloading frameworks rely on four steps, which we provide in detail below:

1. Application Profiling. This step consists of dissecting the application structure to estimate resource consumption investigating such things as processor time, energy consumption, and memory utilization.

A well-known technique for recording program behaviour and measuring its performance is to insert code into the program [START_REF] Ball | Optimally profiling and tracing programs[END_REF][START_REF] Fisher | Parallel processing: a smart compiler and a dumb machine (with retrospective)[END_REF][START_REF] Pettis | Profile guided code positioning[END_REF]. The granularity level of this estimation (e.g., class-or functionlevel) is determined by taking into account performance overheads and privacy concerns. Several systems and frameworks have been devised for computation offloading with dedicated profilers. For instance, MAUI [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF] evaluates the energy consumption of each method (i.e., function, procedure),

and ThinkAir [START_REF] Thinkair | Dynamic resource allocation and parallel execution in the cloud for mobile code offloading[END_REF] estimates the CPU cost, memory utilization, latency, and bandwidth utilization. For the same purpose, Scavenger [START_REF] Kristensen | Scavenger: Transparent development of efficient cyber foraging applications[END_REF] uses a dual, adaptive, history-based profiling approach to evaluate the execution time of an application, and Spectra [START_REF] Flinn | Balancing performance, energy, and quality in pervasive computing[END_REF] profiles the CPU time, network, power consumption, cache utilization, remote CPU consumption, and remote cache state for each task.

2. Application Modelling. Usually, in this step, we define a model to describe the problem based on the granularity defined in the precedent step. Most existing works are related to the methodologies used to identify the parts of the application that can be offloaded. Some works represent the application with a valued graph [START_REF] Han | A resource aware software partitioning algorithm based on mobility constraints in pervasive grid environments[END_REF], wherein the vertices correspond to the application components, valued with the resource consumption metrics of these components, while the edges represent the interactions between the components, valued with the frequency of calls and the amount of the exchanged data between the calls. The optimal solution is obtained with Integer Linear Programming (ILP) models [START_REF] Kovachev | Adaptive computation offloading from mobile devices into the cloud[END_REF]. Other studies rely on Markov theory [START_REF] Chen | A semi-markovian decision process based control method for offloading tasks from mobile devices to the cloud[END_REF] to design the mobile device platform with queues and Markovian Decision Processs (MDPs). Recent studies follow a game-theoretic approach to represent the application as a game between selfish players, in which equilibrium should be derived to satisfy each player [START_REF] Cardellini | A game-theoretic approach to computation offloading in mobile cloud computing[END_REF].

3. Application Partitioning. In this step, a decision is made for each component as to whether it should be offloaded or not. The decision is based on an objective function, such as improving performance or saving energy, that was assigned to the model in the previous step. The objective function may be resolved at run-time, which known as dynamic offloading [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF], or prior to the execution of the application, which is known as static offloading [START_REF] Cánepa | An adaptable application offloading scheme based on application behavior[END_REF]. Many algorithms have been proposed to solve the objective function. For instance, graph partitioning is done by applying graph partitioning algorithms to the resulting graph. Often, this is accomplished using maximum flow-minimum cut algorithms, such as the pre-flow-push [START_REF] Han | A resource aware software partitioning algorithm based on mobility constraints in pervasive grid environments[END_REF] or the Stoer-Wagner [START_REF] Niu | Bandwidth-adaptive partitioning for distributed execution optimization of mobile applications[END_REF]. The aim of such algorithms is to partition the graph representing the application into a minimum cut, which includes the local components in one partition, and the components, being considered for remote execution in the second partition. Since graph partitioning is NP-hard, heuristics can be used to efficiently approximate solutions when dealing with large graphs using branch and bound [START_REF] Li | Computation offloading to save energy on handheld devices: a partition scheme[END_REF], greedy [START_REF] Ra | Odessa: enabling interactive perception applications on mobile devices[END_REF], or genetic algorithms [START_REF] Deng | Computation offloading for service workflow in mobile cloud computing[END_REF].

Communication.

The last step consists in establishing a communications channel between the client and server to migrate the code and required data from the mobile device to the server and back again with the results of the computation. Various mechanisms have been used for communications in a client-server model. Some frameworks, such as Chroma [START_REF] Balan | Tactics-based remote execution for mobile computing[END_REF] and Spectra [START_REF] Flinn | Balancing performance, energy, and quality in pervasive computing[END_REF], use Remote Procedure Call (RPC), wherein the tasks are pre-installed on the server and ready for service. Thus, the desired functionality is always available on the server, and there is no need to install it on -demand. Despite their good performance, RPC solutions cannot be applied to a mobility environment which does not support RPC. Similar to RPC, Remote Methods Invocation (RMI) can be used for remote calls [START_REF] Friedman | COARA: code offloading on android with aspectj[END_REF] between Java Virtual Machines (JVMs). The Java objects are automatically serialized and sent to the remote JVM.

In Uniform Resource Locator (URL)-based download approaches [START_REF] Goyal | A lightweight secure cyber foraging infrastructure for resourceconstrained devices[END_REF], instead of migrating the code, an URL is sent to the server, indicating the location of the code to download.

To illustrate the aforementioned steps, we present the case described by Satyanarayanan et al. [START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF] in 2009.

Ron has recently been diagnosed with Alzheimer's disease. Due to the sharp decline in his mental acuity, he is often unable to remember the names of friends and relatives; he also frequently forgets to do simple daily tasks. He faces an uncertain future that is clouded by a lack of close family nearby and limited financial resources for professional caregivers.

Even modest improvements in his cognitive ability would greatly improve his quality of life, while also reducing the attention demanded from caregivers. This would allow him to live independently in dignity and comfort for many more years, before he has to move to a nursing home. Fortunately, a new experimental technology might provide Ron with cognitive assistance. At the heart of this technology is a lightweight wearable computer with a head-up display in the form of eyeglasses. Built into the eyeglass frame are a camera for scene capture and earphones for audio feedback. These hardware components offer the essentials of an augmented-reality system to aid cognition when combined with software for scene interpretation, facial recognition, context awareness, and voice synthesis. When Ron looks at a person for a few seconds, that person's name is whispered in his ear along with additional cues to guide Ron's greeting and interactions; when he looks at his thirsty houseplant, "water me" is whispered; when he looks at his long-suffering dog, "take me out" is whispered.

The eyeglasses architecture is composed of different applications, including Augmented Reality (AR), computer vision, and audio processing to serve different needs for users. Due to the resource-intensive nature of these applications and the intrinsic limitations of eyeglasses, offloading computationallyintensive functionality is needed to meet applications requirements, particularly for the delay-sensitive applications, such as AR [START_REF] Tsai | Integrating geographical information and augmented reality techniques for mobile escape guidelines on nuclear accident sites[END_REF]. glasses [START_REF] Doswell | Augmented learning: Context-aware mobile augmented reality architecture for learning[END_REF]. The system software architecture is made up of several services and subsystems: The visual subsystem is in charge of processing image recognition and facilitating real-world recognition.

The Human Computer Interface (HCI) subsystem is responsible for speech recognition and speech synthesis to allow natural interaction with the different learning interfaces. The Training subsystem is the logical entity which can host new functionality for future usage. The glasses have two main limitations: low computing capabilities and battery drains due to the high utilization of hardware resources, including the miniature camera, heads-up display, and mini-speakers. A solution is to offload the CPU-intensive functions to close-by, powerful, plugged machines (e.g., desktops).

For Ron, the real-time interaction is given top priority. Hence, to achieve such optimal execution in a mobile computing environment, the software components of the Google' glasses application should be computed in the most suitable location, considering their profiles. To efficiently distribute the application, we dissect it into class objects with consuming characteristics, such as processing time, energy consumption, and memory usage. This is the profiling step. For the modelling step, we use the dependency graph or call graph to represent the Google' glasses software, wherein each class may be a callee and/or caller vertex. Hence, a vertex represents a class, and an edge is an interaction between two classes. We valuate the vertices with the obtained statistics, such as the CPU-time, energy, and memory usage. For the edges, we use the call frequency between classes and data size exchange.

The third step consists of partitioning the graph obtained from the second step. For this, we use a Modelling:

• Model: Oriented Valued Graph • Vertices: -Each vertex is a class object -Each vertex is valued with: < α i , β i , γ i , δ i , l i > • Edges:
-Each edge is an interaction between two classes -Each edge is valued with:

< d i , c i > R/G/B 1/2 M1 R/G/B 1/2 Mi Mk Mn ... M1 Mi R/G/B 1/2 Mk R/G/B 1/2 Mn ... ... 1 2
Near-End Front-End Partitioning:

• Algorithm: min-cut/max-flow (Stoer-Wagner)

Communication:

• mechanisms: RMI, RPC, MA, SOA, Command, Stream

Offloading Types

When computation offloading follows the steps described above, it should confront with the performance and overhead1 trade off. To this aim, three time-based approaches (static, dynamic, and hybrid) have been proposed in the literature and are discussed in the following.

Static offloading. As shown in Figure 2.2a, static offloading occurs at the start-time [32, 98, 166-168, 193, 213, 217, 237, 239, 277, 304]. In this mechanism, the application is partitioned only one time into two partitions: the local partition contains the local components, and the remote partition contains components being considered for remote execution. The partitioning process occurs prior to execution at the design or installation stage of the application, after analysing and profiling the code. The aim is to identify the software components with resource bottlenecks. These components will constitute the remote partition. Spectra [START_REF] Flinn | Balancing performance, energy, and quality in pervasive computing[END_REF], Chroma [START_REF] Balan | Tactics-based remote execution for mobile computing[END_REF], and MISCO [START_REF] Dou | Misco: a mapreduce framework for mobile systems[END_REF] are three frameworks using static offloading.

Dynamic offloading. Runtime or dynamic offloading is proposed to cope with the limitations of the static approach (which is becoming obsolete) with the dynamic processing load at runtime [START_REF] Chen | Studying energy trade offs in offloading computation/compilation in java-enabled mobile devices[END_REF][START_REF] Chu | Roam, a seamless application framework[END_REF][START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF] Gu | Adaptive offloading inference for delivering applications in pervasive computing environments[END_REF][START_REF] Hong | Energy efficient content-based image retrieval for mobile systems[END_REF][START_REF] Kremer | A compilation framework for power and energy management on mobile computers[END_REF][START_REF] Nimmagadda | Real-time moving object recognition and tracking using computation offloading[END_REF][START_REF] Ou | Performance analysis of offloading systems in mobile wireless environments[END_REF][START_REF] Seshasayee | Energy-aware mobile service overlays: Cooperative dynamic power management in distributed mobile systems[END_REF][START_REF] Sivavakeesar | Service discovery strategies in ubiquitous communication environments[END_REF][START_REF] Wang | Parametric analysis for adaptive computation offloading[END_REF][START_REF] Wolski | Using bandwidth data to make computation offloading decisions[END_REF][START_REF] Yang | On effective offloading services for resource-constrained mobile devices running heavier mobile internet applications[END_REF]. Indeed, the dynamic approach is more flexible, and it can adapt to different runtime conditions, such as changes in network latency, bandwidth, available energy, the computation loads on mobile devices and remote servers. The dynamic approach, as shown in Figure 2.2b, processes the aforementioned steps at run time. That is, all the offloading steps are done in real-time, when the application is running. MAUI [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF] is a framework that is based on dynamic partitioning.

Hybrid offloading. In order to benefit from both static and dynamic offloading strengths, the hybrid (or semi-dynamic) approach has been proposed by Canepa and Lee et al. [START_REF] Cánepa | An adaptable application offloading scheme based on application behavior[END_REF]. A part of the decision is done by the programmer-defined specification and static analysis tools, while the other part is done during the runtime as depicted in Figure 2.2c. The aim behind mixing the dynamic and static approaches was to minimize the side effects of profiling and waiting time (i.e., overhead). This solution does not always result in good performances as the execution time on a mobile device is short. Murarasu and Magedanz [START_REF] Murarasu | Mobile middleware solution for automatic reconfiguration of applications[END_REF] have presented a middleware layer, between services and programs. This middleware supports static and dynamic reconfiguration of services and programs, monitors resource consumption, and manages the offloading to remote servers.

Comparison. Table 2.1 provides a comparison between the three time-based solutions.

Offloading Evolution and History

Computation offloading has been introduced over time in different forms with different objectives. Prior to 2000, researchers mostly focused on making computation offloading feasible, as the primary limitation in this period was network technologies. In the early 2000s, the main focus was on improving the gain and Hailes [START_REF] Othman | Power conservation strategy for mobile computers using load sharing[END_REF] in order to conserve the resources of mobile devices. The authors were inspired by the load balancing concept in distributed systems. In this solution, the entire computation job is migrated to a remote server for computation. The system considers some metrics, including job size, available bandwidth, and result size. The aim was to estimate whether the system can save energy or not. However, this method suffers from a lack of triangulation, wherein the jobs and data transit through a third-party device, which is responsible for finding the appropriate server and forwarding the results back to the mobile device. Furthermore, the computing servers are fixed, and the model does not take into account the user and code mobility at runtime.

Remote Execution. Remote execution became feasible with the work of Rudenko et al. [START_REF] Rudenko | The remote processing framework for portable computer power saving[END_REF][START_REF] Rudenko | Saving portable computer battery power through remote process execution[END_REF] in 1998. The authors addressed this solution for mobile computers (particularly laptops). This method saves energy when the remote processing cost is lower than the local processing cost. It is not sufficiently mature as it neglects the environment characteristics and the speed ration between the mobile computer and the remote server. Furthermore, the entire application needs to be migrated prior to execution.

Cyber Foraging. Cyber foraging is the process of dynamically augmenting the computing resources of a wireless mobile computer by exploiting wired hardware infrastructure. It is a re-definition of remote execution, introduced by Satyanarayana [START_REF] Satyanarayanan | Pervasive computing: vision and challenges[END_REF] in 2001 for pervasive computing. The two key ideas are the consideration of surrogates and dynamism in the remote execution process. Surrogates are static, idle computers located in the near vicinity of mobile devices that are acting as servers. These surrogates include personal computers and public servers; they are connected to uninterrupted power sources and wired Internet to provide unpaid computing resources. The entire application is stored in the mobile device. Therefore, a large overhead appears when identifying and partitioning intensive code, which can exceed conserved resources. Cyber foraging has been used in pervasive computing [START_REF] Balan | Simplifying cyber foraging for mobile devices[END_REF][START_REF] Cánepa | An adaptable application offloading scheme based on application behavior[END_REF][START_REF] Flinn | Balancing performance, energy, and quality in pervasive computing[END_REF][START_REF] Gu | Adaptive offloading for pervasive computing[END_REF][START_REF] Kalasapur | Resource adaptive hierarchical organization in pervasive environments[END_REF][START_REF] Kristensen | Scavenger: Transparent development of efficient cyber foraging applications[END_REF][START_REF] Su | Slingshot: deploying stateful services in wireless hotspots[END_REF], grid computing [START_REF] Li | Energy constrained resource allocation optimization for mobile grids[END_REF][START_REF] Oh | An adaptive mobile system using mobile grid computing in wireless network[END_REF][START_REF] Park | Selective grid access for energy-aware mobile computing[END_REF][START_REF] Storz | Towards 'ubiquitous' ubiquitous computing: an alliance with 'the grid[END_REF], and Cloud computing [START_REF] Buyya | Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility[END_REF][START_REF] Chun | Clonecloud: elastic execution between mobile device and cloud[END_REF][START_REF] Chun | Augmented smartphone applications through clone cloud execution[END_REF][START_REF]Dynamically partitioning applications between weak devices and clouds[END_REF][START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF]The smartphone and the cloud: Power to the user[END_REF][START_REF] Kemp | eyedentify: Multimedia cyber foraging from a smartphone[END_REF][START_REF] Kosta | Unleashing the power of mobile cloud computing using thinkair[END_REF][START_REF] Kumar | Cloud computing for mobile users: Can offloading computation save energy?[END_REF].

Cloudlet is a variant of cyber foraging introduced by Satyanarayana. The aim is to reduce network latency by moving the server closer to mobile devices [START_REF] Jararweh | Scalable cloudlet-based mobile computing model[END_REF][START_REF] Jararweh | Resource efficient mobile computing using cloudlet infrastructure[END_REF][START_REF] Verbelen | Cloudlets: Bringing the cloud to the mobile user[END_REF][START_REF] Wu | Cloudlet-based mobile offloading systems: a performance analysis[END_REF].

Computation Offloading. With the introduction of MCC, network communication technologies (3G, LTE, 5G, and Wi-Fi with high throughput), the latest efforts to address security in Cloud computing, the QoS, and reliability issues, computation offloading is gaining ground. Indeed, a significant amount of research has been performed on computation offloading, introducing various algorithms to make offloading decisions. These decisions are usually made by analysing parameters such as bandwidth, server speed, available memory, server load, network latency, and the amounts of data exchanged between servers and mobile systems. Offloading requires access to resourceful computers for short durations through networks, wired or wireless. These servers may use virtualization to provide offloading services so that different programs and their data are isolated and protected. defining a reference architecture and a set of Application Programming Interfaces (APIs) 6 . Combined with 5G mobile access, which aims to drastically reduce the end-to-end latency, MEC enables a plethora of novel mobile services that require short latency to access data or computation capabilities nearby, at the mobile edge. Among the envisioned services are computation-offloading-driven applications, which need to offload part of the execution of their applications code to a remote server. Chapter 6 is dedicated to MEC-oriented computation offloading.

We were interested in reviewing timely, both quantitatively and comprehensively, state-of-the-art research on the aforementioned transitions. We selected the ACM Digital Library and IEEE Xplore Digital Library to examine how many papers were published per year in the period 1998 to September 2017. The publications included journals, magazines, proceedings, and books. The aim of this research was to identify the key enabling concepts used in the landscape of computation offloading, to position our research on these axes, and to find the open research challenges to consider for our PhD thesis. The search keywords were "load sharing," "remote execution," "cyber foraging," "computation offloading,"

and "edge offloading." Various papers used other words semantically similar to our keywords list.

Therefore, we included in our search all papers wherein one of the following expressions appears: "tasks offloading," "computation outsourcing," "MEC offloading," and "FOG offloading." We also looked for papers in which the keywords were switched in cases where the composition of the two words was semantically correct (e.g., we searched for papers using "offloading task" and "outsourcing computation,"

but not "offloading MEC" or "foraging cyber"). The keywords were found in the title, abstract, research terms, or in the body of the papers. From the obtained results, we excluded the same papers according to the title. We present in Table 2.2 the results of our search using a comparison of the above-cited approaches from the view of architecture used between the mobile device and the external platform, the cost and complexity of implementation, the QoE, the network delay, the possibility of migrating and partitioning the application, the mobility of the mobile user, and the security of data. Throughout this document, we use the terms computation offloading, remote execution, cyber foraging, and edge-based offloading interchangeably.

Metrics

Herein, we will be discussing the suitability of a range of metrics for an optimal offloading of mobile applications, particularly delay-sensitive applications. Figure 2.4 illustrates these metrics and classifies them into five areas namely: (i) user preferences and requirements, (ii) mobile devices, (iii) application

METRICS

specifications, (iv) external platform, and (v) network specifications. We describe below the significance of each metric and how each impedes the offloading computation process.

1. User preferences and requirements. The offloading decision is affected by the user's physiological, physical, and mental states, his mobility, the goals to be achieved, the budget, the Quality of Service (QoS), the tasks and actions to process, and the individual and corporate preferences of the user [START_REF] Krogstie | Requirement engineering for mobile information systems[END_REF].

Some users, unlike others, are more interested in confidentiality and the privacy level, and they do not use risky channels on the Internet to offload confidential data. Other users, are more interested in good QoS/QoE, considering their budget. Frequent mobility impacts the link failure across the mobile network [START_REF] Lenders | Analyzing the impact of mobility in ad hoc networks[END_REF], and therefore the computation offloading performance.

2. Mobile devices. The hardware configuration and OS used are important in computation offloading.

Regarding the hardware, mobile devices have different configurations, which include CPU/GPU architecture and frequency, battery autonomy, memory capacity, and storage size. It is plainly evident that using a large memory prevents page fault exceptions and the paging process, a multi-core CPU better exploits parallel executions, and large battery autonomy increases the operational time for the mobile device. Considering the OS, each has a different architecture with different interruptions, scheduling policies, and algorithms for page replacement in caches, central memory management, and swaps. The access technology used is also vital in terms of the usability of computation offloading regarding latency and packet delivery, which can lessen the Quality of Experience (QoE).

3. Application specifications. Applications also impact the offloading decision. Indeed, code granularity, size, and data type are attributes impacting any decision. Moreover, the usual mobile applications exhibit six profiles, in terms of the users' needs, namely: CPU/GPU-, I/O-, memory- [START_REF] Zhang | Application classification through monitoring and learning of resource consumption patterns[END_REF], network- [START_REF] Ballagas | Rexplorer: a mobile, pervasive spell-casting game for tourists[END_REF], or security-intensive [START_REF] Cano | A secure energy-efficient m-banking application for mobile devices[END_REF][START_REF] Khan | Towards secure mobile cloud computing: A survey[END_REF], plus delay-sensitive [START_REF] Nazir | Time critical content delivery using predictable patterns in mobile social networks[END_REF]. Therefore, the application profile is another important attribute for decision making. In essence, computation offloading should consider the complexity of, data for, and nature of the application. However, some exceptions may occur; depending on the granularity level, some components of the application cannot be offloaded due to code dependency on: (i) the hardware, such as I/O and sensors; (ii) the OS (i.e., the component is a native code); or (iii) the user (user interfaces) [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF] Gu | Adaptive offloading for pervasive computing[END_REF][START_REF] Othman | Power conservation strategy for mobile computers using load sharing[END_REF][START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF][START_REF] Ou | An efficient runtime offloading approach for pervasive services[END_REF].

4. External platforms. The remote infrastructure impacts highly computation offloading performance [START_REF] Zhang | Towards an elastic application model for augmenting computing capabilities of mobile platforms[END_REF]. The server cost is measured with processor cycles, memory size, throughput, input data size, availability, elasticity, vulnerability to security attacks, and reliability in terms of delivering services within the agreed terms and conditions [START_REF]The smartphone and the cloud: Power to the user[END_REF]. Moreover, the greater the distance between the server and mobile device, the higher the network latency and more modest the performance improvement.

5. Network specifications. According to the geographical scope and distance of connected nodes, we classify networks into three categories, namely, the Local Area Network (LAN), Metropolitan Area Network (MAN), and Wide Area Network (WAN) [START_REF]Unleashing the power of mobile cloud computing using thinkair[END_REF]. Cloudlets are usually located in LAN networks, while the Cloud is hosted in the WAN [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF]. The necessity of mobility reduces the usability of CHAPTER 2. COMPUTATION OFFLOADING: CONTEXT networks to those using only wireless technology (such as 3G/4G, and Wi-Fi). These technologies have different features (including latency, throughput, and packet delivery), which impact the computation offloading performance. Furthermore, the dynamic and rapidly changing mobile environment, user mobility, and weather conditions also play an important role in offloading attainment.

Advantages and Disadvantages

Computation offloading is a critical technology that takes part in mobile Cloud computing, mobile edge computing, and 5G architecture. It is considered to be an enabler technology for intensive applications.

In this section, we turn our attention to point out its merits and demerits.

Advantages

Computation offloading provides, but is not limited to, the following advantages:

1. Improves performance. By performance improvement, we mean execution time. Mobile users nowadays are interested in migrating their favourite applications and office work to their mobile devices.

Nevertheless, these applications are usually computationally intensive, and either cannot run on powerless mobile devices, or can run with a low QoE. Due to computation offloading, running such applications on mobile devices became reality [START_REF] Chu | Roam, a seamless application framework[END_REF][START_REF] Gu | Adaptive offloading inference for delivering applications in pervasive computing environments[END_REF][START_REF] Messer | Towards a distributed platform for resource-constrained devices[END_REF][START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF][START_REF] Rim | Transparent method offloading for slim execution[END_REF][START_REF] Sivavakeesar | Service discovery strategies in ubiquitous communication environments[END_REF][START_REF] Tilevich | J-orchestra: Automatic java application partitioning[END_REF][START_REF] Wang | Parametric analysis for adaptive computation offloading[END_REF].

2. Saves energy. Manufacturers are proposing multi-core ARM processors (CPU/GPU) with high clock speed that address power and cost requirements. Furthermore, movies, games, animations, and graphics have become an important part of mobile users' experiences. Increasing the performance of mobile devices means higher energy consumption. With computation offloading, energy can be saved by outsourcing the energy-intensive tasks from mobile devices [START_REF] Chen | Studying energy trade offs in offloading computation/compilation in java-enabled mobile devices[END_REF][START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF] Hong | Energy efficient content-based image retrieval for mobile systems[END_REF][START_REF] Kremer | A compilation framework for power and energy management on mobile computers[END_REF][START_REF] O'hara | Autopower: Toward energy-aware software systems for distributed mobile robots[END_REF][START_REF] Pedram | Extending the lifetime of a network of battery-powered mobile devices by remote processing: a markovian decision-based approach[END_REF][START_REF] Seshasayee | Energy-aware mobile service overlays: Cooperative dynamic power management in distributed mobile systems[END_REF][START_REF] Xian | Adaptive computation offloading for energy conservation on batterypowered systems[END_REF].

ADVANTAGES AND DISADVANTAGES

3. Augments storage. Due to the limited space on their devices, mobile users have to install and remove applications frequently and control the size and type of data stored on their devices. One solution for managing these data is to save them on an external storage-resourceful machine, such as servers on the Cloud. Such a solution maintains applications outside mobile devices, provides remote access to them, and updates the code without any I/O transactions, therefore enhance the QoE and saving energy [START_REF] Kim | An intermediate target for quick-relay of remote storage to mobile devices[END_REF][START_REF] Kim | Misc: A new availability remote storage system for mobile appliance[END_REF][START_REF] Ok | Ubiqstor: A remote storage service for mobile devices[END_REF][START_REF]Ubiqstor: Server and proxy for remote storage of mobile devices[END_REF][START_REF] Park | Design and implementation of iscsi-based remote storage system for mobile appliance[END_REF].

4. Reduces memory usage. Recent operating systems are able to run various applications simultaneously. Some of these applications, such as social media (e.g., WhatsApp and Facebook), are memoryintensive applications. Keeping these running applications' states, will quickly fill the memory. Hopefully, computation offloading can reduce the memory utilization by offloading the memory-intensive parts of these applications [START_REF] Gu | Adaptive offloading inference for delivering applications in pervasive computing environments[END_REF].

5.

Enriches the user experience. QoE and interactivity are the main criteria that impact the immersion of mobile users. According to Tolia et al. [START_REF] Tolia | Quantifying interactive user experience on thin clients[END_REF], an interaction delay higher than 1 s is not acceptable to mobile users. A delay becomes tolerable within the range of 150 ms and 1 s; below 150 ms, the mobile user's immersion is not affected. Computation offloading can guarantee a good QoE by focusing on the interaction delay.

6. Increases data safety. Using Cloud storage increases the size limit for and safety of stored data.

Saving data on mobile devices is risky due to device robbery, physical damage, or malfunctions. It also degrades the QoE, and increases energy consumption, especially when a secure encryption is performed on these devices. By storing data on a secure Cloud [START_REF] Bowers | HAIL: a high-availability and integrity layer for cloud storage[END_REF][START_REF] Wang | Toward publicly auditable secure cloud data storage services[END_REF][START_REF] Wang | Hierarchical attribute-based encryption for fine-grained access control in cloud storage services[END_REF][START_REF] Yang | An efficient and secure dynamic auditing protocol for data storage in cloud computing[END_REF][START_REF] Zeng | Research on cloud storage architecture and key technologies[END_REF][START_REF] Zheng | Design a cloud storage platform for pervasive computing environments[END_REF] users ensure data availability and safety anytime, anywhere, and from any mobile device.

7. Ubiquitous data access and content sharing. Adding to its temporal cost, copying data from one device to another is a risky practice as the data may be corrupted. Storing the data in the Cloud is a safe practice, and it improves the user experience. Indeed, remote storage enables mobile users to access their digital data regardless of time and place. Moreover, the data can be shared among different legitimate users.

8. Protects offloaded content. Cloud providers are deploying strict policies for security and privacy to protect user's code and data, ensure confidentiality, and secure properties and businesses. Virtualization in the Cloud also ensures privacy and security for customers. Furthermore, Cloud providers are using biometric security systems to protect their infrastructure and avoid unauthorized access; such systems include finger-, and retina-scan. Cryptography, frequent patching, and continuous virus signature updates are other forms of security [START_REF] Yang | Provable data possession of resourceconstrained mobile devices in cloud computing[END_REF].

Disadvantages

Computation offloading faces some limitations as outlined below.

1. Dependency on network conditions. The fact that computation offloading depends on network communications is a major issue. Indeed, offloading gain is highly affected by network characteristics.

Leveraging the Cloud infrastructure requires network communications, which is adversely affected by high WAN latency, non-guaranteed bandwidth, jitter, packet losses, and the non-deterministic traffic along the path.

2. Network and local latencies. Network latency affects significantly computation offloading since latency is a part of the interaction delay. Therefore, latency limits the use of computation offloading to delay-tolerant applications. Local latency is hit by the offloading steps, especially modelling and partitioning. For instance, graph partitioning is an NP-hard problem, and its resolution might take a long time. This leads to delayed decisions, which could be incorrect.

Code profiling.

To make an offloading decision, the system needs to profile an application in order to estimate its resource consumption and obtain a call graph, which is an intensive operation. The resource consumption of the different software components (according to the granularity level) may include the processing time, energy consumption, and communications between modules. Profiling can provide incorrect estimations, fill up the storage, and considerably consume energy on mobile devices.

4. Tolerance for partitioning. Offloading frameworks should distinguish between monolithic and distributable applications [START_REF] Messaoudi | Dissecting games engines: The case of unity3d[END_REF]. Indeed, the application requesting offloading should tolerate component partitioning. Determining this is arduous, as a complete knowledge of the application is needed to identify code dependencies.

5. Framework complexity. When frameworks incorporate several parameters in decision making, the system becomes complex to manage and solve, which means the consumption of more energy and occupying more space due to the profiling of various metrics. Therefore, this increases the local latency and stresses the offloading process due to components moving back and forth between between local and remote partitions.

6. Security Issues. Leveraging the Cloud is a risky practice, especially for enterprise users, wherein competitors might access the offloaded confidential and financial data of other companies. Moreover, the risky Internet channel is a central concern. Indeed, packets might be captured and modified. Regarding mobile devices, security is also a challenge. In fact, malicious resource providers might attack mobile users to access to their private data or falsify offloading results.

Conclusion

Computation offloading is highly promoted for MCC, MEC, and the upcoming 5G systems. This will results in a plethora of applications and services. However, more investigation is necessary in order to evolve the computation offloading frameworks, optimize them, and move toward the next generation of frameworks with which to integrate with 5G scenarios, such as vehicles and m-heath, in which seamless and real-time constraints are on the top priority.

CONCLUSION

Throughout this chapter, we have defined the computation offloading concept. We surveyed the state-of-the-art computation offloading approaches from different perspectives. We highlighted the main steps employed in computation offloading architecture and projected them onto a scenario based on Google glasses. We classified the offloading mechanisms into three time-scale approaches, namely, static, dynamic, and semi-dynamic offloading. After that, we proposed an historical evolution of computation offloading that we quantified through the published papers in the literature. We classified the metrics impacting computation offloading into five areas (mobile devices, external platform, user requirements and preferences, applications specifications, and network characteristics). Finally, we discussed the advantages and disadvantages related to computation offloading. Overall, this introductory chapter provides an understanding of the computation offloading concept. In the following chapters, an exhaustive taxonomy of computation offloading will be provided.

C H A P T E R

3

COMPUTATION OFFLOADING: TAXONOMY REVIEW

Introduction

Computation offloading is considered to be corner stone of MCC, mobile gaming, MEC, and the upcoming 5G networks. Computation offloading allows code distributing and portability, and improved performance. However, deploying such a system is complex due to a large number of problems, which are, but are not limited to, network and Cloud heterogeneity, application complexity, and code ability for offloading. Researchers in industry and academia have devised many frameworks for computation offloading, the latest of which manage some challenges and limitations of past frameworks. These research works have covered the actors involved in computation offloading, as defined in Chapter 2, namely, the mobile user, mobile device, application, network, remote infrastructure, and offloading framework, each of which describes a set of challenges and issues. We propose in the following, a comprehensive survey that studies state-of-the-art computation offloading from different points of view according to the actors that impede the offloading process. We propose a thematic taxonomy that reviews comprehensively and qualitatively, computation offloading approaches from different perspectives. That is, from each side, we identify several challenging concepts described in past studies. Finally, we review several frameworks and propose a qualitative comparison from different perspectives.

Computation Offloading Taxonomy: From the User Perspective

This section provides the reader with state-of-the-art, optimization-based strategies for frameworks.

A comparison between various frameworks on the basis of significant optimization parameters that affect performance is also provided in this section. Some mobility models described in the literature are highlighted, after which we discuss the mobile users' concerns regarding computation offloading.

Figure 3.1 depicts the axes on which we focus in this section, namely the objective function, mobility, and concerns regarding mobile users in a computation offloading environment.

Objective Function

The aim behind computation offloading is to fulfil the requirements of various types of applications by leveraging remote infrastructures. Most frameworks focus on three main requirements: (i) performance, which is expressed by execution time, (ii) energy expressed by the energy saved through computation offloading, and (iii) memory, where the objective is to save or extend the memory of the mobile device.

We study in Appendix A.1, the gains obtained by computation offloading through proposed mathematical models. Hereafter, we classify state-of-the-art computation offloading frameworks according to the number of involved parameters in the objective function. This results in three models, namely, the mono-, bi-, and multi-objective models.

Mono-objective model

The mono-objective frameworks mainly focus on the optimization of a single parameter. It is a straightforward optimization model. However it cannot meet the requirements of applications in an heterogeneous execution environment. Herein, we present some frameworks that use mono-objective models:

(a) CloneCloud [START_REF] Chun | Clonecloud: elastic execution between mobile device and cloud[END_REF] is a Cloud-based system that clones the mobile device platform with a VMhosted platform in the Cloud. The implementation is based on Java DalvikVM. It is proposed to empower mobile applications through offloading computation to the Cloud. It is a dynamic offloading framework, with the objective function to optimize the overall execution cost of mobile applications. The authors have split the execution cost into a computation cost, C omp(E ), and a migration cost, Mi g r (E ). The 3.2. COMPUTATION OFFLOADING TAXONOMY: FROM THE USER PERSPECTIVE energy consumption cost is is expressed as:

C (E ) = C omp(E ) + Mi g r (E ) (3.1) C omp(E ) = � i ∈E ,m [(1 -L(m).I (i , m).C c (i , 0) + L(m).I (i , m).C (i , 1))] (3.2) Mi g r (E ) = � i ∈E ,m R(m).I (i , m).C s (i ) (3.3)
For every invocation i ∈ E , the computation cost C omp(E ) takes its value from the mobile device cost variables C c (i , 0) or the clone cost variables C c (i , 1) depending on whether the invoked method m will be run on the mobile device or in the Cloud. The migration cost Mi g r (E ) sums the individual migration costs C s (i ) of each invoked method i that is a migration point. The optimization problem has been modelled using an ILP wherein the objective is to find value of a decision variable R(i ) for the method i that minimizes the ), under the constraints:

� E ∈S C (E
L(m 1 ) � = L(m 2 ) ∀m 1 , m 2 : DC (m 1 , m 2 ) = 1 ∧ R(m 2 ) = 1 (3.4) L(m) = 0 ∀m ∈ V m (3.5) L(m 1 ) = L(m 2 ) ∀m 1 , m 2 ,C : m 1 , m 2 ∈ V N at c (3.6) R(m 2 ) = 0, ∀m 1 , m 2 : T C (m 1 , m 2 ) = 1 ∧ R(m 1 ) = 1 (3.7)
Equation 3.4 is a soundness constraint, which stipulates that a method m 1 , which causes a migration to happen, cannot be located in the same location as its caller method, m 2 . Constraint 3.5 is a dependency constraint, wherein methods annotated to be pinned on the mobile device run only on the mobile device. Constraint 3.6 ensures that methods depending on the same class state are collocated, at either location. Finally, constraint 3.7 ensures that all methods transitively called by a migrated method cannot, themselves, be migrated.

As stated above, R(m) is the decision variable that represents the modification (i.e., R(m) = 1) or not (i.e., R(m) = 0) of the method m, which is done through an insertion of a migration point in the entry of the method.

(b) CODM [START_REF] Verbelen | Dynamic deployment and quality adaptation for mobile augmented reality applications[END_REF] is a middleware aimed at selecting and deploying the application configuration that offers the best quality possible, according to the current available resources and connectivity. The deployment granularity of the middleware is a bundle. For each bundle, the framework provides multiple configurations with different levels of resource consumption and quality levels. The objective function is given by: M ax con f i g ur at i ons

� i w i s.t .    ∀m : � i X i m × w i ≤ M m ∀i : � i X i m = 1 (3.8)
where w i represents the cost (CPU power) of the i t h bundle, and X i m is the decision variable that is equal to 1 if the bundle i is assigned to the machine m (m ∈ 0, 1) (mobile device or Cloud) and 0 otherwise. The first constraint ensures that the sum of the weights of all bundles deployed on the machine m cannot exceed the maximum allowed weight, while the second constraint stipulates that a bundle i of the configuration is deployed either on the mobile device or on the Cloud. The framework adapts dynamically the configuration and deployment of the bundles, but also degrades gracefully the quality level in some cases. However, the framework requires different configurations of the application and relies on the OSGi framework.

(c) MAUI [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF] is an energy-aware framework that operates on method granularity. It employs both static and dynamic partitioning. The framework requires programmer efforts to annotate the application methods as remotable or not. MAUI uses a timeout mechanism to detect connection failures with the remote server. The authors have drawn the optimization problem for an ILP as follows:

M ax � v∈V I v × E l v - � (u,v)∈E |I u -I v | × C u,v s.t . � v∈V � (1 -I v ) × T l v + � I v × T r v � � + � (u,v)∈E � |I u -I v | × B u,v � ≤ L and I v ≤ r v , ∀v ∈ V (3.9)
where I v is the decision variable, and

I v = 0 (I v = 1, resp.) if the method v is executed locally (offloaded, resp.
). E l v and T l v denote, respectively, the energy consumption and execution time of method v locally. B u,v represents the necessary program state when u calls v, and C u,v is the energy cost of the transferring state, and finally, r v indicates if the method v is remotable (i.e., r v = 1) or not remotable (i.e., r v = 0).

(d) Yang et al. [START_REF] Yang | A framework for partitioning and execution of data stream applications in mobile cloud computing[END_REF] have studied how to optimize the computation partitioning of a data stream application between mobile devices and the Cloud to achieve a maximum speed/throughput in processing the streaming data. The partitioning problem has been formulated as a weighted dataflow graph and then drawn into an ILP with the objective to maximize the data stream throughput. The ILP is given by: M ax x i ,y i , j T P = 1 t p , i , j ∈ {0, 1, ..., v + 1} wher e t p = max

� max i ∈V � x i × S i ηρ � i ∈V x i � , max (i , j )∈E � d i , j � x i , y i � 2 y i , j �� s.t .                          � i , j ∈E y i , j (x i -y i ) 2 = B, y i , j > 0, x 0 = 1, x v+1 = 1, x i = 0 or 1, i ∈ {1, 2, ..., v} (3.10)
ρ and η represent, respectively, the CPU capability of the mobile device and its workload, and B is the current network bandwidth. Next, x i and y i , j are the core variables, and x i is the decision variable: when x i = 1 (x i = 0, resp.), component i is computed locally (offloaded, resp.). Finally, y i , j is the wireless bandwidth allocated to channel (i , j ).

Bi-objective model

In bi-objective models, the main focus is on optimizing two parameters. Bi-objective optimization-based frameworks are relatively complex compared to the mono-objective frameworks. These frameworks aim to optimize simultaneously the two parameters in the objective function. This produces a better fit to diverse environments and fulfilment of the applications' requirements.

(a) AIOLOS [START_REF] Verbelen | AIOLOS: middleware for improving mobile application performance through cyber foraging[END_REF] is a mobile, middleware-based cyber foraging system. The framework operates at method granularity level. It relies on an estimation model of both local and remote resources, with a network state to dynamically decide whether or not a method should be offloaded. AIOLOS is built on OSGi1 , with the objective to optimize both the local execution time and energy consumption. The authors use a history-based profile to estimate the local execution time TCPU,local . The formula to estimate the remote execution time is given by:

Tremote = 1 α × � i ∈RM ( TCPU,local i ) + 1 β × (A + R) + γ + � j ∈C M � TCPU,local j + 1 β × (A j + R j ) + γ � (3.11)
where α is the speedup factor of processing, and β and γ represent, respectively, the network bandwidth and latency. R M and C M define, respectively, the collection of remotely executed methods and the collection of callbacks. Finally, A and R are, respectively, the input and output sizes. For energy optimization, the authors have presented a simple decision model in which a method is offloaded only when the energy consumed by sending and receiving bytes to and from the server is smaller than the energy saved by offloading the computation. The proposed formula is given in Eq. 3.12, where E C PU denotes the energy consumption per time unit by the CPU, and E T R and E RCV denote, respectively, the energy cost for the transmission and reception of a byte of data.

Êsaved = E C PU × � i ∈RM ( TCPU,local i ) -E T R × A -E RCV × R - � j ∈C M � E RCV × A j + E T R × R j � > 0
(3.12)

Multi-objective model

The multi-objective optimization-based frameworks focus on the optimization of multiple parameters.

These frameworks are more complex in comparison to the mono-objective and bi-objective frameworks.

The multi-objective frameworks include multiple parameters in the objective function. These frameworks are more adapted to heterogeneous computing environments. Hereafter, we present some of these frameworks.

(a) AIDE [START_REF] Gu | Adaptive offloading inference for delivering applications in pervasive computing environments[END_REF] is a fine-grained dynamic offloading system. The authors have focused on three metrics: bandwidth requirement, interaction frequency, and memory size. A coalescing process based on a minimum-cut heuristic algorithm [START_REF] Stoer | A simple min-cut algorithm[END_REF] has been implemented to find all possible 2-way cuts of the execution graph. In the beginning, the authors created two partitions. The first partition contains the classes that should be executed on the mobile device, these nodes are merged together to make one node.

The second partition encloses the rest of the nodes. Next, the authors have repeated the following rules, until all the nodes are merged together in the first partition: (i) They selected the least memory-intensive class with the largest interaction frequencies and bandwidth requirements from the second partition in such a way that this node is a successor node to the merged node (partition one); (ii) next, they merged the selected node with partition one; (iii) in each step, a possible 2-way cuts is generated, and (iv) at the end of the process, the authors selected the 2-way cut that minimizes the metrics defined above.

Therefore, to select the best 2-way partitioning, the authors have to compare between two metrics C k , C l as follows: C k > C l if and only if:

w 1 × b i ,k -b i ,l b max + w 2 × f i ,k -f i ,l f max + w 3 × M l -M k M max > 0 (3.13)
where w i (1 < i < 3) is the weight of the i t h metric in the decision making; b max , f max and M max represent the maximum values of the inter-class bandwidth requirement, inter-class interaction frequency, and class memory size, respectively; b i , j , f i , j , and M i represent, respectively, the bandwidth requirement from class i to class j , the number of interactions between the two classes i and j , and the memory size of class i .

(b) Elastic Application [START_REF] Zhang | Towards an elastic application model for augmenting computing capabilities of mobile platforms[END_REF]. Zhang et al. have designed a framework for elastic applications enabling the use of Cloud resources in an optimal and transparent manner. The proposed framework includes four attributes of the optimization-based model; energy, monetary cost, throughput, and security/privacy. The authors, through their model, wish to minimize both energy consumption and the cost, while maximizing the throughput, and security and privacy. Applications are partitioned into various weblets that are replicated across multiple Clouds aiming at improving the availability and reliability. The objective function is given by: y * = ar g max y p(y)

L � i =1 p(x i |y) M � j =1 p(z j |y) (3.14)
where x and z are vectors; x contains values of different device status components, including the throughput, memory usage, upload bandwidth, and file cache; z contains a user's preferred option values, such as processing speed and monetary cost; y represents the sum of all configurations; and L (M, resp.) is the number of components in the status (preference, resp.) vector. As the framework is for multi-objective decision making, additional computing resources are needed to solve the optimization problem, which may take a long time.

(c) Mobile Augmentation Cloud Services (MACS) [START_REF]Adaptive computation offloading from mobile devices into the cloud[END_REF] is a middleware enabling a lightweight partitioning with seamless execution of applications in the Cloud. The framework is devised for android applications. To make a decision to offload a service or not, the framework first monitors the resources at both locations, then creates an optimization problem that combines memory, transfer, and execution time costs. The cost function is represented as follows:

Mi n x∈0,1 � C t r ans f er × w t r + C memor y × W mem + C C PU × W C PU � (3.15)
Where:

           C t r ans f er = � n i =1 cod e i × x i + � n i =1 � k j =1 t r j × � x j X OR x i � C memor y = � n i =1 mem i × (1 -x i ) C C PU = � n i =1 cod e i × a × (1 -x i ) (3.16)
In the above equation, n is the sum of the offloaded modules; cod e i , mem i , and t r i represent, respectively, the code size, memory cost, and transfer cost of module i ; and x i is the decision variable, which represents the decision made for each module in term of whether it should be offloaded (i.e., x i = 1)

or computed locally (i.e., x i = 0). Even though MACS is a lightweight and dynamic framework, it requires developer efforts to structure the application program into a model. Furthermore, the offloading performance is impacted by the profiling and partitioning steps.

(d) Adaptive (k+1) [START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF]. Ou et al. have proposed an adaptive, multi-constraint partitioning algorithm for offloading in pervasive systems. The framework partitions an application into k offloadable partitions and one unffloadable partition. The partitioning algorithm is applied to a dynamic multi-cost graph.

The vertices correspond to the application classes, each valued with an n-tuple, < w 1 , w 2 , ..., w n >, (n � = 0) costs such as memory, bandwidth, and execution time. The edges represent the interactions among classes. The authors have used a heavy-edge and light-vertex matching algorithm to coarsen the multi-cost graph. Hence, a composite-vertex-weight is used to replace the weight vector. The composite vertex weight is computed as: w v composi t e = � i εw v i , where i = 1, 2, ..., n, n is the length of the weight vector, and ε is the importance of the i t h weight in the vector, which is assigned based on the scarcity of the corresponding resource. The higher the scarcity of a resource, the higher ε will be. The authors have formulated the problem as follows: Given an application graph G(V, E ) and a non-negative integer k l , the adaptive (k+1) multi-constraint partitioning algorithm has to find one local (unoffloadable) partition

V U and k disjoint remote (offloadable) partitions V O 1 ,V O 2 , ...,V O
k , which should satisfy the following constraints:

           ∪ k i =1 V o i = V -V U and V o i ∩ V o j = � f or 1 ≤ i , j ≤ k and i � = j T he ed g e -cut o f ∀V i ,V j ∈ V U ,V o 1 ,V o 2 , ...,V o k C (i , j ) = � (u,v)∈E ,u∈V i ,v∈V j ,u� =v ∀i , j : ψ i j ≤ (T i j ± δ i j )
(3.17)

ψ i
j is the sum of the j t h vertex-weight in partition V i : ψ i j = � v∈V i w v j ; T i j and δ i j are the multiple constraints representing threshold and partitioning fluctuating factor in partition V i according to the j t h vertex weight. These two parameters define, respectively, the lower and upper bound of the constraints.

When a composite vertex weight is used, ψ i j becames ψ i composi t e , and it is computed by ψ i composi t e = � v∈V i w v j .

Table 3.1 presents the comparative summary of aforementioned models considering various metrics.

, , and mean, respectively, low, medium, and high consumptions. ✓ and ✗ show whether the functionality is supported or not.

Mobility

As far as we know, mobility has not been fully studied in computation offloading. Only a few studies have addressed mobility when performing computation offloading.

Mob-aware [START_REF] Lee | User mobility-aware decision making for mobile computation offloading[END_REF] is a mobility-aware offloading decision maker, which considers future network changes based on user mobility. The Mob-aware gathers previous user movements and network changes, then builds a mobility model to predict future network changes. The authors have used Markov theory to draw the mobility model and calculate the probability of moving to a certain Wi-Fi Access Point (AP).

Each state s i in the model represents a Wi-Fi AP characterized with a bandwidth bw i and a staying time st i , while a transition represents the probability of visiting a certain state. Using this model, Mob-aware estimates the expected remote and local execution time. Mob-aware explores each possible transition to estimate the response time based on the bandwidth bw i , and the staying time in each state st i . Then, the engine calculates the probability of taking a possible path (i.e., a plausible sequence of transitions). The probability P (Q i ) of taking a path Q i is given by:

P (Q i ) = P (s 0 , s 1 , ..., s n ) = n � k=2 P (s k |s k-1 , s k-2 ) (3.18)
Mob-aware expects the response time R of remote execution using equation 3.19, where R i is the response time of remote execution on a path Q i . The throughput on each path is expected using bandwidth bw and the state time on each state st . Also, d u and d r are the input and result data size, respectively.

R = � i P (Q i ) × R i (Q i , d u , d r ) (3.19)
Ou et al. [START_REF] Ou | Performance analysis of offloading systems in mobile wireless environments[END_REF] proposed an analytic model for computation offloading in a mobile wireless environment using the mobility Random Waypoint (RWP) scheme [START_REF] Johnson | Dynamic source routing in ad hoc wireless networks[END_REF]. The authors considered a one-dimensional mobility. They defined a continuous random variable, X , to express the user mobility coordinate, assuming a random speed

v i ∈ [v mi n , v max ].
f x (x) = -6 d 3 x 2 + 6 d 2 x, 0 < x < d A
surrogate is not reachable when the difference between the mobile user's location, x m , and the surrogate's position, x s , is greater than the surrogate's radio transmission radius, D, (i.e., |x mx s | > D). Since surrogates are immobile, their radio coverage can be obtained.

If m denotes the number of surrogates on segment [0, d ], therefore there are m + 1 sub-segments

([0, x s 1 -D), (x s 1 + D, x s 2 -D), ..., (x s m + D, d ])
, which are out of the radio coverage. The probability of surrogate being un-reachable at anytime is given by:

α = � x s 1 -D 0 f (x)d x + m-1 � i =1 � x s i +1 -D x s i +D f (x)d x + � d x s m +R f (x)d x (3.20)
Events of unreachable surrogates are modelled with a Poisson process. P is a random variable representing the time to the first epoch in which the surrogates are unreachable. P follows an exponential distribution with parameter α.

f p (P ) = αe -αP , P ≥ 0

(3.21)
The authors have modelled the running application with four states; non-offloading execution (S N E ), offloading (S OL ), offloading execution (S OE ), and failure and recovery (S F R ). Offloading events follow a Poisson process with a rate β. During the offloading and failure events, periods of time M and R are needed to, respectively, migrate data to a remote surrogate and to recover after failure. M and R are random variables following a general distribution. When a failure occurs, application execution is interrupted next, the failure is recovered, and the execution is restarted from the scratch in the same period as the last execution. The failure occurs during the states S OL and S OE due to the surrogate's unreachability when the user is moving, and in state S F R when the failure recovery aborts. In these cases, α becomes the probability of failure. The authors have expressed the execution time without failure using the following Equation 3.22:

T non-f ai l ur e (n) = � 1 - (ω -1)σ ω � T � (n) (3.22)
where n is the number of tasks composing the application, ω is the speedup factor of the surrogate compared to the mobile device, σ is the proportion of sub-tasks performed by the surrogate, and T � (n)

is the local execution time of the application on the mobile device. The execution time with failure is CHAPTER 3. COMPUTATION OFFLOADING: TAXONOMY REVIEW given by Equation 3.23.

T * (n) =    T (n) + � h i =1 M i i f P ≥ T (n) + � h i =1 M i P + R * + T * (n) i f P < T (n) + � h i =1 M i (3.23)
where h is the number of transitions from the state S N E to the state S OE , R * is the failure recovery time in the presence of failures within the recovery period R, and P is the time to the first failure after starting recovery.

• if P ≥ T (n) + � h i =1 M i
then, h offloading operations are made before finishing the n tasks without failure. Therefore, the offloading time is given by � h i =1 M i , and the total execution time is expressed by T (n) + � h i =1 M i . The random variables M i , i = 1, 2, ..., h are independent and identically distributed (i.i.d).

• if P < T (n)+ � h i =1 M i
then a failure will occur before finishing the n tasks and making h offloading operations. Therefore, a nested failure occurs, and a new recovery operation is repeated after P , with a recovery time R * .

MOSys [START_REF] Junior | Supporting mobility-aware computational offloading in mobile cloud environment[END_REF] is a seamless computation offloading framework. MOSys uses the Software-Defined Networking (SDN) [START_REF] Yap | Openroads: empowering research in mobile networks[END_REF] paradigm to manage user mobility and caching techniques to reduce response time. The framework MOSys is composed of three entities; a middleware client that is responsible for the collection of data, such as application type, network, and Cloud parameters; a network controller that manages user mobility, tracks his location, and maintains his IP address; and a middleware server that performs the offloading requests.

The architecture manages two types of interactions: (i) between the mobile device and the OpenFlow controller2 to manage mobility, discover Cloud resources and services, and perform offloading computation steps; and (ii) between the OpenFlow controller and the Cloud, which accepts or rejects computing the offloaded tasks, monitors the Cloud resources, and performs caching. The middleware is composed of classical offloading components, such as profiler, decision engine, and offloading manager, and a remote caching component to store data in a cache for future use. The network controller is composed of: (i) OFMAG, responsible for user's mobility and managing handovers and connectivity; and (ii) OFLMA creates OpenFlow rules to manage the traffic and maintain data to identify handovers. The authors used the Proxy Mobile IPv6 (PMIPv6) [START_REF] Gundavelli | Proxy mobile ipv6[END_REF] to devise these two components.

Challenges

• Trust: Establishing trust between mobile end-users and Cloud providers is central in MCC. Several studies have been conducted in this axis to build trust in Cloud resources [START_REF] Mowbray | A client-based privacy manager for cloud computing[END_REF][START_REF] Sanaei | Sami: Service-based arbitrated multitier infrastructure for mobile cloud computing[END_REF][START_REF] Wang | Enabling public verifiability and data dynamics for storage security in cloud computing[END_REF]. However, risky Internet channels and Cloud infrastructure heterogeneity impact the trust between mobile • Data Portability: Cloud providers have alleviated the locked-in problem of mobile device users to facilitate data migration through non-uniform mobile devices. Yet, portability of data is still a challenge for Cloud consumers. For instance mobile users are unable to transfer data from Android-based to iOS-based mobile devices. On top of that, Cloud service heterogeneity causes a provider lock-in problem. Provider lock-in is a real concern for customers and an attractive issue in business [START_REF] Manvi | Resource management for infrastructure as a service (iaas) in cloud computing: A survey[END_REF]. Solutions, such as the proposed middleware [START_REF] Blair | Emergent middleware: Tackling the interoperability problem[END_REF] and standardization of Open Cloud Computing Interface (OCCI) 3 are some approaches addressing the portability issues in MCC.

• Budget: In order to use the Cloud for computation offloading, the costumer should pay for the services offered, which include resource reservations, QoS, reliability, and security [START_REF] Sanaei | Heterogeneity in mobile cloud computing: Taxonomy and open challenges[END_REF], according to the negotiated Service-Level Agreement (SLA) with the Cloud provider. Moreover, to offload computation, the user should have access to the internet through wired or wireless connectivity.

When using radio communication, the user has generally a limited size of data to upload and download; if this quota is exceeded, the user will have to pay for additional data, usually at a very expensive rate.

• QoS/QoE: Concerns in this area are interaction delay, immersion, and in the case of multimedia, the number of frames generated per second. The following chapters discuss these concerns in more details.

Computation Offloading Taxonomy: From the Mobile Device Perspective

In this section, we initiate the reader to mobile device's limitations and characteristics that have pushed for the need to use computation offloading. We are particularly interested in mobile device platforms that have been used for computation offloading. We also want to describe mobile devices from the hardware capabilities view to understand their limitations in term of resources. Finally, wireless communication also matters in computation offloading. Indeed, each technology has its characteristics, including throughput, energy consumption, latency, supported services, which highly impact computation offloading. Figure 3.2 highlights these interests.

Platform

A platform is the operating system (OS) layer that make mobile devices operational, and the operating system manages user applications. The manufacturers of mobile devices can be separated, according to the OS running on these devices, into light OS and full OS. • Light OS concerns smartphones and tablets, which include Android, iOS, and Symbian.

• Full OS is supported by laptops and some surfaces. It includes, Windows (e.g., 7/8/10), Linux (e.g., Mandriva, RedHat, and Debian), and MAC OS.

Wireless Communication

To communicate with the Cloud/Edge environment that is computing the offloaded tasks, mobile devices are using wireless communication such as cellular networks (e.g., 2/3/4/5G, and Wi-Max) or Wi-Fi access point. A comparison study of wireless protocols: Bluetooth, ultra-wideband (UWB), ZigBee, and Wi-Fi was proposed in [START_REF] Lee | A comparative study of wireless protocols: Bluetooth, uwb, zigbee, and wi-fi[END_REF]. The authors have evaluated the protocols' main features and behaviors in terms of various metrics, including the transmission time, data coding efficiency, complexity, and power consumption. In [START_REF] Deruyck | Comparison of power consumption of mobile wimax, HSPA and LTE access networks[END_REF], a comparison between WiMAX, HSPA and LTE access networks was provided regarding the power consumption. In the computation offloading arena, several works have been proposed based on different wireless communication technologies. In [START_REF] Thinkair | Dynamic resource allocation and parallel execution in the cloud for mobile code offloading[END_REF], authors have tested their framework, ThinkAir, for N-Queen-Puzzle, Face detection, and virus scanning for both 3G and Wi-Fi connectivity. In [START_REF] Zhang | Refactoring android java code for on-demand computation offloading[END_REF], the authors have proposed and experimented a method for refactoring Android Java code for on-demand computation offloading in 3G networks. The framework COSMOS [START_REF] Shi | COSMOS: computation offloading as a service for mobile devices[END_REF] was tested for four scenarios: stable Wi-Fi, indoor Wi-Fi, outdoor Wi-Fi, and outdoor 3G. AD-Hoc Cloudlets oriented computation offloading was tested in [START_REF] Chen | On the computation offloading at ad hoc cloudlet: architecture and service modes[END_REF] in the context of 3G/4G connectivity. Chen et al. [START_REF] Chen | Mobility-aware caching and computation offloading in 5g ultra-dense cellular networks[END_REF] have studied the mobility and its impact on the performance of caching and computation offloading in 5G-ultra dense cellular networks. Other studies Considering computation offloading in MEC [START_REF] Zhang | Energy-efficient offloading for mobile edge computing in 5g heterogeneous networks[END_REF] and

Cloud computing [START_REF] Khoda | Efficient computation offloading decision in mobile cloud computing over 5g network[END_REF] in 5G heterogeneous networks are proposed in the state-of-the-art computation 40 2. Battery. The energy is the unique non-replenishable resource. It needs an external resource to restore it. A plenty of efforts seeking to harvest energy from renewable resources including human movement [START_REF] Donnell | Prolog to energy harvesting from human and machine motion for wireless electronic devices[END_REF], solar energy [START_REF] Bialic | Wysips® connect, the first solution for the indoor/outdoor vlc lighting saturation problematics[END_REF][START_REF] Liu | Autocharge: Automatically charge smartphones using a light beam[END_REF], and wireless radiation [START_REF] Huang | Enabling wireless power transfer in cellular networks: Architecture, modeling and deployment[END_REF]. In parallel, researchers aim at reducing the energy overhead in different aspects of computing, including hardware, OS, application, and networking interface. DVS technology [START_REF] Burd And R | Design issues for dynamic voltage scaling[END_REF] is a power management technique used to conserve the energy, particularly in wearable devices by increasing and decreasing the voltage. The automatic shutdown of the screen is another concept to save energy for mobile devices.

Some other efforts are trying to develop alternative energy resources such as nuclear batteries.

3. Screen. The screen size has grown since 2007 from 2.59 i nches to 6 i nches for today's smartphones. For instance, the iPhone 8 Plus has a screen size of5.5 i nches. Despite, these large screens offer high visualization, they sharply drain the batteries. Some alternatives have been proposed, they include the GeoTV [START_REF] Chen | Project geotv: a three-screen service[END_REF], and remote display solution [START_REF] Simoens | Remote display solutions for mobile cloud computing[END_REF]. Other efforts to extend data-presentation area have considered the utilization of dual screens such as Codex [START_REF] Hinckley | Codex: a dual screen tablet computer[END_REF],

FoldMe [START_REF] Khalilbeigi | Foldme: interacting with double-sided foldable displays[END_REF], and Foldable3D [START_REF] Büschel | Foldable3d: Interacting with 3d content using dual-display devices[END_REF].

4. Memory and storage. Today, most smartphones have a Random Access Memory (RAM) for running applications. Their capacity increased over the year following Moore's law from only 100 M B to up to 4GB today. Regarding the storage, smartphones are equipped with a large flash storage (e.g., 64GB ) used to store user's files such as pictures, applications, music, and videos.

The speed of evolution of the storage capacity is doubling every two years, fit to Moore's law again.

Augmenting the hardware increases the performance of the mobile devices, however, it brings different drawbacks, that include (but are not limited to):

• Increasing the energy consumption due to large screens, powerful processors, and large storage.

• Decreasing the hardiness of mobile devices due to the additional size, weight, and heat, which are caused by the incorporation of powerful processor, large storage, and big screen.

• Increasing the price of these devices due to the integration of high technology and powerful ships in a dense space.

Computation Offloading Taxonomy: From the Application Perspective

We focus in this section on motivations, issues, and challenges encountered by mobile applications when requesting computation offloading. It will be of special interest to identify the genre of applications, described in the literature, which advocates and motivates the use of computation offloading. It is also interesting to identify the application programing languages, aiming at discovering application portability and developing frameworks that target, as much as possible, compatible applications. We are also motivated to classify applications in the literature under different resource demand groups in order to define objective functions that should be considered for each group. We also analyse application code dependency challenges. We represent these different axis in The study in Section 3.2 has demonstrated that not all mobile applications are suitable for computation offloading, since the offloading gain depends on several metrics (e.g., computation amount, exchanged data). We report in this section the main suitable applications, described in the literature, for computation offloading.

• Augmented Reality. In [START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF] an AR application is described. It presents eyeglasses for cognitive assistance, composed of a camera and earphones. The system hosts different applications, including AR, computer vision, and audio processing. The authors in [START_REF]Cloudlets: bringing the cloud to the mobile user[END_REF]286] present another AR application, which features marker-less tracking and object recognition. The system tracks feature points in a video to enable the overlay of 3D objects. The application is divided into several modules that each can be offloaded to a Cloudlet to optimize the user experience. In [288], a middleware built upon OSGi7 is presented with an algorithm, which calculates the best deployment of the AR application according to the possible configurations.

• M-Gaming. MAUI [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF] and ThinkAir [START_REF] Thinkair | Dynamic resource allocation and parallel execution in the cloud for mobile code offloading[END_REF] have been tested for arcade, chess, and N-Queens puzzle games. MAUI represents the games into a graph, then draws an ILP model to obtain the location of each method. ThinkAir uses past-invocations of methods to to make decisions (see Chapter 5 for more details). Messaoudi et al. have discussed the possibility of offloading game engines in [START_REF] Messaoudi | Dissecting games engines: The case of unity3d[END_REF], and proposed, in [START_REF] Messaoudi | Performance analysis of game engines on mobile and fixed devices[END_REF], the UCOF or Unity 3D-based Computation Offloading

Framework. Cloud gaming [START_REF] Huang | Gaminganywhere: The first open source cloud gaming system[END_REF] represents another use case of computation offloading. Here, the entire application (i.e., game engine) is offloaded and computed in the Cloud. Commands and video streams are exchanged between the powerless devices and the game engine hosted in the Cloud (more details in Chapter 4).

• Image Processing. In [START_REF]On using edge computing for computation offloading in mobile network[END_REF], a framework has been proposed that relies on the MEC to enhance the execution of a facial recognition application (see Chapter 6). A facial detection scenario was described in [START_REF] Mahmoodi | Optimal joint scheduling and cloud offloading for mobile applications[END_REF] wherein the application is represented by an hybrid (i.e., parallel and sequential) dependency graph, which is drawn into an ILP to make offloading decisions regarding energy consumption. Image manipulation based on cyber foraging was proposed in [START_REF] Kristensen | Scavenger: Transparent development of efficient cyber foraging applications[END_REF]. The use case describes touching an image up by applying filters, sharpening, removing the red-eye effect, and adjusting brightness, colour, and contrast. Other use cases were presented in [START_REF] Kallonen | Use of distributed resources in mobile environment, in Software in Telecommunications and Computer Networks[END_REF][START_REF] Kemp | Opportunistic communication for multiplayer mobile gaming: Lessons learned from photoshoot[END_REF][START_REF] Kemp | eyedentify: Multimedia cyber foraging from a smartphone[END_REF][START_REF] Yang | On effective offloading services for resource-constrained mobile devices running heavier mobile internet applications[END_REF] for optical character recognition (OCR), barcode analysis, face detection, and object recognition.

• Audio Processing. Goyal and Carter (GnC) framework was tested for speech recognition applications in [START_REF] Goyal | A lightweight secure cyber foraging infrastructure for resourceconstrained devices[END_REF]. The authors used the Sphinx28 application. GnC records what the client is saying and sends the sound data to a surrogate, which in turn recognizes the phrases and sends the results back to the client. Locuts [START_REF] Kristensen | Enabling cyber foraging for mobile devices[END_REF] is a framework providing a tool for developing applications-oriented cyber foraging. A daemon running on the powerless device calculates an optimal execution plan according to the resource measurements on the device and surrogate. The example given describes a doctor who enters patients information on his electronic journal using a lightweight headset, which needs a surrogate for translation.

The above-mentioned use-cases/applications are a small sampling of the applications and scenarios used in the literature. The applications used in state-of-the-art computation offloading include, but are not limited to, data mining [START_REF] Goyal | A lightweight secure cyber foraging infrastructure for resourceconstrained devices[END_REF], text translation [START_REF] Yang | On effective offloading services for resource-constrained mobile devices running heavier mobile internet applications[END_REF], 3D home interior design [START_REF] Giurgiu | Calling the cloud: Enabling mobile phones as interfaces to cloud applications[END_REF], virus scan [START_REF] Chun | Augmented smartphone applications through clone cloud execution[END_REF][START_REF] Portokalidis | Using virtualisation to protect against zero-day attacks[END_REF], SciMark 2.0 benchmarking [START_REF] Zhang | Towards module-based automatic partitioning of java applications[END_REF], multimedia (M4Play) [START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF], and mathematics processing (π-calculator) [START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF].

Programing Language

Computation offloading frameworks and mobile applications are highly dependent, as they should support code portability. We distinguish two alternatives: (i) a single-platform, which is a light-weight, efficient approach, wherein the offloading framework is dedicated for applications developed on the same environment; (ii) a Cross-platform, the framework of which can run on several operating systems and various hardware configurations. Therefore, a cross-platform framework supports a variety of applications written in diverse programming languages. However, this solution is complex, and it induces a high overhead due to wrapping the application components in order to be supported. To sum up, application that are candidates for offloading depend on their frameworks, which should be portable through platforms.

Table 3.2 summarizes some reviewed works. We observe that most of the proof-of-concept computation offloadings are based on Java applications that encompass facial detection and recognition, speech translation and recognition, and 2D games. Researchers tend to focus on Java as it is easy to use (i.e., it is a high-level language), is supported by the main mobile operating systems (such as Android), includes memory management and a garbage collector to efficiently manage the memory, and it defines a set of services and APIs that are ready for use. In contrast, C/C++ and embedded C are low-level programing languages that involve considerable efforts from developers to manage the memory and develop applications.

Requirements

Below, we classify the requirements of candidate applications for computation offloading into seven groups, according to the needs served by the applications. This classification is useful for managing the framework objective functions through the applications requirements.

• CPU-intensive category. This category includes applications that need powerful CPUs to execute and consume a consider-able amount of energy. We mention audio analysis, image processing, data analysis, and benchmarking. Proposes a framework to develop application-oriented offloading

� Speech Recogn � File Prepar � langauge Transl � NA � Latex � NA Cuckoo [128]
Partial offloading with programming UI to ease the code integration � Object recogn � Face recogn Java eXCloud [START_REF] Ma | excloud: Transparent runtime support for scaling mobile applications in cloud[END_REF] Uses stack-on-demand technique to offload segments of frames to the Cloud Math calculations Objective C

Zhang et al. [322]

Weblets-based partitioning using elastic applications approach Image processing C#

Giurgiu et al. [91]

Distributes application into functional layers based on the R-OSGI 3D home interior OSGI (Java)

Ou et al. [217]

Adaptive (k + 1) graph partitioning algorithm for offloading MPEG-4 player Java

Verbelen et al. [START_REF] Verbelen | Cloudlets: Bringing the cloud to the mobile user[END_REF]286] Leverages Cloudlets for immersive applications AR C/C++ wrapped in OSGI DPartner [START_REF] Zhang | Refactoring android java code for on-demand computation offloading[END_REF][START_REF] Zhang | Towards module-based automatic partitioning of java applications[END_REF] On-demand automatic factorization for android bytecode

� Linpack Bench � Gomoku Chess � 3D car Games Java (bytecode)
JDOP [START_REF] Wang | Automatic partitioning of object-oriented programs for resourceconstrained mobile devices with multiple distribution objectives[END_REF] Dynamic graph partitioning algorithm for Java bytecode applications � Java Grand � SpecJVM98 Java (bytecode)

Chroma [START_REF] Balan | Tactics-based remote execution for mobile computing[END_REF] Proposes a tactics-based remote execution for mobile computing

� Pangloss-Lite � Janus � Face � C++ � C � Ada
Yang et al. [START_REF] Yang | On effective offloading services for resource-constrained mobile devices running heavier mobile internet applications[END_REF] Leverages surrogates for bytecode offlaoding AutoTranslator Java (bytecode)

Coca [START_REF] Chen | Coca: Computation offload to clouds using aop[END_REF] Offloads computation to the Cloud using aspect-oriented programming Chess game Java

IC-Cloud [261]

Predicts connectivity on intermittent Cloud to enhance offloading

� Face Detect � Voice recogn � Droid Fish Java
• GPU-intensive category. The GPU, as its name implies, is largely dedicated to graphic processing, so applications with intense rendering are included in this category. Games, AR, VR, and multimedia are the main applications.

• RAM-intensive category. Some applications demand much memory to run, such as 3D modelling and gaming. Also, the IoT, including sensors, are memory-constrained devices. Therefore, almost all programs running on these devices are RAM-intensive.

• I/O-intensive category. This category contains the applications that increase memory paging and I/O activity such as PostMark 9 , PageBench 10 , and Bonnie 11 .

• Network-intensive category. This category includes applications involving Internet connectivity used to access remote services. We mention social network applications, such as Facebook, and 9 File system benchmark program: http://www.netapp.com/tech_library/3022.html. 10 Synthetic program which initiates and updates an array whose size is bigger 11 Unix file system performance benchmark: http://www.textuality.com/bonnie/.

Twitter, Sftp12 , and PostMark_NFS13 .

• Security-intensive category. This category concerns applications that need security mechanisms, such encryption, authentication, and authorization.

• Delay-sensitive category. These are mainly considered to be real-time applications, such as games and AR/VR.

In general, memory [START_REF] Zhang | Application classification through monitoring and learning of resource consumption patterns[END_REF], CPU, and GPU high-demand applications are mainly suitable for computation offloading. It is prudent to execute bandwidth-intensive applications locally at the mobile device [START_REF] Hung | Executing mobile applications on the cloud: Framework and issues[END_REF].

Offloading delay-sensitive applications [START_REF] Nazir | Time critical content delivery using predictable patterns in mobile social networks[END_REF] depends on the network latency and data exchange: (a) the higher the network latency, the lower the offloading gain; and (b) the larger the exchanged data size, the higher the latency, and the lower the offloading gain. In mobile networks, the latency is impacted by different parameters, which depend on both the core network and wireless channel access delays.

Kumar et al. [START_REF] Kumar | A survey of computation offloading for mobile systems[END_REF] have shown, via a mathematical model, that if the access delay is higher than the execution time on the mobile device, then, even if the server is infinitely fast, there is no offloading gain.

Concerning the network-intensive [START_REF] Ballagas | Rexplorer: a mobile, pervasive spell-casting game for tourists[END_REF], the I/O-intensive [START_REF] Zhang | Application classification through monitoring and learning of resource consumption patterns[END_REF], and the security-intensive [START_REF] Cano | A secure energy-efficient m-banking application for mobile devices[END_REF][START_REF] Khan | Towards secure mobile cloud computing: A survey[END_REF][START_REF] Sookhak | A review on remote data auditing in single cloud server: Taxonomy and open issues[END_REF] applications, their execution in remote servers is restricted by some constraints including, hardware dependency, security and confidentiality, and network communications. Almost all the applications reported in the manuscript are computationally-intensive applications.

Code Dependency

We finish this section by distinguishing components of applications that cannot be offloaded. We call this constraint code dependency. For some reasons, which we will discuss later, offloading the entire application is not always possible, as some components of the mobile application depend on specific hardware components, such as sensors or on the device software, such as libraries. Figure 3.4 portrays some of the different hardware and software entities involved in an interaction between a user and his device. Obviously, in reality, the device interacts with the user via multiples of these entities. As this figure shows, a user application, from the background, may depend on diverse programs, known as libraries, Software Development Kits (SDKs), middleware, operating systems, and drivers, but also on hardware, especially sensors. From the foreground, the application interacts with the user via User-Interfaces (UIs), which manage for instance, the mouse and touch screen for the inputs, and headphones and speakers for the outputs.

We now clarify, the role of the layered programs triggered in an application execution.

• The platform independence layer is a set of libraries that allow an application to be cross-platform.

It sits atop the hardware, drivers, operating systems, and third-party SDKs. It releases the rest of the application from being dependent on the underlying platform. • The operating system is the software that runs continuously on a device to orchestrate the execution of multiple applications, one of which is the application requesting computation offloading. The software uses interruptions and preemption scheduling to share the hardware with the applications that are running.

• The device drivers are low-level software components provided by the operating system or the hardware vendor. They manage hardware resources and release the operating system and upper layers from the details in communications with the hardware.

Accordingly, we can classify the non-transferable components of an application into four groups: (i) components involving UIs [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF] Othman | Power conservation strategy for mobile computers using load sharing[END_REF][START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF]; (ii) components interacting directly with the device hardware, such as a Global Positioning System (GPS) and accelerometer sensors [START_REF] Othman | Power conservation strategy for mobile computers using load sharing[END_REF]; (iii) components depending on APIs, middleware, or libraries located on the same device [START_REF] Gu | Adaptive offloading for pervasive computing[END_REF][START_REF] Ou | An efficient runtime offloading approach for pervasive services[END_REF]; and (iv) components using directly device-related information [START_REF] Gu | Adaptive offloading for pervasive computing[END_REF].

Computation Offloading Taxonomy: From the Network Perspective

This section provides some background regarding the network environment in which, the powerless device and server are performing the computation offloading. Particularly, in this section, we focus on the QoS metrics, communications support, and networking models. Figure 3.5 depicts these points.

Metrics

• Delay: The main aspect of seamless application execution is the interactive delay. Interactive delay is defined as the elapsed time between the moment when an action is triggered by a user and the moment when the result of this action is perceived by the user. Interactive delay is a mandatory constraint in MCC, since it is linked to interactivity. The work in [START_REF] Tolia | Quantifying interactive user experience on thin clients[END_REF] demonstrated that a user is satisfied and productivity is not affected by an interactive delay when the latter is below 150 ms.

The user becomes aware of an interaction delay within the range of 150 ms and, furthermore, the user becomes unsatisfied and frustrated for delays higher than 1 s. Work in [START_REF] Choy | The brewing storm in cloud gaming: A measurement study on cloud to end-user latency[END_REF] decomposed the interactive delay into six parts: t cl i ent + t access + t i sp + t t r ansi t + t d at acent er + t ser ver , wherein t cl i ent is the playout delay, which is the time spent triggering an action, and receiving and visualizing the result; t ser ver is the processing delay, which is the time spent by the server in computing the incoming tasks from the client and transmitting back the results of the tasks; and t access + t i sp + t t r ansi t + t d at acent er represents the network latency, where, t access is the data transmission time between the client and the first router, t i sp is the phase between the access router and the access point, t t r ansi t is the delay in reaching the front-end of a datacenter, and, t d at acent er is the time to access the server reserved for the client. To reduce the interactive delay, several works related to computation offloading have focused on bringing the Cloud closer to the mobile user by leveraging the MEC [START_REF] Liu | Delay-optimal computation task scheduling for mobile-edge computing systems[END_REF][START_REF] Sardellitti | Joint optimization of radio and computational resources for multicell mobile-edge computing[END_REF][START_REF] You | Multiuser resource allocation for mobile-edge computation offloading[END_REF], Fog computing [START_REF] Chen | Dynamic urban surveillance video stream processing using fog computing[END_REF][START_REF] Hassan | Help your mobile applications with fog computing[END_REF][START_REF] Yi | Fog computing: Platform and applications[END_REF], and Cloudlets [START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF][START_REF] Soyata | Combat: mobile cloud-based compute/communications infrastructure for battlefield applications[END_REF][START_REF] Soyata | Cloudvision: Real-time face recognition using a mobile-cloudlet-cloud acceleration architecture[END_REF] paradigm.

• Bandwidth: In a packet network, both bandwidth and throughput characterize the amount of transferred data over the network per unit of time. Bandwidth estimation is of interest to users aiming to optimize the end-to-end transport performance, overlay network routing, and peer-topeer file distribution. For several data-intensive application, such as multimedia streaming and file transfers, the available bandwidth impacts directly the performance of the application. Three main metrics characterize the bandwidth, namely, capacity, available bandwidth, and Bulk Transfer Capacity (BTC) [START_REF] Prasad | Bandwidth estimation: metrics, measurement techniques, and tools[END_REF]. Several bandwidth estimation methodologies have been proposed in the literature to estimate the end-to-end capacity and available bandwidth. We cite the variable packet size probing [START_REF] Downey | Using pathchar to estimate internet link characteristics[END_REF][START_REF] Lai | Measuring link bandwidths using a deterministic model of packet delay[END_REF], the packet pair/train dispersion probing [START_REF] Bolot | Characterizing end-to-end packet delay and loss in the internet[END_REF], the self-loading periodic streams [START_REF] Jain | End-to-end available bandwidth: measurement methodology, dynamics, and relation with TCP throughput[END_REF], and the Trains of Packet Pairs [START_REF] Melander | A new end-to-end probing and analysis method for estimating bandwidth bottlenecks[END_REF] methodologies. Various strategies have been used to improve the computation offloading performance by using high bandwidth link [START_REF] Fesehaye | Impact of cloudlets on interactive mobile cloud applications[END_REF][START_REF] Zhao | Mirroring smartphones for good: A feasibility study[END_REF], ondemand bandwidth allocation [START_REF] Hung | Executing mobile applications on the cloud: Framework and issues[END_REF], multi-Radio Access Technology (RAT) [START_REF] Mahmoodi | A time-adaptive heuristic for cognitive cloud offloading in multi-rat enabled wireless devices[END_REF], and Multipath TCP (MPTCP) [START_REF] Magurawalage | Aqua computing: Coupling computing and communications[END_REF].

Several other metrics are considered in computation offloading, we cite energy consumed by each communication technology (3/4/5G, and Wi-Fi), packet loss, accuracy, fault tolerance, scalability, and packet delivery [START_REF] Lei | Challenges on wireless heterogeneous networks for mobile cloud computing[END_REF][START_REF] Mitra | M 2 c 2 : A mobility management system for mobile cloud computing[END_REF][START_REF] Soyata | Cloudvision: Real-time face recognition using a mobile-cloudlet-cloud acceleration architecture[END_REF][START_REF] Verbelen | Dynamic deployment and quality adaptation for mobile augmented reality applications[END_REF].

Communication Support

To perform a computation offloading, communications between a mobile device requesting offloading computation and a remote infrastructure, which computes the offloaded code, have to be established. We distinguish several mechanisms by which to communicate with state-of-the-art computation offloading, such as; RPC, RMI, VM migration, Mobile agents, and proxy.

• RPC: RPC is a request-response protocol. The request is initiated by a mobile device, which sends a message to a well-known remote server requesting the execution of a specified procedure with supplied parameters. The answer to the request is performed by the remote server. During the remote execution, the mobile device is in waiting mode until the reception of the response from the server. In this mechanism, applications are partitioned into locally executable code and remotely executable services. These services are pre-installed on remote infrastructure, which expose these RPC as APIs. Several frameworks have been proposed in the literature for computation offloading based on RPC support for communication. We mention Spectra [START_REF] Flinn | Balancing performance, energy, and quality in pervasive computing[END_REF], Chroma [START_REF] Balan | Simplifying cyber foraging for mobile devices[END_REF][START_REF] Balan | Tactics-based remote execution for mobile computing[END_REF], MAUI [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF],

and Odessa [START_REF] Ra | Odessa: enabling interactive perception applications on mobile devices[END_REF].

• RMI: RMI is a Java API that performs a remote invocation of methods; it is the object-oriented equivalent of RPC. RMI supports a direct transfer for serialized Java classes and distributed garbage collection. RMI invokes remote methods in a transparent and seamless way using references for the remote objects. To perform RMI, two particular classes should be created by the Java Development Kit (JDK): the stub from the client side and the skeleton from the server side. These two classes are in charge of calls, communications, execution, and sending and receiving execution results.

Past studies such as Cuckoo [START_REF] Kemp | Cuckoo: A computation offloading framework for smartphones[END_REF], JavaParty [START_REF] Philippsen | Javaparty -transparent remote objects in java[END_REF], J-Orchestra [START_REF]Enhancing java programs with distribution capabilities[END_REF], and JADE [START_REF] Bhargava | An agent-based optimization framework for mobile-cloud computing[END_REF] have been designed with the RMI mechanism.

• VM Migration: VM migration is another mechanism that can be used to support communications for computation offloading. The concept is to create a VM that replicates the execution environment of the mobile platform, and migrate the VM to a remote server to compute the running application.

VM migration follows two ways; cold, and hot migration. The difference between these two approaches is in how data are migrated. In cold migration, the VM is stopped to migrate all the pages related to the VM, while in the hot migration, the VM is migrated without interrupting the OS or any of its applications, giving the illusion of seamless migration. Some research on state-ofthe-art computation offloading have been conducted using virtualization and VM migration. We cite CloneCloud [START_REF] Chun | Clonecloud: elastic execution between mobile device and cloud[END_REF][START_REF] Chun | Augmented smartphone applications through clone cloud execution[END_REF], GnC [START_REF] Goyal | A lightweight secure cyber foraging infrastructure for resourceconstrained devices[END_REF], Slingshot [START_REF] Su | Slingshot: deploying stateful services in wireless hotspots[END_REF], and Cloudlet [START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF].

• Mobile Agents: Mobile agents are autonomous programs which are able to control their movement between machines in an heterogeneous network. Communication between agents is achieved through message passing using RMI or RPC. In [START_REF] Bhargava | An agent-based optimization framework for mobile-cloud computing[END_REF], the authors used the Java Agent Development Environment (JADE) 14 . JADE is a popular framework for developing agent applications for interoperable, intelligent, multi-agent systems. Scavenger [START_REF] Kristensen | Scavenger: Transparent development of efficient cyber foraging applications[END_REF] is another framework, in which surrogates run a daemon, which is responsible for offering remote access for the mobile code execution environment and device discovery.

Network Type

• Peer-to-peer: In a P2P topology, the overall system load is distributed among all participating mobile devices/peers, which organize themselves to act as clients and servers at the same time.

In the computation offloading umbrella, several works have been proposed in the peer-to-peer context. In [START_REF] Kosta | Clone2clone (C2C): peer-to-peer networking of smartphones on the cloud[END_REF], the authors have introduced the Clone2Clone (C2C), a distributed peer-to-peer platform for Cloud clones of smartphones. Chen et al. [START_REF] Chen | On the computation offloading at ad hoc cloudlet: architecture and service modes[END_REF] have proposed a peer-to-peer model to interconnect nearby mobile devices through various short-range radio communication technologies forming ad-hoc Cloudlets, where every mobile device works as either a consumer or provider of a service. In [START_REF] Hu | Cloud robotics: architecture, challenges and applications[END_REF] a peer-to-peer model is described for Cloud robotics.

• Client-Server: In client-server model oriented for computation offloading, the client represents the powerless device such as smartphone, while the server generally, corresponds to a resourceful machine able to compute the client's requests, for example, server in the Cloud or Grid computing.

In [START_REF] Pedram | Extending the lifetime of a network of battery-powered mobile devices by remote processing: a markovian decision-based approach[END_REF] a stochastic model of the client-server system based on Markovian decision processes wherein the power management problem is formulated with task migration as an optimization

problem. An energy trade-offs in offloading computation/compilation in Java-enabled mobile devices [START_REF] Chen | Studying energy trade offs in offloading computation/compilation in java-enabled mobile devices[END_REF] have been studied considering the client-server model. To summarize, most of the research works presented through this document are based on the client-server model.

Computation Offloading Taxonomy: From the Server Perspective

In this section, the focus is on servers type, their distance by report from mobile users, their capabilities, and their associated issues. We review state-of-the-art regarding these axes and compare some frame- This section reviews the platforms used to compute offloaded tasks. We attempt to classify these platforms according to their physical distance from mobile users and their capabilities, into three categories, namely, distant Cloud, proximate µCloud, and hybrid platform, as shown in Figure 3.7 and described below.

1. Distant Cloud.

The Cloud is a model that enables ubiquitous, on-demand access to a shared pool of configurable resources (including networks, storage, applications, and services). The Cloud offers three types of services: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). SaaS provides a plethora of remotely accessible applications running on the Cloud infrastructure. PaaS allows customers to deploy applications, libraries, services, and tools supported by the provider. IaaS provisions the consumer with a pool of computing resources.

We distinguish four possible deployments of The Cloud as: private 15 , public 16 , community 17 , or hybrid Cloud 18 . In these deployments, public and private stationary servers are delivered by farms and enterprise premises. Amazon 19 , Google 20 , and Windows Azure21 are the pioneer providers of Cloud computing infrastructure. Usually, the Cloud is provided in a pay-as-you-use fashion.

2. Proximate µCloud.

In state-of-the-art computation offloading, we distinguished five appellations of platforms located in the near vicinity of mobile users. These platforms cross each other and may share some equipment.

a) Surrogates are static, idle computers located in proximity to the mobile users, such as those in airports, cinema halls, shopping malls, and public computing kiosks [START_REF] Garriss | Trustworthy and personalized computing on public kiosks[END_REF]. The surrogates are extended via high computing capabilities to show advertisements, play music, and compute services and applications. They are plugged to a source of energy and connected to the internet.

b) Cloudlet was proposed by Satyanarayan in [START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF], and it extends the definition of surrogates.

It is a resource-rich computer or a cluster of computers, seen as a "data-center in a box" with self-managing that requires internet connectivity, power, access control, and some security mechanisms. It is connected to mobile users via a one-hop, high-speed LAN. Cloudlets are located in public places (e.g., coffee shops or libraries), at access points (e.g., boxes and gateways), or in homes (e.g., desktops). c) Fog is an extension of Cloud computing, which brings network resources from the core network to the edge network to reduce the latency. It is gaining a lot of industry support, particularly from Cisco 22 . For instance, Fog could be the Mobile Network Operators (MNOs) infrastructure scattered in urban area [START_REF] Sanaei | Sami: Service-based arbitrated multitier infrastructure for mobile cloud computing[END_REF]. Fog is a highly virtualized platform, which provides a wide range of applications and services in highly distributed deployments and a real-time manner, such as gaming, video streaming, and AR/VR. Various use cases are leveraging MEC, such as location tracking, AR, video analytics, and distributed content. MEC is heavily promoted by the ETSI, which is trying to develop a standard around MEC [START_REF] Etsi | Mobile edge computing (mec); framework and reference architecture[END_REF], defining a reference architecture and a set of APIs 23 .

e) Ad-Hoc platform refers to clusters of mobile devices, including smartphones, tablets, and laptops. These devices are collaborating in an heterogeneous platform [START_REF] Sanaei | Heterogeneity in mobile cloud computing: Taxonomy and open challenges[END_REF] to compute tasks for a nearby mobile user. The Ad-Hoc platform provides a short latency and an heterogeneous computing environment. However, the ad-hoc capabilities are generally limited, and hence, are unable to perform intensive computational tasks [START_REF] Makris | A survey on context-aware mobile and wireless networking: On networking and computing environments' integration[END_REF]. Moreover, scheduling, mobility, security, and privacy present other issues.

3. Hybrid Platform.

The hybrid infrastructure is a mixing of proximate devices, be they mobile or immobile, with the distant Cloud as depicted in Figure 3.8. The goal is to strike a balance between network latency, server capabilities, and server availability [START_REF] Rahimi | Mapcloud: Mobile applications on an elastic and scalable 2-tier cloud architecture[END_REF]. The main idea is to offload the delay-sensitive tasks to the proximate infrastructure, and the CPU-intensive tasks to the distant Cloud. Such infrastructures are useful in terms of maximizing the benefits of offloading computation. They deliver enhanced security and privacy features and increase the QoS. Mobile users can reap advantages from these features. However, due to its mobile nature, the deployment, management, and resource scheduling of such an infrastructure is not a trivial task. Table 3.3 compares the three aforementioned platforms based on several characteristics, while Table 3.4 reviews various frameworks from the server perspective. In the table, symbols: , , and mean, respectively, low, medium, and high.

Server Improvements

In this section, we present several improvements that, when applied to the remote servers, increase the offloading gain by reducing the network latency and execution time.

1. Caching. Caching refers to the storage of data near the mobile user in order for it to be used in the future. We distinguish four categories of caching: (i) software package caching [START_REF] Goyal | A lightweight secure cyber foraging infrastructure for resourceconstrained devices[END_REF], in which software packages are cached for future installations to avoid download delays; (ii) service code caching [START_REF] Kovachev | Adaptive computation offloading from mobile devices into the cloud[END_REF], which is used to store code sources in jar files; (iii) VM synthesis caching [START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF], which is employed as a pre-fetching technique to reduce VM synthesis delay; and (iv) data caching [START_REF] Fesehaye | Impact of cloudlets on interactive mobile cloud applications[END_REF], which stores data, such as video streams, near the mobile user in what are known as Content Delivery Networks (CDNs). Caching decreases network latency and reduces redundant traffic. However, it increases the overheads, cost, and consistency issues.

2. Parallel execution. Parallelism is the simultaneous execution of different program sections. It is designed in two separate and complementary functionality: computation, which expresses calculations in a procedural manner, and synchronization, which abstracts communications and concurrency controls. Parallelism in the Cloud is viewed from two perspectives: (i) intra-server parallelism, wherein the server hosts multiple VMs. In addition to performance improvement, this approach reduces server authentication and selection time; (ii) inter-server parallelism, which performs parallel execution on multiple servers, each of which hosts one VM. Each server mandates an authentication to deploy a VM, which induces high network overhead and operational complexity. Kosta et al. [START_REF] Thinkair | Dynamic resource allocation and parallel execution in the cloud for mobile code offloading[END_REF] devised a framework that uses these two approaches, and Zhang et al. [START_REF] Zhang | Towards an elastic application model for augmenting computing capabilities of mobile platforms[END_REF] proposed to design elastic mobile applications using weblets distributed over multiple servers. Despite the performance improvement and the scalability amelioration, parallelism increases power consumption, mandates authentication, and requires more hardware. The system clones Android mobile platforms into VMs in the Cloud. Both the VM and the mobile device are synchronized to keep both copies of the application updated by sending only the segment of the data stack that is created by the application.

The system stores input events using a record/reply mechanism with pseudo checkpoint methods, the purpose is to increase the quality and efficiency of computation offloading. Doing such, involves efforts from the application developers to specify the global and local states of the application.

Cloud NA CMH [START_REF] Manjunatha | Power of clouds in your pocket: An efficient approach for cloud mobile hybrid application development[END_REF] Application in CMH model are developed in two steps; the heavy components are developed for the Cloud-side execution, while the lightweight and native code of the application are developed for mobile device execution. The CMH framework does not need for profiling, partitioning and code migration, hence the system induces least overhead. Once the computation on the Cloud is finished, the results are send back to the mobile device for integration with the other components. The application developing is complex due to the interoperability, heterogeneity, and vendor's lock-in problems of infrastructures.

Cloud NA

Kun et al. [310]

The authors have proposed a framework for offloading intensive tasks. To make a proper offloading decision, authors have executed the same application task under three virtual Fog, and two virtual Cloud infrastructures, then identified the parameters impacting the offloading performance. The problem was formulated, using a constrained graph partitioning problem. The authors used the method granularity level for offloading. Fog NA

Liu et al. [169]

A power-constrained delay minimization problem for computation offloading based on Markov decision processes has been proposed and adapted to the MEC context. The authors have considered a mobile device running computation-intensive and delay-sensitive applications. The framework considers the mobile device as a composition of a task buffer, a transmission unit, and a processing unit. Authors propose an algorithm based on the average delay and power consumption at the mobile device for each task to solve the optimization problem.

MEC NA NA

You et al. [315]

A multi-user resource allocation for MEC has been also proposed. The model is formulated as a convex optimization problem to minimize the mobile energy consumption considering the computation overhead and the capacity of the MEC. The model derives an offloading priority for each user according to its channel gain and energy consumption. A low priority derives a minimum offloading, while a high priority performs a complete offloading.

MEC NA NA NA NA MOMCC [8]
The framework uses the SOA, and leverages a cluster of nearby mobile devices to compute the offloaded tasks in a collaborative way. An application is a set of services, developed independently from others. Several smartphones, in near vicinity, are collaborating to compute the services, and therefore earn some money. To offer an IaaS, mobile devices register with UDDI and negotiate the services to compute. Several issues should be considered including, resource limitation, security, and mobility of users.

Ad-Hoc

VMCC [START_REF] Huerta-Canepa | A virtual cloud computing provider for mobile devices[END_REF] Leverages an ad-hoc cluster of nearby smartphones as an infrastructure. The application code is updated with a proxy and RPC instructions. For each application, the framework needs to determine the number of smartphones needed, the offloading overhead, and the security requirements. Hence, the system incessantly traces the smartphones and their geolocation. Upon the partitioning step, the remote partition composed of small codes is offloaded among the available smartphones. The results are integrated back in the mobile device upon completion.

Ad-Hoc

SAMI [246]

The infrastructure is composed of Cloud, nearby MNO, and cluster of very close MNOs authorized dealers. This architecture proposes a multi-tier IaaS that aims to improve the performance, increase the offloading flexibility, and save energy on the mobile devices. MNO dealers compute the latency-sensitive tasks. Depending on the resource scarcity and user mobility, tasks can be computed on the MNOs or on the Cloud. The resource allocation is done by an arbitrator entity, which considers several metrics including resource requirements, latency, and security requirement of services.

Hybrid MOCHA [START_REF] Soyata | Cloudvision: Real-time face recognition using a mobile-cloudlet-cloud acceleration architecture[END_REF] Combines Cloudlets and Cloud to perform a computation offloading. The mobile device sends to the Cloudlet the heavy tasks, the latter partitions these tasks between itself and the Cloud to improve the QoS. MOCHA uses two partitioning algorithms; fair distribution of computation among Cloudlets and Cloud, and greedy distribution, wherein tasks are distributed between the Cloudlets and the Cloud according to their responsiveness. Hybrid NA NA We distinguish two approaches; the first relies on the pre-installation of root partitioned images with applications, operating system boot-up scripts, and software packages [START_REF] Goyal | A lightweight secure cyber foraging infrastructure for resourceconstrained devices[END_REF]; while the second approach provides a pre-installed run-time environment to ease the deployment of mobile applications in the Cloud [154]. Pre-installation decreases network communications and delay as there is no need for application migration. However, it wastes resources when applications are not used and requires maintenance.

Leveraging proximate infrastructure. Proximate infrastructures includes Cloudlets, MEC, and

Ad-Hoc Cloudlets. The aim is to reduce the WAN latency when leveraging Cloud resources.

Chapter 6 reviews some research works leveraging proximate infrastructures, particularly MEC. In addition to the low network latency induced by these platforms, leveraging proximate resources minimizes the data transport cost. However, proximate infrastructures require isolation to prevent users from unauthorized access. Moreover, deployment requires investigations into illegal and opportunistic access to these proximate platforms and negotiating an SLA between the mobile user and the infrastructure provider.

Platform Type

The IaaS oriented for computation offloading is presented to mobile users in the following two forms.

• Physical resources: These resources concern powerless mobile devices and some Cloudlets, which do not support virtualization technology [START_REF] Nasseri | MDP based optimal policy for collaborative processing using mobile cloud computing[END_REF].

• Virtual resources: Mobile users offload computation to servers in the Cloud, Fog, or MEC. These servers can perform several tasks in parallel. Therefore, a consolidation is mandatory for such resources. Usually, infrastructure providers, such as Amazon, provide resources in the form of VMs. There are several implications to virtualization-based approaches in computation offloading [START_REF] Lee | Architecture-aware automatic computation offload for native applications[END_REF][START_REF] Shuja | Case of ARM emulation optimization for offloading mechanisms in mobile cloud computing[END_REF].

Indeed, virtualization is only feasible in high-bandwidth networks. It induces an overhead compared to native executions of applications [START_REF] Shuja | Case of ARM emulation optimization for offloading mechanisms in mobile cloud computing[END_REF]. A mobile device should support virtualization technology, which is not the case for smartphones and tablets. Virtual Machine Managers (VMMs) should be able to suspend, resume, and migrate VMs; on the other hand, the infrastructure should have enough resources to successfully launch the VMs and execute applications [START_REF] Yu | Toward cloud-based vehicular networks with efficient resource management[END_REF]. Several virtualization techniques have been used for computation offloading, which include:

1. VM Migration: Some VMMs support VM migration, such as OpenStack 24 , KVM 25 , and Xen 26 . In VM migration, applications are encapsulated inside VMs and migrated (i.e., pages are transferred) to a remote infrastructure [START_REF] Jararweh | Resource efficient mobile computing using cloudlet infrastructure[END_REF]. After processing the applications, the VMs are migrated back to mobile devices (particularly laptops). Techniques, such as compression and write throttling [START_REF] Shuja | A survey of mobile device virtualization: Taxonomy and state of the art[END_REF],

have been used to minimize the impact of the VM size on the bandwidth-scarce-mobile devices.

The ThinkAir framework [START_REF] Thinkair | Dynamic resource allocation and parallel execution in the cloud for mobile code offloading[END_REF] uses VM migration for computation offloading.

2. VM Overlay: This refers to Dynamic VM synthesis, proposed in [START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF] for Cloudlets. The Cloudlet creates VMs dynamically. A small VM overlay, such as a bootstrap configuration file, is delivered to the Cloudlet, which possesses the base VM from which the overlay is delivered. The overlay is applied to the VM, which starts the execution form an identical state to that defined in the overlay.

This approach requires a base VM, a VM customization script (VM overlay), and a VM clean-up script.

3. On-Demand VM provisioning: The VM is created on demand to satisfy the requirements of mobile devices [START_REF] Echeverría | On-demand VM provisioning for cloudlet-based cyber-foraging in resource-constrained environments[END_REF]. The mobile device transfers a provisioning script to the discovered infrastructure, such as a Cloudlet. Then the latter composes a VM that should fulfil the requirements of the mobile device. The Cloudlet has two choices: (i) select an already configured VM from the VM repository that hosts the necessary components, or (ii) select a base VM and install the required components [START_REF] Wang | Rethink the virtual machine template[END_REF]. On-demand VM provisioning differs from VM overlay as, in the latter, the infrastructure hosts only the base VM, and the overlay is provided by the mobile device; while in on-demand VM provisioning, the infrastructure hosts the base VM, server components, and provisioning software.

Issues

Several research works have contributed to infrastructures being efficiently leveraged for computation offloading. However, various issues and challenges have been raised. These challenges, addressed in the literature, are still open. In the following, we highlight most of them:

• Security: Security is central in Cloud-oriented computation offloading. Cloud security issues have been discussed in [START_REF] Khan | Towards secure mobile cloud computing: A survey[END_REF][START_REF] Xiao | Security and privacy in cloud computing[END_REF], they include: confidentiality, integrity, availability, accountability, and privacy of data. In MCC, security should be considered from both the mobile device and Cloud sides. In terms of the mobile users, mechanisms should be defined to detect malicious codes (e.g., viruses, and Trojan horses). These mechanisms should run incessantly, which would drain considerably the mobile device's battery. Some research works [START_REF] Oberheide | Virtualized in-cloud security services for mobile devices[END_REF][START_REF] Wang | Secure and efficient access to outsourced data[END_REF] have been introduced

to perform computation offloading of malicious code scanning for security and energy-saving objectives. When it comes to the Cloud, stored data can be lost, altered, or denied. Several proposals for security of data have been put forward, which include homomorphic encryption [START_REF] Gentry | Fully homomorphic encryption using ideal lattices[END_REF][START_REF]Computing arbitrary functions of encrypted data[END_REF],

reputation-based trust establishment [START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF], and authentication mechanisms [START_REF] Goyal | A lightweight secure cyber foraging infrastructure for resourceconstrained devices[END_REF]. Other proposals have been made in [START_REF] Chow | Controlling data in the cloud: outsourcing computation without outsourcing control[END_REF][START_REF] Wang | Enabling public verifiability and data dynamics for storage security in cloud computing[END_REF][START_REF] Wang | Secure and efficient access to outsourced data[END_REF], which aim to protect outsourced date. Despite security and privacy issues, these mechanisms induce delay due to authentication and cypher execution.

• Scalability: Scalability refers to unbounded resources purchased in several quantities at any time.

It ensures service provisioning regardless of the number of mobile devices, VMs allocating the necessary computing resources, and VM migration services being performed for load balancing [START_REF] Badger | Draft cloud computing synopsis and recommendations[END_REF][START_REF] Rimal | A taxonomy and survey of cloud computing systems[END_REF]. Some frameworks, such as CloneCloud [START_REF] Chun | Augmented smartphone applications through clone cloud execution[END_REF], Cloudlet [START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF], Kumar and Lu [START_REF] Kumar | Cloud computing for mobile users: Can offloading computation save energy?[END_REF], and Misco [START_REF] Dou | Misco: a mapreduce framework for mobile systems[END_REF], are deficient frameworks in terms of a centralized management of the distributed platform. The unavailability of centralized resources is a challenging research issue for ad-hoc and Cloudlets-based systems [START_REF] Huerta-Canepa | A virtual cloud computing provider for mobile devices[END_REF][START_REF] Liu | An optimized solution for mobile environment using mobile cloud computing[END_REF]. Some other frameworks have addressed the scalability issue. DISC [START_REF] Ananthanarayanan | True elasticity in multi-tenant data-intensive compute clusters[END_REF] have been proposed to achieve elasticity for data-intensive service computing.

Rai et al. [START_REF] Rai | Generalized resource allocation for the cloud[END_REF] proposed a resource allocation scheme by mapping Cloud resources to a single multidimensional resource vector. Zeta [START_REF] He | Zeta: scheduling interactive services with partial execution[END_REF] is a scheduling algorithm that improves the response quality to meet QoS with few resources. CloudScale [START_REF] Shen | Cloudscale: elastic resource scaling for multitenant cloud systems[END_REF] is another framework designed to manage resource elasticity and scalability.

• Consolidation: Resource consolidation consists of using virtualization technology to instantiate multiple VMs. The VMs are dynamically mapped onto a pool of physical resources and concurrently sharing the server resources through the hypervisor. Consolidation improves the utilization of server resources and reduces energy consumption [START_REF] Hermenier | Entropy: a consolidation manager for clusters[END_REF]. Consolidation depends highly on the resource variability of mobile applications. Maximizing resource utilization between a maximum number of customers without breaking the users' SLA is challenging. The Cloud provider should define a trade-off between high consolidation and high performance. He should face with the resource demand variability for a single customer and between multiple customers to handle resource peak utilization. In other words, the Cloud provider should design a system to make server consolidation more efficient and less risky.

• Heterogeneity: Numerous infrastructure providers expose various services (IaaS, PaaS, and SaaS), making infrastructure heterogeneous. Interoperability and portability are two prominent challenges caused by the heterogeneity of Cloud infrastructures [START_REF] Hogan | Nist cloud computing standards roadmap-version 1.0[END_REF]. Cloud business competition is the main cause of this diversity [START_REF] Durkee | Why cloud computing will never be free[END_REF]. A variety of hardware with different architectures between ad-hoc systems, Cloudlets, MEC, Fog, and the Cloud causes the heterogeneity issue for computation offloading, especially when relying on hybrid infrastructures. Connecting heterogeneous systems (i.e., interoperability) is challenging due to the absence of interfaces and standards between infrastructures. In addition, code portability is not an easy task.

Computation Offloading Taxonomy: From the Framework Perspective

In what follows, we describe state-of-the-art computation offloading from frameworks point of view.

The taxonomy proposes seven axis. The first one (Section 3.7.1) is related to code annotation, in which we describe how to annotate the programs of applications to distinguish the anchored from movable code. In Section 3.7.2, we locate the offloading framework either on the mobile device or on the server.

Section 3.7.3 distinguishes whether data are present on the mobile device, on the server or saved in a third-party device. Time-scale offloading types and the generic steps considered in computation offloading are reminded, respectively, in Sections 3.7.4 and 3.7.5. The granularity of offloading is considered in Section 3.7.6. Finally, the framework nature is described in Section 3.7.7. Most applications are designed in two separate sections:

• The desired functionality section, which expresses the main job of the application in a procedural manner. Only this section can be offloaded.

• The deployment feasibility section, which extends the main section with useful code to manage, for example, parallelism and concurrency, and, especially, to interact with the device and mobile user.

The deployment feasibility section cannot be offloaded due to the dependency constraint (see Section 3.4.4). This section of code is annotated before partitioning to add the dependency constraint to the model and limit the search for all of the decision-making possibilities. The annotation is done by adding metadata to the source code. We cite two methods: (i) manual annotation, which is done at the time of design by a developer who expends considerable time and efforts annotating the code by examining the scope of his application components [START_REF] Balan | Simplifying cyber foraging for mobile devices[END_REF][START_REF] Chu | Roam, a seamless application framework[END_REF][START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF] Gu | Adaptive offloading inference for delivering applications in pervasive computing environments[END_REF][START_REF] Iyer | Automated refactoring of objects for application partitioning[END_REF][START_REF] Newton | Wishbone: Profile-based partitioning for sensornet applications[END_REF][START_REF] Ra | Improving energy efficiency of personal sensing applications with heterogeneous multi-processors[END_REF][START_REF] Smit | Partitioning applications for hybrid and federated clouds[END_REF][START_REF] Tilevich | J-orchestra: Automatic java application partitioning[END_REF]286,[START_REF] Wang | Parametric analysis for adaptive computation offloading[END_REF]; and (ii) automatic annotation, in which a profiler performs a deep profiling of the application to create a graph dependency, which is used to identify relevant information about the possibility of offloading [START_REF] Chun | Clonecloud: elastic execution between mobile device and cloud[END_REF][START_REF] Giurgiu | Dynamic software deployment from clouds to mobile devices[END_REF][START_REF] Goraczko | Energy-optimal software partitioning in heterogeneous multiprocessor embedded systems[END_REF][START_REF] Klamma | Framework for computation offloading in mobile cloud computing[END_REF][START_REF] Sinha | Techniques for fine-grained, multi-site computation offloading[END_REF][START_REF] Yang | A framework for partitioning and execution of data stream applications in mobile cloud computing[END_REF].

Framework Location

Two possible locations for the offloading frameworks are identified from the computation offloading taxonomy. Offloading frameworks are designed with functionalities that perform the offloading steps.

• Mobile device. The offloading framework is located on the mobile device, which reduces network communications between the mobile device and server. However, it induces resource consumption (CPU, battery, and memory) on the mobile device. Several studies have been conducted with the offloading frameworks located on mobile devices [START_REF] Balan | Tactics-based remote execution for mobile computing[END_REF][START_REF] Flinn | Balancing performance, energy, and quality in pervasive computing[END_REF][START_REF] Park | Selective grid access for energy-aware mobile computing[END_REF].

• Remote server. The offloading framework is distributed between the mobile device and one or more remote servers. Modules on the mobile device may include profiling, monitoring, and a proxy;

while modules on the server may include modelling, partitioning, and scheduling 27 . Despite, the optimization of resource consumption on the mobile device, this solution induces high network communications to periodically send profiling and monitoring information, which may increase the execution time [START_REF] Begum | A dht-based process migration policy for mobile clusters[END_REF][START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF].

We compare the two solutions in Table 3.5. We highlight the advantages versus disadvantages of each solution. ✗ Updates data on server frequently to make the best decision according to changes, ✗ Increases energy consumption due to high network communications, ✗ Restrains mobility, as modelling and partitioning modules should be pre-installed, ✗ Increases execution time due to network latency induced by the profiling transfer, ✗ Makes incorrect decisions as this latter is delayed due to the profile transfer. 27 Some frameworks include scheduling module to reorder task execution according to the call graph and execution deadlines 60 3.7. COMPUTATION OFFLOADING TAXONOMY: FROM THE FRAMEWORK PERSPECTIVE

Data Availability

Data may represent inputs and outputs, profiling and monitoring statistics, and code sources.

• Inputs and outputs. Inputs are entry parameters needed to execute a program; while the outputs are the results obtained from program execution. In a call graph, the outputs of a vertex (e.g., method or class) are the inputs of the successor vertex.

• Profiling and monitoring data. This is gathered information about the execution of an application, which includes CPU execution time, energy consumption, and execution call graph.

• Source code. This represents a program's code in the form of files in which the functionalities of the program are described using a programming language, such as Java, C #, and C + +.

In state-of-the-art computation offloading, we distinguish three locations for data.

1. Mobile device. Data are located on the mobile device [START_REF] Balan | Tactics-based remote execution for mobile computing[END_REF][START_REF] Othman | Power conservation strategy for mobile computers using load sharing[END_REF][START_REF] Park | Selective grid access for energy-aware mobile computing[END_REF]. According to the location of the offloading framework and the identified partitions, data might need to be transferred to the server. Considering the partitions, if we suppose we have two tasks A and B , where the B inputs are the A outputs, and A/B represents the local/remote partition, then both the B source code and A outputs are transferred to the server.

2. Remote server. Data are present on the server. That is, tasks A and B are pre-installed on the server (i.e., A and B constitute the remote partition) and profiling and monitoring is done on the server using estimations.

3. Third-party device A third-party device could be a device located between the mobile device and remote server [START_REF] Su | Slingshot: deploying stateful services in wireless hotspots[END_REF] acting as a dedicated cache or a server on the Internet. The aim is to save information, such as results of execution, profiling history, and application packages, for future use.

Table 3.6 presents a comparison between these three localities.

Offloading Type

According to the moment at which the profiling, modelling, and partitioning steps are taken, we distinguish three types of offloading, namely, static, dynamic, and semi-dynamic (or hybrid) offloading.

The reader should refer to Section 2.2.2 for details about these types of offloading.

Offloading Steps

As stated in Section 2.2, computation offloading follows four main steps, namely, profiling, modelling, partitioning, and communication. At the communication step, the server is supposed to be known by the mobile device. According to the literature, we distinguish two approaches for the servers discovery; manual and automatic. In the manual approach, the mobile device already knows the server, for example, a trusted Cloudlet with a static IP address. In this case, communications are manually established.

While in the automatic approach, the mobile device seamlessly discovers available servers using discovery mechanisms such as Jini [START_REF] Arnold | Jini specification[END_REF], Universal Plug and Play (UPnP) [START_REF] Miller | Home networking with universal plug and play[END_REF], or Service Location Protocol (SLP) [START_REF] Veizades | Service location protocol[END_REF]. If the offloading framework supports collaborative offloading, then servers should discover each other. The discovery step should be fast, especially in a high mobility environment.

The authors in [START_REF] Gu | Adaptive offloading for pervasive computing[END_REF] used the concept of master and slave. The master is the mobile device; while the server represents the slave. The slave runs a JVM to host any offloaded computation. When the mobile device decides to offload a computation, it initiates a discovery protocol to find nearby idle servers, which use a wireless broadcast discovery message, that can be adapted to UPnP or Jini. The GnJ framework [START_REF] Goyal | A lightweight secure cyber foraging infrastructure for resourceconstrained devices[END_REF] defines a service discovery server used by surrogates to register themselves via Extensible Markup Language (XML) descriptions. Mobile devices discover the surrogates by querying the service discovery server using XML requests. The service discovery server searches for the surrogates that match the mobile device request. The authors in [288] propose a middleware with an hybrid approach that offloads computations or adapts the application configuration to match it with the capabilities of the mobile device. The middleware is built on the OSGI service platform, which includes various modules, one of which is the java Service Location Protocol (jSLP). jSLP is a lightweight Java implementation of the SLP defined in RFC 2608 28 for resource discovery.

We propose to compare four well-known service discovery mechanisms in Table 3.7

Offloading Granularity

The granularity of offloading is the degree to which an application is partitioned. Current frameworks implement two granularity levels: fine-grained and coarse-grained. Figure 3.10, depicts the two granularity levels. The purpose of granularity is to deal with the security, consistency, performance, and [START_REF] Consortium | Salutation architecture specification version 2.1[END_REF] An open standard providing a service discovery protocol and session management protocol. The centralized repository is called a salutation manager. It was primarily designed for home and enterprise environments. Devices, services, and applications advertise their capabilities, and discover and access each other. 1. Fine-granularity includes: thread/process [START_REF] Chun | Clonecloud: elastic execution between mobile device and cloud[END_REF][START_REF] Newton | Wishbone: Profile-based partitioning for sensornet applications[END_REF], bloc (loop) [START_REF] Goraczko | Energy-optimal software partitioning in heterogeneous multiprocessor embedded systems[END_REF][START_REF] Wang | A computation offloading scheme on handheld devices[END_REF][START_REF] Wang | Parametric analysis for adaptive computation offloading[END_REF], method [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF],

class [START_REF] Gu | Adaptive offloading inference for delivering applications in pervasive computing environments[END_REF][START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF], object [START_REF] Niu | Bandwidth-adaptive partitioning for distributed execution optimization of mobile applications[END_REF][START_REF] Tilevich | J-orchestra: Automatic java application partitioning[END_REF][START_REF] Wang | Automatic partitioning of object-oriented programs for resourceconstrained mobile devices with multiple distribution objectives[END_REF], and weblet granularity [START_REF] Zhang | Towards an elastic application model for augmenting computing capabilities of mobile platforms[END_REF].

2. Coarse-granularity includes: VM [START_REF] Luo | From augmented reality to augmented computing: A look at cloud-mobile convergence[END_REF][START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF][START_REF] Shen | Cloudscale: elastic resource scaling for multi-tenant cloud systems[END_REF], application [START_REF] Ferreira | Service offloading in adaptive real-time systems[END_REF][START_REF] Xian | Adaptive computation offloading for energy conservation on batterypowered systems[END_REF], module [START_REF] Balan | Simplifying cyber foraging for mobile devices[END_REF][START_REF] Chu | Roam, a seamless application framework[END_REF][START_REF] Ra | Improving energy efficiency of personal sensing applications with heterogeneous multi-processors[END_REF][START_REF] Smit | Partitioning applications for hybrid and federated clouds[END_REF][START_REF] Yang | A framework for partitioning and execution of data stream applications in mobile cloud computing[END_REF], and bundle granularity [START_REF] Giurgiu | Dynamic software deployment from clouds to mobile devices[END_REF][START_REF] Giurgiu | Calling the cloud: Enabling mobile phones as interfaces to cloud applications[END_REF][START_REF] Klamma | Framework for computation offloading in mobile cloud computing[END_REF] Fine-grained ✓ Saves energy compared to coarse-grain because only the parts that benefit from remote executions are offloaded, ✓ Increases flexibility since more opportunities are created to locate functionality on remote servers, ✓ Supports high mobility, ✓ Increases security as a thread or method has less meaning to attackers than modules or entire applications.

✗ Intensive monitoring at runtime due to the large number of application components to cover, ✗ Resource intensive synchronization mechanism, ✗ Must ensure consistency between mobile device and server, ✗ Increases the resolution overhead due to the large representation of the application, ✗ Programmer greatly involved in annotating the source code for their applications.

Coarse-grained

✓ Simple offloading mechanism, as it reduces programmer responsibility, ✓ Requires low monitoring overhead as the application is represented as a whole or with only a few components, ✓ Less resources are used (memory, CPU, and energy) in the profiling, modelling, and partitioning steps, ✓ Reduces the resolution overhead as the application is represented with a small model.

✗ Increases data transmission, as large classes cause large migration and remote invocation overhead, ✗ Not suitable for mobility; larger tasks increase the probability of task completion failure due to server disconnection, ✗ Increase the vulnerability to network threats, ✗ Not suitable for resource-constrained environments, such as edge computing.

Framework Nature

This section focuses on the models used to describe the partitioning optimization problem. We classify the state-of-the-art models into three axes. In the first, VM migration is adopted to offload computation;

the second axis considers application migration in order to save bandwidth and latency induced by VM migration; the third and last axis describes works that effectively spread applications into a client-server model. While the first two approaches are proposing to migrate the application as a whole, without profiling or partitioning, in the third approach, the application is partitioned into local and remote partitions. Figure 3.11 portrays these different axes with a focus on the partitioning models.

VM Migration

The application is hosted on a VM, which is migrated to a remote server for computation. On the server, a VMM reserves a pool of resources for the migrated VM, which is then resumed. When the application execution finishes, the VM is migrated back to the mobile device (mostly laptops). VM migration uses two approaches:

• Cold migration. The VM is stopped during the migration step when the entire VM is migrated to the server. The VMM will then resume the VM and run the application. The downtime 29 is proportional to the VM size; larger the VM size, the longer the downtime is. Cold migration is used for application running on background, such as virus scanning, indexing files for fast searches, and analysing photos. 29 Is the period of time during which the VM is not accessible. • Live migration or hot migration. This minimizes downtime by ensuring execution continuity of services and applications during the migration step. The state of the VM on the server is progressively updated during migration. Live migration is carried on various network protocols, such as the Locator Identifier Separation Protocol (LISP) [START_REF] Raad | Achieving sub-second downtimes in internet-wide virtual machine live migrations in LISP networks[END_REF] and IP mobility [START_REF] Watanabe | A performance improvement method for the global live migration of virtual machine with ip mobility[END_REF].

To ensure a good QoE, we should consider the case of user mobility in VM migration. Follow me Cloud (FMC) is a recent approach employing live migration [START_REF] Ksentini | A lisp-based implementation of follow me cloud[END_REF] which manages VM mobility to optimal location, according to user location. Various VM migration-based frameworks been proposed [START_REF] Thinkair | Dynamic resource allocation and parallel execution in the cloud for mobile code offloading[END_REF][START_REF] Luo | From augmented reality to augmented computing: A look at cloud-mobile convergence[END_REF][START_REF] March | µcloud: Towards a new paradigm of rich mobile applications[END_REF][START_REF] Satyanarayanan | Pervasive computing: vision and challenges[END_REF][START_REF] Satyanarayanan | The case for vm-based cloudlets in mobile computing[END_REF][START_REF] Shen | Cloudscale: elastic resource scaling for multi-tenant cloud systems[END_REF].

Entire Application Migration

Entire application migration consists on offloading the entire processing job of the running application to remote servers. In the beginning, the application is running on the mobile device. In critical condition, including, battery draining, insufficient memory, and/or approaching processing deadlines, the running instance of the application is offloaded to a remote server [START_REF] Liu | An optimized solution for mobile environment using mobile cloud computing[END_REF]. We distinguished two approaches in the literature:

• CDF: The authors in [START_REF] Xian | Adaptive computation offloading for energy conservation on batterypowered systems[END_REF] have proposed to use the timeout approach [START_REF] Kremer | A compilation framework for power and energy management on mobile computers[END_REF] to reduce energy consumption on mobile devices. The application is initially executed on the mobile device with a timeout (set to the minimum computation time that can be benefit from offloading). If the computation is not completed by the timeout, then it is offloaded. The timeout is called the break-even time. To compute the timeout, the authors proceeded as follows: first, they formulated the energy consumption on the mobile device for offloading the application using the following equation:

P a T c = P t x D i n R t x + P r x D out R r x + P l T c α + P n T c
α , where P a /P l , P t x /P r x , and P n represent, respectively, the active/idle power of processor, the transmission/reception power, and the idle power of the network interface. T c /T s is the execution time on the client/server. D i n /D out is the inputs/outputs size.

Finally, R t x /R r x represent the transmission/reception speed, and α is the server speed. The authors have then solved the above equation for T c to obtain the break-even time T be : T be =

P t x D i n R t x +P r x D out Rr x P a - P l α -Pn α .
The authors have stated that the statistical distribution of the execution time is stable and changes slowly. Therefore, they proposed to use a discrete cumulative distributed function (CDF) of the execution time for the past execution instances. The authors have divided the range of execution times between zero and the worst-case execution time, into n equal intervals t i , i = 0, 1, ..., n. The discrete CDF is denoted with ψ. The probability of consuming the i t h interval is: 1 -ψ(i -1).

To minimize the total energy used by the client, the authors have formulated the problem via Equation 3.24. Here, δ i represents the interval length, and x denotes the number of intervals for the optimal time-out. x is an integer variable in the set {0, 1, ..., n}. To find x, and, therefore, the optimal time-out, the authors have calculated the energy consumption for all the values from 0 to n using Equation 3.24. The x value that results in the least energy consumption is then the optimal time-out.

Mi ni mi ze

x � i =1 � 1 -ψ(i -1) � δ t (P a + P n ) + (1 -ψ(x)) � P t x D i n R t x + P r x D out R r x � + � (1 -ψ(x))xδ t + n � i =x+1 δ t (1 -ψ(i -1)) � P l + P n α (3.24)
• Linear Regression: The authors in [START_REF] Ferreira | Service offloading in adaptive real-time systems[END_REF] proposed to use linear regression to dynamically and seamlessly adapt to the varying execution times through computation offloading. Their approach consists of continually monitoring the execution time t cor e of an application, then calculating a linear regression to predict the evolution of t cor e based on the history of executions. The authors have defined a well-known value, the cycle period, t p . For instance, in game engines, the value of t p is equal to 33.3 ms to generate 30 frames per second (fps), which is a satisfying value for gamers. Therefore, if t p cannot be achieved in the future, then the computation offloading of the application is triggered in advance. In addition, when computation offloading is no longer advantageous, the application execution again takes place on the mobile device. The decision to offload the application is taken when Inequality 3.25 is true. , where m and b are the parameters defining the linear regression line t � cor e = mt + b, m is computed as follows: m = n � n i =0 (t i ×t cor e,i )-

� t xM
� n i =0 t i × � n i =0 t cor e,i n � n i =0 (t i ) 2 -( � n i =0 ) 2
, and b is formulated with b =

� n i =0 t cor e,i -m � n i =0 t i n
. n is the number of past executions. The other value that is required to find when to start offloading is t mob , which is the elapsed time between when the offloading decision is taken and when the application is ready for execution on the remote surrogate.

Application Partitioning

The application is represented by a theoretic model, such as graph theory. Then the model is solved using either well-known algorithms or heuristics. The model is solved to satisfy an objective function.

Various solutions have been proposed to represent and partition an application. For the sake of accuracy, exact methods have been used to find the optimal partition, we can name graph models with partitioning algorithms, such as Ford Fulkerson, Stoer Wagner, and Kuris et al., are applied to find the minimum cut, and the 0-1 ILP. However, the graph and ILP resolution may take a long time, which drastically increases with the size of the model. To cope with this, heuristics have been proposed: Branch & Bound, Gready, and genetic algorithms, to name a few. In recent years, application modelling has shifted to game theory, MDP models, Queuing theory, and machine learning representation. In this following section, we describe these different approaches.

i. Exact Methods.

• Linear Programming (LP): LP, also called linear optimization, is a mathematical representation of a given problem aiming at minimizing or maximizing one or more metrics, which are represented in a linear equation. Formally, an LP is a methodology that searches for an optimal solution of a mathematical problem using a linear objective function, subject to linear equality and inequality constraints. The main benefit of LP is that it always finds the optimal solution, when it exists.

However, solving LP problems may take a long time, which increases with the problem size [START_REF] Niemann | An algorithm for hardware/software partitioning using mixed integer linear programming[END_REF].

In the context of computation offloading, LP formulates applications into a mathematical optimization problem, where, for example the objective function is to optimize energy consumption or improve performance. Some or all the variables are restricted to be integers. Three variants of LPs have been implemented for computation offloading namely: ILP, 0-1LP, and Mixed Integer Linear Programing [START_REF] Gu | Adaptive offloading inference for delivering applications in pervasive computing environments[END_REF][START_REF] Klamma | Framework for computation offloading in mobile cloud computing[END_REF][START_REF]Adaptive computation offloading from mobile devices into the cloud[END_REF][START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF][START_REF] Verbelen | AIOLOS: middleware for improving mobile application performance through cyber foraging[END_REF][START_REF] Verbelen | Dynamic deployment and quality adaptation for mobile augmented reality applications[END_REF][START_REF] Yang | A framework for partitioning and execution of data stream applications in mobile cloud computing[END_REF][START_REF] Zhang | Towards an elastic application model for augmenting computing capabilities of mobile platforms[END_REF].

• Graph: An application is a collection of interacting processing components. When a component calls another one, the two components interact. In a typical client-server model, the client and server components belong to the same distributed application. The client components are computed locally on the client, and the server components run remotely on the server. Formally, we define A as an entire set of application components and, P s (P d , respectively) is the remote (local, respectively) partition. P s and P d should satisfy the two constraints: P s ∪ P d = A, and P s ∩ P d = ∅.

The first constraint stipulates that each component of the application is executed either on the client or on the server, while the second property points out that each component is executed at only one location. The application partitioning problem is equivalent to the graph partitioning problem. An application can be represented with an oriented graph G = (V, E ), where V is the set of n vertices (n = car d (V ) 30 ), and E is the set of edges connecting these vertices. The vertices represent the software components of the application, and the edges represent the interactions between components. We associate costs 〈w 1 , w 2 , . . . , w k 〉 (k ∈ N * ) with each vertex v ∈ V that represent the parameter or context of the component (usually execution time or energy consumption). An edge e i j ∈ E is associated with the frequency of invocation and data access between the two vertices v i and v j . The granularity level chosen to represent an application impacts highly the graph size and its complexity.

The decision on where to place a component, on the server or on the mobile device, depends highly on the objective function. This optimization problem is equivalent to finding a minimum cut for the corresponding graph. A minimum cut of a graph is a partition of the graph vertices into two disjoint subsets that are joined by at least one edge. The cut is minimal in the sense of considering the values affected to the graph. Several past studies have used graph partitioning to make offloading decision, we cite [START_REF] Ryan | A hybrid granularity graph for improving adaptive application partitioning efficacy in mobile computing environments[END_REF][START_REF]Adaptive application offloading using distributed abstract class graphs in mobile environments[END_REF][START_REF] Giurgiu | Dynamic software deployment from clouds to mobile devices[END_REF][START_REF] Giurgiu | Calling the cloud: Enabling mobile phones as interfaces to cloud applications[END_REF][START_REF] Gu | Adaptive offloading inference for delivering applications in pervasive computing environments[END_REF][START_REF] Niu | Bandwidth-adaptive partitioning for distributed execution optimization of mobile applications[END_REF][START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF][START_REF] Pedrosa | The case for complexity prediction in automatic partitioning of cloud-enabled mobile applications[END_REF][START_REF] Smit | Partitioning applications for hybrid and federated clouds[END_REF]286,[START_REF] Wang | Parametric analysis for adaptive computation offloading[END_REF].

• Hybrid: Some frameworks incorporate the combined features of the graph-based and LP-based application partitioning algorithms (APAs). They tend to extract the important features of graphbased and LP-based APAs to improve application performance. The first step is to represent the application using a graph, then an ILP is drawn, based on the graph representation. Some studies have been done using the hybrid approach, these include [START_REF] Chun | Clonecloud: elastic execution between mobile device and cloud[END_REF][START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF] Goraczko | Energy-optimal software partitioning in heterogeneous multiprocessor embedded systems[END_REF][START_REF] Newton | Wishbone: Profile-based partitioning for sensornet applications[END_REF][START_REF] Sinha | Techniques for fine-grained, multi-site computation offloading[END_REF][START_REF] Yang | A framework for partitioning and execution of data stream applications in mobile cloud computing[END_REF].

ii. Heuristics.

• Genetic Algorithms (GA): The GA is an heuristic that belongs to the class of evolutionary algorithms. It is a population-based method, inspired by the process of natural selection, which aims to evolve toward a global optimized solution from a population of solutions [START_REF] Deb | A fast and elitist multiobjective genetic algorithm: NSGA-II[END_REF]. Each candidate solution corresponds to a chromosome, which can be mutated and altered, in the population of genes. A typical genetic algorithm requires: (i) a genetic representation of the solution, i.e, encoding; and (ii) a fitness function to evaluate the solution domain. A random solution is chosen by the algorithm, then improved through a repetitive application of selection, crossover, and mutation.

In the initialization phase, a set of parameters should be defined, namely, the population size N , the maximum iteration number I , the mutation probability p m , and the crossover probability p c . In the selection phase, chromosomes are selected to recombine in order to generate the next population via crossover and mutation. In the crossover operation, two parent chromosomes which will generate a high-quality offspring (chromosomes) are combined. The mutation phase softly modifies the chromosomes to improve their fitness and avoid early convergence.

In a computation offloading optimization-based problem, a population represents the offloading strategy encoded as a vector of n integers 〈x 1 , x 2 , ..., x n 〉, where n is the total number of components 30 c ar d (V ) for cardinal, is the total number of elements in the set V .

(m) = w m ×L(r t F s )+(1-w m )×( � l vE l + � c E F c
) to calculate the fitness value of each chromosome. m represents a given mobile device; w m is a weight coefficient set according to the status of the mobile device; L(r t F s ) is the overall, final execution time for processing a mobile service on both the mobile device and the Cloud; E l is the energy consumption of a locally executed service; and E F c represents the final energy consumption of the service c. At the initialization, each chromosome

X i = (x i 1 , x i 2 , ..., x i d ) is a population i ∈ {1, 2, .
.., N }; d is the number of services in the mobile service workflow; x i j indicates whether the j t h service in the generation X i should be offloaded (i.e., x i j = 1) or computed locally (i.e., x i j = 0). The probability to select a chromosome for recombination is related to its fitness value F i , which is given by

pr s i = 1 -F i � S j =1 F j
. In the crossover operation, the selection of the parents, which generate the offspring is based on the selection probability pr s i . To this aim, the authors first, compare the local fitness of each gene by calculating a weighted factor

f i = w m × r t F i + (1 -w m ) × E F
i , where r t F i and E F i represent, respectively, the final execution time and energy consumption of a service i computed considering the mobility and fault-tolerance. Once the fitness of each gene is calculated, the genes with the best local fitness are chosen and copied to the offspring. In the mutation phase, the gene selection probability is pr m g = 1 -

f g � d j =1 f j .
• Queuing Theory: This is a branch of mathematics that studies and models the act of waiting in lines.The queuing theory is characterized by a set of parameters, namely: (i) the arrival process of customers, which are assumed to be independent and have a common distribution; (ii) the service times, which are independent and identically distributed; (iii) the service discipline, in which customers can be served using the First In First Out (FIFO) model, random order, or with priorities;

(iv) the server capacity, which is the number of servers computing in parallel; and (v) the waiting room, which is the queue capacity. Kendall has introduced a notation, under the form a/b/c, characterizing the range of these queuing models. Here, a specifies the arrival time distribution, b is the service time distribution, and c is the server capacity. For instance, models M /M /1, queue. The authors have defined two policies to make the optimal decision, the main difference is whether or not to consider the wireless channel and server stable. These policies are the offline optimal policy, which is based on the joint stochastic model using LP, and the online optimal policy, in which an M × N matrix is constructed, where each entry (i , j ) corresponds to an offline optimal solution obtained for given values of PE R i and P r e j ec t , j (probability of rejection).

M /M /S, M /G/1, G/M /1, M /D/
• Markov Decision Process (MDP): The MDP is a mathematical model of a problem in which decision making occurs in situations where the outcomes are partly random and partly under the control of the user. MDP is comprised of a decision agent, which checks the current state s and repeatedly makes a decision to perform an action a with a probability P . This transits it to another state s � and generates a reward r . An MDP is defined by the fourfold 〈S, A, R, P 〉, where S defines all the possible states of the system which are known to the decision-maker (user),

A encloses all the possible actions that can be taken by the decision-maker, R represents the reward for taking an action a in the state s, and finally, P represents the transition probability.

The aim behind using MDP is to find the optimal action to take for all possible combinations.

Nasseri et al. [START_REF] Nasseri | MDP based optimal policy for collaborative processing using mobile cloud computing[END_REF] have proposed an MDP-based approach combined with look-up tables for collaborative processing in an ad-hoc network. The authors have used the notion of reward and credit between the helpers and requester. Each mobile device is classified into a matrix according to its energy potential. A helper can accept or reject a request according to a calculated reward. The authors have used an MDP algorithm to calculate rewards. In the calculation of the reward, two parameters are considered, power and delay. The power reward function is given by: f p (s, a) = 1 1+e p a

, where p a denotes the power consumption of the current state for a given action a taken at a time t . Similarly, the delay reward function is expressed by:

f d (s, a) = 1 1+e d a ,
where d a is the response time. The sum of the delay and energy reward functions with a weight factor is given by: f (s, a) = w p × f p (s, a) + w d × f d (s, a). Therefore, the total reward function is

r (s, a) = f (s, a) -h(s, a)
, where h(s, a) is the transition cost function.

• Game Theory: Game theory [START_REF] Milchtaich | Congestion games with player-specific payoff functions[END_REF] studies mathematical models of conflict/cooperation between players, which are competing to use a set of resources. Each player chooses a set of resources to maximize/minimize his utility or cost. The cost and utility depend on the number of players in competition. a congested game is defined by a set of parameters 〈N , R, � i , n j , S i j 〉, where N = {1, ..., N } is a finite set of n players; R = 1, ..r is a finite set of resources; � i is the player i 's set of strategies; n j is the number of players who chose the strategy j ; and finaly, S i j is the cost function for player i when selecting resource j . Algorithms are defined to search for the Nash equilibrium, which is the optimal policy where no player can benefit by changing strategy while the other players keep their strategies unchanged. Ge et al. [START_REF] Ge | A game theoretic resource allocation for overall energy minimization in mobile cloud computing system[END_REF] used game theory to optimize the overall energy consumption in the MCC system. The energy optimization problem was formulated as a congestion problem between various players (mobile devices). Each player's strategy was to select the server minimizing overall energy consumption. The authors have shown that a Nash equilibrium always exists. Other studies include [START_REF] Cardellini | A game-theoretic approach to computation offloading in mobile cloud computing[END_REF][START_REF] Chen | Decentralized computation offloading game for mobile cloud computing[END_REF].

• Machine Learning: Machine learning explores the study and construction of algorithms that can learn from and make predictions on data. Machine learning appears in many guises, including web page ranking (Google engine), collaborative filtering (Amazone, Netflix), and automatic translation of documents. Machine learning appears in several forms, including; supervised/unsupervised, active/passive, helpfulness of the teacher, and online/batch learning. MALMOS [START_REF] Eom | MALMOS: machine learning-based mobile offloading scheduler with online training[END_REF] is a machinelearning-based mobile offloading scheduler, which makes a decision to offload a computation or not. MALMOS provides an online training mechanism to dynamically adapt decision making based on previous decisions. Other studies using machine learning to make offloading decisions have been proposed in the literature, we cite [START_REF] Tham | Energy-efficient mapping and scheduling of task interaction graphs for code offloading in mobile cloud computing[END_REF][START_REF] Eom | Machine learning-based runtime scheduler for mobile offloading framework[END_REF][START_REF] Folino | A framework for modeling automatic offloading of mobile applications using genetic programming[END_REF][START_REF] Shi | Ic-cloud: Computation offloading to an intermittently-connected cloud[END_REF].

Conclusion

A comprehensive survey of computation offloading in the literature, along with classifications, has been presented in this chapter. For each actor impacting the performance of computation offloading, we proposed a survey that is in line with computation offloading. A comparison between approaches has been provided. A review and comparison between the frequently used offloading frameworks in state-of-the-art computation offloading was also described in this chapter using different points of view.

Although several works have been proposed to remedy the problem of resource poverty and scarcity in mobile devices, a great effort is still required to accommodate applications, such as 3D-gaming, VR, and AR on current mobile devices. Indeed, these types of applications are of special interest, due to their real-time constraints, high resource demands, and complexity. Most of the old frameworks reviewed in this manuscript are obsolete, and they cannot manage such constraints. In the next chapter, we propose to dissect one of the most complex applications on the market, game engines, which is also a computationally intensive, resource demanding, and real-time interacting application.

PERFORMANCE ANALYSIS OF GAME ENGINES ON MOBILE AND FIXED DEVICES

Introduction

Game engines, like Unity 3D [1], are well-established tools to generate interactive, fully-multimedia environments that range from games to serious health applications. Game engines are complex software, which consume a lot of resources (including CPU, GPU, energy, and memory) to meet the demand of gamers. Indeed, the QoE depends on the interactivity and on the multimedia quality. Therefore, game developers design their best-seller games so that the game engine exploits the dedicated hardware that is typically present in "boxes" (e.g. Xbox, PS4), however resource-limited devices such as mobile devices (smartphone and tablet) cannot run these games, or at a much lower quality. Game engine developers are looking for solutions to address this issue and to embrace the mobile market, which represents billions of dollars of revenues.

To get rid of the limitations of end-user devices, one of the envisioned solutions is to leverage Cloud computing infrastructure. Developers of games have three options: Computation offloading, Cloud gaming, and Client-server architecture. Whilst the third approach (client/server) is widely implemented and mastered (research work mostly addresses network management [START_REF] Feng | On the geographic distribution of on-line game servers and players[END_REF][START_REF] Raaen | How Much Delay is There Really in Current Games?[END_REF][START_REF] Suznjevic | Analyzing the effect of TCP and Server Population on Massively Multiplayer Games[END_REF]), the two first approaches need more investigations regarding the software aspect of the game engines. Computation offloading requires low latency communication with the remote servers, which might be solved using MEC [START_REF]A hybrid edge-cloud architecture for reducing on-demand gaming latency[END_REF][START_REF] Kämäräinen | Towards pervasive and mobile gaming with distributed cloud infrastructure[END_REF] and Fog Computing [START_REF] Beskow | Reducing Game Latency by Migration, Core-selection and TCP Modifications[END_REF][START_REF] Lee | Demo: Delorean: using speculation to enable low-latency continuous interaction for mobile cloud gaming[END_REF]. However, deciding which module or function should be offloaded remains an open issue. The latency issues of Cloud gaming have also been frequently studied [START_REF]Latency can kill: precision and deadline in online games[END_REF][START_REF] Schlosser | An evaluation of qoe in cloud gaming based on subjective tests[END_REF][START_REF] Raaen | Can gamers detect cloud delay?[END_REF][START_REF] Sackl | QoE Management made uneasy: The case of Cloud Gaming[END_REF]. But, the management of virtualized resources (known as server consolidation) to prevent performance degradation and resource congestion has been rarely addressed [START_REF] Hong | Placing Virtual Machines to Optimize Cloud Gaming Experience[END_REF][START_REF] Zhang | A cloud gaming system based on user-level virtualization and its resource scheduling[END_REF].

To identify the best implementation option, developers should take into account the nature of the game and the considered platform. However, the body of literature related to performance evaluation for game engines is surprisingly small with regard to the significance of the gaming industries. In this regard, we may mention two position papers that called for research on game engine architecture [START_REF] Anderson | The case for research in game engine architecture[END_REF][START_REF] Tulip | Multi-threaded game engine design[END_REF], and some other work that focused on applying game engines to specific areas such as serious games [START_REF] Cowan | A survey of frameworks and game engines for serious game development[END_REF], research [START_REF] Lewis | Game engines[END_REF], and VR serious applications [START_REF] Cowan | A survey of frameworks and game engines for serious game development[END_REF][START_REF] Kot | Information visualisation utilising 3d computer game engines case study: a source code comprehension tool[END_REF][START_REF] Marks | Evaluation of game engines for simulated surgical training[END_REF]. The literature is missing work on the architecture and the performance analysis of modern engines. To fill this gap, we analyze in this chapter the performance of a well-known engine, Unity 3D.

Background: Game Engines

Game engine can be defined either as a framework for game creators or as a piece of code for gamers.

Accordingly, two definitions arise:

• The game engine is the set of tools (i.e., including low-level libraries, UI editors, and game multimedia management tools) that facilitate the work of a game developer in the process of creating a new game. The community of game developers considers thus a game engine as a framework or a platform. The framework provides an abstraction layer between the game content (i.e., multimedia content and main scripts) and the underlying hardware.

• The game engine is the set of software and data that runs on a device to provide the game to an end-user. The community of gamers considers a game engine as a piece of code. The border between the game and its framework is often confused. Some frameworks offer a clear separation, while others do not. All games created by Unity 3D share similarities, making them consistent Unity 3D game engines. We focus in this chapter on typical Unity 3D software, which we refer to as a game engine.

The delay for the result of an action to appear in the screen is central in gaming since the QoE is linked to interactivity [START_REF] Schlosser | An evaluation of qoe in cloud gaming based on subjective tests[END_REF]. We distinguish different genres of games with different requirement. An action game can be a First Person Shooter (FPS) or a Third Person Shooter (TPS) depending on whether the player is immersed in the scene or the avatar representing the player is visible. Studies [START_REF] Claypool | Latency and player actions in online games[END_REF][START_REF] Lee | Are all games equally cloud-gaming-friendly? an electromyographic approach[END_REF][START_REF] Quax | An evaluation of the impact of game genre on user experience in cloud gaming[END_REF] have shown that the acceptable delay depends on the game genre and varies from 100 to 200 ms, and even up to 500 ms for Role-Playing Game (RPG) and Massively Multi-player Online Games (MMOG).

Given their specific constraints regarding short delays, the management of FPS has received scientific efforts [START_REF] Armitage | REED: optimizing first person shooter game server discovery using network coordinates[END_REF][START_REF] Li | Play request dispatching for efficient virtual machine usage in cloud gaming[END_REF]. In this chapter, we tested several game genres and considered these requirements.

Another key criteria for high QoE is the frame rate. Gamers get the feeling of immersion in an animated world when the game engine generates a high number of Frames Per Second (fps). Less than 30 fps is widely seen as non-tolerable [START_REF] Claypool | Perspectives, frame rates and resolutions: it's all in the game[END_REF] and the recent trends in video and interactive multimedia is to deliver frame rate up to 90 fps [START_REF] Nasiri | Perceptual quality assessment of high frame rate video[END_REF]. The rendering pipeline (see Section 4.2.3) is the part of the game engine that generates one frame every x ms (x ranges from 33 to 10). A large part of our measurement study is on the time needed to generate one frame.

Game Architectures

We focus now on the game architectures. Traditional client-server. The game engine runs almost entirely on the client side and the server assists the game engine, either as a secured session manager or as a multi-player gaming enabler. When the server is a session manager, it manages authentication, updates game assets (for example new levels and new graphical environments) and matchs fighting players [START_REF] Véron | Matchmaking in multi-player on-line games: studying user traces to improve the user experience[END_REF]. As a multi-player gaming enabler, the server takes a stronger role: (i) it gets all the gamer input commands and forwards them to the other players, (ii) it implements anti-cheaters policy and acts as referee [START_REF] Yahyavi | Watchmen: Scalable cheat-resistant support for distributed multi-player online games[END_REF], and (iii) it manages Non-Player Character (NPC). Several architectures exist to deal with scalability. (1) client-server architecture with a single server [START_REF] Smed | Aspects of networking in multiplayer computer games[END_REF], (2) mirrored client-server [START_REF] Ng | A multi-server architecture for distributed virtual walkthrough[END_REF][START_REF] Webb | Enhanced mirrored servers for network games[END_REF][START_REF] Wolf | Proceedings of the 1st Workshop on Network and System Support for Games[END_REF], and (3) peer-to-peer architecture [START_REF] Buyukkaya | A survey of peer-to-peer overlay approaches for networked virtual environments[END_REF][START_REF] Yahyavi | Peer-to-peer architectures for massively multiplayer online games: A survey[END_REF].

Cloud gaming. The entire game engine runs in a remote server. The client includes only UI command and a video decoder. This architecture is similar as an interactive video delivery system. The player sends the commands to the server. The engine first converts the client commands into appropriate in-game actions, then computes the game logic, and renders the game scene. This scene is then compressed by a video encoder and forwarded to a video streaming module, which finally streams it to the client. The client decodes the video and displays the frames [START_REF] Chuah | Cloud gaming: a green solution to massive multiplayer online games[END_REF][START_REF] Huang | Gaminganywhere: The first open source cloud gaming system[END_REF][START_REF] Luo | Uniquitous: Implementation and evaluation of a cloud-based game system in unity[END_REF].

Cloud gaming solution relies on the concept of resource consolidation, which consists of using the virtualization technology: each game engine is encapsulated within a virtual machine (or a container) and dynamically mapped onto a pool of physical resources including CPU, GPU, memory, and Inputs/Outputs (I/O). Hence, these game engines concurrently share the server resources through the hypervisor. Studies have shown that virtualization techniques barely degrade the performance compared to a configuration where the game engine is the only program running in a bare-metal [START_REF] Shea | Cloud gaming: Understanding the support from advanced virtualization and hardware[END_REF].

Two main challenges arise with the Cloud gaming architecture: the delay and the resource use. In comparison to the delay issue in the traditional client-server architecture, Cloud gaming adds extra-delay due to video encoding and decoding. Despite various proposals [START_REF] Liu | Enhancing video encoding for cloud gaming using rendering information[END_REF][START_REF] Semsarzadeh | Video encoding acceleration in cloud gaming[END_REF], both processes take around 30 ms [START_REF] Shea | On gpu pass-through performance for cloud gaming: Experiments and analysis[END_REF]. With respect to the network communication delays (around 50 ms in average [START_REF] Choy | The brewing storm in cloud gaming: A measurement study on cloud to end-user latency[END_REF]), the overall delay is close to the threshold at which QoE is reported to degrade [START_REF]Latency can kill: precision and deadline in online games[END_REF][START_REF] Schlosser | An evaluation of qoe in cloud gaming based on subjective tests[END_REF]. Regarding resource use, the Cloud Gaming Providers (CGPs) have to find a trade-off. The smaller is the number of games concurrently running on a server, the higher can be the quality setting, but the higher are also the cost.

Moreover, the CGPs have to reserve some free spare resources in servers, otherwise some games may interrupt due to concurrent workload peaks. One of our motivations is to get a better understanding of the load variability and the internal modular structure of the game engine so as to make server consolidation more efficient and less risky.

Computation offloading. A subset of the game engine modules run on nearby server(s) [START_REF] Abolfazli | Cloud-based augmentation for mobile devices: Motivation, taxonomies, and open challenges[END_REF][START_REF] Khan | A survey of mobile cloud computing application models[END_REF][START_REF] Satyanarayanan | Cloudlets: at the leading edge of mobile-cloud convergence[END_REF].

Depending on specific criteria, including network bandwidth, latency, and processing time, the engine is spread into client and server partitions. The server hosts the modules that improve the responsiveness of the game, and the client hosts the remaining modules, typically those interacting with the device components or with the gamer (like UI). The two sides exchange data during the execution. Whenever needed, the server can call a module, or download it using mechanisms such as RPC, RMI, SOA, and MA. The partitioning requires profiling the whole game.

The computation offloading solution presents two constraints. First, as in Cloud gaming, computation offloading requires low latency. Second, the game engines should tolerate module partitioning. One of the advantages is that module partitioning allows a better exploitation of resources, especially by distinguishing the cutting-edge modules that require specific GPU hardware from the standard ones that can accommodate any CPU configuration. Remote graphic rendering is not a new topic [START_REF] Humphreys | Chromium: a streamprocessing framework for interactive rendering on clusters[END_REF], but none of the existing solutions match the expectations for fast rendering high-definition, complex, 3D images. Moreover, to the best of our knowledge, no previous work has addressed the case of offloading non-graphic components of a game engine, like physics module, audio, and object behaviour scripts.

One of our motivations is to explore offloading different non-graphic components of a game engine.

Game Engine Main Modules

A game engine consists of various modules depending on the game genre. An engine designed for a twoperson fighting game is different from an FPS engine, an MMOG engine, a Real-Time Strategy (RTS) engine, or racing engine. Nevertheless, we identify some families of module that are common to most of the game engines. Artificial Intelligence (AI)these modules emulate an artificial and intelligent behaviour of NPCs, for example, learn and interact socially, exhibit emotions, and even the ability to hunt and the instinct to survive. Different features are used to implement the AI such as: (i) decision-making, to affect the NPC; (ii) basic perception; the AI needs some way of perceiving its environment using humanlike sensors (including sight, hear, smell, and touch), and navigating using basic mechanisms like Scriptingthese modules contain the gameplay itself. From the captured inputs obtained from the Human Interface Devices (HIDs), the game developer details the series of game content and events in a scripting language, which is specific to every framework. The scripts can be used to create graphical effects, control the physical behaviour of objects or implement an AI system for NPCs.

Animationany character in a game (whether it is a human, an animal, or a robot) needs animations (e.g. move, jump, stand up, and set down). Five basic animations exist; (i) rigid body hierarchy animation, (ii) skeletal animation, (iii) sprite/texture animation, (iv) vertex animation, and (v) morph targets. In particular, skeletal animation generates a pose for every bone in the skeleton and passes them to the rendering engine as a set of matrices that are transformed into a final blended vertex position. This process is called skinning. It also interacts with the physics engine to simulate rag dolls, which are dead animation characters, whose bodily motion is simulated by the physics. Some module families are common between most games created within a given framework. These modules represent the abstraction layer and prevent game creators from spending time on low-level issues. In particular:

Physics Engineit includes collision detection and rigid body dynamics. This module aims to make the game world as realistic as possible using the physics laws. Without this module, objects would interpenetrate, leading to block interactions with the virtual world. This module is integrated as a third-party SDK. Existing physics engines in the market include Havok4 , PhysX5 , Open Dynamics Engine (ODE) 6 , and I-Collide7 .

Inputa player interacts with the game using HIDs, e.g., joystick, keyboard, mouse, steering wheels, dance pads, and VR sensors. The input module provides a mechanism to customize the mapping between the physical control and logical game functions. It may include a system for detecting chords, sequences, and gestures. These commands are encapsulated as objects and forwarded to the system.

Networkingthis set of routines and protocols enables interactions with a server to set up multiple players and share a sense of space, time, and presence through avatars. In MMOGs, the players join the game dynamically through game sessions and interact by exchanging commands [START_REF] Nae | Dynamic resource provisioning in massively multiplayer online games[END_REF].

The architecture of most of the MMOGs is based on client/server.

Multimedia Renderingthese modules generate the graphical and audio elements of the game.

Graphics are complex aspects of a game. 3D games are built over 3D assets created by a design application like Maya, XNA, Blender, and WPF. These assets are mixed with other objects like materials, shadows, lights, and animations to create a realistic scene. This engine is designed as a layered architecture, including: (i) Low-Level Renderer, where the focus is on rendering as quickly and richly as possible a set of geometric primitives; (ii) Visual Effects, like particle systems, light mapping, dynamic shadows, and colour correction; (iii) Front End where 2D graphics overlaid on 3D scene such as in-game menu, a console, and in-game Graphical User Interface (GUI).

Regarding sounds, the audio engines vary in sophistication. The audio clips are exported in different formats like mono, stereo, wave files (.wav) or ADPCM files (.vag). Existing commercial audio engines include Quake audio engine, XACT, SoundR!OT, and Scream.

Rendering Pipelines

We describe now the rendering pipeline under Unity 3D. We first describe the pipeline that achieves a 3D rendering, and then, we show how Unity 3D implements it.

A rendering pipeline is a combination of successive stages to generate a 2D image for a geometric description of a 3D scene and a virtual camera. Unity 3D is cross-platform: a given game can run on various operating systems and hardware. For each configuration, the engine uses the default rendering pipeline developed for these targets. Firstly, a series of geometric operations are done to render a collection of geometric primitives as fast as possible. The data (vertices and indices) of 3D objects are approximated by triangle meshes, forming the basic building blocks. The more triangles are used to approximate an object, the better is the approximation but the more processing power is needed. Each object is then centered at the origin of a local coordinate system with local orientation and size. Thereafter, all objects are brought together in a global coordinate system by applying geometric transformations. At the end, the virtual camera in the scene is translated to the origin of the world space.

Secondly, a set of aesthetic effects (lights, materials, shaders, and textures) is applied to the scene.

The lighting is a key step to produce a realistic scene. The light sources are simple objects defined in the world space with a combination of colour, intensity, direction, focus, and position. This step also includes a repetition of absorbing and reflecting light processes depending on various parameters (e.g., smoothness and material of the surface and incidence angle).

Thirdly, a set of culling operations (scene graph/culling optimization) is done. Each object has two sides with respect to camera position: a front and a back side. The front (respect. back) sides are polygons with vertexes ordered in a clockwise (respect. counter clockwise). All the back-face polygons are culled. The culling step is triggered to also decide which object should be discarded from the scene, according to the computation of the view frustum. An object inside (respect. outside) the frustum is kept in (respect. completely culled from) the scene, while the object that is between the inside and outside of the frustum is partially clipped.

Finally, a perspective projection is done to render the 3D vertices into a 2D projection window inside the frustum. The vertex coordinates are transformed to place the 2D scene into a rectangular window on the screen, called the viewport. The outputs of this stage are pixels. The rasterization transforms these pixels into screen coordinates forming a list of triangles that should be checked and coloured.

Unity 3D uses four additional rendering activities, which occur in conjunction with the main pipeline.

We summarize these activities in the appendix Section A.2.1.

Methodology and Testbed

We describe now the configuration of the devices that we used in our experiment, the process of running games on these devices, a description of the used games, and our measurement.

Platforms

To evaluate the performance of the game engines generated by the framework Unity 3D, we installed Unity 3D v5.03 on top of three devices: a Dell Precision M4800 laptop, a Microsoft Surface Pro tablet, and a Dell PC tower. The latter is used as a server in our second experiment (implementation of Cloud gaming and computation offloading architectures). We used different configurations as shown in Table 4.1. We then used the installed frameworks to compile the games and generate the adequate files for a range of OSs: an ".exe" file in Windows 7/8/10, an ".deb" in Linux, an HTML page with javascript files for web players, and an ".apk" for Android devices. Accordingly, we were able to run the games generated by Unity 3D on a wider range of configurations: not only the said Dell M4800 and Surface

Pro, but also a smartphone HTC One (M8) and a Samsung galaxy S6 Edge. Moreover, we were able to implement Cloud gaming and computation offloading architectures.

Games

We selected nine games from the "Asset Store" of Unity 3D for our evaluation. These games have different characteristics, which cover the most representative games in the market. A description of the different games is presented in the appendix. We summarize the main characteristics of each game in Table 4.2. For more details about these games, the reader may refer to the Unity 3D asset store.

Game qualities

For each game, we generated more than 10,000 frames for two quality types: good quality with a reasonable framerate, i.e., around 30 fps, and fast quality, where the game pace is maximum. The engine achieves these two qualities depending on many parameters, which are outlined in Table 4.3.

Measurement

We describe now how we obtain the internal flow and the execution time per frame and per module for the different games over the different platforms and targets, including Cloud gaming and computation offloading architectures. Execution Time. The CPU/GPU execution time per frame, for the aforementioned modules, is obtained for 10,000 frames for each quality encoding. We used the Unity Profiler and script to obtain these values.

Internal Flow. We used two tools with a script to identify the Unity 3D internal flow. We dumped the memory using the script that identifies all the classes/objects and methods that are called per frame.

We used Visual Studio 2015 profiler 17 and Dependency Walker 18 to check the validity of the obtained results.

Performance Analysis and Game Classification

Now, we present the results of our measurement campaign regarding the time needed to generate one game frame. We then propose a classification of the games with respect to the best approach to adopt for efficient implementation (i.e., whether the game engine should run on the device, in a Cloud gaming system, or with computation offloading). In Section 4.5, we will study more precisely the case of computation offloading by a thorough analysis at the modular scale. factors: the quality settings, the platform that runs the game engine, and the type of the game.

Time Needed to Generate One frame

Impact of the quality settings. It is epitomized by the Stealth game, for which the time needed to generate a good quality frame is excessive on both Dell M4800 and Surface Pro (up to 100 and 200 ms, respectively), while it stays in more acceptable ranges for fast quality (up to 32 and 90 ms resp.). We observe the same impact on the other games: for instance, the time consumption per frame is reduced by a factor ranging from two to three for the Survival Shooter game. To understand the reasons behind this impact, readers are referred to Section 4.2.3 and Annex part A.2.1. A pixel resolution of 640 × 480 has typically shorter processing time than a 1920 × 1200 resolution, in particular because the additional pixels in the viewport requires more processing at the rasterization step. Another impacting parameter in high quality settings is the pixel light count, where the process of drawing geometry with lighting is repeated during the light pass step for all the pixel lights. Both texture quality and shadow also increase the processing time.

Impact of the used platform. The hardware configuration and the used OS matter. Regarding the hardware, it is obvious that: (i) using a GPU enables faster frame rendering; (ii) large memory prevents page fault exception and paging process; (iii) multi-core CPU better exploits the parallel executions.

Considering the OS, each one has a different architecture with different interruptions, scheduling policies, and algorithms for page replacement in cache, central memory management, and swap. In addition, the device drivers and the used compiler may impact game performance.

For all games, the time needed to generate one frame is smaller on the Dell than on tablet, which in turn is faster than smartphones. Regarding OS, we observe a difference in the frame duration, such as Viking Village game at fast quality is three to four time faster in Linux than in Windows. For other games (e.g., Tower Bridge), the frame duration has different variations depending on the executions in Linux and Windows. We also notice that the frame generation time on the web players is (to our surprise) in the same range as when the frame is directly generated on Windows and Linux. We explain this by the screen resolution, which is automatically reduced to almost a half of the screen window. Some parameters of the quality setting are independent of the screen size, but multiple parameters directly Impact of the game genre. Some games are more demanding than others with respect to scene complexity, AI, and scripting. The various game genres impact the frame duration. For the same platform and the same quality settings, two different games exhibit different profiles of resource consumption and variability of resources. In particular, we observe that the variability of the frame generation times differs among the games: for some games, all the frames take approximately the same time to be generated, while the generation of a frame can be eight times longer than another frame for some other games. Each game has a behavior signature.

Game Classification

Game providers are interested in determining the best option to host the game engine. From our previous results and analysis, we identify two criteria to characterize games: the variability of resource demand, and the relation between resource demand and quality settings, which we call playability. We set thresholds for both criteria and we define predicates, which can be either verified or not by each game. Finally, we classify games based on the set of validations. In the following, we first detail the predicates (criteria and thresholds), and then we explain the classification process.

Playability. It is a mix of framerate and quality settings. To evaluate a framerate for a game, we take the 90 th percentile of the longest frame duration.This percentile is a basis for the setting of the achieved framerate of the game. The higher is the framerate, the better is the QoE. The latter also depends on the quality setting. The higher is the quality setting, the better is the immersion, so the higher is the QoE.

We combine both by setting that a given game is playable if the framerate is greater than 30 fps (60 fps, respectively) for good quality (fast quality, respectively) settings. That is, the 90 th percentile should be lower than 33 ms (16 ms, respectively) to validate the playability of a given game. This criteria depends on the platform on which the game engine runs. For example, Tower Bridge at good quality on the Dell M4800 is playable on Linux but not on Windows. When a game cannot verify the playability criteria on a device, the game engine cannot run on the device in the traditional client-server mode. Other options must be considered, either Cloud gaming platform or computation offloading.

Resource Variability. It describes the variability in frame generation time. We consider two values to differentiate high and low variabilities: the range and the Inter-Quartile Range (IQR). The range is the difference between the highest and the lowest score, while IQR corresponds to the range of half of the scores around the median (the difference between the 75 th and the 25 th percentiles). We say that the variability is low when the range (IQR, respectively) is less than 20 ms (10 ms, respectively). For example, Survival Shooter, Tanks, and Tower Bridge games exhibit a low resource variability.

The resource variability matters because it impacts the efficiency of the implementation on a virtualized hardware. A high resource variability means that the game provider must reserve a vast amount of resources to absorb the peak, at the expense that the game engine only uses a fraction of these resources during most of the execution time. High resource variability, thus, means an inefficient resource reservation and a lower benefits for the game providers. On the contrary, a game characterized by a low resource variability is easy to pack into a well-sized VM (or container), which enables a better consolidation and low infrastructure cost.

Based on both predicates, we classify the games as follows:

• Client-server, where all functions of the game engine (except session and multi-player management) run on the device. A game falls into this category if and only if it verifies the playability criteria.

• Cloud gaming, which means that the game as a whole runs in a VM in a data-center, while the client only runs a video decoder. A game falls into this category if both it is not playable on the device and it exhibits a low resource variability.

• Computation offloading, which means that the game engine is distributed among a client and a server, both of them being linked with a high-bandwidth low-latency network connection. A game falls into this category if the playability criteria is not verified and the game exhibits a high resource variability.

Table 4.4 summarizes the classification of the games based on the aforementioned devices (more details in the appendix). We observe that, for these representative games and devices, Cloud gaming is rarely the best option (only for two games on the mobile devices, and one game on Dell, and browsers).

On the contrary, solutions based on computation offloading are the best option for four games in all devices except the fourth game on the Dell and browsers. This result calls for a deeper exploration of computation offloading solution, which has not been studied for gaming so far.

Is Computation Offloading Possible in Game Engines?

We address now a second part of our measurement analysis with a focus on modular aspects of game engines. Our main motivation is the study of solutions based on computation offloading. In this approach,

IS COMPUTATION OFFLOADING POSSIBLE IN GAME ENGINES?

the resource requirements of each module and the interactions between the modules are two needed key information for an efficient implementation. A secondary motivation is the study of solutions based on Cloud gaming. In existing platforms [START_REF] Huang | Gaminganywhere: The first open source cloud gaming system[END_REF][START_REF] Luo | Uniquitous: Implementation and evaluation of a cloud-based game system in unity[END_REF], the game engine is seen as a "black box". One of the improvements we would like to study in the future is to distribute a game engine into several physical machines in a data-center to enable parallel computation. Similarly, one needs to understand the resource requirements at the module scale as well as the interactions between the modules.

CPU Consumption per Module

To understand the time consumption of each module per frame, we look at the CPU usage percentage at the modular level. We gather modules into seven families: Rendering, Scripts, Physics, Garbage Collector (GC), Global Illumination (GI), Vsync, and Others. We abusively use the term "modules" hereafter to refer to a family of modules. For every game, the frame duration is limited by one of three threads: the CPU game thread, the CPU render thread, or the GPU thread. In Figure 4.7a, we identify the rendering engine as the most consuming module. It is responsible of up to 70% of CPU usage in average. Since the rendering is done by the GPU, it means that the game performance is limited by the GPU thread. Indeed, once the CPU launches the rendering process in the GPU, it can run in parallel some other modules, including AI, physics and scripting. As soon as the process of these modules terminates, the CPU waits for the GPU process termination. For some highly-graphical games such as Viking Village, the rendering modules are responsible for 95% of the CPU consumption on the Dell Win7 platform at high-quality. We are also interested in understanding the differences in the module consumption per platform and game quality. For a given platform and a given user quality setting, we compute the average time consumption for all frames and all games to obtain a global average platform-dependent qualitydependent module requirement. We thus get eight measures of the average module requirement (four platforms and two game qualities), noted r pq for each platform p and each quality q. We compute the average requirement, noted R for the eight measures. Then, we compute, for one given platform-quality pq, the difference to the average measure, r pq -R. A platform-quality pq with a high difference means that, for this given module, the requirement significantly differs from the other platform-quality, and thus it would justify the game provider to pay a specific attention. Our idea is also to check if some modules exhibit much wider different behaviors than others. To enable comparison across modules, we thus compute a relative measure of the difference by computing the ratio of this difference r pq -R to the standard deviation µ. We call this measure the relative load variability. The higher is the relative load variability of a platform-quality pq, the more different is the platform-quality pq from the other platforms.

We represent, for each module, the eight relative load variability measures in Figure 4.7b. We have two observations. First, the resource requirement is sensitive to platform-quality. Some platformquality pq have a difference to the average that is nearly 1.5 larger than the standard deviation. It calls for paying attention to platform-quality when implementing a computation offloading because these platform-quality exhibit specific and unusual resource consumption. Second, all modules have similar relative load variability. This is counter-intuitive since we expected that rendering modules would be more sensitive to platform-quality than other modules.

In Figure 4.8, we represent the consumption per module for the web players. The CPU spends a lot of time computing other type of modules, like scheduling the tasks over the different layers. The rendering portion of time is lower than for the case of standalone platforms, which is due to the default resolution used in the web players. The script and physics take more portion of CPU than in the standalone cases.

GPU Consumption per Module

We concluded from Figure 4.7 that the rendering modules are the most consuming modules regarding CPU use. One of our previous explanations is that CPU is bounded by the performance of GPU to render the scene. In the following, we look at the GPU consumption to validate this statement. We plot in Figure 4.9a the time spent by the GPU to generate one frame for each of the games on the Dell laptop. In We derive from Figure 4.9a that the time taken by the GPU is approximately the same as the CPU in Figures 4.7a. It confirms our intuition that, since the CPU finishes processing tasks faster than the GPU, the CPU waits for the GPU to finish the frame generation. As we will see later, the "waiting mode" is considered as a module to schedule and synchronize the two processors. Moreover, in Figure 4.9b, the consumption per rendering activity is different for each game. Indeed, the nine game worlds are different. We also observe that the GPU is not entirely used for rendering processing. Typically a game like Tower Bridge consumes the entirety of available GPU for other types of module.

Calls between Modules

We pay now attention to the modular architecture and the interactions between these modules. This study is key for the implementation of computation offloading, and it is also useful for new implementations of Cloud gaming systems.

We depict in Figures 4.10 Each module family can be offloaded as a separate service. Indeed, we observe in the figures that these families exhibit few interactions and data sharing each other, which is expected since these • The Scripting family (see Figure 4.11d) is the only module that interacts directly with the Physics engine. It would thus make sense to run this family of modules on the same computer as the one that hosts the Physics modules.

• The Audio family (see Figure 4.11a) has no interaction with the other main modules and only deals with the game thread. This module can thus be offloaded as an API to a remote machine.

The communication between the client and the remote machine can be done either by RPC or by streaming the audio data.

• The AI family can be computationally intensive. It is difficult to simulate the game on constrainedresource devices without reducing the complexity of the AI. Since this family is also mostly independent, the module family can be offloaded.

Finally, we address in Figure 4.12 the Rendering modules. We revealed in our previous results that this family is the most resource consuming, and thus is a candidate to migrate from the lightweight client devices to nearby servers in a computation offloading solutions (or from one standard server running the game engine to a specialized GPU-enabled server in the same cluster of servers for the case of a Cloud gaming solution).

The offloading mechanism can be instruction-based or image-based. In instruction-based systems, the client renders the graphics by itself using the commands received from the server. This system consumes less bandwidth as only graphics drawing commands transit over the network. Image-based system streams the rendered game as a real-time video. The clients are platform-and implementationindependent, and demand fewer resources. However, it is harder to distribute this module. Indeed, we identify some "sub-families" within the Rendering family that are rarely independent. We observe in Figure 4.12 that the calls come from multiple other modules, which are not necessarily in their own sub-family. These inter-calls between modules, from different sub-families, make the code offloading harder. Indeed, the calls frequency is high, which implies intensive communication between the different computers and ultra-low-delay data mirroring in the case of offloading. Moreover, some sub-families are more called than the others. For example, SharedSet-Pass, RenderTexture, and MeshVBOModule are called to generate the frames. Finally, the WaitingForJobs module is used to synchronize the modules that have different running time. The time spent into the WaitingForJob module is a waste of time and CPU consumption. In Section 4.4, we tested the different games in the traditional client-server architecture, from which we derived a game classification for the different platforms. In Section 4.5, we studied the possibility to offload a game engine and concluded with promising solution regarding offloading the game engine modules. Now, we present the performance of the games when we offload a part and the whole game engine to a server as in the two architectures (Cloud gaming and computation offloading). We present the needed CPU-time to generate one game frame on the client device in both architectures.

For a fair comparison between the games, we offload the same game objects namely NPC, Player Character (PC), environment, and lights. Table 4.5 summarizes the game module distribution. Table A .4 presents the used devices for each architecture.

� ✗ � ✗ � ✗ � ✗ � ✗ � � � � � � � � � � � � � ✗ Non-Player character Rendering Audio Animations AI Physics � ✗ � ✗ � ✗ � ✗ � ✗ � � � � � � � � � � Particle Effects Rendering Animation Physics � � � � � � � ✗ � ✗ � ✗ Arena Rendering Physics � ✗ � ✗ � � � � Sound Audio Scripting � � � � � ✗ � ✗ Sun Light Rendering � � � ✗ Arena Light Rendering � ✗ � � Main Camera Rendering � � � ✗ Weapon Camera Rendering � ✗ � � Game Manager Scripting � � � ✗
fast qualities (Figure 4.13b). We use box-plots to present the results since we focus on the variability of CPU consumption per frame. Indeed, the consolidation of resources in a data-center is easier when the consumption of processing resources is accurately predicted. The more stable are the CPU and GPU consumption, the more games can concurrently run in a cluster.

We distinguish three categories of game. Some games are ideal for client-server architecture and/or consolidation because all frames take approximately the same CPU and GPU time to be generated. The

Discussion and Main Findings

To sum up our findings in this chapter: Firstly, the GPU is the main source of performance limitation in the different cases. The CPU game and CPU render threads are frequently blocked waiting for the results of the GPU due to a synchronization problem. To improve GPU performance, an idea would be to free the latter from some jobs. For instance, recent GPU cards improves the game performance by offloading the PhysX from GPU to CPU, especially for powerful CPU. Unfortunately, this solution works only for games using PhysX as physics engines (like Batman [START_REF] Brooker | Hunting the Dark Knight: Twenty-First Century Batman[END_REF], Assassin's Creed [START_REF] Nasr | Assassin's creed: A multi-cultural read[END_REF], and some others 19 ) but it does not work for other engines like Havok, ODE, or I-Collide. We also identified that both CPU and GPU consumptions have a high correlation, which is useful for the Cloud gaming providers to estimate from the CPU demand the amount of GPU resources that need to be reserved, as well as the game variability.

Second, the frame rate of device-friendly games is generally higher than 60 fps. This is a waste of resources, especially in terms of energy. Here, we envision a solution where we first calculate the number of generated and saved frames in the frame buffer, by monitoring the synchronization, then the GPU breaks the game main loop when the number of 60 fps is reached. The idle GPU saves a signfiicant part of the energy consumption. The provider can use the idle GPU to serve more games using a preemptive scheduling. NVIDIA proposed the mechanism G-Synch, which improves the V-Sync mechanism, where the monitor refresh is conducted by the GPU frequency. It finds trade-off between the off-and on-mode of V-Sync. Indeed, when V-Sync is deactivated, the GPU sends the frames following its own pace. At each screen refresh cycle, multiple frames are displayed because the frame rate is maximal causing the phenomenon of tearing. Now, when the V-Sync is activated, the GPU follows the screen tempon so tearing no longer occurs. But, when the time to render a frame is longer than a refresh cycle, the phenomenon of stutter and display delay (lag) occurs because the monitor has to display again the last frame.

Third, some modules related to rendering are mostly in waiting mode, meaning that the CPU consumption associated with these modules is not significant. These waiting times are not necessarily a waste of resources when only one game runs on a computer, since the rendering pipeline is at a given step and no further actions can be taken. However, in the context of Cloud computing, these waiting times represent opportunities to free some resources and to better exploit the processing units.

Fourth, a non-graphic component of the game engine can represent a significant part of the CPU consumption, typically in games where the AI, the physics, and the scripts are complex. A motivation behind code offloading is to study the gains when the display device embeds dedicated GPU resources, and powerful servers are available nearby. This configuration matches the new generation of game centers with VR headsets.

Finally, the game classification of the games into the three architectures matches our predictions based on the criteria: playability, and resource variability.

Conclusion

This chapter has dealt with the topic of game engines. We presented a general architecture and conducted a set of experiments on three architectures: client-server, Cloud gaming, and computation offloading.

We used nine representative games, including FPS, TPS, Racing, and MMOG. We adapted these games to different platforms and tested their performance on each platform for two encoding qualities.

Based on our results, we classified the games into the three architectures depending on two parameters: playability and resource variability. We also identified that the quality settings, the used platforms, and the game genre exhibit varying behaviors. Next, we provided a detailed view of the game engine by representing the internal flow that constitutes each module, which is a basis for solutions exploring computation offloading. Finally, we validated our finding regarding the game classification according to the aforementioned criteria and the feasibility of game engine offloading. In our experiments, we used static offloading of the sub-families of modules. Our work opens new exciting perspectives and research directions to improve gaming experience. Indeed, we may mention particularly two directions to follows, one based on computation offloading and another one on Cloud gaming consolidation.

Regarding computation offloading, it is interesting to explore not only partitioning algorithms to find the best execution location of each module sub-family, but also use systems for polygon rendering to decompose an object, or an entire image to offload some part aiming at improving the rendering process between the client and the server. About game consolidation, it will be useful to define a regression model for the resource consumption to maximize the consolidation and minimize the risks, and find somehow to serve different gamers in Single Online Shared Game Instance (SOSGI) (i.e., throw only one instance of game engine).

TOWARD A MOBILE GAMING BASED-COMPUTATION OFFLOADING

Introduction

In light of conclusions made through chapter 4; video games are complex, intensive, and real-time applications that need powerful devices to run smoothly, in order to provide a gamer an illusion of inside an animated world; the rendering engine should perform all the rendering activities in real-time. For a gamer, a good QoE is obtained when the game engine displays frames at a higher rate, more than 30 fps [START_REF] Claypool | Perspectives, frame rates and resolutions: it's all in the game[END_REF]. Thus, the rendering engine has at most 33 ms to generate one frame. Usually, much less time is available, since the bandwidth is also consumed by the other engines such physics and scripting.

Inside the umbrella of conclusions, we also demonstrated that computation offloading is feasible for game engines. Indeed, we extracted the different call flows inside the game engine and checked the possibility of splitting modules. We observed that module families are mostly, independents. Therefore, it is possible to offload these modules entirely or partially with respect to the network latency. The classification of games into three architectures namely, client-server, Cloud gaming, and computation offloading revealed that computation offloading architecture should be the best option in most cases.

This observation was existing and a good motivation to go farther and provide a static solution for computation offloading of game engines.

Through this chapter, we unveil an enhancement of our game engine offloading proposal by making dynamic, the offloading decision. We propose a heuristic, which according to the network latency, resource consumption, and code dependency, selects clusters of modules that should be offloaded to improve the performance. We survey state-of-the-art computation offloading-oriented mobile gaming.

Then, we introduce some concepts and keywords that we use through the chapter. After what, we describe our methodology and contribution. We use a testbed composed of a smartphone and a server to evaluate and compare the performance of our solution with the classical one.

Related Work

Computation offloading is gaining ground with the emergence of MEC, which locates servers at the network edge allowing to drastically reduce the end-to-end latency. Several works have addressed the problem of computation offloading in the context of mobile Cloud. We cite hereafter some of these works (reported in the previous chapters) oriented for games with some technical implementation details. In MAUI [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF], the authors presented a dynamic offloading framework operating at the method (i.e. application component) granularity. The games are represented with graphs and translated into a linear programming formulations, with the objective to save energy, subject to the total execution time.

MAUI requires annotating methods as "remote" or "local". The communication between the mobile device and the Cloud is done through RPC. The design of MAUI supports only games written in C#.

Similarly, ThinkAir [START_REF] Thinkair | Dynamic resource allocation and parallel execution in the cloud for mobile code offloading[END_REF] introduced a mobile Cloud computing framework, with dynamic offloading.

The proposed framework clones the smartphone platform in VM. It offers a library and a compiler to ease the adaptation of games. A code generator creates wrappers and utility functions. A customized Native Development Kit (NDK) is used to convert the ARM-based instructions of remote methods into x86 instructions. ThinkAir uses Java reflection to offload methods based on past invocations. ThinkAir defines four objective functions that combine execution time, energy, and money cost. In [START_REF] Zhang | Refactoring android java code for on-demand computation offloading[END_REF][START_REF] Zhang | Towards module-based automatic partitioning of java applications[END_REF],

the authors propose DPartner framework, an automatic partitioning system that rewrites Java bytecode of monolithic application into a distributed application. The framework operates in three steps; first, it classifies Java bytecode classes into anchored or movable based on Java lexicon. Then, the framework clusters classes regarding the call frequency into different groups representing the game modules. Finally, the framework rewrites the clusters bytecode and packages them into OSGi bundles. These bundles are classified into anchored or movable modules according to classes. The framework defines a proxy, which rewrites the classes to create new interfaces, and duplicates classes on both sides (client and server). The framework offloads all the bundles that improve the performance and reduce the energy consumption.

Another framework proposing to offload GPU computation to remote servers has been introduced in Kahawai [START_REF] Cuervo | Kahawai: High-quality mobile gaming using GPU offload[END_REF]. It uses a collaborative rendering, which combines both server GPU and mobile device GPU outputs to render frames. Kahawai uses two techniques for collaborative rendering; the delta encoding and client-side I-frame rendering. In delta encoding, the mobile device renders frames with low quality encoding, while in the server, the same frames are rendered with high quality. The per-frame difference is streamed to the mobile device to transform frames into high quality frames. In client-side I-frame, both the mobile device and server are rendering frames at high quality encoding, however, the mobile device generates the frames at a low rate compared with the server. The server compresses the frames into a video, replaces the I-frames with empty place-holders, and streams the remaining P-frames to the mobile device, which fills in the missing I-frames and renders the video. Di et al. [START_REF] Huang | Dust: Real-time code offloading system for wearable computing[END_REF] have proposed Dust, a real-time code offloading system for device-to-device. Dust uses a network evaluator component to find the stable linked offloadees, and a task scheduler component, which takes a decision regarding each task of a game. The tasks are annotated by programmers as "@offloadable".

GAME ENGINES BACKGROUND

Even these frameworks provide in general good performance, these framework are obsolete for the use case of 3D FPS games, which are very high resource consuming and real-time interacting.

Indeed, in all these frameworks, the authors have considered only strategic 2D games like Sudoku, Chess, N-Queens, and Gomuko, which renders one frame for each player movement. To this purpose, we propose an offloading 3D FPS game system using Unity 3D game engine. We split the game scene into different Game Objects (GOs) including, NPC, PC, environment, and particles. To select the GOs to offload, we use a heuristic relaying on three main criteria, namely, resource consumption, code dependency, and network latency as detailed later. Furthermore, we introduce a network manager component, which orchestrates the offloading mechanism. This solution offers a promising performance.

It is easy to configure, as the GOs to offload are added to the server through a network manager, and scalable as all games could be modified easily to fill in this architecture. Lastly, the proposed solution is not bandwidth consuming, as only command packets are exchanged over the network.

Game Engines Background

To better understand our contribution in this chapter, we introduce/remind in the following some concepts and keywords that we will use through the chapter.

Interactivity and Framerate

The interaction delay, defined as the elapsed time between a user action is captured by a HID, and the moment that the result of this action appears on the screen, is central in gaming. Studies [START_REF] Claypool | Latency and player actions in online games[END_REF][START_REF] Lee | Are all games equally cloud-gaming-friendly? an electromyographic approach[END_REF][START_REF] Quax | An evaluation of the impact of game genre on user experience in cloud gaming[END_REF] have shown that the acceptable delay depends on the game genre and varies from 100 to 200 ms and even up to 500 ms for RPGs and MMOGs. FPS games require low delays (less than 100 ms), since the gamer is immersed in the scene, and a high interaction delay will degrade the QoE [START_REF] Schlosser | An evaluation of qoe in cloud gaming based on subjective tests[END_REF]. Regarding this constraint, the management of FPS games has received scientific efforts [START_REF] Armitage | REED: optimizing first person shooter game server discovery using network coordinates[END_REF][START_REF] Li | Play request dispatching for efficient virtual machine usage in cloud gaming[END_REF]; therefore the interaction delay will be considered as a metric in this chapter.

The framerate is another key criteria to ensure high QoE for the gamers. Indeed, the latter are immersed in an animated world when the game engine generates a high number of fps. Less than 30 f ps is seen as non-tolerable by players [START_REF] Claypool | Perspectives, frame rates and resolutions: it's all in the game[END_REF]. For the interactive multimedia, the High Frame Rate (HFR) combined with the High Dynamic Range (HDR) technology can deliver up to 240 f ps [START_REF] Lantin | High frame rate (hfr)[END_REF]. The rendering pipeline [START_REF] Pfister | Surfels: Surface elements as rendering primitives[END_REF] represents the engine responsible for generating frames; every x ms the graphic pipeline displays one frame, with x ranging from 33 to 10 ms. The framerate will be also considered as a metric in this chapter.

Main Modules

A game engine is a combination of different modules depending on the game genre. Messaoudi et al. [START_REF] Messaoudi | Dissecting games engines: The case of unity3d[END_REF] have identified some modules that are common to most game engines, and classified them into different families. Some of these module families are written by game developers that include: (i) the AI, which emulates an artificial and intelligent behaviour of the NPC to learn, to interact, to fight, and to survive; (ii) the scripts represent the game scenario. Game developers detail, in a scripting language, the control flow of the game, from the instant wherein the gamer command is captured by HID until displaying a frame on the screen. (iii) Animations are used to make objects, dynamic in the game. They emulate movement or reshape objects.

Some other families of modules are leveraged as a third-party SDK and middleware accessible through APIs. These families of module represent an abstraction layer common to all games created within a given framework, aiming at preventing the game developers from spending time in low-level programming. These modules include the following: (i) physics, which simulates the physics laws to make the game as realistic as possible. Physics uses collisions and rigid body dynamics 1 . Without physics module, objects would interpenetrate, leading to block interactions with the virtual world. (ii)

Multimedia rendering modules are responsible for generating the graphical and audio elements of the game. Rendering is a resource-consuming module in game engines, since the 3D-scene undergoes several transformations through the rendering pipeline before getting displayed on the screen [190]. (iii)

Inputs convert the physical commands applied by the gamer on his HID (including gamepad, joystick or keyboard) into logical game functions, and forward them to the engine system. Finally, (iv) networking modules define a set of routines and protocols that enable interactions with a remote server to share a game instance between multiple players.

Scene Representation

A real-world scene is a projection of dynamic foreground (the dynamic GOs) on a layout of a static background or static GOs. The static background layout is crucial in video games, as it brings the player inside an immersive world. The game's world populates different types of GOs, through which the gamer explores the virtual world. The game world as a whole presents perceptual stimuli to the player, which experiences a degree of presence over the objects of this world that he can manipulate. These objects include: (i) a PC, which is a fictional character, controlled by the gamer. Generally, these characters GO that displays what it currently seen on the screen. The camera can move and rotate around, hence the displayed view moves and rotates accordingly. The area seen by the camera defines a truncated pyramid known as a frustum.

Methodology

We describe now the game, platform, and encoding qualities that have been used in our experiment, as well as the methodology undertaken to offload modules to a remote server.

Game

We modified the multiplayer FPS game2 to make player characters fighting together against a NPC inside an arena. The player character is a robot with blasters flying inside the arena. The NPC is a humanoid avatar triggered by the player characters when they are near to its position. The game scene is depicted in Figure 5.1. We summarize the main characteristics of this game in Table 5.1.

platform

To evaluate the performance of the proposed solution, we installed Unity 3D engine v5.4 on top of a Dell PC tower. The installed engine is used to compile the tested game and generate two different instances;

the first one runs on the server (Dell PC tower), while the second one runs on the smartphone HTC One M8. The configuration of these devices is given in Table 5.2.

Quality Encoding

We generated 10,000 frames for two encoding qualities; a good and fast quality. The good quality is encoded with high parameter settings, which generate a reasonable framerate, i.e., around 30 f ps. The fast quality, configured with reduced requirements, produces inferior visualization results, hence obtain a maximum framerate. Unity 3D achieves these two qualities through different parameters as described in [190].

In light of what is stated in the background section, the following paragraph tackles the questions:

how we can improve the performance of a game through modules offloading? or what is the optimal location (on the mobile device or on the server) of each module of the game engine? To answer efficiently this question, we introduced the following criteria:

1. Resource consumption. Usually, the gameplay is concentrated within dynamic objects, which are high resource consuming. Rendering these GOs is complex in video games [190]. Each object in the scene is approximated by triangle meshes. The more triangles are used to approximate an object, the better is the approximation, but more is the processing.

2. Code Dependency. Games depend on hardware (e.g., sensors) and software known as libraries and SDKs, but also interact with players via UIs, which manage the HIDs. According to this, we distinguish three classes of non-transferable modules; modules involving UIs [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF]; modules interacting device sensors [START_REF] Othman | Power conservation strategy for mobile computers using load sharing[END_REF]; and modules depending on local APIs [START_REF] Gu | Adaptive offloading for pervasive computing[END_REF][START_REF] Ou | An efficient runtime offloading approach for pervasive services[END_REF].

3. Bandwidth consumption and Network latency. Some GOs, if they are offloaded to the server, need high network communications with the mobile device, which increases the bandwidth consumption and the interaction delay. Particles are an example, they are 2D images generated and animated in large number. Several modules are interacting together to make their behaviour, which leads to high communication between modules of the game engine. When the connection is established, a game manager script is executed on the mobile device. It starts the execution of the local GOs, while it requests the network manager to start computation on the server. Therefore, remote GOs are rendered on the server at default coordinates. Start playing the game, input modules capture the gamer inputs and send commands to the server. On the server side, both the GOs and the outputs of the involved modules (modules used by each GO to compute its behaviour) are updated with the gamer commands. Thus the network manager captures these results and injects them on modules, located in the mobile device, interacting with the remote GOs. At the end, a frame composed of the local and the remote GOs is rendered on the mobile device. This process is repeated for each frame until a disconnection of the gamer. In this case, the GOs are destroyed on both client and server.

Proposed Framework

The network manager uses both RPC and GigE Vision Stream Protocol (GVSP) [START_REF] He | A high speed robot vision system with gige vision extension[END_REF] carried over User Datagram Protocol (UDP) for communication between the mobile device and the remote server, with a multi-channel design supporting a variety of levels of QoS, and a flexible network topology supporting peer-to-peer and client-server architectures. RPCs are used to update some module entries and variables such as (N)PC health level or weapon state. GVSP is used to stream OpenGL ES commands from the remote server to the mobile device, then the latter will prefetch these commands and inject them inside the rendering pipeline to draw a frame on the mobile device. Each GO involves a number of modules to compute its behaviour and to draw its shape. These modules may differ in number and family between the GOs. We propose to enclose for each GO, the requested modules inside clusters. Our heuristic, computed by the network manager, dissects the possibility to offload or not a cluster, with respect to the code dependency constraint. This solution is a cluster decision-making; that is, it focuses on each GO independently from the others, since we need to decide rapidly to offload a cluster or not, to avoid any additional delay induced by more sophisticated algorithms like ILP or graph resolution. The proposed algorithm accepts as input a cluster, j (the set of modules requested by the object GO j ) and returns a binary decision x j (i.e., to offload or not the cluster j ). The concept of this algorithm is simple; if either the network latency or the time to send/receive data is higher than the local execution time of a cluster, then offloading the cluster will not improve the performance, thus x j = 0. Otherwise, if both latency and time to exchange data are less than the cluster execution time, the algorithm checks if a gain is achieved when offloading the cluster. The offloading gain is the difference between the local cost and the offload cost, this latter includes the communication cost and the remote execution. It is given by:

T G GO j = � s -1 s � × k j � i =1 T i - � d i U L + r i DL + RT T � (5.1)
where s is the speed ratio between the mobile device and the remote server, T i is the execution time of the module i that belongs to cluster j , k j is the number of modules enclosing the cluster j , and d i and r i represent, respectively, the data to send (receive, respectively) on the uplink, U L (downlink DL, respectively) bandwidth.

If offloading a cluster will achieve a gain, then it will be offloaded (i.e., x i = 1).

Algorithm 1 Offloading Decision

Inputs:

GO j : {T i , i = 1, 2, ..., k i } Outputs: Deci si on x j if ((RT T < �k j i =1 T i ) & (d i /B s + r i /B r < �k j i =1 T i )) then if (T G GO j > 0) then x j = 1 else x j = 0 else x j = 0 return x j

Performance

Now, we present the results of our measurement campaign regarding the CPU consumption and network communication needed to generate one game frame.

CPU Consumption

This section discusses the CPU consumption per frame and per module, for local and remote execution, under the two encoding qualities. Figure 5.3a presents the time (in ms) needed to generate one frame.

We used box-plots as we want to focus on the variability of the CPU consumption per frame. The aim is to quantify the stability of our framework. The box plot includes the 10 t h , 25 t h , median, 75 t h , and 90 t h percentiles of these times. On the other hand, Figure 5.3b shows (in %) the time spent by the aforementioned modules to contribute to the frame generation. We observe two things:

• Performance improvement. As seen in Figure 5.3a, our framework improves the performance by up to 21%. Indeed, more than 50% of frames are generated in less than 154 ms (125ms, respectively) for the good (fast, respectively) quality. However, the framework is not enough stable as the IRQ 3 and the range 4 are high values (143.97 ms and 151.52 ms, respectively).

• Rendering consumption. As Figure 5.3b is showing, rendering is the main consuming module. Indeed, this module is responsible for up to 70% of the CPU consumption for both executions (i.e., whether or not the game is offloaded) under the two encoding qualities. This high CPU consumption represents a concern in mobile gaming. For the other modules that are not related to rendering, they represent less than 30% of the CPU consumption of the demanding games.

Local Offload

Local Offload

Network Communication

To test the network performance of our framework, we captured the network load incurred by offloading the game modules to the remote server. Packets were captured using "Wireshark 5 ". We limited the 3 Interquartile Range (IQR) corresponds to the range of half of the scores around the median (the difference between the 75 t h and the 25 t h percentiles) 4 The difference between the highest (90 t h ) and the lowest (10 t h ) score 5 https://www.wireshark.org/ captures to 200 s.

We plot in Figure 5.4 the bitrate (in b y t es/s) for the network traffic between the mobile device and the remote server for the two qualities encoding.

We captured both the uplink and downlink traffic between the client and the server. In the downlink direction, the packet size varies between 54 and 394 B , and the median is 88 B for both the fast and the good quality. On the uplink direction, the packets size varies between 60 and 162 B (60 and 228 B , respectively) with a median about 86.5 B (83.9B, respectively) for the fast (good, respectively) quality.

As stated above, only commands are streamed to the mobile device. Therefore, the variation in the bit rate depends on the number of offloaded GOs. Indeed, higher are the GOs offloaded to the remote server, the greater is the number of streamed commands, hence, the higher is the bit rate. Between the two qualities, there is also a variation in the bit rate. We believe that it is due to the difference in the time needed by the server to compute the GOs before streaming the commands. This time depends on the number and type of GOs, which may differ between the two qualities encoding. directions for each frame encoded with the good (fast, respectively) quality. We make three main observations:

• Downlink rate is higher than the uplink rate. The average rate for the fast (good, respectively) quality on the downlink direction is around 17.13 (3.94, respectively) packet s/ f r ame, while on the uplink direction, this average is about 11.51 (2.39, respectively) packet s/ f r ame. This is somehow obvious as our framework relies on the remote server to stream back rendering commands and update various modules. The uplink traffic represents only input commands and (N)PC variables.

• The server follows the client pace. Despite the powerful capabilities of the remote server, it has to follow the client pace to stream back the results, since the network manager synchronizes between them. Indeed, the server is triggered only when it receives an event (input commands or RPC) from the mobile device.

• Server requested only on performance enhancement. Both Figures 5.5a and 5.5b exhibit two behaviors; less and high network communications. When the heuristic estimates that no offloading gain can be achieved, then the whole game is computed on the mobile device, hence the server is in an idle state, that is to say, only few control packets are sent by the server. However, when a gain can be achieved, the network manager establishes a communication between the mobile device and the remote server to collaborate in the frame rendering.

Responsiveness

To better understand how the client and server contributed in the frame generation, it is necessary to determine the interaction delay, which is consumed by several tasks: (i) capture of gamer input actions, (ii) transfer of command(s) to the remote server, (iii) execution of the m offloaded modules (om) on the server and the n -m non-offloaded modules (nom) on the client (where n is the total number of modules), (v) stream OpenGL ES commands, and finally (vi) inject the commands in the graphic pipeline and render a frame. This overall interaction delay I DL is divided into three parts:

1. Processing Delay, P D, is the maximum time between local and remote execution. Local (remote, respectively) execution time is the sum of non-offloaded (offloaded, respectively) modules execution delays as given in Equation (5.2). We used the visual studio profiler to extract these delays.

P T = max � n-m � i =1 t (nom) i , m � i =1 t (om) i � (5.2)
2. Updating Delay, U D, is the time spent to update locally modules inputs (such as the scripting module). We instrumented the code of the game to identify these delays. The U D is then, equal to the sum of all the networked update times t (uom) i for om i , given by Equation (6.2). longer than what we expected, 105.79 ms and 151.48 ms for fast and good quality, respectively. Since we leverage powerful remote server, we hope closer performance to Cloud gaming solutions, as the consuming modules are computed on the remote server and only command packets transit over the network. We believe that this drawback is due to the injection of the OpenGL ES commands in the graphic pipeline.

U T = m � i =1 t (uom) i (5.3

Framerate

We conclude the performance section by summarizing the different results via the framerate performance. Figures 5.7a and 5.7b depict the ratio of frames in a population of 1000 frames that are generated in less than x ms for the good and fast quality, respectively. When using our heuristic, the game engine generates more than 65% (30%, respectively) of frames in less than 33 ms for the good (fast, respectively) quality in comparison to the local execution, where the engine generates less than 10% of frames for the two qualities. Some frames are composed of several GOs that highly communicate through various modules which increase the interaction delay. Indeed, as the figures are showing, up to 35%, 70% of frames for the good, respectively fast quality need until 210 ms and 150 ms to be rendered. Our heuristic, in this case, offloads only a few clusters, as the communication cost is higher than the computational cost, or because no offloading gain is obtained for these frames.

Conclusion

In this chapter, we proposed a solution to play best-seller 3D games with high quality encoding, on powerless devices via offloading computation to a remote server. The concept is to identify modules involved by each GO in the game scene. Then, decide to offload them (as a whole) or not, depending on three main criteria: resource consumption, network communication, and code dependency. The mobile device and the server are synchronized through network manager, which orchestrates the offloading.

The solution is scalable and adaptable to the network latency as only modules improving performance are offloaded. It supports mobility since network packets are automatically routed to the mobile device.

MEC ORIENTED COMPUTATION OFFLOADING

Introduction

One of the 5G objectives is to reduce the network latency to 1 ms. This shall be possible only by bringing computation and storage resources closer to end-users. This has given rise to a novel concept, known as MEC or also Fog Computing. MEC is gaining lots of momentum, wherein the key idea is to empower mobile edge entities (e.g., radio access points such as eNodeBs and access gateways) with computation capabilities, allowing hosting and executing applications at the edge of mobile networks, rather than at a remote server in the Cloud or in the operator's core network domain. Combined with the 5G mobile access, which aims to drastically reduce the end-to-end latency, MEC will enable a plethora of novel mobile services that require low latency to access data or computation capabilities. Among the envisioned services are computation-offloading-driven applications.

Most of computation offloading works have been devised without considering MEC, since this concept is very recent. Moreover, they consider enforcing the offloading algorithms at the powerless device side, ignoring all information on the device network environment, especially varying radio quality. This can lead to dramatic situations, as the powerless devices may offload data even when the network conditions are bad (e.g., introducing high latency with the remote servers, not compatible with the devices application requirements). In this chapter, we use MEC as an enabler for low-latency computation offloading-based applications, not only by hosting the remote server on the ME, but also by devising a Mobile Edge (ME) service that continuously estimates the expected latency in order to feed the device decision to offload parts of an application's computing tasks. Indeed, according to the ETSI definition of MEC [START_REF] Etsi | Mobile edge computing (mec); framework and reference architecture[END_REF], the ME host is able to expose high level APIs to ME applications in order to provide real-time User Equipment (UE)-relevant network state information, making possible the prediction of UE network state (particularly the latency), and hence driving the UE decision of when to offload, according to the network conditions. To this aim, we devised a framework that runs on three different entities: a ME application (hosted on ME host and capable to access UE-related radio information), a UE, and a server (hosted in the ME side to reduce end-to-end latency), enabling network-aware computation offloading of low-latency applications. The ME application is in charge of: (i) accepting or rejecting UE requests to offload or not, and (ii) predicting (using the Radio Network Information Service (RNIS) API) and sending latency information to the UE. The UE enforces all the steps composing the computation offloading process, while using the estimated RTT value obtained from the ME application. Finally, the server is in charge of executing the offloaded code and sending back the results to UE.

Background and Related Work

The chapter presents a novel approach for computation offloading in MEC environment. We designed an application hosted in the ME, which interacts with the MEC host through different services to; (i) give an approximation of latency between a UE and a server in MEC; (ii) check the network condition and resource availability for a subscriber demand, in one hand, and with the end-user to accept or refuse his requests for computation offloading, in the other hand. To better understand these contributions, we introduce hereafter the LTE and MEC concepts followed by the state-of-the-art computation offloading oriented to MEC. EPS Bearer (Bearer for short) [2] is an end-to-end tunnel between a UE and a P-GW , in which UE Internet Protocol (IP) packets are encapsulated inside General Packet Radio Service (GPRS) Tunneling Protocol (GTP) header. A bearer uniquely identifies packet flows with a common QoS parameters. Therefore, all packet flows mapped to the same bearer, follow the same forwarding-packet treatment (e.g., scheduling policy, queue management policy, and link-layer configuration). For each bearer, we define a QoS class and a UE's IP address. An end-to-end IP packet is encapsulated within a tunnel header containing a bearer identifier so that the network nodes can associate the packet with the correct QoS parameters.

Based on the QoS parameters, a bearer can be classified as either default or dedicated bearer, as shown in Figure 6.1.

• Default Bearer: It is set up when a UE attaches to an LTE network and it is kept as long as the UE retains that IP address. It does not guarantee the bit rate and it offers only best effort service. In 3GPP specifications, it is mandated that a default bearer is non-Guaranteed Bit Rate (GBR) bearer because it can remain established for a long period.

• Dedicated Bearer: It is dedicated to one or more specific traffic (e.g., Voice over IP (VOIP) and video). It acts as a secondary bearer on a top of the default bearer, with which it shares the IP address. The dedicated bearer can be either a GBR or non-GBR bearer. An operator distinguishes traffic flows mapped onto dedicated bearers and their QoS levels using the Policy and Charging Resource Function (PCRF).

QoS Parameters

In the LTE network, the EPS bearer QoS is controlled by the LTE QoS parameters described in the following.

• Resource type: We distinguish two types of resources allocated to a bearer; GBR and non-GBR type.

-GBR bearer guarantees bandwidth and avoid congestion-related packets losses. Therefore, a traffic carried by a GBR bearer conforms to GBR QoS parameter associated with the bearer.

Consequently, GBR bearers are generally subject to admission control within the network when created or modified. GBR bearers are established on demand because they obstruct transmission resources and reserve them in an admission control function. GBR bearers are only established for dedicated bearers. The QoS Class Identifier (QCI) of a GBR bearer ranges from 1 to 4.

non-GBR bearer is a best effort type bearer and its bandwidth is not guaranteed. A service using a non-GBR bearer must be prepared to experience congestion-related packet loss. A default bearer is always a non-GBR bearer, whereas a dedicated bearer can be either GBR or non-GBR. Non-GBR bearer does not block any network specific traffic or transmission resources. It can remain established for a long time, its QCI ranges from 5 to 9.

• QoS parameters:

-QCI [3] is a scalar ranging from 1 to 9 to indicate nine different QoS performance characteristics of each IP packet. The QCI is used within the access network as a reference to node-specific parameters that give details of how an LTE node handles packet forwarding (e.g., scheduling weight, admission thresholds, and queue threshold). Operators deploy pre-configured nodes to handle packet forwarding according to QCI value. QCI values are standardized to reference specific QoS characteristics, and each QCI is associated with standardized performance characteristics that describe the packet-forwarding treatment that the bearer traffic receives in terms of resource type (GBR or non-GBR), priority (1 to 9), packet delay budget (from 50 ms to 300 ms), and packet error loss rate (from 10 -6 to 10 -2 ).

-Allocation and Retention Priority (ARP) is a scalar ranging from 1 to 15, with 1 being the highest level of priority. an ARP specifies the control-plane treatment that a bearer receives.

More precisely, it allows an LTE entity (e.g., P-GW, S-GW, or eNB) to decide whether a bearer establishment or modification request can be accepted or be rejected, and further, which bearer to release during network congestion.

-Maximum Bit Rate (MBR) and GBR are used only for GBR bearers. GBR and MBR define respectively, the minimum bit rate to be guaranteed by LTE networks and the maximum bit rate that a traffic in a bearer may not exceed. Any packets arriving at the bearer after the specified MBR is exceeded will be discarded.

-Aggregate Maximum Bit Rate (AMBR) is used to limit the total amount of bit rate consumed by a single subscriber. It is not defined per bearer, but rather per the entire non-GBR EPS bearer. In 3GPP specifications, we distinguish two AMBR parameters: (i) UE-AMBR, which is defined per subscriber and it is known by both the gateway and the RAN; (ii) APN-AMBR, which is also defined per subscriber, but only known to the gateway. The UE-AMBR and APN-AMBR are defined for an aggregate non-GBR bearers. These AMBR parameters are defined separately for uplink (UL) and dowlink (DL) direction. Therefore, there is four values for AMBR; (i) UL UE-AMBR; (ii) DL UE-AMBR; (iii) UL APN-AMBR; and (iv) DL APN-AMBR. The bit rate consumed by a GBR bearer is included in these AMBR values. length is equal to one slot1 (i.e., 0.5 ms), while in the frequency domain, the length of a RB is 180 K H z organized in 12 sub-carriers of 15 K H z spacing.

The used scheduling method largely impacts the throughput of individual users as well as throughput of the cell. Different scheduling methods have been proposed in the literature to deal with fairness and throughput.

• Round Robin (RR) [START_REF] Luo | Quality-driven cross-layer optimized video delivery over LTE[END_REF]: Resources are furnished cyclically to users without considering channel conditions. That is, the RBs are assigned equally among users (i.e.,in turn, one after another) regardless of CQI. The scheduler is aiming at giving the best fairness by providing an equal share of packet transmission time to each user. Thus, UEs are equally scheduled. However, throughput performance may degrade significantly due to the non consideration of the reported instantaneous downlink Signal to Noise Ratio (SNR) values in determining the number of transmitted bits.

• Proportional Fair (PF) [START_REF] Lee | Proportional fair frequencydomain packet scheduling for 3gpp LTE uplink[END_REF]: The algorithm is balancing between throughput and fairness among all UEs. PF aims to maximize, over all feasible scheduling rules, the utility function � i l og R i , where R i is the long-term service-rate of user i , by serving the user with the highest ratio r i (t )/R i (t ) at each time slot t ; r i (t ) and R i (t ) represent respectively, the quality channel-rate and the current average service-rate. That is, the scheduler tries to maximize the total throughput while, at the same time, provides all users at least a minimal level of service.

• Best Channel Quality Indicator (CQI) [START_REF] Schwarz | Low complexity approximate maximum throughput scheduling for lte[END_REF]: In this approach, the resource blocks are assigned to a user with the best radio link conditions. To perform a scheduling, an eNodeB sends a reference signal to a UE in order to measure its CQI. The UE generates the CQI reports2 and fed back them periodically, to the eNodeB in a quantized form. A higher CQI means better channel condition.

The scheduler can increase the cell capacity at the expense of fairness. That is, UEs that are far away from the eNodeB are unlikely to be scheduled.

MEC

MEC is an emerging ecosystem that provides an IT and Cloud computing capabilities (i.e., storage and computational resources) at the RAN edge in a near vicinity to end users. Besides the supplied resources, MEC offers real-time access to radio and network analytics and efficiently uses the mobile backhaul and core networks. MEC allows developing a plethora of new applications and services, consumed in an ultra-low latency and high bandwidth. The ecosystem is useful for service providers to introduce new services and differentiate costumers portfolio, by collecting information regarding costumers content, location, and interests. MEC offers an open radio network edge platform, facilitating multi-service and multi-tenancy. That is, authorized third-parties are allowed to use storage and processing capabilities and introduce on-demand, in flexible manner new businesses. MEC should enable a secure Cloud platform architecture and provide APIs to dynamically share and use the MEC platform, easily installing and modifying new services, and efficiently interacting with the RAN, e.g., being able to retrieve RAN-relevant information.

MEC Architecture

MEC is deemed as a critical technology to enable the transition toward 5 t h Generation (5G). Behind MEC standard, ETSI would mainly ease the deployment of UE applications requiring short latency access to remote servers. ETSI proposes a complete reference architecture that defines functional blocks and interfaces to describe the MEC system [START_REF] Etsi | Mobile edge computing (mec); framework and reference architecture[END_REF][START_REF]Technical Requirements, Group Specification (GS) 002[END_REF][START_REF]Terminology, Group Specification (GS) 001[END_REF].

The ETSI MEC framework describes three levels of entities and functions; mobile edge system, mobile edge host, and network level entities. Figure 6.2 portrays a simplified version of the MEC architecture as defined by ETSI [START_REF] Etsi | Mobile edge computing (mec); framework and reference architecture[END_REF]. This architecture concentrates on the mobile edge system level and on the mobile edge host level excluding the network level. The ME management system comprises the ME orchestrator, the ME platform manager, and the Virtualization Infrastructure Manager (VIM). The ME orchestrator has the view on the whole ME system, as it maintains the information about all the deployed ME hosts, the services and resources available in each host, the instantiated ME applications and the network's topology. The orchestrator is also responsible about installing ME applications, checking their authenticity, and validating the associated policies. It has a reference point with the operator's Operating Support System (OSS), which is the highest level management entity in a mobile network. The ME host is the logical entity that contains the ME platform and the virtualization infrastructure on which the ME applications run. The ME platform contains a set of baseline functions that enable ME applications to run on a particular host, to discover and consume ME services or to advertise and provide them through the service registry. The ME platform is also responsible for enforcing the traffic rules to route the data packets to/from the ME applications, and to maintain a Domain Name System (DNS) subsystem to discover the ME applications. ME applications run on the ME host as virtual instances (i.e., VMs or containers) and are designed to consume and/or provide ME services. The latter provide high level APIs that expose UEs status (radio and context information), which will be then used by the ME applications to optimize a registered service (e.g., offload computation).

ME Host Services

The MEC application development framework [START_REF] Chang | Analyzing mec architectural implications for lte/lte-a[END_REF] implemented in the ME host provides services and APIs for high-layer MEC applications. The framework is composed of four type of services highlighted through Figure 6.3.

• Common services. They are central in the MEC host as they facilitate the usage of the real-time network and radio information. In particular, the RNIS APIs, which exposes the following RAN information: -Control-plane interface: Exposes information on UE/eNodeB layer3, S1/X2 interface messages, used for network control. We may mention: UE status information (mobility state, mobility history report (X2); radio link failure report); eNodeB status information (including, physical RB usage per traffic class).

-Data-plane interface: It provides information on the X2-U and S1-U interfaces, such as UE configuration information (EPS bearer identity, bearer type (default or dedicated), bearer context (CQI, ARP), bearer bit rate (GBR or MBR)), UE status information (QCI, Channel State Information (CSI)), and network status information (aggregated physical RB usage, delay jitter of specific QCI).

• MEC services. Provide a common high-level APIs to the different MEC applications and use cases. These services include Key Performance Indicators (KPIs) evaluation and traffic profiling, positioning, IP and named data services, network status and configuration, analytic, and event capture.

• Support services. Provide common, specific functionality to most MEC services. They represent a basic platform services, that other more elaborated services can use. These services include but are not limited to; communication service, discovery and registry, policy and charging, monitoring, authentication, authorization, accounting, and SLA.

• Platform services. Provide physical and virtual resources through an orchestrator such as Open-Stack. The provided resources include the compute resources (CPU, and GPU), storage (e.g., RAM, and disc), network resources (vNIC), and I/O. SDN and Network Function Virtualization (NFV) operations belong to this service.

ME Host

Higher-Layer Application PLatform Interface (Mp1) Few studies have been proposed to use MEC as an enabler for computation offloading mechanism. For instance, in [START_REF] Zhang | Energy-efficient offloading for mobile edge computing in 5g heterogeneous networks[END_REF], authors studied the consumed energy in a computation offloading context for MEC in 5G heterogeneous networks. The authors have formulated an optimization problem that minimizes the energy consumption of the offloading scheme, which takes into consideration the energy consumption of both task computing and data transmission. The solution incorporates the multi-access characteristics of 5G networks. Therefore, a joint optimization problem was addressed to optimize the offloading and radio resource allocation under latency constraints. In [START_REF] Mao | Power-delay tradeoff in multi-user mobileedge computing systems[END_REF], authors have considered a MEC environment with several UEs, wherein tasks arrive in stochastic fashion. A trade-off is investigated between power consumption on mobile devices and execution delay for computation tasks. To this aim, find the optimal solution. A multi-user resource allocation for MEC has been also proposed in [START_REF] You | Multiuser resource allocation for mobile-edge computation offloading[END_REF].

The model is formulated as a convex optimization problem to minimize the mobile energy consumption considering the computation overhead and the capacity of the MEC. The model derives an offloading priority for each user according to its channel gain and energy consumption. A low priority derives a minimum offloading, while a high priority performs a complete offloading. Lastly, an extended study of computation offloading in a multi-cell environment was proposed in [START_REF] Sardellitti | Joint optimization of radio and computational resources for multicell mobile-edge computing[END_REF], wherein the authors considered a Multiple Inputs Multiple Outputs (MIMO) multi-cell system, with multiple users requests for computation offloading. The authors formulated the problem using a joint optimization of the radio and the computational resources for computation offloading in a dense deployment, with the presence of inter-cell interference.

Clearly, none of these proposed solutions use the MEC services to drive the decision to offload or not.

They all rely on local device's information to take such a decision. Our proposed framework overtakes this limitation by highly interacting with the MEC service to better predict UE's network quality of service, and thus considering up-to-date information to take offloading decision. The key idea of the proposed solution is to enable UEs to offload computation tasks to a remote server located near to the ME host. As stated before, MEC allows the reduction of the end to end latency, which may ease the computation offloading process. Unlike the existing solutions, where UEs take locally, without the remote server help, the decision to offload or not a part of the computation task, in this work we rely on the MEC architecture, to not only host the remote server, but also drive the UE decision to offload or not a computation task. To this end, we propose to dedicate a ME application for computation offloading (MEACOF3 ), on top of the ME host, to steer the UE decision to offload or not.

The ME application is in charge of initiating the computation offloading, using up-to-date information available within the RNIS API, and help the UE in taking the decision to offload or not.

One of the inputs usually considered to decide whether to offload computation tasks, is the latency between the remote server (hosted in the Cloud) and UE. In mobile networks, the latency value is impacted by different parameters, which depend on both the core network congestion level or the number of hops, and the wireless channel access. Note that hosting a server in the mobile edge to run the offloaded code prevents core network delay issue. Indeed, any server located near to an eNodeB is being reachable within a one hop connection. Therefore, only the wireless channel access may have impact on the latency. This latter is impacted by RBs allocated among different UEs in the same cell according to the priority of each UE. For the PF, Best CQI, and weighted RR schedulers, the higher the UE priority, the more often the UE is scheduled, so shorter the latency to access the wireless channel will be. The priority of each UE depends on his subscribed QoS parameters (refers to Section 6.2.1).

In another way, if a UE has a highly bad channel conditions it may not be scheduled often, which may increase the latency. In addition, depending on the number of active UEs in a cell as well as the scheduler policy for a UE in that cell, the packets towards that UE (or from that UE to a MEC server) may experience delay. Indeed, on the downlink (uplink, respectively) direction, if the number of active UEs in the cell is high and a UE is using a non-GBR type bearer (a default bearer or a dedicated bearer with no GBR), the packets towards that UE ( from that UE to a MEC server, respectively) might experience high delays at the eNodeB downlink queue (UE uplink queue).

Approximating the Round Trip Time (RTT) value in the wireless channel may be challenging as many types of information are required, such as the number of active UEs in the cell, the channel quality of the UE ( CQI and CSI), and the downlink and uplink bandwidth. But knowing that the ME application has access to these information via the RNIS API, it is possible to approximate the RTT and hence help the UE to decide to offload or not a part of the computation tasks. A global view of the proposed solution is shown in Figure 6.4. At the beginning, the ME application registers to use the RNIS API for specific UEs through the service registry, shown in Figure 6.2. Once a UE sends a request to offload data to a remote server (1), the ME application checks the RNIS API (2). If the ME application considers that it is better to executes the application locally on the UE, then it sends a reject (NON-OK message); otherwise it sends an accept (OK message) that includes the RTT approximation and the IP address of the ME server to connect to (3). The RTT value will be used upstream with energy and execution time to obtain the remote and local partitions, then offload the remote partition to the server having the IP address included in the OK message (4). The ME application approximates the RTT periodically and sends a

Keep-to-Live message including the estimated RTT [START_REF] Ryan | A hybrid granularity graph for improving adaptive application partitioning efficacy in mobile computing environments[END_REF]. The UE synchronized with the ME application, computes the partitioning algorithm at each period (i.e., use the new RTT to find the new partitions) and offload the remote partition [START_REF]Adaptive application offloading using distributed abstract class graphs in mobile environments[END_REF]. More details are given hereafter.

ME application Side

Once receiving the first request from a UE asking to offload data, the ME application, through different services gather several information to: (1) give an approximation of the RTT, (2) check the resource availability on the MEC, and (3) check the network conditions to accept or not subscribers offloading requests. Diagram in Figure 6.8 summarizes these actions, which are detailed in the following.

The minimum quality of the computation offloading service is guaranteed via the arguments defined by: Arguments: Quality (GBR, MBR, loss rate, and priority), protocol configuration (IP, named service), and the needed IT resources for the computation offloading service. 1. RTT approximation. Many works have tried to model the access latency in LTE radio access.

Among them, the authors in [START_REF] Baid | Delay estimation and fast iterative scheduling policies for LTE uplink[END_REF] proposed to rely on the Remaining Block Signal (RBS), which is sent periodically by the UE to the eNB in order to estimate the access delay. Though this solution shows a good approximation, it is difficult to use it at the MEACOF, since the RBS will arrive delayed to the ME application, leading to wrong approximations. Our solution is based on the UL scheduling report obtained via the RNIS API. Indeed, the UL Scheduling information indicates the PRB assignment per UE. The ME application will gather the UL information during a period of time, noted T , and analyze it to approximate the delay. To do so, we perform some simulations to provide an LTE environment in which several UEs are connected to an eNodeB using different bandwidths. The simulation details are provided in Section 6.4.1.

To better understand the eNodeB's scheduler behaviour, we limited the communication to one packet par UEs and only on the uplink direction. Results are shown in Figures 6.5, 6.6. The obtained results confirm that predicting the packet delay depends on four main factors: the number of UEs in the cell, the bandwidth capacity, the eNodeB scheduler, and the packet size.

Impact of the number of UEs. The packet delay is proportional to the number of UEs in the cell. For instance, in Figure 6.5a, when twenty UEs are interacting with the eNodeB in the same cell, the delay for the packets sent by the UE #19 and #20 take 51 ms to arrive to the eNodeB. However, in case of one UE is interacting with the eNodeB in the cell, the packet delay is 13 ms. We observe the same impact in the other cases (Figure 6.5b, 6.5c, and 6.5d), where the network latency is increasing with the number of active UEs in the cell. However, as the used bandwidths are larger than the one used in Figure 6.5a, the latency is reduced by a factor ranging from two to four for the UEs #19 and #20.

The reasons behind this impact are the following. Within a cell, increasing the number of UEs, will increase the communication, that is the number of transmitted packets to the eNodeB. Therefore, the UEs concurrently share the bandwidth to transmit their packets. The scheduler in the eNodeB should allocate the bandwidth resource (in term of RBs) with a certain policy. Therefore, each UE packet is segmented with respect to fairness.

Impact of the bandwidth capacity. The bandwidth has a direct impact on the delay; the higher is the bandwidth, the larger number of RBs can be allocated, so shorter the latency will be (with respect to the number of UEs in the cell). The bandwidth in term of RBs varies from 6 RB s to 100 RB s. The smallest resource capacity that can be allocated for a UE is the RB (180K H z organized in 12 sub-carriers of 15 K H z spacing). In case of 1.4 M H z (i.e., Figure 6.5a), The bandwidth carries 6RB s. Therefore, in the best case, only six UEs can be scheduled simultaneously, the other UEs should wait for other TTIs to be seen allocated RBs, and hence increase the delay with at least 1 ms (in case of resource allocation in the next TTI). In the other hand, when the bandwidth provides 100 RB s (i.e., capacity of 20 M H z), more then six UEs are packaged within the same TTI to send their packets. Indeed, the entire twenty UEs are scheduled in the same TTI.

Impact of the eNodeB's scheduler. The scheduling policy matter in network delay. Indeed, according to the scheduler policy in the eNodeB, a UE may take a long time to be scheduled, due to its poor modulation, because this latter depends on the radio conditions of the UE. As described in Section 6.2.1.3, the RR scheduler allocates RBs equally and periodically among the entire UEs, without considering the channel conditions, while the PF scheduler is serving UEs with the highest ratio between the quality channel-rate and the current average service-rate. In addition, CQI scheduler allocates resources according to users with the best radio link conditions. Therefore, each scheduler has its own algorithm to allocate resources, which promote a group of users, then reduce their network latency, and disadvantage other users, hence increase their network latency.

Impact of the packet size. The packet size has also an impact on the network delay that we illustrate To sum up: The number of RBs composing a packet, the bandwidth capacity, the number of UEs in the cell, and the scheduling policy impact the network delay. It is difficult to predict the network latency using all these information in complex calculation. What we propose to do is to use the RB and the scheduling allocation calculated by the eNodeB for each UE. To obtain these information, the eNodeB takes into consideration, the number of UEs in the cell, the scheduling policy, and the bandwidth. In this case, we only need to use these two information (RBs and scheduling allocation) gathered into the scheduling report, and obtained through the RNIS API, besides the size of packets in term of RBs.

We know that the TTI (or the smallest scheduling interval) in LTE is 1 ms. If we fix T to 1 s, then each period will include 1000 UL scheduling samples to be analyzed. If the UE has been scheduled X times during T , we can estimate the average scheduling delay during the period T , as T /X . In addition, the average of RBs that have been allocated for a UE during the period T is given by � � T i =1 RB al l oc /X �.

The average access delay noted by D is given by:

D = T X × P acket Si ze(RB s) � � T i =1 RB al l oc X � + 10 D = T X × P acket Si ze(RB s) � � T i =1 RB al l oc X � + 10 D = T X × P acket Si ze(RB s) � � T i =1 RB al l oc X � + 10
(6.1)
Of course this calculation represents an average, which may not lead to an exact approximation, but at least it can be used easily to estimate the UE's packet delay, requiring only the UL scheduling information available through the RNIS API. We believe that the 10 ms in the equation corresponds to the frame duration.

It is well known that the RTT could be approximated by multiplying the access delay by two, as the DL latency could not exceed the UL latency but would somehow be equivalent. Moreover, the backhaul latency may be omitted, as the server is located at the ME host. Then, the approximated RTT is equal to 2 × D. To avoid a sudden fluctuation of the estimated RTT, an Exponential Weighting Moving Average (EWMA) technique is used. The final value of the RTT, to be sent to the UE periodically is as follows:

RT T est = α × RT T pr ec + (1 -α) × RT T cur RT T est = α × RT T pr ec + (1 -α) × RT T cur RT T est = α × RT T pr ec + (1 -α) × RT T cur (6.2)
where α ∈ [0, 1], and RT T pr ec and RT T cur represent the most recent RTT estimate and RTT sample respectively.

2. Resource availability. The ME application accesses to the infrastructure service to check if sufficient resources can be reserved for the UE to compute the offloading code regarding to the UE requested requirements. Indeed, if the UE requirements are computation-intensive then, the ME application will reserve sufficient CPU and/or GPU if available. If the requirements are more memory-intensive than computation then, the ME application will reserve enough space (including disc, RAM, and cache).

Therefore, the ME application will request for a VM creation in the nearest server, which will be connected to the UE.

UE Side

The UE's framework, represented in Figure 6.9, in addition to profiling, scheduling, and proxy, it includes the following functionalities:

• Modelling -Modellizes applications into a valued graph.

• Partitioning -Solves the optimization problem via graph partitioning algorithms.

• Monitoring -Monitors resources on the UE (e.g., remaining energy, CPU load), and transmits periodically, these values with the RTT estimation to the Partitioning module.

• Patchingintroduces keyword "non-transferable" for classes with a code dependency constraint [START_REF] Cuervo | MAUI: making smartphones last longer with code offload[END_REF][START_REF] Gu | Adaptive offloading for pervasive computing[END_REF][START_REF] Othman | Power conservation strategy for mobile computers using load sharing[END_REF][START_REF] Ou | An adaptive multi-constraint partitioning algorithm for offloading in pervasive systems[END_REF][START_REF] Ou | An efficient runtime offloading approach for pervasive services[END_REF]. The request contains the application requirements (# CPU/GPU units, and memory size) and profile (computationintensive? memory-intensive? real-time application?)

The granularity level is a class, the profiling includes the execution time ti and energy consumption ei per class i , the interactions (calls frequency fi ) and exchanged data di with class i , the dependency constraint li , and the execution order oi .

1. Graph representation with a cardinality equal to # of classes:

• a vertex i represents the class i labeled with ti , ei , and li ,

• an edge (i , j ) corresponds to an interaction between two classes i and j , the edge is labeled with fi and di .

Graph reduction:

• Constitute the clusters (SCC algorithm),

• Compute the cluster weights ti , ei , and li (Vertices Modelization algo),

• Connect the clusters and compute the edge weights fi and di (Edges Connections algo). From the valued and locality-labeled graph (VLG) we construct a reduced valued and locality-labeled graph (RVLG). The first step consists into grouping the vertices that highly communicate inside clusters using the Strongly Connected Components (SCC) algorithm, leading to reduce the size of the graph as well as the communication between components. Indeed, reducing the graph size permits to decrease the resolution overhead and the network communication. Next, we compute the weights for each cluster and connect them together to create the reduced graph RVLG. To this aim we used the procedures Vertices Modelization, and Edges Connections.

Local-View algorithm

a. Create the Clusters. The SCC algorithm constructs a cluster from a given vertex a. This cluster will at least contain the element a. To construct the cluster we proceed as follows. First, we initialize all the components of the graph to non visited (lines (3,4) and [START_REF] Arnold | Jini specification[END_REF][START_REF] Badger | Draft cloud computing synopsis and recommendations[END_REF]). Next, we create two sets of 128 6.3. PROPOSED FRAMEWORK vertices (lines 6, 16). One of them will contain all the successors4 of all the vertices in this set (lines 7 to 12), and the other one will regroup all the predecessors5 of all the elements in this set (lines 17 to 22).

Finally, we obtain a cluster which is the intersection between the two sets of vertices (line 23). for each v i n V 4:

vi si t ed ( v ) = f al se ; 5: end 6: V 1 = {a}; 7: while ( ( v i n V 1 ) && ( not vi si t ed ( v ) ) ) 8:
vi si t ed ( v ) = t r ue ; 9:

for each for each v i n V while ( ( v i n V 2 ) && ( not vi si t ed ( v ) ) )

� ( u = (v, y) i n E ) && ( y not i n V 1 ) � 10: V 1 = V 1 + {y} ; 11:
18:

vi si t ed ( v ) = t r ue ;

19:

for each

� ( u = (y, v) i n E ) && ( y not i n V 2 ) � 20:
V 2 = V 2 + {y} ; return

V 1 -(V -V 2, ) ; // (V 1 � V 2 )
24:

end b. Create the new Graph. Once the clusters have been created (using the SCC algorithm), we create the reduced valued and locality-labeled graph (RVLG), reduced graph for short 6 . First, we define the vertices that compose the reduced graph using the procedure Vertices Modelization. Each vertex in the reduced graph corresponds to one of the created clusters (with at least one vertex inside). The cardinality 7 of the reduced graph is equal to the number of created clusters. In what follow, we use the term cluster to represent a vertex in the RVLG, in order to distinguish the appellation with the vertices of the VLG. Next, we assign weights (time and energy) to each cluster in the reduced graph. The energy and time weights of each cluster c i are the cumulative weights of all the vertices inside this cluster c i (lines 8 and 9). After, we put a locality label for each cluster in the reduced graph, which depends on the locality labels assigned to the vertices inside these clusters. If at least one vertex j in the original graph (VLG), that is inside a cluster c i , has a label l j = 0, then the cluster c i should be labeled with l c i = 0, otherwise l c i = 1. In other words, if a class from the cluster c i cannot be offloaded, then the whole cluster c i cannot be offloaded (lines 11 to 14).

Afterward, we connect the clusters using the Edges Connections procedure. For each edge in the original graph (VLG), if the two vertices that constitute the edge belong to two distinct clusters, then an edge between the two clusters (if it does not exist, line 7) is created. Finally, we compute the edge weights for the reduced graph. The weights of an edge (c i , c j ) are equal to the sum of weights of each edge (x, y) in the VLG wherein, x, y do not belong to the same cluster c i or c j (i.e., � x ∈ c i and y ∈ c j � or �

x ∈ c j and y ∈ c i � (line 8)). This process is repeated for all the clusters. The result is a reduced valued and locality-labeled graph (RVLG).

1: procedure VERTICES_MODELIZATION(G(V , E )) 2: begin 3: G � (V � , E � ) = G(V , E ); 4: i = 1; 5: while (V � � = ∅) 6: v = r and om(V � ); 7: C i = SCC (G � (V � , E � ), v); 8: T C i = � c ar d (C i ) j =1 T v j , v j ∈ C i ;
9:

E C i = � c ar d (C i ) j =1 E v j , v j ∈ C i ; 10: V � = V � -C i ; 11: if ((∃ v j ∈ C i ) & (l j == 0)) then 12:
l c i = 0;

return C = � i j =1 C i ; 18: end 1: procedure EDGES_CONNECTIONS (G (V , E ) , C = � i j =1 c i ) 2: begin 3: for ( i = 1 , i ≤ C .l eng t h , i ++ ) 4: j = 1 ; 5: while � ( j ≤ C .l eng ht ) && ( j ! = i ) � 6: for each � � ( u = (v, w) ∈ E ) && ( v i n c i ) � && (w ∈ c j ) � 7:
Create e(c i , c j ) in the RVLG if it does not exists ; 8: To this end we model the offloading decision problem using an ILP. However, the resolution of the ILP may take time and drastically increase with the size of the application. Indeed, there is a local Energy consumption by the UE for the uplink and downlink results

W (c i , c j ) += W (v,

E i d l e

Energy consumption by the UE while the server computes the remote partition Finally, the communication cost, which includes the latency as well as the time to send and receive the results from the server. We define a threshold value, E t h , for the energy, as the maximum amount of energy that can be spent for the application processing. We set this value to 95% percent of the total consumption of the application when it is executed locally. This constraint is useful in our model: In the worst case, we gain 5% energy, and more importantly, this constraint prevents from wasting additional energy due to the network communication, as our objective function focuses on the execution time optimization. The algorithm steps are as follows:

First, the RVLG is represented by a matrix in order to be given as input to an ILP. The proposed ILP 6.3 aims to improve the execution cost of the overall program, while maintaining the energy consumption under a certain threshold (E t h ).

Mi n

n � i =1 � (1 -x i ) T i + x i � T i s + d i U L + r i DL + 2 × RT T �� s.t .            � n i =1 � (1 -x i ) E cpu + x i (E i d l e + E ni c ) � ≤ E t h ∀i ∈ {1, ..., n} , x i ∈ {0, 1}, l c i ∈ {0, 1} x i ≤ l c i (6.3)
The symbol x i is a binary variable that indicates the ILP output: x i = 0 (respectively x i = 1) denotes local (respectively remote) execution of cluster c i . The constraint x i ≤ l c i concerns the clusters that cannot be offloaded, due to the hardware dependency constraint, as stated before; therefore, if a cluster is labeled with l c i = 0 (i.e, non-offloaded cluster), then x i = 0 (i.e., this cluster will not be offloaded).

The server CPU speed s, could be obtained along with the IP address of the remote server.

Similar to performance, ILP 6.4 aims to minimize the energy consumption of the application through offloading under some constraints; the total execution time of the application should be less or equal to the total execution time on the UE, the symbols x i as well as l c i are binary variables, and clusters that have the dependency constraint cannot be offloaded.

Mi n

n � i =1 � (1 -x i ) E cpu + x i (E i d l e + E ni c ) �            � n i =1 � (1 -x i ) T i + x i � T i s + d i U L + r i DL + 2RT T �� ≤ � n i =1 T i ∀i ∈ {1, ..., n} , x i ∈ {0, 1}, l c i ∈ {0, 1} x i ≤ l c i (6.4)
Next, When the ILP is defined, it is solved to compute the value of each x i . Afterward, each cluster c i is assigned to one of the two partitions (local partition or remote partition) according to the value of the corresponding x i ; that is, if x i = 0, then the corresponding cluster is assigned to the local partition, otherwise it is enclosed inside the remote one. Last, the algorithm returns the set of clusters that should be offloaded (remote partition), and those that should be executed on the UE (local partition).

Algorithm 2 Global-view 1: Inputs: M n,n , L = � k i =1 (l c i = 0), k < n; 2: Outputs: X = � X Loc al , X C l oud ; 3: Objective = T i me 0 OR Ener g y 1 ; 4: if (Ob j ec t i ve == 0) then 5: X = � n-k i =1
x i = Solve_ILP (eq : 6.

3);

X =

� n-k i =1 x i = Solve_ILP (eq : 6.4); separately from the others. The proposed algorithm dissects the possibility of offloading a cluster or not, with respect to the dependency constraint. The purpose is to avoid using the ILP, in order to reduce the resolution time compared with the Global-View algorithm. Indeed, for some low-latency applications, there is a need to decide rapidly to offload a cluster or not, to avoid additional delays. Like the Global-View model, the proposed algorithm accepts as input the RVLG and generates two partitions as output;

the local partition and the remote partition. The concept of this algorithm is simple; for each cluster c i , if either the latency or the cost of communication (i.e., exchanged data) with the ME is higher than the local execution time of this cluster, then offloading the cluster will neither improve the computation cost nor the consumption cost (i.e., x i = 0). Otherwise, if both latency and the communication cost are less than the execution time, the algorithm checks if a gain is achieved when offloading the cluster. The offloading gain is the difference between the local cost and the offload cost (the offload cost includes the communication cost and the remote execution) and is defined as:

T G o f f = w × � 1 s m - 1 s � - � d i U L + r i DL + 2 × RT T � (6.5)
where w is the the amount of computation for cluster c i , and s m represents the UE processing speed.

If offloading a cluster will achieve a gain and no dependency constraint was made on this cluster (i.e., l c i = 1), then it will be offloaded (i.e., x i = 1).

Inputs: M n,n , L = � k i =1 (l c i = 0), k < n; 2: Outputs: X = � X Loc al , X C l oud ; 3: for each i ∈ V 4:
if (i ∈ L) then 5:

x i = 0 6: else 7: if ((RT T < T i ) & (d i /B s + r i /B r < T i )) then 8: if (T G i o f f > 0) then 9:
x i = 1 10: else 11:

x i = 0 12: else 13:

x i = 0

14: end 15: return X

Server Side

We introduce in this section, the architecture and the functionalities of our framework installed on the server. The framework is composed of:

• Profiling -Keeps track of several attributes evaluation (e.g., memory usage, CPU time, and energy consumption) during the application execution. Valgrind 8 , IntelVTune 9 , and Visual Studio 10 are some profilers.

• Scheduling -Schedules the execution on the server according to the component dependency graph, generated by the profiler or sent from the UE.

• S-Proxyinserts RPC communication sockets between the UE and the server.

• Monitoring -Monitors resources usage. The values are sent to the UE to be used in the offloading process. In this section, we present the evaluation of the proposed framework, through a computer simulation for the MEACOF and a testbed for computation offloading. We describe the simulation scenario and testbed, then discuss the obtained results.

Latency approximation

Our use case is made on the network simulator NS3 11 using lena 12 project, to simulate an LTE environment wherein, we connect between one to twenty UE with the same budgets and distance to an The UL bandwidth is around 50 M bps, and the DL bandwidth is 60 M bps.

In this section we discuss the results obtained through the two proposed algorithms: global-view and local-view.

After the profiling step, 96 classes are used by the application. These classes were then grouped into clusters.

Figure 6.12 illustrates the number of clusters to offload regarding the latency between the UE and the MEC server. We make two main observations here.

• The number of clusters to offload is inversely proportional to the latency. This remark is applicable for both proposed algorithms (i.e., Global-View and Local-View). When the network latency is increasing, there is less offloading gain, hence less clusters to offload. Basically, the Global-View (Local-View, respectively) algorithm minimizes (maximizes, respectively) the model defined by equation 6.3 (the gains through equation 6.5, respectively). To minimize equation 6.3, the second part of the sum (i.e., x i

� T i s + d i U L + r i DL + 2 × RT T �
) should be equal to zero when the latency (RTT) is high (i.e., x i = 0). For equation 6.5, there is a gain (T G o f f > 0) when the RT T is less than

� 1 2 � × � w � 1 s m -1 s � - � d i U L + r i DL ��
. Once the latency reaches 110 ms, the performances of both algorithms converge; less than 10 clusters are offloaded. The number of offloaded clusters is merely zero when offloading a cluster will not generate gains.

• The Global-View algorithm identifies more clusters to offload than the Local-View. Deciding where to execute each cluster subject to latency constraints is very challenging, as it requires a global view of the program's behavior. The solution is optimal only when the decision strategy is globally optimal (i.e., across the entire program) rather than locally optimal (i.e., relative to a single cluster invocation). The Global-View algorithm solves an ILP, which helps to derive the optimal solution.

Thus, for each latency value, the ILP finds the maximum number of clusters that minimizes the cost (i.e., the optimal number of clusters to offload). The Local-View algorithm, on the other hand, focuses on each cluster independently of the others, searching only for local solutions. A cluster is offloaded if and only if a gain (i.e., T G o f f ) is obtained. We believe that the difference between the two curves is due to the communication cost of some clusters which do not result in a local gain as the communication cost exceeds the computation one but improve the global gain. Now we turn our attention to the gain that could be achieved for users. For this purpose, we focus on two important metrics regarding improving user experience: (i) the time needed to execute the face 136 6.4. RESULTS recognition application, and (ii) the energy consumed at the user end. Figure 6.13 presents the response time using three approaches: (i) the whole application is computed locally on the UE, (ii) the application is computed using the Local-View algorithm, and (iii) the application is executed employing the Global-View algorithm. The two last approaches are subject to the network latency. The total execution time for face recognition takes around 9.5 s. This time corresponds to the elapsed time between the moment when the web camera of the laptop is launched and the moment of viewing the result. Inside this delay interval, different actions are performed, including (i) launching the web-camera, (ii) capturing a video (a set of 300 frames), (iii) communication with a graphical QT interface to display the video in real-time, (iv) detection (detecting eyes, face, keypoints, and landmarks) for each frame to have the illusion of tracking, (v) normalization (applying color conversion, enhancement, and filtering), (vi) representation (computing binary patterns, key-point descriptors, orientation histograms, and wavelets), (vii) extraction (using clustering, normalization, and quantization), and (viii) matching (using classifiers, distance metrics, and density estimation).

The Global-View algorithm achieves the best performance for all the latency values. For a 10 ms latency, the Global-View algorithm (Local-View, respectively) offers almost 69 (62, respectively) percent of gain compared with the local execution. For small latency (10ms to 60 ms), the Global-View algorithm is almost 1.13× optimal compared with the Local-View Algorithm. For a latency higher than 110 ms, the two algorithms offer the same performance, since both identify the same clusters to offload. As the latency is high, the two algorithms converge to the same results.

Conclusion

In this chapter, we proposed a novel framework for computation offloading, which uses the MEC architecture defined by the ETSI, taking advantage of its RNIS API to estimate network latency between the UE and a server hosted in the ME. This estimation, coupled with other parameters, is used to derive an offloading decision for the UE. We formulated two models operating at different granularity (application component vs. component cluster level). Whilst the fist model searches for an optimal offloading, the second model searches for a fast solution. The effectiveness of our design, tested using a face recognition application, unveils an execution 62 percent faster than the local execution, and can save up to 93.5 percent of energy for the UE.

CONCLUSION

Nowadays, computation offloading is gaining ground and maturity especially with the transition toward 5G mobile access and edge computing, which solve the issue of high latency with the Cloud. Therefore, offloading delay-sensitive applications becomes possible with these two technologies. 5G mobile network promote the concept of "Anything as a Service" (ANYaaS), which allows MNOs to create and orchestrate 5G services on demand and in a dynamic way. Computation offloading as a Service (COFaaS) is one of these services. Indeed, most of verticals will be connected to the Cloud or edge to offload their requests.

In case of automotive, smart cars are interested into collision avoidance and traffic fluidity, therefore, they offload requests to MEC in order to predict and anticipate traffic congestion. For the eHealth, smart clothes, chooses or watches will offload their data/computation to the Cloud/edge to study a consumer health and if needed call the emergency service for intervention. Several other use cases are defined by verticals such as robotics and many others. Yet, Computation offloading can not be deployed before solving the overcoming issues that face this solution raging from resource consumption, interoperability and dependency constraints to security and monetary cost.

We developed through this thesis several algorithms and methods to improve performance of applications via computation offloading, reduce resource consumption and make possible the computation offloading of 3D mobile applications.

Results obtained during the thesis

The contributions of the thesis were divided into three parts:

• A computation offloading heuristic for 3D mobile games: The proposed heuristic first, decomposes the 3D world scene of the game into various game objects including the NPC, player character, environment, and particles. Then enclose for each GO, the requested modules inside 139 CHAPTER 7. CONCLUSION clusters. The heuristic studies the possibility to offload or not a cluster, with respect to the code dependency constraint. It is a cluster decision-making, which focuses on each GO independently from the others. The proposed algorithm accepts as input a cluster and returns a binary decision (i.e., to offload or not the cluster). The heuristic checks if the network latency or the transmission delay is higher than the local execution time of a cluster, then offloading the cluster will not improve the performance, thus it is not offloaded. Otherwise, if both latency and time to exchange data are less than the cluster execution time, the algorithm checks if a gain is obtained by offloading the cluster. The offloading gain is the difference between the local cost and the offload cost, this latter includes the communication cost.

• Two algorithms for computation offloading; Global-view and Local-view: The former is based on ILP and the latter is an heuristic. First, the application candidate for computation offloading is modelled with a valued graph, wherein the vertices represent the application components and the edges are the interactions between the components. The vertices are valued with the resource consumption (i.e., CPU time and energy consumption), while the edges are labeled with the amount of exchanged data, frequency of interactions, and code dependency. The graph size is then reduced by clustering the components that highly interact. The global-view algorithm draws an ILP from the reduced graph and solve that ILP with the objective function to reduce the energy consumption and improve performance subject to available energy, execution time, and code dependency. The local-view algorithm computes for each cluster of the reduced graph, the offloading gain. Then decides according to this gain if a cluster will be offloaded or not.

• A framework-based computation offloading oriented MEC: The contribution was to devise a framework running on three different entities: (i) ME application hosted on ME, which is able to access mobile user related radio information, (ii) mobile user, and (iii) server hosted in the ME.

The ME application is responsible for driving a decision to accept or to reject offloading requests coming from mobile devices, and predicting, using low-level APIs, the RTT value. The mobile device is in charge to take the decision to offload or not the application modules according to the estimated RTT value obtained from the ME application. Finally, the server, hosted on the ME side, computes the offloaded code and sends back the results to the mobile device. As a proof of concept, the authors have run a face recognition application on the mobile device, which offloads computation to the server hosted in the ME.

Perspectives

To extend our works, the future research directions will cover the following axes: Our frameworks still works in progress, they are unoptimized initial prototypes, with several performance optimizations still possible. In the future we will continue to improve the frameworks to deal with two main issues; the network latency and the rendering activity.

PERSPECTIVES

• One of our motivations is to leverage MEC architecture to drive a computation offloading. We want to use MEC as an enabler for low-latency computation offloading-based games. To this aim, we rely on our framework proposed in [START_REF]On using edge computing for computation offloading in mobile network[END_REF] to orchestrate the offloading process and introduce the concept of Edge gaming.

• Another axis that we want to explore is the caching concept. Caching allows storing data locally to cope with network latency. Data are used in future invocations to reduce the interaction delay and therefore improve the performance. Data caching approach stores data such as video streams near to the mobile user. This solution is known as CDNs.CDN has been proposed to maximize bandwidth, improve accessibility, and maintain correctness through content replication. We want to investigate service code caching and CDN in our framework to improve the performance.

There are still numerous challenges that need to be solved to make computation offloading a prevalent technique.

• Security and trust issues prohibit the applicability of computation offloading to unknown environments. Introducing SDN controllers and firewalls in computation offloading is a reliable solution.

Indeed, an SDN firewall will filter the TCP communications according network security policies by recording and processing the different states of connections and interpreting the possible transitions into an OpenFlow rules.

• Another challenge that current research is facing is mobility of users requesting computation offloading. In the recent trends, users are mobile using their mobile devices such as smartphones to connect to the Internet and consume their applications. Offloading computation in a highly mobile environment is challenging. One of our future motivation is to introduce the SDN/NFV, Follow Me Cloud/Edge [START_REF] Ksentini | A lisp-based implementation of follow me cloud[END_REF] to manage the mobility.

• We are also interested into the placement of the offloaded tasks to better exploit the provider resources and improve the performance of the end-user. Offloaded task placement should be similar to the VNF placement. This is central in 5G mobile access, as a tremendous mobile devices are requesting for remote finite resources located in the edge of access network.

• Last but not least, we would like to explore computation offloading from business view. Mobile Network Operators may provide computation offloading as a service in 5G networks. Therefore, we will need to define a model for computation offloading to deal with the 5G architecture and propose a cost model for that service. tasks sequentially. We suppose an application requesting for computation offloading. The program of this application is divided into two partitions; the local partition and the remote partition;

• The local partition (P 1 ) contains the part of the program that should be computed on the mobile device.

• The remote partition (P 2 ) encloses the part that may be offloaded (i.e., the program remainder).

The local partition, P 1 , should be computed on the mobile device, it cannot be offloaded according to Section 3.4.4. Therefore, no offloading gain can be achieved through this partition. Hence, we turn our interest on partition P 2 .

1. Local execution of the partition P 2 . The time to execute the partition P 2 on the mobile device is given by: T m = w We note from Equation A.1 that if the execution time of partition P 2 on the mobile device is shorter than the communication delay (i.e., w s m < D t B t + D r B r + RT T ) then, even if the server is infinitely fast, Equation A.1 will be false (i.e., offloading will not improve the execution time). Hence, this inequality is correct for CPU-computation intensive tasks (Large w), powerful server (high speed s s ), large uplink bandwidth B t , and downlink bandwidth B r , and exchanging small data size between the mobile device and the remote server (small d i ).

We define G t o f f (Equation A.2) as the computation offloading gain.

G t o f f = w × � 1 s m - 1 s s � - � D t B t + D r B r + RT T � G t o f f = w × � 1 s m - 1 s s � - � D t B t + D r B r + RT T � G t o f f = w × � 1 s m - 1 s s � - � D t

A.1.3 Reducing memory

Running some applications with memory intensive on resource-constrained mobile devices such as Personal Digital Assistant (PDA) is not possible. Hopefully, offloading the memory-intensive tasks to a remote server make the execution of these applications on such devices (i.e., PDA) possible. We propose in the following, a simple model analysis of a memory-related offloading consumption.

The memory consumption of the whole application on the mobile device is the sum of the memory occupied by the part P 1 (mem 1 ) and the part P 2 (mem 2 ) i.e., (mem 1 + mem 2 ).

Offloading the part P 2 saves the memory utilization when:

   mem 1 + mem 2 > Av ai l mem × f mem 1 < Av ai l mem × f (A.5)
The memory offloading gain is given by Equation A.6.

G m o f f = mem 2 -δ G m o f f = mem 2 -δ G m o f f = mem 2 -δ (A.6)
Selon que ces étapes soient réalisées au moment de l'exécution de l'application ou avant, nous distinguons trois approches de délestage de calcul : a. Délestage statique : il se produit avant le démarrage de l'application. Dans ce type de délestage, l'application est partitionnée seulement une fois en deux partitions : la partition locale qui contient les composantes logicielles qui doivent s'exécuter localement sur le terminal et la partition distante qui englobera les composantes à exécuter à distance. L'application est ainsi partitionnée avant son exécution, durant les phases de développement ou d'installation. b. Délestage dynamique : pour pallier aux limitations de l'approche statique (en particulier l'hétérogénéité de l'environnement), l'approche dynamique est proposée. Cette approche s'adapte mieux aux variations de l'environnement (ex. latence, qualité du réseau, bande passante, énergie restante sur le terminal, sa charge de travail et celle du serveur) durant l'exécution. Les différentes étapes de délestage sont effectuées durant l'exécution de l'application. c. Délestage hybride : pour tirer profit des deux approches (statique et dynamique), l'approche hybride ou semi-dynamique est proposée. Dans cette approche, une partie de la décision est prise durant la phase de design de l'application par le programmeur ou durant la phase d'installation par des outils d'analyse statiques. L'autre partie est partitionnée durant la phase d'exécution de l'application (délestage dynamique).

Le délestage de calcul implique diverses parties prenantes: le terminal, le réseau, l'application, le serveur distant, l'utilisateur mobile, et le framework de délestage. En conséquence, plusieurs défis et problèmes sont apparus traitant du temps de réponse, de la consommation en énergie, de la sécurité, et des communications réseau. Différents travaux de recherche sont menés pour soulever ces verrous. Certains sont résolus, tels que la latence du réseau, en utilisant le ''Multi-access Edge Computing (MEC)'' ou le ''Fog Computing'' dans des solutions de délestage de calcul. En termes de communications réseau, des technologies d'accès multi-radio (multi-RAT) et une utilisation de la bande passante à la demande pour améliorer le débit sont proposées. Certains autres défis restent à résoudre, tels que la latence du Framework, son architecture, et les algorithmes que ce dernier embarque pour les prises de décision. Nos contributions couvrent certaines de ces questions.

1.1 Contributions de la thèse La thématique générale de la thèse traite du délestage de calcul pour des applications temps réel, à forte demandes en ressources, et grande complexité, comme les moteurs de jeux 3D et la reconnaissance faciale. Les travaux de recherche abordent des sujets relatifs à la faisabilité, la performance, et la latence réseau impactant les solutions de délestage. Les contributions de la thèse sont triples:

1. Les moteurs de jeux: sous cet axe, il y a deux contributions [190,[START_REF] Messaoudi | Dissecting games engines: The case of unity3d[END_REF], divisées en trois parties :

a. Stratégie de déploiement: les moteurs de jeux sont étudiés dans un contexte Cloud en termes de variabilité des demandes en ressources. Différents types de jeux sont testés, et les performances obtenues sont considérées pour la consolidation du serveur. Les fournisseurs de jeux dans le Cloud devraient trouver un compromis entre la qualité de l'expérience (QoE) de l'utilisateur et le nombre de moteurs de jeux hébergés par un serveur. Actuellement, les serveurs dans le Cloud sont répartis entre plusieurs moteurs de jeux en utilisant les technologies de virtualisation. Plus la demande en ressources d'un moteur de jeu est élevée, plus importantes seront les ressources à réserver à la machine virtuelle hébergeant ce moteur de jeu, ce qui entraîne une sous-exploitation du serveur.

3G 3 r d Generation 5G 5

 5 t h Generation 3GPP 3 r d Generation Partnership Project INTRODUCTION N owadays, mobile devices such as smartphones and tablets, are gaining enormous popularity.

Figure 2 .

 2 Figure 2.1 portrays the aforementioned offloading steps applied to a simplified version of Google'

-

  Class processing time: α i (ms) -Class energy consumption: β i (m j oul es) -Class memory usage: γ i (K B ) -Class energy consumption: δ i (m j oul es) -Class data transfer: d i (B ) -Class calls frequency: c i (#) -Class code dependency: l i (0/1) • Graph interactions: callee/caller (α i (ms)) Energy consum. (β i (m j )) Memory use (γ i (K B )) Data size (B), Calls (#)

Figure 2 . 1 :

 21 Figure 2.1: Computation offloading process

Figure 2 . 2 :

 22 Figure 2.2: Time-based approaches for allocation decision

Figure 2 .Figure 2 . 3 :

 223 Figure 2.3 shows the results. From 1998 to 2009, there were between 34 and 93 papers a year. Load sharing was the main research area during this period. Only a few papers were published on computation offloading during this era. We believe that computation offloading was limited by the lack of technological advancement in this epoch, especially in wireless technology, virtualization, and infrastructure. Since 2010, interest in computation offloading has increased dramatically, thanks to the arrival of new technologies, including materials (such as smartphones, Internet of Things (IoT), robots,

  (3G, 4G LTE, 5G, Wi-Fi, WiMax), -Latency, bandwidth, -Network security, -Weather conditions. -VM profile (CPU, GPU, RAM, I/O), -Virtualization technology (Xen, OpenStack, Docker).-Type (data, application), -Volume/size, -Computation intensity, -Content confidentiality.

Figure 2 . 4 :

 24 Figure 2.4: Critical metrics influencing the offloading decision making

Figure 3 . 1 :

 31 Figure 3.1: User-based computation offloading taxonomy

3. 3 .

 3 COMPUTATION OFFLOADING TAXONOMY: FROM THE MOBILE DEVICE PERSPECTIVE users and Cloud providers. Encryption/decryption, authorization, and authentication techniques are used in the MCC to overcome the trust challenge. However, these techniques increase the communication overhead and resource consumption on mobile devices.

CHAPTER 3 .Figure 3 . 2 :

 332 Figure 3.2: Mobile device-based computation offloading taxonomy

Figure 3 Figure 3 . 3 :

 333 Figure 3.3: Applications-based computation offloading taxonomy

Figure 3 . 4 :

 34 Figure 3.4: Hardware/software entities involved for human-machine interaction

Figure 3 . 5 :

 35 Figure 3.5: Network-based computation offloading taxonomy

3. 6 .Figure 3 . 6 :Figure 3 . 7 :

 63637 Figure 3.6: Server-based computation offloading taxonomy

  d) MEC mainly targets 3GPP-based mobile networks. It provides computing capabilities within the RAN, in close vicinity to mobile users. It offers ultra-low latency with high-bandwidth.

Figure 3 . 8 :

 38 Figure 3.8: Hybrid Cloud model

56 3. 6 .

 566 COMPUTATION OFFLOADING TAXONOMY: FROM THE SERVER PERSPECTIVE

Figure 3 Figure 3 . 9 :

 339 Figure 3.9: Frameworks-based computation offloading taxonomy

✓Figure 3 . 10 :

 310 Figure 3.10: Taxonomy around migration patterns

Figure 3 . 11 :

 311 Figure 3.11: Taxonomy around framework nature (modelling and partitioning algorithms)

68 3. 7 .

 687 COMPUTATION OFFLOADING TAXONOMY: FROM THE FRAMEWORK PERSPECTIVE in the application. Shuiguang et al.[START_REF] Deng | Computation offloading for service workflow in mobile cloud computing[END_REF] have used GA to solve the offloading optimization problem. They used the objective function F

1 ,

 1 and M /M /1/N have been used in various scenarios. M /G/D represent the exponential/general/deterministic distribution, while S/N describes the server/queue capacity. Rong et al.[START_REF]A markovian decision-based approach for extending the lifetime of a network of batterypowered mobile devices by remote processing[END_REF] proposed to use queuing theory, combined with a Markovian Decision Process (MDP), to extend the lifetime of battery-powered mobile devices through computation offloading. The proposed framework is composed of three components; the client (mobile device), the server (base station), and the wireless channel. The authors have modelled the client as a Continuous-Time Markov Decision Process and proposed an interaction model for the client and remote server. The wireless channel has been modelled with a Markov chain using two states, in which each state is assigned a constant Packet Error Rate PE R. The server is an infinite M /M /1

Figure 4 .

 4 1 depicts the characteristics of the discussed architectures by indicating the location of the various modules of the game engine and the used mechanisms to communicate and exchange data or commands. , RPC, SOA, MA 2.RMI, RPC, SOA, MA 3.Commands 4.Video Stream 5.Commands, Piracy requests 6.Update positions, AI of NPCs

Figure 4 . 1 :

 41 Figure 4.1: Comparison of gaming architectures

Figure 4 .

 4 2 shows a baseline architecture of a generic game engine with the main module families. Some of the module families of the engine are written by the game creator including:

Figure 4 . 2 :

 42 Figure 4.2: Game engines baseline architecture

Figure A. 1

 1 Figure A.1 in the appendix, describes the graphic pipelines used by Unity 3D (i.e., OpenGL, OpenGL-ES 2.0, WebGL, and DirectX). Each graphic pipelines is represented by different stages along with their interactions. Each pipeline differs by the number of stages and internal flow, but the general idea of rendering remains the same.

Figure 4 .

 4 3 represents a screen-shot of the different games.

Figure 4 . 3 :

 43 Figure 4.3: Screen-shot of the different games

Figure 4 .

 4 Figure 4.4 shows the time (in ms) spent by the CPU to generate one frame for five games on five platforms. The results in Figure 4.4a (Figure 4.4b, respectively) correspond to the good (fast, respectively) quality.Figure 4.5 represents also the time spent by the CPU to generate one frame for Stealth, Space Shooter, Car, Unity Lab, and Multiplayer FPS games on the Dell and mobile devices for the good (Figure 4.5a) and fast (Figure 4.5b) qualities. These results have been split into two figures for readability

Figure 4 . 6 ,Figure 4 . 4 :

 4644 Figure 4.6, which represents the time spent by the CPU to generate one frame for the two web players on the Dell laptop.

Figure 4 . 5 :

 45 Figure 4.5: CPU-time required to generate one frame on the standalone and wearable devices

Figure 4 . 6 :

 46 Figure 4.6: Time required to generate one frame for the Web Players on the Dell M4800

4. 4 .

 4 PERFORMANCE ANALYSIS AND GAME CLASSIFICATIONdepend on the viewport size.

Figure 4 .

 4 Figure 4.7 shows the consumption (in % of CPU) of modules. We considered for each module, the percentage of time it takes to compute in relation to the overall consumption needed to generate one frame. We aggregated all the data corresponding to the nine games, the two qualities on the different devices (except the Dell tower server) into Figure 4.7a. We plotted the three key values: average, minimum, and maximum consumption. For more details, readers may refer to Figures A.2 and A.3 in the appendix.

  Module Consumption (min, avg, max) Relative load variability:r pq -R µ

Figure 4 . 7 :

 47 Figure 4.7: Module resource requirement and relative load variability

Figure 4 . 8 :

 48 Figure 4.8: CPU consumption per modules on Dell M4800 for Web Players

Figure 4 .

 4 Figure 4.9b, we show the percentage of time the GPU spends in each subfamily of the rendering module.

Figure 4 . 9 :

 49 Figure 4.9: GPU consumption per frame and per module on Dell M4800 for Windows 7

and 4 .Figure 4 .

 44 Figure 4.10 ( 4.11a, 4.11b, 4.11c, 4.11d, and 4.12, respectively) corresponds to the Physics module family (Audio, AI, Animator, Script, and Rendering module families, respectively). In each graph, the vertices represent each module in the family, while the oriented edges are a combination of two parameters: the first one is the number of time the source vertex calls the destination vertex (the calls frequency), the second value is the execution time of the destination vertex. These flowcharts correspond to the case of Survival Shooter game on the HTC One (M8) for the good quality encoding.

Figure 4 . 10 :

 410 Figure 4.10: Internal calls inside the Physics module

CHAPTER

Figure 4 . 11 :

 411 Figure 4.11: Internal flow concerning the main modules: Audio, AI, Animations, and Scripting

Figure 4 .

 4 Figure 4.13 depicts the time needed to generate one frame on the three architectures (i.e., client-server, Cloud gaming, and computation offloading) for each of the used games for the good (Figure 4.13a) and

Figure 4 . 13 :

 413 Figure 4.13: CPU-time required to generate one game frame on the three architectures

  are based on real persons, such as sportive and historical persons. FPS games use black characters without any characteristic. (ii) A NPC is controlled by the computer through an AI and triggered by specific actions. A NPC may define an enemy, a partner or a support character, depending on whether the NPC opposes the PC in duels, helps the PC in its adventure or assists the storyline of the game. (iii) Environment represents the virtual static and realistic area where the game takes place. (iv) Lights are a key step to produce a realistic scene. The light sources are simple objects, defined in the world space, which are a combination of color, intensity, direction, focus, and position. (v) Particles are amorphous objects such as smoke clouds and sparks. They are animated in a rich variety of ways that vary in position, orientation, and size from frame to another. (vi) Sound sources are in charge of reproducing 1 https://gafferongames.com/post/physics_in_3d/ 100 5.4. METHODOLOGY what the player would like to hear such as a car engine sound or a background music. (vii) Camera is a

Figure 5 . 1 :

 51 Figure 5.1: Game screenshot

Figure 5 .

 5 Figure 5.2 presents a global view of the proposed architecture. At the beginning, a connection is established between the mobile device and the server via a network manager. This latter is a set of scripts responsible for remotely instantiating GOs, and orchestrating the offloading process.

Figure 5 . 2 :

 52 Figure 5.2: Global overview of the architecture

Figure 5 . 3 :

 53 Figure 5.3: CPU-time consumption per frame and module

Figure 5 . 4 :

 54 Figure 5.4: Packets load per a tick of 1 second interval

Figure 5 .

 5 Figure 5.5a (5.5b, respectively) illustrates the number of packets captured on the uplink and downlink

Figure 5 . 5 :

 55 Figure 5.5: Uplink and downlink packets rate per frame

) 3 .Figure 5 . 6 :

 356 Figure 5.6: Average of interaction Delay Figure 5.6 illustrates the average I D achieved under both the local and remote execution. We observe that: (1) our framework achieves a small U D, at most 3.91 ms (1.62ms, respectively) for fast (good, respectively) quality. This time represents 3 % (0.93%, respectively) of the I D. (2) The P D is 3×

Figure 5 . 7 :

 57 Figure 5.7: CDF for frame generation

Figure 6 . 1 :

 61 Figure 6.1: Bearers with associated QoS parameters

Figure 6 . 2 :

 62 Figure 6.2: (Simplified) MEC architecture

118 6. 2 .

 1182 BACKGROUND AND RELATED WORK a power consumption minimization problem with task buffer stability constraints was formulated. The authors have developed an online algorithm, based on Lyapunov optimization, to derive the optimal CPUcycle frequencies as well as the transmission power and bandwidth allocation vector for computation offloading. Authors in[START_REF] Wang | Joint computation offloading and interference management in wireless cellular networks with mobile edge computing[END_REF] proposed a framework-based computation offloading with interference management oriented to wireless cellular network with MEC. Computation offloading decision, Physical Resource Block (PRB) allocation, and MEC computation resource allocation are jointly addressed in as optimization problems. The offloading decision is made according to the local and offloading overheads experienced by the entire UEs and MEC server, respectively. The PRB allocation problem is based on the offloading decision and it is solved by the well-know graph coloring algorithm in graph theory. A multi-mobile-users MEC system was considered in[START_REF] Zhao | Energy-saving offloading by jointly allocating radio and computational resources for mobile edge computing[END_REF], where multiple UEs request for computation offloading to a MEC server. To optimize the energy consumption, the authors have proposed to joint between optimal offloading selection, radio resource allocation, and computational resource allocation. An integer nonlinear programming model was drawn with the objective function to minimize the energy consumption, subject to latency constraint. To solve the nonlinear model, the authors proposed a reformulation-linearization-technique-based Branch-and-Bound method with an exponential complexity and a Gini coefficient-based greedy heuristic, which has a polynomial complexity. In[START_REF] Liu | Delay-optimal computation task scheduling for mobile-edge computing systems[END_REF], a power-constrained delay minimization problem for computation offloading based on Markov decision processes has been proposed and adapted to the MEC context. The authors have considered a mobile device running computation-intensive and delay-sensitive applications. The device is composed of a task buffer, a transmission unit, and a processing unit. An algorithm has been designed based on the average delay of each task and the average power consumption at the mobile device to solve the powerconstrained delay model and find the optimal scheduling. An energy-latency trade-off for energy-aware offloading in MEC networks was proposed in[START_REF] Zhang | Energy-latency trade-off for energy-aware offloading in mobile edge computing networks[END_REF]. The scheme jointly optimizes communication and computation resource allocation under the limited energy and sensitive latency. The authors have considered the computation offloading in single and multi-cell MEC networks scenarios. The residual energy of UEs' battery was introduced into definition of weighting factors for energy consumption and latency subjectively defined by mobile users. An iterative search algorithm combining interior penalty function method with the D.C. programming (difference of two convex functions/sets) was proposed to

Figure 6 . 4 :

 64 Figure 6.4: Global overview of the proposed framework

Figure 6 .

 6 Figure 6.7 depicts the involved services for the MEACOF. The support service translates the MEA-COF arguments into RNIS and EPS related arguments. These two common services take the argument values translated as inputs by the support services and look up in their internal data bases and output the parameters to the MEC services: Network Status and Configuration as well as IP and Named Data Services. The Network Status and Configuration applies the required QoS parameters to establish a bearer for the computation offloading service between the UE and the server hosted in the MEC. The IP and Named Data Services adds the computation offloading header with specified protocol configuration for the traffic routing performed by EPS. Some KPI requirements are translated into platform services related requirements (such as VM profiles) and through the VIM (OpenStack for example), these services check resource availability for compute, network, and storage.

Figure 6 . 5 :

 65 Figure 6.5: Latency values for 1 packet when eNB using RR scheduling

Figure 6 . 9 :

 69 Figure 6.9: UE framework

Figure 6 . 10 :

 610 Figure 6.10: UE flowchart

1 :

 1 procedure SCC (G (V, E ) , a i n V )

  Energy threashold consumption by the UE to execute the application Uplink data (inputs, code) for the offloaded cluster c i r i Downlink results from the offloaded cluster c i RT TRound trip time (network latency) l iLocality constraint on the cluster c i a. Global-View Model. We consider that the total execution time of the application candidate for computation offloading is split into three parts. The first part is the local execution time related to the execution of the local partition of clusters on the UE. The second part is the remote execution time, which considers the execution cost of the remaining clusters (i.e. the remote partition) on the server.

  -View Model. In the Local-View model, each cluster composing the application is treated

Figure 6 .

 6 Figure 6.11 depicts the architecture of the server framework.

  Gl obal -V i ewLoc al -V i ew

Figure 6 . 12 :

 612 Figure 6.12: Number of offloaded clusters by report to the RTT between the UE and the MEC sever.

Figure 6 . 13 :

 613 Figure 6.13: The execution time by report to the RTT between the UE and the MEC sever.

Figure 6 .

 6 Figure 6.14 depicts the energy consumed by the face recognition application for the three scenarios (i.e., local execution, Global-View algorithm, and Local-View algorithm). Computing the whole application locally consumes 7.564 J . For 10 ms latency, the Global-View (Local-View, respectively) algorithm offers almost 93.4 (90.5, respectively) percent better performance than the local execution. This gain is inversely proportional to latency. Indeed, when latency increases, the number of clusters to offload decreases, in turn decreasing the achieved gain, which depends on the number of clusters to offload. The Global-View algorithm is almost 3 percent better than the Local-View algorithm. From 140 ms latency,

  Gl obal -V i ew Loc al -V i ew Loc al -E xec

Figure 6 . 14 :

 614 Figure 6.14: Energy consumption versus the network latency

s m 2 .�

 2 Remote execution of the partition P 2 . The time to execute the partition P 2 on the remote server includes the time to compute the code on the server � Computation offloading improve the application performance when the execution time of the partition P 2 on the remote server is shorter than the execution time of this partition P 2 on the mobile device. That is to say; T o f f < T m . This introduce the Equation A.1

A. 1 . 2 1 . 2 . 3 P 3 )

 121233 Saving energyEnergy consumption is a main constraint for mobile devices, as it cannot be replenished without external source of energy. Several research works have been proposed to study the energy consumption when A.1. OFFLOADING GAIN STUDY performing computation offloading. In what follows, we propose a general model analysis of the energyrelated offloading consumption. In this description model, we use the example off the application composed on the local and remote partitions P 1 , and P 2 respectively, as described in the section A.Similar to the previous case, computation offloading may improve performance only through remote execution of P 2 . Therefore, we focus on this partition. Local execution of P 2 . The energy consumption is given by: E m = P m × w s m Remote execution of P 2 . The energy consumption is given by: E o f f = P comm × Computation offloading saves the energy consumption on the mobile device when the energy consumption (on the mobile device) of the partition P 2 , when computed remotely is shorter than the energy consumption (on the mobile device) of the same partition P 2 , when computed locally. Mathematically,� E o f f < E m � . This induces Equation A.This equation holds when: w is large, the remote server is powerful (high speed s s ), the uplink (B t ) and downlink (B r ) bandwidth are large and the data size exchanged is small (small d i ).The computation offloading gain G e o f f is given in Equation A.4

•

  Proposer une nouvelle approche pour le délestage de code vers le MEC en déployant une application sur la bordure du réseau (edge) responsable de la décision de délestage au niveau du terminal et proposer deux algorithmes pour prendre la meilleure décision concernant les tâches à distribuer entre le terminal et le serveur hébergé dans le MEC.

	GLOSSARY GLOSSARY	GLOSSARY GLOSSARY
	GPRS General Packet Radio Service MEC Mobile Edge Computing RMI Remote Methods Invocation VSM Virtual Server Manager
	GPS Global Positioning System MIMO Multiple Inputs Multiple Outputs RNIS Radio Network Information Service WAN Wide Area Network
	GPU Graphic Processing Unit MIMD Multiple Instructions Multiple Data RPC Remote Procedure Call Wi-Fi Wireless-Fidelity
	GUI Graphical User Interface MME Mobility Management Entity RPG Role-Playing Game XML Extensible Markup Language
	GVSP GigE Vision Stream Protocol MMOG Massively Multi-player Online Games RTP Real-Time Transport Protocol
	HCI Human Computer Interface MMORPG Massively Multi-player Online Role-Playing Games RTS Real-Time Strategy
	HD High-Definition MMU Memory Management Unit RTT Round Trip Time
	HDR High Dynamic Range MNO Mobile Network Operator RVLG Reduced Valued Locality-Labeled Graph
	HFR High Frame Rate MPTCP Multipath TCP SaaS Software as a Service
	HID Human Interface Device NDK Native Development Kit SCC Strongly Connected Components
	HTTP Hypertext Transfer Protocol NFV Network Function Virtualization SDK Software Development Kit
	IaaS Infrastructure as a Service NIST National Institute of Standards and Technology SDN Software-Defined Networking
	iSCSI internet Small Computer System Interface NPC Non-Player Character SIMD Single Instruction Multiple Data
	InPs Infrastructure Providers ODE Open Dynamics Engine SOA Service Oriented Architecture
	ID Identifier OFDMA Orthogonal Frequency Division Multiplexing SLA Service-Level Agreement
	ILP Integer Linear Programming OOP Oriented-Object Programming SLP Service Location Protocol
	IP Internet Protocol OS Operating System SNR Signal to Noise Ratio
	IQR Inter-Quartile Range OSS Operating Support System SOSGI Single Online Shared Game Instance
	IVE Immersive Virtual Environments PaaS Platform as a Service TCP Transmission Control Protocol
	I/O Inputs/Outputs PC Player Character TPS Third Person Shooter
	IoT Internet of Things PCRF Policy and Charging Resource Function TSP Telecommunication Service Provider
	jSLP java Service Location Protocol PDA Personal Digital Assistant TTI Transmission Time Interval
	JDK Java Development Kit PDN Packet Data Network UDDI Universal Description Discovery and Integration
	JVM Java Virtual Machine PLMN ID Public Land Mobile Network Identifier UDP User Datagram Protocol
	KPI Key Performance Indicator PRB Physical Resource Block UE User Equipment
	LAN Local Area Network QAM Quadrature Amplitude Modulation UI User-Interface
	LISP Locator Identifier Separation Protocol QCI QoS Class Identifier UMSC Universal Mobile Service Cell
	LOD Level of Details QoE Quality of Experience UPnP Universal Plug and Play
	LTE Long Term Evolution QoS Quality of Service URL Uniform Resource Locator
	MA Mobile Agents QPSK Quadrature Phase-Shift Keying VIM Virtualization Infrastructure Manager
	MAC Medium Access Control RAN Radio Access Network VLG Valued Locality-Labeled Graph
	MAN Metropolitan Area Network RAM Random Access Memory VM Virtual Machine
	MBR Maximum Bit Rate RB Resource Block VMM Virtual Machine Manager
	MCC Mobile Cloud Computing RBS Remaining Block Signal VOIP Voice over IP
	MDP Markovian Decision Process RIM Research in Motion VPN Virtual Private Network
	ME Mobile Edge RISC Reduced Instruction Set Computer VR Virtual Reality
	iii 3

Table 2 .

 2

1: Offloading type advantages versus disadvantages Type Advantage Disadvantage Static ✓ Simple, ✓ Improve the performance, ✓ No overhead, ✓ No need for monitoring. ✗ Not optimal, ✗ Cannot guarantee the best partitioning, ✗ Total knowledge of the program, ✗ Does not support mobility, ✗ Cannot adapt to changes (absence of monitoring), ✗ Resource consumption are estimated in advance, ✗ Extra efforts to integrate the offloading functionality. Dynamic ✓ May find the optimal solution, ✓ Improve the performance, ✓ Guarantee the best partitioning, ✓ May support mobility, ✓ Flexible and adaptive to dynamic environment, ✓ Offloading functionality not considered in application dev. ✗ Realization complexity, ✗ Total knowledge of the program, ✗ Increase the overhead, ✗ Always delayed with the overhead elapsed time, ✗ Waste local scarce resources (RAM and battery). Hybrid ✓ Reduce the overhead, ✓ Improve the performance, ✓ May support mobility, ✓ Adaptive to available energy on the device. ✗ Realization complexity, ✗ Total knowledge of the program, ✗ Maybe delayed with the overhead elapsed time, ✗ Waste local scarce resources (RAM and battery), directions. Since 2007, mobile users have embraced the concept of smartphones and tablets, which quickly became pervasive and ubiquitous devices. Thus, mobile developers have been motivated to create more and more mobile applications, including graphic rendering, face and speech recognition, mobile gaming, AR, and Virtual Reality (VR). These applications are CPU/GPU-intensive and energy consuming, which has resulted in more interest in and scope to computation offloading. Since 2015, computation offloading has gained even more ground, particularly with the emergence of MEC, FOG computing, and 5G, which allow real-time applications, such as interactive and gaming based-computation offloading. Load Sharing. This work is considered the earliest research; it was first proposed in 1998 by Othman

  PRINCIPALSto the edge network. It is gaining a lot of industry support, particularly from Cisco5 . Fog is a highly virtualized platform, which provides a wide range of applications and services in highly distributed deployments, such as gaming, video streaming, augmented reality, and virtual reality. It offers low latency communication, which allows real-time delivery of data for delay-sensitive and health-care services. On the other hand, MEC has the same objective, but mainly targets 3 r d Generation Partnership Project (3GPP)-based mobile networks. MEC provides IT and computing capabilities within the Radio Access Network (RAN) in the close vicinity to mobile devices. It is heavily promoted by the European Telecommunications Standards Institute (ETSI), which is trying to develop a standard around MEC[START_REF] Etsi | Mobile edge computing (mec); framework and reference architecture[END_REF],

	Isolation and protection have
	motivated research on developing infrastructures for offloading at various granularity levels. Offloading
	may be performed at a method level, task level, application level, or Virtual Machine (VM) level.
	Chapter 3 is dedicated to computation offloading.

Edge-Based Computation Offloading. The last two years have characterized the emergence of Fog and MEC. Fog is an extension of Cloud computing, bringing network resources from the core network 20

2.2.

Table 2 . 2 :

 22 Features of offloading approaches

	Approach	Communication	Latency	Migration	Partitioning	Cost	Complexity	QoE	Mobility	Security
	Load Sharing	Client-server (C/S)	High	Full job	No	High Medium Bad	No	NA
	Remote Execution	C/S	High	Full, Partial	Static	Low	Low	Bad	No	NA
	Cyber Foraging	C/S, P2P	Short	Full, Partial	Dynamic	High	High	Medium No	No
	Computation Offloading	C/S, P2P, AdHoc	Depends on server location	Full, Partial, VM Migration	Static, Dynamic, Hybrid High	High	Good	Yes	Cloud
	Edge-Oriented Offloading	C/S	Short	Full, Parital, VM Migration	Static, Dynamic	High	High	Good	Yes	Yes

Table 3

 3

	.1: Comparison between mono-, bi-, and multi-objective optimization-based frameworks
	Framework	Type	Optimization Objectives	Latency	QoS Support	Overhead	Scalability	Annotations	Energy Consmp.	Operational Cost
	CloneCloud [50]	Mono-Objective	Execution Cost		NA		✗	✗
	CODM [287]	Mono-Objective	Optimize Deployment		✓		✗	✓
	MAUI [59]	Mono-Objective	Optimize Energy Consmp.		✗		✗	✓
	Yang et al. [312]	Mono-Objective	Optimize Throughput	✗	✗		✓	✓
	AIOLOS [285]	Bi-Objective	�Reduce Latency, �Minimize Energy		NA NA ✓	NA
	AIDE [95]	Multi-Objective	�Min. Bandwidth, �Min. Network Communication, �Min. Memory		NA		NA ✓	NA
	Elastic Application [322]	Multi-Objective	�Min. Energy, �Max. Throughput, �Min. Monetary Cost		✓		✓	✓
	MACS [144]	Multi-Objective	�Min. Energy, �Max. Security, �Min. Exec. Cost		✗		✗	✓
	Adaptive (k+1) [217]	Multi-Objective	�Min. Bandwidth, �Min. Memory, �Min. Exec. Cost	NA ✗		✓	✓	NA

  Central Processing Unit (CPU)/Graphic Processing Unit (GPU). Multi-core processors with a high clock speed are being proposed. For instance, ARM industry developed microprocessor cores with high performances, power and cost requirements, such as Cortex-A. Cortex A7, A9, and A15 execute 32-bit instructions while Cortex A53, A57, and A72 process 64-bit instructions4 . These processors offer better performances, at the expense of energy 5 . Nvidia's Tegra, Samsung's Exynos,

3.3. COMPUTATION OFFLOADING TAXONOMY: FROM THE MOBILE DEVICE PERSPECTIVE

offloading.

3.3.3 Capabilities

Mobile devices have achieved great development in terms of capabilities (i.e., hardware resources) during the past decade.

1.

Apple's A8, and Qualcomm's Snapdragon are few of chips in the industry. Regarding GPU, mobile devices have been designed with GPU since 2013. Mali-T604 was the first GPU integrated inside Samsung Chromebook and the Google Nexus 10 6 . PowerVR, Tegra, and Adreno are other GPUs developed by Imagination Technologies, Nvidia, and Qualcomm, respectively.

Table 3 . 2 :

 32 Applications with programming language used in computation offloading arena

	Framework	Description	Application	Language
	Siri	Apple's commercial framework which relies on the Cloud to get things done	Speech recogn	Objective C
	MAUI [59]	Leveraging the Cloud to enhance dynamic offloading of methods	� Games � Face recogn	.Net
	VM-based Cloudlet [99]	Uses VM-based Cloudlets with a delivery approach for hostile environment	OpenCV	C++
	CloneCloud [50]	Dynamic offloading of threads from mobile devices to VM clone in Cloud	� Virus scan � Image search	Java
	ThinkAir [139]	Offloads methods at runtime to a VM clone in the Cloud	N-Queens puzzle	Java
	Scavenger [147]	Offloads tasks to surrogates based on dual scheduling profiles	Image decorator	Python
	Spectra [82]

  Computation Offloading Taxonomy: from Network Perspective

	Types	Metrics	Support	Model
	Wired	Delay	RPC	Client-Server
	Wireless	Bandwidth	RMI	Peer-to-Peer
		Energy	.Net Remoting
		Packet Loss	Migration VM
		Acuracy	Code Migration
		Fault Tolerance	Proxy
		Scalability	Mobile Agents
		Packet Delivery	SOA

Table 3 . 3 :

 33 Server types characteristics' comparison

	Characteristic	Cloud	Surrogates	Cloudlets	Fog	MEC	Ad-Hoc	Hybrid
	Communication	3G/4G/5G/WiFi	3G/4G/5G/WiFi	3G/4G/5G/WiFi	3G/4G/5G/WiFi	3G/4G/5G/WiFi	3G/4G/5G/WiFi	3G/4G/5G/WiFi
	Bandwidth	Moderate	High	Moderate	High	High	High	Moderate
	Latency	High	Low	Low	Low	Low	Low	Moderate
	Architecture	Distributed	Distributed	Distributed	Distributed	Distributed	Distributed	Distributed
	Capabilities	High	Medium	Medium	Medium	Medium	Low	High
	Flexibility	High	Medium	Low	Medium	Medium	High	High
	Availability	High	Medium	Low	Medium	Medium	Medium	High
	Scalability	High	Medium	Low	High	Medium	Medium	High
	Cost	Pay-As-You-Use	Pay-As-You-Use	Pay-As-You-Use	Pay-As-You-Use	Pay-As-You-Use	Credit / Reward	Infra. Dependent
	Heterogeneity	High	Medium	High	High	Low	High	High
	Security	High	Moderate	Low	Moderate	Moderate	Low	High

Table 3 . 4 :

 34 Framework comparison according to server type

	Framework	Description	Server	CPU Augmentation	Battery Prolonging	RAM Extension	Overhead	Security	Responsiveness	Complexity
	VEE [116]

3 .

 3 Mirroring. A mirror server is a configured server that hosts multiple VM templates with default settings to serve a large number of mobile users. Mirroring offers three services: file scanning, file caching, and computation offloading. Computation offloading induces a high overhead due to the VM cloning, migrating, and configuring on the mirror server. Zhao et al.[START_REF] Zhao | Mirroring smartphones for good: A feasibility study[END_REF] devised and tested a framework, Mirror Server, employing Telecommunication Service Provider (TSP)-based remote services. The framework provides a lightweight protocol for accessing remote services on the mirror server and uses an optimized mechanism to download and offload applications. Mirroring offers high scalability, but limited services and low security, as TSP mirror servers are not designed for data processing in the way that Cloud is. 4. Pre-installation. Installing software packages or complete application on remote servers before running the application improves the application performance. Since the application and packages are already installed on remote servers, initiation, preparation, and migration delays are avoided.

Table 3 . 5 :

 35 Comparison between the framework locations

	Location	Advantage	Disadvantage
	Mobile device	✓ Saves bandwidth by keeping the profiling data locally, ✓ Accepts mobility, ✓ Hosts all modules locally, hence no consistency issue.	✗ Involves local resources consumption, ✗ Needs a long time to make a decision.
		✓ Saves local computing resources,
	Remote server	✓ Saves energy as decision making is done by the server, ✓ Reduces memory occupation through profiling transfer.

Table 3 . 6 :

 36 Comparison of data availability locationCreates data consistency issues between the three entities, ✗ Forwards date to the server, ✗ Consumes bandwidth to save data and to forward them to the server, ✗ Induces network latency due to data forwarding, ✗ Security issues: �Attacker can eavesdrop on the network, �Attacker can change the data state.

	Approach	Advantage	Disadvantage
			✗ Induces a local overhead due to the profile step,
	On Mobile device	✓ It keeps monitoring information, ✓ Does not consume bandwidth for profiling transfer.	✗ Needs additional resource consumption, ✗ Needs to transfer code and inputs to server, ✗ Consumes bandwidth and increases the execution time.
	On remote server	✓ Does not need profiling on mobile device, ✓ Does not waste resources for profiling, ✓ No latency or transfer for remote code.	✗ May make an incorrect decision as profiling is based on predictions, ✗ Does not support user mobility due to the pre-installation of tasks.
			✗
		✓ Keeps history of different executions,
	On third-party machine	✓ Does not waste resources, ✓ Supports user mobility,

Table 3 . 7 :

 37 Comparison of service discovery mechanismsIt is an open-source Java program. It uses a similar strategy to SLP, but has additional functionality. Services register their attributes with at least one lookup service. The service is contacted later by the Jini client. The lookup service store both service information and the proxy responsible for code execution, locally or remotely.✓ Services are recognized automatically, ✓ Services are available to everyone, ✓ Supports a flexible network, ✓ An open-source program, ✗ May incur large overheads, ✗ Needs a reliable, stream-oriented transport protocol (e.g., TCP), and multicast support. ✗ Not attractive in a wireless ubiquitous environment, ✗ Vulnerable due to the single point of contact.

	Mechanism	Description	Advantages versus Disadvantages	Network type	Multicast	Broadcast	Approach
			✓ Fast search,
	Service Location Pro-tocol [282]	An IETF protocol, centralized and proactive. It includes a mobile agent (a centralized service repository), which is used by a service agent and a user agent, respectively, to register and locate required services.	✓ Discovering services on a various range of networks, ✓ Supports a large number of nodes, ✓ Uses caching, authentication, and scoping. ✗ Centralized, ✗ Has a single point of failure,	Fixed	Yes	No	Centralized
			✗ Vulneriable to DoS attacks.
	Jini [13]			Fixed	Yes	No	Centralized
	IBM's
	Salutation
	Protocol

Table 3 . 8 :

 38 Granularity advantages versus disadvantages

	Strategy	Advantage	versus	Disadvantages

  axC ap is the estimated time at which the t cor e will exceed the maximum reserved CPU capacity t M axC ap per cycle period t p . This time represents the intersection between the regression linear line and the horizontal t M axC ap line. t xM axC ap is computed as follows: t xM axC ap =

	(3.25)	axC ap t p	�	× t p ≤	� t mob T p	�	× t p
	where t xM

t M axC ap -b m

  Khronos-developed graphic library. It is the most used API in industry. It is developed to launch a large number of applications on different computer platforms, such as gaming,

	manufacturing, medical, VR, content creation, and Dynamic Audio-Visual Communication (DAC).
	• OpenGL ES is a fork of OpenGL. It has been developed for embedded systems, including smart
	phones, consoles, appliances, and vehicles.
	• WebGL is a free low-level 3D graphics API based on OpenGL ES 2.0. It is integrated to HTML5 as
	Document Object Model interfaces. Major browsers (such as Safari, Chrome, Firefox, and Opera)
	implement this pipeline as a 3D plugin.
	• Direct 3D is a Microsoft's 3D graphics low-level API. It is used to draw lines, triangles, and points
	or to launch parallel processing on the GPU. It is the primary competitor of OpenGL. It is used on
	Microsoft platforms (Xbox 360, Xbox One, and the Windows operating system platforms).

• OpenGL is a

Table 4 . 1 :

 41 Main characteristics of the used platforms

	Platform	Target	CPU	GPU	RAM	Pipeline
	Windows 7 Pro					D3D11
	Ubuntu 14.04 Mozilla Firefox 44.0.2	Dell Precision M4800	Intel Core i7, 2.8GHz	Nvidia Quadro k2100M, 2GB	16GB	OpenGL WebGL
	Opera 35.0.2066.37					WebGL
	Windows 10	Microsoft Surface Pro	Intel Core i5 -3317U, 1.7GHz	Intel HD 4000	4GB	D3D11
	Android 4.4.2	HTC one (M8)	Quad-Core 801 Snapdragon, 2.3GHz	Adreno 330	2GB	OpenGL ES 2.0
	Android 5.1.1 Lollipop	Samsung Galaxy S6 edge	Octa-Core Exynos 7420 -2.1 GHz	ARM Mali T760	3GB	OpenGL ES 2.0
	Windows 8.1 Pro	Dell PC tower	Intel Core i7, 3.4 GHz	3x NVIDIA GeForce GTX 780 Ti, 3GB	16GB	D3D11

Table 4 . 2 :

 42 Main characteristics of the tested games

	Games	# of players	Dimension	Type	Rendering	Physics	Scripts
	Viking Village 8	1 player	3D	FPS	++++	+	+++
	Tower Bridge 9	1 player	2D	TPS	+	+++	+
	Stealth 10	1 player	3D	TPS	+++	+++	+++
	Survival Shooter 11	1 player	3D	TPS	++	++	++
	Tanks 12	2 players	2D	MMOG	+	++	++
	Space Shooter 13	1 player	2D	TPS	++	+	++
	Car 14	1 player	3D	Racing	++	++	+++
	Unity Lab 15	1 player	3D	TPS	++++	+++	+++
	Multiplayer Shooter 16	multiplayer	3D	MMOG-FPS	+++	+++	+++

Table 4 . 3 :

 43 Good quality versus fast quality

		Quality Settings	Good Quality	Fast Quality
		Resolution	Full-screen	Full-screen
		Pixel Light Count	4	0
		Texture Quality	Full Res	Eighth Res
	Rendering	Anisotropic Textures Anti Aliasing	Per Texture 4x Multi Sampling	Disabled Disabled
		Soft Particles	Activated	Disabled
		Realtime Reflection	Activated	Disabled
		Billboards Face Camera Position Probes	Activated	Disabled
		Shadows	Hard Shadows Only	Disable Shadows
		Shadow Resolution	Medium Resolution	Low Resolution
		Shadow Projection	Stable Fit	Stable Fit
		Shadow Distance	50	15
	Shadows	Shadow Near Plane Offset Shadow Cascades	2 Two Cascades	2 No Cascades
		Cascade Splits	(33,3%, 66.7% )	0
		Blend Weights	2 Bones	1 Bone
		V Sync Count	Every V Blank	Don't Sync
	Others	Lod Bias Maximum LOD Level	1 0	0.3 0
		Particle Raycast Budget	256	4

  PERFORMANCE ANALYSIS AND GAME CLASSIFICATIONbecause the time needed to generate one frame for the Stealth and the Multiplayer FPS games, on the mobile devices, is one order of magnitude larger than for the other games. Moreover, Car, Unity Lab, and Multiplayer FPS have not been tested on all devices and platforms. The same remark applies for

17 http://blogs.msdn.com/b/visualstudioalm/archive/2015/07/20/performance-and-diagnostic-tools-in-visualaspx 18 http://www.dependencywalker.com/ 82 4.4.

Table 4 . 4 :

 44 Best option for architecture implementation per game and device

	Games	Dell M4800	Surface Pro	HTC M8	Galaxy S6 Edge	Browsers
	Viking Village	Offload	Offload	Offload	Offload	Offload
	Tower Bridge	Client-server	Client-server	Client-server	Client-server	Client-server
	Stealth	Offload	Offload	Offload	Offload	Offload
	Survival Shooter	Client-server	Client-server	Cloud	Cloud	Client-server
	Tanks	Client-server	Client-server	Client-server	Client-server	Client-server
	Space Shooter	Client-server	Client-server	Client-server	Client-server	Client-server
	Car	Client-server	Client-server	Cloud	Cloud	Client-server
	Unity Lab	Offload	Offload	Offload	Offload	Offload
	Multiplayer	Cloud	Offload	Offload	Offload	Cloud

  CHAPTER 4. PERFORMANCE ANALYSIS OF GAME ENGINES ON MOBILE AND FIXED DEVICES

							0 1			0 2
	UpdateCloth DoneLaserSwitchDeactivation 2.88 0	TriggerStays 2.88 0 0 2.88	OnTriggerStay	0 1 0.040 2.88 DoneEnemySight 0 2.88 ProcessReport 2.88 0 2.88 0 0 2.88 2.88 Contacts 0 0 2.88 0 2.88	0.040 2.88 2.88 0 solveStep 0 2.88 JointBreaks DoneLaserPlayerDetection 0.016 2.88	Physics3D TriggerEnterExits 0.016 2.88 BPWorkTask	1.410 2.88 0.172 2.88 0.001 2 0.395 2.88 UpdateBodies Interpolation Completion Task postNarrowPhase 0.02 1.25 0.071 2.11 0.00023 1.68 2.10 0.932 2.88 FetchResults AggrOverlapTask 0.061 1.56 0.121	Processing PhysX SapPostUpdWorkTask 0.5 1 0.03 2.78	Physics Simulate 1.48 PxsSolverStartTask 0.04 1.44 0.022 UpdCCDSinglePass 0.021 1.60 0.075 1.55 0.042 UpdateTransform UpdCCDMultiplePass 1.50	0.0236 2.88 DynamicUpdate postBroadPhase 2.88 0.0236	0.001 1 0.00013 2.88 MovementState 0 1 PostCCDPass 0.00013 2.88	0 1	Physics2D 0.074 2.88 0.011 2.88 0.00013 2.88 FixedUpdate	0.011 2.88	0.0005 0.053 2.88 2.88 Callbacks 0.053 2.88 0.0005 2.88	ContactReporting	EffectorFixedUpdate

  4. PERFORMANCE ANALYSIS OF GAME ENGINES ON MOBILE AND FIXED DEVICES Internal calls inside the Animator module

				Audio				AI
		0.096 1	AudioManager 1 0.6	0.043 10.46 0.0345 10.46	BehaviourUpdate 1 0.6 10.46 1.284	1 0.117	1 0.0025	0.0006 1
					EnemyAttack EnemyHealth EnemyMovement EventSystem GameOverManager PauseManager
		Update	4.52 0.018	FixedUpdate AudioSource 0.116 2.88	0.043 10.46	0.0345 10.46	1.284 10.46	Update	0.117 1	0.0025 1	0.0006 1
		(a) Internal calls inside the Audio module	(b) Internal calls inside the AI module
				Animator
				0.617
	Apply Ani-mator Move	Update FK and State Ma-chine Job and Schedul-ing 2 1 0.352 Fire An-imation Events and Be-haviours 1 0.053 Dirty Scene Objects 0.016 1 0.018 1 0.170 1 (c) Scripts Prepare For 1 st Pass Prepare For 2 nd Pass Write Ani-mated Values Job Schedul-ing Waiting For Job Evaluate Anima-tion Clip Write Ani-mated Values 0.010 1 0.001 1 0.120 1 0.041 1 0.147 7.35 0.0284 6.35 BehaviourUpdate performscript PlayerHealth PlayerShooting ScoreManager FixedUpdate PlayerMovement Update LogStringToConsole Physics StackTraceUtility Raycast ExtractStackTrace PostProcessStackTrace 1.63 1 10.056 1 3.66 2.87 1.194 102 0.0025 1 0.104 1 0.014 1 0.7 1 1.194 102 0.0025 1 1 3.756 2.642 6.16 1.2 3.08 1.242 3.08 0.161 3.02 0.043 1 0.7 1 0.104 3.08 0.7 0.014 1 1

(d) Internal calls inside the Scripting module

Table 4 . 5 :

 45 4.6. GAME PERFORMANCE WHEN ASSISTED BY SERVER. Location of the game objects in case of computation offloading

									Rendering
			CameraRender				BehaviorUpdate	Overhead	Physics	Audio	Network	Other
	AnimatorUpdate					Drawing			TextRender	LightManagement
			Culling		RenderPrepare	RenderSkybox	Geometries
	SceneCulling	LevelofDetails	ImageEffects				DirectionalLight	RenderForward	RenderDeferred
			GraphicsBlit		GraphicsDraw	ParticleSystems	ReflectionProbes	ShadowsCollect	ShadowsMap	GUIRepaint	CanvasOverlays
	WaitingForJob	TerrainModule					ShaderSetPass	MeshRender	BatchDynamic
	CullVisibleUmbra	CullLight	EvalAnim	EvalStatemachine	WriteAnimValues	RenderTexture	MeshVBOModule
	JobAllocGrow	FindShadowModule	LightModule			ShadowCulling
					Element			Module	Client	Server
									Rendering
									Audio
					Player character			Animations Scripting
									Physics
									Inputs

ShadowCasterPass

Figure 4.12: Internal calls inside the Rendering module

  10 t h and 90 t h percentiles are so close that they nearly overlap. It is notably the case of Tanks and Space Shooter. A game offering a small variability features scenes that are not complex and are thus easily rendered by the GPU. For the good quality, a frame is generated in less then 33 ms and in less then 16 ms for the fast quality. These games are device-friendly.Some other games exhibit a high variability, notably Viking Village, Stealth, and Unity Lab. These are the worst cases for Cloud provider, which has to reserve resources to accommodate the peaks (more than 75 ms CPU for Viking Village, 65 ms for Stealth, and 67 ms for Unity Lab), although the median frame requires almost quarter the time (16ms here). The reserved resources are wasted. These games in general are the most consuming for the CPU and GPU resources due to the scene complexity. Since these games are not desirable for Cloud gaming architectures, and cannot be played locally on the wearable devices, then these games should be offloaded.Finally, the games that are the less demanding and have less variability, typically Car in our set of games, are good candidates for Cloud gaming systems.

Table 5 . 1 :

 51 Game characteristics

	# of players	Dimension	Type	Rendering	Physics	Scripts
	Multiplayer	3D	FPS	++++	+++	+++

Table 5 . 2 :

 52 Platforms characteristics

	Platform	CPU	GPU	RAM	OS
	HTC one (M8)	Quad-Core 801 Snapdragon, 2.3GHz	Adreno 330	2GB	Android 4.4.2
	Dell PC tower	Intel Core i7, 3.4 GHz	3x NVIDIA GeForce	16GB	Windows
			GTX 780 Ti, 3GB		8.1 Pro

  CHAPTER 6. MEC ORIENTED COMPUTATION OFFLOADING size of a packet depends on the used Codec for the voice. If we consider an Adaptive Multi Rate-Wide Band Codec (AMR-12.65), every 20 ms are generated 253 bi t s. To deliver a voice sample to a UE, we need to add other protocol headers such as Real-Time Transport Protocol (RTP) header (typically 12 b y t es), a UDP header (8by t es), and an IP header (40by t es). Hence, the entire VoLTE packet length is equal to 733 bi t s generated every 20 ms. For a UDP packet is about 1024 b y t es (8by t es for UDP header, 40 b y t es for IP header, and 976 b y t es for the payload). We are interested here into the number of radio resources needed to transmit in the air for the VoLTE call and the UDP packets. In LTE, a RB is composed of 12 × 7 resource elements (REs) (for a normal Cyclic Prefix). Based on the LTE downlink modulation, a RE carries respectively, 2, 4 or 6 bi t s for Quadrature Phase-Shift Keying (QPSK),[START_REF] Tham | Energy-efficient mapping and scheduling of task interaction graphs for code offloading in mobile cloud computing[END_REF] Quadrature Amplitude Modulation (QAM), and 64 QAM modulation scheme. The modulation scheme is chosen by the eNodeB with the respect to UE CQI. For example, a UE using CQI #15 (i.e., good channel condition), the eNodeB can use a modulation of 64 QAM. Therefore, each RE holds 6 bi t s. Accordingly, a RB can carry 168 × 6 = 504 bi t s. When the Robust Header Compression (RoHC) method is used for the VoLTE call, the VoLTE packet is compacted in 300 bi t s. Knowing that a RB is the smallest resource allocated per UE by the eNodeB, the VoLTE call needs one RB, while the UDP packets needs sixteen RBs. When the bandwidth cannot carries the entire RBs needed for a packet, the latter is fragmented into several frames, and when the eNodeB is larger than the packet size, padding information is added to the packet. Figure6.6 summarizes the number of RB (in bytes) needed to transmit one UPD packet, for different bandwidth capacities.

		9,500										9,500										9,500										9,500
		8,500 9,000							549 B y t es	9,000 8,500							2292 B y t es	9,000 8,500							4578 B y t es	9,000 8,500							9422 B y t es
		7,500 8,000							277 B y t es	7,500 8,000							1095 B y t es	7,500 8,000							2292 B y t es	7,500 8,000							4587 B y t es
	y t es) RBs size(B	2,500 3,000 3,500 4,000 4,500 5,000 5,500 6,000 6,500 7,000										6,000 6,500 7,000 3,500 4,000 4,500 5,000 5,500 2,500 3,000							549 B y t es 373 B y t es 277 B y t es		6,000 6,500 7,000 3,500 4,000 4,500 5,000 5,500 2,500 3,000							1095 B y t es 749 B y t es 469 B y t es 373 B y t es 277 B y t es	6,000 6,500 7,000 3,500 4,000 4,500 5,000 5,500 2,500 3,000							2292 B y t es 1479 B y t es 1095 B y t es 935 B y t es 749 B y t es 645 B y t es
		2,000										2,000										2,000										2,000							549 B y t es
		1,000 1,500										1,000 1,500										1,000 1,500										1,000 1,500							469 B y t es
		500										500										500										500
		1 2	4	6	8	10	12	14	16	18	20	1 2	4	6	8	10	12	14	16	18	20	1 2	4	6	8	10	12	14	16	18	20	1 2	4	6	8	10	12	14	16	18	20
					Number of UEs (#)							Number of UEs (#)							Number of UEs (#)							Number of UEs (#)
		(a) Bandwidth = 1.4 M H z		(b) Bandwidth = 5 M H z		(c) Bandwidth = 10 M H z		(d) Bandwidth = 20 M H z
											Figure 6.6: RBs size (in Bytes) for 1 UL RR scheduling

via two examples: Voice over LTE (VoLTE) call packet, and a UDP packet. In case of VoLTE call, the

[START_REF] Junior | Supporting mobility-aware computational offloading in mobile cloud environment[END_REF]

  3. Network conditions. From the RNIS and EPS API, the ME application knows the number of active UEs in the cell, the UE bearer type and the CQI of the UE. Obviously, if the UE's CQI is bad, then it is better to execute the code locally as UE packets may experience high delays (due to the low modulation throughput), which may degrade the QoE and the QoS. Furthermore, form the EPS API, the ME application identifies which UEs are using GBR and Non-GBR bearers. if the UE is using a non-GBR bearer and the number of active UE is high, then the offloading request is rejected. Even if the UE has a dedicated bearer, the ME application should check the associated QCI in order to evaluate the packet delay budget allowed to this bearer.If the ME application estimates that the channel conditions are good or the UE has a dedicated bearer that guarantees low delay access and there is sufficient resources on the MEC, the UE is authorized to offload. The decision along with the remote IP address and an RTT approximation (i.e., if the offload is accepted) are included in the response of the ME application to UE. The initial RTT value could be the packet delay budget associated with the UE bearer type (i.e., maximum tolerated latency). Then periodically, the ME application will further approximate the RTT according to the RNIS information and provide it to the UE.

							ME APP		Arguments
									1	Quality (GBR, MBR, Loss Rate, Priority)
									2	Protocol Configuration (IP, Named service)
							Offloading
									3	IT resources
			Infra. Services			Support Services		MEC Service
								Common Service	IP and Named
			Compute			RNIS			Data Services
	ID 1 2 3	vCPU	vGPU	OS	Element eNB List UE List	Network element/UE database ID Configuration Cell ID, TAI, ECGI Geo-region, eNB capability, Connected MME/GW C-RNTI, GUTI, S-TMSI Connected eNB, UE category, UE capability	Parameter	1 3 2	Target bearer Operate period Protocol configuration
										4	Network element
			Storage						5	Target user
	RAM 1	DISC	Cache	EPS	QoS parameter database
	2 3		Network			QCI 1 2 3 4 5 6	Bearer GBR GBR GBR GBR Non-GBR Non-GBR	Delay 100 ms 150 ms 50 ms 300 ms 100 ms 300 ms	Loss 10 -2 10 -3 10 -3 10 -6 10 -6 10 -6	Parameter	1	Network Status and configuration Target bearer
	#NIC 1 2		ID		Queue	7 8 9	Non-GBR Non-GBR Non-GBR	100 ms 300 ms 300 ms	10 -3 10 -6 10 -6	2	Applied policy & config. (QCI, ARP, MBR, GBR)
	3							QCI mapping table	3	Network element
										4	Target user
							priority	ARP	Compatibility	Vulunability
							High	1 ∼ H	Yes	No
							Medium Low	H + 1 ∼ M M + 1 ∼ 15	No No	Yes Yes
								ARP mapping table
				Figure 6.7: ME application (interconnection with the different services)
									1. ME App receives
								Offloading-request form a UE
									2. ME App Calculates	Obtain BSR
									an RTT approximation	Compute RTT
										Support Service	RNIS EPS
										Compute
								3. ME App Checks Network con-ditions and resource availability	Infra Service	Storage
										Network
										MEC Service	IP & Named Data serv. Net.Status & conf.
								NO	Decision	YES
							Send NOK	Send OK with RTT value, @IP server
							Figure 6.8: ME application flowchart

  w) ; Global-View and Local-View. In the Global-View model, we focus on the optimal solution.

	9:	end
	10:	j ++ ;
	11:	end
	12:	end
	13:	end
	2. Partitioning. Regarding the decision algorithm (i.e., offload a cluster or not), we propose two
	different models;

  6.3. PROPOSED FRAMEWORK latency (overhead) of the model resolution to consider in the response time. In the Local-View model, we try to minimize this overhead by proposing a more simple but efficient heuristic solution. Both algorithms take as inputs the reduced version of the graph, the wireless network characteristics (bandwidth and RTT) and the available resources on the UE (energy and computing resources), and return as output the local and remote partitions. For the convenience of presentation, we use the parameters listed in Table A.1 to describe the two models hereafter.

Table 6 . 1 :

 61 List of used parameters

	Variable	Description
	T i	Time Execution of the i t h cluster on the UE
	E cpu	Energy consumption on the UE to compte the local partition
	E ni c

  RESULTSeNodeB using four bandwidth capacities namely; 1.4 M H z, 5 M H z, 10 M H z, and 20 M H z, then we simulate a communication between these UEs and the eNodeB simultaneously, using UDP packets with 1024 b y t es each one. Table6.2 lists all Lena network parameters we used in the simulation.

8 http://valgrind.org/ 9 https://software.intel.com/en-us/intel-vtune-amplifier-xe 10 https://profiler-and-tracer.com/ 11 https://www.nsnam.org/ 12 http://networks.cttc.es/mobile-networks/software-tools/lena/ 134 6.4.

Table 6 . 2 :

 62 Communication simulation parametersTo evaluate the offloading performance of the proposed framework, we developed a testbed composed of a MEC server and a UE performing computation offloading of a face recognition application application (OpenBr13 ). The MEC server is Dell M4800 laptop, powered by an Intel Core i7 processor (clocked at 2.8Ghz) running Ubuntu 14.04, also including an Nvidia Quadro K2100M GPU card with 2GB memory. The UE is emulated by a VM running Ubuntu 14.04. The MEC server is 8× faster than the UE.

	Parameter	Value
	eNB TxPower	30 d B m
	N o of eNBs	1
	N o of UEs	1 to 20
	Frequency	1.4 M H z, 5 M H z, 10 M H z, 20 M H z
	eNB Antenna Gain	18 d B m
	UE Antenna Gain	0
	eNB Noise Figure	5 d B
	UE Noise Figure	9 d B
	Resource Blocks per Cell	25
	LTE Scheduler	Round Robin
	Duplex Mode	Frequency Division Duplex
	Maximum Sending Power	10000 mW
	Signal Attenuation Threshold	-110 d B m
	Propagation Model	Free Space Model
	UE TxPower	26 mW
	Path Loss Scenario	URBAN MACROCELL
	Packet Size	1024 B
	Simulation Time	60 s
	Distance UEs to eNB	50 m
	MTU	1500 B
	LTE RLC Max Buffer Size	1, 000, 000 × 1024
	6.4.2 Offloading Performance

  Si les demandes de ressources d'un moteur de jeu ne varient pas beaucoup dans le temps, le fournisseur peut facilement prévoir cette demande et, par conséquent, consolider efficacement le serveur. Cependant, si la demande en ressource du moteur du jeu varie beaucoup, dans ce cas le fournisseur d'infrastructure Cloud devrait réserver des ressources pour accommoder les pics de consommation, qui est une perte de ressources car les pics surviennent rarement. Dans cette logique, le fournisseur d'infrastructure Cloud devrait trouver un compromis entre une forte consolidation et une QoE élevée, en utilisant l'étude proposée dans[190]. b. Dissection du moteur de jeu: les moteurs de jeux, à notre connaissance, ne sont pas étudiés du point de vue d'architecture interne. Les moteurs de jeux sont considérés comme des boîtes noires. En comparaison avec des boxes, telles que la XBox One, les terminaux smartphones et tablettes ne permettent pas d'exécuter des jeux 3D avec une qualité d'encodage assez élevée. Des solutions exploitant une infrastructure à distance, telle que le ''Cloud gaming'' et le délestage de calcul, représentent la prochaine étape vers l'amélioration de l'expérience des jeux. Par conséquent, disséquer, tester, et analyser le comportement d'un moteur de jeu est un pas vers une meilleure compréhension sur la façon de distribuer les moteurs de jeux sur réseau. Cette contribution vise à analyser le comportement des différents types de jeux, tester leur performance, identifier les goulots d'étranglement des ressources, et, surtout, extraire les ''call flows'' internes au jeu. c. Faisabilité de délestage de calcul: Un moteur de jeu est composé d'un ensemble de modules comme le module de physique, de rendu, d'intelligence artificielle, d'animations, etc. Pour chaque module, nous représentons son architecture interne et les interactions entre les blocs composants le module. Cette manière de faire nous facilite l'étude de faisabilité de délestage de calcul pour les jeux vidéo. L'architecture du module de rendu est assez complexe, ce qui rend ardue l'implémentation du délestage de calcul pour ce module. En effet, à travers l'architecture de ce module, les blocs sont rarement indépendants, et les appels sont assez fréquents entre ces blocs générant un besoin important de communications entre le terminal et le serveur, ce qui limite le gain atteignable en termes de performances. Le module de physique peut être réparti en trois sous-familles qui communiquent à travers une classe. Il serait donc relativement simple de distribuer le calcul de ces trois sous-familles sur des entités distinctes. Le module de scripts est le seul module qui interagit directement avec le module de physique. Il serait donc logique de gérer cette famille de modules sur le même ordinateur que les modules de physique. Le module d'audio n'a aucune interaction avec les autres modules principaux et n'interagit qu'avec le thread principal du jeu. Ce module peut ainsi être migré et représenté en tant qu'interface (API) sur une machine distante. La communication entre le client et la machine distante peut se faire soit par des appels à distance comme les RPC ou en streaming. Le Module de l'intelligence artificielle peut être très intensif en calcul. Il est difficile, voire impossible, de simuler le jeu sur des dispositifs à ressources contraintes sans réduire la complexité de ce module. De plus, vu que ce module est, la plupart du temps, indépendant des autres, il peut être déporté dans son ensemble. 2. Délestage de calcul orienté moteur de jeu: sous cet axe, il y a deux contributions [188, 190]. En [190], un le délestage de calcul statique des modules d'un moteur de jeu est proposé. La méthode consiste à décomposer la scène d'un jeu en plusieurs patterns ou objets ; par exemple, l'avatar du joueur, l'avatar de l'ennemi, et l'environnement. Différents critères sont définis, à savoir la consommation en ressources, les contraintes de dépendance au code, la latence réseau et la bande passante. Selon ces critères, chaque objet du jeu est placé soit sur le terminal soit sur le serveur distant. Dans [188], un délestage dynamique des modules du moteur de jeu a été proposé. Cette contribution est une amélioration de notre travail effectué dans [190], où nous avons proposé une heuristique pour planifier le placement des modules en utilisant les mêmes critères. 3. Délestage de calcul orienté MEC: nous avons une contribution sous cet axe [189]. Une des contraintes les plus pertinentes dans une solution de délestage de calcul est la latence réseau entre le terminal et le serveur. En effet, une latence importante limite l'applicabilité des solutions de délestage de calcul aux applications tolérantes aux délais. Pour les applications temps réel (i.e., sensible aux délais) telles que les jeux vidéo, une latence élevée est intolérable et dégrade la qualité perçue par les utilisateurs. Heureusement, avec le MEC et la transition vers la 5G, la latence du réseau sera considérablement réduite. Notre contribution consiste à tirer parti de l'architecture MEC pour prendre en charge le délestage de calcul. Pour cela, nous concevons un Framework chargé de l'orchestration du processus de délestage. Ce Framework est conçu avec trois entités : (i) une application ''mobile edge'' installée sur le MEC host dont le rôle est d'accéder aux API RNIS (Radio Network Information Service) de l'eNodeB et de récupérer des informations liées aux utilisateurs actifs dans la cellule, faire des approximations de latence réseau, et enfin décider en fonction de différentes informations si un utilisateur donné est autorisé à effectuer un délestage de calcul ou non ; (ii) le terminal qui hébergera les fonctionnalités de délestage, on parle ici de profilage, modélisation, partitionnement, et communication ; enfin (iii) le serveur localisé en bordure de réseau d'accès (« edge »), qui aura pour rôle d'exécuter le code délesté depuis le terminal, et lui renvoyer les résultats. 1.2 Organisation du manuscrit Ce manuscrit est organisé en six chapitres, comme suit : Le chapitre 2 introduit le lecteur aux concepts de base du délestage de calcul (ou ''computation offloading'' ) nécessaires à la compréhension des contributions de la thèse. Premièrement, nous identifions les étapes requises pour effectuer un délestage de calcul citées précédemment, à savoir ; le profilage de l'application, sa modélisation mathématique, le partitionnement du modèle, puis la communication entre partitions. Ces étapes clés du délestage, peuvent être faites durant l'exécution de l'application, ce que nous appelons ''délestage dynamique'' ou avant l'exécution, ce qui est connu comme ''délestage statique''. Deuxièmement, nous rappelons l'historique du mécanisme de délestage de calcul et ses évolutions. Nous terminons ce chapitre en présentant les avantages et inconvénients du délestage de calcul. Le chapitre 3 présente, de manière exhaustive et qualitative, l'état de l'art du délestage de calcul pour compléter la compréhension du chapitre précédent. Ce chapitre est donc organisé selon une classification des travaux de recherche en fonction des différents acteurs impliqués dans le processus de délestage de calcul. Ces classes de taxonomie tournent autour de : l'utilisateur, le terminal, le réseau, l'application candidate au délestage de calcul, le serveur, et enfin le framework de délestage. Le chapitre 4 aborde un type d'application temps-réel, à savoir les jeux vidéo. Dans un premier lieu, une dissection des moteurs de jeux est nécessaire à la compréhension de la contribution. De ce fait, le paysage des jeux vidéo et des moteurs de jeux en terme d'architecture, modules, types de jeux et contraintes est étudié et synthétisé dans ce chapitre. Dans un second temps, l'étape de profilage est mise en avant en réalisant une batterie de tests de performances sur neuf types de jeux différents, dans des environnements fixes et mobiles. La consommation en ressource CPU et GPU par frame et par module est utilisée pour définir une stratégie de déploiement du jeu soit sur une architecture traditionnelle type client/serveur, soit une architecture Cloud gaming, ou encore une architecture de délestage de calcul. La stratégie de déploiement est basée sur la variabilité des demandes en ressource CPU/GPU par frame et la jouabilité du jeu. Suite à cela, nous nous sommes intéressés à la faisabilité de l'architecture délestage de calcul pour les jeux vidéo en présentant son apport en termes de ressources CPU/GPU. La dernière partie de ce chapitre traite du délestage statique des jeux et compare les résultats obtenus à ceux de l'architecture client/serveur et Cloud gaming. Le chapitre 5 décrit une architecture de délestage de calcul pour les jeux vidéo. Nous commençons ce chapitre en passant en revue les études antérieures de délestage de calcul orienté moteurs de jeux. Ces travaux de recherche souffrent principalement de la non considération des jeux type 3D ''First Person Shooter (FPS)''. En effet, dans ces travaux, seuls des jeux 2D non-FPS, non complexes, et non gourmands en ressource sont considérés. Les jeux 3D sont plus complexes, demandent beaucoup de ressources CPU/GPU et, plus important encore, les jeux FPS sont des jeux temps réel où les délais d'interaction entre le joueur et sa machine doivent être très courts. Notre approche apporte une solution à ces problèmes. En premier lieu, nous décrivons la représentation d'une scène 3D et les objets/patterns qui y sont utilisés. Ensuite, nous présentons notre solution de délestage de calculs pour les jeux vidéo. Nous proposons une heuristique basée sur les communications réseau pour sélectionner les objets avec les modules associés qui devraient être déportés sur le serveur. Cette approche est testée ensuite, avec la mise en place d'un banc de tests composé d'un smartphone et d'un serveur. Les résultats en termes de consommation CPU/GPU et communications réseau sont présentés montrant un grand potentiel vers une amélioration des performances et la qualité d'expérience utilisateur. Le chapitre 6 se concentre principalement sur le MEC. Nous avons vu à travers les chapitres précédents que la latence est primordiale dans les solutions de délestage de calcul, en particulier pour les applications temps réel. Pour éviter cette contrainte, nous proposons de rapprocher les serveurs qui doivent heberger les moteurs de jeux ou tout type d'applications candidate au délestage de calcul, de l'utilisateur final. En particulier, nous utilisons le MEC pour effectuer le délestage de calcul. Ce chapitre commence donc par présenter le MEC, son architecture, et décrivant les termes techniques utilisés à travers ce chapitre, en particulier ceux liés au MEC et aux réseaux LTE. Ensuite, nous passons en revue l'état de l'art des solutions de délestage orientées MEC. Suite à cela, nous proposons un framework qui s'appuie sur le MEC, ses services et API pour aider dans la prise de décision. Le framework est composé de trois entités: deux middlewares, l'un sur le terminal et l'autre sur le serveur MEC, et une application ''mobile edge'', responsable de la prise de décision de délestage de calcul. Le framework est ensuite testé dans un cas d'utilisation de reconnaissance faciale. Enfin, le chapitre 7 traite de la conclusion finale, il synthétise les résultats obtenus à travers la thèse et présente des perspectives d'évolution concernant la sécurité, la mobilité, le placement des tâches, et enfin une description d'un modèle de ''Computation Offloading as a Service (COFFaaS)'' dans un contexte 5G.

https://www.arm.com/products/processors

http://www.samsung.com/semiconductor/minisite/exynos/

https://www.qualcomm.com/products/mobile-processors

2.2. PRINCIPALS

Local latency induced in the computation of the offloading steps.

https://www.vmware.com/

https://www.openstack.org/

https://www.docker.com/what-docker

https://developer.cisco.com/site/iox

http://www.etsi.org/technologies-clusters/technologies/multi-access-edge-computing

3.2. COMPUTATION OFFLOADING TAXONOMY: FROM THE USER PERSPECTIVE

A module system and service platform enabling runtime deployment of application components, called bundles, implemented in Java.

http://archive.openflow.org/

http://occi-wg.org/

http://www.arm.com/products/processors/

http://www.arm.com/products/processors/cortex-a/

http://malideveloper.arm.com/

3.4. COMPUTATION OFFLOADING TAXONOMY: FROM THE APPLICATION PERSPECTIVE

https://www.osgi.org/

Real-time application incorporating a large American English vocabulary with pronunciation dictionary.

Synthetic program which uses sftp to transfer a 2GB size file

The Postmark benchmark with a NFS mounted working directory

http://jade.tilab.com

The IaaS is provisioned for single organization.

The IaaS is provisioned for an open use.

The IaaS is provisioned for a specific organization to ensure concerns (e.g., mission, security requirements).

The IaaS is a composition of distinct Cloud infrastructures.

https://aws.amazon.com/

https://cloud.google.com/

https://azure.microsoft.com/en-us/

https://developer.cisco.com/site/iox

http://www.etsi.org/technologies-clusters/technologies/mobile-edge-computing

https://www.redhat.com/en/topics/openstack

https://www.linux-kvm.org/page/Main_Page

https://www.xenproject.org/

https://tools.ietf.org/html/rfc2608

3.7. COMPUTATION OFFLOADING TAXONOMY: FROM THE FRAMEWORK PERSPECTIVE

http://alive.sourceforge.net/

http://game-ai.gatech.edu/

http://www.ai.mit.edu/projects/humanoid-robotics-group/kismet/

http://www.havok.com/physics/

https://developer.nvidia.com/gameworks-physx-overview

httph//www.ode.org

http://www.cs.unc.edu/~geom/I_COLLIDE/index.html

https://www.youtube.com/watch?v=iV-224nMwN8

https://www.youtube.com/watch?v=iTwtoOO7wXc

https://www.youtube.com/watch?v=LBbPwMmpqQI

https://www.youtube.com/watch?v=uRsspkum8LI

https://www.youtube.com/watch?v=paLLfWd2k5A

https://www.youtube.com/watch?v=kX0hnOS1QQQ&list=PLX2vGYjWbI0RibPF7vixmr4x8ONJX-mNd

https://www.youtube.com/watch?v=-Lkbo9ZyYbo

https://www.youtube.com/watch?v=XjiBDKrCsVI

https://www.youtube.com/watch?v=UK57qdq_lak

http://www.geforce.com/hardware/technology/physx/games

https://www.youtube.com/watch?v ŪK57qdq_lak

Number of symbols in one slot is 7 (6, respectively) for normal cyclic prefix ( extended cyclic prefix, respectively) in case of 15 K hz sub-carrier spacing.

Contain the signal-to-noise and -interference ratio (SINR) value measured by the UE.

Through this chapter, we use MEACOF and ME application interchangeably

A vertex coming after the current vertex in a path (e.g., G(V, E ) is a graph, (x, y) ∈ E ; y is a successor of x).

A vertex coming before the current vertex in a path (e.g., G(V, E ) is a graph, (x, y) ∈ E ; x is a predecessor of y).

We use the term RVLG and reduced graph interchangeably.

Number of elements in a set.

http://openbiometrics.org/

ACKNOWLEDGEMENTS

Dans cette thèse, je présente le travail que j'ai effectué sur une période de plus de trois ans. Pendant longtemps, de nombreuses personnes m'ont aidé, m'ont inspiré, ou autrement m'ont soutenu pour arriver

Offloading Gain study

For the convenience of presentation, we used various symbols to describe the following models. Table A.1 lists these symbols and their signification. Power consumption on the terminal

Power consumption for network communication

Power consumption on the terminal when the server is computing the offloaded tasks

Av ai l mem

The memory size available on the mobile

A.1.1 Improve performance

In this section, we propose an analytic performance-based model for computation offloading. We are interested on identifying when computation offloading brings a gain and what are the parameters impacting this gain. In this model, we suppose that both mobile device and remote server are computing

Where δ includes the size of the results sent from the remote server to the mobile device and the size of the offloading framework.

To sum up, we proposed here above, three simple mathematical models to study how to fulfill the requirements of applications and how to calculate the computation offloading gain. However, the number of parameters involved in the optimization models varies between frameworks.

A.2 Games

A.2.1 Rendering Pipelines

Unity 3D uses four additional rendering activities, which occur in conjunction with the main pipeline.

We summarize these rendering activities hereafter. the same way as for opaque objects, but with a drawing order of transparent objects from back to front. The transparent geometry is added to the frame buffer and combined with the ambient and opaque results [START_REF] Deering | The triangle processor and normal vector shader: a VLSI system for high performance graphics[END_REF].

2. Deferred shading -The idea is to defer the lighting calculation to the second pass until all the geometry has been rendered. The deferred shader algorithm uses smart management of different buffers [START_REF] Saito | Comprehensible rendering of 3-d shapes[END_REF], defined through three passes as follows: (i) Geometry Pass (Opaque Pass) applies an ambient lighting, saves the results in the frame buffer, and fills the Geometry buffer; (ii) Light Pass processes the lighting through the buffers transition calculations, starting with a depth buffer to rebuild origin position of pixels. The results are added to a normal buffer data to calculate the diffuse light. Then, a specular lighting is calculated using the position, the normal, and specular data buffers. Finally, the specular light is applied to colour and shading data buffer and accumulated with all the other light sources. The global colour of these buffers is accumulated in the frame buffer; (iii) Transparency Pass renders the transparent geometry using the forward rendering (Ambient Pass and Light Pass) [START_REF] Deering | The triangle processor and normal vector shader: a VLSI system for high performance graphics[END_REF][START_REF] Schneegans | guacamole -an extensible scene graph and rendering framework based on deferred shading[END_REF]. 4. Vertex lit -This operation is the fastest one and is supported by a large number of hardware. This process is done in one pass, wherein each object is rendered with lighting calculated on the vertices of the object from all the light sources.

A.2.2 Game Description

Viking Villageis a FPS 3D-game. The sequence offers a look at a medieval Viking village. The scene is characterized by high design quality with many details and various effects like water vibration, fire and smoke particles, sunlight, firelight, shadows, and reflecting lights, shadows, and colours by surfaces.

Tower Bridge Defenseis a TPS 2D platformer game. It depicts a player character fighting against NPC in a physics-driven 2D sample level. The avatars jump between suspended platforms, over obstacles, to advance the game. It features many objects subject to the 2D physics such as gravity, velocity, and other forces.

Stealthis a TPS 3D-game that describes a hostile environment characterized with guards (NPC) and security cameras, laser gates, key-card, and elevator. The game objects have a high rendering quality. The PC and NPC have an advanced animators, and the AI that manages NPC, laser gates, key-cards, and elevator is complex.

Survival Shooteris a TPS 3D action-game, wherein the gamer fights against an NPC. The objective is to shoot them, eliminate as many as possible, stay alive and try to get a high score. The game is characterized by 3D physics, character animations, and many NPC.

Tanksis a 2D MMOG where two players fight in a tank shooting game in a hostile desert environment. It is characterized by few graphical add-ons (such as rocks, palm trees, and rocky mountains).

The tanks are subject to physics (explosion particles, velocity, and friction), and directional light to simulate the sun.

Space Shooteris a 2D TPS game that takes place in space. The game is described by a large number of spacial-ships (enemies) and asteroids objects that are subject to physics: explosion particles, velocity and friction and, AI management.

Caris a 3D racing game, with platforms. It is a standard scene, representing a car with a whole engine system (including speedup, stop, red light, turning left and right, and engine sound). The scene includes some obstacles (static objects) and has platforms like bridges and pings. The terrain is a car road with obstacles and platforms around.

Unity Labis a 3D TPS game with a simulation about the daily life of Dr. Charles Francis, a research scientist at Unity Lab. The Unity lab includes different rooms reachable through hallways, with dynamic doors and elevators. The environment has an improved graphics, including shading, cinematic image effects, particles systems, and lighting. The NPC is represented by a flying robot.

Multiplayer FPSis a 3D MMOG FPS game describing a player fighting against a NPC inside an arena. The player character is a flying robot with blasters. The NPC is a humanoid character. The game is characterized with various effects for the arena such as fires, smokes, lights, sun, and storm.

A.2.3 Game Classification -(i) Classification per Playability

We start by collecting the data from Figures 4.4, 4.5, and 4.6, which enable to classify the nine games on each platform with the two encoding qualities as playable or non-playable. Next, we use the system A.7 to compact the classification through Table A

Pl a y abi l i t y ∧ ¬(Pl a y abi l i t y) ⇒ ¬(Pl a y abi l i t y) Pl a y abi l i t y ∧ Pl a y abi l i t y ⇒ Pl a y abi l i t y ¬(Pl a y abi l i t y) ∧ ¬(Pl a y abi l i t y) ⇒ ¬(Pl a y abi l i t y) (A.7)

-(ii) Classification per Resource variability

We attribute the predicate high variability or low variability for each game on each platform and for each quality to the results obtained in Figures 4.4

Hi g hV ar i abi l i t y ∧ Hi g hV ar i abi l i t y ⇒ Hi g hV ar i abi l i t y Hi g hV ar i abi l i t y ∧ LowV ar i abi l i t y ⇒ Hi g hV ar i abi l i t y LowV ar i abi l i t y ∧ LowV ar i abi l i t y ⇒ LowV ar i abi l i t y (A.8)

Pl a y abl e ⇒ Tr ad i t i onal ¬(Pl a y abi l i t y) ∧ LowV ar i abi l i t y ⇒ C l oud ¬(Pl a y abi l i t y) ∧ Hi g hV ar i abi l i t y ⇒ O f f l oad (A.9)

A.2.4 Client and Server Devices

Table A.4 presents the devices used for each architecture to do our experiments. Symbol ( †) represents the client, and (*) the server.