Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
  • G06F9/5094—Allocation of resources, e.g. of the central processing unit [CPU] where the allocation takes into account power or heat criteria
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
  • H04L67/1004—Server selection for load balancing
  • H04L67/101—Server selection for load balancing based on network conditions
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
  • H04L67/1004—Server selection for load balancing
  • H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2209/00—Indexing scheme relating to G06F9/00
  • G06F2209/50—Indexing scheme relating to G06F9/50
  • G06F2209/509—Offload
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
  • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
  • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

• the present invention is related to building a hybrid code offloading system in mobile computing.
• This hybrid offloading system is a combination of a cloud comprising one or more servers (also known as server cloud) and an ambient cloud comprising a plurality of smart devices (also known as cirrus cloud or mobile devices cloud).
• Mobile computing has been proposed for long with the rapid growth of smart device users.
• the smart device such as smartphone (e.g. iPhoneTM) is a computational device.
• Mobile computing involves the interaction of humans, laptops, cloud servers and smart devices. And there are many components in mobile computing such as communication and hardware. Despite the fact that hardware has been upgraded with a tremendous speed, the application execution speed still bothers both the developer and the smart device users.
• MCC Mobile cloud computing
• CloneCloud [3], ThinkAir [10], COMET [8] and Cuckoo [9] create VMs to configure smartphones' running environment on cloud servers, where offloadable methods in smartphones can be directly executed. These systems work well when network bandwidth is high. More recently, researches started to work on the device to device (D2D) offloading, where mobile phones offload tasks to other devices when network bandwidth is poor [12], [11]. These two case studies show the potential and feasibility of D2D offloading by measuring the execution capabilities and energy savings. Some programming frameworks like Honey bee [7], Misco [6] are also proposed to support device to device computing. The more systemic work for device to device offloading was done by Serendipity [14].
• Serendipity takes a PNP -block as input and tries to minimize the execution time with task allocation algorithm.
• the link predictability in the algorithm is too strong to implement in real world.
• COSMOS [13] tries to provide services for offloading users, which minimizes the offloading cost while maintaining performance.
• cloud offloading smart devices (mobile computational devices) can offload tasks to the cloud server, e.g. with 3G or WiFi connections. Smart devices achieve execution speedup and energy saving when they are well connected to the remote cloud. Usually such a system creates various several VMs (virtual machines) for fast execution, which increases a lot of monetary cost. And the offloading performance degrades as the bandwidth goes down. More recent works consider ambient offloading, the other extreme where smart devices have no Internet access. Smart devices leverage the intermittent connection opportunities with nearby devices for offloading. They can offload tasks to other devices when they are connected e.g. with WiFiDirect or Bluetooth.
• Ambient offloading systems can work as a supplementary solution for offloading when cloud offloading (by means of a server cloud which is built by mainframes) is inaccessible.
• Ambient offloading however, suffers from vulnerability since the connections are often broken up due to mobility. The drawbacks in both the remote and ambient cloud hinder the popularization of offloading systems.
• the present invention provides a brand new offloading system, which leverages both the cloud and ambient offloading to build a powerful offloading system.
• the system contains three components: a remote cloud (server cloud), a smart router and an ambient cloud.
• Remote cloud serves as the basic infrastructure for the offloading systems. It has the most powerful computational resources.
• the server cloud includes at least a server and storage means.
• the cloud can be any number of remote servers that are networked to allow a centralized data storage. Most computational exhausting tasks are usually delivered to these places when bandwidth is good.
• Ambient cloud is formed by the smart devices connected to the smart router. These smart devices serve as masters or slaves. When a smart device is busy with its own tasks, it would be a master. Otherwise it is a slave who is idle and can wait for execution.
• Smart router is the controller of the offloading systems.
• master node decides to offload tasks to the cloud (which will be either a server cloud or other smart device), it will send tasks to the smart router, which decides the executor of this task according to the optimization goal.
• the router is a computational device (comprising an operating system) and therefore a smart router.
• the present invention aims at overcoming the drawbacks and limitations brought by both the cloud and ambient offloading. That is, the present invention is directed towards combining both the cloud and the smart devices together, to build a hybrid offloading architecture to dynamically allocate computational resources.
• a hybrid offloading network system for offloading computational tasks comprises a first cloud comprising one or more servers and adapted, when receiving an offloading task, to execute the offloading task; and a second cloud comprising a plurality of smart devices.
• Each smart device is adapted to deliver, as an offloader, its offloading task and attributes of the offloading task, and/or is adapted, when receiving an offloading task, to execute, as an offloadee, the offloading task.
• a router manages information on currently available computational resources both in the first cloud and the second cloud, receives offloading tasks from the second cloud, decides which candidate among the first cloud and the offloadee or offloadees of the second cloud, each received offloading task is to be forwarded to, based on said resource information of each candidate, said attributes of the offloading task and/or network bandwidth, and forward the offloading task to the decided candidate.
• the attributes of the offloading task may preferably include a data size and/or an instruction count
• the router may apply a linear programming to make the decision.
• the linear programming includes an optimization function to optimize a total cost under the constraints of (i) the network bandwidth and execution time of each offloading task and/or (ii) energy consumption of said offloading task.
• the total cost is a sum of sub-costs that are each defined per candidate, each sub-cost being a cost that will be incurred if the offloading task is executed by said candidate.
• FIG. 1 illustrates the architecture of a hybrid offloading system according to an embodiment of the present invention.
• FIG. 2 illustrates the software architecture of a cloud shown in FIG. 1.
• FIG. 3 illustrates the software architecture of a smart router shown in FIG. 1.
• FIG. 4 illustrates the software architecture of a smart device shown in FIG. 1.
• FIG. 5 is a flowchart illustrating how to process a task in the smart device.
• FIG. 6 is a flowchart illustrating how to process multiple tasks in the smart router.
• FIG. 7 is a flowchart illustrating how to train a decision model in the smart device.
• This section mainly explains the system architecture of a hybrid offloading system according to an embodiment shown in FIG. 1.
• Three different kinds of software are deployed in cloud servers (component 102 and 103), a smart router 104 and smart devices 106.
• the cloud server end 101 has two different types: a main server 102 and a plurality of sub-servers 103.
• the main server 102 comprises a virtual machine manager 201 (FIG. 2).
• the virtual machine manager 201 responds to requests from the smart router 104, manages creation and destruction of virtual machines 203 (FIG. 2).
• the virtual machine manager 201 creates virtual machines 203 using resources of the sub-servers 103. Virtual machines 203 are only responsible for execution.
• These two components (virtual machine manager 201 and virtual machines 203) together form an essential part of the remote cloud 101.
• a task scheduler 302 (FIG. 3) allocates the executors of tasks submitted by smart devices as offloaders.
• the smart router 104 serves to minimize the total cost for renting cloud servers while maintaining the offloading performance.
• a master decision maker 403 (FIG. 4) will decide whether to offload or not according to performance need. All of the smart devices that are connected with the smart router 104 form an ambient cloud 105.
• the remote cloud 101 , the ambient cloud 105, and the smart router 104 form a hybrid offloading system according to the present embodiment.
• the main server 102 comprises a request listener 202 for responding to requests from the smart router 104.
• the identification of each request is verified in this listener 202 to make sure that the request comes from the smart router 104. If the verification is passed, the socket connection between the main server 102 and the smart router 104 can be set up and preserved.
• the request listener 202 will respond to all the requests from the smart router 104.
• the core component in the virtual machine manager 201 is a virtual machine scheduler 201. It has two basic functions: managing all the virtual machines 203 and performing the scheduling for all tasks received from the smart router 104.
• the scheduling algorithm is greedy but highly efficient, which takes only 0(nlog(n)) time for n submitted tasks. It should be noted that in the context of the present invention, "scheduling" in the virtual machine manager 201 is determining which task is to be sent to which virtual machine, while “scheduling" in the smart router 104 (which will be explained below) is determining which task is to be sent to which executor (i.e. server cloud or offloadee of the ambient cloud).
• the smart router 104 according to the present embodiment of the hybrid offloading system comprises a recovery machine 301, a task scheduler 302, a network manager 303, and a task queue 304.
• the task queue 304 estimates a current arrival rate of a plurality of submitted tasks (i.e. how many tasks are submitted to the queue in one unit time (usually in one second)), which will help the task scheduler 302 for fast and efficient task allocation.
• the task scheduler 302 is the core part in this router 104.
• the smart router 104 works as the proxy for all the smart devices connected to this router.
• the smart router 104 manages the resources (e.g. number of virtual machines) both in the server cloud 101 and the ambient cloud 105.
• the network manager 303 is used to measure the network condition (in particular, network bandwidth) with the server cloud 101.
• the task scheduler 302 is configured to decide which executor the task is forwarded to.
• the recovery machine 301 in the smart router 104 is different in terms of operation from a local recovery machine 406 (FIG. 4) integrated in the smart device 106: the recovery machine 301 of the smart router 104 does not request the local execution of this task, but request the smart router 104 itself to execute the task). It must instruct another executor (another smart device or the cloud) to execute the task.
• a local recovery machine 406 FIG. 4
• the smart device 106 according to the present embodiment of the hybrid offloading system comprises an application tracker 402, a master decision maker 403, an energy model 404, a profiler 405, and a local recovery machine 406.
• the application tracker 402 tracks all applications 401 running in the smart device 106 and specifies (identifies) each offloadable method.
• the application tracker 402 uses a task queue (not shown) to maintain all the offloadable methods submitted by the applications 401.
• the task queue applies a first-come-first-serve strategy where each offloadable method is equally served. Node who wants to offload tasks is called master node.
• Every offloadable method in the task queue should be sent to the master decision maker 403 to decide whether to offload or not the offloadable method.
• the decision maker 403 also invokes the profiler 405 to obtain hardware parameters (e.g. CPU status such as CPU utilization, CPU frequency, and battery level) and method parameters (i.e., instruction count) before decision.
• hardware parameters e.g. CPU status such as CPU utilization, CPU frequency, and battery level
• method parameters i.e., instruction count
• the smart device 106 may further comprise a (not shown) execution time estimation means for estimating execution time of each offloadable method based on the hardware parameters and the instruction count of the offloadable method by referring to the profiler 405.
• the decision maker 403 uses the estimated execution time when making the decision.
• the smart device 106 delivers, when the decision maker 403 decides that the offloadable method is to be offloaded, to deliver the estimated execution time as an attribute of the offloadable method to the smart router 104.
• the local recovery machine 406 is invoked to monitor the remote execution.
• the local recovery machine 406 backs up each delivered offloading task, monitors a remote execution of the offloading task.
• the smart router 104 is adapted to monitor a remote execution of each received offloading task in the server cloud 104 or in the ambient cloud 105 and report a monitoring result to the smart device 106.
• the local recovery machine 406 monitors a remote execution on the basis of the monitoring result from the smart router 104. If errors happen in this system, the local recovery machine 406 will respond immediately to call a local execution of this task.
• the energy model (energy consumption estimation means) 404 is the individual part in this system where the energy consumption of offloadable methods is estimated. Specifically, the energy model 404 estimates energy consumption of each offloadable method based on the hardware parameters and the instruction count of the offloadable method by referring to the profiler 405. The estimation is saved in the local database of the smartphone for future use. Using this value (i.e. energy consumption estimation) with respect to the offloadable method, the decision maker 403 may learn to perform a more precise estimation by actually executing the offloadable method within the smart device 106 and compare the actual energy consumption with an estimated value. In this case, the actual execution time may also be compared with an estimated execution time to allow the smart device 106 to perform a more precise estimation of the execution time of a current task.
• This section mainly discusses how the system operates when a task is generated at a smart device and submitted to this system.
• precompiling step 502
• precompiling program step 501
• system API application programming interface
• the smart device 106 starts the profiling by the profiler 405 (step 504), which are useful for the master decision maker 403 and the energy model 404. Then the master decision maker 403 makes the offloading decision (step 505) according to SVM (support vector machine) model (FIG. 7). The SVM classifier decides whether to offload or not according to the profiling information. After the decision, the smart device starts to send the code to the smart router 104 (step 506). If the code starts execution on an executor selected by the smart router 104, the program will use e.g. the "future" mechanism provided by java to wait for notification of an execution result (step 507). In the end the profiler 405 is stopped and all collected data will be written into a (not shown) local database (storage) of the smart device 104 (step 508).
• SVM support vector machine
• the smart router 104 also has a task queue 304 to maintain all the tasks submitted to the router. There will be an individual thread to query and fetch tasks from the queue. As shown in FIG. 6, the smart router 104 will probe available computation resources (step 601 ) and the current bandwidth (step 602) by sending requests to the connected devices of the ambient cloud 105 and the server cloud 101. With these resources, the router 104 decides the offloading targets with linear programming (step 603). Afterwards each task is sent to the decided offloading target (step 604) and the recovery module 301 is invoked (step 605). Finally the result is sent back through the smart router 104 to the original smart device (step 607) which has offloaded the task.
• the smart router 104 will probe available computation resources (step 601 ) and the current bandwidth (step 602) by sending requests to the connected devices of the ambient cloud 105 and the server cloud 101. With these resources, the router 104 decides the offloading targets with linear programming (step 603). Afterwards each task is sent to the decided offloading target (step
• the system Before the usage of the master decision maker 403 in smart devices, the system preferably has to train the parameters (i.e. runtime parameters and profiling information mentioned below) in this model.
• the training process first runs multiple applications to collect the data (step 701). The data collection needs to monitor the runtime parameters like CPU usage and bandwidth. So the training flow will also get the profiling information (e.g. battery usage) and stores these data into the local database of the smart device (step 702 and 703). With enough data entries, the system will use the training algorithm to get the initial decision parameters of SVM (step 704 and 705). However, these initial parameters could have the over-fitting problems if the training process uses only this small partial of data. To overcome this problem, an algorithm may be used to dynamically correct the parameters (step 706). Finally the training process can get the corrected SVM parameters (step 707).
• the training process can get the corrected SVM parameters (step 707).
• the design of this system can be divided into three parts: the smart devices, the smart router and the server cloud. The specific details of these parts will be explained in the following subsections.
• the design for the smart device has to meet the requirements of both the end users and the application developers.
• the hybrid offloading system should be efficient and powerful enough to deal with the speedup and the energy problem. Therefore the master decision maker 403 (FIG. 4) of the smart device can make right decisions according to current local hardware status.
• the application developers they mainly focus on their application designs rather than the optimization over the ambient cloud 105. But we have to acknowledge that the application can run smoother if the application developers obey some rule. Therefore we provide two levels of programming for these application designers.
• Profiler 405 profiler design contains all the information of the hardware parameters, the application parameters and the network. It should be noted that the master decision maker 403 of the smart device 106 is able to decide that tasks should not be offloaded if the network condition is not good (or does not satisfy a predetermined criteria).
• the profiler 405 may monitor the following things:
• the profiler 405 mainly monitors the applications in the runtime. It can monitor the following things: • Execution time of a method
• the profiler 405 is simplified by considering:
• Energy model 404 serves two functions in this system: i) providing benclimarks for the master decision maker 403 as to whether to offload the offloadable task and ii) evaluating energy consumption in experiments.
• PowerTutor a powerful tool that can have measurement error less than 6.27%.
• PowerTutor takes the CPU, screen, GPS, WiFi into consideration.
• This architecture is very friendly to the application developers. Like what has been proposed in previous offloading architectures, the programmers only need to mark the offloadable method before the definition with annotation(@offloadable).
• the hybrid offloading system invokes the analyzer to generate a runnable version with the offloading services. And the developer's version of code is also added to the remote code version for rewriting and generation of a new apk file.
• This annotation mechanism has little limitations on the programmers. They just need to specify the code that can be run in other machines. However, this mechanism is not powerful enough to support better optimization like parallel execution.
• Recovery machine 406 A recovery machine 406 is preferable in the offloading since tasks submitted for remote execution often suffer from failures in terms of network and operating systems.
• the recovery machine 406 of the smart device (offloader) 106 is needed to specify what occurs and make quick response when failure occurs.
• RemoteException designates errors which may occur within remote devices (cloud servers or offloadees in the ambient cloud). If RemoteException happens, the smart device will call a local execution.
• the smart router 104 monitors a remote execution of each offloading task in the server cloud 101 or the ambient cloud 105 and report a monitoring result to the smart device (offloader).
• the local recovery machine 406 backs up each delivered offloading task, monitors a remote execution of the offloading task on the basis of the monitoring result from the smart router 104, and calls a local execution of the offloading task in the smart device.
• the master decision maker 403 may mark each exceptional remote device. For example, the remote device will be excluded if it continuously throws exceptions 2 times.
• NetworkException designates errors which may occur when connection is lost or the socket streams are blocked.
• the smart router 104 will reping and reconnect the remote device.
• the master decision maker 403 of the smart device 106 waits for the remote device's results provided that the remote device and the smart router 104 are re-connected. Otherwise the smart router 104 reports to the smart device 106 that the reconnection fails, and the smart device 106 then calls a local execution in a similar manner as in the case of RemoteException.
• the smart router end is actually the local decision center. Besides the basic connection and communications, the smart router 104 may contain a recovery machine 301 , which is different in terms of operation from the recovery machine 406 in the smart device end.
• the offloading target in the smart router 104 contains two types: the cloud servers and the smart device executors (i.e. offloadees).
• Cloud servers are usually regarded as the stable computational resources where few errors happen except the API version.
• the smart devices often suffer from vulnerability since the smart devices (such as smartphones) sometimes move and disconnect to the smart router 104.
• the main contributor for the recovery machine 301 in the smart router end is to deal with the abrupt failure brought by smart device executor.
• the smart router may make backup for every task in the smart device, putting them in a waiting list. In this case, if any of the executors has some problems for the execution, the smart router itself may start execution immediately.
• the cloud server provides a general service entrance for all users who want to offload.
• the Java reflection mechanism requires the applications to be compiled and send the apk file for dynamic calling and indexing. And each time before the sending of offloading method, the cloud will check whether the corresponding apk file exists or not. Every apk file is installed with the name of the hash (apk) value. This naming has an advantage which can specify the version changes of the applications. Thus different versions of the same application can be dynamically invoked at the same time.
• the virtual machine manager 201 (FIG. 2) serves as two main functions: to manage the virtual machines and to schedule the tasks (i.e. determining which task is to be supplied to which virtual machine for execution).
• the virtual machine manager 201 finds the daily patterns for the traffic and tries to open corresponding numbers of virtual machines 203.
• the creation and destruction of virtual machine instances is implemented, for example, by installing the AWS CLI packages. By this way the virtual machine manager 201 can directly create and stop the virtual machines 203. DECISION AND SCHEDULING
• SVM support vector machine
• the goal in this decision machine is to make balances between the smart device helpers and the cloud virtual machines. If the task scheduler 302 (FIG. 3) of the smart router 104 decides to offload the task to the ambient cloud, the task will be directly offloaded to the selected candidate. If the task is sent to the server cloud, the virtual machine manager 201 (FIG. 2) of the server cloud will schedule the task to balance the load between the virtual machines 203 (i.e. decide the virtual machine to which the task is to be sent). And the virtual machine manager 201 will manage the VM creation and destruction to save the cost (typically, monetary cost).
• SVM support vector machine
• x is the feature vector of an example. For an example xi, it belongs to one class if f(xi) ⁇ 0, otherwise it belongs to the other class. Specific w and b determine a classifier. When there is some x, we calculate f(x) and check if it is less than zero.
• G(Tj) the loss of remote execution.
• the remote execution is beneficial only when G(Ti) ⁇ 0.
• tc is the connection setup time with the router
• t s is the method sending time
• te is the remote execution time
• t r is the time for results return
• ti is the time for local execution.
• t c is usually 0 or a certain value that can be directly estimated by the profiler.
• t s is determined by the data size(s) and the current bandwidth estimated by the signal strength (rssi).
• t e is determined by the executor CPU frequency and the number of instructions (inum).
• t r is estimated by the return parameter size (r) and the future bandwidth which can also estimated as the rssi.
• the ti is detemiined by both inum and current CPU utilization (util).
• the feature x in Eq. 1 for time incentive classifier is x - (t c , s, rssi, inum, r, util).
• the smart router 104 makes a balance between smart devices and cloud servers while causing less harm to the smart devices.
• the smart router 104 minimizes the total cost for the task execution, preferably with linear programming.
• the linear programming includes an optimization function to optimize a total cost under the constraints of (i) the network bandwidth and execution time of each offloading task and/or (ii) energy consumption of said offloading task.
• Sub-costs are each defined per candidate, each sub-cost being a cost that will be incurred if the offloading task is executed by said candidate.
• a sum of sub-costs is defined for each offloading task.
• a total cost is a sum of the sum of sub-costs for multiple tasks.
• a task 7 ⁇ i.e. i-th task received by the task queue 304 arrives and then the smart router decides which instance (including both the VMs and smart devices) h (i.e. k-th execution instance) to execute.
• h i.e. k-th execution instance
• n and m are the number of tasks and instances respectively, n and m are an integer of 2 or more (as will be explained below, n can take a value of 1).
• D r is a result data size (to be sent back from the execution instance to the smart device via the network; the smart router may receive and forward the result, but the result may be directly sent from the execution instance to the smart device) and
• b is the bandwidth (e.g. in units of kbps).
• M(T it l]) is an estimated execution time in the chosen execution instance and L(Tj) is a remaining lifetime (i.e.
• the optimization goal of this smart router is to minimize the total cost of the execution of all these tasks submitted to the smart router and preserved in the queue.
• the first constraint means that only one copy of method is executed.
• the second constraint means that the total time of offloading should meet the deadline of ⁇ ; .
• the third constraint is to protect the helpful smart devices from energy hole when it helps others with offloading.
• Eo here means an original energy level of the executing instance I k .
• Ec is a remaining energy level after the execution of that task.
• We set a threshold ⁇ in order to ensure that a large among of energy will not be consumed when assigning the offloading task to the smart device (offloadee) in the ambient cloud.
• the executing instance is a virtual machine instance in the cloud, the third constraint is not considered.
• R(I k ) is the reputation of instance .
• ⁇ for choosing the instance that has good executing reputation. This reputation value is calculated via evaluating the execution history of that node. For example, if a smart device (offloadee) only returns a result once every 3 times, the reputation can be calculated as 1/3 and compared with a predetermined value such as 0.5.
• avg(w) and avg(p) are an average workload of the virtual machines on the cloud servers (or cloud server in case where there is a single cloud server) and an average charge of the virtual machines on the cloud servers (or cloud server in case where there is a single cloud server) per unit time. They range from 0 to 1. With respect to avg(w), 0 represents the virtual machine being not loaded at all; 1 represents the virtual machine being fully loaded. With respect to avg(p), the system designer can set its unit (e.g. currency like Euro) and range. Ci is an instruction count of 7 ⁇ . S t refers to the smart device, and the first half of Eq. 5 designates a cost in case of a smart device executor.
• S 2 refers to the cloud server
• the second half of Eq. 5 designates a cost in case of a cloud server executor.
• 3 ⁇ 4 designates a remaining energy of the smart device after offloading and ranges from 0 to 1. 0 represents no energy; 1 represents full energy.
• the multiplication with avg(p) relating to virtual machines on the cloud servers has been made in order to set reasonable cost of smart device executor (first half) so as to be comparable with the cost of server executor (second half).
• first half the cost of smart device executor
• second half the cost of server executor
• avg(w) x avg(p) means that the cost is proportional to avg(w) as well as proportional to avg(p).
• Eq. 5 provides a comparison between the costs of the smart device and the server so that the user tends to choose the lower one.
• avg(w) server workload
• the cost of the server gets higher while the cost of the smart device gets lower. It is possible to generalize what is specifically defined in Eq. 5. If certain task is executed on the server, the cost only depends on the workload of the server and the charge. Higher workload or higher charge will lead to higher cost. However, if the task is executed on the smart device, the cost will also largely depend on the energy level of the smart device. If the energy level is low, it will significantly increase the cost.
• Eq. 5 actually can make balance between the cloud servers and the smart devices. If the cost is set to real cost (i.e. monetary cost), the final optimization algorithm would go into greedy strategy where all tasks that can meet the constraints will be offloaded to the especially powerful smart devices. However, these smart devices cannot get any reward from it and thus will deny cooperation. To avoid this problem, we propose to assign some cost from the task submitters and reward the task executors. The cost, however, also changes according to the server runtime environment. When the server is very busy with task execution, the cost of cloud computing would be more expensive while the cost for the smart devices execution will be lower. This strategy can greatly protect the system from sudden job jams when the cloud server is busy.
• real cost i.e. monetary cost
• the total cost to be optimized may be differently defined as those defined in formulae (4), (4'), (4") and (5).
• the total cost is a sum of sub-costs that are each defined per candidate, and the sub-cost is a cost that will be incurred if the single offloading task is executed by the candidate.
• the smart router may decide which candidate each offloading task is to be forwarded using another method that uses resource of infonnation of each candidate, attributes of the offloading task and/or network bandwidth as criteria.
• a data size and/or an instruction count of each offloading task may be used as such attributes of the offloading task.
• the offloadee may record execution information of the task and/or energy consumption required for the task in its local database.
• the execution information may include execution time and CPU status such as CPU utilization when executing the task.
• the execution information and/or the energy consumption (which are referred to as history execution information and history energy consumption, respectively) may be provided to the smarter router in order to assist the smart router in allocating future tasks.
• the smart router can more accurately estimate execution time of the same offloadee as a candidate for a current, different task to be offloaded. Furthermore, by comparing the history energy consumption (i.e. actually consumed energy of an offloaded, past task) of an offloadee with its corresponding estimated energy consumption of the past task, the smart router can more accurately estimate energy consumption of the same offloadee as a candidate for a current, different task to be offloaded.
• the cloud When tasks are submitted to the cloud, the cloud should be able to scale (allocate) almost all the tasks submitted by an application.
• the initial goal for the cloud optimization is to satisfy the deadline requirement of the application while balancing the load for the servers.
• the cloud server manager should preferably try to minimize the total cost for this application.
• the cost here refers to the resource used in the cloud or the load thereof.
• Load Balancing In our offloading system, we design an online load balancing algorithm to let a faster execution and lower latency for the tasks submitted by the smart router. Actually, the virtual machine manager can also benefit from this algorithm according to the average workload of the virtual machines on the cloud servers. As has been proved by the approximation theory, the solution to find the optimal scheduling is NP-hard. In order to save the scheduling and allocation time, we design a longest processing time based balancing algorithm.
• This algorithm sorts the task queue according to the load first and then greedily submit these tasks to the least loaded servers.
• the time complexity for this algorithm is only 0(nlogn) where n is the number of tasks in this queue.
• FaceDetection This method detects how many faces are there in a picture.
• the attributes of this method varies according to the parameter input. If the picture size is large, the FaceDetection method can be both computation and bandwidth intensive.
• N-Queen This method is designed to find the possible solutions for N queens on an NxN chessboard. We use a brute force method to traverse all the possible cases, which takes 0(N 2N ) time complexity. This method is only a representation of computational intensive method.
• Quicksort has been regarded as the most efficient and representative sorting algorithm. We design this method to take an unsorted array as the input and return a sorted array. This method is computation and bandwidth intensive if the input array is very large. Besides, the method can also be memory intensive since the method is invoked recursively.
• Sudoku Apart from the previous applications, we also design a Sudoku solver method, which takes a ° ⁇ ° matrix as input and returns whether there exists solutions of this matrix. Sudoku therefore can be regarded as a lightweight method.
• Sharplens is an augmented application developed with Google glassTM. Google glass is used to help the poor visual or blind people to recognize the context in front of them. This application first recognizes the hand in the video taken by the camera embedded in the glass. Then it locates the position of the finger and recognizes the paragraph around the finger. Finally the paragraph is presented in prism or read out by the speaker. In this application, this patent applies both of the two types of programming rules to show the execution efficiency.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=54601733

Family Applications (1)

Country Status (2)

Families Citing this family (26)

Family Cites Families (2)

• 2015
  • 2015-10-21 WO PCT/EP2015/074319 patent/WO2017067586A1/en active Application Filing
  • 2015-10-21 EP EP15797260.5A patent/EP3221789A1/de not_active Ceased

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events