1 / 25

TinyOS

TinyOS. By Morgan Leider CS 411 with Mike Rowe. Background. Created at UCBerkeley Used by over 500 groups tinyos.net Uses Habitat Monitoring Shooter Localization Pursuer-Evader. Design Features. Cross-layer control Static Resource allocation Snooping & scheduled communication.

gay-everett
Download Presentation

TinyOS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TinyOS By Morgan Leider CS 411 with Mike Rowe

  2. Background • Created at UCBerkeley • Used by over 500 groups • tinyos.net • Uses • Habitat Monitoring • Shooter Localization • Pursuer-Evader

  3. Design Features • Cross-layer control • Static Resource allocation • Snooping & scheduled communication

  4. Design Requirements • Work with current and future designs • Allow diverse implementation of operating system services and applications • Support varying hardware • Address the unusual challenges of sensor networks

  5. Hardware • Motes-small resource constrained computing nodes • Mica motes • Radio capable of 40Kbps • 4Mhz processor • 1-4k of ram • Up to 128K of storage • 32Khz external clock

  6. General code info • TinyOS requires 400 bytes for core OS • Supports • Event-driven execution • Flexible concurrency model • Tasks • Events • Component oriented application design • Apps use only the components they need

  7. Language • Written in nesC • An extension of C • Stripped down • No function pointers • Static • No dynamic memory allocation • Call-graph fully known at run time

  8. Writing in nesC • Everything is a component • Module – application code, implements interfaces • Configurations – connect interfaces • All components use modular interfaces • Group commands and events together • Bi-directional interfaces to support hardware interrupts

  9. Writing in nesC • Discourage sharing of data • Asynchronous operation with interrupts • Synchronous operation with tasks • Make event code atomic • Optimizes • Inlines small functions • Eleminates unreachable code • Reduces cpu usage by 30% and code size by 10%

  10. TinyOS features • Multi-hop communication • Tree-based collection • Intra-network routing • Dissemination • Broadcast – everyone transmits once • Epidemic – send when needed, snoop

  11. TinyOS Features • Scheduling • Timed listening and communication • Reduces collisions • Extends Life • Synchronization • Time-stamped messages • External Clock • Accurate to within +/- 1 ms

  12. Flexible Power Scheduling • Idle listening costs tons of power • Provides communication schedules for local nodes • Tree based topology • Adaptive slotted communication schedule used to route packets • Allows for global routing schedules • Base/root nodes have higher duty cycles

  13. Node States + Reservations • Sending • Receiving • Advertisement – receive from parent node with available reservation slot • Transmit pending – send reservation request • Receive pending – receive a reservation request from child • Idle

  14. Effects of Power Scheduling • High efficiency AA battery gives about 221 hours or 9 days of operation without power management. • 1274 hours or 53 days of operation with power scheduling • Can be increased even more

  15. Trickle – A TinyOS component • “A self-regulating algorithm for code propagation and maintenance in wireless sensor networks” • Designed with 3 principles • Low maintenance – scalable and infrequent data exchanges • Rapid propagation – must be able to update every node in a network within 2 mins • Scalability – handle few to hundreds of neighbors, don’t rely on mapped info because wireless networks change

  16. Trickle’s (Polite Gossip) • Periodically broadcast code summaries to local neighbors • Stay quiet if another neighbor has broadcast identical code summary • Older summaries result in broadcast of an update • Newer summaries result in request for update • Few seconds of operation an hour • Prevents network flooding

  17. Trickle’s Code • Requires only 11 bytes of state on node • Broadcasts and listens every interval I for time T • Transmission time is T/2 • Max of 2 transmissions every interval i • Transmissions suppress other broadcasts • Each node has a 1/(num of local node/ max 75) chance of broadcasting

  18. Trickle’s Code • If over 75 neighbors, collisions begin to happen • 512/75 or 1024/75 chance of broadcasting • Does not have overhead of discovering and maintaining local groups

  19. Trickle’s Benefits • Traditionally – have to rebroadcast all code to entire network if a node disconnects for a while • Trickle – local distribution where needed • Tremendous power savings • 1 bit broadcasted costs 1000 cpu cycles of power • 64k file costs days worth of operation time

  20. TinyDB – A TinyOS component • Problems with databases in wireless networks • Frequency of queries • Relevance of a node’s data • Order of query samples • Is a sample worth processing?

  21. TinyDB features • Query optimization • Do work on motes to reduce broadcast size • Eliminate recursive queries • Identification of similar or unchanged info • Ability to specify sampling rate and minimum sampling rate • Dynamic adjustment of sampling rate based upon power and minimum specified lifetime

  22. Deluge – A variant of Trickle • Trickle is designed for single packet dissemination • Deluge designed to handle large data objects

  23. Deluge Features • Message suppression • Robust asymmetric link creation • Get rid of bad and find new neighbors • Dynamic advertisement rate adjustment • Minimize collisions in node cells • Spatial multiplexing allows parallel transfers of data

  24. How Deluge works • Divides data objects into fixed-size pages • Broadcasts all pages, in order • Must receive 1 page before can start the next • 16 bit cyclic redundancy checks • Updates OS by page • Capable of catching up nodes with only local communication

  25. Conclusions • TinyOS is a highly customizable and adaptable operating system. • Used by hundreds of reported groups. • Open source. • Dozens of modules available for download for free at tinyos.net Any Questions?

More Related