1 / 11

IEEE 802.15.4 Platforms, Progress, and TinyOS

IEEE 802.15.4 Platforms, Progress, and TinyOS. Joe Polastre <polastre@cs.berkeley.edu>. Designed for low power, low data, high density rate wireless networks Services may interface with either 802.2 or directly with the MAC protocol Finally… a standard for interoperable radio communication

ernst
Download Presentation

IEEE 802.15.4 Platforms, Progress, and 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. IEEE 802.15.4Platforms, Progress, and TinyOS Joe Polastre <polastre@cs.berkeley.edu>

  2. Designed for low power, low data, high density rate wireless networks Services may interface with either 802.2 or directly with the MAC protocol Finally… a standard for interoperable radio communication And 802.15.4 is here… … but 802.15.4 is not Zigbee Zigbee requires 15.4 as the link and physical protocols The great “TinyOS vs Zigbee” debate IEEE 802.15.4“Low Rate Wireless Personal Area Networks”IEEE Standard, 2003 Networking/Routing/Organization “Upper Layers” 802.2 802.1 802.15.4 MAC 802.15.4 PHY

  3. 2.4 GHz 250kbps / 2MChips O-QPSK DSSS 900 MHz 40kbps BPSK 802.15.4 Physical Layer • RSSI, LQI required for each packet • CRC calculation and Address decoding • Automatic Acknowledgements • Encryption and Authentication

  4. 802.15.4 Link Functionality CSMA / Clear Channel Assessment Beaconing / Coordinator Slotting Encryption / Authentication Full Functionality Devices vs Reduced Functionality Device Single hop organization and communication Integrated network/link protocol design 802.15.4 has lots of extra functionality that may never be used: Enable the development of a “lightweight 802.15.4 MAC” Use 15.4 hardware without using the 15.4 MAC protocol (eg: B-MAC, S-MAC, etc) 802.15.4 MAC

  5. Good Standardized link protocol Hardware support encryption/authentication CRC Higher data rate Packet link estimation (LQI and RSSI) Network link estimation speeds organization Low duty cycle operation built in to design Reduces idle listening cost …but comes at the cost of synchronization and state The bad (and ugly) Large protocol Instance specific code Couples single hop organization with communication Beaconing, PANs, etc Power hungry 20x power of mcu Hardware support vs flexibility Promiscuous mode Minimal Time Synchronization Support Implicit heirarchy of networks Typically more powerful nodes act as a bridge to more powerful networks, not other 802.15.4 nodes The good, the bad, and the ugly

  6. What do routing/organization/network protocols actually want? • What subset is actually necessary to support low power, low data rate, wireless sensor networks? • Factored link protocol using 802.15.4 hardware and primitives • Network protocol optimization • Minimal state, code, RAM • Just get what each node (or the network) needs • More on this tomorrow (B-MAC)

  7. MicaZ CC2420 AVR (8-bit, 4/128k) MMCX Maintains compatibility with previous mote generations/sensors Get 15.4 to people quickly to start work with it Telos CC2420 MSP430 (16-bit 2/60k) Internal & SMA New single board design with USB for ultra low power New architecture = new low power mechanisms Interoperability and Platforms

  8. What is difficult about interoperability? • Same radio doesn’t solve your problems • Different mcu = Different architecture • Word Alignment • Endian-ness • RAM size, Flash size, MIPS • Hardware interfaces • AVR-centric Hardware abstractions • Over the air data format vs Local data format • New area for TinyOS—Need marshalling/unmarshalling support • But don’t parse everything going out, just what needs to be parsed • LibC for TinyOS? • Marshalling, byte order, qsort, etc… • Information hiding – Eliminate instance specific code

  9. One implementation, many platforms Lower layers for communicating with the CC2420 part of each platform UCB wrote Telos drivers Xbow wrote MicaZ drivers Link layer adjusts for: Byte ordering Alignment Proven MicaZ/Telos interoperability Generic Generic Comm Comm AM AM Backoff Backoff Encoding Encoding Data Data Control Control CC2420RadioC CC2420RadioC ( ( Freq,Power,etc Freq,Power,etc ) ) CC2420Control CC2420Control CC2420RadioM CC2420RadioM Hardware Specific Hardware Specific Read/Write CC2420 Read/Write CC2420 Registers/Commands Registers/Commands HPLCC2420M HPLCC2420C RandomLFSR RandomLFSR High Speed Timer High Speed Timer Transfer to/from Transfer to/from TXFIFO/RXFIFO TXFIFO/RXFIFO SpiByte SpiByte Chipcon CC2420 InteroperabilityTinyOS Platform Independent Radio Stack MicaZ (AVR) Telos (TI MSP430)

  10. Everything you’re used to still works SerialForwarder with 802.15.4 Packets TinyOS Mesh Networking “MintRoute” “Surge” “make telos/micaz” TinyOS Tools ~60m

  11. Status and Questions • TinyOS 802.15.4 RFD implementation in progress • Call for help from the community! • What do network protocols need? • MicaZ and Telos available • Supported by next TinyOS release (1.1.7) • CC2420DBK initial support in CVS • Demos this evening • Platforms • Security (David Wagner)

More Related