RESOURCE AWARE PROCESS MIGRATION IN WIRELESS SENSOR NETWORKS
By
Syed Ishtiaq Hussain
Supervised By
Dr. Humma Javed
DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF PESHAWAR SESSION 2009-2010
RESOURCE AWARE PROCESS MIGRATION IN WIRELESS SENSOR NETWORKS
By
Syed Ishtiaq Hussain
Dissertation Submitted to the University of Peshawar in partial fulfillment of the requirement for the degree of
DOCTOR OF PHILOSOPHY
Supervised By Dr. Humma Javed
DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF PESHAWAR SESSION 2009-2010
DEDICATION
Dedicated to my beloved parents, and my kids…
iv
STATEMENT OF SOURCES
DECLARATION
I, the undersigned, author of this thesis, declare that this thesis is my own work and has not been submitted in any form for another degree at any university or institution.
Information derived from published or unpublished work of others has been acknowledged in the text and a list of references is given.
______Syed Ishtiaq Hussain 28th September 2018
v
RIGHTS OF THESIS
All parts of this dissertation are reserved by the author, any part of this research shall not be produced or transmitted in any form or by any means, without formal permission from the author.
Syed Ishtiaq Hussain
vi ABSTRACT
This thesis presents a novel architecture for native process migration (PM) in wireless sensors networks (WSN) without the use of virtual execution environment. Resources in
WSN are scarce, therefore creating a virtual execution environment for processes so that they can be migrated, put an extra burden on already constrained resources. The proposed architecture for process migration allows live native processes to be migrated during execution. The process migration architecture takes migration decisions by continuously monitoring resources including remaining battery life and free memory space on a node. The architecture is suitable for networks with fewer expensive sensor nodes as it allows for better utilization of network resources. Transferring a live executing process helps in meeting processing demands dynamically, improves fault tolerance and resource utilization, and allows easier network management in WSN.
The proposed architecture supports resourcing monitoring, request broadcasting and response collection, target node selection, process code and state transfer, and restoration of native process at the target node. Implementation of proposed architecture has been successfully tested on COOJA simulator and a test-bed of TelosB motes. The final implementation has been compared to agent based systems and virtual machine architectures. It shows a remarkable improvement in runtime energy efficiency and executable code size.
vii ACKNOWLEDGEMENTS
First and foremost, I would like to thank the source of all the wisdom, the ALLAH
Almighty for bestowing me with the capabilities to accomplish this gigantic task. Next, I have no words to express my deepest sense of gratitude to my supervisor, Dr. Huma
Javed for her encouragement and outstanding supervision. I am highly obliged to her for her untiring efforts and patience in reviewing numerous drafts of this thesis.
I am also highly indebted to Prof. Dr. Shah Khusro, Prof. Dr. Saeed Mahfooz, Prof. Dr.
Muhammad Abid as they have been very kind at all the time during the course of my
PhD. Their cooperation was instrumental in overcoming some of the insurmountable problems without which this task would not have been possible. I would also thank Dr.
Murad, Dr. Bilal, Muhammad Tehseen Khan and Saqib Muhammad Khawaja for their support and encouragement.
Syed Ishtiaq Hussain
viii TABLE OF CONTENTS
Chapter 1. Introduction ...... 1
1.1 Preamble ...... 1
1.2 Middleware ...... 5
1.2.1 WSNs Middleware ...... 6
1.3 Process Migration ...... 7
1.3.1 Process Migration Scenarios ...... 8
1.3.2 Issues in Process Migration ...... 10
1.4 Problem Statement ...... 12
1.5 Design Goals ...... 15
1.6 Novel Contributions ...... 16
1.6.1 Process Migration Middleware Architecture ...... 16
1.7 Thesis Structure ...... 19
1.8 Summary ...... 19
Chapter 2. Overview of Wireless Sensor Networks ...... 21
2.1 Structure of Wireless Sensor Networks ...... 22
2.1.1 Components of Wireless Sensor Nodes ...... 22
2.2 Wireless Sensor Network Characteristics ...... 25
2.2.1 Wireless Sensor Network Topology and Software ...... 28
2.3 Physical Constraints on Wireless Sensor Networks ...... 30
2.4 Programming Paradigms for WSNs ...... 31
2.5 Operating System for Wireless Sensor Networks ...... 32
2.5.1 Mobile Agent based Systems for WSNs ...... 32
2.5.2 Contiki Operating System for Wireless Sensor Networks ..... 33
ix 2.6 Summary ...... 33
Chapter 3. Overview of Process Migration ...... 35
3.1 Process Migration Types ...... 35
3.2 Process Migration in Conventional Operating Systems ...... 36
3.2.1 Check-point and Restore ...... 37
3.3 Existing Process Migration Middleware Architectures for WSNs .... 38
3.3.1 Native Process Migration ...... 39
3.3.2 Agent Based Systems ...... 39
3.3.3 Process migration in Java ...... 40
3.4 Homogeneous Process Migration ...... 42
3.5 Heterogeneous Process Migration ...... 44
3.6 Advantages of Process Migration in WSNs ...... 45
3.6.1 General Advantages of Process Migration ...... 46
3.6.2 Ubiquitous Computing ...... 48
3.7 Load Balancing ...... 49
3.7.1 Fault Tolerance in Wireless Sensor Networks ...... 49
3.8 Initiation of Process Migration in WSNs ...... 50
3.9 Functional and Deployment Constraints in Process Migration on
WSNs 51
3.10 Types of Processes on Wireless Sensor Nodes ...... 53
3.11 Summary ...... 54
Chapter 4. Process Migration Architecture for WSN ...... 55
4.1 Steps of Process Migration...... 55
4.2 Proposed Process Migration Architecture for WSNs ...... 58
x 4.2.1 Components of Process Migration Architecture for WSNs ... 58
4.2.2 Core Services ...... 61
4.3 Performance Measurements for Process Migration ...... 62
4.4 Process Migration Implementation ...... 63
4.5 Overview of the Sender and Receiver Algorithms ...... 63
4.5.1 Submodules ...... 65
4.5.2 Overview of process migration between two nodes ...... 65
4.6 Sender Node Algorithm ...... 67
4.7 Receiver Node Algorithm ...... 69
4.8 Details of helper algorithms ...... 71
4.8.1 Energy Consumption Estimation ...... 71
4.8.2 Battery Voltage Estimation ...... 71
4.8.3 Free Memory Estimation...... 72
4.8.4 Node Proximity Estimation ...... 73
4.8.5 Load Balancing ...... 74
4.8.6 Process Selection ...... 74
4.8.7 Processor Load Estimation ...... 75
4.9 Summary ...... 76
Chapter 5. Evaluation...... 78
5.1 Comparison between Native and Non-native Code Execution ...... 78
5.2 Comparison to other Architectures ...... 80
5.3 Results of Simulation and Testbed ...... 82
5.4 Summary ...... 87
Chapter 6...... 88
xi Conclusion and Future Work ...... 88
6.1 Future work ...... 89
6.2 Conclusion ...... 90
REFERENCES ...... 91
xii LIST OF FIGURES
Figure 1 -1 Components of Wireless Sensor Node ...... 1
Figure 1 -2 Wireless Sensor Network ...... 2
Figure 1 -3 Wireless Sensor Applications ...... 3
Figure 1 -4 Sequence Diagram of Process Migration for WSN ...... 8
Figure 4 -1 Generic Steps in Process Migration ...... 57
Figure 4 -2 Process Migration Architecture for WSN ...... 59
Figure 4 -3 Record Structure for storing memory and process loop count ...... 75
Figure 4 -4 Code for computing processor load ...... 76
Figure 5 -1 Graph of Execution Time and Code Size ...... 80
Figure 5 -2 Blink Program ...... 84
Figure 5 -3 Process Migration between two nodes in COOJA ...... 85
Figure 5 -4 Process Migration between multiple nodes ...... 85
Figure 5 -5 Process Migration in Star Node Configuration ...... 86
Figure 5 -6 TelosB mote Testbed ...... 86
xiii LIST OF TABLES
Table 2.1Comparison of Agent Based Systems ...... 33
Table 4.1Variables in Migration Time Calculation ...... 62
Table 5.1 Execution Time and Code Size Comparison ...... 80
Table 5.2 Comparison of proposed process migration architecture with Dunkle et.al..... 82
Table 5.3 Evaluation Hardware and Software Platform ...... 83
xiv PUBLICATION
Native Process Migration in Wireless Sensor Networks. Syed Ishtiaq Hussain1, Huma
Javed, Tehseen Khan, Sara Shazad, Falak Naz Khalil, International Journal of
Distributed Sensor Networks, Volume 11, Number 10, 2015 doi:10.1155/2015/607143
(1.787 Impact Factor)
xv Chapter 1. Introduction 1.1 Preamble
The physical aspect of wireless sensor networks has given computing environments a new dimension. These tiny wireless computing devices combined with existing data networks have opened gateways to avenues of smart environments, smart technologies, and the Internet of Things (IoT). The main components of a wireless sensor node are shown in Figure 1-1.
Sensors
Power Source Low Power Communication Microprocessor System
Data Logging Memory
Figure 1-1 Components of Wireless Sensor Node
The power source is often a battery that can last for extended time. Low power radio transceiver is used for wireless communication to other nodes within the network. The sensors allow a node that take physical readings of the environmental factors such as humidity, temperature, light etc. The microprocessor facilitates application program execution. The sensor readings and configuration information can be stored permanently in data logging memory.
Sensors with limited capabilities can team up in a wireless network to perform huge
1 tasks that are distributed among nodes without any human intervention to explore new phenomena inaccessible to humans such as under the sea exploration. Wireless Sensor
Network (WSN) is composed of a group of nodes that connect to each other using short range and low power radio transceivers as shown in Figure 1-2 [1].
Figure 1-2 Wireless Sensor Network
WSNs have unique characteristics; they can self-manage to start functioning and create a network when deployed in difficult unattended environments. Sensor nodes are designed to be physically small, low cost and are typically equipped with short range wireless radio for exchanging sensed data not only within a distributed network but also across the network with other networks as well. Sensors can sense various physical measurements from surrounding environment. A sensor is an electronic device that monitors a physical phenomenon, and then provides a corresponding output in the form of electrical voltage. It works as a type of transducer by converting one form of energy to another form of energy, the latter being voltage. Sensors are used for sensing several types of physical quantities including light, pressure, humidity, pollutants, gases, direction, acceleration/motion, radiation, position, gas and liquid flow, touch, torque, rotation, electrical current, magnetic field, altitude, inertia, temperature, force, density, proximity, distance, seismic vibrations, smoke and sound
2 [2-7]. Sensors are based on MEMS (Microelectromechanical systems) [8], which allows very small micro Electro-mechanical devices to be constructed having low power consumption.
The WSNs have applications in several areas of day to day life as shown in Figure
1-3. Major applications of WSNs are in health and medicine [6, 9] military [10], environmental and weather monitoring [7, 11], body area WSNs [12-15], remote monitoring of seismic and volcanic activity [16, 17], disaster recovery[18]. In the domain of health WSNs have many applications such as, better diagnosis/treatment of diseases[19], detection of sleep apnea [20], fall detection in elderly people [21], and detection of cardiac problems [22].
Transportation
Industrial Smart Home Automation
Agriculture and Energy Control Livestock
Wireless Sensor Network Applications
Monitoring Health Care Environment
Building Security Structure Monitoring
Entertainment
Figure 1-3 Wireless Sensor Applications
WSNs can also be used indoors such as conference-room monitoring [23], or outdoors such as surveillance [24], pollution monitoring [25], energy monitoring [26], water
3 quality monitoring [27], early fire detection [28], pharmaceutical manufacturing [29], gas and oil industries [30], mining industry [31], railway industry [32], soldier health
[33], and smart homes [34]. In agriculture, they are used for data collection in farming such as moisture tracking, monitoring of nutrients, lighting, and temperature monitoring, herd and livestock tracking [35]. Also WSN have been combined with the
Internet, distributed systems and Internet of Things (IoT) to extend sensing applications [36-38]. So it is evident by looking at the above list that sensors are already everywhere around us and has even more potential.
Sensor in WSNs, make WSN very exciting because it has opened a whole new world of smart applications. Sensor based Internet of Things has added physical dimension to the internet. The evolution of computer hardware and hand-held devices shows that as micro-processors have evolved over time, the energy consumption has reduced, and processing speed, as well as memory, has increased. This is most evident from the developments in smart phones, which have powerful microprocessors with large memory and are powered by a small battery which can last for a considerable amount of time compared to previous years. These mobile devices have small physical size and use very little energy for computing and transmitting data via radio signals.
These smart devices have multi-core application processor, several megabytes of primary memory along with hundreds of megabytes of secondary storage space. They are equipped with various sensors, enabling them to sense external environment for various physical attributes such as acceleration, temperature, orientation, light, and proximity. With the introduction of 3G, 4G and 5G, mobile telecommunication has enabled users to use smart phones for mobile internet access and voice telephony. The application software on these devices includes games, biometric applications, data
4 capturing applications, web applications, and educational applications. Different hardware and software platforms that have been developed so far often require middleware, which enables applications to operate on cross-platform basis.
1.2 Middleware
Middleware is a type of software that extends services to application programs that are not originally provided by the operating system. It can be described as “software glue” [39-43]. Middleware hides lower level details and differences among competing architectures to expose underlying functionality uniformly across different platforms.
It can be referred to as a distributed collection of interfaces and services that exist between applications and operating systems to enable easier development and deployment of distributed applications. Examples of middleware include Object
Management Group (OMG) CORBA [44] Microsoft DCOM/.Net [45] and JAVA
RMI [46].
OMG designed Common Object Request Broker Architecture (CORBA) as independent vendor architecture for distributed systems. It consists of Object Request
Broker (ORB) and object management architecture (OMA). ORB establishes communications between clients and objects. Distributed Object Model was introduced by Microsoft to help with the execution of a program running on .Net
Framework [47]. The java remote method invocation (Java RMI) allows for the creation of distributed applications on top of java runtime environment (JRE). It is based on remote procedure call (RPC).
Middleware provides services and application program interfaces to aid the development of complex sensor applications. Middleware creates abstractions and interfaces to support integration, reuse and development of applications. Its main aim
5 is to hide the hardware and software heterogeneity of the lower levels of platforms and operating system environments. It also hides the distribution and communication details of the underlying layers from the client application programs. Middleware facilitates communications among distributed components in a distributed system, by establishing common services for general functionality commonly required by applications to decrease time to develop and maintain a system. Furthermore, it allows the developers to add new services and features without performing major changes to application programs. Non-functional features of application programs such as
Quality of Service (QoS), security, and reliability are additional benefits of using a middleware. Additionally middleware improves performance and increase scalability and stability of applications in distributed systems.
1.2.1 WSNs Middleware
The traditional middlewares are primarily targeted at wired networks with abundant resources. However, they are not suitable for WSNs for the following reasons.
1) Wired networks have more resources compared to sensor networks, whereas
nodes in the WSN run on small batteries compared to wired networks where
each node has a continuous power supply available.
2) WSNs run autonomously most of the time, whereas wired networks are
constantly managed by a network administrator.
3) WSNs are often deployed in harsh conditions, and their topology may change
with time more often, compared to wired networks, whose topology is almost
always fixed. Operating systems for WSNs are resource limited and are not as
mature as other operating systems for devices such as personal computers and
servers.
6 Some example of Middleware for WSNs includes Mate [48], Magnet [49], EnviroTrack [50], Impala [51], Milan [52], Cougar [53], SINA [54] and DsWare [55].
1.3 Process Migration
Process migration originated in distributed systems[56]. It refers to moving a process between nodes during execution. Process Migration moves live (or suspended) processes in a distributed environment. The term live migration refers to the transfer of a process from one machine to anther machine, during the execution of the process.
Process migration is widely used in mobile computing frameworks including cloud computing [57], ubiquitous computing and smartphones [58-69]. Advantages of process migration include improved fault tolerance [70, 71], efficient system administration, resource sharing, data access locality, distributed computing [56], and dynamic load distribution/balancing. Traditionally process migration has been available in distributed processing environments such as computing clusters.
Examples of such system include OpenMosix, which was precursor to Sprite OS at
University of California, Berkeley.
The sequence of steps for process migration in WSNs is shown in Figure 1-4. Process migration is accomplished in the following generic three steps [56].
1) Suspending a process to be migrated at the source node
2) Sending process state, memory space and executable code over the network
to the destination node
3) Restoring process at target node using information received from the source
node
7
Figure 1-4 Sequence Diagram of Process Migration for WSN
1.3.1 Process Migration Scenarios
It is a known fact that more energy is consumed in transmission, then on processing in a WSN, but this might not be always true [72]. If solar powered sensor nodes are used, then some nodes might be under full sunlight, while others are in the partial or full shade. For those nodes which are under bright sun light, energy might not be an issue because power is being delivered continuously from the solar cells to charge the batteries. In such situation, if several processes are executing on different nodes of the network, the processes should preferably be moved to nodes that have less energy issues. This helps in preserving energy resources of those nodes which do not have access to a renewable energy such as sun light.
8 It has already been established above that, energy spent on transmission is more than any other activity. However, the amount of energy spent on transmission maybe variable and is also dependent on the proximity of receiving node (the distance between two nodes). If two nodes are nearby, they need lower signal strength in order to communicate with each other, compared to the case where nodes are far apart from each other and need a strong signal, which use more battery power. So, the nodes that are nearby can easily exchange data and migrate programs using lower power signal.
To motivate process migration for WSNs following scenarios can be considered.
(1) Node shut down caused by the drained battery.
In this scenario, when a node is in use over a long period of time, it would have accumulated useful work since bootup, and some long running process may be executing on this node. Since precious energy has already been used, therefore process migration would be useful in this situation. Before a node shuts down completely, a long running process should be migrated, which helps in saving energy and processing time.
(2) Overloaded Node.
In this scenario, if a node has too many processes, they would quickly drain its battery. To optimize the battery time, one or more processes may be migrated to other nodes in the network with more energy availability. Such balancing of processes between nodes would optimize the processing time and optimize use of energy in the network.
9 1.3.2 Issues in Process Migration
In view of the above discussion it may be concluded that there are several scenarios in which process migration will prove beneficial to WSNs. However, there are several issues which need to be solved before a live executing process is moved to another node. Some of the issues are:
(1) Redirection of Input/output.
When a process is performing reads and writes to files that are on a specific machine on which the process is executing, there should be some mechanism for access redirection to these resources after the process has migrated to a different node.
The redirection of I/O can however have disadvantages relating to security and reliability. The particular problems in security are node authentication and non- repudiation. The reliability concerns include broken connections, and node failures.
(2) Inter-process communication.
Processes in distributed systems typically use messages for inter-process communication. When a process P migrates to new node, messages destined for the process P which was previously on a machine M, and is now on machine N needs rerouting of messages from machine M to N. The machine M, has to keep track of the process P to reroute the messages. The factors which can affect inter-process communication management of message queue, and network connectivity.
(3) Shared memory.
Several processes can join a group of communicating processes by using shared memory segment. After a process migrates, the shared memory is still required to be accessible to the migrated process after migration takes place. The access to the
10 distributed shared memory may reduce speed of execution of a migrated process as it has to access shared memory remotely through the network. The main issue is the efficient management of address space information, and efficient sharing of the address space information among nodes.
Operating systems keep a variety of information about processes in the form of tables and states for currently executing processes. Most of such information cannot be copied to the destination system, but have to be modified and reconstructed on the target machine, this include process table and process address space.
Desirable features of good process migration are as follows.
1) Transparent access at object level such as files and devices ensures that a
device or data object can be located on any node in the network and also can
be accessed from anywhere.
2) Inter-process communication transparency ensures that processes would not
be affected by any changes in execution environment before and after
migration has taken place.
3) Interference minimization ensures that duration of migration would be
minimized therefore the time a process spends in frozen state is also
minimized.
4) Minimizing Parent Node Dependency makes sure that the migrated process
is least dependent on the node from which it migrated.
5) Minimizing network bandwidth ensures that relocating a process uses the least amount of network bandwidth.
Issues in process migration pose several challenges in WSNs. Problems occur when a process on a node depends on a resource which is only available locally at the native
11 node and is expensive to move. During the migration of a process, several components of the address space of a program have to be transferred including process state (input/output buffers, interrupt signals, registers values, etc.), address space (code, data and stack). To transfer address space, several options exist, which include Transfer-on-Reference [73], Pre-transferring [74], Total Freezing [75].
The first approach is the Transfer-on-Reference approach. In this approach the process is restarted at the destination node; the address space of the process is migrated page by page. The pages related to the process are retrieved from the source node as the process demands them. Compared to the Transfer-of-reference approach, in Pre-Transferring, the address space of the process is transferred while the migrating process is still executing on the source node, and when the transfer is complete, the updated pages are transferred. In Total Freezing, the process is not executed while the address space of the process is being transferred to the target node.
In the above section advantages and issues during process migration have been highlighted which shows that it is possible to implement this technique in WSN, hence, the next section presents the research problem which is addressed in this thesis.
1.4 Problem Statement
In WSN nodes, failure is a very frequent and common problem. If a node fails, the process and data are lost. In case of physical destruction, the data and programs cannot be recovered. However in case of depleted batteries recovery of nodes is possible. On a process migration enabled nodes, as soon as the battery’s life crosses a certain threshold, the node can transfer data and code to another node which has more energy and memory. Process migration can be used for migrating processes which have been processed partially and thus optimize the use of energy. In a WSN, when a
12 node fails during operation, due to hardware failure, depleted battery, or shortage of memory or storage space, the node loses both processes and data. The data may be recovered as it is logged in flash memory, but the process state may not be recovered because it is stored in random access memory which is volatile. The main faults that can affect a WSN at any time possibly include the following resource shortages and network issues [76].
1) Energy
2) Centralization
3) Availability of memory space and processor time
4) Hardware failure
Processing and communication on a wireless sensor node consume drastically different amounts of energy. More energy is normally spent on transmission in sensor networks rather than on computing [72]. Wireless sensor nodes may be powered by batteries and may be able to harvest energy from externals sources such as solar and electromagnetic radiation [77]. In order to conserve energy, nodes have to manage power dynamically [78]. A better approach is to compute information locally instead of sending it to the base station. In practical wireless sensor networks, all nodes may not have the same level of energy as all the batteries are not exactly identical and each node uses the battery at varying level. In case of depleting battery, if a node is shutting down too soon because of a depleted battery, there must be a mechanism to transfer the process using process migration to another node which is idle or is more resourceful. It should be possible to move a process from one node to another along with all of its resource. In some designs, nodes might use battery charging sources such as solar cells to charge their batteries, therefore replenishing their batteries
13 regularly. Nodes with sufficient battery charge may run compute intensive jobs while nodes with less battery charge should avoid executing heavy processes to conserve battery. In the current WSNs, the nodes either send data continuously to the base station node or perform simple data aggregation in the form of cluster heads, which aim at decreasing the total number of transmissions throughout the network. Each node might transmit sensor data at regular intervals and continuously or at irregular intervals and only when necessary.
Centralization in WSNs is present in the form of base-station. The control structure in
WSNs is often hierarchical. A system can perform better if its control is de- centralised, by being resistant to faults and security threats. In a distributed wireless sensor any one of a more privileged set of nodes with abundant energy supply can assume the role of the base-station.
WSN nodes have limitations due to size and cost of hardware components which limits the memory size, storage size of a process. Often nodes come with memory space ranging in kilobytes or megabytes, program storage space in the range of kilo to megabyte and processor frequency measuring several megahertz which is very limited in terms of storage and processing speed. These limitations call for smaller programs and low process concurrency. Each node in a WSN can have different set and number of processes. The nodes which are running at full capacity may affect their batteries and deplete sooner than those nodes which have fewer numbers of processes running on them.
In addition, a task on a node may request more memory or may need more processing power or time. If these resources are not available, the task cannot continue to execute and has to be terminated. Hardware failures can also affect the performance of a node.
14 Such types of failures can include physical damage to sensors and battery. These can result in partially functioning nodes, which can no longer sense and process data successfully. Physical damage to node hardware or manufacturing defects can cause complete or partial failure of a node. In the case of partial failure, unfinished processes cannot continue, but they can be resumed after the problem has been rectified.
To solve the above mentioned problems, unfinished processes can be moved from resource-scarce nodes to other resource-full nodes, to save both time and energy in the wider context of a WSN. A process which has already consumed precious resources such as energy should not be allowed to terminate without completion. Therefore, transfer of a live executing process can not only help in managing resources and avoid failures but most important of all save energy. This makes a WSN more robust and fault tolerant. The main challenge addressed in this thesis, is the design of an efficient process migration architecture for WSNs.
1.5 Design Goals
Although process migration is a relatively old feature in various conventional operating systems, yet as mentioned above, no known process migration mechanism is available in WSNs. The main goal of this research is to develop a complete process migration middleware framework for migrating live processes on the wireless sensor nodes. The process migration middleware for WSNs has the following design goals.
1) To be energy efficient
2) To be implemented as middleware on existing WSNs.
3) To allow for migration of native processes
4) To implement and evaluate the proposed architecture on a real testbed of
15 motes to gain a better understanding of problems and benefits of process
migration.
This thesis presents a framework for the migration of a live executing process from one sensor node to another sensor node in a WSN. The main motivation for incorporating of process migration in WSNs is better resource utilization, distributed computing, load balancing and fault tolerance. The proposed middleware architecture will allow process migration and process level fault tolerance. Based on resource information, the system allows processes to migrate among network sensor nodes as to better utilize resources available throughout the network.
1.6 Novel Contributions
In the previous sections, it was mentioned that the recent advances have prepared the ground for incorporating newer capabilities into existing WSN operating systems and platforms. It has also been established that WSN can benefit from incorporating a middleware framework for process migration. To the best of our knowledge based on the literature survey conducted for this research, this thesis presents first ever novel architecture for migration processes on WSNs. Following are the main contributions of this study.
1.6.1 Process Migration Middleware Architecture
A thorough literature survey has been conducted in order to fully understand WSN in general and process migration in particular. The objective of this survey is to understand the proposed area in detail and understand the main issues. This literature survey resulted in a list of novel requirements for the research proposed in this thesis and are highlighted in the design goals given above which resulted in the proposed architecture.
16 The proposed architecture is a resource-aware, lightweight middleware designed for process migration in a homogeneous WSN. The migration architecture is lightweight because, it has minimal design rather than implementing a whole new layer of software such as used in virtual machines that are heavy on resources.
The main novelty of the proposed architecture is the migration of a live active process from one node to another node along with its state so the process can resume processing on the new node exactly from the same point it stopped on the previous node. The advantage of this migration is that it will not only save energy and other resources but also make the system more fault-tolerant, in addition to balancing the load evenly among nodes. Whenever a node’s energy reaches a specific threshold, it would try to migrate an active process to another node. Migrating active process will ensure that not only the process will run to completion but also the resources it has consumed so far are not wasted and used efficiently. The proposed architecture is adaptable as it is neither hardware nor software dependent rather it is platform independent. The proposed architecture can be implemented on top of any standard operating system in WSN and will be present on all individual nodes, therefore it is scalable.
Migration manager is the main novel component of the proposed architecture; all the other components are dependent on it. All decisions about the migration are handled by this component. It helps in managing and coordinating requests by different nodes within the network and also decides on the basis of resources the target node from which a process will be migrated or the source node on which a process will be received. It helps in sending and receiving the process along with its state from one node to another.
17 Another contribution of this research is that, nodes in the proposed system can also be configured at post-deployment phase which makes the system robust and flexible. In existing systems the nodes are preconfigured and it cannot be configured after deployment. The base station in our scenario is a powerful node with which the users have direct interaction and using this base station as a gateway the user can access nodes of the WSN. New applications can be installed, or updated if required through this base station by erasing the existing software on the nodes. The process will be migrated to the nodes which need updating or new installation and reconfigure them.
The architecture might further work as a platform for parallel and distributed processing where a process automatically spawns threads of its own and then distributing those threads to different nodes and collects outputs from individual nodes, aggregate them into a final result that may be sent back to the base station.
The proposed architecture is flexible and new modules if required can be added to the architecture without affecting the existing components such as security module. The process migration middleware allows the migration of the processes between nodes based on the same hardware and software architecture.
The proposed middleware is resource-aware because it continuously monitors the battery charge and free memory using the Resource monitor module, which is also a contribution of this architecture. If there is a request from another node for process migration, the node will check its resources and if available it will send an acknowledgement to other nodes. Resource monitoring also helps in distributing the tasks evenly within the network.
The proposed architecture not only improves resource management and introduces work-load balancing by migrating processes among nodes. In load balancing the
18 system tries to optimise the energy consumption across the nodes in the network by distributing processes evenly among nodes according to resources demand and availability of the resources on nodes.
1.7 Thesis Structure
The thesis is organized as follows.
1) The second chapter describes the WSNs and various properties along with
fault tolerance in WSNs.
2) The third chapter surveys process migration on various platforms other than
WSNs.
3) The proposed process migration architecture is presented in chapter 4.
4) Chapter 5 presents implementation details and evaluation, while chapter 6
focuses on future directions.
1.8 Summary
WSNs consist of wirelesses connected nodes equipped with sensors. These networks find numerous applications in diverse fields such as health, medicine, remote monitoring, agriculture, internet of things and many others. Rapid advances in hardware technology and shrinking hardware footprints have enabled to run complex multitasking software systems on wireless sensor nodes. One of the important types of software vital to the operation of WSN is middleware. The purpose of middleware is to establish common services to make application development easier and provide a uniform application programming interface to network services. This thesis proposes a new middleware architecture to enable live migration of executing processes between nodes. Process migration finds applications in cloud computing, ubiquitous
19 computing and mobile computing. It improves energy consumption and fault tolerance of the network. The design goals of process migration for WSNs are energy efficiency, implementation on current sensor network platforms, and migration of native binary code. The contributions of this work include process migration middleware architecture. The architecture for process migration is component based and flexible enough to be extended with more features in future.
20 Chapter 2. Overview of Wireless Sensor Networks
The first chapter highlighted the benefits and importance of process migration in
WSNs while introducing novel process migration architecture. This chapter describes
WSNs in general, including characteristics, physical constraints and fault tolerance.
Moore identified that on the integrated circuits, the number of transistors per square
inch double every year [79]. With the advancements in computing as per Moore’s
law, the hardware in laptops, cell phones, GPS enabled devices, Radio Frequency
Identification (RFID) tags and systems, general purpose computing has not only
become cost effective, and portable but mobile and distributed as well, thus,
becoming part of our everyday life. Using Commercial off the shelf hardware
components (COTS), is now more affordable to create small pocket size and hand-
held device which embeds enough computing power to handle moderately complex
tasks such as monitoring surrounding environment, store sensed data and process it
locally. Such systems can now run entire operating systems such as Linux. An
example of such devices is RaspberryPi [61]. Recently Internet of things (IoT) allows
everyday items and devices to have built in Internet connectivity, thus enabling them
to transmit and receive data from the Internet [80, 81]. This has resulted in new
technologies such as IoT based on the idea of smart objects dating back to Mark
Weiser’s concept of ubiquitous computing [82]. It makes use of embedded computing
elements into user environment to provide seamless integration with such artifacts as
the human body, clothes, tools and equipment, home, office, cars, airplanes etc. Major
applications of WSN include environmental monitoring, habitant study, military
surveillance, reconnaissance, search and rescue, process control in factories,
monitoring of heating and saftey in buildings, smart homes, and patient monitoring.
21 2.1 Structure of Wireless Sensor Networks
A WSN is a network a group of spatially distributed and autonomous computing devices containing sensors and radios for communication. These devices are termed as nodes, and their purpose is to observe physical and environmental conditions. A
WSN may typically contain from a few nodes to thousands of nodes. These nodes share information with each other and cooperatively process sensed data. At the time of initial deployment (which is typically random or ad-hoc), sensor nodes establish multi-hop connections with each other and perform self-organization to use the network infrastructure. The sensors on each node then begin data collection. The position of each node is sensed by the onboard global position system (GPS) sensor on each node, if the nodes have GPS sensors. The GPS locations and sensory data are then used for creating an environmental map. Each node in a WSN has limited capability, however the whole network works as aggregate to provide useful service.
The information from the network is accesses by query injection and result gathering from special nodes named base-stations. The base-stations are the main access interface between users and WSN. To make a WSN more accessible it may be connected to Internet for sharing information over the World Wide Web.
2.1.1 Components of Wireless Sensor Nodes
A wireless sensor node typically consists of computing, sensing, communication, actuation, and power components. The central processing unit (microcontroller), random access memory and non-volatile flash memory are built into a single circuit and occupy a few centimetres. These components are normally placed on a single and packed in an area of a few cubic inches. A sensor node powered by 2AA batteries can last for up to three years.
22 1) Sensors.
WSN nodes have onboard MEMS sensors [8]. These sensors allow
nodes to capture physical measurements such as light, temperature, humidity,
and vibration etc. These sensors are physically very small and consume
minute amounts of power.
2) Radio Transceiver.
The radios on wireless sensor node use 2.4 GHz radio based on either
IEEE802.15.4 or IEEE802.11 (WiFi) standards or proprietary radio, which
are usually 900MHz [1, 4]. Recently many WSN platforms use ZigBee due to
its low-power consumption [83]. On a sensor node, high data rates and
frequent radio transmissions result in more power consumption. The software
for communication normally consists of media access control (MAC) and
network layers. MAC layer is designed to be energy efficient, and
independent of network size, density and topology [84].
3) Microcontroller.
Wireless sensor nodes use high-performance CPU which consumes
very low power [84]. Low energy consumption is necessary for prolonging
the battery life. These microcontrollers are typically based on System on Chip
(SoC) technology that can integrate a full computer with storage and I/O
devices on a single chip [72, 85-87]. In the recent years, open source
hardware for wireless sensor nodes has also been tried [88]. A WSN node
periodically wakes up and sleeps to transmit data. In each wake-up and sleep
cycle the radio is powered on, data is transmitted and then the radio is turned
23 off. This is done to conserve the energy used by the radio transceiver. The
transceiver has to efficiently transmit a signal, and then allow the system to
go into low power mode or sleep mode to minimize power consumption. The
processors used in WSNs support low power modes and sleep modes.
4) Battery.
WSN nodes use low power and energy efficient components which are
typically powered by 2AA batteries. The lifetime of battery can extend up to
two to three years without replacement or recharging. These batteries
typically have alkaline and lithium based chemistry. Power to nodes can also
be delivered using solar cells [89].
The hardware of WSN nodes is normally an SoC (System on Chip). SoC technology is capable of integrating complete systems on a single chip. An example is UC
Berkeley’s motes which are built on SoCs from Atmel, Intel, and Texas Instruments.
On these motes, RF circuits enable short range wireless data exchanges with very low power consumption. The sensors on these motes are based on Micro-Electro
Mechanical Systems (MEMS) technology.
The 802.15.4-based Zig Bee protocol provides short range and low speed for wireless personal area networks (WPAN). It has been used by MICAz. Environmental variations and external interfaces as well as sensor design cause sensor readings to be noisy. The noisy readings are passed through filters such as Kalman filters [90] to remove noise and make data easy to interpret. On WSN nodes computation is generally energy efficient, so it consumes less power when compared to radio communication. To minimize the number of transmissions, a set of sensor nodes in
24 close proximity should collaborate more often by lowering the transmission signal strength.
2.2 Wireless Sensor Network Characteristics
In wireless sensor network, an application running on node can “sense-only”, or
“sense-and-react”. The sense-only applications do not have actuators while sense and react application have an actuator to change the environment by making decisions on sensory input. In a typical WSN, nodes can communicate in “one to many”, “many to many” and “many to one” communication relationships. For WSNs node mobility can be of three forms, (a) “static”, (b) “mobile nodes” and (c) “mobile sinks”. In static applications, nodes and sinks do not move, once they are operational. In some applications, mobile nodes are attached to moving objects such as robots or animals.
In mobile sink applications, nodes can operate in both static and mobile modes, and data is collected opportunistically when sensor nodes come into proximity. Nodes can be distributed spatially on “global” and “regional” scales. In global applications, processing involves the whole network, whereas in regional applications processing is involved within a subgroup of the sensor network. Sensor applications can be
“periodic” or “event triggered”. Periodic applications process sensed data continuously. Event triggered applications stay quiescent in event detection mode, where the sensors are regularly sampled without any communication involved.
Whenever a sensor value crosses a threshold, the application can initiate distributed processing throughout the network.
The characteristics of WSN that make them useful are described as follows [3]:
1) Low cost.
25 A WSN node is by design low cost. This enables the deployment of any number of nodes to monitor a physical environment. The low cost of WSN node is enabled by the low cost components.
2) Energy efficiency.
Energy is used by computation, communication and storage on a sensor node.
The protocols and algorithm development have to focus on minimizing the power consumption.
3) Communication Capabilities.
WSN nodes send and receive data using radio transceivers. These radios have short range. The radio channel can be unidirectional or bidirectional. In hostile environments the wireless communication is required to be robust, secure and resilient.
4) Security and Privacy.
To protect nodes from unauthorized access and malware, a security framework is required. Onboard storage of data on sensor nodes should be encrypted to prevent misuse of information, whenever a node is captured physically by an attacker.
5) Distributed sensing and processing.
In typical deployements of WSNs, nodes are randomly or uniformly distributed in large number over a wide geographical area. After deployment, each node collects, sorts, processes, aggregates and finally sends the data to the sink or base-station node.
6) Dynamic network topology.
26 WSNs are topologically dynamic. Whenever a sensor node fails the data traffic going through a node would be disrupted and several directly connected nodes would be affected. To accommodate failed nodes, network topology is reconfigured and changed dynamically. To achieve dynamic topology reconfiguration, each node has to have dedicated software function to detect topology changes and update node’s internal routing information.
7) Self-organization.
Sensor nodes in a network should be able to organize themselves as they are deployed randomly in a hostile environment. The sensor nodes are configured using distributed algorithm to create a network topology autonomously.
8) Multi-hop communication.
When a WSN is deployed in field, nodes establish routing paths to move the data to sink nodes. A multi-hop route is established, whenever a node wants to transmit data to another node that is not directly connected to it, but can be reached through a series of interconnected neighboring nodes.
9) Application oriented.
WSNs are domain specific, and highly dependent on the targeted problem. The nodes are deployed randomly and their spatial span range from few meters to hundreds of kilometers.
10) Robust Operations.
Typical WSN deployments are over a large geographical area and sometimes
27 the environment is unattended and hostile. The sensor nodes are required to be fault tolerant and error tolerant. To make nodes robust, they should be able to self-test, self- repair and self-calibrate.
11) Small physical size.
Sensor nodes are small in size with the restricted radio range. The small size limits the communication capabilities; therefore sensors nodes cannot send transmissions very far.
2.2.1 Wireless Sensor Network Topology and Software
The WSNs architecture consists of network topology, sensor nodes, operating system and sensor application programs. WSN nodes are topologically organized in one of the three types of network typologies. In the star topology, each node has direct connection to a central node called gateway. In the tree network, each node establishes a connection to a node higher in the tree and then finally to the gateway.
The data is routed from the lowest level node up to the gateway. The mesh networks can connect each node to all nearby nodes in the network and transfer data using the most reliable and shortest route. A WSN may include an internet-gateway that enables the network to be connected to Internet.
The first purpose built operating system for WSN was Tiny-OS. It uses nesC for application programming and is based on the event driven model [91]. The other popular operating system for WSNs includes Contiki [92].
WSN sensor applications are based on three kinds of algorithms [3]. The first type of algorithms is Centralized algorithms. These algorithms, when run on node gather data from other nodes and aggregate the data into useful result. The second kind of
28 algorithms is distributed, which employ message passing for the data communication.
The third type of algorithms is location based, which allows the nodes to acquire data from other nearby nodes in close proximity. The choice of algorithm decides the route and protocol for the network. The localized algorithms force routing protocol to optimize network usage among neighbouring nodes. In the centralized algorithms, message aggregation can be employed before the data goes to a central node. A distributed algorithm must support peer-to-peer communication efficiently. Location based algorithm need support from global position system (GPS), which increases the hardware and software cost of the WSN.
The resource limitations imposed on WSNs force a WSN design to meet the following requirements [4]:
1) Autonomy.
There is no centralized dedicated node for routing decision in a WSN. Each node is autonomous and implements functions for routing and communication.
2) Energy Efficiency.
WSN routing protocols aim at prolonging battery lives, and try to achieve connectivity between nodes optimally. In the most of the applications of WSNs, batteries are not accessible or replaceable, therefore prolonging battery life is important [5].
3) Scalability.
The number of nodes in a WSN may range from a few to hundreds; the routing protocol should be able to work with any number of nodes. In addition new nodes
29 may also be added to the network at any time.
4) Resilience.
Nodes can fail unpredictably, due to depleted batteries or physical damage.
Sensor nodes should be able to route information in a frequently changing topology of nodes.
5) Device Heterogeneity.
Most of the applications of WSNs involve homogeneous collection of nodes.
However, sometimes heterogeneous nodes have to be used. For heterogeneous collection of nodes, a routing protocol has to communicate with different types of nodes using different communication systems.
2.3 Physical Constraints on Wireless Sensor Networks
Each node in a WSN is equipped with an energy source, which is typically small sized low voltage battery. Energy is mainly used for communicating and processing data in a sensor node. Communicating 1KB of data by 100 meters uses as much energy as processing 3 million Instructions [72]. It is superior to run/process the data locally than to transfer raw data among sensor nodes. Following constraints impose limitations on the operations of WSNs.
1) Small physical size of node
2) Low cost per node in manufacturing
3) Small battery size and weight
4) Limited Processing Power
5) Short distance radio transmissions
30 To increase the processing power, radio-signal range and battery lifetime, bigger battery and more electronic circuitry is required, which in turn increases the cost. The design of a WSN node is a tradeoff among cost, physical size, battery lifetime, radio- signal rage, and processing power.
2.4 Programming Paradigms for WSNs
Programming paradigm refers to the use of abstract constructs used for building a program. These constructs include functions, variables and steps for computations such as assignments, iterations and program flow control. There have been three major paradigms for programming WSNs.
1) Imperative paradigm.
The program instructions explicitly describe how the program state is to be changed. This paradigm is further subdivided into sequential and event-driven paradigms. In sequential paradigm, program instructions are executed sequentially from the first instruction of the program to the last instruction of the program, whereas in event driven paradigm, code is executed in response to internal and external events.
2) Declarative.
In the declarative paradigm, the goal of computation is specified without specifying how the computation is to be carried out. An example of such paradigm is
SQL used in database management systems for information retrieval and manipulation.
3) Hybrid.
31 This approach is the combination of imperative and declarative paradigms. An example is nesC language which provides an imperative event driven paradigm using split-phase operations. The operations are executed asynchronously to provide parallelism. Application development using hybrid paradigm is often complex and difficult to understand.
2.5 Operating System for Wireless Sensor Networks
Wireless sensor nodes have resource constrained hardware; therefore operating systems for WSNs tend to be specialized. The first attempt on the operating system for WSNs was TinyOS [91]. Tiny OS was developed in nesC which is aimed at embedded systems. NesC is an extension of C language. It uses an event-driven model based on event handlers and tasks to process external events, such as sensor data. Other operating systems that use C language are Contiki [92], MANTIS [93],
SOS [94], LiteOS [50], NanoRK [95] . NanoRKx is different from Contiki and SOS as it supports preemptive multi-threading besides event-driven architecture.
2.5.1 Mobile Agent based Systems for WSNs
A mobile agent is an intelligent and autonomous program that can navigate autonomously. The agent can be distributed throughout the network, so multiple agents can collect local sensor data by using mobile executable code. Examples of such light weight mobile agent based systems are Mate [48] and Sensor Ware [96],
Agilla [97], ActorNet [98] Darjeeling [99] and Taka Tuka [100]. Table 2.1 compares these systems from several important aspects.
32 Table 2.1Comparison of Agent Based Systems
Architecture TakaTuka Darjeeling Contiki Agilla Agent Based No No No Yes Virtual machine Yes Yes No Yes Dynamic Linking- Yes Yes Yes Yes Liveloading Transfer No No No Yes State Transfer No No No Yes Resource No No No No EnergyMonitoring Aware No No No No Live process No No No Yes migration 2.5.2 Contiki Operating System for Wireless Sensor Networks
Contiki was developed by Adam Dunkels at the Networked Embedded Systems group at the Swedish Institute of Computer Science. It is a multitasking, portable, open source, operating system for embedded systems. The main features of Contiki are:
1) Contiki takes 2KB of RAM and 40KB of ROM on most platforms
2) Event Driven Kernel
3) Supports dynamic loading and unloading of applications at runtime
4) Preemptive Multithreading (uses proto threads)
5) Inter process communication among multiple threads using message passing
6) Supports TCP/IP using uIP and Rime
7) Open Source under BSD-style license
8) Portable
9) Contiki has been applied to applications such as aerospace, process control
and automation, household electronic equipment, and networking
2.6 Summary
This chapter discussed WSNs, their significance and their applications in various areas of life. A WSN consists of a collection of sensor nodes, gateway and possibly
33 may be connected to the internet. A wireless sensor node consists of the power source, sensors, microcontroller or microprocessor, permanent memory store and a communication subsystem. Important issues in WSNs are physical constraints, programming paradigms, routing of messages, operating systems, and network topologies.
34 Chapter 3. Overview of Process Migration
The previous chapter discussed general characteristics and architecture of WSNs.
Process migration allows for distributed processing as well as management of energy
and other resources, such as memory and communication links, files, processing time
across the network nodes. Moreover, utilization of the network resources can be
improved by distributing and redistributing tasks dynamically when the processes are
in the live execution phase. Major steps in process migration are the following [7].
1) Suspending the process on source node and resuming it on destination node.
2) Packaging and then transporting the process state from source node to
destination node.
3) Message forwarding from source node to the destination node to allow the
migrated process to receive data.
4) Routing of communication between collaborating processes after process
migration has occurred.
3.1 Process Migration Types
Process migration can be preemptive and non-preemptive [101] [102].
1) Non-preemptive process migration.
This type of process migration occurs before the execution of process has even
started. Because the process has not been started, preemption is not required.
35 2) Preemptive process migration.
In preemptive process migration, the process has already started execution; it is forcibly suspended by the operating system and moved to another node where it continues processing. Preemptive process migration is resource intensive since it needs checking and restoration of the process state, and construction of communication channels for inter-process communication.
3.2 Process Migration in Conventional Operating Systems
A detailed survey of process migration is presented by Smith et. al [103]. The authors describe design issues for process migration after studying MOSIX, Sprite, and Mach operating systems, and the advantages, disadvantages, and potential of process migration is presented. The main benefits of process migration are listed as: dynamic load distribution, fault tolerance, easy network administration, data access locality, scalability, heterogeneity, and access transparency. The survey also gives examples of microkernel’s and mobile agents. Smith also gives a survey of different implementation mechanism for process migration. The focuses of these mechanisms are of various processes migration design factors such as performance, fault tolerance and computational load balancing. The impact of these factors is described in detail.
Finally author proposes that if a system uses message passing, the overall design of an operating system with process migration is less complex compared to other approaches.
A detailed comparison of implementation of process migration is provided by
Thulasidasan [104]. The author compares various operating systems that support process migration including Condor, MOSIX, Sprite and MPVM. Various issues relating to allocation, scheduling, file system, naming, transparency and scale are
36 discussed in detail. In Amoeba OS [105], the process migration facilitates load distribution. In an Amoeba cluster multiple systems are linked together to handle variable workload or continued operation to avoid failure problems through power distribution to ensure continuous working of a system.
Process migration in heterogeneous systems has been studied by Milojivcic et. al [56].
Authors discuss different data formats and instruction sets in heterogeneous process migrations.
3.2.1 Check-point and Restore
The main component of all process migration architectures is process check-point and restore [106]. Check-pointing stores the state of a live running process and restore is responsible for restoring an instance of the check-pointed process from the stored state of a process. The process state data is typically stored in a file which is later on used for restoring the process. The file typically stores stack, heap and registers. The restorer can recover the state of a process from this file and resume the execution of the check-pointed process.
Check-pointing can be implemented by user library or may be provided as an operating system service. When implemented in operating system kernel as a service, it can facilitate the suspension and resumption of a running process for very long durations over multiple reboots of the machine. Example of an actively developed system for check-pointing is CRIU (Check-point and Restore In User space) [106], which provides check-point/restore for Linux processes. CRIU allows the user to check point and restore a running process or groups of processes. Check-pointing is the core component of process migration implementation. In our architecture check- pointing and restore are used for storing process execution state for a later resumption.
37 Check-pointing and restore concept can be applied in wider context to the whole
WSN. Lo¨scheret.al. [107] present an architecture for check-pointing and restoring the state of full WSN. From the preceding discussion, check-pointing can be implemented by user library or may be provided as an operating system service.
When implemented in operating system kernel as a service, it can facilitate the suspension and resumption of running processes.
3.3 Existing Process Migration Middleware Architectures for WSNs
This section reviews process migration. In the past process, migration has been extensively used in heterogeneous and homogenous distributed systems [56, 108].
A process is a basic component of any operating system. When a program is loaded into computer memory, and it is given resources by the operating system is defined as a process. A process consists of the data segment, stack segment, heap, register values, open files, open connections, child process, and other attribute related to an operating system which is used by the operating system to control the process. [109].
Process migration is the concept of transferring a live process between two machines.
A process moves from one executing system to another with all its address space and execution state. Before the migration is initiated the process is suspended, and when the migration is complete, the process resumes execution, where it left off last time before migration initiated.
Recent efforts on process migration, include LinuxPMI [110] for Linux clusters [106],
CRIU (Check-point/Restore In User space) for Linux systems [106], DMTCP
(Distributed Multithreaded Check-pointing) [111] and BLCR (Berkeley Lab Check- point/Restart) [112]. For smart phones and mobile computing, a frame-work for
38 migration of Android application to Cloud has also been proposed [113]
Process migration has been implemented in WSN based on agent based systems such as Agilla using virtual execution environments. Virtual execution environment has processing and memory overheads. Native code out performs virtual machine code at energy efficiency and execution speed. Dunkle et al. [114] have compared Java VM based code and a native code energy consumption, and conclude that native code is better than VM code regarding energy efficiency for extended duration tasks.
Process migration architectures can be divided into two types.
1) The first type of architectures is based on native process migration.
2) The second type of architectures is based on agents and virtual machines such
as Java VM.
3.3.1 Native Process Migration
The first type of architectures is based on native process migration. In the native code execution the program code directly runs on the processes without translation.
3.3.2 Agent Based Systems
Agents based systems have applications in gathering high-quality information on the
Internet, such as databases searches, transactions, diagnostics, and e-commerce [14].
Agents are highly portable and more secure as they are executed sandbox created by the virtual machine. The agents have the flexibility of moving from one machine to another with different hardware architecture during execution on a virtual machine
[108]. Table- 1 gives a brief comparison of the WSN middleware and operating systems which include BerthaOS [115], MagnetOS [49], Agilla [116], Mate [48] and
Contiki [92]. Several Java virtual machine has also been implemented on embedded
39 systems which include AOT (Ahead of Time Compilation) [117, 118]Darjeeling JVM
[99, 119], and TakaTukaJVM [100, 120, 121] Agilla is a self-adaptive application for
WSN using mobile agents, and allows agents to move from one sensor node to another during execution.
In virtual machine architectures applications called agents run on virtual machines, and are migrated from one machine to another while the application is executing.
During process migration, both the code and current state of the process has to be transferred across the network. The most important components which are transferred are data segment, code segment, stack segment, resource handles (unique identifiers to resources on the system) such as open file, network sockets process control block containing instruction pointer, process priority, process metrics, and privileges.
Although agents are very useful, the primary disadvantage of agents is an execution in efficiency. Agents take longer to execute because the bytecode has to be interpreted by the virtual machine, which takes more time, uses more energy and consumes more memory space compared to native code. Agents are have typically smaller code size executing for short duration, therefore, they are more suitable to be run as agents
(virtual machine based application programs), while long-running tasks should be executed as native code[114].
3.3.3 Process migration in Java
Sumatra [122] was the first implementation of strong mobility on Java platform. It was implemented as an extension with support for resource aware mobile applications. In 1998 Wasp [123] was released. It implemented a preprocessor that instrumented the user application code by inserting java statements that recorded the
40 original state and reestablish the state on target machine after migration. JavaGo
[124], released in 1999 also used the source code instrumentation for thread migration. It used mobile calculus [125] for controlling process migration. Source code transformations for converting strong mobility constructs to weak mobility code by Chakravarti et al. [126]. They recorded the current execution state of the source code, serialized the code and state and sent it across the network. JavaGo was extended to JavaGoX [127] by using bytecode-level transformations. In JavaGoX a method in byte code form is modified at byte code level for restoring and check- pointing execution state. This technique was also applied to Brakes [128]. Nomads mobile agent [129] developed a Java compatible virtual machine that allows virtual machine state capture and resource control.
Aroma [130] was developed to allow multiple concurrent threads to migrated by check-pointing and restore. Merpati [131] was also a modified Java virtual machine, which provided light weight API for check-pointing, recovery and migration of JVM.
D’Agents [132] supported multiple languages including Tcl, java and scheme while providing strong mobility for Java. CIA [133] used modified JVM debugger to perform state capture by accessing debugging information generated by javac compiler. JESSICA2 [134], which was developed at University of Hong Kong) implemented thread migration by using native conde instrumentation and register patching. It was used for thread distribution and load balancing in cluster environments.
41 Thompson and Weddle implement JPM (Java Process Migration) [135]. Their design goal to formulate efficient mobile computing, optimal process scheduling algorithms, logging process transfers, and process caching algorithms. The system allows any java process to be migrated to another java virtual machine by plugging into the Java
PM daemon. Bringing the process to the location where data is present is term as data access locality.
3.4 Homogeneous Process Migration
A platform or environment is homogeneous when all systems have the identical architecture as well as operating system. There are two ways for performing process migration in homogeneous platforms i.e user and kernel level process migration.
Homogenous process migration can be implemented at two levels, namely at user level and at kernel level [136]. In the user level process migration is done without changing the kernel of operating system. User level implementation have two problems. The first problem is direct kernel state inaccessibility. The kernel state can only be accessed by calling the kernel which is slow. The second is the Kernel level process migration. In this implementation process migration, the kernel of operating system is modified to support migration functionality. Kernel level process migration is quicker and efficient. There are five generic algorithms for homogeneous process migration.
(1) Total Copy Algorithm
Total copy Algorithm this is baseline algorithm for process migration. It first suspends the process, transfers state information, and afterwards resumes the process at the target node. The main advantage of this technique is that it avoids residual
42 dependencies. A residual dependency refers to the unremovable information at the source node after the process has migrated to the destination node. Residual dependencies decrease fault tolerance of a system.
(2) Pre-Copy Algorithm
In this algorithm, the process space is divided into pages [137]. The pages are copied one by one to the target node while the process is still executing on the source node in wsn. When all the pages have been transferred to the target node, the process is suspended on the source node and resumes execution on the target node. The main disadvantage of this approach it that if a page is modified at the source while pages are being transferred the modified pages have to be retransmitted. The second disadvantage of this approach is the management of virtual address space.
(3) Demand Page Algorithm
The demand page algorithm is inspired from demand paging in virtual memory management system [138]. It uses demand copying or copies on access. The key idea of this algorithm is that no virtual memory pages are transferred to the target node at migration time. Only process state information is transferred. After the process is resumed on the target node, it creates page fault. Based on these page faults the desired pages are copied from source to target node and cached at the target node. The benefit of low latency process migration and avoidance of unused pages. The main disadvantage of this approach is the overhead caused by the virtual address space management in source and target nodes. This problem becomes severe when a process migrates multiple times to other nodes in a network, as the source node has to be tracked each time the process migrates to a new node.
43 (4) File Server Algorithm
File Server Algorithm is based on the use a third machine called file server
[139]. The file server provides pages on demand without involving source node.
Before migration the source node copies the resource descriptors, process state, and address space of the process to the file server. The source node then asks the destination node to start the execution of the migrated process. Meanwhile, the source node concurrently sends modified process pages to the file server. At the start of execution of process, the source node has to handle frequent page faults, but eventually, file server handles most the page faults. This algorithm solves the problem of the pre-copy algorithm when a process migrates multiple times.
(5) Freeze Free Algorithm
The Freeze Free algorithm assumes homogeneous hardware and operating system [140]. Process migration is standard on multicore machines. It is efficient and fast on these systems as most of the resources include memory, files, sockets are present on the same machine.
3.5 Heterogeneous Process Migration
In heterogeneous process migration, processes are migrated across machines with different software and hardware infrastructures. Heterogeneous process migrations require operations like conversion and translation of data structures and addresses spaces. Heterogeneous process migration applies to those environments, where different hardware platforms are combined to solve a particular problem. There are four types of heterogeneous process migration [73].
44 1) Passive Object Migration
In the Passive Object Migration, data objects are passively transmitted and must be translated according to the target node platform [141, 142]. The code and state changes on object are executed once the transfer and translation is complete.
2) Active Object Migration
In the active object migration, the code exists both on source and destination nodes.
Such migrations only allow active data object is transferred and translated, therefore no code is migrated during migrations [141].
3) Interpreted Code and Active Object Migration
In this approach, the process is runs executable byte-code on an interpreter. To migrate an, object, only data and bytecode needs be transferred only. Because bytecode is smaller is size, the scheme is efficient in terms of the data transferred during migration.
4) Native Code and Active Object Migration
The native code directly runs in the bare processor hardware, and therefore does not need to be recompiled or interpreted at the destination node. This scheme also allows active objects to be migrated without the need for translation.
3.6 Advantages of Process Migration in WSNs
In the sensor data collection tasks such as seismic, volcano, snow, forest fires, battle field, data is more important and critical than the network itself. The sensor nodes which have been deployed in this way might need new configuration parameters to be installed at any time based on new data collection objectives. It is very difficult to
45 remove the sensor nodes from the field, bring them to the laboratory and install new software and modules to alter the functionality of the whole network. The two major advantages of process migration are described in (section 3.6.1) and (section 3.6.2).
3.6.1 General Advantages of Process Migration
Besides these, the following is a list of motivating factors for Process Migration in
WSNs:
(1) Dynamic Application Deployment. If operating system provides process
migration service, a wireless sensor node never needs pre-installation and pre-
configuration of a program in the laboratory. Instead when the node boots for the
first in a deployed environment, it would request the base station to download a
clone of the process to execute. When the download is complete, it will start
execution, and it would be stored on node’s flash memory for later execution
sessions. New processes can dynamically replace older processes in a deployed
network using process migration.
(2) Better utilization of heterogeneous resources. Nodes in a network may be
heterogeneous from resource aspect, such as battery capacity, available sensors,
processing speed, memory size, transmission power. A process can move to more
resourceful nodes if the process needs more resources in order to continue or
improve execution. For instance, if a node is low on power, or has some hardware
damage, before shutting down it can send the running process to a nearby more
resourceful node, without losing any work completed so far. This behaviour leads
to an overall fault tolerant network.
(3) Parallel and Distributed Processing. The architecture might further work as a
46 platform for parallel processing and distributed processing where a program
automatically spans threads of its own, distributes those threads on nodes and uses
out puts from individual nodes for aggregation into the final output. This system
would require program routing, master slave control in threads, load balancing
techniques and resource monitoring on network nodes. Process migration can
facilitate all the activities by moving processing from any node to any other node
in the WSN.
(4) Continuity or Processing. If a node is low on battery power, before shutting
down it can send the running program to the nearby resourceful node, without
losing any work completed.
(5) Dynamic base station. Any node can be transformed into a base-station by
migrating base- station/cluster-head processes to the candidate node. A base
station node is characterized by having more resources and software modules for
dealing with data aggregation and computing tasks. In the circumstances,
involving failure of a base station node, a worker node or backup base station
node can take over the task of base station node by migrating data aggregating
processes from the failing base station node, thereby keeping the whole network
functional, and always maintaining the existence of a base station in the network.
(6) Simplified kernel. The operating system kernel need only support basic services.
Such a kernel can be implemented as a micro-kernel. Other modules can migrate
to the node at a run time.
(7) Task management. Some processes may move through the network and perform
configuration or maintenance tasks on sensor nodes in an agent like manner. Such
47 processes do not need to be installed on each node. This leads to smaller basic run
time image size on each node, smaller program images on nodes, and reduces
flash memory size, as well as hardware costs.
(8) Ease of Deployment. New sensor applications can be programmed dynamically
using process migration. An instance of the process can be cloned across a group
of nodes to setup new sensor application. Some processes may move through the
network and perform configuration or maintenance tasks on sensor nodes similar
to agents. Agent processes do not need to be fully installed on each node but
migrate from node to node which saves code space on the entire WSN.
(9) Resource Management. Nodes in a WSN may have different resource levels,
such as battery level, or memory available. A process can move to more
resourceful nodes if it needs more resources. Long running processes specially
benefit from process migration as it allows transparent resumption of
computational work after migration to another node. Process migration can also
help in distributing tasks among nodes in a distributed processing by cloning
initialized tasks among sensor nodes. In data aggregation tasks such as cluster
heads, clustering tasks can be migrated from node to node instead of being
installed on every node in the network, thus saving a significant amount of code
space across WSN nodes.
3.6.2 Ubiquitous Computing
The ubiquitous computing [143] and more specifically IoT [144] emphasises computing everywhere and all the time by small, powerful communicating nodes.
WSNs are part of ubiquitous computing and IoT environments, allowing nodes to sense their environment, communicate with each other and react to changes in the
48 surrounding environment. Process migration can allow long running processes to migrate from node to node and allowing administrative tasks to be performed in ubiquitous networks. The main idea of ubiquitous computing is computing everywhere and all the time. Ubiquitous computing would be the most pervasive technology of future, such that computing would be embedded in everyday objects we use and are surrounded by, but nobody will notice it and might seem effectively invisible. The WSNs might become part of the ubiquitous computing environment, allowing embedded computing systems to sense their environment, communicate with each other and react to the changes in the surrounding environment. Process migration plays an important role by allowing automatic deployment and management of software using minimalist resources bandwidth leading to more autonomy of these sensor rich networks.
3.7 Load Balancing
The load is defined as the total number of running tasks, CPU utilisation, I/O rate, free
CPU time, memory space, etc. Load balancing aims at allocation of tasks to processors so that system wide resource utilization increase. One of the ways load balacing is avhieved is by using process migration [145].
3.7.1 Fault Tolerance in Wireless Sensor Networks
A system which can work even after partial failure can be termed as Fault Tolerant
System [146]. The most important role in a cluster based WSN is cluster-head. The cluster head performs certain tasks, such as aggregation of sensor data before transmitting the data to the base station node. Cluster head nodes are equipped with more hardware execute resource intensive operations for other nodes that would be prohibitively expensive to run on individual sensor nodes. On a sensor node failures
49 can be cuased by software and hardware faults, environmental factors, malware. A cluster-head node can fail due radio interference, de- synchronization of radio signal, drained battery, and physical dislocation.
The consequence of a failure on sensor node make the node reachable or may compromise data security. In physical dislocation a node cannot send sensor data anymore. In some situations a software bug can propagate it effects to result in complete failure of the network.
To build a completely fault tolerant WSN, it has to be brought to all the levels of abstraction of the networks. Hardware and software components such as microcontroller, communication and storage subsystems, battery, sensors, actuators, operating system, applications, and drivers might cause fault.
3.8 Initiation of Process Migration in WSNs
Process migration can be initiated for the following reasons.
1) Low battery
2) Low memory
3) Hardware failure
Common energy sources for sensors nodes are a battery, and solar cells. Because batteries have a finite supply of energy to deliver, efficiency is very critical to the operation of sensor nodes. In practical deployments, the battery levels on vary across nodes. The large variance in battery level occurs because of differing communication patterns and workloads on individual nodes. If on a given sensor node battery is low and cannot sustain node operation any longer, a mechanism can be devised to transfer long running processes using process migration to another node which is idle and has
50 more energy supply from a source such as a solar cell. On solar powered sensor nodes, some nodes may be under full sunlight, where as some nodes might be in the partial or full shade. For nodes which are not receiving sunlight, conserved use of the battery is a requirement to remain functional for a longer duration.
In such a situation, if there are several processes that are executing on the node, highly active process should preferably be moved to those nodes that have continuous energy supply and might run the processes at full processor speed. This can help in preserving energy resources of those nodes which do not have access to a continuous energy source such as the sun. It is more efficient to compute information locally instead of sending it to the base station.
Memory is also of limited-size and very crucial resource in WSN. If a node is running several processing threads simultaneously, very little free memory may be left. In addition, if a process demands more memory which is not available on the node, the requesting process can be migrated to another node with more memory.
3.9 Functional and Deployment Constraints in Process Migration on WSNs
Sensor nodes suffer from following inherent functional and deployment constraints.
1) Resource Dependencies
2) Security
3) Transfer size
Process migration can be difficult when resource dependencies exist, and security is also a concern. In ideal case, when a process migrates, it should transfer from one node to another along with all of its resources. An unmovable resource creates
51 resource dependency and can prevent a process from migrating to another node.
Instances of such resources dependencies include open files, node specific sensors
(only available on a particular node). Finally, the cost can increase when migrating a large process, because its code has to be transmitted, however, data compression techniques that would be used to shrink the amount of data to be transmitted. In wireless sensor nodes, a resource may be tightly tied to a node. Such a resource creates a resource dependency which has to be resolved before a process in the move from node A to node B. An example of such a resource dependency is an open file, which can be moved to node B, or a remote file link can be maintained from node A to node B. Both of these solutions can be applied depending on the size of file and frequency of reads and writes to the file.
There needs to be a security mechanism in each node that can verify the origin of a migrating process in order to avoid the movement of malicious processes violating the integrity of the whole network. Malicious activities might include, over loading the communication channels, data stealing, or disturbing the regular working of a network. However authentication methods such as SPINS [147], LEAP [70] and Tesla
[148] can be used for ensuring security.
The transfer size refers the memory image size of the process. The major cost process migration is the time used in copying the memory image of the process from source to destination machine. The time is dependent on high band width of connection used for transferring the state of the process from source node to destination node. The main solution to this problem is to minimise the image size, by compressing the image. The transferred process image includes the following components.
1) Data Segment(Heap)
52 2) Code Segment
3) Stack Segment
4) Resource Handles (open file handles, network sockets, etc.)
5) Process Control Block (IP register, Priority, Process metrics, Privileges)
6) Thread Control Blocks
The process control block (PCB) stores several values that are used for controlling and monitoring a process while it is executing. Following are the fields of the PCB.
1) Process ID
2) Parent Process ID
3) Privilege Level
4) Code Segment Base Address
5) Data Segment Base Address
6) Stack and heap segment base address
7) Top of Stack Pointer
8) Total Execution Time
9) Pointer to Resource Handle Table (such as open files, network sockets)
10) Execution State (such as ready, running, suspended, waiting/blocked)
11) Security Level PCB will occupy 16-byte memory, which is estimated cost.
Ideally, Process migration service should add a small overhead to the overall size of node software, but give more benefits by providing improved re-configurability, load balancing and overall utilization of the entire sensor network.
3.10 Types of Processes on Wireless Sensor Nodes
The process that executes on a wireless sensor node can roughly be classified in to the
53 following types.
1) Sensing and Transmitting Processes (These are the processes which do not
perform an computations, but only read sensor values and then transmit them
to other nodes)
2) Data Aggregation Processes (These processes merge and combine sensor
values received from several other nodes, process and condense the data
before sending it out the other nodes).
3) Data Compressor Processes (These processes collect sensor readings from
other nodes, compress the readings, and then send out the compressed data).
4) Security and Authentication Processes (These processes perform
authentication, encryption/decryption, and access control).
5) Algorithmic Processes (These processes perform complex computations on
sensor readings locally, perform analytical tasks, such as geo mapping, and
trigger actuators)
3.11 Summary
This chapter described process migration in detail. The major steps involved in migrating a process between two nodes are suspending the process at the source node, transferring the process to destination node and then restoring and resuming the process. Process migration in conventional operating systems is frequently implemented by check-point and restores method. Middleware for process migration comes in the form Agents. Process migration is also available in Java based applications. Process migration in homogenous systems can be implemented on user level or kernel level. The advantages and constraints on process migration for WSNs were described in the later sections.
54 Chapter 4. Process Migration Architecture for WSN
This chapter describes process migration and its architecture in detail which is the
major contribution of the research presented in this Thesis. Process migration
transfers a live running process between two machines. Although process migration is
a relatively old feature in various operating system, no known process migration
mechanism is available for any of the WSNs operating systems. In WSNs there are
many benefits of process migration such as dynamic load distribution of
computational tasks, fault resilience, improved system administration, data access
locality, computational scalability, and transparency.
4.1 Steps of Process Migration
A major component of all process migration architectures is process check-pointing
and restore mechanism. Check-pointing stores the state of a live running process. The
counterpart of check-pointing is restore which is responsible for restoring an instance
of check-point process from stored state of a process. The process state data is
typically stored in a file which is later on used for restoring the process. The file
typically stores stack, heap and registers. The restore mechanism can recover the state
of a process from this file and resume execution of check-pointed process.
The generic steps common to all process migration system as described by Milojicic
et al. [56] as shown in the Figure 4-1.
1) Process Migration Request is sent to a remote node. At the beginning node A
requests another node B to transfer a process P. Node B checks for resources
required by the process P and then may send accept or reject reply.
2) The process P is removed from source node by first suspending execution and
55 then identifying it in migrating state.
3) Communication is redirected temporarily by en-queuing arriving messages
destined for the migrated process P in a queue, and delivering these messages
to the process after migration is complete. This step runs in parallel with steps
4, 5, and 6.
4) The process state is extracted. The process state comprises of memory
contents; code segment, data segment, stack, heap space, register values;
opened files and message channels/queues and relevant kernel context. The
process state is typically kept on the source node until end of migration for
retry in case of failure due to some communication problem.
5) At the destination node a process instance is created which would be
initialized with the transferred state of the migrated process. This newly
initialized process is not resumed until all the required process state has been
received from the source node, which is enough to resume execution of the
process.
6) State is transferred and incorporated into a new instance on the destination
node. In some designs of process migration frameworks the complete state is
not necessary to be transferred; some of the state may be imported later on
demand. Such state information may include data files and network socket.
7) After step 6, references ae required to be forwarded to the migrated process.
Reference forwarding is required to allow uninterrupted communication
between cooperating processes on multiple nodes. Reference forwarding is
achieved in three steps. The first step is to register the present location at the
originating node of process P. The second step is to get the address of node B
where P migrated. After this step the senders to process P are notified of the
56 new location of the process P.
8) The new process instance is resumed when sufficient process state has been
brought in. At this stage the migration of the process is considered complete.
The original process from the source node can be deleted now.
Figure 4-1 Generic Steps in Process Migration
Steps for migrating a process are shown abstractly by sequence diagram in Figure 4-1 and described in detail above in steps (1) to (8). The source node contains a module called Migration Manager. The migration manager is responsible for initiating and controlling entire sequence of events for transferring a process from source node to target node. The Source Migration Manager suspends the process to be migrated and issues a migration request to Target Migration Manager which then replies with an acceptance message. When the Source Migration Manager receives the acceptance message, it saves a process image containing process code and state. The processed image is sent to Target Migration Manager which then creates a new process and
57 initializes it with code and state of the migrated process. Next, the migrated process resumes execution. An acknowledgement of successful migration is sent to Source
Migration Manager, which then destroys the original process.
4.2 Proposed Process Migration Architecture for WSNs
Process migration is a relatively old feature in various operating systems such as
Unix. However, for the WSNs operating systems, no known implementation or proposal exists. Process Migration can be added as a middleware service to existing operating systems. Implementing the proposed architecture as middleware offers several advantage, including modularity and extensibility, while using the existing hardware and software infrastructure.
The main focus of proposed research is on creation of a resource aware architecture for native process migration in homogenous WSNs [4]. The proposed architecture enables native live (running) processes to migrate between nodes. The proposed architecture is suitable for applications that require deployment of fewer nodes with expensive hardware infrastructure. It improves the fault tolerance of the network; reduces the power consumption of overall network, and enables distributed computing and load balancing [149] . The proposed architecture is a middleware layer implemented on top of the operating system. It provides several core services as described in next subsection.
4.2.1 Components of Process Migration Architecture for WSNs
Process migration architecture has been split into several individual components.
Figure 4-2 shows the complete architecture of process migration middleware for
WSNs. The architecture is based on generic steps common to all process migration system as described by Milojicic et al. [56]. The proposed architecture consists of
58 following seven components.
Processes
Resource Monitor
Program Request Migration Loader & Broadcaster & Manager Deserializer listener
Process Transporter Configuration Manager
OS
Figure 4-2 Process Migration Architecture for WSN
1. Migration Manager
The migration manager is the central component that controls other sub components.
It provides support and functionality for various tasks required in the migration of a process, such as check-pointing, restore, serialisation, broadcasting, listening to incoming migration requests and transportation of process code image and state data.
2. Program Loader and De-serializer
After the process state and code has been received at the target node, the program loader initializes process space from the image received, and then state de-serializer restores process’s local and global variables. After the process has been restored on the target node, the migration manager on the target node adds it to the scheduling queue to be resumed. Process migration steps have been summarized above in the previous section.
59 3. Data Transporter
This component is responsible for error free transmission and reception of data relating to process migration. This data includes the process executable binary code, program stack, heap space, global variables, and file handles.
4. Configuration Manager
The Configuration Manager stores configuration information, which includes battery and memory thresholds, as well as permissions and information relating to resources for controlling the behaviour of Resource Monitor.
5. Request Broadcaster and Listener
The request broad caster and listener component is responsible for broadcasting migration request to other nodes on the network. The listener waits for the migration request broad cast, using the component “Request Broad cast Listener”. It continuously listens to requests on the broadcast channel. After the request has been received by the request broad cast listener, it replies back with acceptance message to the sender. The sender then selects a target node, transmits the process state and executable code using process code image transporter. After the process state and code has been received at the target node, the program loader initialises process space from the image received, and then state de-serializer restores process’s local and global variables. After the process has been restored on the target node, the migration manager adds it to the scheduling queue to be resumed on the target node.
6. Resource Monitor
The resource monitor has two responsibilities: estimating battery charge and monitoring free memory. Battery charge estimation is done by battery estimator which
60 is responsible for predicting the amount of charge left in the battery and determines how much time the battery can sustain the node operation. It uses battery voltage sensor to sample the battery voltage periodically.
7. Logger
The logger stores information about the incoming and outgoing processes. It is an optional component, which can be used for determining the performance and monitoring of the network. The performance includes such variables as total number of processes migrated in a given time interval, and total time taken by each migration.
4.2.2 Core Services
The process migration for WSNs provides following high level services.
1) Process Loading. This service loads a process from the dererialized
representation of a process.
2) Data transportation. This service allows the nodes to process migration
related data to be transported between nodes in an efficient and error free
manner.
3) Process Serialization. This service allows a process to be serialized and
packaged its state into a single file.
4) Process Deserialization. This service unpacks code and process state of a
process from the serialized file.
5) Request Broadcasting. This service allows broadcasting of a process
migration request in a network.
6) Request Listening. This service allows listening for incoming process migration requests. 7) Resources Monitoring. This service allows different resources to be
61 monitored. 8) Event Logging. This service records information related process migration for performance evaluation purpose. 9) Configuration Query. This service allows reading and writing of
configuration parameters.
4.3 Performance Measurements for Process Migration The primary measure for determining the performance of process migration is the total time taken for migrating a process from source to target node. To compute the total time consumed in migration the following expression has been formulated. The
Tmigration is the total time a process takes while the migration takes place. The time unit for all the variables is milliseconds. Tmigration can be used for comparing differing implementations of the proposed architecture on different operating systems in a heterogeneous system. Each variable in the time calculation is described in Table 4.1.
Tmigration = Tbroadcast + Tresponse_wait + Tcheck-point + Ttransfer + Tunmarshel + Tresume
Table 4.1Variables in Migration Time Calculation
Tmigration time is taken to migrate a process from source node to destination node Tbroadcast time is taken by broadcasting the request message Tresponse time spent in waiting for a response to a request wait Tcheck- time consumed in check-pointing the process point Ttransfer time is taken by transmission of process data from source to the destination node Tunmarshel time consumed by the destination node in unmarshalling the state of the process Tresume time consumed in setting up symbol table memory initialization of process data Tmigration time is taken to migrate a process from source node to destination node
62 4.4 Process Migration Implementation
The goal of implementation is to validate a novel idea, and to evaluate the claims made by the proposal. This chapter describes the implementation details of the process migration architecture on Contiki-OS. The implementation of proposed process migration architecture focuses on evaluation and validation on real hardware and software platforms. The proposed architecture has been implemented in Contiki
[114] using run-time dynamic linking library which is part of standard Contiki distribution. The implementation is split into two separate modules, that is sender and receiver modules, both of which are installed on each node in a given WSN. The sender module on the WSN node is responsible for sending a process to another node, while the receiver module on a WSN node is responsible for receiving a process from a sender node. The overview of both the sender and receiver modules is presented in this chapter, and a detailed explanation of algorithms executed by sender and receiver node is also part of this chapter.
4.5 Overview of the Sender and Receiver Algorithms
The process migration implementation on has been split into two modules, namely the sender and receiver modules. These modules are described as follows.
1) Sender Module
The sender module on a node continuously monitors node’s battery and memory space. The battery charge is estimated by sampling battery voltage at regular intervals.
In the event of detecting low battery level or memory space less a user specified threshold, the sender module initiates process migration. The migration of process P begins at the source node A, which broadcasts a request for migrating the process P to
63 a recipient node B. Any node that has the required resources by P available i.e. battery and memory space, can send back an acceptance reply message to the requesting node
A. The reply from the accepting node B is sent back to the node A using a unicast reply channel. In case of multiple replies arriving from more than one recipient nodes, the sender node A selects the physically nearest destination node to minimize the energy usage by radio, by lowering the transmission signal length.
2) Receiver Module
The receiver module is responsible for accepting the migrated process. The receiver module waits for incoming requests from sender nodes. On the receiver side, if multiple requests are received, they are processed in the order of arrival one at a time.
Before proceeding to next request, the receiver has to complete the current migration request. The job of receiver module is to receive the check-pointed state of the process
P as data message from source node A, unpack the contents of the message contents and recreate the process on node B. After the process has been restored correctly it resumed from the point where it was stopped at the source node A.
The execution behavior of the sender and receiver modules is controlled by the configuration parameters. These configuration parameters store permissions and user settings for controlling process migration at runtime. The permissions and settings include permission for the system to block and unblock migration of different processes selectively. To optimize the storage space used by the configuration, parameters are stored in a text file.
64 4.5.1 Submodules
The implementation of sender and receiver modules is spread across the following low level sub modules. This is done to minimize the code size and improve the runtime performance.
1) The migration manager is implemented by the SENDER_NODE_ALGORITHM()
and RECIVER_NODE_ALGORITHM() procedures.
2) The serializer and deserializer are implemented by SERIALIZE_PROCESS() and
DESERIALIZE_PROCESS() procedures.
3) The transporter, which ensures error free delivery of the data between two
nodes is implemented by RECIVEPROCESSSTATE() and SENDPROCESSSTATE()
procedures.
4) Configuration Manager is implemented by the CONFIG module.
5) Request Boardcast and Listener are implemented by SENDBROADCAST() and
WAITFORINCOMINGREQUEST().
6) Resource monitor is expressed by the following Boolean expression:
(freemem > reqmem) AND (charge > bThreshold).
7) Logger is implemented by the LOG() procedure.
4.5.2 Overview of process migration between two nodes
This section explains the detailed steps that are carried out while migrating a process from sender node the receiving node.
1) The process P being migrated is removed from source node.
2) Process P, is suspended and marked for migration. At this stage, the source
node is ready for redirecting/rerouting any open communication channels
held/opened by process P.
65 3) Communication connections are redirected temporarily. This is done by
storing incoming messages to the process P in a message queue. The message
is delivered to process P after migration of P is complete. This step runs in
parallel with steps 4, 5 and 6.
4) The state of the process is copied (check-pointing). The process state includes
process heap, global variables, process stack, register values, and
communication protocol state (for example open file handles and open
network connections). The process state is kept on the source node until the
process has migrated successfully to the destination node.
5) The check-pointed state and executable binary code of the process P is
transported to the target node. If transport of the process state and code fails
due to some communication problem it is re-attempted. The new instance at
the destination node can not be started until the complete state of process P
has not been transferred from the source node.
6) The migrating process is loaded into memory and resumes execution from the
point of the last suspension at the source node. Process execution state is
copied into the newly created instance (Restore) on the remote node. At the
receiving end the target node unpacks the memory space and code from the
received data.. An instance of the process is created at the target node into
which the transferred state of process P is copied. This includes global
variables, heap and stack of process P.
7) Reference forwarding is done at the source node to maintain open
communication channels created by process P to other connected nodes in
WSN. The new location of process P is broadcast in WSN by the source node
which enables all other nodes previously connected to P to close connections
66 to process P and reopen connections to P at the destination node. The
message queue from step-3 is also delivered to the process P at this stage.
8) The migrated process P resumes execution at the destination node. This
marks the successful completion of migration for process P. There resources
held by process P post migration can now be released at the source node.
The sender and receiver end execute identical algorithms which are describe in the next two sections.
4.6 Sender Node Algorithm
Sender node algorithm is shown in Algorithm 1. In the algorithm for the sender node, the execution control enters into an infinite loop. The first step is get the memory and battery status. After getting status, the battery and memory thresholds are compared, if the thresholds are exceeded, a process is selected for migration. The battery and memory thresholds are set by the user. The migration consists of several steps. First, a process is selected for migration, and then it is suspended. After suspending the process, a message queue is initialized for temporarily storing messages directed to a process. Next local data belonging to process, which in this case is the stack and heap space is read from process memory space. Afterwards the algorithm sends out a broadcast request to other nodes in the network and waits for at least N replies. Upon receiving replies from accepting nodes, the sender then selects the nearest neighbour as the destination node. The process state is check-pointed and transported to the destination node. All the data connections of the process are closed and message queue is belonging to the process is transferred to the destination node. Finally, after successful completion of the migration, the process is removed from the source node, and all the resources are returned to the operating system.
67
The sub-procedures used in the above algorithm are described as follows. The
SELECTPROCESSFORMIGRATION() procedure chooses a process among many for migration to another node. The CREATEREQUESTFORMIGRATION () prepares a message to be broadcast across the network containing a request message for migrating a process with resource requirements. The execution of the process is suspended by the procedure SUSPENDPROCESS(). To initialize the message
INITIALIZEMESSAGEQUEUE() creates and initializes the message queue for the process to queue in coming service requests to this process.
68 The SENDBROADCAST() sends the requests message as a broadcast, so all the nodes nearby receive the message. The GETACCEPTANCEREPLIES() waits for at least N number of incoming replies from other nodes in the network. The
GETNEARESTREPLY() extracts the address of the selected node. The
OPENUNICASTCONNECTION() opens a unicast connection to the destination node for transferring the process migration data. The SENDPROCESS() sends data to the destination node. The CLOSEDATACONNECTIONS() closes all sockets terminating at the process. The SENDMESSAGEQUEUE() sends the message queue of the migrated process to the destination node. BROADCASTNEWLOCATION() broadcasts a message to tell all other nodes the new location of the migrated process.
4.7 Receiver Node Algorithm
Algorithm for receiver node is shown in Algorithm 2. The algorithm works as follows. The receiver node continuously listens for incoming requests. When a request arrives, the nodes check the free memory and battery status, if the requested memory and battery values are less than preset thresholds, then the node sends an acknowledgement to the sender node. After sending the acknowledgement the node waits for the process data from sender node. When the process data has been received, the node creates a new process instance and copies process data into the newly created instance. Next, the symbol table is linked, and message queue is received, and all the data connections are redirected. Finally, after the completion of process creation, the process is added to the short term scheduler queue as ready for execution.
69
The receiver node algorithm uses several sub-procedures. These are described as follows. WAITFORMIGRATIONREQUESTS() blocks until a request for migrating a process. GETFREEMEMEORY() gets the available free memory space on the node. The
SENDACCEPTREPLY() sends a packet of data such as acceptance message.
OPENUNICASTLISTENINGPORT() creates a unicast socket. CONNECT() waits for incoming connection to this node. RECEIVEPROCESS() receives an incoming process.
CREATEPROCESS() creates a process from received image of the process.
LINKSYMBOLTABLE() links the symbols in the symbol table of the process to the operating system procedure symbol table. RECIEVEMESSAGEQUEUE() retrieves a
70 handle to the local message queue. The ADDTOSCHEDULER() adds this process to the process scheduler of the operating system.
4.8 Details of helper algorithms
The following helping algorithms have been used to estimate battery charge, free memory space and get the nearest neighbour node.
4.8.1 Energy Consumption Estimation
The battery charge estimation in GETBATTERYCHARGE() procedure follows Dunkle et. al. [150, 151]. The energy consumption on a sensor node is defined by the following linear model [150].
In the battery charge estimation model V is the supply voltage. Im is the current drawn by the microprocessor, tm is the duration of time for which the microprocessor has been active. When the processor in the low power mode, Il and tl are the current draw and the duration of the processor low power mode. It and tt are the current draw and the active time of the radio in transmission mode. Ir and tr are the current draw and time of the radio in receiving state. The Ici and tci are the current draw and time of for other components including sensors and LEDs. Calibrated values of the constants Im,
Il, It, Ir, and Ici are obtained empirically using an oscilloscope by measuring voltage and current through the battery on active node.
4.8.2 Battery Voltage Estimation
The battery voltage is indicative of remaining battery charge. To get accurate battery
71 voltage multiple readings have to be averaged from the battery sensor over a period of time. The following function shown in Algorithm 3, has been used to estimate battery voltage in millivolts on Contiki.
4.8.3 Free Memory Estimation
The free memory is estimated in GETFREEMEMORY() using the following algorithm shown in Algorithm 4. The estimate is computed by repeatedly requesting increasing sized memory blocks.
The following built-in functions in Contiki provides have been used in the implementation of the battery estimation algorithm.
72 MEMB(): Declare a memory block. memb_init(): Initialize a memory block. memb_alloc(): Allocate a memory block. memb_free(): Free a memory block. memb_inmemb(): Check if an address is in a memory block.
4.8.4 Node Proximity Estimation
To choose a recipient node for process migration request, the sender node algorithm
CHOOSENEARESTREPLY() selects a nearest reply to optimize energy spent on sending process check-pointed state and related information. The selection is based on determining the geographically nearest nodes using RSSI values. Received Signal
Strength is used several times for measuring the average distance between nodes in
WSNs. [152, 153]. The Received Signal Strength is measured using the following module [154] as shown in Algorithm 5.
On the Sky-Mote and TelosB Motes, the global cc2420-last-rssi variable provides the signal strength of last received packet. The calculation of the rssi is shown as follows.
The value -45 is defined as rss_offset and has to be subtracted from rss value to get the correct value of RSSI.
static signed char rss; static signed char rss_val; static signed char rss_offset;
73 rss_val = cc2420_last_rssi; // RSSI of last received packet rss_offset = -45; // decrease by -45 rss = rss_val + rss_offset; // RSSI value in dBm
4.8.5 Load Balancing
The load balancing attempts at equalize and distribute the computational load among nodes. Load balancing has been used for balancing computational load among nodes
[155-158]. The algorithm for load balancing based on process migration is shown in
Algorithm 6. The replies are sorted using merge sort, in ascending order by memory and battery status of replying nodes.
The load balancing protocol is initiated by broadcasting a request for processor load, battery status and memory status, to all other nodes in the WSN. The node then waits for incoming replies. When a certain number of replies have been received, represented by N, the replies are sorted in ascending order according to CPU load, free memory space, and battery charge. The reply at N[0] represents the node with least amount of load. The load factor is sum of three values: free memory percentage, remaining battery percentage and processor load. The source node that initiated the load balancing operation, now selects a process P for migration using process selection algorithm and migrates to the node N[0]. The load balancing protocol is run by each node in the network to optimize the overall performance the WSN.
4.8.6 Process Selection
74 This algorithm implements selection procedure for selecting process to migrate to another node. For each process, two profile parameters are required for deciding the resource load generated by that process. The first parameter relates to loop cycles, which can be approximated by global counters kept by each user application. Such counters are incremented after each execution of main loop code. The higher loop count for given process indicates that the process is performing more computations and generating more CPU load. The second parameter is computed the amount of memory consumed by the application, which again can be implemented by each application as the global counter. All these global counters are stored in an array of profile structures. The structure is specified below as shown in Figure 4-3.
struct AppCounters { int app_id; int mem; // memory consumed in bytes int loops; // number of loops completed };
Figure 4-3 Record Structure for storing memory and process loop count
The selection of the process is made by searching this array of counters and then selecting the app with highest values of memory and loop counters.
4.8.7 Processor Load Estimation
Determination of processor load is a required task in load balancing. The code shown in the Figure 4-4 shows how the processor load is estimated. The estimation of CPU load is based on power consumption of the CPU. The energyest module is available on Contiki-OS to measure CPU load in terms of power consumption. The variables diff_cpu and diff_lpm record the differential CPU load after each second, in terms of
75 CPU power consumption.
#include "contiki.h" int last_cpu, last_lpm, diff_cpu, diff_lpm; PROCESS_THREAD(output_process, ev, data) { static struct etimer et; PROCESS_BEGIN(); ENERGEST_ON(ENERGEST_TYPE_CPU); etimer_set(&et, CLOCK_SECOND); while(1) { PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); if(timer_expired(&et)) { last_cpu = energest_type_time(ENERGEST_TYPE_CPU); last_lpm = energest_type_time(ENERGEST_TYPE_LPM); diff_cpu -= last_cpu; // power consumed by CPU diff_lpm -= last_lpm; // power in low power mode timer_reset(&et); } } PROCESS_END(); } Figure 4-4 Code for computing processor load
4.9 Summary
This chapter proposed the process migration architecture for the WSNs and presented the algorithmic details of the migration algorithm and various sub procedures. The architecture has been designed modularly. Each module has a specific function and responsibility for handling various stages of migrating a process from one node to another node. The proposed architecture includes migration manager, program loader, data transporter, request broadcaster/listener, resource monitor, logger, and configuration manager. The next chapter goes into the details of the implementing the process migration on Contiki OS for wireless sensor networks. The algorithm for sending and receiving nodes was described in detail. Both of the algorithms are
76 designed modularly. Platform specific helper algorithms for estimating battery charge, node proximity detection, load balancing and processor load were described. These helper algorithms are called by the sender and receiver algorithms. The next chapter evaluates the implementation described in this chapter.
77 Chapter 5. Evaluation
This chapter presents the implementation and evaluation results. The proposed process migration architecture for WSNs was evaluated on COOJA [159] and a testbed of TelosB motes. The main objective of the implementation is to show the working and feasibility of the proposed architecture by using both simulation and real test bed of sensors. The previous chapter explained design of the proposed architecture. This chapter not only gives implementation details but also evaluates and compares the proposed architecture against existing architectures. During implementation the underlying Rime stack which is part of Contiki OS, was selected for communication between the nodes. The main thread in the program named pmig process opened broadcast channels, unicast channels and performed node monitoring and managed the process migration steps. The test program was the LED blinker program called blink which migrated for several times between randomly selected nodes both in the simulation and a test bed of telosb nodes.
5.1 Comparison between Native and Non-native Code Execution
The section examines and compares the efficiency of native and non-native code execution. An example of Non-native code execution is Agilla [116] middleware which allows the mobile agents are executing on a byte code interpreter virtual machine to migrate state and executable code from one node to another node at a run time. It has been suggested that migrating small executable code modules consume less energy than a full application [160] and for shorter tasks, this strategy is energy efficient, but for long running tasks, the nature of code interpretation makes it less energy efficient. In real world situations, virtual machine based applications typically
78 consume more resources including time, space and energy than the native applications. A comparison of the running times of different algorithms have been provided by Ellul [117, 118] and summarized in Tabe-4, which bench marks Ahead-
Of-Time (AOT) compilation, with native and TakaTuka JVM. The increased time of execution indicates more energy consumed compared to native code. Long Running
Tasks Lavis and Culler [15] suggest that it is more energy efficient to implement long running and complex application programs with frequent executions as native code rather than as virtual machine based code, because of the overhead caused by virtual machine’s interpreted execution. Furthermore the energy saving in the long term out- weighs the energy consumed during the migration of large and complex processes needing frequent executions. It is recommended that for smaller applications with small sized executable code, and frequent migration requirements, mobile agents are suitable. And for larger and complex applications, process migration is preferred. To compare the code execution efficiency of execution on between native and non-native code a 16 bit version of bubble sort was used to sort 256 values as benchmark. The execution times, binary code size and energy consumed between TakaTuka, AOT and native code are presented in Table 5.1 using TelosB motes. Figure 5-1 graphically compares the results in Table 5.1. The execution time was measured using Contiki clock library function clock_seconds() function. Native code is more efficient in execution time and energy consumption, however it may be larger sized than the non- native code. Moreover the code size of native code is much lower than TakaTuka, and almost double of AOT. The small code size is a desirable feature in process migration, as it requires less bandwidth, which translates to less energy consumption.
79 Table 5.1 Execution Time and Code Size Comparison
Energy Architecture Execution Time Binary Size Consumed TakaTuka 120 seconds 1050 bytes 587.76mJ
AOT 13 seconds 110 bytes 63.67mJ
Native 2 seconds 230 bytes 9.769mJ
Code Exeuction Efficiency Comparsion
1200
1000
800
600
400
200
0 TakaTuka AOT Native
Time(Sec) Binary Size Energy (mJ)
Figure 5-1 Graph of Execution Time and Code Size
5.2 Comparison to other Architectures
The process migration bears similarities with code migration and virtual agents. Code migration mainly focuses on the distribution and seamless installation of executable code on multiple nodes, whereas virtual agents allow small agent process running on virtual machines to migrate from one virtual machine to another in a WSN.
80 1) Code Migration
Code management in WSNs is typically achieved by code migration [48] [161] which allows the migration of application code from one node to another. This facilitates the remote installation of the software on nodes with ease and without the need of having physical access to nodes. Our implementation differs from code migration because in addition to code migration it also supports the migration of the execution state which means the whole process state is migrated. The process is resumed from the point it was paused on the previous node.
2) Virtual Machine
In the agent based systems, during agent migration, the code as well as the state of executing agent is migrated, however the agent code is run on the virtual machine, and the code has to be interpreted at run time. Therefore it is slow, consumes more time and energy. Compared to Virtual Machine based agent systems, native process migration enables process to execute native code and to migrate native executable processes along with state so that after migration the migrated process can resume execution at the target node. Native code has the advantage that it is faster and more energy efficient [114].
Table 5.2 shows comparison of our work with Dunkleet.al [114], Agilla [116] based on Mate [48], DarjeelingJVM [99, 119], and TakaTuka JVM [121] for wireless sensor motes.
81 Table 5.2 Comparison of proposed process migration architecture with Dunkle et.al.
Architecture TakaTuka Darjeeling Contiki Agilla Process Migration
Agent Based No No No Yes No Virtual machine Yes Yes No Yes No Dynamic Linking Yes Yes Yes Yes Yes and Loading Compact ELF Class File Class File Yes No Yes Live Transfer/Migration No No No Agents Yes State Transfer No No No Yes Yes Resource Monitoring No No No No Yes Energy-Aware No No No No Yes
The systems that support dynamic link and loading allow the operating system to load
and unload various application and operating system modules at runtime as compared
to static linking and loading. The compact ELF (executable and linkable format) is a
format for storing binary executable code derived from ELF, which strives to
minimize the size of ELF file which is suitable for WSN applications. Live transfer
refers to the migration of a process running on a virtual machine during execution.
State transfer allows a migrated process to resume from a check point, because state
of the process has to be restored before resumption takes place on virtual machine. A
node has to constantly watch for its resources which are called resource monitoring in
process migration context. Energy awareness refers the continuous activity of
detecting the current energy level of the energy source or battery.
5.3 Results of Simulation and Testbed
Verification and validation of the proposed architecture are the cornerstone of
evaluation. To evaluate the process migration architecture implementation it has been
tested in simulation and on sensor nodes. The details of the platform and tools are
82 shown in Table 5.3.
Table 5.3 Evaluation Hardware and Software Platform
Operating System Contiki Operating System Version 3.0 Simulation Environment COOJA Communication Protocol API Rime Hardware Nodes TELOSB Mote CPU 8 MHz TI MSP430 Microcontroller Program Memory 48kB Memory 10kB RAM Battery Two AA Batteries (3 volts)
To simulate the migration process, the blink application was used as shown in Figure
5-2. The runtime trace of simulating blink on COOJA is shown in Figure 5-3 using two Sky nodes named 1 and 2. The lower panel of COOJA window shows the led blinking on node-1 and node-2. Half of the red-led blinks are on node-1, while remaining half are on the node-2 after migration completed, which was initiated while the blinker process was running at node 1. The blink program was also tested on a testbed of 25 TelOSB nodes arranged in grid spaced at 1 feet interval as shown in
Figure 5-6. The results were the same as simulated in COOJA as shown in Figure 5-4.
The COOJA simulator was initialized in standard configuration. The process migration event was triggered manually.
83
#include "contiki.h" #include "dev/leds.h" #include
84
Figure 5-3 Process Migration between two nodes in COOJA
Figure 5-4 Process Migration between multiple nodes
85 Similarly Figure 5-5 shows that nearest node 6 is selected as target for migrating blink from node 7 to node 6, which shows that the nearest node has been selected as migration target. The node 6 was selected, because it responded to node 7 with an acceptance message and it was the nearest node to node 7.
Figure 5-5 Process Migration in Star Node Configuration
Figure 5-6 TelosB mote Testbed
86
5.4 Summary
The process migration architecture was evaluated on Cooja simulator and a testbed of
TelosB motes. The architecture was compared to other existing architectures. Finally, a comparison of energy consumption of example programs was presented. The energy saved by executing native processes has been shown to be significant, which motivates the live migration of these native processes.
87 Chapter 6. Conclusion and Future Work
It has been established in the previous chapters with detail that the objective of this research is to present a process migration architecture which enables processes to move from one node to another node at runtime. As mentioned previously, process migration has several advantages such as, better resource utilization, distributed processing, load balance and improved fault tolerance. It has also been established, that process migration can be either implemented on top of a virtual machine or directly on top of operating system as a middleware. In the case of virtual machine implementation the code is in the form of bytecode and is interpreted at runtime by the virtual machine. Contrary to the virtual machine, direct implementation of process migration above the operating system, allows the native code to be run on processor, thereby eliminating interpreted execution. Native code is memory efficient and consumes less energy than the interpreted code. This thesis presents an architecture for native process migration in WSNs. The proposed middleware architecture incorporates resource monitoring and dynamic process migration. This architecture improves fault tolerance and energy consumption of a WSN network without using virtual machines. The architecture has been tested and implemented on TeleosB nodes using Contiki OS.
However, no research work is fully complete and there are always issues which remain unsolved or new directions which needs to be explored further. Process migration finds useful applications in ubiquitous computing. It can be potentially used in IoT (internet of things) for improved network administration and utilization.
Therefore the next section presents the research areas or issues which needs to be explored.
88 6.1 Future work
The following features need to be incorporated into the process migration architecture, in the future.
1) Security.
WSNs are highly vulnerable to external security attacks such as malicious software, denial of service attacks and unauthorized access. Process migration allows application programs to move freely from node to node, which increases security risks. In future the process migration architecture needs to incorporate a security mechanism for authenticating the processes before they are migrated. In addition, nodes require mechanism for detecting malware and security attacks.
2) Compression.
To reduce the amount of data in transmission related to process migrations, data may be compressed before migration. Compressed data needs less amount of energy during transmission and also the time taken for transfer is also reduced. The process migration architecture can use compression algorithm for compressing process images before the transfer takes place [162]. This feature would improve the speed and energy consumption of migrations. In future compressions algorithm, such Huffman coding can be used for compression on nodes, as it is computational very efficient and well suited to execution on resource limited nodes.
3) Resource Dependency.
A process can be using resources, such as files and sockets which may pose problems when migration takes place, as they generate additional overhead of managing and movement of resource from one node to another. In future work resource dependency issues are also required to be addressed, so that resources can be efficiently and
89 transparently moved from one node to another in the network. In the case of transferring files compression can be used before the file is transferred to reduce the network traffic. Similarly sockets can be transferred by closing the socket on the source node and reopening it on the target node.
4) Heterogeneity.
As established in the requirements the proposed research is to be implemented on homogenous WSN. Heterogeneous WSNs can have different types of sensors, operating systems, and hardware throughout the network. This is increasing concern, as the emergence of IoT has enabled the incorporation of heterogeneous devices into a network. A sensor which may be available on one node may not be available on another node. Also nodes may be running different sets of operating systems and application programs, whereas another node may be running an entirely different set of software application and operating system. Future work on process migration in
WSNs should focus on heterogeneous networks so that broad range of heterogeneous resources such as sensors can be utilized.
6.2 Conclusion
WSNs have grown into the emerging technology IoT and ubiquitous computing devices. These small connected devices are found everywhere and are now becoming part of every product. Our lives are ever more dependent on the efficient and correct functioning of these devices. The deployment, configuration, security and management of huge number of such connected devices are a major challenge.
Process migration can be employed to improve, resource utilization, management, and fault tolerance of IoT devices while meeting some of these challenges.
90 REFERENCES
[1] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, "Wireless sensor
networks: a survey," Computer networks, vol. 38, pp. 393-422, 2002.
[2] B. Rashid and M. H. Rehmani, "Applications of wireless sensor networks for urban
areas: a survey," Journal of Network and Computer Applications, vol. 60, pp. 192-
219, 2016.
[3] T. Arampatzis, J. Lygeros, and S. Manesis, "A survey of applications of wireless
sensors and wireless sensor networks," in Proceedings of the 2005 IEEE
International Symposium on, Mediterrean Conference on Control and Automation
Intelligent Control, 2005., 2005, pp. 719-724.
[4] J. Yick, B. Mukherjee, and D. Ghosal, "Wireless sensor network survey," Computer
networks, vol. 52, pp. 2292-2330, 2008.
[5] C. F. Garcia-Hernandez, P. H. Ibarguengoytia-Gonzalez, J. Garcia-Hernandez, and J.
A. Perez-Diaz, "Wireless sensor networks and applications: a survey," IJCSNS
International Journal of Computer Science and Network Security, vol. 7, pp. 264-273,
2007.
[6] H. Alemdar and C. Ersoy, "Wireless sensor networks for healthcare: A survey,"
Computer Networks, vol. 54, pp. 2688-2710.
[7] A. Mainwaring, D. Culler, J. Polastre, R. Szewczyk, and J. Anderson, "Wireless
sensor networks for habitat monitoring," in Proceedings of the 1st ACM international
workshop on Wireless sensor networks and applications, 2002, pp. 88-97.
[8] H. Du and R. Bogue, "MEMS sensors: past, present and future," Sensor Review, vol.
27, pp. 7-13, 2007.
[9] A. Milenkovic, C. Otto, and E. Jovanov, "Wireless sensor networks for personal
health monitoring: Issues and an implementation," Computer communications, vol.
29, pp. 2521-2533, 2006.
[10] M. Winkler, K.-D. Tuchs, K. Hughes, and G. Barclay, "Theoretical and practical
91 aspects of military wireless sensor networks," Journal of Telecommunications and
Information Technology, vol. 2, pp. 37-45, 2008.
[11] P. Corke, T. Wark, R. Jurdak, W. Hu, P. Valencia, and D. Moore, "Environmental
wireless sensor networks," Proceedings of the IEEE, vol. 98, pp. 1903-1917.
[12] L. Ciabattoni, A. Freddi, S. Longhi, A. Monteriu, L. Pepa, and M. Prist, "An open and
modular hardware node for wireless sensor and body area networks," Journal of
Sensors, vol. 2016, pp. 1–16.
[13] M. Patel and J. Wang, "Applications, challenges, and prospective in emerging body
area networking technologies," IEEE Wireless Communications Magazine, vol. 17,
pp. 80-88.
[14] B. Latre, B. Braem, I. Moerman, C. Blondia, and P. Demeester, "A survey on
wireless body area networks," Wireless Networks, vol. 17, pp. 1-18, 2011.
[15] G.-Z. Yang and M. Yacoub, Body sensor networks: Springer-Verlag London Limited,
2006.
[16] G. Werner-Allen, J. Johnson, M. Ruiz, J. Lees, and M. Welsh, "Monitoring volcanic
eruptions with a wireless sensor network," in Proceeedings of the Second European
Workshop on Wireless Sensor Networks, 2005., 2005, pp. 108-120.
[17] A. Hande, T. Polk, W. Walker, and D. Bhatia, "Self-powered wireless sensor
networks for remote patient monitoring in hospitals," Sensors, vol. 6, pp. 1102-1117,
2006.
[18] G. Zussman and A. Segall, "Energy efficient routing in ad hoc disaster recovery
networks," Ad Hoc Networks, vol. 1, pp. 405-421, 2003.
[19] A. Pantelopoulos and N. G. Bourbakis, "A survey on wearable sensor-based systems
for health monitoring and prognosis," IEEE Transactions on Systems, Man, and
Cybernetics, Part C (Applications and Reviews), vol. 40, pp. 1-12, .2010
[20] J. A. Stankovic, Q. Cao, T. Doan, L. Fang, Z. He, R. Kiran, S. Lin, S. Son, R. Stoleru,
and A. Wood, "Wireless sensor networks for in-home healthcare: Potential and
challenges," in High confidence medical device software and systems (HCMDSS)
92 workshop, 2005, pp. 2-3.
[21] X. Yu, "Approaches and principles of fall detection for elderly and patient," in e-
health Networking, Applications and Services, 2008. HealthCom 2008. 10th
International Conference on, 2008, pp. 42-47.
[22] B. P. L. Lo, S. Thiemjarus, R. King, and G.-Z. Yang, "Body sensor network, a
wireless sensor platform for pervasive healthcare monitoring," in Proceedings of 3rd
International Conference on Pervasive Computing, 2005.
[23] M. Sugano, T. Kawazoe, Y. Ohta, and M. Murata, "Indoor localization system using
RSSI measurement of wireless sensor network based on ZigBee standard," Wireless
and Optical Communications, vol. 538, pp. 1-6, 2006.
[24] T. He, S. Krishnamurthy, J. A. Stankovic, T. Abdelzaher, L. Luo, R. Stoleru, T. Yan,
L. Gu, J. Hui, and B. Krogh, "Energy-efficient surveillance system using wireless
sensor networks," in Proceedings of the 2nd international conference on Mobile
systems, applications, and services, 2004, pp. 270-283.
[25] K. K. Khedo, R. Perseedoss, and A. Mungur, "A wireless sensor network air pollution
monitoring system," International Journal of Wireless & Mobile Networks, vol. 2, pp.
31-45, 2-4 April 2015 2010.
[26] G. Shirke and M. S. Krishanan, "Energy Conservation Using Wireless Sensor
Network," in International Technological Conference-2014 (ITechCON-2014), 2014.
[27] B. O'Flynn, R. Martinez-Catala, S. Harte, C. O'Mathuna, J. Cleary, C. Slater, F.
Regan, D. Diamond, and H. Murphy, "SmartCoast: a wireless sensor network for
water quality monitoring," in 32nd IEEE Conference on Local Computer Networks
(LCN 2007), 2007, pp. 815-816.
[28] L. Yu, N. Wang, and X. Meng, "Real-time forest fire detection with wireless sensor
networks," in Proceedings. 2005 International Conference on Wireless
Communications, Networking and Mobile Computing, 2005., 2005, pp. 1214-1217.
[29] D. Diamond, S. Coyle, S. Scarmagnani, and J. Hayes, "Wireless sensor networks and
chemo-biosensing," Chemical reviews, vol. 108, pp. 652-679, 2008.
93 [30] M. reza Akhondi, A. Talevski, S. Carlsen, and S. Petersen, "Applications of wireless
sensor networks in the oil, gas and resources industries," in 2010 24th IEEE
International Conference on Advanced Information Networking and Applications, pp.
941-948.
[31] X. Wang, X. Zhao, Z. Liang, and M. Tan, "Deploying a wireless sensor network on
the coal mines," in 2007 IEEE International Conference on Networking, Sensing and
Control, 2007, pp. 324-328.
[32] G. M. Shafiullah, A. Gyasi-Agyei, and P. Wolfs, "Survey of wireless communications
applications in the railway industry," in The 2nd International Conference on
Wireless Broadband and Ultra Wideband Communications (AusWireless 2007),
2007, pp. 65-65.
[33] H. B. Lim, D. Ma, B. Wang, Z. Kalbarczyk, R. K. Iyer, and K. L. Watkin, "A soldier
health monitoring system for military applications," in 2010 International Conference
on Body Sensor Networks, pp. 246-249.
[34] S. Khan, A.-S. K. Pathan, and N. A. Alrajeh, Wireless sensor networks: Current
status and future trends: CRC Press, 2016
[35] A. Baggio, "Wireless sensor networks in precision agriculture," in ACM Workshop on
Real-World Wireless Sensor Networks (REALWSN 2005), Stockholm, Sweden, 2005.
[36] L. Atzori, A. Iera, and G. Morabito, "The internet of things: A survey," Computer
networks, vol. 54, pp. 2787-2805.
[37] G. Fortino, R. Gravina, W. Li, M. M. Hassan, and A. Liotta, "Enhancing Internet and
Distributed Computing Systems with Wireless Sensor Networks," International
Journal of Distributed Sensor Networks, vol. 11, 2015.
[38] S. Sotiriadis, N. Bessis, E. Asimakopoulou, and N. Mustafee, "Towards simulating
the Internet of Things," in Advanced Information Networking and Applications
Workshops (WAINA), 2014 28th International Conference on, pp. 444-448.
[39] D. Bakken, "Middleware," Encyclopedia of Distributed Computing, vol. 11, 2001.
[40] D. Bruneo, A. Puliafito, and M. Scarpa, "Mobile middleware: Definition and
94 motivations," The Handbook of Mobile Middleware, pp. 145-167, 2007.
[41] R. Kay, O. Kasten, and F. Mattern, "Middleware challenges for wireless sensor
networks," ACM SIGMOBILE Mobile Computing and Communications Review, vol.
6, pp. 59-61, 2002.
[42] J. Al-Jaroodi and N. Mohamed, "Middleware is STILL everywhere!!!," Concurrency
and Computation: Practice and Experience, vol. 24, pp. 1919-1926, 2012.
[43] I. S. Acharyya and A. Al-Anbuky, "Towards wireless sensor network softwarization,"
in NetSoft Conference and Workshops (NetSoft), 2016 IEEE, pp. 378-383.
[44] S. Vinoski, "CORBA: integrating diverse applications within distributed
heterogeneous environments," IEEE Communications Magazine, vol. 35, pp. 46-55,
Feb 1997.
[45] B. Karp and H. T. Kung, "GPSR: Greedy Perimeter Stateless Routing for Wireless
Networks," in Proceedings of the 6th Annual International Conference on Mobile
Computing and Networking, New York, NY, USA, 2000, pp. 243-254.
[46] M. Satyanarayanan and D. Narayanan, "Multi-fidelity Algorithms for Interactive
Mobile Applications," Wirel. Netw., vol. 7, pp. 601-607, November 2001.
[47] A. Wigley, M. Sutton, S. Wheelwright, R. Burbidge, and R. McLoud, Microsoft. net
compact framework: Core reference: Microsoft Press, 2002.
[48] P. Levis and D. Culler, "Mate: A tiny virtual machine for sensor networks," in ACM
Sigplan Notices, 2002, pp. 85-95.
[49] R. Barr, J. C. Bicket, D. S. Dantas, B. Du, T. W. Kim, B. Zhou, and E. G. u. n. Sirer,
"On the need for system-level support for ad hoc and sensor networks," ACM
SIGOPS Operating Systems Review, vol. 36, pp. 1-5, 2002.
[50] T. Abdelzaher, B. Blum, Q. Cao, Y. Chen, D. Evans, J. George, S. George, L. Gu, T.
He, and S. Krishnamurthy, "Envirotrack: Towards an environmental computing
paradigm for distributed sensor networks," in Distributed Computing Systems, 2004.
Proceedings. 24th International Conference on, 2004, pp. 582-589.
[51] T. Liu and M. Martonosi, "Impala: A middleware system for managing autonomic,
95 parallel sensor systems," in ACM SIGPLAN Notices, 2003, pp. 107-118.
[52] A. Cerpa, J. Elson, D. Estrin, L. Girod, M. Hamilton, and J. Zhao, "Habitat
monitoring: Application driver for wireless communications technology," ACM
SIGCOMM Computer Communication Review, vol. 31, pp. 20-41, 2001.
[53] Y. Yao and J. Gehrke, "The cougar approach to in-network query processing in
sensor networks," ACM Sigmod Record, vol. 31, pp. 9-18, 2002.
[54] C. Srisathapornphat, C. Jaikaeo, and C.-C. Shen, "Sensor information networking
architecture," in Parallel Processing, 2000. Proceedings. 2000 International
Workshops on, 2000, pp. 23-30.
[55] X. Yu, K. Niyogi, S. Mehrotra, and N. Venkatasubramanian, "Adaptive middleware
for distributed sensor environments," IEEE distributed systems online, 2003.
[56] D. S. Milojivcic, F. Douglis, Y. Paindaveine, R. Wheeler, and S. Zhou, "Process
Migration," ACM Comput. Surv., vol. 32, pp. 241-299, September 2000.
[57] Q. Zhang, L. Cheng, and R. Boutaba, "Cloud computing: state-of-the-art and research
challenges," Journal of internet services and applications, vol. 1, pp. 7-18, 2010.
[58] M. Choi, J. Park, and Y.-S. Jeong, "Mobile cloud computing framework for a
pervasive and ubiquitous environment," The Journal of Supercomputing, vol. 64, pp.
331-356, 2013.
[59] A. Rudenko, P. Reiher, G. J. Popek, and G. H. Kuenning, "Saving portable computer
battery power through remote process execution," ACM SIGMOBILE Mobile
Computing and Communications Review, vol. 2, pp. 19-26, 1998.
[60] M. Satyanarayanan, P. Bahl, R. o. n. Caceres, and N. Davies, "The case for vm-based
cloudlets in mobile computing," IEEE pervasive Computing, vol. 8, pp. 14-23, 2009.
[61] S. Jain, A. Vaibhav, and L. Goyal, "Raspberry Pi based interactive home automation
system through E-mail," in Optimization, Reliabilty, and Information Technology
(ICROIT), 2014 International Conference on, pp. 277-280.
[62] H.-Y. Chen, Y.-H. Lin, and C.-M. Cheng, "Coca: Computation offload to clouds
using aop," in Cluster, Cloud and Grid Computing (CCGrid), 2012 12th IEEE/ACM
96 International Symposium on, pp. 466-473.
[63] S. Sud, R. Want, T. Pering, K. Lyons, B. Rosario, and M. X. Gong, "Dynamic
migration of computation through virtualization of the mobile platform," Mobile
Networks and Applications, vol. 17, pp. 206-215, 2012.
[64] S.-H. Hung, C.-S. Shih, J.-P. Shieh, C.-P. Lee, and Y.-H. Huang, "Executing mobile
applications on the cloud: Framework and issues," Computers and Mathematics with
Applications, vol. 63, pp. 573-587, 2012.
[65] D. Kovachev, Y. Cao, and R. Klamma, "Mobile cloud computing: a comparison of
application models," Computing Research Repository, CoRR, vol. abs/1009.3088,
2010.
[66] M. Shiraz, A. Gani, R. H. Khokhar, and R. Buyya, "A review on distributed
application processing frameworks in smart mobile devices for mobile cloud
computing," IEEE Communications Surveys and Tutorials, vol. 15, pp. 1294-1313,
2013.
[67] K. Kumar, J. Liu, Y.-H. Lu, and B. Bhargava, "A survey of computation offloading
for mobile systems," Mobile Networks and Applications, vol. 18, pp. 129-140, 2013.
[68] M. Othman, S. A. Madani, and S. U. Khan, "A survey of mobile cloud computing
application models," IEEE Communications Surveys and Tutorials, vol. 16, pp. 393-
413, 2012.
[69] E. Cuervo, A. Balasubramanian, D.-k. Cho, A. Wolman, S. Saroiu, R. Chandra, and
P. Bahl, "MAUI: making smartphones last longer with code offload," in Proceedings
of the 8th international conference on Mobile systems, applications, and services,
2010, pp. 49-62.
[70] S. Zhu, S. Setia, and S. Jajodia, "LEAP+: Efficient security mechanisms for large-
scale distributed sensor networks," ACM Transactions on Sensor Networks (TOSN),
vol. 2, pp. 500-528, 2006.
[71] Y. Artsy and R. Finkel, "Designing a process migration facility: The Charlotte
experience," Computer, vol. 22, pp. 47-56, 1989.
97 [72] G. J. Pottie and W. J. Kaiser, "Wireless integrated network sensors," Communications
of the ACM, vol. 43, pp. 51-58, 2000.
[73] P. Smith and N. C. Hutchinson, "Heterogeneous process migration: The Tui system,"
Software-Practice and Experience, vol. 28, pp. 611-640, 1998.
[74] P. K. Sinha, K. S. Park, X. Jia, K. Shimizu, and M. Maekawa, "Process migration in
the GALAXY distributed operating system," in Parallel Processing Symposium,
1991. Proceedings., Fifth International, 1991, pp. 611-618.
[75] M. L. Powell and B. P. Miller, Process migration in DEMOS/MP vol. 17: ACM,
1983.
[76] L. Paradis and Q. Han, "A survey of fault management in wireless sensor networks,"
Journal of Network and systems management, vol. 15, pp. 171-190, 2007.
[77] V. Sharma, U. Mukherji, V. Joseph, and S. Gupta, "Optimal energy management
policies for energy harvesting sensor nodes," IEEE Transactions on Wireless
Communications, vol. 9, pp. 1326-1336, 2010.
[78] A. Sinha and A. Chandrakasan, "Dynamic power management in wireless sensor
networks," IEEE Design and Test of Computers, vol. 18, pp. 62-74, 2001.
[79] R. R. Schaller, "Moore's law: past, present and future," IEEE spectrum, vol. 34, pp.
52-59, 1997.
[80] F. Xia, L. T. Yang, L. Wang, and A. Vinel, "Internet of things," International Journal
of Communication Systems, vol. 25, p. 1101, 2012.
[81] H. Kopetz, "Internet of things," in Real-time systems: Springer, 2011, pp. 307-323.
[82] W. Mark, R. Peter, and P. Gerald, "Some computer science problems in ubiquitous
computing," Communications of the ACM, July, pp. 137-143, 1993.
[83] P. Baronti, P. Pillai, V. W. C. Chook, S. Chessa, A. Gotta, and Y. F. Hu, "Wireless
sensor networks: A survey on the state of the art and the 802.15. 4 and ZigBee
standards," Computer communications, vol. 30, pp. 1655-1695, 2007.
[84] I. Demirkol, C. Ersoy, F. Alagoz, and others, "MAC protocols for wireless sensor
networks: a survey," IEEE Communications Magazine, vol. 44, pp. 115-121, 2006.
98 [85] D. Estrin, R. Govindan, J. Heidemann, and S. Kumar, "Next century challenges:
Scalable coordination in sensor networks," in Proceedings of the 5th annual
ACM/IEEE international conference on Mobile computing and networking, 1999, pp.
263-270.
[86] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, "System
architecture directions for networked sensors," in ACM SIGOPS operating systems
review, 2000, pp. 93-104.
[87] R. Min, M. Bhardwaj, S.-H. Cho, E. Shih, A. Sinha, A. Wang, and A. Chandrakasan,
"Low-power wireless sensor networks," in VLSI Design, 2001. Fourteenth
International Conference on, 2001, pp. 205-210.
[88] R. Fisher, L. Ledwaba, G. Hancke, and C. Kruger, "Open hardware: a role to play in
wireless sensor networks?," Sensors, vol. 15, pp. 6818-6844, 2015.
[89] J. Feng, F. Koushanfar, and M. Potkonjak, "System-architectures for sensor networks
issues, alternatives, and directions," in Computer Design: VLSI in Computers and
Processors, 2002. Proceedings. 2002 IEEE International Conference on, 2002, pp.
226-231.
[90] R. E. Kalman, "A new approach to linear filtering and prediction problems," Journal
of basic Engineering, vol. 82, pp. 35-45, 1960.
[91] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D. Gay, J.
Hill, M. Welsh, E. Brewer, and others, "Tinyos: An operating system for sensor
networks," in Ambient intelligence: Springer, 2005, pp. 115-148.
[92] A. Dunkels, G. Bjorn, and T. Voigt, "Contiki a lightweight and flexible operating
system for tiny networked sensors," in Local Computer Networks, 2004. 29th Annual
IEEE International Conference on, 2004, pp. 455-462.
[93] S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald,
A. Torgerson, and R. Han, "MANTIS OS: An embedded multithreaded operating
system for wireless micro sensor platforms," Mobile Networks and Applications, vol.
10, pp. 563-579, 2005.
99 [94] C.-C. Han, R. K. Rengaswamy, R. Shea, E. Kohler, and M. Srivastava, "SOS: A
dynamic operating system for sensor networks," in Third International Conference on
Mobile Systems, Applications, And Services (Mobisys), 2005, pp. 163-176.
[95] A. Eswaran, A. Rowe, and R. Rajkumar, "Nano-rk: an energy-aware resource-centric
rtos for sensor networks," in 26th IEEE International Real-Time Systems Symposium
(RTSS'05), 2005, pp. 10-pp.
[96] A. Boulis, C.-C. Han, R. Shea, and M. B. Srivastava, "Sensorware: Programming
sensor networks beyond code update and querying," Pervasive and Mobile
Computing, vol. 3, pp. 386-412, 2007.
[97] C. L. Fok, G. C. Roman, and C. Lu, "Mobile agent middleware for sensor networks:
An application case study," in IPSN 2005. Fourth International Symposium on
Information Processing in Sensor Networks, 2005., 2005, pp. 382-387.
[98] Y. Kwon, S. Sundresh, K. Mechitov, and G. Agha, "ActorNet: An actor platform for
wireless sensor networks," in Proceedings of the fifth international joint conference
on Autonomous agents and multiagent systems, 2006, pp. 1297-1300.
[99] N. Brouwers, P. Corke, and K. Langendoen, "Darjeeling, a Java compatible virtual
machine for microcontrollers," in Proceedings of the ACM/IFIP/USENIX
Middleware'08 Conference Companion, 2008, pp. 18-23.
[100] F. Aslam, L. Fennell, C. Schindelhauer, P. Thiemann, G. Ernst, E. Haussmann, h. S.
Ru, and Z. A. Uzmi, "Optimized java binary and virtual machine for tiny motes," in
International Conference on Distributed Computing in Sensor Systems, 2010, pp. 15-
30.
[101] P. Krueger and M. Livny, "A comparison of preemptive and non-preemptive load
distributing," in Distributed Computing Systems, 1988., 8th International Conference
on, 1988, pp. 123-130.
[102] M. R. Eskicioglu, "Design issues of process migration facilities in distributed
systems," 1995.
[103] J. M. Smith, "A survey of process migration mechanisms," ACM SIGOPS Operating
100 Systems Review, vol. 22, pp. 28-40, 1988.
[104] S. Thulasidasan, "Issues in Process Migration," University of Southern California,
December, vol. 15, 2000.
[105] S. J. Mullender, G. Van Rossum, A. S. Tananbaum, R. Van Renesse, and H. Van
Staveren, "Amoeba: A distributed operating system for the 1990s," Computer, vol.
23, pp. 44-53, 1990.
[106] C. R. I. U. Team, "CRIU." vol. 2016, 2016.
[107] A. Loscher, N. Tsiftes, T. Voigt, and V. Handziski, "Efficient and Flexible Sensornet
Checkpointing," in European Conference on Wireless Sensor Networks, 2014, pp. 50-
65.
[108] H. Jiang and V. Chaudhary, "Process/thread migration and checkpointing in
heterogeneous distributed systems," in System Sciences, 2004. Proceedings of the
37th Annual Hawaii International Conference on, 2004, pp. 10-pp.
[109] A. S. Tanenbaum, Modern operating systems, 3rd ed.: Prentice Hall Press Upper
Saddle River, NJ, USA, 2009.
[110] "LinuxPMI," 2008.
[111] J. Ansel, K. Aryay, and G. Coopermany, "DMTCP: Transparent checkpointing for
cluster computations and the desktop," in Parallel and Distributed Processing, 2009.
IPDPS 2009. IEEE International Symposium on Parallel and Distributed Processing,
2009, pp. 1-12.
[112] P. H. Hargrove and J. C. Duell, "Berkeley lab checkpoint/restart (blcr) for linux
clusters," in Journal of Physics: Conference Series, 2006, p. 494.
[113] S.-H. Hung, J.-P. Shieh, and C.-P. Lee, "Virtualizing Smartphone Applications to the
Cloud," Computing and Informatics, vol. 30, pp. 1083-1097, 2012.
[114] A. Dunkels, N. Finne, J. Eriksson, and T. Voigt, "Run-time dynamic linking for
reprogramming wireless sensor networks," in Proceedings of the 4th international
conference on Embedded networked sensor systems, 2006, pp. 15-28.
[115] J. Lifton, D. Seetharam, M. Seltzer, and J. Paradiso, "Technical Report: Bertha, the os
101 for pushpin computers," MIT Media Lab, May 2002 2002.
[116] C.-L. Fok, G.-C. Roman, and C. Lu, "Agilla: A mobile agent middleware for self-
adaptive wireless sensor networks," ACM Transactions on Autonomous and Adaptive
Systems (TAAS), vol. 4, p. 16, 2009.
[117] J. Ellul and K. Martinez, "Run-time compilation of bytecode in sensor networks," in
Sensor Technologies and Applications (SENSORCOMM), 2010 Fourth International
Conference on, pp. 133-138.
[118] J. Ellul, "Run-time compilation techniques for wireless sensor networks," University
of Southampton, 2012.
[119] N. Brouwers, K. Langendoen, and P. Corke, "Darjeeling, a feature-rich vm for the
resource poor," in Proceedings of the 7th ACM Conference on Embedded Networked
Sensor Systems, 2009, pp. 169-182.
[120] F. Aslam, "PhD. Thesis. Challenges and solutions in the design of a Java Virtual
Machine for resource constrained microcontrollers," University of Freiburg, 2011.
[121] F. Aslam, C. Schindelhauer, G. Ernst, D. Spyra, J. Meyer, and M. Zalloom,
"Introducing TakaTuka: a Java virtualmachine for motes," in Proceedings of the 6th
ACM conference on Embedded network sensor systems, 2008, pp. 399-400.
[122] A. Acharya, M. Ranganathan, and J. Saltz, "Sumatra: A language for resource-aware
mobile programs," Mobile Object Systems Towards the Programmable Internet, pp.
111-130, 1997.
[123] S. Funfrocken, "Transparent migration of Java-based mobile agents: Capturing and
re-establishing the state of Java programs," Personal Technologies, vol. 2, pp. 109-
116, 1998.
[124] T. Sekiguchi, H. Masuhara, and A. Yonezawa, "A simple extension of Java language
for controllable transparent migration and its portable implementation," Coordinatio
Languages and Models, pp. 648-648, 1999.
[125] T. Sekiguchi and A. Yonezawa, "A calculus with code mobility," in Formal Methods
for Open Object-based Distributed Systems: Springer, 1997, pp. 21-36.
102 [126] A. J. Chakravarti, X. Wang, J. O. Hallstrom, and G. Baumgartner, "Implementation
of strong mobility for multi-threaded agents in Java," in Proceedings. 2003
International Conference on Parallel Processing, 2003., 2003, pp. 321-330.
[127] T. Sakamoto, T. Sekiguchi, and A. Yonezawa, "Bytecode transformation for portable
thread migration in Java," in ASA/MA, 2000, pp. 16-28.
[128] E. Truyen, B. Robben, B. Vanhaute, T. Coninx, W. Joosen, and P. Verbaeten,
"Portable support for transparent thread migration in Java," in Agent Systems, Mobile
Agents, and Applications Lecture Notes in Computer Science. vol. 1882: Springer,
Berlin, Heidelberg, 2000, pp. 29-43.
[129] N. Suri, J. M. Bradshaw, M. R. Breedy, P. T. Groth, G. A. Hill, R. Jeffers, and T. S.
Mitrovich, "An overview of the NOMADS mobile agent system," in 2nd
International Symposium on Agent Systems and Applications, ASA/MA2000, Zurich,
Switzerland, 2000.
[130] N. Suri, J. M. Bradshaw, M. R. Breedy, K. M. Ford, P. T. Groth, G. A. Hill, and R.
Saavedra, "State Capture and Resource Control for Java: The Design and
Implementation of the Aroma Virtual Machine," in Java Virtual Machine Research
and Technology Symposium, 2001.
[131] T. Suezawa, "Persistent execution state of a Java virtual machine," in Proceedings of
the ACM 2000 conference on Java Grande, 2000, pp. 160-167.
[132] R. S. Gray, G. Cybenko, D. Kotz, R. A. Peterson, and D. Rus, "Agents: Applications
and performance of a mobile agent system," Software: Practice and Experience, vol.
32, pp. 543-573, 2002.
[133] T. Illmann, T. Krueger, F. Kargl, and M. Weber, "Transparent migration of mobile
agents using the java platform debugger architecture," in International Conference on
Mobile Agents, 2001, pp. 198-212.
[134] W. Zhu, C.-L. Wang, and F. C. M. Lau, "Jessica2: A distributed java virtual machine
with transparent thread migration support," in Proceedings. 2002 IEEE International
Conference on Cluster Computing, 2002., 2002, pp. 381-388.
103 [135] W. Thompson and C. Weddle, "Improving Energy for Mobile Computers Through
Process Migration Logging." vol. 2016, 2004.
[136] J. Donga and M. N. Shah, "Study of Process Migration Techniques for Load
Balancing in Distributed Operating System," International Journal of Knowledge
Engineering and Research, vol. 1, 2012.
[137] M. M. Theimer, K. A. Lantz, and D. R. Cheriton, Preemptable remote execution
facilities for the V-system vol. 19: ACM, 1985.
[138] E. Zayas, "Attacking the process migration bottleneck," in ACM SIGOPS Operating
Systems Review, 1987, pp. 13-24.
[139] F. Douglis, "Experience with process migration in Sprite," in Proceedings of the
USENIX Workshop on Experiences with Distributed and Multiprocessor Systems
(WEBDMS), 1989, pp. 59-72.
[140] E. T. Roush, "PhD thesis: The freeze free algorithm for process migration,"
University of Illinois, 1995.
[141] K. Murata, R. N. Horspool, E. G. Manning, Y. Yokote, and M. Tokoro, "Unification
of active and passive objects in an object-oriented operating system," in Object-
Orientation in Operating Systems, 1995., Fourth International Workshop on, 1995,
pp. 68-71.
[142] M. Nuttall, "A brief survey of systems providing process or object migration
facilities," ACM SIGOPS Operating Systems Review, vol. 28, pp. 64-80, 1994.
[143] U. Hansmann, Pervasive computing: The mobile world: Springer Science and
Business Media, 2003.
[144] J. Holler, V. Tsiatsis, C. Mulligan, S. Avesand, S. Karnouskos, and D. Boyle, From
Machine-to-machine to the Internet of Things: Introduction to a New Age of
Intelligence: Academic Press, 2014.
[145] A. Barak and A. Shiloh, "A distributed load‐balancing policy for a multicomputer,"
Software: Practice and Experience, vol. 15, pp. 901-913, 1985.
[146] M. Mannan and S. B. Rana, "Fault Tolerance in Wireless Sensor Network,"
104 International Journal of Current Engineering and Technology, vol. 5, pp. 1785-1788,
2012.
[147] A. Perrig, R. Szewczyk, J. D. Tygar, V. Wen, and D. E. Culler, "SPINS: Security
protocols for sensor networks," Wireless networks, vol. 8, pp. 521-534, 2002.
[148] A. Perrig, R. Canetti, J. D. Tygar, and D. Song, "The TESLA broadcast
authentication protocol," RSA CryptoBytes, vol. 5, 2005.
[149] S. I. Hussain, H. Javed, T. Khan, S. Shazad, and F. N. Khalil, "Native Process
Migration in Wireless Sensor Networks," International Journal of Distributed Sensor
Networks, vol. 11, 2015.
[150] A. Dunkels, F. Osterlind, N. Tsiftes, and Z. He, "Software-based on-line energy
estimation for sensor nodes," in Proceedings of the 4th workshop on Embedded
networked sensors, 2007, pp. 28-32.
[151] E. Nataf and O. Festor, "Online Estimation of Battery Lifetime for Wireless Sensors
Network," Inria Nancy - Grand Est, LORIA - NSS - Department of Networks,
Systems and Services 2012.
[152] S. D. Chitte and S. Dasgupta, "Distance estimation from received signal strength
under log-normal shadowing: Bias and variance," in 2008 9th International
Conference on Signal Processing, 2008, pp. 256-259.
[153] J. Hightower, R. Want, and G. Borriello, "SpotON: An indoor 3D location sensing
technology based on RF signal strength," UW CSE 00-02-02, University of
Washington, Department of Computer Science and Engineering, Seattle, WA, vol. 1,
2000.
[154] M. Robinson and I. Psaromiligkos, "Received signal strength based location
estimation of a wireless LAN client," in IEEE Wireless Communications and
Networking Conference, 2005, 2005, pp. 2350-2354.
[155] G. Gupta and M. Younis, "Load-balanced clustering of wireless sensor networks," in
Communications, 2003. ICC'03. IEEE International Conference on, 2003, pp. 1848-
1852.
105 [156] H. Dai and R. Han, "A node-centric load balancing algorithm for wireless sensor
networks," in Global Telecommunications Conference, 2003. GLOBECOM'03. IEEE,
2003, pp. 548-552.
[157] Y. Yu and V. K. Prasanna, "Energy-balanced task allocation for collaborative
processing in wireless sensor networks," Mobile Networks and Applications, vol. 10,
pp. 115-131, 2005.
[158] M. Kuorilehto, n. M. Ha, and m. T. D. Ha, "A survey of application distribution in
wireless sensor networks," EURASIP Journal on Wireless Communications and
Networking, vol. 2005, pp. 1-15, 2005.
[159] F. Osterlind, A. Dunkels, J. Eriksson, N. Finne, and T. Voigt, "Cross-level sensor
network simulation with cooja," in Proceedings. 2006 31st IEEE Conference on
Local Computer Networks, 2006, pp. 641-648.
[160] W. Zhang, L. Chen, Q. Lu, P. Zhang, and S. Yang, "Flexible Component Migration in
an OSGi Based Pervasive Cloud Infrastructure," in Service-Oriented Computing--
ICSOC 2013 Workshops, pp. 505-514.
[161] M.-M. Wang, J.-N. Cao, J. Li, and S. K. Dasi, "Middleware for wireless sensor
networks: A survey," Journal of computer science and technology, vol. 23, pp. 305-
326, 2008.
[162] N. Tsiftes and A. Dunkels, "A database in every sensor," in Proceedings of the 9th
ACM Conference on Embedded Networked Sensor Systems, 2011, pp. 316-332.
106