Schedule Project Next Week Final Report Out of town for RTAS PC - - PDF document

1

Schedule

Next Week

Out of town for RTAS PC and RTSS Monday: MobiQuery (Guoliang) Wednesday: Agilla (Liang)

ESSAT (Obi) December 12th (Monday)

No critique

Project presentation & demo

December 19th (Monday), 2:30 – 5, MobiLab

Project report and source code

Submit electronic copy December 21st, 11:59pm

Project

Final Report

Similar to a technical paper 10 pages, double column, 10 pts fonts Example & template:

http://www.rtas.org/submission.htm

Source code and documents

Documents: README, INSTALL, HOW-to-RUN Separate from final report Submit with final report

Online Course Evaluation

Now – December 12th Feedbacks are appreciated!

RAP: A Real Time Communication Architecture for Large-scale Wireless Sensor Networks

Lu, Blum, Abdelzaher, Stankovic, and He CSE 520: Real Time Systems Rohan Sen

Contributions of the Paper

A new real-time communication architecture for large-

scale sensor networks

High level query and event service Location-addressed communication models

A new scheduling policy

Velocity monotonic scheduling (VMS)

Target Scenario: Sensor Network

• Resource poor, unreliable devices
• Individual nodes dedicated to a single task

Therefore no CPU scheduling required

• Nodes form groups and work collaboratively

Need for coordination protocol

• Data from the sensor network needs to flow towards the base station

Different sets of deadlines for differing data types

• Main schedulable resource is the communication channel

Multihop communication channel scheduling algorithms must be aware

• f space as well as time

2

Real-time Communication in Sensor Networks

Standard setup of sensor field and static/mobile base

station

Queries can specify timing requirements Start time, duration, end-to-end deadlines Example virus_found in coordinates [x1, y1, x2, y2]

• Events sent every 1.5 seconds for 30 seconds
• Each reading should reach the base station in 5 seconds

Real-time Communication in Sensor Networks

Communication can be divided into two

categories

Local coordination (1 - few hops)

• Data aggregation
• Generation of a reliable result

Sensor-base communication (10s of hops)

• Report aggregated data

Focus of the paper is sensor-base station

communication

Characteristics of sensor-base communication

• Querying is based on location

No queries to a specific address(e.g., 1002) Queries to a region

• Actual IDs of nodes not important
• A sensor that receives the query can trigger local coordination

A leader can be elected to lead the effort and return aggregated results

• Replies can also be returned using location addressing
• Hot regions

Regions of high traffic Caused by numerous or correlated events Must build protocol that meets deadlines under these conditions

Design of RAP

Design Goals

Provide general service APIs suitable for Distributed micro-sensing Control Maximize #packets meeting deadlines By minimizing deadline miss ratio Provide a highly scalable approach Keep communication and processing overhead to a minimum

Design of RAP

RAP Communication Architecture

Not covered in this paper Designed to reduce end-to-end delay

Design of RAP

Query/Event Service APIs

Applications may submit queries / register for events via API Allows applications to specify timing constraints of queries API abstracts locations and status of individual nodes

• Actual sensing and communications deferred to lower layers

Query(attribute_list, area,

timing_constraints, querier_loc)

Register_event(event, area, query)

3

Design of RAP

Location-addressed Protocol

• Connectionless transport layer
• Similar to UDP except messages are addressed by location
• Three types of communication is supported
• Unicast - focus of paper
• Delivers message to the node that is closet to the destination location
• Can be used to send query results to base station
• Area multicast
• Delivers message every node in a specified area
• Can be used tp register for an event or send a query to an area
• Area anycast
• Delivers message to at least one node in the target area
• Node can initiate coordination operations / group formation

Design of RAP

Geographic Forwarding

• Assume that the routing layer is aware of physical geography
• Geographic Forwarding makes the following decisions

Greedy

• If the neighbor has shorted geographic distance to destination

among all neighbors

• It is closer to the destination than the forwarding node

GPSR Perimeter Mode Routing

• Routes around topology hole using right hand rule
• State on each node is limited to neighbor list

Highly scalable

Design of RAP

Geographic Forwarding

Works best in sensor nets that have High node densities

• Helps greedy algorithm
• Results in hop count reflecting distance that has been

traveled

Use location addressed communication

• Eliminates the need for a location directory (map node -->

location)

Scheduling for Real-time Systems

Quick Review

• Key component of real-time architecture is packet scheduling policy

Determines the order in which incoming packets are forwarded on

• utgoing links
• Current protocols use a first-come first-serve approach

FCFS is not suitable because

• Different end-to-end deadlines and distance constraints
• Packet scheduling should be

Deadline-aware

• Priority should relate to its deadline
• Deadline = Priority

Distance aware

• Priority should relate to its distance from the destination
• Distance = Priority

Scheduling for Real-time Systems

Example

Velocity-Monotonic Scheduling

Basics

Considers both distance and deadlines Assigns priority by the requested velocity of the packet Improves the number of packets that meet their deadline

because

It assigns the “right” priorities based on the urgency of the

current hop

Solves fairness problem because packets farther away will have

higher priorities

4

Velocity-Monotonic Scheduling

Static Velocity Monotonic

• Computes a fixed requested velocity at the sender
• This velocity does not change on intermediate nodes
• Velocity is set as follows

Where

• D is end-to-end deadline
• V is requested velocity
• X0, y0 is sender location
• Xd, yd is destination location

Velocity-Monotonic Scheduling

Dynamic Velocity Monotonic

• Dynamically computes velocity at each node

Velocity can change at intermediate nodes

• Based on actual progress of the packet
• Velocity is set as follows

Where

• D is end-to-end deadline
• V is requested velocity
• Xi, yi is the node at which the packet is currently

Slow progress = Velocity Fast progress = Velocity

Priority Queue

• Multiple approaches to priority queue implementation
• Insert all packets in a single queue
• When queue is full, higher priority packets overwrite lower priority ones
• Benefit - Accurately reflects order of requested velocities and

allows sharing of same buffer regardless of priority

• Problem - Requires data structure whose insertion complexity is

logarithmic in number of packets

• Use multiple FIFO queues, one for each priority level
• Each priority corresponds to a range of requested velocities
• Map packet to priority and insert in relevant queue
• Approach is logarithmic in number of priorities
• #priorities << #packets
• Further reduce overhead by not reevaluating velocity until reception at

the next node

• Actively drop packets that have missed their deadlines

MAC Layer Prioritization

Basics

Local prioritization is not sufficient Packets from differing senders can compete for a shared radio

channel

Solution:

• Enforce packet priorities in the MAC protocol by providing

distributed prioritization on packets from different nodes

Implementation based on 802.11 Modified

• Initial wait time after channel becomes idle
• Back-off window increase function

Chosen for minimal overhead and portability to lightweight

CSMA/CA protocols

MAC Layer Prioritization

Initial Wait Time After Idle

802.11 sets a DIFS counter when channel becomes idle

A node will wait between a random amount between 0 and

DIFS before sending RTS

To prioritize this, modify DIFS parameter to

• DIFS = BASE_DIFS * PRIORITY

Higher priority packets choose smaller waiting period

• priority = value of PRIORITY

MAC Layer Prioritization

Backoff Increase Function

802.11 doubles its backoff window (CW) to extend a

node’s waiting period after collision

To prioritize this, modify CW to increase in accordance with

packet priority

• CW = CW * (2 + (PRIORITY - 1)/MAX_PRIORITY)

MAX_PRIORITY is highest priority (lowest value) Higher priority packets have their CW increase slower than lower

priority packets

Gives higher priority packets higher probability to get the channel

in both contention avoidance and contention phases

5

Experiments

Network Configuration

Motes arranged in a 136m x 136m area

Subdivided into 13.6m x 13.6m grids One node placed randomly in each grid

Radio range - 30.5m Packet size - 32B - 160B Bandwidth - 200kbps

Experiments

Application Workload

Two different queries - count and detail

Experiments

Application Workload

• Anticipate
• Large number of count queries
• Fewer detail queries
• Deadlines
• Count packets have longer deadlines (32B)
• Detail packets have shorter deadlines (160B)
• Simulate scenario of corelated events
• Creates two hot regions of 54.4m2
• Southwest corner
• Central
• 31 nodes send CBR count flows
• 15 of these nodes send detail flows

Experiments

Protocol Implementation

• Two routing protocols are used

Dynamic source routing (DSR) Geographic forwarding (GF)

• Compare with two baseline scheduling policy

FCFS DS

• Assigns fixed priority to packets based on end-to-end

deadlines

Experiments

Protocol Implementation

• Dropping packets that have missed deadlines
• DS, SVM, DVM do
• DSR, GF do not
• Only greedy forwarding is implemented for GF
• No perimeter mode
• Queues can hold up to

300 packets

• DS, SVM, DVM have

3 priorities

Experiments

Packet Scheduling

Overall deadline miss ratio for deadlines of 5, 10 s shown DSR/FCFS is not shown since it is significantly higher Priority based scheduling consistently beats FCFS

6

Experiments

Packet Scheduling

Overall deadline miss ratio for deadlines of 5, 25 s shown Priority based scheduling still beats FCFS

SVM begins beating DVM

Experiments

Packet Scheduling

Overall deadline miss ratio for deadlines of 5, 50 s shown DS and SVM have almost identical performance

Experiments

Distance Fairness

• SVM achieves better fairness to

flows from sensors further from base station

• Crucial to sensor networks since it

affects how sensor networks can scale

• Plotted miss ratio as function of

distance from base station

• SVM reduces miss ratio by 30%
• Miss ratio for far-away flows only

17.9% (vs. 46% and 90%)

• Thus SVM has better scalability

Conclusion (not the last slide)

RAP integrates various pieces to deliver real-time

communication in sensor networks

High level query and event service Increases number of packets meeting deadlines Scales well in large sensor networks Novel scheduling policies (VMS)

Critique

Only a very limited class of communication is targeted Is the assumption of single application / sensor valid

now?

GPSR Protocol implementation can be heavyweight for

full feature set?

Scalability question - Fixed number of queues and

assumption of very small number of discrete priorities

Thank You

Questions Comments