Hood – a Neighborhood Abstraction for Wireless Sensor Networks
Another Wireless Sensor Network middleware technique is called “Hood” which is short for Neighborhood. In this paper from Berkeley, the authors describe how Hood can simplify application programming. Instead of using neighborlists, data caches, and messaging protocols, Hood aggregates a cluster of nodes and lets the programmer treat them as one entity. It abstracts away the details of data caches and messaging protocols and lets nodes share and view attributes of neighboring nodes.
The user defines the attributes to be shared and the membership criteria. The Hood software takes over and keeps track of related nodes and their attribute values. This alleviates the user from having to program the search for attribute values and related nodes.
Hood uses a broadcast/filter mechanism for data sharing and neighbor discovery. Receiving nodes filter through the broadcast data to see which neighbors and which of their attributes should be cached. The receiving node or “observing” node determines who is in its neighborhood, rather than the broadcasting or “owner” node. When a node updates its attribute values, this is pushed to the neighbor nodes which can choose to update their data cache or delete it. This provides a “reflective” memory of those nodes’ attribute values. Hood is implemented in nesC on the TinyOS platform.
Efficiency of the network can be tuned based on the “push policy” in so far as how much data and how often it is pushed from one node to its neighbors. For some applications, a low push may be the best in order to conserve memory and battery power. In other applications, a large push more often may be required to provide accurate and up to date information on the network.
Hood faces some challenges. Each “neighborhood” must keep its own data set which can cause problems when neighborhoods overlap. Through the use of parameters, one can distinguish one neighborhood from another. Another challenge is that within a neighborhood, all neighbor values must be kept in memory. This can create an inefficient use of memory and ultimately require large memory capacities. Also, Hood hides the cost of messaging from the user. A user could potentially make requests of the system that weigh it down in terms of memory usage or communications bandwidth and not be aware of the cost of their request.
Hood is ideally suited for object tracking in which locationing, routing, and tracking must be coordinated within groups of nodes (read “neighborhoods”). It may be useful to other wireless sensor network applications in which “neighborhoods” provide a foundation for the application. A search of twenty wireless sensor network applications revealed a large number of them using a neighborhood concept.
Future work in this area focuses on creating neighborhoods with multi-hop rather than one-hop distances. This would create a more robust neighborhood.
Best regards,
Hall T.
The user defines the attributes to be shared and the membership criteria. The Hood software takes over and keeps track of related nodes and their attribute values. This alleviates the user from having to program the search for attribute values and related nodes.
Hood uses a broadcast/filter mechanism for data sharing and neighbor discovery. Receiving nodes filter through the broadcast data to see which neighbors and which of their attributes should be cached. The receiving node or “observing” node determines who is in its neighborhood, rather than the broadcasting or “owner” node. When a node updates its attribute values, this is pushed to the neighbor nodes which can choose to update their data cache or delete it. This provides a “reflective” memory of those nodes’ attribute values. Hood is implemented in nesC on the TinyOS platform.
Efficiency of the network can be tuned based on the “push policy” in so far as how much data and how often it is pushed from one node to its neighbors. For some applications, a low push may be the best in order to conserve memory and battery power. In other applications, a large push more often may be required to provide accurate and up to date information on the network.
Hood faces some challenges. Each “neighborhood” must keep its own data set which can cause problems when neighborhoods overlap. Through the use of parameters, one can distinguish one neighborhood from another. Another challenge is that within a neighborhood, all neighbor values must be kept in memory. This can create an inefficient use of memory and ultimately require large memory capacities. Also, Hood hides the cost of messaging from the user. A user could potentially make requests of the system that weigh it down in terms of memory usage or communications bandwidth and not be aware of the cost of their request.
Hood is ideally suited for object tracking in which locationing, routing, and tracking must be coordinated within groups of nodes (read “neighborhoods”). It may be useful to other wireless sensor network applications in which “neighborhoods” provide a foundation for the application. A search of twenty wireless sensor network applications revealed a large number of them using a neighborhood concept.
Future work in this area focuses on creating neighborhoods with multi-hop rather than one-hop distances. This would create a more robust neighborhood.
Best regards,
Hall T.
1 Comments:
uggs outlet
ugg boots
chanel handbags outlet
uggs outlet
fitflops outlet sale
north face outlet
nike free 5
mac cosmetics
hollister canada
wedding dresses uk
north face jackets
ferragamo outlet
christian louboutin shoes
coach outlet
wellensteyn outlet
tods outlet
nike air huarache
swarovski outlet
true religion jeans
ray-ban sunglasses
1211minko
Post a Comment
<< Home