Grid Computing Implementation in Ad Hoc Networks

Grid Computing Implementation in Ad Hoc Networks Aksenti Grnarov, Bekim Cilku, Igor Miskovski, Sonja Filiposka and Dimitar Trajanov Dept. of Computer Sciences Faculty of Electrical Engineering and Information Technology University Ss. Cyril and Methodious Skopje Skopje, R. Macedonia [email protected] Abstract – The development of ubiquitous computing and mobility opens challenges for implementation of grid computing in ad hoc network environments. In this paper, a new grid computing implementation for ad hoc networks is proposed. The proposed addition of the ad hoc network protocols suite offers an easy and effective way to exploit the computing power of the network nodes. The model is implemented in the NS-2 network simulator providing the possibility to investigate its performances and tune the network grid parameters. Index Terms – Grid Computing, Ad Hoc Networks, Service Deployment, Resource Discovery.

I. INTRODUCTION Not so long ago the target of the Grid scientists in their projects and explorations were the wired networks. But recently there has been a fair amount of research on using computational grids over mobile environments [1][2]. This is due to the expansion of mobile networks and the mobile technology, and the steady rise of their performances and computational capabilities. The potential ad hoc grid applications would allow nodes to accomplish specific task beyond an individual computing capacity. The ad hoc networks are usually used for emergency applications when results are needed immediately. However, some calculations are often time consuming and need to be done in harshest environment. In order to obtain the results more quickly these types of applications can be deployed in an ad hoc grid. Some typical applications are in the field of disaster management, e-healthcare emergency, sharing resources, collaborative computing, etc. Current work concerning ad hoc grid implementation can be divided into three groups. The first group deals with the challenges for establishing ad hoc mobile grids. In [3] various challenges in ad hoc grid like resource description, resource discovery, coordination systems, trust establishment and clearing mechanism are proposed. In [4] different problems like finding the resources, scheduling the tasks, node discovery, node property assessment, service deployment, service security and the Quality of Service are analyzed. The second group deals with the challenges in resource discovery. Several papers concerning resource discovery and executing tasks in the mobile Grid environment are

published. In [5] the use of service advertisement as a method for resource discovery is proposed. Yet this method is clearly inadequate for dynamic resources such as CPU load, available memory, battery lifetime and available time of the nodes. A different solution for resource discovery is proposed in [6]. It is based on using reactive protocols and it’s characterized with the use of a new module for finding resources with the help of the existing AODV routing protocol. However, this approach shows the architecture only of the process responsible for finding the necessary services. Also another drawback of this approach is the fact that AODV packets are changed, which leads to a change of one standardized protocol. In [7] reactive routing protocols are used and the nodes exchange messages between them about their resources and their neighbors resources. In [8] agents are used in order to find nodes that will execute certain tasks. The last two models overload the network with messages even though some nodes would not be used in the execution process. The third group deals with task scheduling in the ad hoc grid environment. One proposed and existing solution that addresses this problem is to use the DICHOTOMY protocol. The main function of this protocol is to allow resource provisioning to be scheduled among the most resourceful nodes in the mobile grid, while mitigating the overhead of discovery messages exchanged among them [9]. Having in mind the needs of the wired Grid, its ad hoc implementation needs to offer: (1) finding resources only when there is a need for execution of a given task, (2) minimum time of execution, (3) no influence on the upper or the lower layers, (4) rescheduling if a certain node is down, (5) implementation on every platform and (6) data protection. Also it must have the following characteristics: (1) to keep pace with the dynamic nature of the network, (2) not to overload the network, (3) to use different scheduling algorithms in order to improve the overall execution time, (4) to intervene in case of node failure, (5) to authenticate and authorize the nodes when joining the network. Starting from the needs stated above we have created new implementation of Grid in ad hoc networks realized as a separate layer. This new independent Ad Hoc Grid Layer (AHGL) gives opportunity for scalability without any affection on the other layers of the network architecture. The AHGL reduces the unnecessary traffic in the ad hoc grid environment because it includes only the nodes that satisfy the criteria for execution of certain jobs. This paper

also illustrates how services are deployed at the nodes in the ad hoc network. The rest of the paper is as follows. Section 2 defines the position of the AHGL in the network architecture and it describes the services that are implemented in AHGL. In Section 3 sequential description of AHGL in master mode is presented while in Section 4 the description of AHGL in slave mode is given. In Section 5 the implementation of AHGL in network simulator is presented. Section 6 presents the simulated scenario and gives analysis of the obtained results. In Section 7 the conclusion and future work in this layer are presented. II. AD HOC GRID LAYER (AHGL) The Ad Hoc Grid Layer is deigned as a separate layer in the network architecture of all the nodes in the ad hoc grid environment (fig. 1). Depending on the function of the node the layer can be in Master or Slave mode. AHGL for a given node is in master mode when that node is supposed to find free resources through out the ad hoc network, to schedule jobs and to dispatch them to the rest of the nodes. The AHGL for nodes that are meant to receive jobs, execute them and reply, with the results is in slave mode.

are used to check if the job can be placed in the available memory of the node and to calculate the time needed for job execution. The output for this service is in form of a table of parameters (fig. 3). The first and the second column (IDapp and IDjob) are used for identification of the jobs; the third column is used for the length of the job in Bytes and the fourth is the number of instructions (Nins).

Fig. 3 Example of the parameters table

For example, the first row presents the parameters of a job that belongs to the first application, the job has ID=12, size of 4378 KB and 212 instructions. B. Resource Finder The dynamic properties of ad hoc networks do not allow a central register node. This is the reason why we have implemented a service which discovers free resources across the network in the moment when there are incoming jobs to be executed. This is done by the resource finder service that generates AHGL request packet and broadcasts it to all available nodes in the network. The structure of AHGL request packet is shown in fig.4.

Fig. 4 AHGL request packet

The first goal of the AHGL layer is to divide the application on small grid jobs with structure as shown in fig. 2. This is done by the Application interface service. Taking into consideration that every node may have several applications to execute, their distinction is done by the field IDapp. Also jobs which are part of the same application must be distinguished. This is done using the IDjob field. The last field IDSW is used to specify the software that is needed for proper execution of the job. The data needed to execute a certain job is in the DATA field.

The first field is the destination of the packet (IDnode) while the second field (SEQ) is used to distinguish the different requests from a same node and to escape forever loops. To reduce traffic and to exclude the nodes that cannot execute even the smallest jobs, we are using the minimalism criterion. The following fields are parameters that every node must satisfy in order to be considered as a part of this ad hoc grid environment. These parameters are the minimum speed of the processor in GHz (CPU), the minimum free memory in KB (MEM) and minimum amount of the battery (BAT). Nodes that satisfy the given criterion reply with an AHGL reply packet shown on fig. 5. Using this packet, the nodes announce their processor speed (CPU), amount of free memory (MEM) and battery status (BAT). For future calculation of time needed to transmit the packet we also count the number of the hops needed to reach node (H). Nodes that are offering free resources are available for certain period of time. This free period of time starts at TS and ends at TE. During this period, nodes can be used in a given effective interval (TEFF).

Fig. 2 Representation of a job

Fig. 5 AHGL reply packet

According to the specified software (IDSW) the Application interface service calculates the size and the number of instructions that every job has. These parameters

The resource finder service creates the resource table using the received AHGL reply packets, which is presented

Fig. 1 Position of AHGL in the ad hoc grid network architecture

All of these layer functions are realized by the means of different services. Depending on the role of the node, the particular services are activated. In AHGL there are implemented six possible services: application interface, resource finder, scheduler, dispatcher, resource responder and job execution service. A. Application interface service

in fig. 6, and afterwards used by the next service (scheduler) as input for the execution time optimization.

The first field IDnode is used as a destination for the job packet, while the other fields are used to represent the job (IDapp, IDjob, IDSW and DATA). After the execution of the job, the node generates a result packet (fig. 9).

Fig. 6 Example of resource table Fig. 9 Result packet

For example, the first row presents the information obtained from node with ID=5 that has processor speed of 2.5 GHz, free memory of 284850 KB, is reachable in two hops from the master. It is available in time interval between 935 s and 8625 s, offers effective interval of 2500 s, and has Round Trip Time (RTT) of 1.7452 seconds. C. Scheduler The purpose of this service is to find the optimum time for execution of all jobs using a given scheduling algorithm, where the process is influenced by different parameters. Such parameters are: start and end time of the nodes availability (TS, TE), effective time (TEFF), processor speed (CPU), number of instructions (Nins), job size, network throughput (R), number of hops, round trip time (RTT) and the job priority. All those parameters are read from resource table and parameters table. The scheduling process first checks the time of the availability of the node (TEFF). It also checks whether the node offers enough time for execution of the job and whether the free memory of the node is big enough for the size of a certain job. If these criteria are achieved, the job is assigned to that node and its effective time is updated. The result of algorithm is a dispatch table (fig. 7) announcing which job is to be executed at which node.

The first field (IDnode) is the ID of the master node, the fields IDapp and IDjob represent the application and the job for which the results are intended. Because of the nature of the ad hoc networks, there is a great possibility that a certain node will not send a result as a consequence of a node failure or connection failure. In this case, the jobs assigned to that node, must be rescheduled. E. Resource Response Service This service monitors the available resources for a given node and it responds when AHGL request packets are received. First it checks the sequence number (SEQ) of the request then it compares the fields: processor (CPU), free memory (MEM) and battery energy (BAT) from the packet with the actual values from the node. If the values from the node are bigger, then the criteria are satisfied and the node generates AHGL response packet (fig. 5), which is then transferred to the lower ad hoc routing layer. F. Job Execution Service Job execution is the last service and is activated when the job arrives at the slave node. The job is forwarded to the upper layer for execution and the obtained results are packed and sent to the master node. III. AHGL IN MASTER MODE

Fig. 7 Example of Dispatch Table

For example, the first row represents a job with ID=14 that belongs to the first application which is assigned to the node 12 for execution. D. Dispatcher The Dispatcher is the fourth service in AHGL and its job is to dispatch the jobs to the appropriate nodes and to forward the obtained results to the Application interface service. This service uses the dispatch table, parameters table, and the queue with the jobs and it creates the job packet (fig. 8). The parameter table is used by the dispatcher to send jobs to the assigned node until the node has a free amount of memory. The packets are transferred to the lower layers and using the ad hoc routing protocol, sent to the destination nodes.

Fig. 8 Job packet

The work flow for a node in a master mode is shown on fig.10. In step 1, after receiving application for grid computing, the application interface service separates the application in smaller jobs forming a queue. The next step the service calculates the parameters for every job and forms the parameters table. In step 3 the resource finder service is activated. This service searches for free resources in the network using an AHGL request packet. The resource request packet is broadcasted to all the nodes in the network (step 4). The nodes that have received the packet send AHGL reply packet with information for the free resources that they have (step 5). Using all of the collected replies (step 6), the service generates a resource table with all the free resources for the nodes that satisfy the criterion for minimal amount of free memory, processor speed and battery status. This table together with the parameters table are then used by the scheduler (step 7). The scheduler uses a given algorithm in order to find the optimum time of execution for all the jobs for a certain application by deciding which job at which node will be executed. The

Application 1

13

activation

AHGL

3

application interface

R1 R2

Job queue

parameters table

2

J1

J2

J3

J4

...

...

Jn

Rn 9

7 6

resource finder 4

resource table

7

8

scheduler

dispatch table

12

9

dispatcher 10

5

9

11

Ad Hoc routing protocol Fig. 10 AHGL in the master mode

output of the scheduler is a dispatch table which describes which job will be executed at which node (step 8). The dispatch table, parameters table and the job queue are input in the fourth service – dispatcher (step 9). This service is responsible for dispatching the jobs to the corresponding slave nodes (step 10). After the completion of the jobs, in step 11, the dispatch service waits for the results from the slave nodes. All of the results are sent to application interface service (step 12). The last step is performed when the application interface service transfers the result to the upper layer (step 13). IV. AHGL IN SLAVE MODE AHGL in slave mode is much simpler. The slave node has to announce its free resources if it fulfills the given criteria. It also executes jobs which are dispatched to it. This is achieved with the activation of the last two services: resource responder and job execution service. The work flow for this mode is shown on fig.11.

Fig. 11 AHGL in slave mode

In step 1, the node receives an AHGL request packet generated by the master. It generates an AHGL reply packet filled with its free resources (step 2), which is then sent to

the master node. Upon receiving packets with job description (step 3), the job execution service transfers the job to the application layer (step 4). When the job is finished, the results are sent back to the job execution service (step 5). Then the result is packed into a result packet and it is sent back to the master node (step 6). V. IMPLEMENTATION IN NS2 For the purposes of analysis of the performances of the ad hoc grid, the previously introduced AHGL was implemented as an extension to the commonly used NS-2 network simulator [10]. The AHGL is implemented using two separate types of application layer derived from the Agent class, FindResources and ExecuteTasks which simulate the behavior of the corresponding resource finder and task execution services, respectfully. For each of the agents the analogous packet types and header control fields are defined. The agents are also keeping track of the specific characteristics of the node where they are activated. In this way, we are able to use the existing routing and other lower level protocols with no necessity to make any kind of changes in their implementation. The FindResources agent is started at each node with the start of the simulation. When working in master mode the agent floods the ad hoc network broadcasting a resource request packet, after which awaits the responses from the slaves. For each received reply, the agent updates the resources table with the received parameters for the packet source slave node. In order to be able to compensate for any lost packets in the network, after a certain period of wait time, the agents stops awaiting for responses and goes into idle state. The agent activated in slave mode is programmed to create a reply packet when they receive a resource request packet and they are satisfying the needed characteristics concerning the processor, battery and memory. The slave fills out the reply packet with the necessary information

VI. SIMULATION This section presents practical results of the implementation of AHGL in NS-2. The simulations were done in order to analyze the effect of the node density on the time needed for execution of a certain application. Application contains 100 jobs on networks with different number of nodes ranging from 20 to 50. The nodes are

randomly scattered on a 600 x 600 m terrain. The CPU is in range from 0.5 to 3.5 GHz and every node has physical memory of 512 MB. The jobs size is from 5 to 30 KB and the number of instructions for one job is calculated as a square from the job size. As a scheduling algorithm for dispatching the jobs among the nodes we used the First Come First Served algorithm. In order to observe the influence of the network density on the time needed for the execution of the application we measured the speedup which is defined as the ratio between the execution time of the application on one node and the execution time of the application in ad hoc grid with a given number of nodes. The time for execution of all the jobs is measured from the moment of dispatching the first job in AHGL until the last result is received. In Fig. 12 speedup calculated from the simulations is shown. It can be concluded that by increasing the number of nodes, the execution time of a certain application decreases. When the number of nodes reaches some threshold the obtained speedup is saturated or is with less intensity.

6,2

5,7 Speedup

about its characteristics and then unicasts the packet to the request source, i.e the master, after which goes into idle state. After replying to the master, the slave then continues the network flooding process. Thus upon receiving another request packet (because of the network flooding process) it drops the packet with no other action. The ExecuteTasks agent is also started at each node and runs in two modes master and slave, depending on the node type. At the master, the agent reads the resource table and the scheduled tasks table in order to obtain information about the next task that needs to be executed. For each task that needs to be executed the agent determines the destination, creates one or several packets that contain the task and sends them to the slave for processing, after which marks the slave as busy. When the master receives a reply from one of the slaves that informs him about the completion of the task and the corresponding response, the master checks to see if there are more tasks for the given slave and, if this is the case, creates new packets with the next task that is to be executed at that slave. The constraints regarding the availability time of the slaves are taken into consideration by scheduling all task packets to be sent in the time interval when the corresponding slave is known to be available, which is made using the NS-2 own Scheduler class. When in slave mode, this agent responds to received task packet by creating a reply packet which contains a bogus result, which is scheduled to be sent to the master after the calculated delay for the purposes of simulation of the time needed to calculate the appropriate result. The total time needed for execution of each task in the ad hoc grid is calculated at the master as the difference between the time stamp on the sent task packet and the time stamp on the received reply for the given task from the slave. In order to be able to simulate the work of the ad hoc grid in a smooth fully featured manner, an AHGTool was developed. The AHGTools firstly reads the values for the adjustable parameters like number of nodes, number of tasks, scheduling algorithm to be used and so on, and afterwards creates tcl scripts which are used for simulation of the ad hoc grid behavior using NS-2. Firstly the ad hoc network topology is defined, then the FindResources agent is activated at each node and the resource finder service is simulated, afterwards the scheduler activity is activated and, in the end, the ExecuteTasks agents are activated and the task execution service is simulated. After all of the ad hoc network activity is over, the results are automatically processed in order to obtain the desired values for the observed parameters of the network.

5,2

4,7 0,2

0,25

0,3

0,35

0,4

0,45

0,5

number of nodes / number of jobs

Fig. 12 Speedup achieved in Grid environment relatively to one node

VII. CONCLUSION In this paper we presented a new layer for grid computing in ad hoc networks called Ad Hoc Grid Layer (AHGL). This layer is a result of the implementation of the grid services in an ad hoc network. Its position in the network architecture allows this layer to be independent from the upper or the lower layers and it allows new services to be added without changing the other layers. AHGL was created in a manner that corresponds to the ad hoc network specific features. It is designed to be able to adapt to the network dynamical environment with a high fault tolerance degree. The proposed AHGL is implemented in the NS2 simulator. The implementation allows us to investigate the advantages and the possible weaknesses of the model. It also gives the opportunities to make an optimization of the different parameters that influences the performances of the ad hoc grid. The scheduler service of AHGL offers large number of different kind of parameters for the network and the nodes that can offer implementation of a different scheduling algorithm.

In our future work we intend to conduct a research in order to discover how the new scheduling algorithms affect the performances of the AHGL. The main goal of the research will be to analyze when grid computing is effective in the ad hoc environment. REFERENCES [1]

[2]

[3]

[4]

J. Hwang and P. Aravamudham. Middleware services for P2P computing in wireless grid networks. IEEE Internet Computing, 8(4):40–46, 2004. S. Kurkovsky, Bhagyavati, and A. Ray. A collaborative problemsolving framework for mobile devices. In ACMSoutheast Regional Conference (ACMSE), pages 5–10, 2004. M. Waldburger and B. Stiller. Toward the mobile grid: Service provisioning in a mobile dynamic virtual organization. In IEEE International Conference on Computer Systems and Applications (ICCSA), pages 579–583, 2006. Matthew Smith, Thomas Friese, Bernd Freisleben. Towards a Service-Oriented Ad Hoc Grid. Third International Symposium on

Parallel and Distributed Computing/Third International Workshop on Algorithms, Models and Tools for Parallel Computing on Heterogeneous Networks (ISPDC/HeteroPar'04) pp. 201-208 [5] R. Baldoni, R. Beraldi, and A. Mian. Survey of service discovery protocols in mobile ad hoc networks. Technical Report MidLab 7/06, Dip. Informatica e Sistemistica, Universita di Roma, 2006. [6] Zhuoqun Li, Lingfen Sun and Emmanuel C. Ifeachor. Challenges of mobile ad hoc grid and their application in e-healthcare. University of Plymouth, UK. [7] Imran Ihsan, Muhammad Abdul Qadir and Nadeem Iftikhar, Mobile Ad-Hoc Service Grid-MASGRID. ENFORMATIKA V5 2005 ISSN 1305-5313. [8] Zhi Wang, Bo Yu, Qi Chen, Chunshan Gao. Wireless Grid Computing over Mobile Ad-Hoc Networks with Mobile Agent. 07695-2534-2/05 IEEE 2006. [9] Antonio Tadeu A. Gomes, Artur Ziviani, DICHOTOMY: A Resource Discovery and Scheduling Protocol for Multihop Ad hoc Mobile Grids. In Proceedings of the Seventh IEEE International Symposium on Cluster Computing and the Grid (CCGRID), pages 719-724, 2007. [10] The network simulator - NS-2 Available: http://www.isi.edu/nsnam/ns