Computer Science Technical Report Archive

USC Computer Science Technical Reports, no. 848 (2005)

(USC DC Other)

USC Computer Science Technical Reports, no. 848 (2005)

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content Macro-programming Wireless Sensor Networks using Kairos Ramki, Om, Ramesh No Institute Given Abstract. The literature on programming sensor networks has, by and large, fo- cused on providing higher-level abstractions for expressing local node behavior. Kairos is a natural next step in sensor network programming in that it allows the programmer to express, in a centralized fashion, the desired global behavior of a distributed computation on the entire sensor network. Kairos’ compile-time and runtime subsystems expose a small set of programming primitives, while hiding from the programmer the details of distributed code generation and instantia- tion, remote data access and management, and inter-node program flow coordi- nation. Kairos’ runtime is greatly simplified by assuming eventual consistency in node state; this assumption underlies many practical distributed computations proposed for sensor networks. In this paper, we describe Kairos’ programming model, and the flexibility and robustness it affords programmers. We demon- strate its suitability, through actual implementation, for a variety of distributed programs—both infrastructure services and signal processing tasks—typically encountered in sensor network literature: routing tree construction, localization, and object tracking. Our experimental results suggest that Kairos does not ad- versely affect the performance or accuracy of distributed programs, while our implementation experiences suggest that it greatly raises the level of abstraction presented to the programmer. 1 Introduction and Motivation Wireless sensor networks research has, till date, made impressive advances in platforms and software services [1,2,3]. The utility and practicality of dense sensing using wire- less sensor networks has also been demonstrated recently [4,5,6]. It is now time to con- sider an essential aspect of sensor network infrastructure—support for programming wireless sensor network applications and systems components at a suitably high-level of abstraction. Many of the same reasons that have motivated the re-design of the net- working stack for sensor networks (energy-efficiency, different network use models) also motivate a fresh look at programming paradigms for these networks. Two broad classes of programming models are currently being investigated by the community. One class focuses on providing higher-level abstractions for specifying a node’s local behavior in a distributed computation. Examples of this approach include the recent work on node-local or region-based abstractions [7,8]. By contrast, a sec- ond class considers programming a sensor network in the large (this has sometimes been called macroprogramming). One line of research in this class enables a user to declaratively specify a distributed computation over a wireless sensor network, where the details of the network are largely hidden from the programmer. Examples in this class include TinyDB [9,10], and Cougar [11]. Kairos’ programming model specifies the global behavior of a distributed sensornet computation using a centralized approach to sensornet programming. Kairos presents an abstraction of a sensor network as a collection of nodes (Section 3) that can all be tasked together simultaneously within a single program. The programmer is presented with three constructs: reading and writing variables at nodes, iterating through the one- hop neighbors of a node, and addressing arbitrary nodes. Using only these three simple language constructs, programmers implicitly express both distributed data flow and dis- tributed control flow. We argue that these constructs are also natural for expressing computations in sensor networks: intuitively, sensor network algorithms process named data generated at individual nodes, often by moving data to other nodes. Allowing the programmer to express the computation by manipulating variables at nodes allows us to almost directly use “textbook” algorithms, as we show later in detail in Section 3.2. Given the single centralized program, Kairos’ compile-time and runtime systems construct and help execute a node-specialized version of the compiled program for all nodes within a network. The code generation portion of Kairos is implemented as a language preprocessor add-on to the compiler toolchain of the native language. The compiled binary that is the single-node derivation of the distributed program includes runtime calls to translate remote reads and, sometimes, local writes into network mes- sages. The Kairos runtime library that is present at every node implements these run- time calls, and communicates with remote Kairos instances to manage access to node state. Kairos is language-independent in that its constructs can be retrofitted into the toolchains of existing languages. Kairos (and the ideas behind it) are related to shared-memory based parallel pro- gramming models implemented over message passing infrastructures. Kairos is dif- ferent from these in one important respect. It leverages the observation that most dis- tributed computations in sensor networks will rely on eventual consistency of shared node state both for robustness to node and link failure, and for energy efficiency. Kairos’ runtime loosely synchronizes state across nodes, achieving higher efficiency and greater robustness over alternatives that provide tight distributed program synchronization se- mantics (such Sequential Consistency, and variants thereof [12]). We have implemented Kairos as an extension to Python. We describe our implemen- tation of the language extensions and the runtime system in Section 4. On Kairos, we have implemented three distributed computations that exemplify system services and signal processing tasks encountered in current sensor networks: constructing a short- est path routing tree, localizing a given set of nodes [2], and object tracking [13]. We exhibit each of them in detail in Section 3 to illustrate Kairos’ expressivity. We then demonstrate through extensive experimentation (Section 5) that Kairos’ level of ab- straction does not sacrifice performance, yet enables compact and flexible realizations of these fairly sophisticated algorithms. For example, in both the localization and ve- hicle tracking experiments, we found that the performance (convergence time, and net- work message traffic) and accuracy of Kairos are within 2x of the reported performance of explicitly distributed original versions, while the Kairos versions of the programs are more succinct and, we believe, are easier to write. Programming Abstractions Support Global Behavior Local Behavior Composition (Sensorware/Snack) Safe Execution (Maté, Tofu) Services (Impala) Node Dependent (Kairos, Regiment) Node Independent (SQL, Astrolabe, Dfuse) Data-Centric (EIP, State Space) Geometric (Regions, Hood) Fig. 1. Taxonomy of Programming Models for Sensor Networks 2 Related Work In this section, we give a brief taxonomy (Figure 1) of sensornet programming and place our work in the context of other existing work in the area. The term “sensor- net programming” seems to refer to two broad classes of work that we categorize as programming abstractions and programming support. The former class is focused on providing programmers with abstractions of sensors and sensor data. The latter is fo- cused on providing additional runtime mechanisms that simplify program execution. Examples of such mechanisms include safe code execution, or reliable code distribu- tion. We now consider the research on sensor network programming abstractions. Broadly speaking, this research can be sub-divided into two sub-classes: one sub-class focuses on providing the programmer abstractions that simplify the task of specifying the node local behavior of a distributed computation, while the second enables programmers to express the global behavior of the distributed computation. In the former sub-class, three different types of programming abstractions have been explored. For example, Liu et al. [14] and Cheong et al. [15] have considered node group abstractions that permit programmers to express communication within groups sharing some common group state. Data-centric mechanisms are used to efficiently im- plement these abstractions. By contrast, Mainland et al. [8] and Whitehouse et al. [7] show that topologically defined group abstractions (“neighborhoods” and “regions” re- spectively) are capable of expressing a number of local behaviors powerfully. Finally, the work on EIP [16] provides abstractions for physical objects in the environment, enabling programmers to express tracking applications. Kairos falls into the sub-class focused on providing abstractions for expressing the global behavior of distributed computations. One line of research in this sub-class pro- vides node-independent abstractions—these programming systems do not contain ex- plicit abstractions for nodes, but rather express a distributed computation in a network- independent way. Thus, the work on SQL-like expressive but Turing-incomplete query systems (e.g., TinyDB [10,9] and Cougar [11]), falls into this class. Another body of work provides support for expressing computations over logical topologies [17,18] or task graphs [19] which are then dynamically mapped to a network instance. Complementary to these approaches, node-dependent abstractions allow a program- mer to express the global behavior of a distributed computation in terms of nodes and node state. Kairos, as we shall discuss later, falls into this class. As we show, these abstractions are natural for expressing a variety of distributed computations. The only other piece of work in this area is Regiment [20], a recent work. While Kairos focuses on a narrow set of flexible language-agnostic abstractions, Regiment focuses on explor- ing how functional programming paradigms might be applied to programming sensor networks in the large. Finally, quite complementary to the work on programming abstractions is the large body of literature devoted to systems in support of network programming. Such sys- tems enable high-level composition of sensor network applications (Sensorware [21] and SNACK [22]), efficient distribution of code (Deluge [23]), support for sandboxed application execution (Mat´ e [24]), and techniques for automatic performance adapta- tion (Impala [25]). 3 Kairos Programming Model In this section, we describe the Kairos abstractions and discuss their expressivity and flexibility using three canonical sensor network distributed applications: routing tree construction, ad-hoc localization, and vehicle tracking. 3.1 Kairos Abstractions and Programming Primitives As discussed above, Kairos is a simple set of extensions to a programming language (for concreteness, we focus on procedural languages) that allows programmers to ex- press the global behavior of a distributed computation. Kairos extends the programming language by providing three simple abstractions. The first of these is the node abstraction. Programmers explicitly manipulate nodes and lists of nodes. Nodes are logically named using integer identifiers. The logical nam- ing of nodes does not correspond to a topological structure. Thus, at the time of pro- gram composition, Kairos does not require programmers to specify a network topology. In Kairos, the node datatype exports operators like equality, ordering (based on node name), and type testing. In addition, Kairos provides anode list iterator data type for manipulating node sets. The second abstraction that Kairos provides is the list of one-hop neighbors of a node. Syntactically, the programmer calls a get neighbors() function. The Kairos runtime (described below) returns the current list of the node’s radio neighbors. Given the broadcast nature of wireless communication, this is a natural abstraction for sensor network programming (and is similar to regions [8], and hoods [7]). Programmers are exposed to the underlying network topology using this abstraction. A Kairos program typically is specified in terms of operations on the neighbor list; it may construct more complex topological structures by iterating on these neighbors. The third abstraction that Kairos provides is remote data access, namely the ability to read from variables at named nodes. Syntactically, the programmer uses avariable@node notation to do this. Kairos itself does not impose any restrictions on which remote vari- ables may be read where and when. However, Kairos’ compiler extensions respect the scoping, lifetime, and access rules of variables imposed by the language it is extend- ing. Of course, variables of types with node-local meaning (e.g., file descriptors, and memory pointers) cannot be meaningfully accessed remotely. Node Synchronization: Kairos’ remote access facility effectively provides a shared- memory abstraction across nodes. The key challenge (and a potential source of ineffi- ciency) in Kairos is the messaging cost of synchronizing node state. One might expect that nodes would need to synchronize their state with other nodes (update variable val- ues at other nodes that have cached copies of those variables, or coordinate writes to a variable) often. In Kairos, only a node may write to its variable, thus mutually exclusive access to remote variables is not required; thereby, we also eliminate typically subtle distributed programming bugs arising from managing concurrent writes. Kairos leverages another property of distributed algorithms for sensor networks in order to achieve low overhead (indeed, without this, Kairos would not even be practi- cable for sensor networks). We argue that, for fairly fundamental reasons, distributed algorithms will rely on a property we call eventual consistency: individual intermediate node states are not guaranteed to be consistent, but, in the absence of failure, the com- putation eventually converges. This notion of eventual consistency is loosely molded on similar ideas previously proposed in well-known systems such as Bayou [26]. The reason for this, is, of course, that sensor network algorithms need to be highly robust to node and link failures, and many of the proposed algorithms for sensor networks use soft-state techniques that essentially permit only eventual consistency. Thus, Kairos is designed under the assumption that loose synchrony of node state suffices for sensor network applications. Loose synchrony means that a read from a client to a remote object blocks only until the referenced object is initialized and avail- able at the remote node and not on every read to the remote variable. This allows nodes to synchronize changed variables in a lazy manner, thereby reducing communication overhead. However, a reader might be reading a stale value of a variable, but because of the way distributed applications are designed for sensor networks, the nodes eventually converge to the right state. Surprisingly enough, as we shall see in Section 3.2, this form of synchrony seems to be adequate enough for many programs. The Mechanics of Kairos Programming: Before we discuss examples of program- ming in Kairos, we discuss the mechanics of programming and program execution (Figure 2). As we have said before, the distinguishing feature of Kairos is that program- mers write a single centralized version of the distributed computation in a programming language of their choice. 1 This language, we shall assume, has been extended to incor- porate the Kairos abstractions. For ease of exposition, assume that a programmer has written a centralized program P that expresses a distributed computation; in the rest of this section, we discuss the transformations on P performed by Kairos. Kairos’ abstractions are first processed using a preprocessor which resides as an extension to the language compiler. Thus, P is first pre-processed to generate annotated source code, which is then compiled into a binary P b using the native language com- piler. While P represents a global specification of the distributed computation, P b is a node-specific version that contains code for what a single node does at any time, and what data, both remote and local, it manipulates. In generating P b , the Kairos preprocessor identifies and translates references to re- mote data into calls to the Kairos runtime. P b is linked to the Kairos runtime and can be 1 We believe that Kairos abstractions are language-agnostic. However, we have only validated this with one language (Python), as we describe in Section 4. Multi-hop wireless network Centralized Program Annotated Binary Kairos Preprocessor & Language Compiler Program Kairos Runtime Thread of control Sync Read/Write Cached Objects Managed Objects Queue Manager Requests Replies Sensor Node Link with runtime & distribute Program Kairos Runtime Thread of control Sync Read/Write Cached Objects Managed Objects Queue Manager Requests Replies Sensor Node Link with runtime & distribute Link with runtime & distribute Fig. 2. Kairos Programming Architecture distributed to all nodes in the sensor network through some form of code distribution and node re-programming facility [27,23]. When a copy is instantiated and run on each sensor node, the Kairos runtime exports and manages program variables that are owned by the current node but are referenced by remote nodes; these objects are called man- aged objects in Figure 2. In addition, it also caches copies of managed objects owned by remote nodes in its cached objects pool. Accesses to both sets of objects are man- aged through queues as asynchronous request/reply messages that are carried over a potentially multihop radio network. The user program that runs on a sensor node calls synchronously into Kairos runtime for reading remote objects, as well as for accessing local managed objects. These syn- chronous calls are automatically generated by the preprocessor. The runtime accesses these cached and managed objects on behalf of the program after suspending the call- ing thread. The runtime uses additional background threads to manage object queues, but this aspect is transparent to the application, and the application is only aware of the usual language threading model. 3.2 Examples of Programming with Kairos We now illustrate Kairos’ expressivity and flexibility by describing how Kairos may be used to program three different distributed computations that have been proposed for sensor networks: routing tree construction, localization, and vehicle tracking. 1: void buildtree(node root) 2: node parent, self; 3: unsigned short dist_from_root; 4: node_list neighboring_nodes, full_node_set; 5: unsigned int sleep_interval=1000; //Initialization 6: full_node_set=get_available_nodes(); 7: for (node temp=get_first(full_node_set); temp!=NULL; temp=get_next(full_node_set)) 8: self=get_local_node_id(); 9: if (temp==root) 10: dist_from_root=0; parent=self; 11: else dist_from_root=INF; 12: neighboring_nodes=create_node_list(get_neighbors(temp)); 13: full_node_set=get_available_nodes(); 14: for (node iter1=get_first(full_node_set); iter1!=NULL; iter1=get_next(full_node_set)) 15: for(;;) //Event Loop 16: sleep(sleep_interval); 17: for (node iter2=get_first(neighboring_nodes); iter2!=NULL; iter2=get_next(neighboring_nodes)) 18: if (dist_from_root@iter2+1<dist_from_root) 19: dist_from_root=dist_from_root@iter2+1; 20: parent=iter2; Fig. 3. Procedural Code for Building a Shortest-path Routing Tree Routing Tree Construction In Figure 3, we illustrate a complete Kairos program for building a routing tree with a given root node. We have implemented this algorithm, and evaluate its performance in Section 5. Note that our program implements shortest- path routing, rather than selecting paths based on link-quality metrics [28]: we have experimented with the latter as well, as we describe below. The code shown in Figure 3 captures the essential functionality involved in con- structing a routing tree while maintaining brevity and clarity. It shows how a centralized Kairos task looks, and illustrates how the Kairos primitives are used to express such a task. Program variabledist from root is the only variable that needs to be remotely accessed in lines 18-19, and is therefore a managed object at a source node and a cached object at the one-hop neighbors of the source node that programmatically read this vari- able. The program also shows how thenode andnode list datatypes and their API’s are used.get available nodes() in lines 6 and 13 instructs the Kairos preprocessor to include the enclosed code for each iterated node; it also provides an iterator handle that can be used for addressing nodes from the iterator’s perspective, as shown in line 12. Finally, the program shows how theget neighbors() function is used in line 12 to acquire the one-hop neighbor list at every node. The event loop between lines 15-20 that runs at all nodes eventually picks a short- est path from a node to the root node. Our implementation results show that the path monotonically converges to the optimal path, thereby demonstrating progressive cor- rectness. Furthermore, the path found is stable and does not change unless there are transient or permanent link failures that cause nodes to be intermittently unreachable. This event loop illustrates how Kairos leverages eventual consistency. The access to the remote variable dist from root need not be synchronized at every step of the iteration; the reader can use the current cached copy, and use a lazy update mechanism to avoid overhead. As we shall see in Section 5, the convergence performance and the message overhead of loose synchrony in real-world experiments is reasonable. We also tried metrics other than shortest hop count (such as fixing parents according to available bandwidth or loss rates, a common technique used in real-world routing systems [3]), and we found that the general principle of eventual consistency and loose synchrony can be applied to such scenarios as well. Let us examine Figure 3 for the flexibility programming to the Kairos model af- fords. If we want to change the behavior of the program to have the tree construction algorithm commence at a pre-set time that is programmed into a base station node with id 0, we could add a single line before the start of the for(){} loop at line 7: sleep(starting time@0-get current time()). The runtime would then au- tomatically fetch thestarting time value from node 0. Finally, we study how to incorporate robustness into Kairos programs. The program, the way it is currently written, is quite fragile with respect to node and link failures be- cause it may try to read unavailable remotedist from root’s@neighboring node’s inside the loop between lines 17-20. We could re-write the program a little differently so that we periodically refresh the neighbor list. Thus, in order to make the program above robust, we would eliminate line 12 of the code, and insert the following fragment at line 17 to recover from failed parent links: neighboring_nodes=create_node_list(get_neighbors(iter1)); //Check whether a node’s parent still exists or is dead boolean parent_exists=false; for (node iter2=get_first(neighboring_nodes); iter2!=NULL && iter2!=root; iter2=get_next(neighboring_nodes)) if (iter2==parent) parent_exists=true; if (!parent_exists) dist_from_root=INF; Distributed Localization using Multi-lateration Figure 4 gives a complete distributed program for collaboratively fixing the locations of nodes with unknown coordinates. The basic algorithm was developed by Savvides et al. [2]. Our goal in implementing this algorithm in Kairos was to demonstrate that Kairos is flexible and powerful enough to program a relatively sophisticated distributed computation. We also wanted to explore how difficult it would be to program a “textbook” algorithm in Kairos, and compare the relative performance of Kairos with the reported original version (Section 5). The goal of the “iterative multi-lateration” algorithm is to compute the locations of all unknown nodes in a connected meshed wireless graph given ranging measurements between one-hop neighboring nodes and a small set of beacon nodes that already know their position. Sometimes, it may happen that there are not enough beacon nodes in the one-hop vicinity of an unknown node for it to mathematically laterize its location. The basic idea is to iteratively search for enough beacons and unknown nodes in the network graph so that, taken together, there are enough measurements and known co-ordinates to successfully deduce the locations of all unknown nodes in the sub-graph. Figure 4 shows the complete code for the iterative multi-lateration algorithm. 2 The code localizes non-beacon nodes by progressively expanding the subgraph, (subgraph to localize), considered at a given node with next-hop neighbors of unlocalized leaf vertices (unlocalized leaves), and is an implementation of Savvides’ algorithm [2]. The process continues until either all nodes in the graph are considered (lines 20-25) and the graph is deemed unlocaliz- able, or until the initiator localizes itself (using the auxiliary functionsubgraph check()) 2 Of course, we have not included the low-level code that actually computes the range estimates using ultrasound beacons. Our code snippet assumes the existence of node-local OS/library support for this purpose. 1: void iterativeMultilateration() 2: boolean localized=false, not_localizable=false, is_beacon=GPS_available(); 3: node self=get_local_node_id(); 4: graph subgraph_to_localize=NULL; 5: node_list full_node_set=get_available_nodes(); 6: for (node iter=get_first(full_node_set); iter!=NULL; iter=get_next(full_node_set))) //At each node, start building a localization graph 7: participating_nodes=create_graph(iter); 8: node_list neighboring_nodes=get_neighbors(iter); 9: while ((!localized || !is_beacon) && !not_localizable) 10: for (node temp=get_first(neighboring_nodes); temp!=NULL; temp=get_next(neighboring_nodes)) //Extend the subgraph with neighboring nodes 11: extend_graph(subgraph_to_localize, temp, localized@temp2||is_beacon@temp2?beacon:unknown); //See if we can localize the currently available subgraph 12: if (graph newly_localized_g=subgraph_check(subgraph_to_localize)) 13: node_list newly_localized_l=get_vertices(newly_localized_g); 14: for (node temp=get_first(newly_localized_l); temp!=NULL; temp=get_next(newly_localized_l)) 15: if (temp==iter) localized=true; 16: next; //If not, add nodes adjacent to the leaves of the // accumulated subgraph and try again 17 node_list unlocalized_leaves; 18: unlocalized_leaves=get_leaves(subgraph_to_localize); 19: boolean is_extended=false; 20: for (node temp1=get_first(unlocalized_leaves); temp!=NULL; temp=get_next(unlocalized_leaves)) 21: node_list next_hop_l=get_neighbors(temp); 22: for (node temp2=get_first(next_hop_l); temp2!=NULL; temp2=get_next(next_hop_l)) 23: extend_graph(subgraph_to_localize, temp2, localized@temp2||is_beacon@temp2?beacon:unknown); 24: is_extended=true; 25: if (!is_extended) not_localizable=true; Fig. 4. Procedural Code for Localizing Sensor Nodes after acquiring a sufficient number of beacon nodes. This program once again illustrates eventual consistency because the variable localized@node is a monotonic boolean, and eventually attains its correct asymptotic value when enclosed in an event loop. We also found an interesting testimonial to the value of Kairos’ centralized global program specification approach—we encountered a subtle logical (corner-case recursion) bug in the original algorithm described in [2] in a local (i.e., bottom-up, node-specific) manner, that became apparent in Kairos. Kairos’ abstractions allow a programmer to trade-off some robustness for increased efficiency. For example, in the version of the code shown, all nodes simultaneously, and somewhat redundantly, initiate localization. This makes it extremely robust because each node is only responsible for localizing itself. However, this approach loses out optimization opportunities for joint localization where one node can localize on behalf of others. We can make the following simple modifications to have only one node with lowest id within each broadcast domain act as the initiator: at line 8, add a simple check for node identifier comparison by reading node id@temp, and enter the loop at line 9 only if the node is the minimum numbered. Finally, in step 15, the node with minimum node id does not just set localized for itself, but also for all other nodes for whichlocalized@iter=true by storing theseiter node values in a local array. Every node periodically checks these remote (from its perspective) array values at all initiators in the network for its own presence. 1: void track vehicle() 2: boolean master=true; 3: float grid[MAX X][MAX Y], z t+1 , normalizing const; 4: float p(x t|z t )[MAX X][MAX Y], p(x t+1 |z t )[MAX X][MAX Y], p(z t+1 |x t+1 )[MAX X][MAX Y], p(x t+1 ,z k t+1 |z t )[MAX X][MAX Y], p(z k t+1 |z t ), D xz[MAX X][MAX Y], p(x t+1 |z t+1 )[MAX X][MAX Y]; 5: float max I k =I k ; node argmax I k , self=get local node id(); 6: node list full node set=get available nodes(); 7: for (node iter=get first(full node set); iter!=NULL; iter=get next(full node set)) 8: for (int x=0; x<MAX X; x++) 9: for (int y=0; y<MAX Y; y++) 10: p(x t|z t )[x][y]= 1 MAX X×MAX Y ; 11: for(;;) 12: sleep(); 13: if (master) 14: for (int x=0; x<MAX X; x++) 15: for (int y=0; y<MAX Y; y++) 16: p(x t+1 |z t )[x][y]= ∑ 0≤x ′ <MAX X ∑ 0≤y ′ <MAX Y δ( q x ′2 + y ′2 − q x 2 + y 2 − v)p(x t|z t ) δ( q x ′2 + y ′2 − q x 2 + y 2 − v) ; 17: z t+1 =sense z(); 18: normalizing const=0; 19: for (int x=0; x<MAX X; x++) 20: for (int y=0; y<MAX Y; y++) 21: p(z t+1 |x t+1 )[x][y]= r δ a h Φ a hi −rz rσ − Φ a lo −rz rσ i ; 22: normalizing const+=p(z t+1 |x t+1 )[x][y]· p(x t+1 |z t )[x][y]; 23: for (int x=0; x<MAX X; x++) 24: for (int y=0; y<MAX Y; y++) 25: p(x t+1 |z t+1 )[x][y]= p(z t+1 |x t+1 )[x][y]·p(x t+1 |z t )[x][y] normalizing const ; 26: node list neighboring nodes=get neighbors(iter); 27: append to list(neighboring nodes, self); 28: max I k =−∞; argmax I k =self; 29: for (node temp=get first(neighboring nodes); temp!=NULL; temp=get next(neighboring nodes)) 30: p(z k t+1 |z t )=0; 31: for (int x=0; x<MAX X; x++) 32: for (int y=0; y<MAX Y; y++) 33: p(x t+1 ,z k t+1 |z t )[x][y]=p(z t+1 |x t+1 )[x][y]@temp·p(x t+1 |z t )[x][y]; 34: p(z k t+1 |z t )+=p(x t+1 ,z k t+1 |z t )[x][y]; 35: for (int x=0; x<MAX X; x++) 36: for (int y=0; y<MAX Y; y++) 37: I k += log   p(x t+1 ,z k t+1 |z t )[x][y] p(x t+1 |z t )[x][y]p(z k t+1 |z t )   · p(x t+1 ,z k t+1 |z t )[x][y]; 38: if (max I k

Abstract (if available)

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

USC Computer Science Technical Reports, no. 873 (2005)

PDF

USC Computer Science Technical Reports, no. 872 (2005)

PDF

USC Computer Science Technical Reports, no. 839 (2004)

PDF

USC Computer Science Technical Reports, no. 841 (2005)

PDF

USC Computer Science Technical Reports, no. 745 (2001)

PDF

USC Computer Science Technical Reports, no. 750 (2001)

PDF

USC Computer Science Technical Reports, no. 692 (1999)

PDF

USC Computer Science Technical Reports, no. 774 (2002)

PDF

USC Computer Science Technical Reports, no. 910 (2009)

PDF

USC Computer Science Technical Reports, no. 971 (2017)

PDF

USC Computer Science Technical Reports, no. 746 (2001)

PDF

USC Computer Science Technical Reports, no. 957 (2015)

PDF

USC Computer Science Technical Reports, no. 771 (2002)

PDF

USC Computer Science Technical Reports, no. 866 (2005)

PDF

USC Computer Science Technical Reports, no. 915 (2010)

PDF

USC Computer Science Technical Reports, no. 852 (2005)

PDF

USC Computer Science Technical Reports, no. 905 (2009)

PDF

USC Computer Science Technical Reports, no. 669 (1998)

PDF

USC Computer Science Technical Reports, no. 900 (2008)

PDF

USC Computer Science Technical Reports, no. 786 (2003)

Description

Ramakrishna Gummadi, Ramesh Govindan. "Macro-programming wireless senson networks using kairos." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 848 (2005).

Asset Metadata

Creator Govindan, Ramesh (author), Gummadi, Ramakrishna (author)

Core Title USC Computer Science Technical Reports, no. 848 (2005)

Alternative Title Macro-programming wireless senson networks using kairos (title)

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)

Tag OAI-PMH Harvest

Format 21 pages (extent), technical reports (aat)

Language English

Unique identifier UC16270540

Identifier 05-848 Macro-programming wireless senson networks using Kairos (filename)

Legacy Identifier usc-cstr-05-848

Format 21 pages (extent),technical reports (aat)

Rights Department of Computer Science (University of Southern California) and the author(s).

Internet Media Type application/pdf

Source 20180426-rozan-cstechreports-shoaf (batch), Computer Science Technical Report Archive (collection), University of Southern California. Department of Computer Science. Technical Reports (series)

Access Conditions The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Repository Email csdept@usc.edu

Inherited Values

Title Computer Science Technical Report Archive

Description Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.

Coverage Temporal 1991/2017

Repository Email csdept@usc.edu

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)