EnviroTrack: Middleware system designed for object tracking . An - - PDF document

envirotrack
SMART_READER_LITE
LIVE PREVIEW

EnviroTrack: Middleware system designed for object tracking . An - - PDF document

1.Overview 1)What is EnviroTrack: EnviroTrack: Middleware system designed for object tracking . An Innovative and Simple Mideleware 2)Features: System for Object-Tracking Export a novel logical address space in which external


slide-1
SLIDE 1

1

EnviroTrack:

An Innovative and Simple Mideleware System for Object-Tracking

Yuling Liang , Nov-17-2004

1.Overview

1)What is EnviroTrack:

Middleware system designed for object tracking.

2)Features:

Export a novel logical address space in which external environmental

  • bjects are the labeled entities.

Allow arbitrary data, computation, or actuation to be attached to such

logical network addresses.

Encapsulate lower level details (the dirty work) from users by

providing a high level abstraction and interfaces.

1.Overview (cont.)

3)Hardware and Software Environment Hardware: MICA motes. OS: TinyOS Language: NesC 4)Syllabus

entity context / context label

  • bject

2.Programming Model

1)Three key functions: a) sensee() b) statee() c) tracking objects

Interesting concept

2.Programming Model (cont.)

  • sensee()
  • use for sensing

and grouping

  • statee()
  • Aggregation function.
  • Freshness Le.
  • Critical mass Ne.

Pe =Le - d N>=Ne

  • 3. Language Sample

sensee

  • ne aggregate variable
slide-2
SLIDE 2

2

  • 4. Implementation

The EnviroTrack preprocessor The Group Management protocol Routing services

  • 4. Implementation (cont.)

The EnviroTrack preprocessor

handler array of contexts. goes through this array checking if any context satisfies the activation condition. group management activate

  • 4. Implementation (cont.)

The Group Management protocol

Leader Election

  • Randomly chooses a small timeout value.
  • The first time out node sends a message informing its

neighbors that it is leader. *Critique: A Conflicting Scenario

leader candidate leader candidate

  • 4. Implementation (cont.)

The Group Management

protocol

Entity Management Module 1) Create entities when an new

event occurs.

2) Maintain the single entity

and prevent spurious entities creation.

3) Ensure nodes know when to

join and when to create new entities.

  • 4. Implementation (cont.)

The Group Management protocol (cont.)

Heartbeats of Group Leader

  • inform current members that the leader is alive
  • application state for new possible leader (can be adopted by

A-Track)

  • indicate followers ( potential group members)
  • 4. Implementation (cont.)

Entity Management Module

slide-3
SLIDE 3

3

  • 4. Implementation (cont.)

Discovery

Scenario

leader awareness horizon independent node entity member entity follower

  • 4. Implementation (cont.)

Target Moving

Scenario

awareness horizon independent node entity member entity follower leader heartbeat

  • 4. Implementation (cont.)

Hand-Off

Scenario

awareness horizon awareness horizon independent node entity member entity follower leader heartbeat relinquish leadership new leader

  • 4. Implementation (cont.)

Hand-Off Failure Scenario

Solution: a. Increase the awareness horizon ( need more energy)

  • b. Track the bigger object
  • c. Use end-point filter

spurious entity

  • 4. Implementation (cont.)

Radio Irregularity Failure Scenario Solution:

Introduce new variables:

  • failed leader timer

(> heartbeat period

  • r depend on radio

signal strength )

  • alive counter
  • min time alive

spurious entity good point

  • 4. Implementation (cont.)

Routing services

Landmark routing

  • Nodes are assumed to know

their location

  • Forwarding messages

Landmark Leader members

slide-4
SLIDE 4

4

  • 5. Performance and Test Case

Real Test

Target: T-72 Tank Testing Area: 70 km x 5 km Number of Motes: 18,000 Sensor Type: Magnetometer Speed: 11.2 seconds / hop

  • 5. Performance and Test Case

Simulation Test

Target: Testing Area: Rectangular Number of Motes: Unknown Sensor Type: light sensor Speed: 10 seconds/hop and 15 seconds/ hop

  • 5. Performance and Test Case

(cont.)

Reasons for Error:

no notion of proximity to the target

  • nly using a subset of reporting sensors due to radio

loss

  • 5. Performance and Test Case

(cont.)

  • 5. Performance and Test Case

(cont.)

HB loss: heartbeats lost Msg loss: sensor messages lost during data

aggregation

Link Util: average useful link utilization

  • 5. Performance and Test Case

(cont.)

Conclusions of Table 1:

The system operates correctly in the presence of message

loss.

Message loss is not caused by link utilization but rather by

the unreliability of the wireless medium

Communication requirements constitute only a tiny fraction

  • f available link capacity.

Link utilization increases only slightly with tank speed

meaning potential to scale well with tracking difficulty.

slide-5
SLIDE 5

5

  • 5. Performance and Test Case

(cont.)

Conclusions on Trackable Speed

  • The tracking speed is fast “enough“.
  • The bigger target is easier to track at

fast speed

  • Shorter heartbeat period

can increase tracking speed

  • 5. Performance and Test Case

(cont.)

Conclusion on

CR (Communication Radius : SR (Sensing Radius) graph

Larger events are trackable

at faster speed.

Tracking architecture

breaks down when the CR:SR ratio falls below 1

  • 6. Critiques (cont.)
  • leader election basing on timeout is too simple, should address energy as a

factor

  • not addressing the power management problem.
  • Not adaptive to target speed
  • did not explain what is a “landmark”
  • the assumption of CR > SR cant always hold in many cases in real

environment

  • Based on assumption of group management on Target are located sparsely
  • node identifier/weight/priority is not clearly explained
  • Terms are sometimes confusing.
  • 7. Q & A

Any Questions?