Download
1 / 13
130 likes | 263 Views
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)
E N D
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) • Sentient Objects (CORTEX project) • Others … (?)
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
(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?
(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!
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
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 ?
Existing Architecture (3) • Sentient Objects (CORTEX) • Nice ideas involved • Can be used as a starting point
Towards a Solution… • Local data centric architecture • Protocols implemented as entities that produce/consume data • Each entity (wyber) has: • Input & outputs • Functionality • Capabilities
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
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
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)
