DAIS: Enabling Declarative Applications

in Immersive Sensor Networks

Presented by Sanem Kabadayı

Mobile and Pervasive Computing GroupApril 27, 2006

2

Overview Motivation and Challenges What is DAIS? The DAIS Middleware Model

Novel Contributions: Scenes and Virtual Sensors The DAIS Implementation Evaluation Related Work Conclusion

3

Motivation Sensor networks

Integral component of pervasive computing environments, rapidly becoming ubiquitous.

Numerous miniature, battery-powered devices that gather and share information about the instrumented environment.

Many potential applications Aware homes, intelligent construction sites, first-responder

deployments, battlefield scenarios One significant barrier to the widespread development of

ubiquitous computing applications Increased complexity of the programming task

4

Application Examples

First-responder deployment

Aware home

Intelligent construction site

[http://www.icta.ufl.edu/projects/publications/ubicog02.pdf]

[http://www.nist.gov/public_affairs/factsheet/improving_first_repsonder_communication.htm]

5

Challenges Immersive sensor networks

Users move through an instrumented environment and desire on-demand access to locally gathered information.

Ubiquitous computing, not remote distributed sensing Locality of interactions Mobility-induced dynamics Unpredictability of coordination Complexity of programming

6

What is DAIS? A hierarchical middleware platform providing programming

abstractions tailored to ubiquitous applications. An application running on the user's device connects

seamlessly to the sensors in the local region. Removes the requirement that physically distant sensors

participate in the query's resolution. Does not run strictly on the sensors. Allows developers to create applications that run on client

devices (laptops or PDAs) that interact directly with the sensor networks.

Through the virtual sensor and scene abstractions, developers can declaratively specify the interactions.

7

The DAIS Middleware Model

Focus on scenes and virtual sensors: Scene: Enables automatic abstraction of

heterogeneous data VS: Allows an application's operating

environment to include a dynamic set of application-appropriate sensors.

Consists of a handheld component and the immersive sensor environment

The hierarchical model enables more powerful (client) devices to support more of the middleware's functionality than resource-constrained devices (physical sensors).

8

Scenes and Virtual Sensors A client application runs with the support of two key

abstractions: Scenes: rely on an application's declarative specification of data

requirements and create a dynamic data structure representing these needs.

Virtual Sensors: allow an application developer to create sensors that do not exist in the physical world by abstracting and aggregating information available from actual physical sensors.

9

Virtual Sensor Model Provide measurements of abstract conditions by

combining data from heterogeneous physical sensors. Safe load indicator on a crane

Uses physical sensors that monitor boom angle, load, telescoping length, wind speed, etc.

The programmer only needs to specify the following four parameters to create the virtual sensor: Input data types Operator (or Aggregator) Resulting data type Aggregation frequency

An application delegates sensor discovery to the virtual sensor.

10

Benefits of the Virtual Sensor Model Reusability

The future will see multipurpose networks deployed to support numerous applications.

Cost of physically visiting each sensor to program is prohibitive; ability to remotely program sensor networks to tailor them to particular applications will be essential.

Heterogeneity The power of virtual sensors lies in the fact that the physical

sensors used may be heterogeneous. Masking explicit data sources (sensors)

A virtual position sensor that uses GPS when available on the local device, but can switch to providing a position estimate based on the relative

positions of other nearby (physical) location sensors if GPS is unavailable (for example, inside a building).

11

Virtual Sensor Model Departure from traditional approaches A novel and powerful programming abstraction

Allows the programmer to simply specify heterogeneous aggregation and subsequently delegate that aggregation to the network

Puts this aggregation task firmly in the expert's hands, but leaves the complex communication programming to the middleware

An application's high-level specification of a virtual sensor (Java) is translated into low-level code (nesC).

This code can either run locally or be deployed to a sensor.

12

Virtual Sensor Example CraneDangerCircle

Represents the area near a crane where it is unsafe to walk Centered at the base of the crane (which may move) Has a radius defined by the position of the boom (which is even

more likely to move). Expands and contracts accordingly, as the boom moves along

the crane arm.

Domain programmer specifies the mechanics behind the aggregator.

13

Scenes: Abstractions of Local Data In an instrumented sensor network, a user's operational

context is highly dynamic. If the sensor network is well-connected, the user will be

able to reach vast amounts of raw information. The application must be able to limit the scope of

interactions to include only the data that matches needs. Scene: A novel communication abstraction that

encapsulates an application's operating environment. The programmer only needs to specify three parameters

for the scene: Metric Aggregator Threshold

0

i

kck > THRESHOLDFor all j < k,

cj <= THRESHOLD

ci = AGGREGATOR(METRIC(pi, i))

14

Scenes: API Simple API that includes

built-in general-purpose metrics (e.g., hop count, distance, etc.) straightforward mechanism for developers to insert additional

metrics From the application's perspective:

Scene is a dynamic data structure Contains a set of qualified sensors constrained as specified by a

list of Constraints Accessed through a SceneView

Each constraint is a triple ⟨Metric m, Aggregator a, Threshold t⟩

Node's value for the metric must satisfy constraints.

15

Scenes: Example Scene Definitions

SCENE_HOP_COUNT has the effect of assigning a value of one to each network link.

Using the built-in SCENE_SUM aggregator, the application can build a hop-count scene that sums the number of hops a message takes and only includes in the scene nodes that are within the maximum

number of hops as specified by the threshold. A scene that includes every sensor within three hops of

the declaring device:

Hop Count Scene Battery Power Scene Distance SceneMetric SCENE_HOP_COUNT SCENE_BATTERY_POWER SCENE_DISTANCEAggregator SCENE_SUM SCENE_MIN SCENE_DFORMULAMetric Value Number of hops traversed Minimum battery power Location of source

16

The Dynamic Scene As the user moves:

The scene declaration stays the same The set of devices that participate in the scene may change

17

Scene Functionality on Sensors Constraints imposed by TinyOS: small message sizes

(29 bytes) The message carries all the information that defines how

the protocol functions.

For example, SCENE_DISTANCE

For example, SCENE_MIN

Allows the scene building process to propagate state

Allows this node to know its parent in the routing tree

18

NesC Conventions An application consists of modules wired together via

shared interfaces to form configurations. Components represented by rounded rectangles and

interfaces by arrows connecting components. A component provides an interface if the corresponding

arrow points towards it. A component uses an interface if the corresponding

arrow points away from it. If a component provides an interface, it must implement

all the commands in the interface. If a component uses an interface, it can call any

commands in the interface and must handle all events generated by the interface.

19

SceneM Module Adaptive, lightweight communication protocol that is

responsive to a variety of applications When the SceneM module receives a message:

Check seqNo to determine if this is a duplicate. If message not processed before, compare calculated the metric

value against the threshold. If within scene, forward

message and pass application's message onto the query processor.

For persistent queries, Beacon and Monitor activated to monitor scene membership

20

Simulation Setup 100 sensor nodes in a 200ft x 200ft square, client device

moving among them Two types of topologies:

Regular grid with 20ft internode spacing Uniform random placement

TOSSIM empirical radio model (probabilistic model based on real Mica measurements in outdoor environment)

Client device speed: 0 mph, 2mph, 4mph (brisk walk), or 8 mph

For simplicity, number of hops: 1, 2, or 3 hops Implementation easily supports other types of scenes Beacon interval set inversely proportional to speed For mica2 (unoptimized) implementation occupies 12,980

bytes in ROM and 2,322 bytes in RAM

21

Example Scene Fixed radius (10 ft)

radio model, grid topology, and static client node for ease of presentation (threshold = 3 hops)

The red LEDs turn on for members of the scene.

Node 0 (with the green LED on) is the client node.

Blue circles represent beacon and scene message broadcasts.

22

Performance Metrics Average number of scene members

Beacon interval is set proportional to client device speed.

Measures how selected beacon intervals perform (number of scene members found should stay the same as speed increases)

Number of messages sent normalized by the number of scene members Measure of the sensor node's cost of participation

in the scene Can provide an idea of the battery dissipation for

the sensors that participate in the scene Number of messages sent per unit time

Measure of average activity in the network On-demand communication protocol Activity in the network takes place only within the

scene

Measure the scalability of the scene abstraction (how the protocol will function in scenes of increasing sizes and increasing client mobility)

23

Number of Scene Members We set beacon interval directly proportional to client speed to

make the lines flat, so flat lines are good For a given scene size and given topology, the number of

scene members is almost independent of the speed of the client node.

24

Messages per Second of Scene Registration Since beacon frequency is directly proportional to the

speed of the client node, beacons are sent more frequently as speed increases.

This causes more messages to be packed into a time interval.

25

Messages Sent per Scene Member Beacons sent out more frequently as the speed increases. As scene size increases, more nodes become members,

increasing the number of nodes sending beacons.

26

DAIS Query Processing Use of strategy pattern: algorithms can be chosen at

runtime depending on system conditions The Query is decoupled from the code that runs it, so we

can vary the Query dissemination algorithm without modifying the Query class.

Other communication can be swapped in for the BasicScene (for example, one built around query dissemination mechanisms such as TinyDB or directed diffusion)

27

Programming Interface The application interacts with the scene through the

SceneView interface. The types of queries enabled on a scene can be classified

as: One-time queries: return a single result from each scene member Persistent queries: return periodic results from scene members

To support these types, we provide different methods for posing queries to the network: sendQuery registerQuery sendAggQuery registerAggQuery

28

Query Methods sendQuery: one location reading

for each crane in the construction site.

registerQuery: crane location readings every second.

sendAggQuery: average temperature from concrete sensors (as a measure of the cure rate) in the scene.

registerAggQuery: average temperature from concrete sensors in the scene every 5 min.

29

Query Model Query, QueryResult, ResultListener Declarative specification allows the programmer to

describe desired data, without specifying how it should be obtained.

Asynchronous and nonblocking implementation A ResultListener is registered to receive the results of each query. When the result is ready, the middleware calls the

resultReceived(QueryResult) method for the result listeners to forward the results back to the application.

Allows the user interacts directly with a changing set of local information sources and minimizes communication.

The aggregation functions operate over any sensor that is in the scene, including virtual sensors.

30

Step 1: Declare a Scene

Scene Specifications

31

Step 2: Issue a Query

Scene Specifications

32

Step 3: Local Data Proxy is Created

Local Data Proxies

Control passes from the application developer to the middleware

DAIS creates local proxy to handle return calls for this query

Local proxy facilitates the translation from low-level language to high-level language

33

Step 4: Construct & Distribute Protocol Query Local data proxy transforms the

application's request into a protocol data unit for the scene implementation in use.

The scene protocol message carries information about scene membership constraints and the data query at the same time.

DA

IS A

bstr

actio

n Pr

otoc

ols

34

Step 5: Process Scene Query at Sensor

Query Processor

If the communication protocol determines that the node is in the scene, it passes the message up to the QueryProcessor

If one-time query, connect to the on-board sensor through the ADC interface, (QueryTimer for persistent)

Message ignored if type not supported on this device; node is still included in scene

35

Step 6: Query Processor Replies

Scene Building

!!

If the query processor can connect to the correct sensor and the constraints on the data value are satisfied, the query processor replies.

Every 10 seconds, if sensor attached to crane, has a weight sensor and value of that sensor is greater than 15 tons.

36

Step 7: Result Received by Client Device

Local Data Proxies

The result is demultiplexed by the Request Processor and handed off to the appropriate local data proxy.

Multiple queries may be active over a single scene at any given time (SceneView)

Control transfers back to the application and its ResultListener which handles the result.

Request Processor

37

Related Work Hood, Abstract Regions, Logical Neighborhoods

Do not directly consider the dynamics of mobility and require constant proactive behavior by all sensors that in the network.

Mobicast, MobiQuery Address the dynamics of mobility, but require nodes to have a fine-

grained knowledge of their physical locations. Relative location is important to DAIS

Envirotrack Also requires physical locations Performs the reverse of our desired interactions and focuses on

identifying and labeling tracked objects so that they can be addressed using a more traditional communication protocol.

TinyDB, Cougar Attempt to make the sensor network look like a database Enable applications with data requests that flow out from a central

point (BS) and create routing trees to funnel replies back to this root. TinyLIME

Provides only single-hop connections to sensors and assumes that the sensors do not communicate among themselves

38

Conclusions DAIS allows developers to create lightweight applications

that run on client devices and interact directly with an immersive sensor environment.

Through the virtual sensor and scene abstractions, application developers can declaratively specify the components over which the interactions occur. Scenes capture local interactions, reducing the communication

overhead. Virtual sensors abstract a set of (possibly heterogeneous)

physical sensors and the operations that are performed on them. Intuitive and easy-to-use wrappers for complex

underlying interactive behavior (can use other communication protocols.)

A first step in enabling novice programmers to create sophisticated pervasive computing applications.

39

References S. Kabadayi, A. Pridgen, and C. Julien, “Virtual Sensors: Abstracting Data

from Physical Sensors,” in Proceedings of the 4th International Workshop on Mobile Distributed Computing (MDC 2006), co-located with WoWMoM'06, Buffalo, NY (USA), June 2006 (to appear).

S. Kabadayi and C. Julien, “Enabling Local Communication for Immersive Mobile Computing,” Technical Report TR-UTEDGE-2006-004, Center for Excellence in Distributed Global Environments, The University of Texas at Austin, 2006, submitted to MASS 2006.

S. Kabadayi and C. Julien, “DAIS: Enabling Declarative Applications in Immersive Sensor Networks,” Technical Report TR-UTEDGE-2006-000, Center for Excellence in Distributed Global Environments, The University of Texas at Austin, 2006, submitted to FSE 2006.

http://mpc.ece.utexas.edu/publications.html

40

Questions?

Thank you!

http://mpc.ece.utexas.edu