WDC Architecture

Get Complete Project Material File(s) Now! »

Chapter 2 Software Architecture

Introduction

In order to enable wireless distributed computing, a management engine (implemented in software, hardware, or a combination of both) needs to exist. The WDC management engine is responsible for managing the distribution of tasks, the communication between nodes, and among other things the load balancing of work among available processing nodes in order to optimize the amount of time it takes to complete a task and the energy expended in completing the task. The goal of this thesis is to demonstrate that wireless distributed computing is possible on an Android platform. In order to fuse the concepts of distributed computing and Android, this chapter explains the WDC software architecture, which is the management engine implemented in software. It then provides an overview of the Android system. Finally, the Android implementation of the WDC software architecture is discussed.

WDC Architecture

The WDC software architecture is a design model for how a general wireless distributed computing system should work. The software architecture is designed with the goals of being a reusable and exible architecture for future improvements, as well as allowing for a clean implementation. In order to meet these design goals, the WDC software architecture is based upon a layered software model similar to the OSI networking model. Each layer in the WDC system provides services to the layer immediately above it, and as such is restricted to communicate with neighboring layers only [20]. Figure 2.1 shows the high level WDC architecture.
Figure 2.1 outlines the three major layers in the WDC software architecture: 1.) the WDC application layer, 2.) the WDC layer, and 3.) the Communications layer. The WDC appli-cation layer contains the applications that are to be executed over the distributed wireless network. The applications generally consist of a complex computational task (such as fa-cial recognition or 3D environment reconstruction) fragmented into atomic work units. An atomic work unit is de ned as the minimum amount of work that can be given to a certain processing node and is relative to the application. For example, a facial recognition appli-cation may de ne an atomic work unit to be recognizing one face, while a 3D environment reconstruction application may de ne an atomic work unit to be reconstructing one of the three dimensions. The WDC Application layer performs application-dependent functions required for WDC. Fragmenting the application computational task into atomic work units is one such example.
The WDC layer is the software piece that deals with managing the entire WDC system. The main job of the WDC layer is to optimize how the task to be completed by the wireless application should be distributed such that total energy and processing time are minimized. The WDC layer makes some high-level decisions, including whether or not to use local on-board processing or distributed processing for a given WDC application. The WDC layer manages and controls various aspects of distributed computing on the wireless network. It performs application-independent functions that are relevant for distributed computing, such as providing WDC metrics to the optimizer for making decisions between local and distributed processing, optimizing WDC resource allocation, and controlling and managing the distributed computation processes [20]. Finally, as Figure 2.1 shows, the WDC layer provides an API to the WDC application layer to allow the wireless applications the ability to use the WDC system. The WDC layer can be considered as the \brains » of the WDC system, since it manages the distribution of tasks, execution of the task, and accumulation of results.
The communications layer takes care of reliable communications between the wirelessly dis-tributed nodes. The communications layer provides an API to the WDC layer in order to allow the WDC system to seamlessly communicate with any other node in the system, regardless of whether the low level communications mechanism is a TCP/IP based WiFi network or a proprietary communications protocol.
It is important to note that there is no distinction between master and slave nodes in the WDC architecture, as shown by Figure 2.1. The node starting the wireless application is automatically considered the master node while nodes assisting in the processing are slave nodes. Any node can be a master or slave node in the WDC architecture described, and all nodes must run the same software that enables WDC.
The detailed WDC architecture is shown in Figure 2.2 [20]. As shown by Figure 2.2, the WDC layer is made up of the WDC Interface, the WDC controller, Local Task Executor, Optimizer, Network and System Monitor, and the Communications interface. At a high level, these components work together to provide WDC functionality to the WDC application.
The WDC Interface is, as shown in Figure 2.2, the interface to the WDC application layer. It provides function calls that the wireless application (such as the distributed facial recog-nition) can use. The function calls speci ed by the WDC software architecture for the WDC interface are listed in Table 2.1.
The API speci ed by the WDC interface is used by the wireless application to manage a task. For example, a wireless application would start a task by calling the queueJob() function. It would receive the job results by calling the requestJobResults() function.
The WDC controller can be considered the nerve center of the WDC layer software. On the master node, the WDC controller coordinates the entire distribution of the job. Once a job is queued by the user to the WDC Interface through the queueJob() function, the WDC controller pulls in that speci c job request. The WDC controller then sends a request to the Optimizer block to determine how best to distribute the job. The optimizer’s response is then used by the WDC controller to allocate atomic work units to each slave node through the Communications interface. For a slave node, the WDC controller’s job is to listen for task execution requests from the Communications interface. If a task execution request is received on a slave node, the WDC controller will pass the atomic work units to the Local Task Executor for algorithm execution. After the Local Task Executor has completed processing the task, the WDC controller on the slave node will push the results back to the node from which the request came.
The job of the Local Task Executor (LTE) is to run the user-speci c algorithm processing software with the work assigned to that speci c node. After the atomic work units have been processed by the node, the results are pushed back to the node which assigned the slave node that speci c task.
The goal of the Optimizer is to determine the optimal distribution of the job such that both total energy required to complete the task and the total time required to process the task are minimized. In order to perform its function, the Optimizer communicates with the Network and State monitor (NSM) to determine the the state of every node available for processing in the WDC network. The theory and the algorithm behind the optimizer is explained in detail in Chapter 3. In short however, the optimizer uses the state information of all the available nodes to determine how best to distribute the atomic work units among the available processing nodes. For example, suppose there are 100 atomic work units to be processed and ve available processing nodes. The optimizer will use the network state monitor to get state information about each available processing nodes. Based on the battery life available to each node, the current processing load that the node is under, the number of network hops that a node is away from the master node, and an optimization criterion, the optimizer may decide to use three of the ve available processing nodes with an even distribution among the nodes, or use all ve nodes with an uneven job distribution among all nodes.
As stated above, the job of the Network and State Monitor (NSM) is to provide state information to the optimizer when requested. State information includes percentage battery life remaining, current processing load, and the communications latency between the node and the master node.
Finally, the communications interface is a generalized API that allows the WDC controller to communicate with the other nodes. The generalized API allows for a standard interface to be de ned between the WDC controller and the communications interface, regardless of the actual wireless protocol or technology that is used for communication between wireless nodes, that allows nodes to communicate with each other.
 

Android

The WDC software architecture described in Section 2.2 above is generalized such that it can be implemented on any architecture and operating system, because the WDC software architecture essentially de nes a generalized API rather than how it should be implemented. This section describes the Android operating system and the components that make up an Android application, such as a wireless application that uses the WDC service or the WDC service itself.
The Android operating system is a Linux based operating system built for mobile devices by the Open Handset Alliance. It contains many components including a Linux based kernel, middleware, and core applications required for basic mobile device functionality.
Figure 2.3 shows the Android architecture in detail [11]. It highlights the major components that make up Android. As can be seen from Figure 2.3, the major Android components are the Applications, Application Framework, Libraries, Android Runtime, and the modi ed Linux kernel. These components work together in the form of applications, or \Apps », in order to provide mobile device functionality to the user. The Linux based Android kernel provides core system services to the Android OS including security, memory management, process management, hardware access, and network connectivity. The kernel essentially acts as an abstraction layer between the hardware on-board the mobile device and the rest of the software stack. Kernel and middleware code (software libraries, application framework code) is generally written in the C programming language. Applications for Android are generally written in the Java programming language and work with the kernel through the Application Framework and Libraries to provide functionality to the user [11]. The Android runtime pulls it all together and allows the application code to be executed in a real-time fashion to provide a user experience.

1 Introduction 
1.1 Overview
1.2 Prior Work
2 Software Architecture 
2.1 Introduction
2.2 WDC Architecture
2.3 Android
2.4 Android Implementation of WDC Architecture
3 Theory 
3.1 Introduction
3.2 Assumptions
3.3 Processing
3.4 Communication
3.5 Resource Function
3.6 Continuous Approximation
3.7 Convexity
3.8 Optimizer
4 Simulation and Results 
4.1 Introduction
4.2 Testing Environment
4.3 Testing and Results
4.4 Theoretical Model Validation
4.5 Model Anomalies
4.6 Interesting Observations
4.7 Scalability
5 Conclusions and Future Work 
5.1 Summary
5.2 Recommendations for Future Work .
GET THE COMPLETE PROJECT
Wireless Distributed Computing on the Android Platform