Sample Project Ideas KD Kang

Project Idea 1: Real-time task scheduling in TinyOS EDF in TinyOS 2.x –Description is available at –Prototype implementation is available at –Is this a good implementation? Can we improve it? Can it deal with multiple resources? –Implement another real-time task scheduling algorithm in TinyOS –Implement an overload protection mechanism, for example, aggregate two sensor readings and set the new deadline = max(D1, D2)

Project Idea 2: Just-in-time packet scheduling ASAP forwarding can actually increase E2E delay and deadline miss ratio Exploit slack time to improve real-time performance –K. Liu, N. Abu-Ghazaleh, K. D. Kang, "JiTS: Just-in- Time Scheduling for Real-Time Sensor Data Dissemination", 4th Annual IEEE International Conference on Pervasive Computing and Communications (PerCom 2006), Pisa, Italy, Mar , 2006."JiTS: Just-in- Time Scheduling for Real-Time Sensor Data Dissemination" Extend JiTS

Project Idea 3: Resource Management for Multiple Queries Most WSN work assumes a single query What if multiple queries are executed simultaneously? Which queury should receive more resources? Why? Can similar queries can be combined? How?

Project Idea 4: Virtual Machine for WSNs Maté – Extend Mate to support –Real-time task/packet scheduling; –Multiple concurrent queries; or –Overload protection

Project Idea 5: Security Trust-based routing –Overhearding-based trust level computation –Does overhearing always work? There are collisions, overloads, interferences, etc. –“Practical” trust-based routing –More feedback or probing? Introduce new security holes? Terrible performance? Secure sensor network reprogramming –Prabal K. Dutta, Jonathan W. Hui, David C. Chu, and David E. Culler, “Securing the Deluge network programming”, 5th Internaltional Conference on Information Processing in Sensor Networks (IPSN'06), April 25-27, “Securing the Deluge network programming”, –Improve the security or performance of reprogramming Secure data aggregation –Y. Sang, H. Shen, Y. Inoguchi, Y. Tan, N. Xiong, “Secure Data Aggregation in Wireless Sensor Networks: A Survey”, Seventh International Conference on Parallel and Distributed Computing, Applications and Technologies (PDCAT'06)Secure Data Aggregation in Wireless Sensor Networks: A Survey –Extend to support multiple streams for concurrent queries

Project Idea 6: Sensor Network Applications For EngiNet students only Applications related to your work, e.g., medical, defense, structural monitoring, habitat monitoring, smart-* applications Not only wireless sensors, e.g., MICA motes, but any other sensors, e.g., medical sensors –Describe the functionalities of important sensors Specify application requirements What’s the expected advantage of networking these sensors together with computational systems such as medical databases? –Explain how sensor networks can improve your application Specify the system architecture and reason why this architecture is desirable for the specific application Specify the required network services such as routing, MAC, or security protocols Show how the existing sensor network protocols should be changed to support the specific application of yours –Propose a new protocol –The final outcome is a report Take advantage of your domain knowledge

The nesC Language: A Holistic Approach to Networked Embedded Systems D. Gay, P. Levis, R. Behren, M. Welsh, E. Brewer, D. Culler

What is nesC? Extension of C –C has direct HW control –Many programmers already know C –nesC provides safety check missing in C Whole program analsys at compile time –Detect race conditions -> Eliminate potential bugs –Agressive function inlining -> Optimization Static language –No dynamic memory allocation –No function pointers –Call graph and variable access are fully known at compile time Supports and refelcts TinyOS’s design –Based on the component concept –Directly supports envet-driven concurrency model –Addresses the issue of concurrent access to shared via atomic section and norace keyword

Key Properties All resources are known statically No general purpose OS, but applications are built from a set of reusable system components coupled with application- specific code HW/SW boundaries may vary depending on the application & HW platform -> Flexible decomposition is required

Challenges Event-driven –Driven by interaction with environments Limited resoruces Reliability Soft real-time requirements

Reminder: TinyOS Component-based architecture –An application wires reusable components together in a customized way Tasks and event-driven concurrency –Tasks & events run to completion, but an event can preempt the execution of a task or an event –Tasks can’t preemt another task or event Split-phase operations (for non-blocking operations) –A command will return immediately and an event signals the completion

Component A component provides and uses interfaces –The interfaces are the only point of access to the component An interface models some service, e.g., sending a msg The provider of a command implements the commands, while the user implements the events

Interface Bidirectional interfaces support split- phase execution

Component implementation Two types of components: modules & configurations Modules provide application code and implements one or more interfaces Configurations wire components together –Connect interfaces used by components to interfaces provided by others

Module Surge: Get a sensor reading and send a message every second

Configuration Wire TimerM and HWClock components together

Example: SurgeC configuration

Abstract component Sometimes useful to create several instances of a component optional parameter used to specify #max retransmissions

Parameterized interfaces Used to model Active Messages in TinyOS –In active messages, a packet contains a numeric identifier to specify which event handler should be executed

Concurrency and Atomicity Asynchronous code (AC): reachable from at least one interrupt handler Synchronous code (SC): only reachable from tasks –Synchronous code is atomic w.r.t. other synchronous code Still potential races between AC and SC –Any update to shared state from AC –Any update to shared state from SC that is also updated from AC Solution: Race-Free Invariant –Any update to a shared variable is by SC or occurs inside an atomic section

atomic & norace Atomic –Disable interrupts –Atomic statements are not allowed to call commands or signal events –If a variable x is accessed by AC, any access of x outside of an atomic section is a compile time error –An atomic section should be short! norace –If a programmer knows a potential race is not an actual race, declare norace Disable interrupts Enable interrupts

Evaluation Tested for three TinyOS applications –Surge, Mate, TinyDB Core TinyOS consists of 172 components –108 modules & 64 configurations Group necessary components, via nesC’s bidirectional interfaces, for a specific application

Effect of inlining Impact of inlining on footprint and performance

Remaining issues Static memory allocation –Advantages Offline analysis of memory requirements –No problem? No dynamic allocation Short code only in atomic sections & command/event handlers Little language support for real-time programming

Questions?