1 / 13

Sensor Node Architecture Issues

Sensor Node Architecture Issues. Stefan Dulman Email: dulman@cs.utwente.nl. Introduction. Current sensor node architecture Layered protocol stack (OSI Model) Each node is once programmed with a fixed number of protocols Alternatives: Active Messages (TinyOS – Berkley Motes)

conan
Download Presentation

Sensor Node Architecture Issues

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. Sensor Node Architecture Issues Stefan Dulman Email: dulman@cs.utwente.nl

  2. Introduction • Current sensor node architecture • Layered protocol stack (OSI Model) • Each node is once programmed with a fixed number of protocols • Alternatives: • Active Messages (TinyOS – Berkley Motes) • Sentient Objects (CORTEX project) • Others … (?)

  3. Open Questions • Problems to be solved locally: • Where to fit localization, timing & synchronization… • They can move in the protocol stack as they pass through different phases • Several blocks might need their data • Which block is responsible for turning them off • Managing the existing protocol blocks • Having several versions of algorithms inside a sensor node that get activated while data becomes available • Updating/replacing/switching the existing modules • A task scheduler fitted for these operations

  4. (More) Open Questions • The new architecture should enable efficient: • Error control • Traditionally performed at all layers • Each layer is optimized for the worst case • Higher layers usually support a certain degree of failure of the underlying layers • Energy control • Traditionally performed at physical layer only – each block inside the sensor node is concerned with it • Switch among different versions of protocols as a function of the available energy (or even shut down a few) • Other?

  5. (Even More) Open Questions • The nodes are not single & independent! • Problems addressed: • Nodes need to exchange data • Remote procedure calls for expensive operations • New features: • Heterogeneous network from protocol point of view • Groups of nodes (clustering!) share groups of protocols (memory saving, energy efficiency) • I will route my packets with my neighbor’s routing protocol using his timing information!

  6. Alternatives for blocks Protocol stack layers Existing Architectures • Current EYES architecture • Does not answer almost ANY of the previous issues • Far too complicated and impossible to fit inside a sensor node

  7. sensing application application Routing Layer routing Messaging Layer messaging UART Packet Radio Packet packet Radio byte UART byte Temp byte photo SW HW RFM i2c ADC bit clocks Existing Architectures (2) • Active Messages • Initially designed to answer data centric routing issues • Can be extended to cover some more issues • Relationship with the OS • Communication inside a sensor node ?

  8. Existing Architecture (3) • Sentient Objects (CORTEX) • Nice ideas involved • Can be used as a starting point

  9. Towards a Solution… • Local data centric architecture • Protocols implemented as entities that produce/consume data • Each entity (wyber) has: • Input & outputs • Functionality • Capabilities

  10. Towards a Solution (2) • Data centric scheduler: • Unifies the OS scheduling and the entities management • Can be built on top of the existing Eyes OS

  11. Towards a Solution (3) • Data centric schedulers have to connect to each-other to form a network backbone • Entities publishing/subscribing to data will be able to use data from entities inside other nodes

  12. Issues to be solved • Open issues: • Choosing entities function of the capabilities • Compatibility issues among entities • Minimum number of layers for the backbone formation • Service discovery • Naming schemes • (Directed Diffusion naming system)

  13. Questions & suggestions (please!!!)

More Related