Schedule Project � Next Week � Final Report � Out of town for RTAS PC and RTSS � Similar to a technical paper � Monday: MobiQuery (Guoliang) � 10 pages, double column, 10 pts fonts � Wednesday: Agilla (Liang) � Example & template: � ESSAT (Obi) � December 12 th (Monday) http://www.rtas.org/submission.htm � No critique � Source code and documents � Project presentation & demo � December 19 th (Monday), 2:30 – 5, MobiLab � Documents: README, INSTALL, HOW-to-RUN � Project report and source code � Separate from final report � Submit electronic copy � Submit with final report � December 21 st , 11:59pm Online Course Evaluation RAP: A Real Time Communication Architecture for Large-scale Wireless � Now – December 12 th Sensor Networks � Feedbacks are appreciated! Lu, Blum, Abdelzaher, Stankovic, and He CSE 520: Real Time Systems Rohan Sen Contributions of the Paper Target Scenario: Sensor Network � A new real-time communication architecture for large- � Resource poor, unreliable devices scale sensor networks Individual nodes dedicated to a single task � � High level query and event service � Therefore no CPU scheduling required � Location-addressed communication models Nodes form groups and work collaboratively � � Need for coordination protocol � A new scheduling policy � Velocity monotonic scheduling (VMS) 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 of space as well as time 1
Real-time Communication in Real-time Communication in Sensor Networks Sensor Networks � Standard setup of sensor field and static/mobile base � Communication can be divided into two station categories � Local coordination (1 - few hops) � Queries can specify timing requirements • Data aggregation � Start time, duration, end-to-end deadlines • Generation of a reliable result � Sensor-base communication (10s of hops) � Example • Report aggregated data � virus_found in coordinates [x1, y1, x2, y2] • Events sent every 1.5 seconds for 30 seconds � Focus of the paper is sensor-base station • Each reading should reach the base station in 5 seconds communication Characteristics of sensor-base Design of RAP communication Design Goals Querying is based on location � � Provide general service APIs suitable for � No queries to a specific address(e.g., 1002) � Distributed micro-sensing � Queries to a region � Control • Actual IDs of nodes not important � A sensor that receives the query can trigger local coordination � Maximize #packets meeting deadlines � A leader can be elected to lead the effort and return aggregated results � By minimizing deadline miss ratio � Replies can also be returned using location addressing � Provide a highly scalable approach � Hot regions � Regions of high traffic � Keep communication and processing overhead to a minimum � Caused by numerous or correlated events � Must build protocol that meets deadlines under these conditions Design of RAP Design of RAP RAP Communication Architecture Query/Event Service APIs � Applications may submit queries / register for events via API � Allows applications to specify timing constraints of queries Not covered in this paper � API abstracts locations and status of individual nodes • Actual sensing and communications deferred to lower layers � Query(attribute_list, area, � Register_event(event, area, query) timing_constraints, querier_loc) Designed to reduce end-to-end delay 2
Design of RAP Design of RAP Location-addressed Protocol Geographic Forwarding Connectionless transport layer Assume that the routing layer is aware of physical geography � � Similar to UDP except messages are addressed by location � Geographic Forwarding makes the following decisions � � Three types of communication is supported � Greedy � Unicast - focus of paper • If the neighbor has shorted geographic distance to destination among all neighbors • Delivers message to the node that is closet to the destination location • It is closer to the destination than the forwarding node • Can be used to send query results to base station Area multicast � GPSR Perimeter Mode Routing � • Routes around topology hole using right hand rule • 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 � State on each node is limited to neighbor list � � Highly scalable • Delivers message to at least one node in the target area • Node can initiate coordination operations / group formation Design of RAP Scheduling for Real-time Systems Geographic Forwarding Quick Review Key component of real-time architecture is packet scheduling policy � Works best in sensor nets that have � � Determines the order in which incoming packets are forwarded on � High node densities outgoing links • Helps greedy algorithm • Results in hop count reflecting distance that has been Current protocols use a first-come first-serve approach � traveled � FCFS is not suitable because • Different end-to-end deadlines and distance constraints � Use location addressed communication • Eliminates the need for a location directory (map node --> � Packet scheduling should be location) � 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 Velocity-Monotonic Scheduling Example 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 3
Velocity-Monotonic Scheduling Velocity-Monotonic Scheduling Static Velocity Monotonic Dynamic Velocity Monotonic � Computes a fixed requested velocity at the sender � Dynamically computes velocity at each node This velocity does not change on intermediate nodes � Velocity can change at intermediate nodes � • Based on actual progress of the packet Velocity is set as follows � Velocity is set as follows � � Where • D is end-to-end deadline � Where • V is requested velocity • D is end-to-end deadline • X 0 , y 0 is sender location • V is requested velocity • X d , y d is destination location • X i , y i is the node at which the packet is currently � Slow progress = � Velocity � Fast progress = � Velocity MAC Layer Prioritization Priority Queue Basics Multiple approaches to priority queue implementation � Local prioritization is not sufficient � Insert all packets in a single queue � � Packets from differing senders can compete for a shared radio • When queue is full, higher priority packets overwrite lower priority ones channel • Benefit - Accurately reflects order of requested velocities and � Solution: allows sharing of same buffer regardless of priority • Enforce packet priorities in the MAC protocol by providing • Problem - Requires data structure whose insertion complexity is distributed prioritization on packets from different nodes logarithmic in number of packets Use multiple FIFO queues, one for each priority level � � Implementation based on 802.11 • Each priority corresponds to a range of requested velocities � Modified • Map packet to priority and insert in relevant queue • Initial wait time after channel becomes idle • Approach is logarithmic in number of priorities • Back-off window increase function • #priorities << #packets � Chosen for minimal overhead and portability to lightweight • Further reduce overhead by not reevaluating velocity until reception at the next node CSMA/CA protocols • Actively drop packets that have missed their deadlines MAC Layer Prioritization MAC Layer Prioritization Initial Wait Time After Idle Backoff Increase Function � 802.11 sets a DIFS counter when channel becomes idle � 802.11 doubles its backoff window (CW) to extend a node’s waiting period after collision � A node will wait between a random amount between 0 and DIFS before sending RTS � To prioritize this, modify CW to increase in accordance with packet priority • CW = CW * (2 + (PRIORITY - 1)/MAX_PRIORITY) � To prioritize this, modify DIFS parameter to • DIFS = BASE_DIFS * PRIORITY � MAX_PRIORITY is highest priority (lowest value) � Higher priority packets have their CW increase slower than lower � Higher priority packets choose smaller waiting period priority packets • � priority = � value of PRIORITY � Gives higher priority packets higher probability to get the channel in both contention avoidance and contention phases 4
Recommend
More recommend
