A Task Graph Based Application Framework for Mobile Ad Hoc Networks

Wang Ke, Prithwish Basu, and Thomas D.C. LittleDepartment of Electrical and Computer Engineering, Boston University

8 Saint Mary’s St., Boston, MA 02215, USA

Abstract—We propose a task graph based framework for mod-eling and execution of distributed applications in mobile ad hocnetworks. Our framework represents a distributed applicationby a graph composed of nodes and edges in which the nodeslog-ically represent application sub-tasks that need to be completedand the edges represent associations, with certain attributes, be-tween nodes. During application run-time, suitable devices thatcan complete the sub-tasks and can satisfy the attributes of theassociations between them are selected on-the-fly to execute theapplication. New devices are selected to continue application exe-cution if old devices become unavailable due to mobility. Thus, wede-couple the application from a specific set of devices and allowits execution if there is at least one suitable device in the networkfor carrying out each of the required sub-tasks. In this paper, wepropose an application execution protocol to realize this vision andshow simulation results which indicate that our approach is prac-tical for environments with low user/device mobility.

I. I NTRODUCTION

New exciting possibilities are being opened by the continualdecrease in size, increase in the quantity of processor-embeddeddevices that surround us, and the emergence of network en-abling technologies such as Bluetooth [1] and IEEE 802.11 [2].In a world where any display device, be it a PDA, a monitor, oreven a projector can act as my “TV screen”, and likewise, anyearphone or speaker can act as my “radio” or “MP3 player,”new challenges need be overcome to tap into the full potentialof such environments.

Traditional operating systems and network protocols havebeen generally concerned with specific memory or network ad-dresses. While the abstraction of “address” is essential, its un-derlying emphasis is on reaching aspecifichost that can com-plete a required task. However, with the proliferation and mul-tiplicity of devices that can perform similar tasks, we need ashift in focus towards emphasizing on how to characterize anapplication logically and how to allow an application compo-nent to “dynamically bind” itself to a device that can completethe corresponding task. No longer should we be prevented fromrunning an application when one specific device becomes un-available. Also, with specialized heterogeneous devices offer-ing different services in the environment of the user, an applica-tion may need to simultaneously request multiple services andtherefore must be able to determine the correct communicationrelationships required between these devices to ensure properexecution. In addition, due to the shrinking size of the devicesand added wireless networking capabilities, device mobility,which implies fluctuating service availability, is another issue

This work was supported by the NSF under grant No. ANI-0073843

Instance 1

Instance 2

Instance 3

Microphone Speaker 2Speaker 1

Video DisplayVideo Recorder

Network

Video Terminal Node

Fig. 1. A Node and its instances

that must be addressed in order to develop, run and support dif-ferent applications in aMobile Ad-hoc NETwork(MANET) en-vironment.

To tackle the challenges described, we introduce aTaskGraph(TG) based framework for application development andexecution in MANETs. Our TG approach is inherently dis-tributed, as we believe many of the applications for MANETsmust be. It also de-couples the task to be performed on any spe-cific host, allowing an application to take advantage of the mul-tiple devices that are present in the environment. In addition,it supports hierarchical composability, allowing sets of devicesto be logically grouped together and be treated as a single unitessentially enabling the network to offer new services based onexisting ones. We offer support for applications built in our TGframework by adding an intermediate layer above the routinglayer, theTasklayer. Thus, a “tele-conferencing virtual termi-nal” application, with its requirements of audio input/output,video input/output and networking capabilities, need no longerbe restrained to only one type of hardware configuration (typ-ically a networked multimedia computer). Instead, it can alsobe executed by a combination of electronic devices in a homeentertainment center or even by connecting a PDA, a digitalcamera and a cell phone as shown in Fig. 1.

In this paper, we present an initial implementation of the“task layer” of our TG-based approach in the network simu-lator ns [3]. We introduce some useful metrics to evaluate theperformance of the system and show that such approach is prac-tical under low mobility environments. In the next section wepresent related work in the area. Section III introduces theoret-ical foundations for the TG concept and describes the protocolimplemented by the Task layer. Section IV shows simulationdata. We conclude in Section V with an analysis of the dataobtained and a discussion of the conditions under which ourapproach performs more efficiently.

32790-7803-7400-2/02/$17.00 © 2002 IEEE

II. RELATED WORK

Task graphs have been used in the parallel computing andscheduling literature for representing tasks that can be splittem-porally into sub-tasks and then allocated to different homoge-neous processors for reducing total completion time [4]. Ourformulation of task graphs extends the concept described aboveby including heterogeneous devices, and switches focus fromminimizing the completion time of distributable sub-tasks toensuring the presence of suitable (heterogeneous) devices thatcan cooperatively complete the execution of a distributed appli-cation.

The de-coupling of a service from the host providing the ser-vice is the idea behind Service Location Protocol (SLP) [6] andJini [7], as well as MOCA [8], which offers a Jini-like ser-vice to mobile computing devices. Intentional Naming Sys-tem (INS) [9] is a more sophisticated scheme which attempts tocapture “user intent” to find an appropriate service. It also has alate binding feature that allows applications to bind themselvesto a service and not to any specific host. While we advocatethe same de-coupling principle, we apply such a principle inbuilding a systematic framework in which complex distributedapplications can be modeled, with the inter-relationships of itscomponents expressed and integrated with mobility manage-ment issues.

Both the Portolano project [10] and IBM’s Platform-Independent Model for Applications [11] represent visions thatconsider applications as services provided to or task executedon behalf of the end user, which should be independent of thespecific user interface devices available. Our work shares thesame vision, and is a concrete and systematic approach that at-tempts to realize it.

III. A T ASK GRAPH APPLICATION FRAMEWORK

Concepts and DefinitionsA deviceis a physical entity thatperforms at least one function such as interaction with its phys-ical environment, computation, or communication with otherdevices. There is alink between two devices with network-ing capabilities when at least one device can receive data sentfrom the other. A link can be unidirectional or bidirectional. Adevice’s capabilities are summarized by a set ofattributes. At-tributes can be static, such as the resolution of a digital camera,or dynamic, such as the location of the camera. Aserviceis afunctionality, possibly offered by a device or a collection of co-operating devices, in which a desired output is obtained throughprocessing a given input data. Anodeis an abstract representa-tion of a device or a collection of devices with a minimal set ofattributes that can offer a particular service. A node is simplewhen it represents a single device and it is complex when it rep-resents multiple devices. Anedgeis an association between 2nodes that satisfies certain attributes necessary for the comple-tion of a task. Ataskis work executed by a node. If the node iscomplex, then the work done by each of the constituents of thecomplex node is considered a “sub-task” of the task. Anatomic

task (defined in terms of a device’s capability and subjective de-sign criteria) is an indivisible unit of work which is executed bya simple node.

A task graphis a graphTG = (VT , ET ), whereVT is the setof nodes that need to participate in the task, andET is the set ofdirected edges (from source node to the destination node) asso-ciated with the task graph. A network of mobile devices can berepresented as a graphNG = (DN , LN ), whereDN is the setof devices that are present andLN is the set of links connectingany two devices. If we define apathof lengthN as an orderedsequence ofN unique links, in which the destination of linknis the source of linkn + 1, n ∈ {1, · · · , N − 1}, then anem-beddingor aninstantiationof a task graphTG onto a MANETNG is the process of selecting a pair of functions(ϕ,ψ), suchthatϕ : VT → DN andψ : ET → PLN , where the serviceand the set of attributes of a nodev ∈ VT are contained in theset of services offered and the collection of attributes of a de-viceϕ(v) ∈ DN , and where the attributes of an edgee ∈ ETare satisfied by a pathψ(e) ∈ PLN , PLN being the set of pathsformed by the links inLN . A particular pair of functions(ϕ,ψ)represent aninstanceof the task graphTG, and a deviceϕ(v)is an “instance” of the nodev. If an instance of a node becomesunavailable, the process of selecting a new suitable device iscalled node re-instantiation. The source node of an edge iscalled a “parent” of the destination node, and the destinationnode is a “child” of the source node.

Instantiation and Mobility Management in Task Graphs Wenow introduce our protocol which can be implemented at alayer above the routing and transport layers to support the taskgraph abstraction. It assumes the presence of one node that willact as thecontroller (or coordinator) of the application, i.e., itis in charge of instantiating each node of the task graph andexecuting the node re-instantiation process, if necessary. Sucha centralized approach simplifies the problem of instance syn-chronization, since all devices participating in the task knowthat the coordinator will always select a new instance if an ex-isting instance becomes unreachable. In addition to that, thisprotocol can take advantage of any available powerful comput-ing device in the environment to optimize the instantiation pro-cess, if applicable.

The Application Instantiationprocess can be decomposedinto three major phases:• Discovery: The controller broadcasts a TASK-QUERY

packet with a list of nodes and attributes desired. A devicereceiving this packet for the first time rebroadcasts it, andone that can satisfy the attributes of at least one node inthe list sends a TASK-QUERY-ACK back to the controllerindicating the node that it can be an instance of.

• Selection: The controller selects from among the possibleinstances one device that will be the node instance. Thecriterion we have used in this paper to select a device is tominimize the average path length over all edges in the taskgraph (see Sec. IV).

• Connection: Each selected node instance S of the task

3280

TQ − TASK QUERYQueries which devicescan be instances. Re−transmit if receivingfor the first time

TI − TASK INSTANTIATE

TL − TASK LINK

TG − TASK GRAPHNotifies which instancesare neighbors

TE − TASK EXEC

TD − TASK DATA

~~ ~~ ~~

Controller

Discovery

Selection

Connection

Instantiation Completed

Device A Device B

TQ−ACK

TQ−ACK

TI−ACK

TL−ACK

TD TD

TQ−ACK

Selects the node instance

TI−ACK

TG−ACK

Connects to child instancesTL−ACK

Starts the device

Data packet

TCPUDP

Tim

e

TQ

TQ TQ

TQ

TI

TITI−ACK

TG

TG TL

TG−ACKTG−ACK

TE

TE

TQ

Fig. 2. Application Instantiation Packet Exchange

graph is notified of its parent and children devices. Then,S proceeds to contact its children and replies to any con-tact attempt made by its parents. The controller is notifiedwhen all of S’s parents and children have been successfullycontacted.

Fig. 2 shows the packet exchange for the application instan-tiation part. Data exchange (through TASK-DATA packets) cantake place soon after the completion of this process. The trans-port protocol at the Discovery part does not have to be reliable,thus we characterized it as UDP in Fig. 2. However, during theSelection and Connection phases, the protocol should be reli-able, so as to distinguish between temporary path unavailability(and consequent packet drop) and true unreachability (see Sec.IV for details).

Mobility Managementof devices involves primarily twoproblems: (1) how to “detect” when a device cannot be reachedand (2) how to react to such an event.

We deal with thedetectionproblem by aperiodicpacket ex-change between the instances and the controller. The controllersends everyT seconds (T is the task layer timeout period)a TASK-CONTROLLER-HELLO packet to each selected in-stance (and to each possible instance until the completion ofthe selection part). In the same way, each selected instance(and each possible instance) sends with periodT : (1) a TASK-DEVICE-HELLO packet to the controller and (2) a TASK-NEIGHBOR-HELLO to each of its parent and child node in-stances, if these are known. Any device receiving such HELLOpackets must send back an acknowledgment. If the sender of aHELLO packet does not receive any TASK-related packet (withthe exception of TASK-QUERY) from the intended recipientwithin T sec, then the recipient is deemed unreachable. If the

Neighbor time outSending to Controller

NM

Controller startsReinstantiation

Controller Device A Device B

Tas

k tim

e ou

t

Device tim

e out

THTH

TH−ACKTH−ACK

NHNH

DH

DH

THTH

TH−ACK

NMDH

~~

~ ~

TQTQTQ

TQTQ

DH−ACKA

B

C

A

B

C

Device B resets

Packet Loss

THTH−ACKDHDH−ACKNH

NMNH−ACK

TQ

TASK HELLO

DEVICE HELLO

NEIGHBOR HELLO

NEIGHBOR MISSINGTASK QUERY

Tim

e

TCPUDP

Fig. 3. Mobility Management

unreachable host is the:1) Controller: The sender device considers that the appli-

cation cannot proceed and switches itself to an idle state(caseB in Fig. 3).

2) Node instance: The controller may repeat the discovery,selection and connection steps as necessary but only withrespect to the node with the missing instance, i.e., otherinstances are kept and no query is made regarding them.In Fig. 3, atC, the controller attempts tore-instantiatethe missing node and starts from the discovery phase.

3) Neighbor node instance: The sender device informs thecontroller that it has a missing neighbor node instance(caseA in Fig. 3). The controller performs a node re-instantiation if necessary and informs the reporting de-vice of its neighbor node’s new instance.

4) Possible node instance: The controller simply drops theunreachable device from the list of possible instances.

The main principle we tried to follow in designing the proto-col was that an application should proceed as long as there aresuitable devices on which it can run. In case such devices donot exist the application layer can be informed via a proper APImechanism to decide on a proper course of action. The “fatesharing” characteristic that a device acting as coordinator cur-rently has with the application can be avoided by developing astate management and recovery mechanism to elect a new co-ordinator when the original becomes unavailable. This topic isbeyond the scope of this paper and needs further research.

IV. SIMULATION RESULTS

We implemented our algorithm in the network simulatorns[3]. The routing protocol adopted was DSR[12]. One helpfulcharacteristic of DSR is source routing, in other words, pack-ets carry addresses of intermediate devices in the path betweenthe source and the destination. This information gives the con-troller a partial knowledge of the network topology, which weexplore in the selection phase of the instantiation. During se-lection, the controller must choose devices as node instancesof the task graph, from among multiple devices that answer its

3281

query. We apply the “breadth-first search” algorithm, startingfrom the controller node and choosing the child instance thathas the shortest path length (according to the network topologyknown by the controller at that instant) to its parent instance.

TCP was chosen as our reliable transport protocol. It min-imizes the probability of mistaking a temporary route failurewith a more permanent phenomenon of device unavailabilitydue to mobility. However, delays due to TCP’s inherent as-sumption of congestion in presence of packet loss, coupled withits subsequent backoff period before attempting retransmission,may result in HELLO packets arriving after their expected timeand triggering re-instantiations when the old instance is stillreachable. Researchers have proposed modifications to TCP toimprove its performance over MANETs [13], but in this paper,we have built our protocol on top of existing ones. For simula-tions, we chose the task layer timeoutT = 7s (the default TCPretransmission timer’s value is 6s).

Metrics and Results From our simulations we observed thevalue of the averageDilation1 of our instantiated task graphs.Average dilation is the average length of the paths mapped byan embedding algorithm over all the edges of the task graph.Lower dilation means less number of hops a packet must tra-verse, on average, when traveling between node instances. TheaverageTime to Instantiatea task graph is the second metricwe study – this is the time taken from the start of the discoveryphase until the end of the selection phase. A related metric isthe averageTime to Re-Instantiate, which is the time taken torediscover and re-select a new device when an existing instancebecomes unreachable. The fourth metric we look at is the aver-ageEffective Throughput, which is the average number of appli-cation data units (ADUs) received at the data destinations overthe number of ADUs that were supposed to be received by theintended targets if no packet drops occurred.

We simulated for 100 devices moving in a 1000m× 1000marea, with a transmission radius of 250m, and following theRandom Waypoint mobility model [14]. The devices were“simple” and belonged to one of the 12 types we had for thesimulation. Each device’s type was randomly selected follow-ing a uniform distribution.

Root

A B

C D

E

Root

A B

C D

E

Specialized Node

Data Flow

Data Sink

Data Source

Fig. 4. Task Graphs for Simulation

We show results for the task graphs in Fig. 4, namedTG1andTreetask. The total simulation time was 600s, with the instan-tiation starting at 50s, and the controller beginning a CBR flow(12500 bytes every 5 seconds) at 60s. Devices which are not

1This metric was originally introduced in [5].

0 2 4 6 8 10 12 14 16 18 200

0.5

1

1.5

2

2.5

3

Avg speed (m/s)

Ave

rage

Dila

tion

− in

num

ber o

f hop

s

TG1 − 0 s TG1 − 60 s treetask − 0 s treetask − 60 s

Fig. 5. Avg. Dilation

0 2 4 6 8 10 12 14 16 18 202

4

6

8

10

12

14

16

18

20

Avg speed (m/s)

Tim

e to

Inst

antia

te (s

)

TG1 − 0 s TG1 − 60 s treetask − 0 s treetask − 60 s

Fig. 6. Avg. Time to Instantiate

instances of the task graph do not forward these packets, thusif a downstream instance is missing at the moment a packet isin transit, the packet is simply dropped2. We simulated for themaximum device speed of 1, 5, 10, 15 and 20 m/s, and for apause time of 0 and 60 s.

Fig. 5 shows that the average dilation does not change signif-icantly with maximum speed, which is due to the fact that thetransmission radius, coupled with the spatially uniform devicedistribution and the size of the simulation area, simply ensuredthat the devices needed for instantiating the task graphs wouldbe within two hops.

The “average time to instantiate” metric (Fig. 6) shows anirregular pattern in our simulation results and we can see a peakwhen the maximum speed is 10 m/s. Such peaks happen mostwhen there is a packet loss or temporary route failure (conges-tion or partition), forcing the controller to go through multiplediscovery phases. For the “average time to re-instantiate” met-ric shown in Fig. 7, we can see that it increases with the maxi-mum speed. At higher speeds the route information cached byDSR becomes stale more quickly, and frequent route updates

2Data packets that follow different paths to a data sink are assumed to havebeen processed by the nodes they meet in the way and contain different informa-tion. Thus multipath availability in this study does not contribute to increasedreliability of data transmission.

3282

0 2 4 6 8 10 12 14 16 18 200

2

4

6

8

10

12

14

16

18

20

Avg speed (m/s)

Tim

e to

Rei

nsta

ntia

te (s

)

TG1 − 0 s TG1 − 60 s treetask − 0 s treetask − 60 s

Fig. 7. Avg. Time to Re-Instantiate

0 2 4 6 8 10 12 14 16 18 200.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Avg speed (m/s)

Thro

ughp

ut

TG1 − 0 s TG1 − 60 s treetask − 0 s treetask − 60 s

Fig. 8. Avg. Effective Throughput

can result in higher delays in packet exchange or even packetdrops, if the buffers of the routing agent become full. Thiseventually translates into the controller thinking that an instancemay be unreachable, which will trigger the re-instantiation pro-cess, and for the re-instantiation process to complete, all in-stances of the task graph must successfully exchange packetswith the controller within one timeout period. Our simulationresults show that it probably takes multiple timeout It is inter-esting to notice that even though the re-instantiation time is longdata are still reaching their intended destinations, as shown bythe average effective throughput in Fig. 8. This shows thateven though the whole task graph might not be fully instan-tiated (there are subtasks uninstantiated), still the parts whichare instantiated can carry on effective communication. This ismade clearer by the higher throughput of the Treetask graph, inwhich the data flows go through less number of instances (onlyparent→ child flows).

V. CONCLUSION

We have proposed in this paper a task graph framework tomodel distributed applications and support their execution inMANETs. Applications are modeled as graphs composed ofnodes, representing sub-tasks to be completed, and edges, rep-

resenting associations with certain attributes between the sub-tasks. We introduce run-time support for applications modeledin this way through a task layer which supports dynamic bind-ing of the tasks to specialized devices and performs their re-selection if any previously selected device moves away and be-comes unreachable.

Our protocol assumes the presence of a controller for eachapplication, responsible for performing discovery and selec-tion of suitable devices (task graph instantiation) on which theapplication will be executed. Also, we require periodic tasklayer packet exchange among the selected devices to monitoravailability. In the case of unavailability, the controller re-instantiates the nodes (selects new devices) whose instances aremissing. Simulation results based on our protocol show thatour approach is suitable for moderate to low mobility scenarios,e.g., where maximum speed does not exceed 10 m/s in a1 km2

area. Such environments can benefit from a higher throughputand lower application instantiation and re-instantiation delays.We noticed that task graphs with more independent data flows(flows intersect at less nodes) are more resilient to high mobilityand perform better in terms of throughput values. Distributedinstantiation protocols, although more complex in their opera-tion, are likely to be more robust under higher degrees of devicemobility. We have investigated such protocols elsewhere [15].

REFERENCES

[1] Bluetooth SIG,http://www.bluetooth.com[2] B. P. Crow, I. Widjaja, J. G. Kim, P. T. Sakai, “IEEE 802.11 wireless

local area networks,”IEEE Communications Magazine, Vol. 35, No. 9,Sep 1997, pp. 116-126.

[3] VINT Network Simulator - ns (version 2).http://www.isi.edu/nsnam/ns[4] S. H. Bokhari, “On the mapping problem,”IEEE Trans. on Computers,

Vol. 30, No. 3, 1981, pp. 207-214.[5] R. Monien and H. Sudborough, “Embedding one interconnection network

in another,”Computing Suppl. 7, 1990, pp. 257-282.[6] E. Guttman, “Service Location Protocol: automatic discovery of IP net-

work services,”IEEE Internet Computing, July 1999.[7] Sun Microsystems, “Jini Technology Core Platform Specification,”

http://www.sun.com/jini/specs[8] J. Beck, A. Gefflaut, and N. Islam, “MOCA: a service framework for

mobile computing devices,”Proc. ACM MobiDE, Seattle WA, Aug 1999.[9] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, and J. Lilley, “The de-

sign and implementation of an intentional naming system,”Proc. ACMSOSP ’99, Kiawah Island SC, Dec 1999.

[10] M. Esler, J. Hightower, T. Anderson, and G. Borriello, “Next centurychallenges: data-centric networking for invisible computing The Por-tolano Project at the University of Washington,”Proc. ACM MobiCom’99, Seattle WA, Aug 1999.

[11] G. Banavar, J. Beck, E. Gluzberg, J. Munson, J. Sussman, and D.Zukowski, “Challenges: an application model for pervasive computing,”Proc. ACM MobiCom ’00, Boston MA, Aug 2000.

[12] D. B. Johnson and D. A. Maltz, “Dynamic Source Routing in ad hocwireless networks,” inMobile Computing, edited by Tomasz Imielinskiand Hank Korth, chapter 5, pages 153-181, Kluwer Academic Pub., 1996.

[13] K. Chandran, S. Raghunathan, S. Venkatesan, and R. Prakash, “Afeedback-based scheme for improving TCP performance in ad hoc wire-less networks,”IEEE Personal Communications, Feb 2001.

[14] J. Broch, D. A. Maltz, D. B. Johnson, Y. C. Hu and J. Jetcheva, “A perfor-mance comparison of multi-hop ad hoc network routing protocols,”Proc.ACM MobiCom ’98, Dallas TX.

[15] P. Basu, W. Ke, and T.D.C. Little, “A novel approach for execution ofdistributed tasks on mobile ad hoc networks,”Proc. IEEE WCNC ’02,Orlando, FL, March 2002, in press.

3283