Dynamic decision support for resource oﬄoading in heterogeneous Internet of Things environments

Computation oﬄoading is one of the primary technological enablers of the Internet of Things (IoT), as it helps address individual devices’ resource restrictions. In the past, oﬄoading would always utilise remote cloud infrastructures, but the increasing size of IoT data traﬃc and the real-time response requirements of modern and future IoT applications have led to the adoption of the edge computing paradigm, where the data is processed at the edge of the network. The decision as to whether cloud or edge resources will be utilised is typically taken at the design stage based on the type of the IoT device. Yet, the conditions that determine the optimality of this decision, such as the arrival rate, nature and sizes of the tasks, and crucially the real-time condition of the networks involved, keep changing. At the same time, the energy consumption of IoT devices is usually a key requirement, which is aﬀected primarily by the time it takes to complete tasks, whether for the actual computation or for oﬄoading them through the network. Here, we model the expected time and energy costs for the diﬀerent options of oﬄoading a task to the edge or the cloud, as well as of carrying out on the device itself. We use this model to allow the device to take the oﬄoading decision


Introduction
As a result of their resource restrictions, Internet of Things (IoT) devices typically rely on the storage, communication, and most significantly, computation resources of remote cloud infrastructures, for example to run computationally intensive artificial intelligence algorithms. This traditional IoT-cloud approach has worked well in the first years of IoT, but is unlikely to be able to efficiently meet the requirements of future IoT applications [1,2]. IoT applications are becoming increasingly demanding in terms of real-time response requirements, and at the same time, the data they produce is increasing dramatically. Indicatively, the Cisco Global Cloud Index has estimated that IoT data will reach 507 ZB per year by 2019, which is 49 times higher than the current total global data centre traffic (10.4 ZB) [3]. Pushing the computations and data to the cloud from IoT devices that have limited bandwidth or are connected to the cloud through unreliable networks costs IoT services in terms of response time and availability. Moreover, due to their energy limitations, a primary goal is to reduce transmission and scheduling computation to what is practical for the power capabilities of IoT devices.
The edge computing paradigm, where the data is processed or even produced at the edge of a network, was introduced in response to these requirements and is now considered a core enabler of the 5th generation of mobile communications (5G) and the IoT [1,4]. The rationale is that with the significant increase of IoT data and the limited speed of IoT data transportation, offloading computation to the edge may allow most of the benefits of the cloud without its key communication disadvantage [5]. However, its fundamental weakness is that unlike the cloud, which does not have geographical restrictions and has considerably greater resources, edge devices have to be in proximity to the IoT devices and their resources are also limited. The choice of whether a task should be processed locally, at the edge or at the cloud has been traditionally based almost entirely on the original design of the system. Here, we propose a Multi-critEria DecIsion support meChanism for IoT offloading (MEDICI) mechanism that decides dynamically whether an IoT task should be processed locally, at the edge or at the cloud.
Without loss of generality, we assume an IoT architecture where a variety of heterogeneous IoT devices and their corresponding applications are connected to the Internet (and the cloud) through a gateway ( Fig. 1) and are directly connected to the edge devices in proximity. Note that we assume that each application has a dedicated corresponding device (edge or cloud). Also, in some IoT architectures the gateway itself can be the edge device for offloading, but this does not materially change our analysis and modelling.
In detail, this paper's contributions are the following: • A response time and energy consumption model for edge IoT, which takes into consideration the application, device and network characteristics of the system.
• An offloading decision support mechanism for heterogeneous IoT devices, each with their own individual requirements, which have the option of at the individual level of each application but also at the global system level, as the total energy consumption too is improved.

Related work on decision making in IoT offloading
The majority of edge offloading decision making mechanisms proposed in the literature refer to mobile edge computing [6]. For example, Meurisch et al. [7] address the issue of heterogeneity of the edge or cloud infrastructures for mobile offloading, where the resource availability of the different edge or cloud devices can vary considerably, as might the resource requirements of the tasks to be offloaded. They propose an offloading decision support system that predicts the completion time and energy consumption by probing edge or cloud devices with micro tasks only lasting a few microseconds, and using regression models.
Probing has indeed proven very useful in task allocation and admission control [8] problems but introduces a delay overhead which can be inappropriate for time-sensitive IoT services.
Offloading in IoT environments can differ considerably, not only in terms of the type of networking protocols and architectures involved, but also in terms of the nature of typical applications. Additionally, most published work focusing on IoT offloading mechanisms addresses decisions between two entities only, the cloud or the edge(s), and omits the IoT device itself. An exception is [9], where it is up to the individual IoT devices to decide themselves whether they wish to optimise offloading based on time or energy, and advertise to the other IoT devices in their network, while a centralised network controller allocates the available bandwidth among the nodes, giving higher priority to time-sensitive tasks. The authors demonstrate the usefulness of employing the edge computing paradigm in comparison to just offloading to the cloud.
In [10], the authors formulate the problem as a computation offloading game of multiple IoT users requiring access to the limited resources of close-by edge devices. The assumption is that the users are selfish and only care about maximising their own quality of experience, measured in terms of reducing computation energy and delay. The authors have proposed a near-optimal algorithm to reduce the complexity of reaching a Nash equilibrium but it is not evident how it can be implemented in an online, dynamic way.
[11] also proposes a computation offloading game to model the competition for cloudlet resources between IoT devices. It aims to minimise energy and delay of the IoT sensors. The authors consider the different technologies of communication between the different entities. When offloading computation tasks to cloudlets, IoT sensors transmit data blocks via wireless access points, while when offloading tasks to the cloud the IoT device connects to the Internet via the base station. They propose a finite improvement iteration algorithm to keep the computation complexity of the game algorithm relatively low. The IoT devices are not considered capable of processing the tasks, and thus are not included in the offloading decision. However, the actual decision and estimation of where to offload can be centralised or distributed, whereby the sensors are assumed to run the algorithm. Their evaluations were against Random Selection (choosing between edge and cloud) and Cloud-only (selecting always the cloud for offloading) strategies.
An IoT offloading technique is proposed in [12] to manage the offloading of computing tasks between IoT devices (smart home controller) and the cloud, based on energy consumption under service time delay restrictions. The authors propose to use the gateway as a middleware platform to decide between local processing and the best cloud infrastructure. They propose a static allocation of resources processed in the smart home controller, based on the application's resource requirements and then, at the gateway, a dynamic allocation to the appropriate cloud server based on the energy savings under QoS delay constraints.
The paper does not consider dynamic allocation at the local level or that classes of IoT devices may be able to perform local processing.
Similarly, [13] proposes a cloud-enhanced home controller that enables computation offloading of smart home applications from the home controller to the cloud, by ranking them based on predefined requirements, priorities, compute resources and network bandwidth values. Apart from choosing between processing at the IoT controller or offloading in the cloud, they also propose a degraded mode of operation when network connection is not possible. The predefined values can be updated but energy consumption of the devices or local processing are not considered.
The authors in [14] impose communication bandwidth constraints to manage computation offloading and increase the utilisation of the edge node which will also lead to energy savings for the IoT devices. They propose an iterative bandwidth allocation algorithm to better utilise the usage of the edge device.
They consider IoT devices with different transmission rates and different offloading levels. They assume that the devices will always process locally until their capacity is reached and then offload. Henceforth, we refer to this type of strategy as IoT-first. Benedetto et al. [19,6] propose MobiCOP-IoT which is a mobile code offloading system for IoT applications. For estimating the network parameters, MobiCOP-IoT samples the network every 15 minutes or probes whenever it is needed. To calculate the execution time for a given task, it uses historical data, assuming that the same tasks always take the same time to be executed.
Recently, Jalali et al. [20] introduced a task allocation strategy called DEFT.
It tries to allocate tasks to nearby discovered devices within a local trusted network and a cloud server. The offloading decision is made based on the assumption that the IoT device can act as a task requester or a task performer. To do so, an IoT requester broadcasts a request to all known devices, enquiring about parameters such as CPU, memory, and transmission rate. These parameters are fed to machine learning algorithms (regression and ensemble models) for predicting how the available nodes would behave for a given task. However, the variation of a task's size or the energy consumption are not considered when making the decision.
Recent work involving computation offloading proposes to use machine learning for the estimation of the response times when making the decision of where to offload. For instance, Alam et al. [21] propose an offloading mechanism that uses Deep Q-learning based code offloading to decide amongst a set of distributed fog nodes, a cloud and mobile devices, while in [22], Alelaiwi proposes to use deep-learning in order to predict the response times of a task based on historical observations or pre-defined parameters such as CPU, memory and bandwidth consumption. The use of deep learning though usually translates in high computation cost, making these mechanisms often unsuitable for IoT environments with limited resources.
Reflecting on the literature review, we can observe that the related work does The decision for where to offload is taken based on the model described in the next section.

Offloading model and multi-criteria decision support mechanism
In this section, we model each component of the system to derive an expression for estimating its response time and energy consumption. The decision on which target device (the IoT device, the edge or the cloud) should process the task is taken autonomously on the IoT device itself. Table 1 summarises the notations used.
Let us consider an IoT application consisting of computational tasks, all of which can be offloaded. A given task n has size z n , representing the computation requirements of the task, and input data of size d x n and output data of size d r n . Specifically, d x n and d r n represent the data block to be transmitted as part of offloading (e.g., a video in a CCTV monitoring system) and the data block to be sent back as the result (e.g., the recognised object in the video) respectively. Each device D can be of the type IoT device, edge device or cloud server (D ∈ {IoT, Edge, Cloud}), with processing speed S D . Normally, the IoT device is the slowest and the cloud is much faster in terms of processing (S IoT << S edge << S cloud ). We assume that the IoT devices can communicate with both the edge (e.g., via Wi-Fi, Bluetooth or Zigbee) and the cloud (e.g., via WAN or cellular), at different effective transmission rates.

Processing times
In accordance to the usual representation of processing time in task allocation problems [23], the time it takes for a task n with size z n to be processed at a device D is: Every time a task arrives at a device D it enters a processing queue. This can be a single queue (i.e. in the case of the IoT device itself) or one of multiple queues (in the case of more powerful devices such as the edge or the cloud, where multiple cores and multiple virtual machines are available, dedicated to specific IoT applications). We assume that each such queue constantly keeps track of the number of tasks (and their corresponding sizes) that are currently  The total energy cost of task n in the case of a altruistic IoT device α Weight denoting preference in minimising response time over energy, Parameter for bringing T n,D and E n,D into a mutually comparable range of values waiting. When a new task n arrives in device D it cannot be processed until all previous tasks of its corresponding queue Q proc n are processed. If k is the number of tasks waiting in Q proc n when task n arrives, then we approximate the time that the task n has to wait in the processing queue as: Here, we assume a first-in-first-out processing model in all devices, where one virtual machine on the edge and one on the cloud is dedicated to one corresponding application.

Network delays
When the processing of a task n is offloaded from an IoT device to a target device D (edge or cloud), there is an additional delay to transmit the task (T x n,D ) to that device and an additional delay (T r n,D ) to get the result back from that device to the IoT device.
In accordance with the standard practice in computation offloading modelling [23], [24], [25], [11], the time it takes to transmit a task n from the IoT to another device D depends on the size of the input data that the task is associated with (d x n ), and the transmission rate R x D .
Similarly for receiving the result back, where the size of the result data is d r n and the transmission rate for the connection between the devices is R r D : In non-ideal communication conditions, where we consider packet loss due to congestion or failures, with a probability p, we assume that, the delay in establishing that a packet is lost and re-transmitting means that each bit lost incurs an increase in communication delay by a factor l = 1 1−p , l ∈ R + Thus, the above equations become: We also model imperfect network conditions in the form of congestion, as expressed by network queuing delays. Similarly to [26], and [27], we assume that the network between an IoT device and the target device D can be expressed as a M/M/1 queue with arrival rates λ x D , λ r D and service rate µ x D , µ r D for transmitting and receiving accordingly.
The utilisation of the network used to offload to D is ρ x D = λ x D /µ x D , and the average number of tasks waiting in the network queue for reaching D is Similarly for receiving the result back from D, the utilisation is ρ r D = λ r D /µ r D and the average number of tasks waiting in the network queue for reaching the source device is Applying Little's Law, the average network queue waiting time of task n offloaded to device D is: and for receiving the result back: We have considered the network for the transmitted data from the IoT device to the target device separately from the the one for the response back, since the input and output average data sizes are different, and thus the M/M/1 parameters are different.

Response time
We refer to response time as the total time it takes for a task n to be transmitted (first two terms of equation 7) and processed (next two terms of Of course, in the case that D is the IoT device, where the task is not

Energy consumption
Let P proc IoT be the average power consumed when the processor of the IoT device is busy, and P idle IoT be the power consumed when idle. Also, P x IoT and P r IoT are the power consumptions when the IoT device is transmitting to and receiving data respectively.
If the task n is run locally at the IoT device, then the energy consumption due to that task is the energy consumed by the IoT device to process it: E local n,IoT = P proc IoT T proc n,IoT If task n is offloaded to a target device D other than the IoT device, then the energy consumed by the target device E of f n,D is the energy consumed for receiving the offloaded data at D, processing the task at D, returning the result to the IoT device, plus the energy consumed by the IoT device E of f n,IoT for sending the data to D, remaining idle while waiting, and receiving the result back from D.
We assume that the IoT device does not initiate a new task until it receives the result from the previous task and is therefore idle during the offloading response time.
Also, the energy consumed by D receiving the offloaded task, processing it and returning the result is: A "selfish" IoT device, which is interested only in its own energy efficiency will aim to minimise E of f n,IoT . An "altruistic" IoT device that is interested in helping improve overall energy efficiency, will aim to minimise the total E of f n , where: Summarising in a single expression, the energy cost of n in the case of a selfish IoT device is: Similarly, for altruistic IoT devices, it is:

The Decision Mechanism
The decision is taken at the IoT device based on a weighted goal metric consisting of response time and energy. For selfish IoT devices, this is: Similarly, for altruistic IoT devices: Note that α ∈ [0, 1] is a weight denoting the application's preference in This decision is taken by each IoT device for its own applications independently, based on information requests for obtaining the local queuing states and processing times, which are communicated between the IoT and the edge, and the IoT and the cloud. We assume that this communication is given priority and as such the total time it takes to receive and process these request/response packets is negligible in comparison with the processing times even during times of congestion, which is a common assumption in the literature [28].
Note that without loss of generalisation, we considered one edge and one cloud device, because our aim is to determine whether edge or cloud (or local processing) should be chosen, rather than which edge or which cloud device should be chosen. This is not only because the single edge/cloud case is by itself realistic for common smart home or smart office environments, but also because additional edge and cloud devices would not make a difference to the model or the decision mechanism. Again, the device chosen would be the one with the minimum goal value, whether there is one or multiple edge and cloud offloading options.

Simulation environment
We performed our simulations by extending the discrete event simulator EdgeCloudSim [29], itself based on CloudSim [30] one of most popular simulators for cloud computing environments [31,32]. EdgeCloudSim allows the simulation of mobile devices which can execute tasks locally and incorporates a networking module for WANs and WLANs or a cellular access network model (3G/4G/5G) between devices. Tasks can be migrated between edge and cloud virtual machines and allows to add a probabilistic network failure model to consider the congestion of the network between the devices. It has been used extensively in the related literature (e.g., [33], [34], and [35]). EdgeCloudSim When the simulation starts, the tasks are served in a chronological order based on their start time and regardless which application they belong to. In each IoT device, an end device manager is responsible for taking the decision of selecting a place to process based on the decision algorithm and the results are saved in log files.

Experimental setup
Our setup consists of an IoT, an edge and a cloud device. For the processing speed configuration of each device, we use Million Instructions Per Second (MIPS ), which is supported by EdgeCloudSim for measuring processing times in a reliable way. We adopt it here for reasons of practicality, as is extensively used in the literature (e.g., [36]). We set the processing speed of IoT devices at 50 MIPS. An edge device is simulated as a single EdgeCloudSim datacentre, consisting of a host with four virtual machines at a processing speed 1000

MIPS.
In our experiments, we equate the transmission rates of the devices to the available bandwidth for sending or receiving data. We refer to this as the effective bandwidth. The edge communicates with IoT devices through a WLAN connection of 5M bps effective bandwidth. The cloud is also simulated as a single EdgeCloudSim datacentre with one host and four virtual machines, each of which has processing rate of 10000 MIPS. The network between between IoT devices and cloud is considered a WAN with 2M bps effective bandwidth. Finally, we have set the packet loss probability p = 0.11 and thus the delay factor due to loss l = 1 1−0.11 = 1.12. In accordance to our energy model (Section 3.4), each device has three modes for energy consumption: processing, transmission and idle. The configurations of the edge and the cloud devices were chosen based on the iFogSim energy profiles [37], where for edge and cloud, the power to transmit is practically equal to the power to process. For the IoT devices, we have run an experiment using a Raspberry Pi3 device acting as the IoT device and a Watts Up Pro meter [38] measuring the actual power consumption when idle, transmitting, receiving and processing a computationally intensive application. Table 2 summarises these specifications for all devices. Although a Raspberry Pi3 device is much more powerful of a typical IoT device today, we anticipate that in the future, IoT devices will become more powerful and thus will consume more power.  [39]), one for healthcare IoT (as one of the in-home therapeutic IoT applications described in [40]), one for IoT intrusion detection (as in our robotic vehicle intrusion detection implementation in [41]), and a hypothetical future indoor monitoring device that will be able to not only visualise a household's sensor data, but also perform advanced analytics to provide predictions and recommendations to its users. We have chosen these four applications so that we can have a range of heterogeneous IoT applications with different specifications (in terms of task size and input/output size) and requirements (in terms of how energy demanding or time critical they are). For instance, the face recognition application is very demanding computationally and also needs to send a relatively large input file (e.g. picture) when offloaded. On the other hand, the computation of the intrusion detection application is moderate and the input file size is small and the result back is very small, since it might consist of a simple yes or no answer of whether an attack was detected or not.
These configurations are summarised in Table 3

Simulation results and discussion
Here we evaluate our proposed Multi-critEria DecIsion support meChanism for IoT offloading (MEDICI). The following are four implementation variants of MEDICI, where we evaluate the differences between selfish and altruistic IoT devices, for the two cases of having different (individualised) and identical (non-individualised) α.
• The selfish individualised version (MEDICI-SI ). Each IoT device has different α according to each application's needs (table 3) and the energy to be minimised is the energy of each IoT device.
• The altruistic individualised version (MEDICI-AI ). Each IoT device has different α according to each application's needs (table 3), and the energy to be minimised is the total energy of the system. • Choosing the IoT device first (IoT-first): If the task is small enough, then it is processed locally until the device's capacity is reached as in [14].
Otherwise, the edge is chosen until its capacity is reached, in which case it is offloaded to the cloud. We have put a restriction on the size of the task for IoT devices (500M I) to avoid a situation where, for applications with computation intensive tasks, the task would not have finished by the end of the experiment.
• Offloading to the edge first (Edge-first): The task is offloaded to the edge until its capacity is reached, and then to the cloud. This is the state of play of most commercial IoT devices that use edge computing. The local computation at the IoT device is not considered here.
• Individualised predefined probability (Probabilistic): The offloading decision is based on a predefined probability, different for each of the applications. Here we report the result for the set of probabilities that are empirically measured to have the highest performance. Note that our aim is to compare this to our own approach, so, choosing the empirically highest performing configuration of this approach for comparison is meaningful.
We have used the same task size restriction as in IoT-first.
• Offloading only to the Cloud (Cloud-only ): All tasks are offloaded to the cloud. Edge and local computation are not considered. This is the traditional IoT approach used by most commercial IoT applications, and considered for comparison also in [11].
• Random Selection (Random): This is a special case of the probabilistic approach, where the probabilities between the choices are equal as in [11].
Each experiment was run for 1 hour of simulated time. The results presented here are the averages of 10 runs for each configuration. Figure 2 shows the av- For the face recognition application, which is characterised by large mean For the healthcare application, which is characterised by large mean task size, large mean input size, low output size and very high α (i.e., strong preference for response time over energy efficiency minimisation), MEDICI-AI was able to reduce the response time by 14% against Edge-first and the total energy cost against IoT-first by around 10%. The IoT energy cost reduction, however, was not significant. This is expected given the application's very low α. For the intrusion detection application, which can be offloaded relatively quickly (lowest input and output size) and has a high value of α, the bestperforming non-MEDICI strategy is cloud-only. Against it, MEDICI-SI achieves a reduction of over 35% in response time and IoT energy cost. In terms of total energy, again as intended, the best performing variant is MEDICI-AI with a reduction of around 31%.
For the indoor monitoring application, which has the lowest mean task size, significant network traffic when offloaded, and a low value of α, MEDICI-AN achieves the lowest response time (54% reduction against the probabilistic strategy) and IoT energy cost (40% reduction), while MEDICI-AI achieves the lowest total energy cost (68% reduction).
Comparing between the two selfish variants, the individualised MEDICI-SI outperforms the non-individualised MEDICI-SN across all four applications and for all three metrics. This showcases the importance of addressing the individual  Figure 5 shows the average percentage of tasks that were allocated to each device per application. It shows that MEDICI appropriately minimises cloud usage for IoT applications that are not computationally demanding, are timesensitive or return large amounts of data as their output. It also appropriately makes more usage of the cloud when IoT energy consumption is important and a task is computationally demanding.

Conclusions and future work
We have proposed a multi-criteria offloading decision mechanism for heterogeneous IoT devices which takes into account not only the execution time of have also demonstrated the importance of the weight α of the applications preference in minimising response time over energy, especially given the often extreme heterogeneity of IoT devices. As intended, the energy-altruistic variants of MEDICI are able to minimise the total energy cost by taking into account the energy cost of the offloading target too, while the selfish variants minimise the energy cost to the IoT device itself. Our evaluation has assumed that the decision is taken locally at each IoT device. However, in a real testbed it might be more realistic to have the decisions taken at the edge device. Of course this will introduce networking overheads incurred for the IoT requests to the edge and the collection of the utilisation data at each device required to take the MEDICI decisions. Another assumption taken in this paper is that the information required for making the decision is (i.e. the local queuing states and processing times) is obtained through high priority request/response packets between the IoT device and the edge/cloud and that we have knowledge of the average end-to-end throughput between the devices. In a real-life situation, the latter could be obtained by regularly probing the network. Of course these communications will introduce some overheads. Additionally, aspects of the cloud, such as its elastic properties, might also be affecting the processing times of a task. Our next steps are to evaluate all these overheads and challenges in different real-world implementations.