Sensors Everywhere 01 - Fundación Vodafone España

Transcripción

Proyecto1
7/9/10
10:17
Página 2
Sensors Everywhere 01
6/9/10
09:58
Página 1
Sensors Everywhere
Wireless Network Technologies and Solutions
Carles Gómez
Josep Paradells
José E. Caballero
6/9/10
09:58
Página 2
Edita: Fundación Vodafone España
Autores:
Carles Gómez Montenegro*
Universitat Politècnica de Catalunya
Assistant professor
Josep Paradells Aspas*
Universitat Politècnica de Catalunya
Professor
José Eugenio Caballero Herrero
Vodafone
R&D Project Manager
* Collaborate with Fundacio i2CAT in R&D projects
Realización: Punto Centro
I.S.B.N.: 978-84-934740-5-8
D.L.:
© 2010, Fundación Vodafone España
Queda prohibida cualquier reproducción total o parcial de este libro, almacenamiento en un sistema informático o transmisión en cualquier forma o por
cualquier medio (electrónico, fotocopia y otros métodos).
6/9/10
09:58
Página 3
Acknowledgements
Acknowledgements
The authors would like to acknowledge Technical University of Catalonia,
i2CAT Foundation, Vodafone Group Research and Development, Vodafone
España S.A. and Fundación Vodafone España for enabling us making this
book a reality.
Especial thanks to Mercedes Gómez (Fundación Vodafone España, Área
de Difusión), Rosa Rodríguez (Vodafone España, Departamento Legal),
Guillermo Cajigas (Vodafone Group Research and Development, Academia)
and Joan Manel Martín and Sergi Figuerola (Fundació i2CAT) for their support in managing the edition of this book.
Carles Gómez would like to thank his parents, and would also like to give
special thanks to his (location-agnostic) soul and life companion, Pili.
Josep Paradells wants to thank everybody that supported him and specially the one that wakes up with him every morning.
José E. Caballero would like to thank Maribel and Josu for their patience
and support.
Carles Gómez and Josep Paradells would like to thank the project
TEC2009-11453.
Authors would like to thank Dynastream Innovations Inc., Ambiosystems
LLC, Ambient Systems B.V., EasySen LLC, Perpetuum Ltd, Jennic Ltd,
ADTel S.L, Gas Natural SDG S.A and Powercast Corporation for giving permission to use the images of their products that have been included in this
book.
3
6/9/10
09:58
Página 4
6/9/10
09:58
Página 5
Presentación
La apuesta por la innovación tecnológica de Vodafone España es una de
nuestras señas de identidad. Y no, solamente, desde la propia actividad empresarial. La Fundación Vodafone España tiene como misión fundamental utilizar la telecomunicación como elemento facilitador de la vida independiente y la autonomía
personal de los mayores y de quienes presentan diversidad funcional, así como
desarrollar nuevas soluciones en accesibilidad, e-asistencia y e-salud. Es decir,
poner las tecnologías de la Información y la comunicación, las TIC, al servicio de
aquellas personas más vulnerables.
Consecuentes con nuestro propósito, la Fundación dedica todos sus
esfuerzos a innovar, investigar, formar y concienciar.
Innovar e investigar para hacer accesibles a los mayores y a las personas
con diversidad funcional, aquellos dispositivos y programas que, inicialmente, han
sido diseñados con un carácter general y estándar por lo que, a priori, pueden no
son accesibles a todos o no se diseñaron inicialmente para la función asistiva que
un buen proceso de innovación puede asignarle.
Motivar, formar y tutelar para el uso y en el uso, de las tecnologías de la
información y la comunicación a nuestros mayores y a las personas con diversidad
funcional para que nadie que quiera o necesite de los servicios que estas prestan,
quede inmerso en la fractura o brecha digital. Posibilitar de manera fehaciente la
accesibilidad a todos los que la desean o la necesiten, es una exigencia social que
se fundamenta en el principio de justicia universal para todos.
Finalmente, nuestra misión es también explicar a la sociedad y a sus dirigentes en todos los niveles, los avances que se producen y las posibilidades de
inclusión y mejora de la calidad de vida para todos estos colectivos vulnerables,
que estos adelantos suponen.
Y precisamente en este punto el libro que nos honramos en prologar
Vodafone España y Fundación Vodafone España cobra su pleno sentido.
Allí donde vamos, oímos hablar, desde hace más de un lustro, de entornos inteligentes, de inteligencia ambiental, hogar digital, vida asistida por el entorno…Todas estas nociones pueden resumirse, de una manera muy general, en la
capacidad de dotar a los entornos de la inteligencia que les permita reconocer y
responder ante la aparición de las necesidades de las personas para, de este modo,
5
6/9/10
09:58
Página 6
facilitarles las actividades de la vida diaria dentro y fuera del hogar. Y es en estos
desarrollos donde las redes de sensores se encargan de recoger la información que
posibilita el acceso y uso de dispositivos en el hogar, el trabajo o el ocio. Y es que
los sensores, aparentemente invisibles, juegan en el complejo proceso tecnológico
que subyace a la accesibilidad, un papel de primer orden.
Sensors Everywhere. Sensores por todas partes. Si, claro y al servicio de
todos. Y de ello habla este libro, que hoy ve la luz, que difunde y explica el trabajo
homónimo desarrollado por sus autores dentro de los proyectos de la Fundació
i2CAT, con la que nos honramos en colaborar desde la Fundación Vodafone y
desde Vodafone España, SAU.
El libro “Sensors Everywhere” que ahora nos ocupa ha sido esmeradamente elaborado por los autores, los profesores de la Universidad Politécnica de
Barcelona, Carles Gómez y Josep Paradells, conjuntamente con el ingeniero del
departamento de I+D de Vodafone España, José Eugenio Caballero, constituye por
un lado un buen ejemplo de colaboración entre la academia y la empresa, algo tan
necesario en nuestros días, y por el otro, el abordaje teórico-práctico de una cuestión de palpitante actualidad tecnológica.
Santiago Moreno
Jaime Bustillo
Director General
Director de Tecnología
Fundación Vodafone España
para España y Portugal
Vodafone España SAU
6
6/9/10
09:58
Página 7
Presentación
En el actual entorno de globalización, la generación de nuevo conocimiento y
su transformación en nuevos productos y servicios es uno de los retos más importantes para mejorar la productividad y la competitividad de nuestras empresas.
El éxito de cualquier sistema de innovación regional o nacional se sustenta en
la óptima interacción y colaboración entre los distintos agentes que lo conforman
(universidades, grupos de investigación, centros tecnológicos, administraciones
públicas, empresas y otras entidades de soporte). En este sentido, las universidades
y los centros de investigación, como principales agentes generadores de conocimiento fruto de sus actividades de I+D+i, desempeñan un papel importante en el
desarrollo económico de la sociedad del conocimiento.
Con la finalidad que este conocimiento acumulado a través de la actividad
investigadora pueda ser transferido a las empresas y genere nuevo valor en el mercado, existen distintos mecanismos de transferencia de conocimiento y de tecnología, que van desde la realización de proyectos conjuntos de I+D hasta la creación
de empresas spin-off, pasando por la difusión de conocimiento científico a través
de conferencias, seminarios o publicaciones científicas.
La Fundació Privada i2CAT, Internet i Innovació Digital a Catalunya (en adelante,
Fundació i2CAT) es una entidad sin ánimo de lucro que desde el año 2003 lleva
desarrollando múltiples proyectos de investigación e innovación tecnológica en el
ámbito de la Internet del Futuro y de las Tecnologías de la Información y la
Comunicación (TIC), fomentando la colaboración con el sector empresarial y facilitando la transferencia de conocimientos de los distintos grupos de investigación
universitarios que colaboran con los proyectos liderados por Fundació i2CAT.
Como centro tecnológico de I+D+i, Fundació i2CAT tiene entre sus principales
objetivos contribuir en la mejora de la competitividad de las empresas mediante el
perfeccionamiento tecnológico y la innovación.
La clave del modelo de la Fundació i2CAT radica en la colaboración entre la
Administración, el sector empresarial, el mundo académico y los usuarios, estableciendo un nuevo modelo de innovación aplicado en el terreno de las Tecnologías
de la Información y de la Comunicación.
En el marco de la investigación y la innovación TIC, Fundació i2CAT es un centro tecnológico de referencia en el ámbito de los servicios y de las aplicaciones de
7
6/9/10
09:58
Página 8
Internet avanzadas, liderando la introducción y la integración de la tecnologías de
la Internet del Futuro en los principales sectores económicos (Sanidad, Educación,
Cultura, Industria, etc) como medio para mejorar la productividad y la competitividad de la economía y el bienestar de las personas.
El presente libro, fruto de una colaboración de Fundació i2CAT con la
Universitat Politècnica de Catalunya (UPC), Vodafone España y Fundación
Vodafone España, es una muestra de la actividad de transferencia de conocimiento, con la cual se pretende compartir y divulgar el conocimiento en el campo de las
tecnologías de las redes de sensores sin hilos que Fundació i2CAT ha conseguido
durante la ejecución de múltiples proyectos de I+D+i, la mayoría de ellos en colaboración con distintas empresas y entidades.
En el marco de la investigación, el interés por las redes de sensores sin hilos
(Wireless Sensor Networks, WSN) se remonta a varias décadas atrás, pero es durante los próximos años cuando según la mayoría de analistas se augura el despegue
de esta tecnología, mediante su introducción en distintas aplicaciones en campos
como el de la teleasistencia médica, la gestión urbana, la eficiencia energética, la
gestión de recursos naturales o la predicción y prevención de desastres naturales.
Por este motivo, consideramos que la publicación del presente libro se produce en el momento oportuno, con el objetivo que la divulgación de las posibilidades
que ofrece la tecnología de las redes de sensores sin hilos y la demostración de su
estado de madurez ayude a las empresas a identificar nuevas oportunidades de
negocio que permitan generar nuevo valor en nuestra economía y mayor bienestar en el conjunto de la sociedad.
Fundació i2CAT quiere agradecer la dedicación del personal investigador que
ha permitido conseguir un profundo conocimiento sobre esta tecnología y reconocer el excelente trabajo realizado por los autores de esta publicación.
Sebastià Sallent
Director Fundació i2CAT
8
6/9/10
09:58
Página 9
Index
Index of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Index of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Summary in Spanish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1. Introducción a las WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Aplicaciones de las WSNs e iniciativas estandarización . . . . . . . . . . .
3. Capa física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Capa MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Plataformas de nodos sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6. Control de topología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7. Encaminamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8. Transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10. Sistemas operativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11. Arquitecturas y tecnologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12. Gestión de los datos obtenidos por la WSNs . . . . . . . . . . . . . . . . . . . .
13. Interoperabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14. Consumo y recolección de energía . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15. Localización en redes de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16. Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17. Direcciones futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
27
28
32
33
35
37
38
40
41
42
44
46
47
49
50
52
55
1. Introduction to Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . .
1.1. Elements of a WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. General characteristics of WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Sensor node architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
59
60
62
62
63
9
6/9/10
09:58
Página 10
Sensors Everywhere
1.4. WSN architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1. WSN topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2. The layered protocol stack approach . . . . . . . . . . . . . . . . . . . . . . .
1.4.3. WSN protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
64
66
67
67
2. Applications of WSNs and standardization initiatives . . . . . . . .
2.1. Applications of WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Environmental monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2. Healthcare, sports and fitness, assisted living . . . . . . . . . . . . . . .
2.1.3. Structural monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4. Automotive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.5. Logistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.6. Home and building automation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.7. Industrial monitoring and control . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.8. Smart utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.9. Urban monitoring and control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.10. Road usage charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.11. Disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.12. Rural monitoring and control . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.13. Telecommunications applications . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.14. Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.15. Robotics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.16. Contextual awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Standardization initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. IEEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3. ITU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4. ISO and IEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.5. ETSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.6. NIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.7. Other standardization efforts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
71
71
72
74
75
75
75
77
78
79
82
82
82
83
84
84
84
84
85
85
86
86
87
87
87
89
3. Physical layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.1. Radiofrequency signal propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
10
6/9/10
09:58
Página 11
Sensores en todas partes
3.1.1. Path loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2. Attenuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3. Reflection, diffraction and scattering . . . . . . . . . . . . . . . . . . . . . . .
3.1.4. Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Frequency bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3. Modulations and spreading techniques . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1. Classical modulation schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2. Spread spectrum techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3. Ultra wideband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4. Transmission range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5. Physical layers of IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1. IEEE 802.15.4-2003 PHYs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2. IEEE 802.15.4-2006 PHYs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.3. IEEE 802.15.4a PHYs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.4. IEEE 802.15.4c, IEEE 802.15.4d, IEEE 802.15.4f and IEEE
802.15.4g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6. Physical layer of Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . .
3.7. Coexistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1. Coexistence of IEEE 802.15.4-2006 with IEEE 802.11b/g . . .
3.7.2. Coexistence of IEEE 802.15.4-2006 with Bluetooth
and BT-LE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
99
99
101
101
101
103
103
105
106
107
108
108
112
115
4. MAC layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1. Scheduling-based MAC protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. TDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2. LEACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3. TRAMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Contention-based protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1. ALOHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2. Slotted ALOHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3. CSMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4. CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.5. Sift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.Duty-cycle-based protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
131
132
132
133
133
134
134
134
134
135
137
138
120
121
123
124
125
126
11
6/9/10
09:58
Página 12
Sensors Everywhere
4.3.1. S-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2. T-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3. DSMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4. DMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4. Other protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1. STEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2. WiseMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5. Comparison of MAC protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6. IEEE 802.15.4 MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1. Device types and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.2. Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.3. Superframe structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.4. IEEE 802.15.4 CSMA/CA mechanisms . . . . . . . . . . . . . . . . . . . . . .
4.6.5. Error control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.6. IFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.7. Data transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.8. Frame formats of IEEE 802.15.4 MAC . . . . . . . . . . . . . . . . . . . . . . .
4.6.9. Performance of an IEEE 802.15.4-2003 peer-to-peer link . .
4.6.10. IEEE 802.15.4e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7. Bluetooth Low Energy MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.1. State diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.2. Data transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.3. Frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.4. Acknowledgment and flow control . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
138
139
139
141
142
142
143
143
148
148
148
148
149
150
150
151
152
155
156
156
157
158
159
160
160
5. Sensor node platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1. Sensor node architecture elements . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1. Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2. Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3. Radio transceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.4. Antennas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.5. Sensor and actuator devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Sensor node router and gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3. Sensor node platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
165
165
166
170
171
172
177
180
180
183
12
6/9/10
09:58
Página 13
6. Topology control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1. Topology control techniques based on hierarchical networks . .
6.1.1. LEACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Topology control techniques based on dynamic transmission
range adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1. Location-based topology control protocols . . . . . . . . . . . . . . . .
6.2.2. Direction-based topology control protocols . . . . . . . . . . . . . . . .
6.2.3. Neighbour-based topology control protocols . . . . . . . . . . . . . . .
6.3. k-connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
187
188
189
7. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1. Routing protocols designed for WSNs . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1. Flat routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.2. Hierarchical routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.3. Geographic routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2. MANET routing protocols adapted for WSNs . . . . . . . . . . . . . . . . . . .
7.2.1. AODV-based routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.2. DYMO-based routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 ROLL routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1. IETF ROLL WG scope and routing requirements . . . . . . . . . . . .
7.3.2. RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.3. IETF 6LoWPAN WG routing requirements . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
197
198
198
202
204
206
207
210
211
211
212
214
214
8. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1. Use of traditional transport protocols in WSNs . . . . . . . . . . . . . . . . .
8.1.1. Drawbacks of using TCP in WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.2. Advantages and initiatives toward the use of TCP in WSNs .
8.1.3. DTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.4. Use of UDP in WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.5. Use of transport layer proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2. Protocols for congestion control in WSNs . . . . . . . . . . . . . . . . . . . . . .
8.2.1. CODA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2. Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.3. CCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
221
222
222
223
224
225
225
226
227
228
229
191
191
192
192
193
193
13
6/9/10
09:58
Página 14
Sensors Everywhere
8.2.4. PCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.5. Siphon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3. Protocols for reliability in WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1. ReInForM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2. RMST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.3. RBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.4. PSFQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4. Protocols for congestion control and reliability in WSNs . . . . . . . .
8.4.1. STCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.2. ESRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5. Transport mechanisms in ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
231
232
233
235
235
236
236
237
239
240
240
241
243
244
245
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1. Security services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2. Security of IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1. Security suites of IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.2. Security of IEEE 802.15.4-2006 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3. Security services of ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.1. ZigBee security architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.2. MAC layer security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.3. NWK layer security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.4. APL security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.5. Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4. Security services of other solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
251
251
252
252
254
255
255
257
257
258
260
267
268
10. Operating systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1. Basic features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2. Existing operating systems for wireless sensor nodes . . . . . . . . .
10.2.1. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.2. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.3. RETOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
273
273
274
275
275
275
14
6/9/10
09:58
Página 15
10.2.3. uC/OS II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.4. AMBIENT RT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.5. Nano-Qplus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.6. MantisOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.7. SOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.8. Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.9. Microsoft .NET Micro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
276
276
276
277
277
277
278
278
11. Wireless sensor network architectures and technologies . . .
11.1. General purpose solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.1.1. ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.1.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.1.3. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2. Home/Building automation and AMR/AMI solutions . . . . . . . . . .
11.2.1. Z-Wave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.2. Wavenis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.3. EnOcean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.4. INSTEON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.5. ONE-NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3. Industrial automation networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.1. TSMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.2. WirelessHART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.3. ISA100.11a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.Other solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.1. SensiNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.2. XMesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.3. ANT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.4. DigiMesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.5. AmbioSystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.6. Ambient Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.7. RuBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
283
283
284
290
292
297
297
299
301
302
304
304
304
306
307
308
308
309
309
310
310
311
312
312
12. Sensed data management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
12.1. In-network storage management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
15
6/9/10
09:58
Página 16
Sensors Everywhere
12.2. Data interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.1. Use of XML in WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.2. EEML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.3. SensorML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.3. Sensor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.4. IEEE 1451 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
321
322
323
323
325
325
328
13. Interoperability between wireless sensor networks and
other networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1. DTN for WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1.1. DTN overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1.2. DTN discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2. Protocol Translation Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2.1. PTG overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2.2. PTG discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3. IP for WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.1. Benefits of IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.2. Benefits of IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.3. Adoption of IP for WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.4. IETF work in progress and future work . . . . . . . . . . . . . . . . . . . .
13.3.5. Usage of existing session/application protocols for WSN . .
13.4. SCADA for WSN applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5. Integration of WSNs into IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
333
334
334
336
336
336
337
338
338
340
340
341
341
345
346
347
14. Energy consumption and harvesting . . . . . . . . . . . . . . . . . . . . . . . .
14.1. Energy consumption model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.1.1. Power consumption for data communication . . . . . . . . . . . . .
14.1.2. Power consumption in data processing . . . . . . . . . . . . . . . . . . .
14.1.3. Power consumption modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.1.4. Communication vs. computation energy consumption . . .
14.2. Power sources for sensor networks . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.2.2. Energy harvesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
355
356
356
358
359
359
360
360
366
16
6/9/10
09:58
Página 17
15. Localization techniques and wireless sensor networks . . . . .
15.1. Proximity location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.2. Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.3. Fingerpinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
371
373
374
377
377
16. Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1. Middleware for WSNs vs. middleware for traditional
environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2. Components of a generic middleware solution for WSNs . . .
16.2.1. Programming abstractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2.2. System services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2.3. Run-time support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2.4. QoS mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3. Middleware system common services . . . . . . . . . . . . . . . . . . . . . . . .
16.3.1. Code management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3.2. Data management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3.3. Discovery of nodes, resources and characteristics . . . . . . . .
16.3.4. Resource management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3.5. Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
381
17. Future directions in wireless sensor networks . . . . . . . . . . . . . .
17.1. More and more sensors in everyday life . . . . . . . . . . . . . . . . . . . . . .
17.2. Efficient energy harvesting sensor nodes . . . . . . . . . . . . . . . . . . . . .
17.3. Standardised WSN solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.4. IP-based WSNs and the Internet of Things . . . . . . . . . . . . . . . . . . . .
17.5. Applications development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
395
395
396
396
397
398
398
381
383
383
385
385
386
386
386
387
387
388
388
388
388
391
Glossary of Terms and Abbreviations in Alphabetical Order . . . . 401
17
6/9/10
09:58
Página 18
Sensors Everywhere
Index of figures
Fig. 1.1. Architecture of a sensor node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 1.2. Star topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 1.3. a) Tree topology; b) mesh topology . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 2.1. Sensor node from Shimmer with a ECG extension [54] . . . . . . . .
Fig. 2.2. Wireless sensor node to be fitted at the wrist (orange box) for
patient identification, monitoring and location. The black box at
the top of the image is used as a wireless router to create a
backhaul network used for communication and as a reference
for location in the hospital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 2.3. Motion sensor based on a passive infrared (PIR) sensor providing also temperature and illumination level . . . . . . . . . . . . . . . . . . .
Fig. 2.4. Advanced metering equipment from Nuri Telecom being
installed on an existing metering equipment . . . . . . . . . . . . . . . . . .
Fig. 2.5. Example of a sensor node that includes a humidity sensor . . . .
Fig. 2.6. A sensor node placed inside of a rubbish container for measuring its occupancy level by using ultrasound signals . . . . . . . .
Fig. 2.7. Sensor node able to support up to five soil moisture sensors
installed in the field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.1. Two signals reach the receiver: an LOS signal and another
which is reflected by the ground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.2. (left) An example of scattering, (right) an example of diffraction
Fig. 3.3. Emission limits for handheld UWB systems allowed by the
European Telecommunications Standards Institute (ETSI), blue
curve, and the Federal Communications Commission (FCC,
USA), red curve (adapted from [6]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.4. An example: use of the ASK modulation for the transmission of
the sequence 101101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.5. An example: use of the BPSK modulation for the transmission
of the sequence 101101. Every “1”introduces a 180º phase
shift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.6. Example: use of the FSK modulation for the transmission of the
sequence 101101. In contrast to this example, the transmission of two different consecutive symbols may lead to an
18
63
64
66
73
73
76
78
80
81
83
100
100
103
104
105
6/9/10
09:58
Página 19
abrupt change in the signal, which enlarges the signal spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.7. The IEEE 802.15.4 PPDU format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.8. Block diagram of the DSSS/BPSK spreading and modulation
techniques used in the 868/915 MHz band . . . . . . . . . . . . . . . . . .
Fig. 3.9.Block diagram of the DSSS/O-QPSK spreading and modulation
techniques used in the 2.4 GHz band . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.10. Block diagram of the spreading and modulation techniques
used in the PSSS/ASK PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.11. Proposed frequency bands and channel numbers for IEEE
802.15.4a UWB (adapted from [12]) . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.12. Block diagram of the modulator used in the UWB PHY . . . . . . .
Fig. 3.13. Example of the location of a burst in a symbol in the BPMUWB modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.14. Block diagram of the modulator used in the CSS PHY . . . . . . . .
Fig. 3.15. Block diagram of the FHSS/GFSK scheme used for the Data
channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.16. (top) IEEE 802.15.4 channels, (medium) non-overlapping IEEE
802.11 channels in America and (bottom) non-overlapping
IEEE 802.11 channels in Europe. NOTE: PSD stands for Power
Spectrum Density . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 4.1. Example of TDMA. If slot 3 has been assigned to a user, it may
transmit at every slot 3 of each frame . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 4.2. Hidden terminal problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 4.3. Exposed terminal problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 4.4. Example of the active and sleep intervals in S-MAC, T-MAC and
DSMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 4.5. Example of DMAC in a data gathering tree . . . . . . . . . . . . . . . . . . . .
Fig. 4.6. Example of a superframe. The CFP contains two GTS of different sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 4.7. Example of acknowledged transmissions and the related IFSs .
Fig. 4.8. Example of unacknowledged transmissions and the related
IFSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 4.9. Format of the IEEE 802.15.4 beacon frame . . . . . . . . . . . . . . . . . . . .
Fig. 4.10. Format of the IEEE 802.15.4 data frame . . . . . . . . . . . . . . . . . . . . . .
105
110
111
111
114
117
117
118
120
123
125
132
136
136
140
141
149
151
151
153
154
19
6/9/10
09:58
Página 20
Sensors Everywhere
Fig. 4.11. Format of the IEEE 802.15.4 acknowledgment frame . . . . . . . .
Fig. 4.12. Format of the IEEE 802.15.4 command frame . . . . . . . . . . . . . . . .
Fig. 4.13. State diagram of BT-LE link layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 4.14. Connection and data transmission message chart . . . . . . . . . . .
Fig. 4.15. Format of a BT-LE frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 4.16. Format of an advertising BT-LE frame . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 5.1. Typical SPI bus with one master and three slaves . . . . . . . . . . . . .
Fig. 5.2. Dipole antenna and the horizontal (in green) and vertical radiation pattern (in red) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 5.3. Whip antenna used to be mounted on a metallic structure. In
this model the connector can be folded to facilitate the transport of the equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 5.4. From left to right: a) Folded monopole, b) Meander antenna, c)
Helix antenna (the total length of the wire is close to a quarter
of wavelength), d) Full wave loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 5.5. Inverted F-antenna (IFA). It is based on a folded monopole by
with an additional segment to modify the resistance offered by
the antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 5.6. Chip antenna used for a 2.4 GHz band . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 5.7. At the upper part of the image an UF-L connector and at lower
part a SMA connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 5.8. Boards for the Mica2, MicaZ and Iris with sensors . . . . . . . . . . . . .
Fig. 5.9. Sensor node made with a single chip (SoC) CC2430 made by
Texas Instruments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 5.10. Module MNZB-900-BO from MeshNetics. At the right the
module showing the upper side. At the left the module
mounted on a board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 5.11. Images of different full operational platforms. From left to
right: the MicaDot, MicaZ and Iris sensor nodes . . . . . . . . . . . . . .
Fig. 6.1. Nodes of a network organized into clusters. The clusterhead acts as a gateway for the nodes that belong to its
cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 6.2. Example of a network with LEACH. The cluster-heads receive data
from the nodes of their clusters, and after being processed the
data are transmitted by the cluster-heads directly to the sink . . . .
20
154
155
157
158
159
160
168
173
174
174
175
175
176
178
181
181
182
189
190
6/9/10
09:58
Página 21
Fig. 6.3. A taxonomy of topology control techniques based on dynamic
transmission range assignment (reproduced from [1]) . . . . . . . . .
Fig. 7.1. Basic operation of Directed Diffusion: a) Interest propagation, b)
initial gradients set up, c) data delivery along reinforced path .
Fig. 7.2. Example of SPIN basic operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 7.3. PEGASIS operation: a) data collected by node A follow the path
ABC and then C transmits directly to the sink, b) in another
turn, data collected by node A follow the path ABCD and then
D transmits directly to the sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 7.4. Example of a greedy forwarding failure. The dotted line indicates the coverage range of node A . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 7.5. Route Discovery in AODV: node S intends to find a path to node
D. Node S broadcasts a RREQ message; when a RREQ reaches
the destination, this node replies back to the source with a
RREP message, which is transmitted backwards to the source
and creates routing entries to node D in the intermediate
nodes and the source node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 7.6. An example of a DAG in RPL. Note that Node 7 has two parents,
which are Nodes 2 and 3. Assuming that Nodes 4 and 6 are
neighbours of Node 5, Node 5 can choose both of them as
siblings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 8.1. Downstream vs. upstream traffic directions in a typical WSN . .
Fig. 8.2. CCF operation (adapted from [16]) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 8.3. Node model that includes sub-queues between MAC and network layer (adapted from [12]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 9.1. Payload of the ZigBee frame (MAC payload, when MAC layer
security is used. The last field, denoted by MAC, is the Message
Authentication Code. The size of each field is expressed in
bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 9.2. Payload of the ZigBee frame (MAC payload, when NWK layer
byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 9.3. Payload of a ZigBee frame (MAC layer payload), when APS
191
199
201
203
205
208
213
226
230
232
257
258
21
6/9/10
09:58
Página 22
Sensors Everywhere
bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 9.4. Message exchange between a router and a new device that
aims at joining a secure ZigBee network . . . . . . . . . . . . . . . . . . . . . .
Fig. 9.5. Message chart for the authentication of a new device in a secure ZigBee network, in residential mode . . . . . . . . . . . . . . . . . . . . .
Fig. 9.6. Message exchange for the authentication of a new device in a
secure ZigBee network, in commercial mode . . . . . . . . . . . . . . . . .
Fig. 9.7. Message exchange for the network key update in a secure
ZigBee network (commercial mode) . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 9.8. Messages of the network key recovery procedure in a secure
ZigBee network (commercial mode) . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 9.9. Sequence of messages for the network key establishment in a
secure ZigBee network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 9.10. Message sequence for a device that leaves a secure ZigBee
network, initiated by the device itself . . . . . . . . . . . . . . . . . . . . . . . .
network, initiated by the trust center . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 11.1. ZigBee protocol stack (adapted from [1]) . . . . . . . . . . . . . . . . . . . . .
Fig. 11.2. 6LoWPAN architecture: a) mesh under, b) route over . . . . . . . . .
Fig. 11.3. Three possible Bluetooth Host and Controller Combinations
[37] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 11.4. BT-LE protocol stack overview for the dual mode [37] . . . . . . .
Fig. 11.5. Z-Wave protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 11.6. Wavenis protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 11.7. nRF24AP2 chip-based solution that includes the ANT protocol stack [31] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 11.8. AmbioMote 24-A platform [33] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 11.9. Ambient Systems MicroRouter [34] . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 12.1. Example of the SensorML description of a sensor [10] . . . . . . .
Fig. 12.2. Response Example – YSI Wind Speed Sensor [10] . . . . . . . . . . .
Fig. 12.3. Smart Transducer model with modules and interfaces [18] . . .
Fig. 13.1. A DTN-based architecture for connecting a WSN to the
Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 13.2. A proposed ZigBee-to-IP gateway architecture [4] . . . . . . . . . . . .
22
258
261
262
263
264
265
266
267
267
284
292
295
296
299
301
310
311
312
324
324
326
335
337
6/9/10
09:58
Página 23
Fig. 13.3. Various WSNs connected to the Internet by means of PTGs . .
Fig. 13.4. Various WSNs connected to the Internet by means of IP routers: the end-to-end IP vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 13.5. ZigBee adaptation to IETF 6LoWPAN protocol stack . . . . . . . . . .
Fig. 13.6. SIP/ZigBee proposed architecture [20] . . . . . . . . . . . . . . . . . . . . . . .
Fig. 14.1. Illustration of an energy harvesting and storage module that
uses an ultra-capacitor [17] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 14.2. A node that uses photovoltaic cells . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 14.3. Example of energy harvesting using vibration . . . . . . . . . . . . . . . .
Fig. 14.4. Thermal harvesting platform able to drive an IEEE 802.15.4
sensor node with a thermal difference of 3.5º K [12] . . . . . . . . .
Fig. 14.5. A system that harvests from wind energy . . . . . . . . . . . . . . . . . . . .
Fig. 14.6. RF power transmitter by Powercast [15] . . . . . . . . . . . . . . . . . . . . . .
Fig. 15.1. Positioning using a) three distances (trilateralization), b) three
angles (triangularization) and c) mixing measures of distance
and angle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 15.2. Location estimation based on the proximity criteria and using
the three strongest signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 15.3. Representation of the error area in a trilateralization with distances erroneously measured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 15.4. Cricket node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 15.5. Ultrasound ranger (to measure distances) with separated
transmitter and receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
338
339
341
347
362
363
364
365
365
366
372
373
374
375
376
Index of tables
Table 2.1. Examples of characteristics that can be sensed in the environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3.1. A subset of the ISM and regional license-free bands of interest to low power applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3.2. Physical layer features of IEEE 802.15.4-2003 . . . . . . . . . . . . . . .
Table 3.3. Optional physical layer features added to the IEEE 802.15.42006 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3.4. Channel pages specified in IEEE 802.15.4-2006 . . . . . . . . . . . . .
Table 3.5. Channel pages added in IEEE 802.15.4a . . . . . . . . . . . . . . . . . . . . .
72
102
109
113
113
115
23
6/9/10
09:58
Página 24
Sensors Everywhere
Table 3.6. Channels and band groups for IEEE 802.15.4a UWB [12] . . . .
Table 3.7. Assignments of radiofrequency channels in BT-LE [18] . . . . . .
Table 4.1. A comparative summary of MAC protocols . . . . . . . . . . . . . . . . . .
Table 4.2. Maximum user data throughput with unslotted IEEE
802.15.4-2003 [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4.3. Range of latencies with unslotted IEEE 802.15.4-2003 . . . . . .
Table 8.1. Main characteristics of transport protocols for congestion
control (adapted from [7]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 8.2. Main characteristics of transport protocols for reliability . . . . .
Table 8.3. Summary of ESRT actions (adapted from [13]) . . . . . . . . . . . . . . .
control and reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 9.1. IEEE 802.15.4 security suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 9.2. Summary of security service provided by ZigBee, 6LoWPAN
and BT-LE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 11.1. Comparison of ZigBee stacks [6] . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 14.1. Definition of parameters of a power consumption model in
data communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 14.2. Characteristics of WSN chips [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
data processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 14.4. Energy density of three primary battery chemistries . . . . . . .
Table 14.5. Energy density of three secondary battery chemistries . . . .
Table 16.1. Middleware proposals and their main characteristics (adapted from [4]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 16.2. Development status of some of the middleware proposals
available for WSNs (adapted from [4]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
116
122
147
155
156
234
239
243
244
253
268
289
356
358
358
361
361
389
390
6/9/10
09:58
Página 25
Summary in Spanish
6/9/10
09:58
Página 26
6/9/10
09:58
Página 27
Sensores en todas partes: tecnologías y
soluciones de redes inalámbricas
1.
Introducción a las WSNs
Una WSN es una red inalámbrica compuesta por nodos sensores (que
pueden interactuar entre ellos) que permite monitorizar parámetros físicos
de un cierto entorno y ofrecer los datos a uno o más nodos sumideros que
se encargan de recolectar la información obtenida. En algunos casos, los
mismos elementos de una red de sensores pueden ser empleados para activar actuadores, para llevar a cabo tareas en respuesta a ciertos estímulos
(p. ej. la detección de un evento).
Un nodo sensor es un dispositivo con capacidad de procesado y transmisión (en general, inalámbrica) que incluye uno o más sensores, y que puede
incluir actuadores.
Los sensores son dispositivos que miden magnitudes físicas, convirtiendo la medida en una señal (que p. ej. puede ser eléctrica). Algunos ejemplos
de magnitudes que puede medir un sensor son: intensidad eléctrica, tensión, presión, humedad, temperatura, intensidad acústica, concentración de
oxígeno, etc.
Los actuadores son dispositivos que pueden llevar a cabo una acción
(p. ej. disparar una alarma, apagar un sistema de riego, etc.) en respuesta a
un cierto estímulo.
Las WSNs pueden ser redes aisladas, pero es interesante conectarlas a
otras redes (p. ej. Internet) para su acceso remoto y gestión. En tal caso, la
27
6/9/10
09:58
Página 28
Sensors Everywhere
conectividad entre la WSN y otra red puede ser lograda por medio de una
pasarela o gateway, o bien otros dispositivos, dependiendo de los protocolos empleados en la WSN y en la red a la cual ésta se conecta.
La tecnología WSN abre la puerta a un gran abanico de aplicaciones de
control y monitorización en multitud de entornos, tales como la automatización residencial y de edificios, el control industrial, la monitorización
ambiental, etc.
Las WSNs se caracterizan por el hecho de que los nodos que las componen exhiben limitaciones hardware significativas (incluyendo que en
muchos casos pueden estar únicamente alimentados por una batería). Por
otra parte, se asume que el número de nodos de una WSN puede ser elevado. En la mayoría de casos, los nodos sensores emplean arquitecturas de
protocolos de comunicaciones basadas en capas.
Las principales topologías que existen en las WSNs son las topologías en
estrella, malladas y en árbol. La topología en estrella puede ser adecuada
para aplicaciones donde existe un nodo central que controla al resto. Por
otra parte, la topología en árbol suele emplearse para la recolección de
datos hacia un sumidero que se ubica en la raíz del árbol. En muchas ocasiones, resulta conveniente el empleo de una topología mallada, que ofrece
diversos caminos entre dos nodos y, por tanto, es tolerante a caídas de enlaces y/o nodos.
2. Aplicaciones de las WSNs e iniciativas de estandarización
El interés por las redes de sensores sin hilos se remonta a los años 70 en
el marco de las investigaciones aplicadas al ámbito militar. Proyectos como
“SmartDust” pusieron las bases de las redes de sensores tanto a nivel conceptual como tecnológico. Desde estas fechas iniciales, el interés por las
redes de sensores inalámbricos no ha parado de crecer en la medida que la
tecnología hacia más factible su realización. De la misma forma han ido apareciendo nuevas aplicaciones que han generado nuevos requerimientos en
la tecnología. Por el momento, el mercado de las aplicaciones de redes de
sensores corresponde a nichos de mercado que no justifican todo el esfuer-
28
6/9/10
09:58
Página 29
zo dedicado a esta tecnología, pero la mayoría de analistas auguran para las
redes de sensores un despegue en los próximos años. Por el momento las
aplicaciones en las que más comunes en las que se aplican las redes de sensores son las presentadas a continuación:
• Teleasistencia médica: personas con problemas de salud (p. ej. ancianos, discapacitados, etc.) pueden beneficiarse del uso de sensores que
midan sus parámetros biométricos, entre otros, para permitir su monitorización remota permanente. De este modo, se pueden llevar a cabo
diagnósticos precisos y se pueden disparar alarmas en caso de que se
detecte alguna situación de emergencia.
• Monitorización medioambiental: las propiedades de reducido tamaño
y gran autonomía hacen de los sensores los elementos ideales para
poder monitorizar el entorno. Los sensores se puede camuflar fácilmente o incluso colocarse encima de animales.
• Monitorización preventiva: tanto en infraestructuras como en sistemas
mecánicos, las redes de sensores se pueden usar para realizar una
monitorización continua de parámetros que permitan predecir el colapso de un puente o la rotura de una pieza. Para este propósito se usan
sensores de vibración, desplazamiento o temperatura, principalmente.
Se debe disponer de un software que pueda extrapolar la evolución
temporal de las medidas en potenciales problemas en los sistemas.
• Agricultura: la mejora de la productividad, no sólo en cantidad sino
también en calidad, y la escasez de agua en ciertas regiones justifica
el uso de sensores que permitan ver el grado de humedad del suelo
para determinar el momento y la cantidad de riego. También la humedad de las hojas se puede usar para predecir la posibilidad de que ocurran infecciones de hongos, así como los medidores de radiación solar,
para determinar el grado de madurez y por ello el momento ideal para
la recolección. El uso de redes de sensores sin hilos se está planteando en cultivos como el de la vid, en los que se requiere un control preciso de la calidad.
• Automatización de edificios: un hogar o una oficina son lugares en los
que se pueden encontrar diversos sensores, actuadores y dispositivos
29
6/9/10
09:58
Página 30
Sensors Everywhere
que deben ser controlados. Hasta la fecha, han existido soluciones
especificas para cada área como climatización, control luminoso o
seguridad, pero eran costosas, complejas de instalar y propietarias.
Con el desarrollo de las redes de sensores sin hilos se pueden unificar
todas las soluciones en un único sistema, facilitando mejoras de funcionamiento y de coste.
• Medida de contadores: las empresas de suministro de gas, agua y
electricidad llevan intentando realizar las lecturas de los contadores
situados en casa del cliente de forma remota. Las redes de sensores
en un primer paso han de medir el consumo y reportarlo al operador. En un segundo paso, del que ya se está hablando, se debe poder
usar estas redes para poder interactuar con los equipos del usuario
y poder realizar un control de la demanda y ofrecer servicios adicionales.
• Ciudades inteligentes: la gestión urbana engloba aspectos como la
gestión de los equipamientos, zonas verdes, recogida de basuras,
transporte público, alcantarillado, tráfico rodado e iluminación, para
citar algunos. Las redes de sensores se pueden usar como monitores
del correcto funcionamiento y como automatismos inteligentes. Se
pueden controlar el riego de las zonas verdes, el ahorro en la iluminación en zonas sin presencia de personas, planificar la recogida de
basuras en función de la ocupación de los contenedores o la identificación de plazas de aparcamiento disponibles. Esta información
puede redundar en una reducción del personal y una mejora de la
información ofrecida al ciudadano.
• Generación de contexto: los sensores, al poder captar parámetros físicos de entorno, tienen la capacidad de describirlo. Esta virtualización
del entorno se puede usar para crear un contexto que facilite el uso de
aplicaciones. Por ejemplo, el conocimiento de la localización se puede
usar para entregar información adecuada al usuario o las condiciones
de nivel de ruido o iluminación para ajustar el reproductor de contenidos. Los teléfonos móviles actuales disponen de una amplia gama de
sensores (posición, temperatura, proximidad, aceleración, campo magnético). Además, en un futuro próximo, podrían disponer de interfaces
30
6/9/10
09:58
Página 31
radio Bluetooth con modo de operación Low Energy, que les permitirán recoger información de otros sensores situados en las inmediaciones.
El mercado (productores, desarrolladores, usuarios, etc.) reconoce la
necesidad de una estandarización. Ésta podrá dar al mercado el tamaño
necesario para recuperar las inversiones en el desarrollo de la electrónica
integrada, permitirá al desarrollador de aplicaciones reusar su experiencia y
ofrecer al usuario multitud de aplicaciones a partir de información recogida
de una gran variedad de redes de sensores.
Diversos foros han ganado protagonismo en la estandarización de las
WSNs. El primero de ellos fue el Instituto de Ingenieros Eléctricos y
Electrónicos (IEEE) que creó un grupo de trabajo específico en el ámbito de
las redes de área personal de baja velocidad. El objetivo inicial no eran las
WSN, pero sí la definición de una interfaz radio que se pudiese compartir y
que fuese de bajas prestaciones. El citado grupo de trabajo ha desarrollado
la familia de especificaciones IEEE 802.15.4 para los protocolos de capa física y de control de acceso al medio de esa interfaz radio. Por su parte, los
fabricantes de circuitos integrados mayoritariamente lideraron la creación
de otros foros de estandarización, como por ejemplo ZigBee Alliance (inspirados por el éxito de Wi-Fi Alliance, pero con objetivos mucho más ambiciosos). ZigBee Alliance ha especificado una pila completa de protocolos, usando en las capas física y MAC los protocolos definidos por IEEE 802.15.4. En
el entorno de Internet, y ante la posibilidad de dotar a estos elementos de
conectividad a Internet, el IETF también empezó su actividad en el área. Se
ofreció inicialmente una capa de adaptación que permita el transporte de IP
(versión 6 en particular) también sobre interfaces radio IEEE 802.15.4
(6LoWPAN WG). Esta actividad continuó con la definición de soluciones de
encaminamiento (ROLL WG) y funcionalidades y aplicaciones de nivel superior (CoRE WG). Otro grupo de fabricantes y desarrolladores que se ha unido
a la estandarización de las WSN ha sido el grupo de interés de Bluetooth
(Bluetooth SIG) con la incorporación de una modificación del estándar
denominada Bluetooth Low Energy. La ISO, viendo la necesidad de estándares mundiales para que la tecnología llegue a triunfar, ha creado un grupo
de trabajo en el ámbito de la Internet de las cosas y el área de las WSN.
31
6/9/10
09:58
Página 32
Sensors Everywhere
Finalmente, fabricantes de tecnologías que por el momento se podrían
catalogar como propietarias han creado foros para fomentar sus soluciones
y ofrecer una imagen de estándar abierto y público, como por ejemplo
Z-Wave Alliance, Wavenis Open Standard Alliance, INSTEON Alliance o
EnOcean Alliance.
3.
Capa física
Los nodos de una WSN emplean tecnologías radio para la transmisión de
señales. Por tanto, estas tecnologías se pueden ver afectadas por problemas
como la interferencia, la atenuación, la propagación multi–camino, etc. Las
soluciones de capa física para WSNs deben hacer frente a estos fenómenos
y, al mismo tiempo, deben posibilitar una implementación sencilla, dadas las
restricciones de los nodos de una WSN (típicamente bajo consumo, pequeño tamaño y bajo coste).
Un parámetro fundamental en el diseño y evaluación de WSNs (al igual
que ocurre en general en las redes de comunicaciones inalámbricas) es el
radio de transmisión de un emisor, que se define como la máxima distancia
desde la antena del emisor que da lugar a una relación señal a ruido (SNR)
superior a la mínima requerida por el receptor. La potencia de la señal recibida depende de la distancia entre emisor y receptor y de la frecuencia portadora de la señal, entre otros parámetros.
Las bandas de frecuencia más utilizadas en redes WSN son cuatro:
(430 – 434) MHz, (865 – 870) MHz, (902-928) MHz y (2400 – 2483.5) MHz.
Se suelen denominar por la frecuencia típica de uso, que en cada caso es
433 MHz, 868 MHz, 915 MHz y 2,4 GHz respectivamente. Estas bandas han
sido asignadas por la ITU y se reservan para uso privado y no licenciado,
aunque en algún caso pueden estar sujetas a ciertas restricciones dependiendo de la regulación nacional o regional correspondiente. Salvo la banda
de 915 MHz, el resto se emplea habitualmente en Europa.
El estándar IEEE 802.15.4 ofrece distintas soluciones de capa física en
sus distintas versiones. Las características principales de IEEE 802.15.42003 se muestran en la Tabla 1.
32
6/9/10
09:58
Página 33
Banda de Número de
frecuencia
canales
868 MHz
1
915 MHz
10
2.4 GHz
16
Técnica de
ensanchado
Modulación
Tasa de
Tasa de bit
símbolo por por canal
canal (kbaud)
(kbps)
Binary
DSSS
Binary
DSSS
16-array
DSSS
BPSK
20
20
BPSK
40
40
O-QPSK
62.5
250
Tabla 1. Características de capa física de IEEE 802.15.4-2003
El estándar IEEE 802.15.4-2006 incorpora soluciones de capa física opcionales basadas en ASK y O-QPSK, que proporcionan tasas de bits de 100
kbps y 250 kbps. Por otra parte, la especificación IEEE 802.15.4a define una
capa física con tecnología UWB (que, al menos, debe ofrecer una tasa de
851 kbps) y otra basada en CSS (con tasas de 250 kbps y 1 Mbps).
La tecnología BT-LE emplea 40 canales en la banda de 2.4 GHz. Estos
canales se dividen en canales de datos y de “anuncio” (empleados para la
difusión de datos de señalización y control). Los canales de datos emplean
FHSS para hacer frente a interferencias, mientras que los de anuncio emplean frecuencias fijas.
El uso de las mismas bandas de frecuencia (p. ej. la banda de 2.4 GHz) por
parte de distintos sistemas plantea problemas de coexistencia. La diferente
definición de las frecuencias portadoras entre los sistemas IEEE 802.11 e
IEEE 802.15.4 hace que las redes IEEE 802.15.4 pueden emplear canales no
solapados con los de IEEE 802.11, mientras que Bluetooth dispone de
mecanismos que evitan canales interferidos.
4.
Capa MAC
Las WSNs son redes donde varios dispositivos comparten el mismo
medio de transmisión (un canal radio). La capa de control de acceso al
medio (MAC) se encarga de gestionar el acceso al medio por parte de los
33
6/9/10
09:58
Página 34
Sensors Everywhere
nodos. Los protocolos MAC de las WSNs difieren de los protocolos tradicionales en dos aspectos fundamentales: i) la conservación de energía es el
principal principio de diseño y ii) tienen en cuenta el empleo de esquemas
de comunicación multi–salto.
Según su principio de funcionamiento, la mayoría de los protocolos MAC
para WSNs se pueden clasificar en protocolos basados en planificación, protocolos basados en contienda y protocolos basados en ciclo de trabajo. Los protocolos basados en planificación (p. ej. TDMA, LEACH, TRAMA) consisten en la
asignación de intervalos temporales para la transmisión de un determinado
nodo. Los protocolos basados en contienda (p. ej. CSMA, Sift, etc.) consisten en
un acceso al medio probabilístico y no reservan recursos para la transmisión de
los nodos. En estos casos, pueden ocurrir colisiones. Los protocolos basados en
ciclo de trabajo (p. ej. S-MAC, T-MAC, DSMAC, etc.) emplean distintas estrategias
para decidir cuándo la radio de un nodo está activada y cuándo está desactivada (sleep mode), así como en qué momento se realiza una transmisión.
La capa MAC de IEEE 802.15.4 ofrece dos soluciones. La primera asume
la existencia de un nodo coordinador, que transmite señales de radio baliza
(o beacons) para la sincronización entre dispositivos; en este caso, el acceso al medio se puede realizar sin contienda (mediante TDMA) y con contienda (con CSMA/CA). La segunda solución, donde no existe nodo coordinador,
ofrece un acceso al medio con contienda. En ambos casos, IEEE 802.15.4
ofrece la posibilidad de que un nodo transmita una confirmación tras cada
recepción correcta de trama (modo fiable). Las prestaciones del modo sin
baliza se muestran en la Tabla 2. El tamaño máximo de una trama IEEE
802.15.4 es 127 bytes.
Longitud
dirección
MAC
Modo
16 bit
Fiable
No fiable
Fiable
No fiable
64 bit
Máximo caudal de datos
de usuario (kbps)
868 MHz
915 MHz
2.4 GHz
14.3
15.5
12.8
13.9
28.6
31.1
26.6
27.8
139.0
151.6
124.4
135.6
Tabla 2. Máximo caudal de usuario con IEEE 802.15.4-2003, sin baliza
34
6/9/10
09:58
Página 35
Por su parte, BT-LE simplifica el número de estados y el procedimiento
de transacción de datos entre los nodos involucrados. BT-LE incorpora el
uso de confirmaciones y control de flujo mediante ventana deslizante. Las
tramas de BT-LE tienen un tamaño máximo de 47 bytes.
5.
Plataformas de nodos sensores
Un nodo sensor está compuesto por un conjunto de elementos como un
procesador, memoria, transceptor radio, antena, fuente de energía y sensores o actuadores. Unas características comunes de estos elementos son la
minimización del tamaño, del coste y del consumo energético. La mayoría
de elementos se presentan montados en una placa de circuito impreso y se
ofrece conectores a todos aquellos elementos que pueden tener más variabilidad en la elección, como antena, sensores o actuadores y fuente de alimentación. Cuando esta placa se dispone para ser usada en otro circuito
integrado, se habla de módulo o de SiP (System in Package), si se encapsula como un circuito integrado. El procesador, el transceptor radio y la
memoria se presentan como circuitos integrados en uno, dos o tres circuitos. Si procesador y transceptor se integran como un mismo circuito integrado se habla de un SoC (System on Chip). También es bastante común que
procesador y memoria se integren en un solo chip.
El circuito transceptor se encarga de generar una señal de radiofrecuencia a partir de una de banda base digital y viceversa. Las bandas de frecuencias usadas corresponden a las ISM de mayor aceptación global como las de
433 MHz y 2,4 GHz. Las de 868 MHz y 915 MHz, a pesar de ser de ámbito
más local, también disponen de transceptores integrados. El estándar más
adoptado en los transceptores de un nodo sensor es el IEEE 802.15.4, pero
también podemos encontrar otros genéricos (que permiten definir un interfaz radio diseñado en función de las necesidades, gustos o preferencias
específicas de cada usuario) y otros propietarios. Están empezando a aparecer en el mercado transceptores de Bluetooth Low Energy. La potencia de
salida de estos transceptores es del orden de unos pocos milivatios (1 a
10 mW). Para alcanzar mayores potencias se usa una etapa amplificadora. El
medio radio es compartido y, por ello, se precisa un protocolo de acceso o
35
6/9/10
09:58
Página 36
Sensors Everywhere
MAC. Este protocolo se implementa entre el transceptor radio y el procesador. Este último elemento, el elemento inteligente del nodo, se cataloga
como MCU (Microcontroller Unit) que engloba una unidad de proceso simple, memoria e interfaces de entrada/salida. La gama de MCUs es muy
extensa, con diversos fabricantes que ofrecen una gama de modelos. Se
puede observar unos dispositivos que usan procesadores de 8 bits hasta los
de 32 bits con una arquitectura RISC (Reduced Instruction Set Computer),
que ofrece hasta los 32 MIPS (Million Instructions Per Second). Las MCUs de
baja gama se asocian a diseños SoC. La cantidad de memoria disponible,
particularmente la RAM, es muy variable. Podemos encontrar MCUs con 1
kB de RAM hasta las que disponen de 128 kB. La memoria no volátil puede
ser ROM o flash y varía entre las decenas de kbytes a las pocas centenas. Un
aspecto importante en estos componentes son los modos de funcionamiento y el consumo asociado. La MCU puede pasar de un estado inactivo
(sleep mode) con alguna de sus componentes desconectadas y con un reloj
de 32 kHz a un estado activo con un reloj de decenas de megahercios. Entre
estos dos estados se pasa de las fracciones de microamperio a los pocos
miliamperios. Las MCUs también disponen de una amplia gama de entradas
y salidas. Se disponen de varios puertos analógicos y sus correspondientes
conversores de analógico a digital y digital a analógico. Estos conversores
permiten que ciertos tipos de sensores y actuadores que manejan señales
analógicas se puedan conectar fácilmente. También se dispone de puertos
serie o UART (Universal Asynchronous Receiver/Transmitter) y buses que
permiten conectar varios dispositivos como el I2C (Inter-Integrated Circuit),
el SPI (Serial Peripheral Interface) o líneas individuales de entrada/salida.
Alguno de estor puertos se usa para conectar sensores/actuadores que
manejan información en formato digital, para conectar memoria flash o
conectarse con el transceptor radio.
Los sensores presentan una gama muy amplia de interfases, alimentaciones y señales de diferentes formatos. Generalmente se requieren circuitos de adaptación, ya que los niveles de señal y las alimentaciones que se
pueden ofrecer no encajan con los de la MCU. Existen iniciativas para la
estandarización de las interfases como la del IEEE 1451 que no han tenido
hasta el momento la aceptación necesaria para ser relevante en el área.
Existe una iniciativa denominada phidgets que ofrece un único interfaz.
36
6/9/10
09:58
Página 37
Como elementos adicionales, tenemos las antenas. Como el lugar de
ubicación de un sensor y los nodos con los que se comunica no es conocido generalmente a priori, las antenas son omnidireccionales. Las bandas de
frecuencia permiten tener antenas monopolo o antena whip, o una antena
integrada en placa de circuito impreso o cerámica (también llamada antena
chip). Las primeras generalmente ofrecen mejor ganancia, pero requieren
un conector y, en algunos casos, también un cable coaxial. Las segundas
son económicas mientras que las antenas chip pueden ser de muy reducido tamaño. Estas dos últimas tienen el problema de que la directividad de la
antena se ve afectada por los propios componentes y que se deben instalar
en compartimentos no metálicos.
6.
Control de topología
El control de topología es una técnica empleada en WSNs para optimizar
el rendimiento de algunos parámetros clave (p. ej. el tiempo de vida de la
red), manteniendo al mismo tiempo un buen compromiso con otros parámetros como la conectividad.
Los principales esquemas de control de topología se pueden clasificar en
dos categorías: i) técnicas basadas en el uso de redes jerárquicas y ii) técnicas basadas en ajustar el radio de transmisión de los nodos de manera dinámica. En el primer caso, existe una jerarquía en la red mediante la cual algunos mecanismos no involucran a todos los nodos de la red, sino a un subconjunto de nodos de acuerdo con su nivel jerárquico. Por otra parte, algunos nodos especiales pueden aliviar ciertas tareas de otros nodos. En el
segundo caso, independientemente de la existencia o no de jerarquía de
red, el radio de transmisión es configurado dinámicamente para lograr un
cierto objetivo. Dado que la transmisión y recepción son dos componentes
dominantes en el consumo de energía de un nodo sensor, el ajuste del radio
de transmisión es una técnica relevante que permite mejorar el rendimiento de la red en términos de consumo de energía y conectividad.
Un esquema jerárquico empleado en WSNs consiste en el uso de clusters. En este esquema, los nodos se organizan de modo que cada uno per-
37
6/9/10
09:58
Página 38
Sensors Everywhere
tenece a un cluster. Uno de los nodos del cluster es elegido como clusterhead, que actúa como pasarela para la comunicación entre nodos que no
pertenecen al mismo cluster. El cluster-head se puede comunicar con otros
cluster-head o puede transmitir datos directamente hacia un destino (p. ej.
un sumidero). En WSNs orientadas a la recolección de datos, un clusterhead puede también realizar operaciones con los datos obtenidos por los
nodos de su cluster, para minimizar la redundancia de la información obtenida por el cluster. El protocolo LEACH emplea un control de topología jerárquico, donde los cluster-heads son elegidos de forma rotativa y se encargan
de transmitir los datos a un sumidero.
Por otra parte, las técnicas de control de topología basadas en ajuste de
radio de transmisión pueden ser divididas en homogéneas y no homogéneas. En el primer caso, todos los nodos emplean un mismo radio de transmisión, mientras que en el segundo, cada nodo puede emplear un radio de
transmisión distinto. En control de topología no-homogéneo, la topología
puede ser gestionada empleando información de localización (asumiendo
que las posiciones de los nodos son conocidas), dirección (asumiendo que
los nodos no conocen su posición, pero pueden estimar la dirección relativa de sus vecinos) y de los vecinos de que dispone un nodo.
El control de topología requiere el uso de protocolos de control de topología, cuyo objetivo es la construcción y mantenimiento de ciertas topologías de red. Idealmente, estos protocolos deberían ser distribuidos, asíncronos
y deberían emplear únicamente información disponible a nivel local.
7.
Encaminamiento
Como en otros tipos de redes inalámbricas multi–salto, en WSNs, si el
destino no se encuentra dentro del alcance de la fuente, entonces la información puede ser retransmitida por nodos intermedios desde la fuente
hasta del destino. Este enfoque evita que la fuente deba emplear una potencia de transmisión elevada para alcanzar al destino. Por otra parte, es habitual que en las WSNs exista redundancia de caminos entre origen y destino,
lo cual proporciona fiabilidad frente a posibles caídas de enlaces y/o nodos.
38
6/9/10
09:58
Página 39
Los protocolos de encaminamiento son responsables de elegir el camino más adecuado entre la fuente y su destino. En las WSNs, los protocolos
de encaminamiento deben encontrar un buen compromiso entre varios
parámetros de rendimiento, como la tasa de entrega, la latencia y el consumo energético. Por otra parte, la escalabilidad es particularmente importante, dado el número elevado de nodos que pueden existir en una red y sus
limitaciones de memoria y energía.
Los protocolos de encaminamiento en WSNs se pueden clasificar según
el método empleado para seleccionar caminos en: encaminamiento plano,
encaminamiento jerárquico y encaminamiento geográfico. En encaminamiento plano, todos los nodos ejercen un mismo rol y se encuentran a un
mismo nivel, mientras que en encaminamiento jerárquico, los nodos ejercen
roles distintos según su categoría, lo cual delimita el alcance de ciertos
mecanismos y tiene buenas propiedades en cuanto a escalabilidad y ahorro
energético. En encaminamiento geográfico, los nodos, cuyas posiciones son
conocidas, reenvían los datos al vecino que más se aproxima geográficamente al destino.
Cabe comentar que algunos protocolos de encaminamiento plano,
como Directed Diffusion, se centran en la obtención de ciertos datos de interés, en lugar de pretender obtener datos de un cierto nodo en concreto.
Existe una gama de protocolos de encaminamiento que se han empleado en WSNs y que consisten en adaptaciones de protocolos de encaminamiento MANET. Un caso relevante es el del protocolo AODV, que constituye
la funcionalidad principal del mecanismo de encaminamiento mallado de
ZigBee.
Por otra parte, cabe destacar que el IETF ROLL WG está desarrollando el
protocolo denominado RPL, para redes que incluyen a las WSNs. RPL construye y mantiene un grafo acíclico dirigido que tiene su raíz en un nodo
sumidero. Un grafo acíclico dirigido representa una topología similar a la de
un árbol, con la salvedad de que un nodo puede escoger a varios nodos
padres. RPL está optimizado para aplicaciones de recolección de datos, pero
presenta problemas para las comunicaciones entre dos nodos arbitrarios,
dado que las rutas posibles se restringen al grafo que define el protocolo.
39
6/9/10
09:58
Página 40
Sensors Everywhere
8.
Transporte
La capa de transporte es la encargada de ofrecer fiabilidad extremo a
extremo. En algunos casos, también ofrece control de congestión. En WSNs,
el concepto de fiabilidad puede diferir del concepto tradicional, puesto que
algunas aplicaciones requieren fiabilidad en la detección de un evento, de
modo que no es necesario garantizar fiabilidad para la transmisión de cada
paquete. Por otra parte, el control de congestión puede ser realizado a cada
salto, lo cual permite ahorrar energía y ancho de banda.
Una solución a nivel de transporte en WSNs es plantear el uso de protocolos de transporte tradicionales (p. ej. TCP). Pese a que TCP ofrece ventajas en cuanto a interoperabilidad, exhibe un rendimiento subóptimo en
WSNs y su implementación es compleja. Una posibilidad para WSNs conectadas a Internet es emplear un elemento de traducción de protocolos, de
modo que se pueda usar un protocolo adecuado de transporte para el
tramo WSN y TCP en el tramo del resto de Internet).
Dadas las desventajas de TCP en WSNs, se han diseñado numerosos protocolos de transporte para estos entornos. Se pueden clasificar en tres grupos: i) protocolos que ofrecen control de congestión, ii) protocolos que ofrecen fiabilidad y iii) protocolos que ofrecen ambos servicios.
Los protocolos de control de congestión para WSNs (p. ej. CODA, Fusion,
CCF, etc.) emplean técnicas como la monitorización de las colas para detectar situaciones de congestión. Tras detectar la congestión, los protocolos
citados notifican tal situación a la fuente mediante mensajes y/o flags activados en mensajes que son transmitidos a la fuente. Se pueden emplear distintas técnicas para ajustar la tasa de transmisión de información, como
AIMD, o bien ajustes exactos de tasa.
Los protocolos que ofrecen fiabilidad (p. ej. RMST, RBC, PSFQ) emplean
distintas técnicas para la detección de pérdidas de datos, como el uso de
NACKs, ofreciendo la posibilidad de recuperar los errores en cada salto, o
bien extremo a extremo. PSFQ ofrece fiabilidad en sentido downstream, esto
es, de nodo sumidero a los nodos sensores. RBC y PSFQ ofrecen fiabilidad
en sentido upstream.
40
6/9/10
09:58
Página 41
Algunos protocolos como STCP y ESRT ofrecen fiabilidad y control de
congestión. STCP ofrece mecanismos de fiabilidad variable según los requisitos de las aplicaciones, mientras que ESRT se emplea para garantizar la fiabilidad a nivel de evento.
9.
Seguridad
La naturaleza de las comunicaciones inalámbricas abre la puerta a multitud de ataques de seguridad. Las WSNs no constituyen una excepción a
este hecho. Por ejemplo, la introducción de mensajes malintencionados en
una WSN para un entorno industrial, o para un entorno doméstico, puede
causar problemas graves.
Los mecanismos de seguridad como cifrado y autentificación o integridad se basan en métodos criptográficos. Estos mecanismos requieren capacidad de proceso y contribuyen de manera significativa al tamaño del código de las implementaciones. Por tanto, existe un compromiso entre los
mecanismos de seguridad y las capacidades hardware de los dispositivos,
las cuales son limitadas en WSNs.
El estándar IEEE 802.15.4-2003 define ocho suites de seguridad, con distintos servicios y prestaciones de seguridad en cada una. Tales suites son las
mostradas en la Tabla 3. El algoritmo criptográfico empleado en las suites
indicadas es el AES.
41
6/9/10
09:58
Página 42
Sensors Everywhere
Servicio de seguridad
Grupo de
Nombre de Control Cifrado Autentificación Protección
seguridad
la suite de acceso
e integridad
frente a
de trama retransmisión
Sin seguridad Sin seguridad
No
No
No
No
Sólo cifrado
AES-CTR
Sí
Sí
No
Sí
Sólo
AES-CBCSí
No
Sí
No
autentificación MAC-128
/integridad
AES-CBC
Sí
No
Sí
No
-MAC-64
AES-CBCSí
No
Sí
No
MAC-32
Cifrado más AES-CCM-128
Sí
Sí
Sí
Sí
autentificación AES-CCM-64
Sí
Sí
Sí
Sí
/integridad AES-CCM-32
Sí
Sí
Sí
Sí
Tabla 3. Suites de seguridad de IEEE 802.15.4
ZigBee ofrece servicios de seguridad en todas sus capas (desde la capa
física a la de aplicación). Entre otros, ZigBee ofrece servicios de seguridad en
cada capa equivalentes a las ocho suites de seguridad de IEEE 802.15.4. Una
característica importante de ZigBee es que ofrece una solución para la gestión de claves (servicio que no ofrece IEEE 802.15.4) y la inclusión de forma
segura de dispositivos en una red. La seguridad en una red ZigBee se basa
en el uso de claves de enlace (para la comunicación entre dos entidades) y
una clave de red (para las comunicaciones broadcast). No existe aún la funcionalidad equivalente para 6LoWPAN. Otras soluciones tecnológicas (p. ej.
Wavenis, Z-Wave, INSTEON) soportan el uso de algoritmos de cifrado.
10.
Sistemas operativos
Como ya hemos comentado, un nodo sensor dispone de un procesador
que debe ejecutar una serie de tareas que requieren el acceso al hardware
de elemento como la memoria, entradas/salidas y comunicaciones. El siste-
42
6/9/10
09:58
Página 43
ma operativo (SO) es un tarea más que permite coordinar el uso de los
recursos y que ofrece una interfaz con el hardware para hacerlo independiente de las aplicaciones que en el nodo sensor se ejecutan. Las funciones
básicas que el sistema operativo realiza son: gestión del procesador, gestión
de la memoria, gestión de los dispositivos, planificación de los tiempos de
ejecución y gestión de la ejecución de tareas concurrentemente.
Adicionalmente, es deseable que un sistema operativo ofrezca funcionalidades que faciliten la carga y descarga de código y que ofrezca un interfaz
para que las aplicaciones puedan acceder al hardware sin tener un conocimiento detallado del mismo. Para los sistemas operativos de nodos sensores, otra funcionalidad necesaria será la gestión de la energía con el objetivo de minimizar el consumo. Un sistema operativo es un programa de gran
importancia en cualquier elemento procesador, ya que facilita el desarrollo
de aplicaciones, pero no debe degradar las prestaciones que este elemento
procesador puede ofrecer. En entornos en los que recursos son amplios
este último requerimiento no es vital, pero para un nodo sensor en el que la
capacidad de proceso y memoria son extremadamente limitados, este
requerimiento es una necesidad. En un escenario distribuido como es una
red de sensores el sistema operativo puede ofrecer facilidades adicionales
relacionadas con ejecución distribuida de aplicaciones. Este aspecto se vincula generalmente con una aplicación de intermediación conocida como
middleware que se puede ubicar en un elemento de la red, como por ejemplo el nodo pasarela, y los nodos sensores. Algunos middleware son una
tarea más del nodo y en otros casos el sistema operativo incorpora estas
funcionalidades.
En la literatura podemos encontrar una gran variedad de sistemas operativos para nodos sensores. Algunos de ellos son adaptaciones de soluciones
existentes para plataformas de limitadas prestaciones y otros han sido desarrollados para nodos sensores. La clasificación de los sistemas operativos se
puede hacer en función de unas características básicas como son la arquitectura, la reprogramación, el modelo de ejecución y la planificación (scheduling) temporal.
La arquitectura de un SO se refiere a la organización del SO y de las aplicaciones que se ejecutan. Existe la arquitectura denominada monolítica
43
6/9/10
09:58
Página 44
Sensors Everywhere
(con SO y aplicaciones integradas en un programa), la modular y la basada
en máquina virtual. En esta última, el SO incorpora componentes de las aplicaciones que permiten hacer las aplicaciones más compactas y permite
esconder la red, esto es, que el desarrollador de aplicaciones pueda despreocuparse parcial o totalmente de los detalles de la red sobre la cual se ejecutarán las aplicaciones.
El modelo de ejecución de un SO indica de qué modo se ejecutan las
aplicaciones en el nodo. El más común es el basado en eventos, pero también encontramos el basado en hilos o threads. Para el primer caso, las aplicaciones generan eventos que son tratados uno detrás de otro. Existen otras
opciones, como la basada en máquina de estados.
La reprogramación hace referencia a la facilidad para modificar el software que se ejecuta en el SO. Este aspecto tiene especial interés en las redes
de sensores dada la posible inaccesibilidad de los nodos de red, en cuyo
caso se haría de forma remota.
En cuanto a la planificación temporal, el procesador se reparte entre las
diferentes tareas. Las formas más comunes en redes de sensores son periódica/no periódica y crítica/no crítica. Por ejemplo, una medida de temperatura es periódica, una generación de una alarma es no periódica.
Existe una gran variedad de sistemas operativos en la literatura. Los que
podemos considerar que gozan de mayor aceptación son el TinyOS,
FreeRTOS y Contiki. Todos ellos son de código abierto.
11.
Arquitecturas y tecnologías
En la última década, las WSNs han focalizado la atención de círculos académicos y también han suscitado el interés por parte de compañías privadas, alianzas de empresas y organismos de estandarización. Algunas soluciones para WSNs han sido desarrolladas para aplicaciones específicas,
mientras que otras han sido diseñadas para un propósito general.
Las principales soluciones que podemos considerar de propósito general son ZigBee, 6LoWPAN y Bluetooth Low Energy (BT-LE). Tanto ZigBee
44
6/9/10
09:58
Página 45
como 6LoWPAN emplean la tecnología IEEE 802.15.4 para las capas física y
MAC. ZigBee define su propia pila de protocolos, ofreciendo funciones de
red y aplicación, además de funciones de seguridad en todas las capas.
ZigBee dispone de varios perfiles que permiten configurar de forma óptima
el estándar para distintos entornos y aplicaciones (gestión inteligente de la
energía, automatización de edificios y doméstica, aplicaciones de salud,
etc.). Por su parte, la suite 6LoWPAN consiste en el conjunto de mecanismos
que permiten la transmisión de paquetes IPv6 sobre redes IEEE 802.15.4.
6LoWPAN se puede complementar con el protocolo de encaminamiento
RPL, que está en desarrollo. Finalmente, BT-LE permite definir enlaces de
bajo consumo con respecto a Bluetooth. Sin embargo, la especificación BTLE no define cómo formar redes multi-salto.
Existen varias tecnologías en el mercado desarrolladas especialmente
para la automatización y control de residencias y edificios. En este ámbito,
podemos destacar Z-Wave, Wavenis, EnOcean, INSTEON y One-Net. Z-Wave
consiste en una arquitectura completa de cinco capas basada en una interfaz radio propietaria. Wavenis ofrece funcionalidad de capa física, enlace y
red, y ha sido diseñada para enlaces de largo alcance y aplicaciones de recolección de smart utility. EnOcean se orienta a la automatización de edificios
y emplea mecanismos autosuficientes de recolección de energía (a partir de
fenómenos físicos que acontecen en el propio entorno) para alimentar a sus
dispositivos. INSTEON define una red que puede emplear enlaces inalámbricos y cableados (a través de la red eléctrica) para la transmisión de información en entornos domésticos.
Además, existen soluciones de WSNs para la automatización y control
industrial. Cabe destacar el protocolo TSMP, que constituye la base de los
estándares WirelessHART e ISA100.11a. TSMP emplea diversidad en frecuencia y en tiempo para el acceso al medio, incluye mecanismos de encaminamiento y también de seguridad. WirelessHART emplea la capa física y
el formato de trama MAC de IEEE 802.15.4, mientras que ISA100.11a
emplea las capas física y MAC de IEEE 802.15.4-2006 y define el uso de
6LoWPAN a nivel de red.
Finalmente, existen otras soluciones como SensiNet, Xmesh, ANT,
DigiMesh, AmbioSystems o Ambient Systems.
45
6/9/10
09:58
Página 46
Sensors Everywhere
12. Gestión de los datos obtenidos por las WSNs
Las WSNs tienen una gran capacidad de recolección de datos, pero tales
datos deben ser enriquecidos con información adicional de contexto para
poder transformarlos en información. Esta información adicional puede
incluir el instante en el que se obtiene un dato, la localización del nodo sensor correspondiente, el tipo de atributo, etc. Sin embargo, los metadatos que
permiten enriquecer a los datos suelen requerir cantidades elevadas de
bytes para ser codificados, y por otra parte, consumen recursos de los dispositivos, los cuales son limitados en WSNs. Una posible solución a este problema consiste en emplear formatos de metadatos compactos. Otra opción
es que algunos nodos intermedios se encarguen de añadir metadatos a la
información bruta recogida por los nodos sensores.
En WSNs es interesante minimizar el número de transmisiones, para ahorrar
energía y ancho de banda. Para ello, existen técnicas de agregación de datos que
consisten en que algunos nodos sensores comparen la información obtenida
por sus nodos vecinos, y que sólo se transmita hasta el sumidero correspondiente la información imprescindible, evitando transmitir datos redundantes.
Finalmente, los datos, junto con sus metadatos, pueden ser almacenados de
manera eficiente en una base de datos, para su posterior análisis.
Existen aplicaciones de las WSNs donde la información recogida por los
distintos sensores no es obtenida en tiempo real. En tales aplicaciones, los
datos deben ser temporalmente almacenados en la red. Para ello, se definen protocolos de almacenamiento colaborativo en la propia red, que permiten llevar a cabo tareas de agregación y de eliminación de la redundancia
de los datos obtenidos.
El protocolo XML es el estándar de facto para el intercambio de información estructurada en la Web. Existen diversas adaptaciones de XML para su
uso en WSNs. Algunos ejemplos son BXML, EXI, EEML y SensorML.
Por otra parte, la iniciativa Sensor Web ha sido creada por el OGC y la
Semantic Web Activity del W3C para proporcionar descripciones mejoradas
y significado a los datos recogidos por sensores y para facilitar su transporte a través de Internet. De hecho, el OGC ha establecido un conjunto de
46
6/9/10
09:58
Página 47
especificaciones relacionadas con sensores, modelos de datos de sensores
y servicios web para sensores, de forma que los nodos sensores sean accesibles y controlables a través de la web.
Cabe destacar también el estándar IEEE 1451, que fue desarrollado para
facilitar la conectividad entre sensores y actuadores con un sistema central
de información. Adicionalmente, IEEE 1451 soporta tecnologías para lograr
la conectividad remota. De hecho, IEEE 1451 constituye un conjunto de
interfaces para transductores inteligentes con facilidades para la auto-identificación, auto-descripción, auto-diagnóstico, auto-calibración, formato de
presentación estándar y protocolos de comunicaciones.
13.
Interoperabilidad
Las WSNs requieren conectividad con otras redes por varias razones que
incluyen el control remoto, el acceso remoto a los datos recogidos, actualizaciones de software de los nodos sensores, etc. Pese a que existen opiniones en contra de las arquitecturas basadas en capas para WSNs, tales arquitecturas pueden ser ventajosas en términos de interoperabilidad dado que
las redes convencionales emplean este mismo principio.
La principal red con la cual resulta interesante poder conectar una WSN
es Internet. Existen varias propuestas para lograr tal objetivo. Sin embargo,
muchas WSNs emplean protocolos especiales, no estandarizados. En tales
condiciones, no es posible conectar una WSN con una red IP. Se han propuesto dos opciones para resolver este problema: el uso de la arquitectura
DTN (que no está teniendo una aceptación mayoritaria en la comunidad
interesada en las WSNs) y el empleo de un proxy o pasarela de traducción
de protocolos entre la WSN y la red IP. Un enfoque distinto, que está adquiriendo relevancia a medida que la tecnología evoluciona, es conectar directamente la WSN a una red IP mediante el uso de una pila IP en los propios
nodos sensores. Este esquema facilita además la inclusión de WSNs en el
entorno IMS (IP Multimedia Subystem).
Un gateway de traducción de protocolos es un dispositivo que soporta
dos o más interfaces físicas y la semántica y funcionalidad de dos o más
47
6/9/10
09:58
Página 48
Sensors Everywhere
pilas de protocolos. Por ejemplo, un dispositivo de este tipo puede conectar
una red ZigBee con una red IP. Sin embargo, estos dispositivos exhiben algunas desventajas. Una de ellas es la falta de consistencia extremo a extremo,
la cual dificulta realizar tareas como el transporte o la calidad de servicio de
forma eficaz. De hecho, los dispositivos de traducción de protocolos pueden
emplear el principio del “mínimo común denominador” para permitir la interoperabilidad de las distintas tecnologías que comunican. Por otra parte,
dado que la WSN y la red IP a la que se conecta constituyen dominios distintos, existen mayores riesgos a nivel de seguridad, puesto que a cada lado
de la pasarela existe una esfera de seguridad distinta.
En cambio, el empleo del protocolo IP en los propios nodos sensores
tiene numerosas ventajas. El protocolo IP es un buen protocolo para la interoperabilidad entre redes distintas (tal y como ha demostrado durante varias
décadas). Es un protocolo universal en términos de la variedad de aplicaciones, dispositivos, sistemas operativos y tecnologías de red que soporta.
Además, IPv6 ofrece características adecuadas para las WSNs, como una
gran disponibilidad de direcciones y facilidades para la autoconfiguración de
dispositivos.
Cabe destacar la tendencia que distintas soluciones comerciales de
WSNs (p. ej. ZigBee, Z-Wave y Wavenis) han mostrado al manifestar su interés por adoptar los protocolos IP en sus especificaciones.
Existen propuestas para plantear una interoperabilidad de redes a
nivel de sesión. Una de ellas (TinySIP) está basada en el uso de SIP como
mecanismo de intercambio de información de estado usando el paradigma de PUBLISH/SUBSCRIBE. Otra propuesta usa el XMPP (eXtensible
Messaging and Presence Protocol) desarrollada originalmente por la
comunidad de código abierto Jabber. Este protocolo es la alternativa a
SIP en la realización de aplicaciones de presencia que usa tres tipos de
comandos relacionados con la publicación/subscripción de un evento, la
transferencia de mensajes y el petición/información. OpenSpime de
WideTag usa este protocolo para en intercambio de información de los
sensores. Finalmente, existen otras iniciativas como el MQTT-S de IBM o
Pachube que también se basan en el paradigma de publicación y suscripción.
48
6/9/10
09:58
Página 49
14.
Consumo y recolección de energía
Un aspecto fundamental en el diseño y despliegue de WSNs es el consumo de energía de los nodos. Las soluciones tradicionales basadas en el
empleo de baterías, o bien de conectar los nodos a la red eléctrica (cuando
ésta esté disponible) son soluciones viables sólo para un conjunto limitado
de usos. Para una aceptación amplia de las WSNs, una vez se ha emplazado
un nodo en una WSN, éste debería poder operar de manera no atendida,
mientras que el recambio de su batería puede ser una opción inviable o
poco práctica. Las limitaciones de energía de las WSNs dan lugar a una serie
de principios de diseño distintos a los que habitualmente existen en las
redes tradicionales.
El elemento que contribuye en mayor medida al consumo de energía de
un nodo sensor es la comunicación del mismo (tanto la transmisión como
la recepción de señales). El procesado de datos también consume energía,
pero en una medida muy inferior. De ello se deduce que es preferible procesar la información de que se dispone si con ello se ahorran bytes a transmitir.
Es destacable el hecho de que, para determinadas potencias de transmisión, un nodo sensor puede consumir más energía en recepción que en
transmisión. De todos modos, la potencia empleada en las comunicaciones
depende linealmente de la frecuencia con la cual se realizan transmisiones
y recepciones. Por otra parte, los periodos de preparación para que un transceptor pase de modo inactivo a activo también consumen energía y no
deben menospreciarse.
Se pueden emplear dispositivos de almacenaje de energía para alimentar a los nodos de una WSN. Estos dispositivos pueden ser baterías primarias
(como las que se emplean para alimentar electrodomésticos habituales) o
secundarias (estas últimas son baterías recargables), o bien los denominados supercondensadores.
Pese a que se está realizando un esfuerzo importante por reducir el consumo energético de los nodos sensores, se están considerando fuentes de
energía alternativas para maximizar el tiempo de vida de los nodos de una
49
6/9/10
09:58
Página 50
Sensors Everywhere
WSN. En particular, se está considerando la obtención de la energía que
puede existir en el ambiente. Algunas posibles fuentes de energía son la
radiación solar, la energía mecánica (el movimiento, la presión o la vibración), los gradientes de temperatura, los flujos de viento y/o líquido y la
radiación electromagnética ambiental. Este tipo de fuentes ofrecen niveles
de potencia bajos, variables y difíciles de predecir, dada su naturaleza.
Además, en muchos casos, requieren el uso de extensiones aparatosas y
caras. Sin embargo, existen dispositivos comerciales que incorporan una
placa solar para su alimentación (p. ej. el nodo Eko de Crossbow), o productos como los ofrecidos por EnOcean, que constituyen soluciones auto-alimentadas de WSNs.
15.
Localización en redes de sensores
Un nodo sensor es capaz de obtener una o varias magnitudes físicas
como la temperatura o humedad de un determinado punto o lugar. Este
valor debe ser interpretado en el momento de su captura o en una fecha
posterior. En cualquiera de los dos casos, cuanta más información de contexto de la medida se tenga, mejor podrá ser la interpretación de la misma.
Por ejemplo, si las medidas son de sensores próximos es lógico pensar que
estén correladas. Una de las informaciones de contexto más interesantes es,
sin duda, la localización física del sensor. De hecho, la propia localización se
puede ver como un dato que el sensor puede ofrecer.
La localización puede ser física (las coordenadas geográficas, distancia…)
o lógica (en la tercera planta del edificio C3, del campus Norte de la universidad). Para poder conocer la localización de un nodo se debe disponer de
referencias. Si estas referencias son absolutas, la localización que se pueda
derivar será absoluta. Si son relativas, se conseguirá una localización relativa. Una de las técnicas de localización física absoluta más utilizada es el sistema GPS, pero a pesar de los avances en la reducción de consumo de los
receptores de GPS, no es una solución que atienda las necesidades de la
localización en redes de sensores. La limitada precisión, el no poder funcionar en interiores y el mencionado consumo hacen que esta solución sea
inapropiada en la mayoría de los casos. Para su uso en redes de sensores se
50
6/9/10
09:58
Página 51
debe considerar el bajo coste y consumo, la limitada capacidad de comunicación y proceso, y la posibilidad de usarse en interiores.
La localización se puede obtener por métodos de proximidad, de posicionado o por patrones (fingerprinting). La proximidad consiste en asociar la
localización del sensor con la de la referencia a la que se encuentra más
próximo. El posicionado trata de determinar las coordenadas del objeto.
Para este propósito se pueden usar distancias, ángulos o combinaciones de
ambos. Una localización en tres dimensiones precisa de tres de estas magnitudes. La medida de distancias y ángulos depende del tipo de señal física
que se maneje. La localización por clasificación se basa en asociar patrones
de señales a localizaciones.
Las señales habitualmente usadas en redes de sensores para localización son señales radio, infrarrojos y ultrasonidos. La señal radio es la propia
señal disponible del interfaz de comunicación, mientras que las otras dos
son señales especificas que se deben que se deben transmitir y recibir,
empleando los “sensores” correspondientes.
La localización por proximidad consiste en recibir señales de una o varias
referencias y decidir que se está localizado en la referencia de la que se recibe mayor nivel de señal. Normalmente se usan señales radio o infrarrojos
para este tipo de localización.
La localización por posicionado se realiza básicamente con señales radio
y con ultrasonidos. Los ultrasonidos presentan una velocidad de propagación lenta (330 m/s) para la cual es fácil medir tiempos absolutos o diferencias de tiempos con los relojes convencionales existentes en lo nodos sensores. Estos tiempos pueden ser convertidos en ángulos de llegada de la
señal y distancias que a su vez nos dan la posición respecto las referencias.
Los ultrasonidos se ven confinados entre paredes, su alcance puede llegar a
la quincena de metros y los transmisores son directivos, por lo que una localización en cualquier punto exige un número de referencias mínimo de tres
por habitación. Por contrapartida, ofrecen precisiones de centímetros. Para
las señales de radio basadas en IEEE 802.15.4, lo más común es usar la relación entre atenuación y distancia para estimar la separación a una referencia. Con tres distancias a diferentes referencias se puede ofrecer una posición. Dado que hay otros efectos que afectan a la atenuación, la estimación
51
6/9/10
09:58
Página 52
Sensors Everywhere
de la distancia puede tener errores de varios metros si no se aplican técnicas de corrección, por ejemplo la medida del tiempo de vuelo de la señal
radio es una técnica que puede mejorar la precisión. Para poder conseguir
medidas de distancias basadas en tiempo de vuelo con precisiones de centímetros, se desarrolló en interfaz radio IEEE 802.15.4a, pero por el momento no existen productos comerciales que lo implementen.
La localización por patrones emplea principalmente señales radio.
Consiste en tener un número de referencias que transmiten diferentes señales (generalmente a diferente frecuencia) que cubren el espacio en el que se
quiere hacer la localización. Los transmisores se ubicarán de modo que en
cualquier punto se reciban varias señales. En una primera fase de funcionamiento el sistema debe ser entrenado creando una base de datos con las
localizaciones y las señales y niveles recibidos en ese punto. En funcionamiento el dispositivo a localizar debe medir de forma continua las señales del sistema y reportar a un elemento central estos niveles. Este elemento intenta
buscar coincidencias entre las medidas reportadas y las almacenadas en la
base de datos para las distintas posiciones. La localización de la base de datos
que mejor se ajuste al conjunto de medidas será la localización asignada al
objeto. Este método ofrece una precisión que depende del detalle de la calibración realizada y del número de señales de señales de referencia. Requiere
calibración en caso de que se vea modificada la propagación de señales. Los
sistemas existentes ofrecen precisiones de varios metros.
Para el caso de querer localizar un nodo sensor cuando no se tiene de
forma directa el número de referencias necesario es posible usar localizaciones mutuas o derivadas. Se trata de localizar un conjunto de nodos sensores a partir de un número limitado de referencias y las localizaciones relativas que efectúan los nodos sensores entre ellos. Existen diferentes algoritmos, pero resultan complejos para las prestaciones de los sensores.
16.
Middleware
En el ámbito de los sistemas distribuidos es común usar un software
específico para facilitar el desarrollo de aplicaciones. Este software se inter-
52
6/9/10
09:58
Página 53
pone entre el sistema y la aplicación por lo que recibe el nombre de middleware. Este software puede realizar funciones diversas que faciliten la gestión de la red, la mejora de la fiabilidad, la calidad de servicio, la gestión de
los datos y de la energía entre otras. De forma simplista podríamos decir que
el middleware es “el pegamento” que une el hardware, el sistema operativo
del nodo sensor, la propia red de sensores, su relación con el mundo exterior (conectividad, bases de datos, desarrolladores o programadores, usuarios, etc) y la aplicación o aplicaciones que realiza todo el sistema.
Una red de sensores, como sistema distribuido, tiene una serie de características que lo diferencian de los sistemas distribuidos clásicos. Los nodos
sensores tienen limitaciones (memoria, procesador, enlace y alimentación)
que recomiendan una programación a bajo nivel para poder obtener el
máximo de prestaciones. Como resultado el middleware en una red de sensores debe diferenciarse del de los sistemas middleware clásicos en:
• No hacer la aplicación independiente del escenario en el que se usa.
El middleware clásico esconde el entrono a la aplicación. En una red
de sensores necesitamos captar el entorno y por ello no queremos
que lo esconda.
• Incorporar elementos intermedios. Las soluciones tradicionales de
middleware asumen una comunicación extremo a extremo. En las
redes de sensores elementos como el sumidero o la pasarela son elementos que realizan funciones en la comunicación entre sensor y
aplicación.
• Simplicidad en la parte software del nodo sensor. Las soluciones
middleware añaden funcionalidad a costa de software adicional y
comunicaciones. Dadas las limitaciones del nodo se deben hacer diseños lo más ligeros posible en esta parte del sistema.
El middleware como concepto tiene diversas implementaciones que
cubren algunos de los aspectos que hemos citado como requerimientos y
que se pueden realizar de diferentes formas. Una solución middleware completa debe ofrecer una abstracción al programador, funcionalidades que
ayuden al programador, extensiones en el sistema operativo de los nodos y
calidad de servicio.
53
6/9/10
09:58
Página 54
Sensors Everywhere
La abstracción de programación incluye una visión del sistema, cómo se
interactúa con el middleware y con qué interfaces. La visión puede ser con
respecto a la red o al nodo, y la interacción puede ser básicamente como
con una base de datos o como una maquina virtual. De hecho la elección
de una u otra depende del propósito de la red de sensores. Por último el tipo
de interfaz puede ser descriptivo (indicando qué información se desea) o en
base a comandos.
Las extensiones del sistema operativo pueden ser relativas a las comunicaciones entre procesos, la planificación de tareas, gestión de memoria y de
potencia consumida.
La calidad de servicio en las redes de sensores amplía la acepción tradicional de este término. Se consideran aspectos como la entrega de datos, retardo de agregación o vida del sistema como parámetros de calidad de servicio.
En lo relativo a los servicios que ofrece el middleware, se pueden detallar los siguientes ejemplos:
• Gestión del código. Se trata de colocar en cada nodo el software adecuado para que el nodo realice la función. Este código debe ser cargado, instalado y actualizado si es necesario. Idealmente el código
podría ser el mismo para diferentes nodos, pero en una red de sensores los requerimientos de prestaciones obligan a trabajar a bajo nivel y
por ello a tener distintos códigos para distintos nodos.
• Gestión de datos. Una de las funciones de una red de sensores es la
recogida de datos lo implica un proceso de datos y un almacenamiento. Aquí nuevamente las restricciones de proceso, y en particular las
de comunicación, hacen que el compromiso proceso – comunicación
sea diferente al de los sistemas convencionales. La posibilidad de
agregar datos introduce un grado más de diferenciación.
• Descubrimiento de nuevos nodos y recursos.
• Gestión de recursos del sistema. Se especifica que nodos realizan ciertas funciones y como se mueven los datos entre los diferentes nodos.
• Integración. La red de sensores no será en la mayoría de los casos un
sistema aislado. Se deberá poder interconectar por Internet con otros
54
6/9/10
09:58
Página 55
sistemas. El middleware puede ofrecer las funcionalidades de proxy
que adapte protocolos, un interfaz de base de datos tipo SQL o un servicio web.
• Seguridad. Aspectos como la gestión de claves son tareas que puede
realizar el middleware en el ámbito de la seguridad.
La mayoría de soluciones de middleware analizadas en este libro sólo
realizan parte de los servicios que hemos descrito y por ello son soluciones
parciales al problema que motiva el middleware. En la actualidad se reconoce la importancia del middleware en las redes de sensores.
17.
Direcciones futuras
Se han identificado cinco áreas o líneas de trabajo e investigación relevantes de cara al futuro relacionadas con las redes de sensores.
La primera de ellas consiste en constatar la realidad de que cada vez más
y más sensores están y estarán realizando determinadas funciones en nuestro entorno físico próximo (p. ej. tanto en la ropa u objetos que podamos llevar
encima, como en los terminales móviles, como en la infraestructura próxima
que nos rodea- edificios, farolas, etc.- en las ciudades). Las redes de sensores
pueden ser el catalizador que aglutine toda esa información obtenida, facilite
que se pueda poner en contexto y a partir de ella se puedan extraer servicios
enriquecedores e innovadores para las personas o empresas.
La segunda línea de trabajo estará centrada en los propios nodos sensores, al objeto de conseguir que su rendimiento sea mejor (capacidad de procesado y de transmisión / recepción de datos) al tiempo que se consuma
poca energía. Así, un aspecto importante será el de las fuentes de energía
alternativas procedentes del propio entorno que palien los problemas de alimentación de los nodos sensores, que deben ser baratos y deben poder
estar, en el peor caso, proporcionando servicios durante años en entornos a
veces hostiles o de muy difícil acceso.
Pero el mercado y las oportunidades de negocio entorno a las redes de
sensores (como habilitadoras de nuevos servicios) no serán una realidad si
55
6/9/10
09:58
Página 56
Sensors Everywhere
no se consigue superar el problema de un ecosistema (tecnologías y protocolos) excesivamente fragmentado en el que no aparezcan estándares de
referencia. Por tanto, la tercera línea de actuación debería ir en este sentido.
En cuarto lugar, las soluciones de inter-conexión con el mundo exterior
para poner en valor esa información procedente de las redes de sensores
precisan de una evolución de las tecnologías existentes hacia aproximaciones estándar, ampliamente aceptadas, típicamente basadas en el protocolo
IP. IETF está trabajando en ello desde hace algún tiempo (p. ej. en los grupos
de trabajo 6LoWPAN y ROLL), y ya se puede decir que existen soluciones de
redes de sensores sobre IP que ofrecen un buen rendimiento. De hecho
algunas organizaciones de referencia en el sector (que desarrollan sus propios estándares inicialmente no-IP), como por ejemplo ZigBee o Z-Wave, ya
han anunciado que están evolucionando sus soluciones hacia una pila de
protocolos que incluirá IP (IP stack). Este será un pilar fundamental sobre el
que se pueda construir la “Internet de las Cosas”, cuya visión quedó establecida por la UIT hace algunos años, y que muy básicamente consiste en vislumbrar que a partir de un determinado momento empezará a haber
muchas más máquinas que personas inter-conectadas (p. ej. a través de
Internet), y gran parte de ellas podrían ser nodos de una red de sensores.
En quinto y último lugar, el desarrollo de una gran cantidad de aplicaciones entorno a la información obtenida desde las redes de sensores debería
ser habilitado por la existencia de un marco de trabajo adecuado que facilitase el desarrollo de servicios innovadores, y que puede pasar por aproximaciones de middleware y plataformas “horizontales”, alineadas con el modelo exitoso de la web 2.0 actual, en contraposición a aproximaciones “verticales” que afrontan nichos de mercado concretos y que ofrecen soluciones
propietarias.
A un plazo más largo, se puede pensar en las siguientes generaciones de
las redes de sensores en las que los nodos sensores estén embebidos en las
cosas y personas. En este punto se puede hablar de la redes de sensores en
las superficies, en la materia y en las personas. En este contexto se necesitarán nuevos paradigmas de funcionamiento.
56
6/9/10
09:58
Página 57
1
Introducción to Wireless
Sensor Networks
6/9/10
09:58
Página 58
6/9/10
09:58
Página 59
Chapter 1. Introduction to Wireless Sensor Networks
1. Introduction to Wireless Sensor
Networks
This chapter introduces the main concepts concerning Wireless Sensor
Networks (WSNs). The chapter is organized as follows: Section 1.1 provides
the definition of the main devices that can be found in a WSN [8]; Section 1.2
describes the main characteristics of WSNs; Section 1.3 introduces the
architecture of a sensor node, and finally, section 1.4 presents the main WSN
architectures, including network topologies and communication protocol
solutions.
1.1.
Elements of a WSN
A WSN is a wireless network of wireless sensor nodes (that may interact
which each other) aimed at monitoring real world physical parameters (in
many cases, covering a certain geographical area) and offering the sensed
data to one or more data collection elements. In some cases, the same elements of a WSN can be used to activate actuators in order to perform certain tasks in response to an event or to exceed a predefined threshold for a
certain parameter.
Sensor nodes are devices that account with at least one sensor and may
include actuators as well as having processing and networking capabilities
to process data and use the wireless access.
Sensors are devices included in the sensor nodes. Sensors measure the
physical property and quantity of an observation, converting the measure-
59
6/9/10
09:58
Página 60
Sensors Everywhere
ment into a signal that may be electrical (e.g. current, voltage, power, resistance, etc.), mechanical (e.g. pressure, flow, liquid density, humidity, etc.),
chemical (e.g. oxygen, carbon monoxide, etc.), acoustic (e.g. noise, ultrasounds, etc.), or any other signal type. Other parameters which can be
sensed include the identification of a device or its location.
Actuator nodes are devices with wireless communications and processing capabilities which include at least one actuator.
Actuators are devices that can carry out an action (e.g. a physical response such as turn on a light, trigger an alarm, turn off an irrigation system,
etc.) in response to a certain stimulus (caused by an input signal).
Typically, sensors are small, low-cost, and low-power consumption devices requiring a limited amount of information transfer. However, a wider
concept may include microphones, GPS-receivers or cameras as sensors.
Furthermore, even a satellite system can be considered as a “sensor device” [7].
In data collection applications, there exist one or more sink nodes, which
are special nodes in charge of gathering, processing and controlling the
received data from a set of sensor nodes.
WSNs can be stand-alone networks, but it may be interesting to connect
them to other networks (e.g. the Internet) for remote access and management. In this case, connectivity between the WSN and another network can
be achieved by means of a Sensor Network Gateway,
WSN technology opens the door to a wide range of control and monitoring Sensor Network Applications (or use cases) in a large spectrum of
environments, such as home automation, building automation, industrial
automation, environmental monitoring, urban monitoring, etc. (see
Chapter 2).
1.2.
General characteristics of WSNs
A WSN can be as small as a two-node network or as large as a ten-million
nodes network [1]. The actual network size will depend on each particular
60
6/9/10
09:58
Página 61
application and deployment, but it is assumed that, in general, a WSN is
composed of a large number of nodes.
An important feature of WSNs is their unattended operation. Some reasons for this include the possibly large number of nodes and the fact that
some WSNs may be placed in zones where access is difficult.
In many applications, the nodes may only obtain their power from a battery1. In this way, network deployment is easy and independent of power
supply availability. However, battery replacement may not be practical or
even possible. In consequence, energy conservation is a primary goal in
WSN design, as the nodes will only operate before battery depletion.
In contrast with many other networking technologies, WSNs exhibit
relaxed bandwidth requirements. In fact, in many applications, the data
collected by a sensor (e.g. a temperature measurement) can be encoded
using a reduced number of bytes and transmitted at a low rate (e.g. once per
minute). However, the actual data transmission rate depends on each application, and some applications may exhibit low latency requirements (e.g. a
light is turned on when the user presses a button in a remote control).
The nodes in a WSN use wireless communication technology, which
offers greater flexibility and lower deployment costs than wired technology.
As the transmission range of a node is limited (see Chapter 3), a multi-hop
communication solution is needed so that nodes can route data on behalf
of other nodes and enable the transmission of data between two nodes that
are not within the transmission range of each other. Typically, WSNs are
multi-hop networks. On the other hand, there exist various radio propagation impairments (see Chapter 3) which make the quality of a wireless link
uncertain and variable in comparison with that of a wired link. This is an
important feature that WSN communication protocol design must take into
account.
Wireless sensor nodes are typically constrained devices, which exhibit low
processing power and low memory storage capacity. Some examples include
1
Another option is to harvest energy from the environment-,( see Chapter 14), but this
option does not provide an unconstrained energy supply.
61
6/9/10
09:58
Página 62
Sensors Everywhere
8-bit, 16-bit and 32-bit processors running at tens of MHz and RAM sizes from
1 kB to 256 kB [2]. Hence, the protocols running in WSNs must be lightweight.
This is challenging, as the large number of devices and unattended operation
of WSNs pose additional constraints to the networking solutions.
Some WSNs are mainly static (e.g. a set of nodes deployed in a forest).
However, the dynamics of wireless communications make the network conditions quite variable. On the other hand, in some scenarios, the nodes may
exhibit a certain degree of mobility (e.g. a remote control, on-body sensor
nodes, sensors attached to vehicles, etc.). Thus, the WSN protocols must be
self-healing and capable of operating in the presence of topology changes.
1.3.
Sensor node architecture
This section overviews the architecture of a sensor node from the hardware (subsection 1.3.1) and software (subsection 1.3.2) points of view.
1.3.1. Hardware
A sensor node is typically a small-sized, autonomous sensing and communication system. One of the seminal projects in the WSN field was the
Smart Dust project [3], which started in the late nineties with the aim of
developing a cubic millimeter sensor node. Most current sensor node hardware platforms have a larger size, but are still called motes, which is the
name given to the devices developed by the Smart Dust project. In fact, the
small size of sensor nodes is practical, cost-effective, and approaches WSNs
to the concept of invisible, ambient intelligence. However, the node size
poses constraints on the hardware capabilities of the devices, which affect
communication protocol design on top of WSNs.
Fig. 1.1 shows the main components of a sensor node: processor, transceiver, memory, power source, transducers and, if necessary, analogue to
digital converters (ADCs). A transducer2 refers here to a sensor device which
2
A transducer may either be a sensor or an actuator.
62
6/9/10
09:58
Página 63
generates a signal (e.g. an electrical one) that depends on a parameter of
the environment.
Fig. 1.1. Architecture of a sensor node
Chapter 5 provides more detail on the hardware elements of a sensor
node and the features of the main platforms available on the market.
1.3.2. Software
Sensor nodes run special operating systems, communications protocols,
management functionality and applications on top of them.
The operating systems have been specifically developed for the particular characteristics of sensor nodes. As already mentioned, the hardware platforms on top of which these operating systems run are constrained. Hence,
these operating systems have been developed under the goals of simplicity
and efficiency. Some of them are also adequate for event-detection applications, which are common among WSN applications. Chapter 10 further elaborates on the characteristics of the operating systems developed for constrained devices such as sensor nodes.
From a certain point of view, the applications running on a sensor node
require a correct operation of the node and the network in terms of quality
of service, data management and energy management. This software functionality as a whole is sometimes referred to as middleware (see Chapter
16).
63
6/9/10
09:58
Página 64
Sensors Everywhere
1.4.
WSN architectures
This section presents the main network architecture paradigms of WSNs.
First, the main topologies used in WSNs are introduced in subsection 1.4.1.
Then, subsection 1.4.2 discusses the use of a layered protocol stack in
WSNs. Finally, subsection 1.4.3 introduces the protocols needed in WSNs.
1.4.1. WSN topologies
This subsection presents some of the main topologies that can be found
in WSN solutions. These topologies are: star topology, tree topology and
mesh topology. In some cases, combinations of these topologies are also
supported by WSN solutions.
1.4.1.1. Star topology
In the star topology, there exists a central node which has communication links with the other nodes (see Fig. 1.2). The central node plays an
important role, as it may act as a controller scheduling the transmissions of
the rest of nodes; it may route data between nodes if necessary (note that
the largest paths will be composed of two hops), and it may also act as a sink
node. As the central node has greater functionality and importance than the
other nodes, it may not be as constrained as the others (e.g. in processing
power, memory storage, power supply, etc.).
Fig. 1.2. Star topology
64
6/9/10
09:58
Página 65
The star topology is suitable for small networks where the nodes have a
direct communications link with the central node. A drawback of this topology is its lack of path redundancy. In other words, there exists a single path
between any two nodes in the network. Given the dynamicity of wireless
links, when data cannot reach the destination through a certain path, the
communication cannot benefit from using other paths. Hence, the star
topology should be used in very specific, well-dimensioned scenarios.
1.4.1.2. Tree topology
In a tree topology (see Fig. 1.3.a)), each node has a communications link
with a parent node, which is the next hop in the path towards a special node
called the root. (Note that the root does not have parents.). The nodes that
have a certain parent are called the children of that parent. For example, in
Fig. 1.3.a), nodes 4 and 5 are children of node 1, which is their parent. In turn,
node 1 is a child of node 14, which is both the parent of nodes 1, 2 and 3
and the root of this tree topology.
The tree topology is adequate for data collection applications, whereby
the data have to be transmitted to a sink node. The root of the tree can be
the sink node. Communication between any two nodes is also possible in a
tree topology, but without additional mechanisms it can be suboptimal. For
example, in Fig. 1.3.a), the path followed by the data transmitted from node
10 to node 11 will be 10-5-1-14-3-8-11. This path is longer than the minimum possible path, which would be available in other possible network
topologies (see Fig. 1.3.b), for instance).
A strict tree topology is not robust to link failures (e.g. due to radio impairments, battery depletion, node mobility, etc.) because there exists a single
path between a node and the root. To increase path redundancy, some
topology variants have been considered in WSNs, including the possibility of
selecting more than one parent for a node, or to use siblings3 for forwarding
data (see subsection 7.3.2, Chapter 7).
3
A sibling node can be defined as a neighbour of a specific node, which has the same rank
in the topology but does not necessarily have the same parent as this node.
65
6/9/10
09:59
Página 66
Sensors Everywhere
Finally, note that the star topology is a particular case of a tree topology
where all nodes are one hop away from the tree root.
1.4.1.3. Mesh topology
In the mesh topology, nodes can communicate with all their neighbours
(i.e. the nodes that are within the coverage range of a certain node) and any
node can communicate with any other node if a path exists. Hence, this
topology exploits all the communications links that exist in a network (see
Fig. 1.3.b).
The mesh topology is suitable for applications where any node can communicate with any other node. In contrast with the star and tree topologies,
the mesh topology does not require the presence of special nodes.
Fig. 1.3. a) Tree topology; b) mesh topology
1.4.2. The layered protocol stack approach
Typically, many computer network protocol architectures follow the
layered approach, whereby a layer offers a set of services to the layer on top
of it. The well known Open Systems Interconnection (OSI) reference model
[4] proposes a layered protocol stack, and the Transmission Control
66
6/9/10
09:59
Página 67
Protocol/Internet Protocol (TCP/IP) stack constitutes a well known example
that follows the layered architecture [5].
The use of layers allows one layer to operate independently despite the
problems addressed by other layers. The layered approach has some overhead, which is not significant in devices with plenty of resources such as
desktops. However, about a decade ago, some researchers believed that the
resource constraints of sensor nodes might constitute a reason for abandoning the layered approach in WSNs [6].
As will be seen throughout the book (and especially in Chapter 11), the
main current WSN solutions follow the layered approach. Nevertheless,
cross-layer mechanisms, which use information from various layers to operate, have proved to be beneficial in many wireless systems. These include
WSNs, where the simplicity of the sensor node platforms makes it easy to
implement cross-layer mechanisms.
1.4.3. WSN protocols
Communication among devices in WSNs is enabled by the following
types of protocols:
• Physical layer protocols (see Chapter 3).
• Medium Access Control (MAC) protocols (see Chapter 4).
• Routing protocols (see Chapter 7).
• Transport protocols (see Chapter 8).
• Data encoding and aggregation protocols (see Chapter 12)
Additionally, there are important cross-layer services in WSNs such as
security (see Chapter 9) and topology control (see Chapter 6).
REFERENCES
[1] M. Dohler, T. Watteyne, T. Winter, D. Barthel, “Routing Requirements for
Urban Low-Power and Lossy Networks”, RFC 5548, May 2009.
67
6/9/10
09:59
Página 68
Sensors Everywhere
[2] E. Kim, D. Kaspar, N. Chevrollier, J.P. Vasseur, “Design and Application
spaces for 6LoWPANs”, draft-ietf-6lowpan-usecases-05, IETF Internet
Draft, November 2009 (Work in progress).
[3] Smart Dust project website:
http://robotics.eecs.berkeley.edu/–pister/SmartDust/
[4] H. Zimmermann, “OSI Reference Model – The ISO Model of Architecture
for Open Systems Interconnection”, IEEE Transactions on Communications, Vol. COM-28, No. 4, April 1980.
[5] R. Braden, “Requirements for Internet Hosts – Communication Layers”,
RFC 1122, October 1989.
[6] D. Estrin, R. Govindan, J. Heidemann, S. Kumar, “Next century challenges:
scalable coordination in sensor networks”. In MobiCom ’99: Proceedings
of the 5th annual ACM/IEEE international conference on Mobile computing and networking, pages 263–270, New York, USA, 1999.
[7] A. Sheth, “Semantic Sensor Web”, Intelligent Sensors, Sensor Networks
and Information Processing – ISSNIP, Melbourne, Australia, August 2008.
[8] “Technical Document on Sensor Networks (Version 3)”, Technical
Document of ISO/IEC JTC 1, Study Group on Sensor Networks (SGSN),
December 2009.
68
6/9/10
09:59
Página 69
2
Applications of WSNs and
standardization initiatives
6/9/10
09:59
Página 70
6/9/10
09:59
Página 71
Chapter 2. Applications of WSNs and standardization initiatives
2. Applications of WSNs and
standardization initiatives
The range of WSN applications is huge. On the other hand, future predictions are indicating that “In the next 10 years, many more devices and
machines than humans will be connected to the Internet”; or in other words,
"The number of elements to communicate is no longer Billions (people) but
Trillions (things) [57, 58]”. This fact has triggered many standardization initiatives, in order to facilitate products interoperability. Firstly, this chapter aims
at briefly introducing the main WSN application areas and some of the general characteristics of the network in each case (see Section 2.1). Secondly,
the chapter focuses on the main standardization initiatives and organizations in the area of WSNs (see section 2.2).
2.1.
Applications of WSNs
This section aims at introducing the main application areas for WSNs. The
reader may note that some of these areas overlap to some extent.
2.1.1. Environmental monitoring
One of the classical WSN applications is environmental monitoring. In
this type of application, sensor nodes are spread over a certain area (e.g. an
urban area, a forest, a jungle, etc.) for monitoring parameters such as temperature, humidity, quality of the air, pollen concentration etc. These (and
71
6/9/10
09:59
Página 72
Sensors Everywhere
other) data allow studying the environmental conditions of the zone and
how they influence people, animals [18] and/or vegetation of the zone. In
rural zones, forest fire control is another area of applicability. The following
table shows examples of what can be sensed at present.
Application
Environmental
Monitoring
What can be sensed?
-Temperature
- Atmospheric pressure
- Humidity
- Ambient light intensity
- UV radiation
- Air pollutants (CO2, CO,
NO2, ammonia,
methane, etc.)
- Pollen concentration
pick-up
- Ozone (O3)
- Ambient sounds/noise
Comments
Wide variety in the market
Small size (e.g. see [24] and
[25] as general sensor
product references).
See [26].
See [27].
Academic/R&D stage.
Big size; e.g. see [28].
Academic/R&D stage; e.g.
see [29].
See [30]
Table 2.1. Examples of characteristics that can be sensed in the environment
In rural scenarios, especially in zones where access is difficult, the nodes
may be randomly deployed (e.g. thrown from a helicopter) and remain static. The data is collected by one or more sink nodes, which can be connected to other networks for remote access.
2.1.2. Healthcare, sports and fitness, assisted living
Wearable wireless sensors can periodically report the levels of several
body parameters [31], e.g. temperature, blood pressure, ElectroCardioGraph
(ECG) (see Fig. 2.1) and insulin for a precise diagnosis. Sensor nodes can be
used for patient location, monitoring and indentification in the hospital or at
home (see Fig. 2.2). This fact enables remote care, by which patients,
disabled and elderly citizens can benefit from at-home medical attention
[35, 48]. On the other hand, alarms can be activated if critical events are
72
6/9/10
09:59
Página 73
detected (e.g. acceleration sensors suggest that a person has fallen).
At-home medical attention may exploit the presence of a home automation
WSN (see 2.1.6) for enhanced connectivity within the home and with remote
hosts.
Fig. 2.1. Sensor node from Shimmer with a ECG extension [54]
Fig. 2.2. Wireless sensor node to be fitted at the wrist (orange box) for patient
identification, monitoring and location. The black box at the top of the image is
used as a wireless router to create a backhaul network used for
communication and as a reference for location in the hospital
73
6/9/10
09:59
Página 74
Sensors Everywhere
Some examples of European Projects addressing different aspects of the
health care research topic are HeartCycle [33] and PERSONA [34]. While the
scope of the HeartCycle project is the closed-loop management of both
heart failure patients and chronic heart disease patients (including diabetes,
arrhythmias, etc.), the scope of the PERSONA (PERceptive Spaces
prOmoting iNdependent Aging) project is a standard AAL (Ambient Assisted
Living) service platform aimed at assisting elderly people in their daily activities.
Another application area that can benefit from wearable sensors is
sports and fitness [36, 37]. Heart rate sensors may communicate, for
example, either with a watch which can display the result of the
measurement, or with a device which can store the main statistics of a
training session. The WSN is, in this case, composed of a small number
of nodes. In addition, it may also be possible to transmit these data to a
remote database (e.g. connected to the Internet) where the recorded
data can be processed and analysed, and based on that, a “virtual
coacher” can provide feedback and guidance to the user while the
training session is in progress.
Finally, in addition to health-related parameters, biometric sensors can
report data from which the emotions of a person can be obtained.
Emotional sensing is an interesting new area of research [38].
2.1.3. Structural monitoring
Buildings, bridges, tunnels, etc., can benefit from periodic monitoring of
the architecture health [15]. On the other hand, upon detection of emergency situations (for example testing of earthquake or structural damages),
the sensor nodes can inform quickly about the event, so that appropriate
actions can be taken in response.
Another area of application may be internal pipeline corrosion monitoring in the fuel and gas industry.
The nodes in these environments are manually deployed and remain
static. The data is collected by one or more sink nodes, which can be connected to other networks for remote access.
74
6/9/10
09:59
Página 75
2.1.4. Automotive
There are a wide range of applications based on sensors already working
within a car, like for example environment control (indoor and outdoor temperatures), windows status, vehicle occupancy, seat belt monitoring, rain
brush control, fuel control, tire pressure [50] or brake assistance (signal information from pedestrian and obstacles sensing), etc. All these sensed data
could be arranged based on simple WSN configurations.
2.1.5. Logistics
WSNs can provide value for logistics (tracking goods, pallets, baggage, etc), supply chain management or dynamic pricing information
update in retail stores. For example, product packages can have embedded sensor nodes for detecting unauthorized package opening. These
sensor nodes can communicate with static nodes placed in the warehouse for triggering alarms upon detection of unauthorized opening.
On the other hand, the embedded sensor nodes may store information
about each product, such as its own identification and additional information, such as the current location, the temperature inside the package, etc. RFID technologies are also suitable for this application category
[39, 40].
2.1.6. Home and building automation
WSNs enable a variety of applications in the home for user comfort and
home management. Some examples follow [41, 42]:
• Light control. A new light can be controlled from any switch, which
reduces the need for new wired connections. Lights can also be activated in response to a command from a remote control. Furthermore,
they can be turned on automatically when presence and luminance
sensors detect that people are in a poorly illuminated room.
• Remote control. Infrared technology has been used for wireless communication between a remote control and devices such as TVs, HiFi
equipment and Heating Ventilating and Air Conditioning (HVAC) sys-
75
6/9/10
09:59
Página 76
Sensors Everywhere
tems. However, infrared requires line-of-sight (LOS) and short-distance
communication. RF technology overcomes these limitations.
• Security and safety. Advanced security systems can be based on several
sensors (e.g. smoke detectors, glass-break sensors and motion sensors)
for detecting possible risk situations that trigger appropriate actions in
response. For example, smoke detectors may activate fire alarms.
• Window shades, HVAC, central heating, etc. may be controlled
depending on the information collected by several types of sensors
that monitor parameters such as temperature, humidity, light and
presence. Unnecessary waste of energy can thus be avoided.
Fig. 2.3. Motion sensor based on a passive infrared (PIR) sensor providing
also temperature and illumination level
In a home, the number of nodes may be in the order of tens (and even
hundreds in some residences), and the node density can be high. The nodes
are mainly static, but some of them (e.g. those attached to remote controls
or even to people) may exhibit some degree of mobility. The home automation network can be connected to other networks (e.g. the Internet) via a
gateway or a router, depending on the protocols used.
76
6/9/10
09:59
Página 77
The applications in building automation are similar to the ones in home
automation, but the network size and structure may be different. In a building, the number of nodes may be in the order of thousands. In building automation, areas are defined as small physical locales, such as a room [16].
These areas are managed by controls which obtain the measurements
provided by the sensors present in the area (e.g. temperature, occupancy,
light, humidity, etc.). On the other hand, zones are defined as extended
physical locales (e.g. a floor) which are also managed by controls that receive the data from the sensors within that zone. In building automation,
most of the interactions between nodes do not involve sink nodes.
2.1.7. Industrial monitoring and control
In industrial environments, very critical communications are carried out
using cables, which are known to be more reliable than wireless links.
However, these environments will benefit from adding wireless sensor
nodes for controlling devices which are not currently connected.
The main WSN applications envisioned for process control (where the
main product is typically a fluid, e.g. oil, chemicals, etc.) are monitoring applications with various requirements with regard to real time operation and
non-critical loop control operations [20]. In factory automation (where the
product is a discrete element, e.g. a car, a lamp, etc.), WSNs will allow to carry
out monitoring operations that currently are done manually or are not done.
The number of nodes in an industrial automation WSN may be up to hundreds. The nodes will offer the data they capture to one or more sinks. The
deployment of nodes is done manually.
Another scenario where WSN-based applications may be of high interest
is harsh industrial environments (e.g. chemical, energy or water treatment
industries). In this scenario, the location of the workers can be obtained in
real time and also enable them to trigger an emergency request if this would
be necessary. In those scenarios, the monitoring of chemical agents in the
environment or fuels and gas tanks levels to ensure security is another
application area.
77
6/9/10
09:59
Página 78
Sensors Everywhere
2.1.8.Smart utility
2.1.8.1. Automatic Meter Reading
Traditionally, data collection from utility meters has required human
intervention. Automatic Meter Reading (AMR) systems based on wireless
sensors enable a low cost solution for collecting electric power, gas and
water usage of a residence (see Fig. 2.4 for an example).
Fig. 2.4. Advanced metering equipment from Nuri Telecom being installed on
an existing metering equipment
2.1.8.2. Real time energy control
Smart utility meters can be used to detect usage peaks and alert to the
household devices that may be causing them.
2.1.8.3. Advanced Metering Infrastructure
Advanced Metering Infrastructure (AMI) is a system that allows two-way
interaction with smart meters. Strictly speaking, AMR systems only provide
information from the meters to the utilities (i.e. “uplink”), but do not support
interaction in the opposite direction (i.e. “downlink”).
Energy supply companies can exploit AMI to perform energy load management and to offer pricing information to the home (e.g. by offering special
78
6/9/10
09:59
Página 79
incentives for customers who shed load during peak periods), where the
devices activity can be intelligently scheduled based on that information.
In addition, uplink communications will facilitate customers to become
energy suppliers, for instance selling the utility their remaining power generated by solar panels, bio-fuel, or any other green energy source (which is
usually called microgeneration).
2.1.8.4. Smart Grid
Within the Smart Grid future vision4 [43], the integration of WSNs with
advanced data telecom network infrastructure may have a chance in providing the required “intelligence” to the electricity networks, because they may
be used to monitor delivery and use of energy in the elements of the electrical supply chain (generation, transmission, distribution and consumption).
For example, sensors and actuators may be used for power flow assessment,
voltage control and systems protection. Indeed, AMR/AMI can be seen as a
small part of the future Smart Grid vision.
2.1.9.Urban monitoring and control
WSNs can be used in an urban environment for many applications. A
non-exhaustive list follows.
2.1.9.1. Traffic monitoring
Sensor nodes placed in roads and streets can provide vehicle traffic measurements for carrying out traffic management and to alert vehicle drivers
of dense zones.
This type of applications are usually framed under the acronym
Intelligent Transportation Systems (ITS) [44, 51], which are systems aiming
4
There is not a standard global definition for “Smart-Grid”. However, it is expected that it
will provide a secure data communications network integrated with the electricity network that collects and analyzes power data captured in real-time (in combination with
prognosis) from all the elements of the electrical supply chain. Based on these data, predictive information and recommendations should be provided to utilities, their suppliers
and their customers on how best to manage power.
79
6/9/10
09:59
Página 80
Sensors Everywhere
to allow people to get more from vehicular transport networks, with greater
safety and with less impact on the environment. Both car-to-car and car-toinfrastructure communication applications are identified in this area addressing not only traffic control or road situation monitoring, but also road usage
charging (see section 2.1.10), fleet management or driver assistance information (e.g. driving assistance supported by data recorded from road signals
information placed along the route [52]).
2.1.9.2. On-street parking operations and payment
Vehicles equipped with sensor nodes may interact with fixed control devices placed at parking zones for carrying out the parking payment. The sensor node attached to the vehicle may provide the identification of the car
owner and may also be used to measure the vehicle parking time [22, 45].
2.1.9.3. Green zones watering control
Underground humidity sensors may be placed at green zones (e.g. grass
areas). When the humidity level is below a certain threshold, the sensors can send
a message to an actuator that controls the irrigation system. Hence, the irrigation
mechanism can be automatically turned on or off, based on the green zone
watering needs. Fig. 2.5 shows a sensor node that includes a humidity sensor.
Fig. 2.5. Example of a sensor node that includes a soil moisture sensor
80
6/9/10
09:59
Página 81
2.1.9.4. Rubbish selective recollection
Sensor nodes can be placed inside of rubbish containers for sensing the
rubbish occupancy level of each container (see Fig. 2.6). This information
can be transmitted (possibly, in a multi-hop way) to the vehicles in charge of
rubbish collection. This way, the vehicle can follow optimized routes, avoiding the need for passing by streets where the rubbish containers are empty.
Fig. 2.6. A sensor node placed inside of a rubbish container for measuring
its occupancy level by using ultrasound signals
2.1.9.5. Lighting
At night street light illuminate the city to facilitate the people movement
and improve the security. The usage of a sensor network can detect the presence of people and modify or even switch off and on light in order to save
energy when nobody is in the area close to the lamp pole [23, 46].
2.1.9.6. Public safety
Applications related to public safety may be enabled by means of
WSNs, as for example chemical agents monitoring in civilian settings. In
addition sewage remote management is other related area of potential
applicability.
81
6/9/10
09:59
Página 82
Sensors Everywhere
2.1.10.Road usage charging
Sensor nodes placed in vehicles can be used in Road Usage Charging
(RUC) operations. Such sensor nodes may store the identity of the vehicle owner and may include information to enable payment operations.
When a vehicle approaches a toll barrier, the sensor node in the vehicle
can communicate with another sensor placed close to the barrier, so
that both devices can exchange the information necessary to enable the
payment required [47]. In some advanced proposals sensors detect the
number of people inside to apply different charging depending on the
vehicle occupation.
2.1.11. Disaster recovery
For a quick public service response to disasters, a set of sensor nodes
could be distributed in the rescue area (for example robots or fire brigades
could have these nodes with their wearable equipments) and ad-hoc wireless mesh networks could be quickly set up to map out the disaster area and
transmit it to the command centre [49].
2.1.12.Rural monitoring and control
WSNs can significantly enhance the efficiency and productivity of
agricultural and livestock management [19, 21]. For example, specialized
sensor nodes can be placed to cover the area of interest for monitoring
the temperature, frosting, plagues, soil moisture (see Fig. 2.7) or sunlight.
These sensor nodes can provide measurements with significantly greater sampling rate than any other human-based monitoring mechanism.
Due to farmers’ natural limitations, and the collected data can be centralized and managed in a PC. Based on the information collected, the
farmers can better decide about water, energy or pesticide usage [15].
The number of nodes for such a network may be in the order of thousands and the nodes are static.
82
6/9/10
09:59
Página 83
Fig. 2.7. Sensor node able to support up to five soil moisture sensors
installed in the field
Similarly, livestock can be controlled by attaching a sensor node to each
animal. Each sensor node can provide information about its location, its
identification and about the environment. The nodes in this case are mobile (their mobility depends on the mobility of the animals), except for static
sink nodes that receive the collected data.
2.1.13. Telecommunications applications
Sensor nodes embedded in telecommunications devices (e.g. mobile
phones) can provide added value and a new range of services offered to the
telecom operators customers. For example, the location of a user can be
determined if other sensor nodes with known locations detect his/her sensor-enabled mobile phone. This information can be used to offer advertisements or information in general to the user, based on his/her location and
interests. Mobile payment is another application for mobile users (the same
idea presented in 2.1.10 can be extended to any type of payment).
83
6/9/10
09:59
Página 84
Sensors Everywhere
2.1.14. Gaming
WSNs have a large potential to enable gaming applications. Players with
attached sensor nodes, or holding devices equipped with sensor nodes, can
interact with each other and their environment by moving and gesturing in
order to carry out game related actions [17]. In fact, there exist games where
devices with 3-axial accelerometer sensors are used, in order to emulate 3D
actions.
2.1.15. Robotics
Wireless sensor nodes can be embedded on various types of robots, for
example, for measuring physical parameters in zones where human access
is difficult. A group of robots can collaborate with each other, based on their
measurements. These robots can be seen as a WSN composed of mobile
nodes.
2.1.16. Contextual awareness
In general, everyday human life activities could be enhanced in terms of
wellbeing, productivity, efficiency and sustainability concerns if the contextual relevant data obtained from a wide variety of sensors placed in the
surrounding space of people could be properly managed [53]. For example,
today the sensor devices technology in a mobile phone exists in order to
allow activating the keyboard illumination depending on the ambient light,
to change the view depending on the terminal inclination or even to
change the ringing volume according to the ambient noise. In an office
building, presence sensors can switch off the lights or a temperature sensor
can activate the heater.
2.2.
Standardization initiatives
This section presents some of the main standardization initiatives in the
area of WSNs. We consider the initiatives that have been promoted and/or
are promoted by the IEEE, the IETF, the ITU, the ISO/IEC and industry alli-
84
6/9/10
09:59
Página 85
ances (such as the ZigBee Alliance, the Bluetooth Special Interest Group
(SIG), the Z-Wave Alliance, the Wavenis Open Standard Alliance (OSA), the
INSTEON Alliance and the EnOcean Alliance).
2.2.1. IEEE
The Institute of Electrical and Electronics Engineers (IEEE) is a professional association which develops and promotes engineering, computing and
technology information [1]. The IEEE is in charge of a large amount of publications, conferences, technology standards, and professional and educational activities.
With regard to WSNs, the main standard developed by IEEE is IEEE
802.15.4, which specifies the physical (PHY) layer and Medium Access
Control (MAC) layer functionality of a low power radio interface (see chapters 3 and 4). IEEE 802.15.4 is actually a family of standards developed by
the IEEE 802.15 Task Group 4, which was chartered “to investigate a low
data rate solution with multi-month to multi-year battery life and very low
complexity” [2]. In fact, IEEE 802.15.4 has become the de facto radio interface used in WSNs.
Also in the area of WSNs, the IEEE produced the IEEE 1451 specification,
which describes a family of smart transducer interface standards (see
Chapter 12).
2.2.2. IETF
The Internet Engineering Task Force (IETF) is an open international
community “of network designers, operators, vendors, and researchers
concerned with the evolution of the Internet architecture and the
smooth operation of the Internet” [3]. The IETF develops and updates
the protocols and architectures of the Internet. An important detail
about the specifications developed by the IETF is that they are not
standards from a formal point of view. They are de facto standards,
which mean that these specifications are accepted and used by a large
community.
85
6/9/10
09:59
Página 86
Sensors Everywhere
Work in the IETF is carried out by Working Groups (WGs), which produce
documents that aim at offering solutions and useful information with regard
to specific problems on the Internet.
There are three main IETF WGs relevant to WSNs: the IPv6 Low power
Wireless Personal Area Network (6LoWPAN) WG [4], the Routing over Low
power and Lossy networks (ROLL) WG [5] and the Constrained RESTful
Environments (CoRE) WG.
The main purpose of 6LoWPAN is to develop solutions for enabling the
transmission of IPv6 packets on top of IEEE 802.15.4 networks. See Chapter
11 for more details.
The main goal of ROLL is the development of routing solutions for Low
power and Lossy Networks (LLNs), which include WSNs. See Chapter 7 for
more details.
CoRE is a WG that was recently created to define a Constrainednode/network Application Protocol (CoAP) for the manipulation of resources on a device.
2.2.3. ITU
The International Telecommunications Union (ITU) is the United Nations
agency for the areas of information and communication technology issues
[6]. The telecommunication standardization sector is known as ITU-T.
Ubiquitous Sensor Networks (USNs) were the subject under study of a
recent report carried out by ITU-T, which aimed at identifying candidate
technologies for standardization work within ITU [7].
On the other hand, the ITU published in 2005 a report about the Internet
of Things [8], a topic where WSNs play a fundamental role.
2.2.4. ISO and IEC
The International Organization for Standardization (ISO) develops and
publishes international standards on a wide variety of subjects. ISO members include organizations from the public and private sectors.
86
6/9/10
09:59
Página 87
The International Electro-technical Commission (IEC) is an international
standards organization that develops and publishes international standards
for the areas of electrical and electronic technologies.
The ISO/IEC Joint Technical Committee (JTC) 1 was formed as a merger
between ISO and IEC groups to focus on information technology. Recently,
the JTC 1 Work Group 7 was created to undertake standardization in the
area of generic solutions for sensor networks and application-oriented sensor networks.
2.2.5. ETSI
The European Telecommunications Standards Institute (ETSI) has created the machine to machine technical committee (M2M TC) to define
standards for M2M communications. It is expected that in 2017, 7000
billion (connected) objects will be serving billion people [56]. A tremendous increase in the following years is also envisaged. According to ETSI
[55] the M2M communication is in the heart of personal health monitoring, intelligent tracking and tracing in the supply chain, smart utility
metering, remote control of vending machines, industrial wireless automation and ambient assisted living, applications related commonly to
WSN.
2.2.6. NIST
NIST stands for National Institute of Standards and Technology. NIST
plays the role of research institute and also contributes to the harmonisation of technologies, such as sensor-related standards. In this regard, NIST
promotes a working group for the information exchange related to sensor
equipment interoperability.
2.2.7. Other standardization efforts
The organizations included in this subsection are industry alliances,
which promote the use of a certain technology as a de facto standard.
87
6/9/10
09:59
Página 88
Sensors Everywhere
2.2.7.1. ZigBee Alliance
The ZigBee Alliance [9] is an association of companies that develops
the specifications of the ZigBee technology, which defines security, network and application layer functionality on top of IEEE 802.15.4 (see
Chapter 11).
2.2.7.2. Bluetooth Special Interest Group
The Bluetooth Special Interest Group (SIG) is a privately held association.
The main tasks for the Bluetooth SIG are the publication of Bluetooth specifications, and the protection and promotion of Bluetooth technology [10].
The recent Bluetooth Low Energy (BT-LE) technology is suitable for certain applications in the area of WSNs. For more details about BT-LE, the reader may refer to chapters 3, 4 and 11.
2.2.7.3. Z-Wave Alliance
The Z-Wave Alliance [11] is an open consortium of manufacturers who
create products and services based on a proprietary technology called
Z-Wave (See Chapter 11).
2.2.7.4. Wavenis Open Standard Alliance
The Wavenis Open Standard Alliance [12] is a body whose participants
work to define the Wavenis technology roadmap and new Wavenis features
and capabilities. For details about Wavenis technology, the reader may refer
to Chapter 11.
2.2.7.5. INSTEON Alliance
The INSTEON Alliance [13] is a community of product designers and
technologists that cooperate towards the adoption and development of
INSTEON technology. For details about INSTEON, the reader may refer to
Chapter 11.
88
6/9/10
09:59
Página 89
2.2.7.6. EnOcean Alliance
The EnOcean Alliance [14] is an organization which develops and promotes the use of self-powered wireless monitoring and control systems by
making use of EnOcean technology. For details about EnOcean, the reader
may refer to Chapter 11.
REFERENCES
[1]
IEEE web site: http://www.ieee.org/web/aboutus/home/index.html
[2]
IEEE 802.15 Task Group 4 web site:
http://www.ieee802.org/15/pub/TG4.html
[3]
IETF web site: http://www.ietf.org/about/
[4]
IETF 6LoWPAN WG charter:
http://www.ietf.org/dyn/wg/charter/6lowpan-charter.html
[5]
IETF ROLL WG charter:
http://www.ietf.org/dyn/wg/charter/roll-charter.html
[6]
ITU web site: http://www.itu.int
[7] “Ubiquitous Sensor Networks (USN)”, ITU-T Technology Watch Report
#4, February 2008.
[8]
“The Internet of Things”, ITU Report, 2005.
[9]
ZigBee Alliance web site: http://www.zigbee.org/
[10] Bluetooth SIG web site: http://www.bluetooth.com/Bluetooth/SIG/
[11] Z-Wave Alliance web site: http://www.z-wavealliance.org
[12] Wavenis Open Standard Association web site: http://www.wavenis-osa.org
[13] INSTEON Alliance web site: http://www.insteon.net/allianceabout.html
[14] EnOcean
Alliance
alliance.org/en/home/
web
site:
http://www.enocean-
89
6/9/10
09:59
Página 90
Sensors Everywhere
[15] E. Kim, D. Kaspar, N. Chevrollier, J.P. Vasseur, “Design and Application
Spaces for 6LoWPANs”, draft-ietf-6lowpan-usecases-05, IETF Internet
draf (Work in Progress), November 2009.
[16] J. Martocci, P. De Mil, Vermeylen, N. Riou, “Building Automation Routing
Requirements in Low Power and Lossy Networks”, draft-ietf-roll-buildingrouting-reqs-09, IETF Internet draf (Work in Progress), January 2010.
[17] O. Akrivopoulos et al., “Demo Abstract: Using Wireless Sensor Networks
to Develop Pervasive Multi-player Games”, in proc. of SenSys’08,
Raleigh, North Carolina, USA, November 2008.
[18] A. Mainwaring, D. Culler, J. Polastre, R. Szewczyk, and J. Anderson.
“Wireless sensor networks for habitat monitoring”. in proc of the 1st
ACM international Workshop on Wireless Sensor Networks and
Applications. Atlanta, Georgia, USA, September 28 - 28, 2002.
[19] J Burrell, T Brooke, R Beckwith, “Vineyard computing: sensor networks
in agricultural production”, IEEE Pervasive Computing, Vol. 3, Issue 1,
March, 2004. pp. 38 – 45.
[20] V.C. Gungor, G.P, Hancke, “Industrial Wireless Sensor Networks:
Challenges, Design Principles, and Technical Approaches”, Industrial
Electronics, IEEE Transactions on. Vol. 56, Issue 10, Oct. 2009, pp. 4258
– 4265
[21] Ning Wang, Naiqian Zhang, Maohua Wang, “Wireless sensors in agriculture and food industry--Recent development and future perspective”,
Computers and Electronics in Agriculture, Vol. 50, Issue 1, January
2006, pp. 1-14
[22] Jung-Wook Lee; Yoon-Bong Yoo; Jae-Jeung Rho; Sae-Sol Choi, “An
enhanced parking lot service model using wireless sensor network”,
Industrial Informatics, 2008. INDIN 2008. 6th IEEE International
Conference on, 13-16 July 2008, pp. 349 – 354
[23] Chunguo Jing; Dongmei Shu; Deying Gu, “Design of Streetlight
Monitoring and Control System Based on Wireless Sensor Networks”,
Industrial Electronics and Applications, 2007. ICIEA 2007. 2nd IEEE
Conference on, 23-25 May 2007, pp. 57 – 62
90
6/9/10
09:59
Página 91
[24] http://sensors-transducers.globalspec.com/ProductFinder/–
Sensors_Transducers_Detectors
[25] http://www.sensorsmag.com/
[26] http://www.electronicsmanufacturers.com/Optoelectronics/UV_sensors/
[27] http://www.libelium.com/documentation/waspmote/gases-sensorboard_eng.pdf
[28] http://www.lasprovincias.es/valencia/20080503/costera/aparatohospital-xativa-permite-20080503.html
[29] http://www.samaylive.com/news/researchers-develop-ultrasensitiveozone-sensor/672510.html
[30] MTS 300 and MTS 310 sensor board datasheet.
[31] Guang-Zhong Yang (Ed.) “Body Sensor Networks”; Springer’s book,
2006.
[32] http://www.hitech-projects.com/euprojects/myheart/
[33] http://heartcycle.med.auth.gr/
[34] http://www.aal-persona.org/
[35] http://www.aerotel.com/en/
[36] http://www.nokia.com/corporate-responsibility/environment/sustainable-products/eco-sensor-concept
[37] http://www.adidas.com/es/miCoach/#Start/sdf/mdf
[38] http://www.design.philips.com/probes/projects/emotion_sensor/–
index.page
[39] RFID Product solutions http://www.gaorfid.com/
[40] LandMARC Research Center: “Active Tag Project”
http://eosl.gtri.gatech.edu/Capabilities/CentersofExcellence/Landma
rcResearchCenter/LandmarcProjects/GTRIActiveTagProject/tabid/36
5/Default.aspx
[41] http://www.hometronic.com/
91
6/9/10
09:59
Página 92
Sensors Everywhere
[42] http://www.cm-zone.com/
[43] http://www.smartgrids.eu/documents/vision.pdf
[44] Special Session: “Intelligent Transportation and Traffic Telematics Challenges, Applications, Standardization” 19th Annual IEEE
International Symposium on PIMRC 2008.
[45] http://www.streetlinenetworks.com/site/index.php
[46] http://www.simplicityevent.philips.com/global/tomorrow/light_blossom/
[47] C. Birle “Innovative road usage and congestion charging approaches
using 2G and 3G cellular network capabilities and infrastructure”. IEE
Seminar “Road User Charging: Technical and Operational
Development” June 2004.
[48] C. R. Baker et al., "Wireless Sensor Networks for Home Health Care,"
Advanced Information Networking and Applications Workshops, 2007,
AINAW '07. 21st International Conference on, Vol. 2, pp. 832-837, 2123 May 2007.
[49] K. Lorincz, D.J. Malan, T.R.F. Fulford-Jones, A. Nawoj, A. Clavel, V.
Shnayder, G. Mainland, M. Welsh, S. Moulton, "Sensor networks for
emergency response: challenges and opportunities," Pervasive
Computing, IEEE, Vol. 3, No. 4, pp. 16- 23, Oct.-Dec. 2004.
[50] J. Zhang, Q. Liu, Y. Zhong “A Tire Pressure Monitoring System Based On
Wireless Sensor Networks Technology”, International Conference on
Information Technology 2008.
[51] M. Nekovee, “Sensor networks on the road: the promises and challenges of vehicular ad hoc networks and grids”.
[52] T. Gruber, E. Schoitsch, “Automotive Visions beyond In-Car Driver
Assistance: Integrated Traffic Management with Coopers”.
http://ercim-news.ercim.eu/coopers-automotive-visions-beyond-incar-driver-assistance
[53] M. Strohbach, J. Vercher, M. Bauer, "A case for IMS," Vehicular
Technology Magazine, IEEE, Vol. 4, No.1, pp. 57-64, March 2009.
92
6/9/10
09:59
Página 93
[54] http://shimmer-research.com/wordpress/home
[55] http://www.etsi.org/Website/Technologies/M2M.aspx
[56] J. Koss, “Open Standards for M2M”, M2M Business Exchange, Brussels,
Belgique, November 2009.
[57] MOCOM 2020 - Future Vision Video: http://www.mocom2020.com/
[58] http://www.computerworld.com/s/article/9132386/Opinion_10_
game_changing technologies?source=NLT_HW
93
6/9/10
09:59
Página 94
6/9/10
09:59
Página 95
3
Physical layer
6/9/10
09:59
Página 96
6/9/10
09:59
Página 97
Chapter 3. Physical layer
3. Physical layer
Physical reachability is one of the conditions that must be fulfilled to
allow direct communication between two devices in any network. Because
the devices of a WSN use radiofrequency (RF) signals, data transmissions are
challenged at the physical layer by several phenomena including interference, multipath and attenuation. Hence, the solutions for data transmission
must be robust to radio impairments. However, because the devices of a
WSN must be designed for low power consumption, the solutions must also
be simple.
This chapter first focuses on the propagation of RF signals and presents
some of its main problems. Next, the chapter overviews the most relevant
frequency bands for WSNs and other wireless applications. Then, the chapter gives a background on modulations and spreading techniques that are
currently used in WSNs. Finally, the chapter describes the physical layers
(PHYs) of the IEEE 802.15.4 family and Bluetooth Low Energy (BT-LE).
3.1.
Radiofrequency signal propagation
Communication between two wireless devices requires the signal power
at the receiver antenna to be above the receiver sensitivity. However, the
reception of a radiofrequency signal is affected by several elements and
phenomena, including the distance between the devices, the propagation
environment and external interference sources. This subsection summarizes
the main aspects that may affect the propagation of radiofrequency signals.
97
6/9/10
09:59
Página 98
Sensors Everywhere
3.1.1. Path loss
Path loss can be defined as the attenuation suffered by a transmitted signal when it arrives at the receiver after traversing a certain path. It can be
obtained as the ratio between the transmitted and received power, as
shown in equation (1):
(1)
where PL, Pt and Pr are the path loss, transmitted power and received
power, respectively.
In free space, and assuming the use of an isotropic antenna (i.e. an antenna that transmits the same signal level in all directions), the maximum received power at a distance d can be obtained from the Friis equation:
(2)
where λ is the wavelength in meters, Gt and Gr are the gains of the transmitting and receiving antennae. Note that received power decreases proportionally to f2, where f is the signal frequency in Hertz, and to d2.
The free space model is not accurate enough in real world scenarios, due
to several phenomena including signal absorption in different materials, signal reflection, etc. Several experimental models aim at predicting the received power. These models include parameters that depend on the environment considered in each case. A general model that can be used is the
following [1]:
(3)
98
6/9/10
09:59
Página 99
Since equation (2) is not consistent for d=0, many models like this use a
distance, do, which is called the received-power reference point and is generally chosen to be 1 m [1]. In addition, in equation (3) PL is expressed in dB,
γ denotes the power-law relationship between the received power and the
distance, and χσ is a zero-mean Gaussian random variable of standard deviation σ, which represents the variation of the received power that can occur
when using this model. In effect, γ = 2 models free space propagation, but in
realistic scenarios γ is in the range between 2 and 4. In some particular environments, γ can even take values beyond this range. Experiments in office
buildings have shown that γ can be between 1.6 and 1.8 in line-of-sight
(LOS) [4], while it can reach values greater than 4 when there is no LOS communication [19]. When the antennae are near the ground (which is the case
of many WSNs), γ is close to 4 [2].
3.1.2. Attenuation
When a signal is incident to an object, the characteristics of the object
material, the signal frequency and the angle at which the signal impinges
the surface of the object determine the attenuation (i.e. the loss of signal)
that the signal will undergo. A material can be characterized by its attenuation constant, which can be expressed in dB/m. For instance, the water attenuation constant at a typical home temperature for a 2.4 GHz signal is
around 330 dB/m. This means that the human body attenuates the signal
significantly [3].
3.1.3. Reflection, diffraction and scattering
Reflection, diffraction and scattering are the three basic propagation
mechanisms that affect wireless propagation [4].
When a signal reaches a large object in comparison with the signal wavelength, a part of the signal or the whole signal will be reflected. The ground,
walls and furniture cause reflection (see Fig. 3.1). The amount of reflected
signal will depend on the properties of the reflecting materials, in addition to
the properties of the incident signal.
99
6/9/10
09:59
Página 100
Sensors Everywhere
Diffraction (see Fig 3.2) takes place when an obstacle with sharp edges is
present in the path between the radio sender and receiver. As a result, the
waves bend around the obstacle and may reach the receiver, even when
there is no LOS path between them.
Scattering (See Fig. 3.2) occurs when the signal is incident to small obstacles (compared to the signal wavelength) or rough surfaces. In such a
case, the signal is propagated in many directions.
Fig. 3.1. Two signals reach the receiver: an LOS signal and another
which is reflected by the ground
Fig. 3.2. (left) an example of scattering, (right) an example of diffraction
100
6/9/10
09:59
Página 101
3.1.4. Multipath
In view of the propagation phenomena already presented, the same signal can reach the receiver via several different paths. For instance, a signal
can be directly propagated from the transmitter to the receiver through an
LOS path. A different version of the same signal can reach the receiver as well;
for example, due to the reflection of the signal on the ground (see
Fig. 3.1). The amplitude, phase and delay of the first and second versions of
the same signal may not be the same. Therefore, the sum of these different
versions will be a distorted signal. A signal strength measurement may provide greater values than in the case of a single path transmission. However,
the quality of the signal may not be greater. Even the different versions of the
same signal may lead to signal nulls. For instance, in the two-path example, if
the two versions of the same signal have 180º phase difference and their
amplitudes are quite similar, the signal power will be significantly reduced.
For all the aforementioned reasons, Received Signal Strength Indicator (RSSI)
measurements, which are often offered by radio chips used in sensor platforms,
have to be taken carefully as an indication of good quality signal reception.
3.2.
Frequency bands
The frequency band used by a wireless communications system is a key
factor that influences the performance of the system. In fact, the frequency
band is related with the symbol rate that the system is able to achieve. On
the other hand, as already seen in the previous section, the quantitative
effect of several propagation phenomena depends on the frequency of the
signals transmitted. Another important consideration is interference, since
transmissions at a given frequency may interfere the communications of
other systems operating at the same frequency..
3.2.1. Regulation
Many wireless communications systems, including WSNs, exploit bands
originally intended for industrial, scientific and medical (ISM) applications.
101
6/9/10
09:59
Página 102
Sensors Everywhere
These bands, which are available worldwide or in particular regions of the
world, are defined by the International Telecommunication Union (ITU) and
are reserved for private and unlicensed use, subject to certain restrictions
that may depend on regional or national regulation (e.g. regarding transmit
power and duty cycle). Further regulation may apply in certain regions. For
this reason, some parts of the spectrum are license-free in some countries
or geographical areas.
Table 3.1 shows a subset of the ISM bands and license-free regional
bands of interest to low power applications.
Frequency band
6.765 – 6.795 MHz
13.553 – 13.567 MHz
26.957 – 27.283 MHz
40.66 – 40.70 MHz
314 – 316 MHz
430 – 434 MHz
433.05 – 434.79 MHz
779 – 787 MHz
865 – 868 MHz
868 – 870 MHz
902 – 928 MHz
Availability
Applications
Worldwide
Worldwide
Worldwide
Worldwide
China
China
Europe, Africa and part
of Asia (including the former
Soviet Union and west of
the Persian Gulf)
China
Europe
Europe
ISM
ISM, RFID
ISM, ham radio
950 – 956 MHz
2.400 – 2.4835 GHz
Americas, Greenland and
some of the eastern
Pacific Islands
Japan
Worldwide
5.725 – 5.875 GHz
Worldwide
RFID
RFID
ISM, RFID
WSN
WSN, RFID
Non-specific low power
data devices
ISM, WPAN, cordless
phones
WSN, RFID
RFID
ISM, WLAN, WPAN, cordless
phones WSN, RFID
ISM, WLAN, cordless
phones
Table 3.1. A subset of the ISM and regional license-free bands of interest to
low power applications
102
6/9/10
09:59
Página 103
A particular case is the regulation for Ultra Wideband (UWB) that applies
in the United States and Europe, which covers frequencies up to 14 GHz (see
Fig. 3.3). In some regions, it is mandatory to implement a mechanism called
Detect and Avoid (DAA) to decrease UWB signal levels if the spectrum is
being used by any other service.
Fig. 3.3. Emission limits for handheld UWB systems allowed by the European
Telecommunications Standards Institute (ETSI), blue curve, and the Federal
Communications Commission (FCC, USA), red curve (adapted from [6])
3.3.
Modulations and spreading techniques
A modulation is a method used for the transmission of a signal that contains information over another signal, which has the purpose of carrying the
information signal. The modulation used in a communications system
influences several properties of the signal transmitted, such as the bandwidth required, robustness against interference and the data rate.
3.3.1. Classical modulation schemes
The classical types of modulations used in radio applications are
Amplitude Modulation (AM), Frequency Modulation (FM) and Phase
103
6/9/10
09:59
Página 104
Sensors Everywhere
Modulation (PM). In AM, the information signal modulates the amplitude of
the carrier signal; in FM, the information signal modulates the frequency of
the carrier signal; finally, in PM, the information signal modulates the phase
of the carrier signal. When the information signal is digital, these modulations are called Amplitude Shift Keying (ASK), Frequency Shift Keying (FSK)
and Phase Shift Keying (PSK), respectively. Incoming bits can be grouped so
that the resulting signal defines a sequence of states, each state
corresponding to a physical waveform called symbol. Each symbol, which
codifies one or more bits, is transmitted at a certain rate.
The most simple ASK modulation uses a sinusoid with a certain amplitude to encode the symbol “1”, and another with null amplitude (i.e.
absence of signal) for the symbol “0 ” (see Fig. 3.4). In Binary PSK (BPSK), the
symbols “1” and “0” are codified by adding 180º and 0º, respectively, to the
phase of a sinusoid (see Fig. 3.5). In Quadrature PSK (QPSK), the symbols
“11”, “01”, “00” and “10” (which correspond to the four combinations of a
group of two bits) are codified by adding 45º, 135º, 225º and 315º, respectively, to the phase of a sinusoid. A simple FSK modulation transmits a sinusoid with frequency f1 or f0 during a symbol period for the transmission of
the symbols “1” and “0”, respectively (see Fig. 3.6).
Fig. 3.4. An example: use of the ASK modulation for the transmission of
the sequence 101101
104
6/9/10
09:59
Página 105
Fig. 3.5. An example: use of the BPSK modulation for the transmission of
the sequence 101101. Every “1”introduces a 180º phase shift
Fig. 3.6. Example: use of the FSK modulation for the transmission of the
sequence 101101. In contrast to this example, the transmission of two
different consecutive symbols may lead to an abrupt change in the signal,
which enlarges the signal spectrum
3.3.2. Spread spectrum techniques
Many radio systems also use spread spectrum techniques for transmitting data in order to increase their resistance against interference and multi-
105
6/9/10
09:59
Página 106
Sensors Everywhere
path, and in some cases even to prevent detection. These techniques
expand the bandwidth of a signal by distributing the energy of the signal into
a range larger than the original one in the frequency domain [7].
In Frequency Hopping Spread Spectrum (FHSS), which is the oldest
spread spectrum technique, the carrier frequency of the signal is quickly
changed according to a pseudo-random pattern of changes known to both
the sender and the receiver. Direct Sequence Spread Spectrum (DSSS) is
based on multiplying a sequence of binary data by a pseudo-random
sequence composed of the values “-1” and “1”. The result is a signal that looks
like noise. However, the original signal can be obtained at the receiver by
multiplying the received signal by the same pseudo-random sequence used
at the transmitter and then summating the result. Parallel Sequence Spread
Spectrum (PSSS) extends the concept of DSSS by parallelizing the binary data
so that N data bits are the input of a scheme formed by N branches. In each
branch, the input bits are multiplied by a sequence composed of the “-1” and
“1” values. The N sequences are near-orthogonal, which allows recovery of
the original data at the receiver. The result is summated for every group of N
input bits, so that every N input bits form a single symbol.
3.3.3. Ultra wideband (UWB)
The original definition of an Ultra Wideband (UWB) system is based on
the usage of very narrow pulses5 (in the order of hundreds of picoseconds
to nanoseconds) that generate a very wide spectrum. This scheme, which
has been used in Radar applications, allows precision ranging applications
and has good properties in terms of interference. In fact, since the energy is
distributed over a very wide band, it neither interferes nor is interfered by
typical narrowband communication systems. In addition, because the
pulses are also very short in space, reflections cannot overlap the original
signal. Hence, this scheme is resilient to multipath [8].
The United States Federal Communication Commission (FCC) has extended the original definition to a general term for a radio technology that
5
In many contexts, these pulses are also referred to as ‘chips’.
106
6/9/10
09:59
Página 107
uses pulses of energy with spread energy over more than 0.5 GHz or
exceeding 20% of the central frequency. The FCC ruled the UWB to be in the
frequency range of 3.1 GHz and 10.6 GHz in 2001. In other countries, other
regulations apply.
The two main UWB techniques are Direct-Sequence UWB (DS-UWB) and
Multiband – Orthogonal Frequency Division Multiplex (MB-OFDM). DS-UWB
consists in transmitting a set of pulses that can transport information by
changing their polarity or their amplitude, or by using an orthogonally
shaped set of pulses. One advantage of DS-UWB is that it can be implemented by using a small number of circuit gates. MB-OFDM divides the spectrum
into several bands, and data are transmitted in each band using OFDM [21].
In OFDM, data is divided into several parallel data streams. The available
bandwidth is divided into several orthogonal6 sub-bands, and each stream is
transmitted over each sub-band. OFDM allows the power used for each subband to be chosen adaptively. This feature avoids the use of frequencies that
may undergo problems (e.g. interference).
UWB has attracted the attention of different communication proposals,
such as the Wireless Personal Area Networks (WPANs) for low and high bit
rates, and also from the Bluetooth Special Interest Group (SIG).
3.4.
Transmission range
The transmission range of a radio transmitter can be defined as the maximum distance from the antenna of the transmitter that leads to a Signal
Interference and Noise Ratio (SINR) above the minimum required by the
receiver. In consequence, the transmission range depends on the transmission power, the environment in which the signal is propagated, the frequency band and the modulation and bit rate.
A common transmission range figure for a transmitted power of 1 mW at
2.4 GHz is 30 m indoors and 90 m when transmitting at 100 mW. For outdoors, the range reaches 100 m for 1 mW and a further 10 km for the 100 mW.
6
The sub-bands are considered ‘orthogonal’ because there is no cross-talk between them.
107
6/9/10
09:59
Página 108
Sensors Everywhere
In addition, in general terms, when using a channel in the 800-900 MHz
band, the range is almost 2.5 times that which can be obtained at the
2.4 GHz band.
A relevant parameter influencing the transmission range is receiver sensitivity, which specifies the minimum received signal level to enable a sufficient reception quality. For example, IEEE 802.15.4 requires a receiver sensitivity of -85 dBm in the 2.4 GHz band and -92 dBm in the 868/915 MHz
band in order to yield a Packet Error Rate (PER) of less than 1% [9]. Other
values for the receiver sensitivity can be found in the market, such as
-101 dBm for 1% PER [10].
3.5.
Physical layers of IEEE 802.15.4
This section presents the physical layers (PHYs) of the several versions
and amendments to the IEEE 802.15.4 standard.
3.5.1. IEEE 802.15.4-2003 PHYs
The physical layer (PHY) of IEEE 802.15.4-2003 is responsible for a number
of tasks including data transmission and reception as well as carrying out
measurements that are needed or can be exploited by upper layer services.
3.5.1.1. Main features of IEEE 802.15.4-2003 PHY
The original IEEE 802.15.4 version [11] specifies the use of radio channels
in three different bands: 1 channel in the 868 MHz band, 10 channels in the
915 MHz band and 16 channels in the 2.4 GHz band. Recall that the first
band is available in Europe, the second one is available in the Americas
region and the third is available worldwide. The spacing between consecutive channels is 2 MHz in the 915 MHz band and 5 MHz in the 2.4 GHz band.
Note that the actual effective bandwidth of the signal may be smaller than
the spacing between channels.
In all cases, DSSS is used for spreading the spectrum of the signal. The
standard mandates the use of Binary PSK (BPSK) modulation for the
108
6/9/10
09:59
Página 109
868/915 MHz bands and Offset-Quadrature PSK (O-QPSK) in the 2.4 GHz
band. Table 3.2 summarizes the main physical layer features of IEEE
802.15.4-2003.
Frequency Number Spreading Modulation
band of channels technique
868 MHz
915 MHz
2.4 GHz
1
10
16
Binary DSSS
Binary DSSS
16-array DSSS
BPSK
BPSK
O-QPSK
Symbol
Bit rate
rate per
per channel
channel (kbaud) (kbps)
20
40
62.5
20
40
250
Table 3.2. Physical layer features of IEEE 802.15.4-2003
3.5.1.2. Centre frequencies
The centre frequency of each channel, denoted by Fc, can be obtained as
follows:
Fc (MHz) = 868.3 (for channel number 0)
Fc (MHz) = 906 + 2·(channel number – 1), for channel numbers between
1 and 10
Fc (MHz) = 2405 + 5·(channel number -11), for channel numbers be-
tween 11 and 26
(4)
3.5.1.3. PHY protocol data unit (PPDU)
The IEEE 802.15.4 PHY protocol data unit (PPDU) is the data unit that
carries the upper layer data unit (i.e. MAC frame), and is transmitted and
received by the IEEE 802.15.4 PHY. The PPDU is composed of three components: the Synchronization header (SHR), the PHY header (PHR) and the
PHY payload (see Fig. 3.7).
109
6/9/10
09:59
Página 110
Sensors Everywhere
Fig. 3.7. Tthe IEEE 802.15.4 PPDU format
The SHR is composed of a four-byte preamble, which allows the
receiver to synchronize with the received message and a one-byte
start-of-frame delimiter that indicates the beginning of the packet data.
The PHR contains the number of bytes in the PHY payload. The PHY
payload, also called PHY Service Data Unit (PSDU), contains the MAC
layer frame. The size of the MAC layer frame cannot be larger than 127
bytes. In consequence, the maximum size of an IEEE 802.15.4-2003
PPDU is 133 bytes. The size of the SHR varies in subsequent versions of
the standard.
3.5.1.4. Modulation methods for the 868/915 MHz bands
Fig. 3.8 shows a block diagram of the operations performed for data
transmission in the 868/915 MHz bands. First, the raw bits to be transmitted
are differentially encoded in order to solve a problem exhibited by the BPSK
modulation. If the communication channel introduces a 180º phase shift,
the receiver detects the received symbols as valid ones. To overcome this
ambiguity, differential encoding is used so that the transmitted symbols
correspond to differences in the information bits.
Once the information bits are differentially encoded, each of them is
mapped onto a 15-bit chip sequence, which constitutes the DSSS technique
applied in this case. The resulting chip sequences are the input of the BPSK
modulator. While BPSK carries only one bit (one chip in this case) per symbol, this modulation is the simplest and most robust of all PSK modulations.
The reason for this is that the signal must be strongly affected to lead the
demodulator to an incorrect decision.
110
6/9/10
09:59
Página 111
Fig. 3.8. Block diagram of the DSSS/BPSK spreading and modulation
techniques used in the 868/915 MHz band
3.5.1.5. Modulation methods for the 2.4 GHz band
Fig. 3.9 shows a block diagram that models the modulation mechanisms used in the 2.4 GHz band. In this case, every four raw bits are
grouped together to form one symbol. Each symbol is then mapped onto
a 32-chip sequence (there exist 16 such sequences, i.e. one for each symbol). Each chip sequence is then modulated using a variant of the QPSK
modulation. This modulation carries two information bits (chips in this
case) per symbol and increases the bandwidth efficiency of the BPSK
modulation. To reduce the maximum phase shift of QPSK and facilitate
implementation, O-QPSK is used. The resulting signal has a bandwidth of
roughly 2 MHz.
Fig. 3.9. Block diagram of the DSSS/O-QPSK spreading and modulation
techniques used in the 2.4 GHz band
3.5.1.6. Physical layer measurements
The IEEE 802.15.4-2003 PHY is responsible for several measurements that may assist in a number of upper level tasks. Some of these
measurements are Energy Detection (ED) and Link Quality Indication
(LQI).
111
6/9/10
09:59
Página 112
Sensors Everywhere
ED is a measurement performed by the receiver, which may be used by
upper layer services to select the channel to be used (e.g. for avoiding the
use of busy channels). ED is encoded as an 8-bit value.
The LQI represents the strength and/or quality of the signal at the
reception of a data unit. The measurement may be implemented by
using receiver ED, a signal-to-noise (SNR) estimation or a combination
of both. LQI is also represented as an 8-bit value. This parameter can be
used by upper layer services (e.g. as an input to routing metrics, in
order to choose the highest quality paths in a multi-hop IEEE 802.15.4
network).
On the other hand, the 802.15.4-2003 PHY carries out the Clear
Channel Assessment (CCA), which is a functionality used by the MAC
sub-layer in order to implement the CSMA/CA (Carrier Sense Multiple
Access with Collision Avoidance) algorithm (see Chapter 4). In particular, this mechanism requires verification of the absence of signal before
a device starts to transmit data. Three methods can be used for the
detection of a busy medium: a) the detection of any energy above an
ED threshold, b) detection of a signal with the characteristics of IEEE
802.15.4 and c) detection of a signal with the characteristics of IEEE
802.15.4 and energy above the ED threshold.
3.5.2. IEEE 802.15.4-2006 PHYs
IEEE 802.15.4-2006 [9] introduces two new optional PHYs for the
868/915 MHz bands, in addition to those defined by IEEE 802.15.42003: i) a scheme based on O-QPSK combined with DSSS, and ii) another that employs Amplitude Shift Keying (ASK) and Parallel
Sequence Spread Spectrum (PSSS). These optional PHYs increase the
bit rate offered by the IEEE 802.15.4-2003 868/915 MHz bands (see
Table 3.3).
112
6/9/10
09:59
Página 113
Frequency Number Spreading Modulation
band
of channels technique
868 MHz
915 MHz
868 MHz
1
10
1
915 MHz
10
20-bit PSSS
ASK
5-bit PSSS
ASK
16-array
O-QPSK
DSSS
16-array
O-QPSK
DSSS
Symbol
Bit rate
rate per
per channel
channel (kbaud) (kbps)
12.5
50
25
250
250
100
62.5
250
Table 3.3. Optional physical layer features added to the
IEEE 802.15.4-2006
3.5.2.1. Channel pages
Since in IEEE 802.15.4-2006 there exist various PHY options for the same
bands, the PHYs supported and that currently used by a device are identified by channel pages, which are defined as shown in Table 3.4.
Channel Page
0
1
2
3 - 31
Channel number
0
1 - 10
11 - 26
0
1 - 10
11 - 26
0
1 - 10
11 - 26
Reserved
Channel description
868 MHz band (BPSK)
915 MHz band (BPSK)
2.4 GHz band (O-QPSK)
868 MHz band (ASK)
915 MHz band (ASK)
Reserved7
868 MHz band (O-QPSK)
915 MHz band (O-QPSK)
Reserved
Reserved
Table 3.4. Channel pages specified in IEEE 802.15.4-2006
7
The standard does not specify the use of channels 11 to 26 in channel pages 1 and 2.
113
6/9/10
09:59
Página 114
Sensors Everywhere
3.5.2.2. Modulation methods for the optional 868/915 MHz bands
The ASK/PSSS scheme introduced in IEEE 802.15.4-2006 is illustrated in Fig. 3.10. The raw bits to be transmitted are first converted to
bipolar data, where the value “0” is replaced by the value “-1”. Each
bipolar bit is then multiplied by a 32-bit bipolar sequence. In the
868 MHz band, there are 20 branches where this operation is performed,
while in the 915 MHz band the number of branches is 5. The sequences
resulting from each branch are then summated, thereby leading to a
single sequence. In consequence, a symbol is formed by 20 input bits
in the 868 MHz band, while in the 915 MHz band a symbol is formed by
5 input bits. The resulting single sequence would be the input of the
ASK modulator, and hence would determine the amplitude of the transmitted signal. However, pre-coding is used before the sequence enters
the ASK modulator. The reason for this is that a constant value must be
added or subtracted in order to ensure that the average values of that
sequence is zero.
Fig. 3.10. Block diagram of the spreading and modulation techniques
used in the PSSS/ASK PHY
114
6/9/10
09:59
Página 115
The DSSS/O-QPSK method introduced in IEEE 802.15.4-2006 is similar
to the DSSS/BPSK specified in the 2003 version of the standard. In this case,
every four raw bits are grouped together to form a symbol and each symbol
is mapped to a 16-bit chip sequence.
3.5.3. IEEE 802.15.4a PHYs
IEEE 802.15.4a is an amendment to IEEE 802.15.4-2006 that was approved in 2007. This new specification defines two alternative PHYs. The first
one, which is based in DS-UWB and operates in unlicensed UWB spectrum,
enables precision ranging and can be useful for applications requiring location awareness (with accuracy of 1 meter or better). The second, which uses
Chirp Spread Spectrum (CSS) and operates in the unlicensed 2.4 GHz band,
offers extended range and enhanced mobility. Both PHYs are robust for
multipath environments.
3.5.3.1. Channel pages
The new PHYs specified in IEEE 802.15.4a make use of two new channel
pages, which identify the channel numbers and the corresponding bands
that can be used by a device. Table 3.5 shows the new channel pages included in IEEE 802.15.4a.
Channel Page Channel number Channel description Frequency band
3
4
0 – 13
0
5 – 31
1–4
5 – 15
Reserved
CSS PHY
Sub–GHz,
UWB PHY
LFB, UWB PHY
HFB, UWB PHY
Reserved
2.4 GHz
250 – 750 MHz
3.1 – 5 GHz
6 – 10.6 GHz
–––
Table 3.5. Channel pages added in IEEE 802.15.4a
3.5.3.2. UWB PHY of IEEE 802.15.4a
The frequency spectrum used by IEEE 802.15.4a UWB is divided into
three band groups: the sub-GHz band (250 - 750 MHz), the Low Frequency
115
6/9/10
09:59
Página 116
Sensors Everywhere
Band (LFB) (3.1 – 5 GHz) and the High Frequency Band (HFB) (6 – 10.6 GHz).
Table 3.6 shows the channels and their main features for each band group.
It is only compulsory to support channels 0, 3 and 9. As can be seen in
Table 3.6 and Fig. 3.11, the bandwidth reserved for most channels is equal
to 499.2 MHz. However, the bandwidth for channels 4, 7, 11 and 15 is
greater than 1 GHz and includes the bandwidth specified for more than one
of the 499.2 MHz-wide channels. The purpose is for the UWB interface to
provide a ranging/location capability of 1 m when using a 499.2 MHz
channel, and better than this when using channels 4, 7, 11 or 15.
Note that there exist frequency gaps between consecutive bands. Their
purpose is to avoid interference with other systems working in the same
environment.
Band group Channel
Center
Bandwidth
(decimal) number frequency, fc
(MHz)
(decimal)
(MHz)
0
1
2
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
499.2
3494.4
3993.6
4492.8
3993.6
6489.6
6988.8
6489.6
7488.0
7987.2
8486.4
7987.2
8985.6
9484.8
9984.0
9484.8
Mandatory/
optional
499.2 Mandatory below 1 GHz
499.2
Optional
499.2
Optional
499.2
Mandatory in low band
1331.2
Optional
499.2
Optional
499.2
Optional
1081.6
Optional
499.2
Optional
499.2
Mandatory in high band
499.2
Optional
1331.2
Optional
499.2
Optional
499.2
Optional
499.2
Optional
1354.97
Optional
Table 3.6 Channels and band groups for IEEE 802.15.4a UWB [12]
116
6/9/10
09:59
Página 117
Fig. 3.11. Proposed frequency bands and channel numbers for IEEE
802.15.4a UWB (adapted from [12])
Fig. 3.12 shows a block diagram for the UWB modulator. First, Reed-Solomon
coding (which allows error correction) is applied to the payload bits of the PPDU,
while a single error correction, double error detection (SECDED) coding is applied
to the PPDU header. Further convolutional coding is then applied to the resulting
bits. The combination of the Reed-Solomon and convolutional coding actually
implements a Forward Error Correction (FEC) technique. Spreading is then applied
according to a spreader sequence generated by a Linear Feedback Shift Register
(LFSR). The preamble is then prefixed to the header and payload bits. The PHR
and PSDU are modulated using Burst Position Modulation BPSK (BPM-BPSK).
Fig. 3.12. Block diagram of the modulator used in the UWB PHY
117
6/9/10
09:59
Página 118
Sensors Everywhere
With BPM-BPSK, each symbol is divided into two equal periods called
BPM intervals. Each one is in turn divided into two halves. The first half of a
BPM interval can contain a burst of pulses (also called chips). The second
half is left as a guard interval in which there is no signal in order to minimize
the inter-symbol interference that can be caused by multipath. Each half is
divided into an integer number of possible burst positions, but only one
burst is transmitted in a symbol. An example of this scheme is shown in
Fig. 3.13.
Each symbol carries two information bits. One is based on the BPM interval that contains the burst of pulses (also called chips). The second is based
on the polarity of the burst. In effect, the BPM-BPSK modulation is a DS-UWB
technique.
Fig. 3.13. Example of the location of a burst in a symbol in the BPM-UWB
modulation
Each UWB channel supports various bit rates. The standard specifies a
mandatory data rates for the PSDU of 851 kbps, as well as optional data
rates of 110 kbps, 6.81 Mbps and 27.24 Mbps. The different data rates are
obtained by modifying the number of chips that can be contained in a burst,
which modifies the symbol duration accordingly. The rate at which the PSDU
is transmitted is indicated in the PHR. The PHR is transmitted at 851 kbps for
all PSDU data rates, except for 110 kbps. In this case, the PHR is also transmitted at 110 kbps.
118
6/9/10
09:59
Página 119
DecaWave [13] has announced a UWB transceiver on a single integrated
circuit (IC). This circuit will be IEEE 802.15.4a-compliant and will offer 110
kbps, 850 kbps, 6.8 Mbps and 27 Mbps transmission rates, at a distance between nodes from 0 to 30 m [14]. In 2007 IMEC [15] presented the first UWB
transmitter designed in accordance with IEEE 802.15.4a.
3.5.3.3. CSS PHY of IEEE 802.15.4a
The CSS PHY uses the 2.4 GHz band and has been created with the aim
of providing good performance in terms of robustness to interference, mobility (up to 170 km/h), coverage and power consumption. Compared to IEEE
802.15.4, these improvements are possible thanks to the use of a larger
bandwidth.
The centre frequency, Fc, of each channel8, expressed in Megahertz, can
be obtained as follows:
Fc (MHz) = 2412 + 5·(channel number -1), for channel numbers between
1 and 13
Fc (MHz) = 2484, for channel number 14
(5)
Therefore, CSS PHY uses 5 MHz radio channels. The CSS PHY supports a
mandatory data rate of 1 Mbps and an optional data rate of 250 kbps.
Fig. 3.14 illustrates the modulation procedure of the CSS PHY. First, every
first bit and every second bit are separated into two different branches,
where the same operations are applied. In each branch, three bits are grouped together and mapped onto an orthogonal 4- or 16-bit codeword. (The
first case leads to a data rate at the modulator output of 1 Mbps, while the
second leads to a data rate of 250 kbps). The resulting sequence of bits is
interleaved and serialized. Then, the serialized bits from the two branches
are the input to a Differential QPSK (DQPSK) modulator. Finally, the DQPSK
8
The IEEE 802.15.4a standard is inconsistent with regard to the use of channel numbers.
The channel page definition (see Table 3.5) cites channels between 0 and 13, while the
centre frequency of each channel assumes channel numbers from 1 to 14.
119
6/9/10
09:59
Página 120
Sensors Everywhere
symbols are modulated onto a stream of chirps produced by a Chirp-Shift
Keying (CSK) generator. A chirp is a signal in which the frequency increases
or decreases with time.
Fig. 3.14. Block diagram of the modulator used in the CSS PHY
As of writing, Nanotron Technologies [16] is the only manufacturer
that implements this option of the standard. The company reports ranges
up to 570 m and bit rates of 2 Mbps, which are higher than the 1 Mbps
proposed by the standard [17]. The Nanotron solution also offers ranging
facilities.
3.5.4. IEEE 802.15.4c, IEEE 802.15.4d, IEEE 802.15.4f and IEEE
802.15.4g
At the moment of writing, other amendments to IEEE 802.15.4 focusing mainly on PHY issues are being developed. In particular, Task Group
4c and Task Group 4d of IEEE 802.15 were created with the goal of
amending IEEE 802.15.4 for supporting operation in new Chinese (315,
432 and 783 MHz) and Japanese (953 MHz) bands, respectively. Task
Group 4c has reached an agreement with the Chinese WPAN Standards
body to define a Multiple PSK (MPSK) PHY and an O-QPSK PHY.
Furthermore, Task Group 4f of IEEE 802.15 is currently developing a PHY
(and MAC) amendment to IEEE 802.15.4-2006 for active RFID applications. Finally, Task Group 4g is currently developing another PHY amendment for smart utility networks.
120
6/9/10
09:59
Página 121
3.6.
Physical layer of Bluetooth Low Energy
Bluetooth Low Energy (BT-LE) operates in the 2.4 GHz ISM band.
The band is divided into 40 RF channels with 2 MHz channel spacing.
This scheme is different from that of traditional Bluetooth9, which defines 79 frequency channels, separated by 1 MHz, also in the 2.4 GHz
band.
Bluetooth uses 16 to 32 channels as advertising channels (which are
used for broadcasting data) and the rest of channels are used as data
channels ( used for the transmission of application data). In contrast,
BT-LE defines only 3 channels as advertising channels, while the other
37 channels are defined as data channels. The small number of advertising channels is the key to a significant improvement in terms of
energy consumption in BT-LE. When a device wants to connect with
another device, the latter must be announcing that it is discoverable via
the advertising channels. Hence, the first device needs to scan the
advertising channels before connecting to the second one. While in
Bluetooth scanning the advertising channels requires 22.5 ms, in BT-LE
it takes only up to 1.2 ms. Hence, in BT-LE, the radio must be turned on
for a length of time that is one order of magnitude shorter than that of
Bluetooth.
Table 3.7 shows the frequency assignment for each channel. Note that
advertising channels operate in frequencies that minimize overlapping with
the channels typically used by IEEE 802.11.
9
Hereafter, traditional Bluetooth will be referred to as ‘Bluetooth’.
121
6/9/10
09:59
Página 122
Sensors Everywhere
Frequency (MHz) Channel number Description
2402
2404
2406
2408
2410
2412
2414
2416
2418
2420
2422
2424
2426
2428
2430
2432
2434
2436
2438
2440
2442
2444
2446
2448
2450
2452
2454
2456
2458
2460
2462
2464
2466
2468
2470
2472
2474
2476
2478
2480
37
0
1
2
3
4
5
6
7
8
9
10
38
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
39
Advertising
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Advertising
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
Advertising
IEEE 802.11
channel (in America)
1 (partially)
1
1
1
1
1
1
1
1
1
1 (partially)
6 (partially)
6
6
6
6
6
6
6
6
6
6 (partially)
11 (partially)
11
11
11
11
11
11
11
11
11
11 (partially)
Table 3.7. Assignments of radiofrequency channels in BT-LE [18]
122
6/9/10
09:59
Página 123
As Bluetooth, BT-LE uses the Gaussian FSK (GFSK) modulation, which is
an FSK modulation where a Gaussian filter is applied. This filter allows the
transitions between frequencies to be smoothed, which would otherwise
lead to a large out-of-band spectrum. In BT-LE, however, a parameter of the
modulation, which is the modulation index, is increased. This reduces the
peak power consumption, and, as a side effect, provides better range and
robustness.
The Data channels are dynamic and use adaptive FHSS, which precludes
the use of crowded frequencies in the hopping sequence. For these channels, each carrier selected by the FHSS algorithm is used as the centre frequency for the GFSK modulator (see Fig. 3.15). In contrast, the Advertising
channels are fixed.
Fig. 3.15. Block diagram of the FHSS/GFSK scheme used for the Data
channels
3.7.
Coexistence
Since ISM bands are unlicensed, many systems operate with these
bands and may indeed share them. In particular, the 2.4 GHz band is
quite crowded. Some technologies operating in this band are Bluetooth,
IEEE 802.11b/g, IEEE 802.15.4 and some types of cordless phones. In
addition, microwave ovens use 2.45 GHz irradiation [5]. Each of these systems is a potential source of interference for the others. Coexistence
requires the use of appropriate mechanisms for reducing the interference
of one system on another, and for reducing the impact of interference on
a given system.
123
6/9/10
09:59
Página 124
Sensors Everywhere
3.7.1. Coexistence of IEEE 802.15.4-2006 with IEEE 802.11b/g
IEEE 802.11b has a maximum data rate of 11 Mbps and uses DSSS
for spreading the signal bandwidth. IEEE 802.11g allows up to 54 Mbps
and uses OFDM. Both standards specify the use of 14 overlapping channels in the 2.4 GHz band and spacing between consecutive centre frequencies equal to 5 MHz, while the bandwidth of each channel is
22 MHz.
An IEEE 802.15.4-2006 signal may appear as a narrowband interferer to
an IEEE 802.11b/g device, while an IEEE 802.11b/g signal may constitute a
wideband noise for an IEEE 802.15.4-2006 node. The typical power output
of an IEEE 802.11b/g transmitter is between 12 dBm and 18 dBm, which is
greater than the typical power output of an IEEE 802.15.4-2006, which is up
to 0 dBm [3].
The centre frequencies in Megahertz in IEEE 802.11b/g are assigned
according to the following equation:
Fc = 2412 + 5·(channel number -1)
(6)
Where channel numbers are from 1 to 11, mainly in America, and from
1 to 13, mainly in Europe. Non-overlapping channels are commonly used in
IEEE 802.11b/g systems. These channels are 1/6/11 and 1/7/13, in
America and Europe, respectively.
As shown in Fig. 3.16, IEEE 802.15.4-2006 can take advantage of the
bands between non-overlapping channels for minimizing inter-system
interference; e.g., the channels 11 (2405 MHz), 15 (2425 MHz), 20
(2450 MHz), 25 (2475 MHz) and 26 (2480 MHz) are not overlapped to IEEE
802.11 channels in America frequency arrangement, although in practice
the energy of IEEE 802.11b/g channels is not zero in those regions of the
spectrum.
124
6/9/10
09:59
Página 125
Fig. 3.16. (top) IEEE 802.15.4 channels, (medium) non-overlapping IEEE
802.11 channels in America and (bottom) non-overlapping IEEE 802.11
channels in Europe. NOTE: PSD stands for Power Spectrum Density
The distance and centre frequency offset between IEEE 802.15.4 and IEEE
802.11b nodes is important for coexistence. The packet error ratio (PER) of an
IEEE 802.15.4-2006 device is smaller than 10-5 if the distance between IEEE
802.15.4-2006 and IEEE 802.11b devices is greater than 8 m. The PER of an
IEEE 802.11b device is smaller than 10-5 for a distance greater than 4 m.
Furthermore, IEEE 802.15.4-2006 and IEEE 802.11b channels suffer nearly
ignorable interference for centre frequency offsets greater than 7 MHz [20].
3.7.2. Coexistence of IEEE 802.15.4-2006 with Bluetooth and BT-LE
As already indicated in section 3.6, Bluetooth defines 79 channels in the
2.4 GHz band. The centre frequencies of these channels are as follows:
Fc = 2402 + channel number
(7)
where the channel number is between 0 and 78.
Since the IEEE 802.15.4-2006 signal in the 2.4 GHz band is 2 MHz, it may
interfere three Bluetooth channels. Since Bluetooth uses FHSS over 79
125
6/9/10
09:59
Página 126
Sensors Everywhere
channels, the maximum probability of interference between two proximal
Bluetooth and IEEE 802.15.4-2006 devices would be 3 out of 79 channel
hops. Since Bluetooth supports adaptive frequency hopping (AFH), it may
detect the channels that offer bad performance and avoid their use, thus
allowing a graceful coexistence between Bluetooth and other networks.
However, this may not occur if a bad channel is not detected, e.g. due to the
low power or low duty cycle of an IEEE 802.15.4 device [3]. A similar reasoning applies to BT-LE, which also supports AFH. The lower duty cycle of
BT-LE is an additional contributor to its coexistence with other networks.
REFERENCES
[1] T.K. Sarkar, Z. Ji, K. Kim, A. Medouri, M. Salazar-Palma, “A Survey of
Various Propagation Models for Mobile Communication”, IEEE
Antennas and Propagation Magazine, Vol. 45, No. 3, pp. 51-82, June
2003.
[2] J. Pottie, W. J. Kalser, “Wireless Integrated Network Sensors”,
Communications ACM, Vol. 43, No 5, pp. 551-558, May 2000.
[3] S. Farahani, “ZigBee Wireless Networks and Transceivers”, Elsevier,
2008.
[4] T.S. Rappaport, “Wireless Communications: Principles & Practice”,
Upper Saddle River, NJ, Prentice Hall PTR, 1996.
[5] P.E. Gawthrop et al., “Radio Spectrum Measurements of Individual
Microwave Ovens”, NTIA Report 94-303-1, March 1994.
[6] E. Faussurier, “Generic Regulation for Ultra-Wideband (UWB)
Applications in Europe”, 2nd Congress of Portuguese Committee of
URSI, November 2008. Available at http://www.anacom.pt/streaming/emmanuel_faussurier.pdf? contentId=760018&field=ATTACHED_FILE.
[7] H. Schwetlick et al., “PSSS - Parallel Sequence Spread Spectrum: A
Physical Layer for RF Communication”, IEEE International Symposium
on Consumer Electronics, 2004, pp. 262-265.
126
6/9/10
09:59
Página 127
[8]
J. Cramer, M. Z. Win, R. A. Scholtz, “Impulse Radio Multipath
Characteristics and Diversity Reception”, in Proceedings of ICC’98, 1998.
[9] IEEE 802.15.4-2006, “Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (LR-WPANs)”, September 2006.
[10] Atmel “Low-Power Transceiver for ZigBee Applications”. AT86RF230
Target Specification. 5131A-ZIGB-08/15/05.
[11] IEEE 802.15.4, “Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low-Rate Wireless Personal Area
Networks (LR-WPANs)”, May 2003
[12] IEEE 802.15.4a, “Wireless Medium Access Control (MAC) and Physical
Networks (LR-WPANs), Amendment 1: Add Alternate PHYs”, March 2007.
[13] DecaWave website: http://www.decawave.com
[14] H. Arslan, Z. N. Chen, M, Di Benedetto, “Ultra Wideband Wireless
Communication”, Wiley 2006.
[15] IMEC website: http://www2.imec.be
[16] Nanotron Technologies: http://www.nanotron.com
[17] Ultra Wideband Communications - Past, Present, and Future
http://bul.ece.ubc.ca/UWB_UBC.pdf.
[18] R. Heidon, K. Kerai, “Bluetooth Low Energy Training”, April 2009.
[19] S.Y. Seidel, T.S. Rappaport, “914 MHz Path-Loss Prediction Models for
Indoor Wireless Communications in Multifloored Buildings”, IEEE
Transactions on Antennas and Propagation, pp. 207-217, February
1992.
[20] S. Y. Shin, H. S. Park, W. H. Kwon, “Mutual Interference Analysis of IEEE
802.15.4 and IEEE 802.11b”, Computer Networks 51, pp. 3338–3353,
2007.
[21] R. Prasad, “OFDM for Wireless Communications Systems”, Artech
House, 2004.
127
6/9/10
09:59
Página 128
6/9/10
09:59
Página 129
4
MAC layer
6/9/10
09:59
Página 130
6/9/10
09:59
Página 131
Chapter 4. MAC layer
4. MAC layer
The Medium Access Control (MAC) layer is responsible for managing
access to a channel shared by several nodes. The principles of MAC layer
design for WSNs differ from those of traditional wireless networks mainly in
two aspects: i) energy conservation is the key design concern, and ii) multihop communication schemes are commonly used.
A MAC protocol for WSNs must deal with several phenomena in order to
achieve energy efficiency. Idle listening has been identified as the problem
that leads to the largest energy waste in many traditional MAC protocols [1].
Since a node does not know a priori when it can receive a message from a
neighbour, its radio must be on in order to listen to the medium. However,
the channel may be idle for most of the time. In order to save energy, many
MAC proposals keep the radio in sleep mode (i.e. switched off) during some
periods of time, trading off energy conservation for latency. Furthermore,
collisions contribute to energy inefficiency, since energy is consumed for
the transmission of a data unit that is not received successfully. In addition,
control overhead must be kept reasonably low. Finally, because a multi-hop
path requires the transmission of a data unit in several links, the nodes must
be appropriately organized to achieve good performance in terms of end-toend latency and energy consumption.
This chapter is devoted to MAC protocols for WSNs. Sections 4.1 to 4.4
present several types of MAC protocols, including proposals for WSNs that
have been conceived in research circles. These are classified into scheduling-based, contention-based, duty-cycle-based and other protocols.
Section 4.5 describes the MAC layer of IEEE 802.15.4 MAC, which is
131
6/9/10
09:59
Página 132
Sensors Everywhere
currently the de facto standard and commercial-off-the-shelf solution for
WSNs. Finally, Section 4.6 introduces the MAC functionality of Bluetooth
Low Energy, which has recently appeared on the market.
4.1.
Scheduling-based MAC protocols
Scheduling-based MAC protocols make use of dedicated resources for
node transmissions. In WSNs, the protocols in this category select specific
time intervals for the transmission of each node. This approach assumes
that nodes are synchronized, which can be performed by using timestamps
[13] or even GPS. Since nodes do not compete for the medium and have
reserved resources, scheduling-based MAC protocols are collision-free.
4.1.1.TDMA
Time Division Multiple Access (TDMA) is a MAC mechanism in which time
is divided into structures called frames, which are composed of time intervals called slots. In general, slots have a fixed size. Each slot is reserved for
the data transmission of a specific node (e.g. the n-th node uses the n-th slot
of each frame). Hence, a node has a slot for transmitting data without contention - every frame period (see Fig. 4.1). Frames of a TDMA scheme for N
devices comprise N slots.
Fig. 4.1. Example of TDMA. If slot 3 has been assigned to a user, it may
transmit at every slot 3 of each frame
A drawback of TDMA is that when nodes have no data to transmit, their
slots remain unused. However, in a WSN, a node can turn off the radio for
energy conservation during the slots of the remaining nodes. In addition,
TDMA is a simple and easy to implement approach.
132
6/9/10
09:59
Página 133
4.1.2. LEACH
Low-Energy Adaptive Clustering Hierarchy (LEACH) [2] is a protocol that
organizes a sensor network into clusters. In each cluster there is a node
called a cluster head, which is responsible for several tasks within its cluster.
With regard to MAC functionality, channel access of a LEACH node is based
on a TDMA schedule, which is established by the cluster head for all the sensors within the cluster. The details about the cluster formation and cluster
head election algorithms in LEACH are shown in Chapter 6.
4.1.3. TRAMA
The TRaffic-Adaptive Medium Access (TRAMA) protocol [14] is a conflict-free,
scheduling-based MAC protocol. TRAMA was designed for energy efficiency. This
feature is achieved by transmission schedules, which prevent collisions between
data packets (and their retransmissions), and by allowing nodes to switch the
radio to a low power mode when they are not involved in communications.
TRAMA uses a single and time-slotted channel for data and signalling
transmissions. Time is divided into scheduled- and random-access periods.
Every node disseminates one-hop neighbour information to all its onehop neighbours. In this way, all nodes obtain two-hop neighbour information. The related messages are transmitted during the random-access
period. Because the random access is based on contention, these messages
are prone to collisions.
A node announces its schedule before starting the transmission of its
data. A schedule contains the slots that will be used by a node and the
intended receivers. This information is periodically broadcast to the one-hop
neighbourhood of a node in a scheduled-access period. The time between
schedules is based on the rate at which upper layer data is generated. When
a sender has no more packets to send in its MAC queue, the vacant slots are
announced and potential senders are evaluated for reuse of those slots.
TRAMA achieves a higher percentage of sleep time and smaller collision
probability than contention-based protocols. However, these latter provide
better performance in terms of delay.
133
6/9/10
09:59
Página 134
Sensors Everywhere
4.2.
Contention-based protocols
In contention-based MAC protocols, nodes have no allocated communication resources; rather they compete for the medium and coordinate in a
probabilistic way. In consequence, collisions (i.e. situations where two or
more nodes transmit their data simultaneously) can occur.
4.2.1. ALOHA
The ALOHA protocol [3] is one of the earliest contention-based MAC protocols. In ALOHA, when a device has data to transmit, it simply transmits the
data. If a collision takes place between two or more transmissions, the senders retry the transmission later. The theoretical maximum throughput that
can be achieved with ALOHA is 18.4% of the channel capacity. The inefficiency of the protocol is due to collisions.
4.2.2. Slotted ALOHA
ALOHA was improved by introducing slots and permitting stations to
transmit only at the beginning of a timeslot. This version of ALOHA, called
Slotted ALOHA, reduced the amount of collisions and doubled the maximum throughput of ALOHA, reaching a maximum of 36.8% of the channel
capacity.
4.2.3. CSMA
Carrier Sense Multiple Access (CSMA) [4] is a channel-access mechanism
in which nodes listen to the medium to verify that there are no on-going
transmissions before transmitting data. There exist two main variants of
CSMA, namely non-persistent and p-persistent CSMA.
In non-persistent CSMA, if the medium is idle, a node transmits immediately. Otherwise, it waits a random amount of time and listens to the
medium again, repeating the same procedure. If a collision takes place
after a transmission, the node waits for a random period (this reduces the
probability of collision, since other nodes may also want to transmit data
134
6/9/10
09:59
Página 135
once the channel becomes clear) and executes the same operation again
for data transmission.
In p-persistent CSMA, if the medium is idle the node transmits with probability p or, with probability 1-p, waits for a certain period before starting
carrier sense again. A particular case of p-persistent CSMA is 1-persistent
CSMA. In 1-persistent CSMA, if the medium is idle, a node transmits (as in
non-persistent CSMA). However, if the medium is busy, it continues to listen
until the medium becomes idle and then transmits the data.
4.2.4. CSMA/CA
CSMA/CA (CSMA with Collision Avoidance) is one of the multiple access
protocols belonging to the CSMA family. In CSMA/CA, a node that has a
frame to transmit performs the following procedure: first, the node listens to
the medium. If the medium is idle then the node transmits the frame.
Otherwise, the node defers transmission for a random amount of time and
tries the transmission again. The random back-off and retry are performed
again until the channel is sensed idle or a maximum number of transmission
attempts are reached. The Collision Avoidance (CA) feature is based on the
use of acknowledgments as follows: when a device receives a data frame, it
transmits an acknowledgment to the sender. If the sender receives the acknowledgment, it can deduce that a collision has not occurred for the transmission of the data frame. Otherwise, the sender retransmits the data frame.
Essentially, CSMA/CA is based on a non-persistent CSMA scheme.
CSMA/CA forms the basis of the MAC mechanisms used in several wireless standards such as IEEE 802.11 and IEEE 802.15.4. Other standards, such
as IEEE 802.3, are based on another derivative of CSMA, which is CSMA with
Collision Detection (CSMA/CD). In this case, a node that transmits a frame
continues to listen to the medium during the transmission, but stops the
transmission if a collision is detected. This scheme can be implemented in
wired links, but wireless transceivers cannot transmit and receive at the
same time and hence use CSMA/CA.
CSMA/CA suffers from two well known problems, namely: the ‘Hidden
terminal problem’ and the ‘Exposed terminal problem’. The ‘Hidden terminal
135
6/9/10
09:59
Página 136
Sensors Everywhere
problem’ is explained next (see Fig. 4.2). Let node A and node S be nodes
within the range of receiver node R, while node A is not in the range of S.
Node A cannot detect transmissions from node S to node R. Hence, data
frames transmitted from Node A to node R will collide with simultaneous
transmissions from node S to node R.
Fig. 4.2. Hidden terminal problem
The ‘Exposed terminal problem’ occurs as shown next (see Fig. 4.3). Let
nodes B and C be neighbouring nodes. Let N be within the range of node B
but out of the range of node C. Let node M be within the range of node C
but out of the range of node B. Node B is prevented from transmitting a
frame to node N when node C is transmitting to node M (note that in this
case this transmission would not affect node B transmission).
Fig. 4.3. Exposed terminal problem
136
6/9/10
09:59
Página 137
The hidden terminal and exposed terminal problems can be mitigated by
using the so-called Request-To-Send/Clear-To-Send (RTS/CTS) mechanism,
in which a node wishing to send data sends an RTS frame to the destination,
which replies to the sender by transmitting a CTS frame. If a node that has
data to transmit overhears an RTS or a CTS frame, it executes a back-off procedure, thus deferring the transmission. With the RTS/CTS mechanism, RTS
frames can suffer collisions. However, since these frames are short in comparison with data frames, the cost of collisions is significantly decreased.
4.2.5.Sift
Sift [5] is a MAC protocol designed in order to address appropriately the
following characteristics of event-driven WSNs: i) Nodes in the same area
may sense the same event, which leads to spatially-correlated contention; ii)
in many WSN applications, it is not necessary for all nodes to report the
same event. Classical CSMA protocols neither handle the first property nor
exploit the second one.
Given the problems described, and assuming that N nodes sense the same
event, Sift is designed to minimize the time taken to send the first R messages
out of the total of N messages. The remaining N - R messages can then be suppressed in order to increase energy efficiency and decrease channel load.
In contrast with traditional contention window schemes, where the contention window increases after a collision, Sift uses a fixed-size contention
window. Thus, very low channel access latency can be achieved. In order to
avoid a high collision probability, a geometrically-increasing probability distribution is used for slot selection so that the later slots have a greater probability of being selected. If no node starts to transmit in the first slot of a
window, then the probability of choosing the second slot is greater (the
intuition behind this scheme is that if no node transmits in the first slot, the
number of competing nodes is not as large as a node might have believed).
The same applies for the remaining slots of a window.
The significant low latency of Sift is traded off for increased energy consumption, since a node has to listen to all slots before sending (which is not
necessary in traditional contention window protocols). Another drawback is
137
6/9/10
09:59
Página 138
Sensors Everywhere
increased overhearing, since when there is an ongoing transmission, nodes
must listen until the end in order to contend for the next transmission, which
causes overhearing [6].
4.3.
Duty-cycle-based protocols
The main characteristic of duty-cycle-based MAC protocols is that devices turn off the radio during certain periods for the sake of energy conservation. These protocols differ in how they select their active/sleep periods
and in how they coordinate for transmitting data.
4.3.1. S-MAC
The Sensor-MAC (S-MAC) [7] protocol was designed for the goal of low
energy consumption. One of the fundamental mechanisms of S-MAC is that
nodes listen to the medium for a certain period and subsequently go into
sleep mode, turn off the radio and set a timer for the next wake up to verify
whether another node wants to talk to it. The duty cycle can be adjusted
according to application and performance requirements.
Every node periodically broadcasts a SYNC packet to its neighbours. This
packet includes the listen/sleep schedule of the node. This allows neighbouring nodes to synchronize and set up a common listen/sleep schedule.
Note that, in some cases, two neighbouring nodes will not be synchronized
if they have to be synchronized with other neighbours. Synchronized nodes
form a virtual cluster. If two neighbouring nodes A and B belong to different
clusters, and node A wants to transmit some data to node B, node A waits
until node B is listening. Although the listen/sleep scheme decreases energy
consumption, latency increases. However, some WSN applications (e.g.
monitoring) tolerate certain latencies very well.
S-MAC includes a number of collision-avoidance mechanisms. Each
transmitted packet includes a duration field that indicates how long the
remaining transmission will be. Nodes that receive a packet sent to another
node record the duration in a Network Allocation Vector (NAV) and update
138
6/9/10
09:59
Página 139
its value periodically. When a node has data to transmit, it first checks the
NAV. If it is not zero, the medium is assumed to be busy. This mechanism is
called virtual carrier sensing. In addition, physical carrier sense is performed
by listening to the channel. A node decides that the medium is free if both
virtual and carrier find that the medium is free.
A node with data to transmit waits until the medium is free and the receiver is listening. RTS/CTS is used to avoid the hidden terminal and
exposed terminal problem. After a successful RTS/CTS exchange, data is
transmitted in accordance with the listen/sleep schedule of the nodes. An
ACK is sent by the receiver in response to correctly received data.
Because sleep and listen periods are predefined and constant, S-MAC is
well suited for fixed traffic load. The efficiency of the protocol decreases
under variable traffic load.
4.3.2. T-MAC
Timeout-MAC (T-MAC) [1] is designed to enhance the performance of
S-MAC under variable traffic loads. Variable loads are expected in many WSN
environments. For example, in applications where a sink collects information
reported by the sensors, the nodes closest to the sink must relay more traffic than those far from it. In addition, traffic may change over time depending
on the application.
T-MAC is essentially based on S-MAC. However, T-MAC adaptively modifies the duration of the active periods of S-MAC. In particular, the listen
period ends when no event requiring the radio to be active has occurred for
a time (see Fig. 4.4). This scheme enables unnecessary energy consumption
to be reduced.
4.3.3. DSMAC
Dynamic Sensor-MAC (DSMAC) [8] is a variant of S-MAC designed to
achieve better performance than S-MAC in terms of latency. In fact, delaysensitive applications (e.g. health, alarms, military areas, etc.) exhibit low
latency requirements.
139
6/9/10
09:59
Página 140
Sensors Everywhere
DSMAC achieves low latency by adaptively reducing the sleep time of
nodes when the average one-hop latency is high (see Fig. 4.4). This onehop latency is defined as the time-difference between the moment at
which a packet gets into the queue of a node and the instant at which the
packet is sent out. This value is written in the packet header. The receiver
collects this value and updates the average of the one-hop latencies
measured in the current SYNC period. If this one-hop latency estimation
exceeds a certain threshold, and providing that energy consumption is
tolerable, the node doubles its duty cycle by reducing the sleep time
accordingly. The new duty cycle is broadcasted in the next SYNC packet.
Nodes that overhear this SYNC message and have packets in their
queues will also double their duty cycle. Nodes with different sleep/listen schedules can still communicate, since the duty cycles used are
multiples of the lowest duty cycle.
DSMAC improves the latency performance of S-MAC while maintaining
an acceptable level of energy consumption.
Fig. 4.4. Example of the active and sleep intervals in S-MAC, T-MAC and
DSMAC
140
6/9/10
09:59
Página 141
4.3.4. DMAC
DMAC10 was essentially designed to achieve very low latency while still
remaining energy efficient, in the context of applications where data are
delivered to a sink node through a tree composed of multihop paths [15]. In
particular, the purpose of DMAC was to solve the so-called data forwarding
interruption problem that occurs in a multihop path of active/sleep cycle
nodes. This problem arises when a node in an active state transmits a packet and the next hop is also in an active state, but the next nodes in the path
are in sleep mode (e.g. because of their fixed duty cycles, as in S-MAC, or
because they go to sleep, as in T-MAC, since they cannot overhear the transmission). The transmitted packet must be queued until the next active
period, which increases latency.
In DMAC, an interval is composed of receiving, sending and sleeping
periods (in the latter the radio is turned off for energy conservation). DMAC
uses a staggered wake up schedule, so that a node transmitting data for the
sink will use the sending period for the transmission, which is coincident
with the receiving period of its next hop. As in a chain reaction, the same procedure is repeated in all the intermediate nodes, so data do not suffer sleep
latency (see Fig. 4.5).
Fig. 4.5. Example of DMAC in a data gathering tree
Nodes with the same hop distance to the sink have a synchronous
schedule. During the receiving period of a node, all its child nodes have
10
What DMAC stands for was not indicated in the paper describing the protocol [15].
141
6/9/10
09:59
Página 142
Sensors Everywhere
sending periods that contend for the medium. Hence, DMAC can be under-
stood as an improved Slotted Aloha algorithm in which slots are assigned to
the sets of nodes to form a tree structure.
DMAC has a mechanism that allows a node to increase the duty cycle of
the nodes in its multi-hop path to the sink, should it have more than one
packet to be transmitted in the same sending slot. Another technique used
in DMAC is data prediction, which allows a receiver to switch back to receiving state rapidly if the aggregated rate at an intermediate node exceeds
the capacity of the basic duty cycle. Additionally, DMAC deals with the
interruption that a flow may suffer if two neighbouring nodes with different
parents have data to transmit at the same time. This problem is solved by
the use of More To Send (MTS) control packets.
DMAC achieves very good latency compared to other sleep/listen period
assignment methods, such as S-MAC. However, because collision avoidance
methods are not utilized, when a number of nodes with the same tree level
try to send to the same node, collisions will occur.
4.4.
Other protocols
This section is devoted to MAC protocols of a different nature from those
described in the previous sections.
4.4.1. STEM
STEM (Sparse Topology and Energy Management) [9] is a protocol that assumes that in many applications nodes may be sleeping for most of the time,
until they detect an event that has to be reported (e.g. to a sink) and for which
a multi-hop path to the destination must be formed. In the sleep state, nodes
retract from the network topology, and hence the topology can be sparse.
The key feature of STEM is that it operates on nodes equipped with two
radios at different frequency bands. One band is used for communications in the
‘wake up plane’ and the other one is used for the ‘data plane’. A node that wants
to communicate with a neighbour uses the wake up band for sending beacons
142
6/9/10
09:59
Página 143
that include the identifier of the neighbour. When this target node, which periodically listens to the wake up band, receives the beacon, it sends a response to the
initiator and both nodes activate the data plane radio. Once the data transmission has finished, both nodes turn off the data plane radio. This procedure is
repeated for each hop in the multi-hop path towards the destination.
The approach used by STEM trades off considerable energy savings by a
latency increase, which is a consequence of the time needed for waking up
every intermediate node in the multi-hop path.
4.4.2. WiseMAC
The WiseMAC protocol [10] combines several techniques. WiseMAC uses
non-persistent CSMA with preamble sampling to decrease idle listening. In the
preamble sampling technique, a preamble precedes each data packet for alerting the receiving node. If a node finds the medium busy after it wakes up and
samples the medium, it continues to listen until it receives a data packet or the
medium becomes idle again. According to the neighbours’ sleep schedule
tables (which nodes learn through reception of acknowledgments from neighbours), WiseMAC schedules transmissions and dynamically determines the
preamble length so that the destination node’s sampling time corresponds to
the middle of the sender’s preamble, which results in energy-saving.
Simulations have shown that WiseMAC performs better than one of
S-MAC variants. Furthermore, the dynamic preamble length adjustment
results in better performance under variable traffic load. The main drawback
of WiseMAC is that decentralized sleep-listen schedules give rise to different
sleep and wake up times for each neighbour. This is a problem for broadcast
packets, since they will be buffered for neighbours in sleep mode and will be
delivered many times as each neighbour wakes up.
4.5.
Comparison of MAC protocols
The previous sections presented the main proposals of MAC protocols for
WSNs, categorized as scheduling-based, contention-based, duty cyclebased and other protocols. Table 4.1 shows a comparative summary of the
143
6/9/10
09:59
Página 144
Sensors Everywhere
main features of each particular MAC protocol. While scheduling-based MAC
protocols are collision-free, contention-based ones are not and thus incur
greater energy consumption. However, in terms of delay the latter offer better performance than scheduling-based protocols. The various types of
duty-cycle-based MAC protocols turn off the radio of devices during certain
periods in order to save energy. These protocols trade energy savings for
latency. Finally, other approaches follow different principles, such as the use
of a wake-up plane in addition to the data plane, or combinations of contention-based and duty-cycle-based mechanisms.
MAC
Protocol
Category
MAC
Protocol
Scheduling- TDMA
Based
144
Basic
Function
Additional
Features
Time divided into
None
Frames / Slots
(typically fixed size).
Each slot is reserved
for the data
transmission of a
specific node
Pros
Energy
conservation
by turning off
the radio
Cons
When nodes
have no data
to transmit, their
slots remain
unused
Simple and
easy to
implement
approach
LEACH
TDMA schedule
version
Arrangement of Energy
sensor nodes in conservation
clusters
by turning off
the radio
When nodes
have no data to
transmit, their
slots remain
unused
TRAMA
Conflict – free
scheduling.
Single and timeslotted channel
for data and
signalling
transmissions.
Time is divided
into scheduledand randomaccess periods
Allow nodes to Designed for
switch the radio Energy
to a low power Efficiency
mode
Poor delay
performance
compared to
contention
based protocols
6/9/10
09:59
Página 145
MAC
Protocol
Category
MAC
Protocol
Contention- ALOHA
Based
Basic
Function
Additional
Features
Pros
Cons
When a device has
data to transmit, it
simply transmits
the data
None
Simple
approach
Inefficiency
due to
collisions
Slotted
ALOHA
ALOHA version
Introduces slots
and permits
stations to
transmit only at
the beginning
of a timeslot
Simple
approach.
Offers twice
the maximum
throughput of
ALOHA
Inefficiency
due to
collisions
Requires
synchronization
CSMA
Nodes listen to
the medium to
verify that there are
no on-going
transmissions before
transmitting data
Non-persistent
CSMA and
Persistent
CSMA
Offers more
Greater
throughput
complexity
than ALOHA
than ALOHA
-based schemes
CSMA/CA CSMA version
(non- persistent)
Collision
Avoidance
(CA) feature
reduces
probability of
collision
Used in IEEE
802.11 and
IEEE 802.15.4.
Sift
Uses a fixed
Very low
size contention channel access
window
latency can be
achieved
Event-driven
protocol optimising
event reporting by
a set of nodes in a
given area
Suffers from
“Hidden
Terminal” and
“Exposed
Terminal”
problems,
mitigated by
Request-ToSend/Clear-ToSend (RTS/CTS)
mechanism
Increased
energy
consumption
Increased
Overhearing
145
6/9/10
09:59
Página 146
Sensors Everywhere
MAC
Protocol
Category
Duty-CycleBased
MAC
Protocol
S-MAC
Basic
Function
Nodes listen to
the medium for a
certain period,
and after that they
go into sleep mode
Additional
Features
Pros
Sleep /wake up Low Energy
functionality
Consumption
Synch nodes
Well suited for
forming a virtual fixed traffic
cluster
load
Cons
Efficiency
decreases
under
variable traffic
load
Collision
avoidance
mechanisms
146
T-MAC
S-MAC version
which adaptively
modifies the
duration of the
active periods of
S-MAC
Optimised for
variable traffic
load
The same and
well suited for
variable traffic
load
Latency
inefficiencies
DSMAC
S-MAC version
which adaptively
reduces the sleep
time of nodes when
the average onehop latency is
high
Average onehop latency
info in the
packet header
Improves
latency
Less energy
efficiency than
S-MAC
DMAC
DSMAC version
which solves the
“Data Forwarding
Interruption”
problem in a multihop path of active/
sleep cycle nodes
Staggered wake
up schedule:
The sending
period for the
transmission is
coincident with
the receiving
period of its next
hop, forming a
tree structure
of nodes.
Good trade-off Collision
between
problems may
latency and
occur
energy
efficiency
6/9/10
09:59
Página 147
MAC
Protocol
Category
MAC
Protocol
Basic
Function
Additional
Features
Pros
Cons
Mechanism to
increase the
duty cycle of
the nodes
- Data
Prediction
technique (to
avoid exceeding
duty cycle
capacity)
Others
STEM
Nodes may be
sleeping for most
of the time, until
they detect an
event that has
to be reported
WiseMAC
Uses nonpersistent CSMA
with preamble
sampling to
decrease idle
listening
Nodes equipped High Energy
with two radios savings
at different
frequency
bands. One
is used for
communications
in the ‘wake up
plane’ and the
other is used for
the ‘data plane’
Latency
increases
Energy savings Inefficiency
data delivery
Better
because
performance
decentralized
than S-MAC
sleep-listen
variants for
schedules
variable traffic results in
loads
different sleep
and wake up
times for each
neighbour
Table 4.1. A comparative summary of MAC protocols
147
6/9/10
09:59
Página 148
Sensors Everywhere
4.6.
IEEE 802.15.4 MAC
This section describes the main features of the IEEE 802.15.4 MAC layer.
4.6.1. Device types and roles
IEEE 802.15.4 defines two types of devices, namely: Full Function
Devices (FFDs) and Reduced Function Devices (RFDs). The first can perform
all the tasks specified in the standard, while the second are limited. For instance, an RFD can only communicate with an FFD. In contrast, FFDs can
communicate with any other type of device. RFDs are expected to exhibit a
higher degree of hardware constraints than FFDs.
IEEE 802.15.4 defines three roles, namely: PAN coordinator, coordinator
and device. FFDs can perform all the roles, while RFDs can only act as devices. A coordinator is capable of relaying messages. If a coordinator is the
main controller of the network, it is called a PAN coordinator. A node that is
not a coordinator is called a device.
4.6.2. Network configuration
An IEEE 802.15.4 network may fall into one of the following configuration
categories: i) beacon-enabled or ii) non-beacon-enabled. In the first category, the network uses a superframe structure bounded by network beacons (see subsection 4.5.3), which is absent in the second one. The channel
access mechanism used depends on the network configuration.
4.6.3. Superframe structure
An IEEE 802.15.4 network may use a superframe structure, which
requires the presence of a coordinator in the network. The superframe is
divided into 16 slots of the same size and is bounded by network beacons
(see Fig. 4.6). These beacons describe the specific format of the superframe,
identify the PAN and are used for synchronization. The coordinator is in
charge of transmitting the network beacons at predetermined intervals, between 15 ms and 251 s.
148
6/9/10
09:59
Página 149
The superframe may have an inactive period during which nodes enter a
low-power mode and cannot transmit data. Hence, communication takes
place only during the active period. The active period is composed of the
Contention Access Period (CAP) and, optionally, the Contention Free Period
(CFP). During the CAP, any device uses slotted CSMA/CA for channel access.
The CFP may be composed of up to seven Guaranteed Time Slots (GTSs),
which are portions of the superframe devoted to a specific application. GTSs
are useful for applications that require low latency or a certain bandwidth.
All transactions have to be completed before the next superframe period.
Fig. 4.6. Example of a superframe. The CFP contains two GTS of
different sizes
4.6.4. IEEE 802.15.4 CSMA/CA mechanisms
Beacon-enabled networks use a slotted CSMA/CA mechanism for channel access. When a device has data to be transmitted, it aligns with the next
slot and waits for a number of slots that is obtained randomly. This procedure is known as back-off. After the back-off period, the device senses the
medium. If the medium is idle, then the device transmits the data.
Otherwise, the device performs another back-off procedure again, up to a
maximum number of times.
Non-beacon-enabled networks use also a CSMA/CA channel access
mechanism, but in contrast with the aforementioned one, it is unslotted.
149
6/9/10
09:59
Página 150
Sensors Everywhere
In any case, acknowledgments (see subsection 4.5.4) and beacons are
transmitted without using the CSMA/CA mechanism.
4.6.5. Error control
IEEE 802.15.4 allows reliable communication (by the use of acknowledgments) and unreliable communication. If a frame is successfully
received, the receiving device can confirm that situation by transmitting
an acknowledgment. Beacon frames and acknowledgments are never
acknowledged.
In reliable mode, if the sender does not receive an acknowledgment,
it assumes that the transmission was not successful and carries out a
retransmission. Several retries can be performed up to a maximum
number.
In applications where reliability requirements are relaxed, or in deployments with a low error probability, network designers may prefer not to use
acknowledgments for saving energy. In this case, the sender of a frame
assumes that the transmission is always successful.
In order to detect errors, a 16-bit ITU-T Cyclic Redundancy Check (CRC)
mechanism is used. The CRC is computed on the header and the payload of
a frame.
4.6.6. IFS
Frame transmission is followed by an InterFrame Space (IFS) to allow the
MAC layer a finite time for processing the data received at the PHY layer. In
the reliable mode, the IFS follows the acknowledgment frame. Before starting a back-off period, the device waits for an IFS.
After the transmission of a long frame, a Long IFS (LIFS) follows, while
after transmission of a short frame, a Short IFS (SIFS) follows. Fig. 4.7 and Fig.
4.8 show examples of acknowledged and unacknowledged transmissions
with their related LIFS and SIFS, respectively.
150
6/9/10
09:59
Página 151
Fig. 4.7. Example of acknowledged transmissions and the related IFSs
Fig. 4.8. Example of unacknowledged transmissions and the related IFSs
4.6.7. Data transactions
Three types of data transactions can take place in an IEEE 802.15.4 network: i) from a device to a coordinator, ii) from a coordinator to a device, and
iii) data transmission between two peers.
4.6.7.1. Data transfer from a device to a coordinator
In a beacon-enabled network, a device that wishes to transfer data first
synchronizes to the superframe and then transmits the data to the coordinator using slotted CSMA/CA. The coordinator may optionally transmit an
ACK to the device after successful reception of the data.
In a non-beacon-enabled network, a device transmits its data frame to
the coordinator using unslotted CSMA/CA. Successful reception of the data
frame may be optionally acknowledged by the coordinator.
4.6.7.2. Data transfer from a coordinator to a device
In a beacon-enabled network, when the coordinator has data to
transmit to a device, it indicates in the beacon that the data is pending
151
6/9/10
09:59
Página 152
Sensors Everywhere
for that device. If the device listens to the beacon and finds that a message is pending for it, then it sends a data request to the coordinator
using slotted CSMA/CA, which may be optionally acknowledged by the
coordinator. The pending message is then sent using slotted CSMA/CA
and in case of successful reception can be optionally acknowledged by
the device. The approach of this data transfer allows flexibility in the
sleep schedules of the devices, which are not forced to listen to all the
beacons.
In a non-beacon-enabled network, a device may send a request for
data to the coordinator using unslotted CSMA/CA. The coordinator acknowledges the data request if it has been successfully received. If the
coordinator has pending data for the device, it transmits the data frame
using unslotted CSMA/CA. Otherwise, the coordinator sends a data
frame with a zero-length payload using the same mechanism. If the
data frame is successfully received by the device, it sends an acknowledgement to the coordinator.
4.6.7.3. Data transfer between peers
In a peer-to-peer topology, a node can communicate with any other
node within its transmission range. The 2003 standard offers two options to
make this scheme possible: i) nodes receive constantly and send data using
unslotted CSMA/CA, or ii) nodes synchronize with each other. However, no
method is specified for synchronization.
4.6.8. Frame formats of IEEE 802.15.4 MAC
IEEE 802.15.4 specifies four types of MAC frames, namely: beacon frame,
data frame, acknowledgment frame and MAC command frame. In general,
the formats of these frame types are composed of three main parts: the
MAC header (MHR), the MAC service data unit (MSDU) and an MAC footer
(MFR).
The MHR contains the frame control, sequence number and addressing information fields. The frame control field has a size of two
bytes and contains information about the frame type, addressing fields
152
6/9/10
09:59
Página 153
and other control flags. The sequence number field has a size of one
byte and specifies a unique number for a frame. The addressing fields
may include a two-byte destination PAN identifier, a 16- or 64-bit destination address, a two-byte source PAN identifier and a 16- or 64-bit
source address.
The purpose of the MSDU (and its presence) depends on the frame type.
The MFR is a 16-bit Frame Check Sequence (FCS).
4.6.8.1. Beacon frame
Fig. 4.9 illustrates the structure of the beacon frame. The addressing
fields contain only the PAN identifier and the address of the device that
transmits the frame. The superframe specification codifies parameters related with the superframe structure, such as the interval between beacons,
the length of the CAP, etc. The GTS fields include information about the devices that take advantage of GTSs and the resources devoted to them. The
pending address fields specify the list of addresses for which the coordinator has pending messages.
Fig. 4.9. Format of the IEEE 802.15.4 beacon frame
4.6.8.2. Data frame
Fig. 4.10 shows the structure of the data frame. The addressing fields
may comprise the destination address and/or the source address fields,
depending on the values encoded in the frame control field.
153
6/9/10
09:59
Página 154
Sensors Everywhere
Fig. 4.10. Format of the IEEE 802.15.4 data frame
4.6.8.3. Acknowledgment frame
Fig. 4.11 depicts the structure of the data frame. Note that ACKs do
not contain an MSDU. Another relevant fact is that ACKs do not have
addressing fields. This feature may lead to false positives. For example,
a node A transmits data to a node B, and after that A receives an ACK.
The ACK could have been transmitted by another node (e.g. node C) in
the range of node A, but could be misunderstood by node A as an ACK
sent by node B.
Fig. 4.11. Format of the IEEE 802.15.4 acknowledgment frame
4.6.8.4. MAC command frame
Fig. 4.12 shows the structure of the MAC command frame. The addressing fields contain the destination address fields and/or source address
fields, depending on the values encoded in the frame control field. The
MSDU is composed of a one-byte command frame identifier, which indicates the type of command and a variable length payload, which includes
the MAC command itself.
154
6/9/10
09:59
Página 155
Fig. 4.12. Format of the IEEE 802.15.4 command frame
4.6.9. Performance of an IEEE 802.15.4-2003 peer-to-peer link
In many deployments, IEEE 802.15.4 is used in its peer-to-peer configuration. In this case, unslotted CSMA/CA is used. Some performance results
for this mode are provided below in terms of throughput and delay.
The maximum user data throughput of a bulk data transmission between
a single sender and a single receiver through an unslotted IEEE 802.15.42003 channel in ideal conditions is as shown in Table 4.2 [11]. Note that
these figures are the highest possible ones under each specific set of conditions (address length, use of ACKs, physical layer channel, etc.).
MAC
address
length
Mode
Maximum user data throughput (kbps)
868 MHz band 915 MHz band 2.4 GHz band
16 bit
Reliable
Unreliable
14.3
15.5
28.6
31.1
139.0
151.6
64 bit
Reliable
Unreliable
12.8
13.9
26.6
27.8
124.4
135.6
Table 4.2. Maximum user data throughput with unslotted
IEEE 802.15.4-2003 [11]
The maximum user data throughputs (at three different frequency
bands) for 16 bit MAC address length and Reliable mode shown in Table 4.2
correspond to the bit rates per channel at PHY layer shown in Table 3.2 of
Chapter 3. The range of latencies of a frame transmission between a single
sender and a single receiver through an unslotted IEEE 802.15.4-2003 chan-
155
6/9/10
09:59
Página 156
Sensors Everywhere
nel in ideal conditions are as shown in Table 4.3 [11]. In the case of reliable
communications, the latency indicated in the table equals the round trip
time, which includes the delay for reception of the ACK.
MAC
address
length
Mode
Maximum user data throughput (kbps)
868 MHz band 915 MHz band 2.4 GHz band
16 bit
Reliable
Unreliable
[16.7, 63.7]
[11.7, 58.7]
[8.35, 31.85]
[5.85, 39.85]
[2.46, 6.56]
[1.92, 6.02]
64 bit
Reliable
Unreliable
[17.9, 58.7]
[22.9, 63.7]
[11.45, 31.82]
[8.95, 29.35]
[3.30, 6.56]
[2.75, 6.02]
Table 4.3. Range of latencies with unslotted IEEE 802.15.4-2003
Note that, as shown in Table 4.3, latency decreases as the available bandwidth increases.
4.6.10. IEEE 802.15.4e
At the time of writing, the IEEE 802.15 Task Group 4e is working to develop an amendment to IEEE 802.15.4-2006. The purpose of this amendment is to provide additional functionality to the IEEE 802.15.4-2006 MAC
layer, the better to satisfy requirements of industrial markets and for improved compatibility with the Chinese WPANs [12].
The application spaces currently being considered for IEEE 802.15.4e are:
Factory Automation, Process Automation, Asset Tracking, General Sensor Control
(Industrial/Commercial, including Building Automation), Home Medical
Health/Monitor, Telecom Application, Neighbourhood Area Networks and Audio.
4.7.
Bluetooth Low Energy MAC
This section presents the main features of BT-LE MAC layer [16]. The MAC
fundamental mechanism used in BT-LE is a TDMA based polling scheme,
whereby one device transmits a packet at a predetermined time and a
corresponding device responds with a packet after a predetermined interval.
156
6/9/10
09:59
Página 157
4.7.1. State diagram
BT-LE operation at link layer is based on a state machine designed for low
power operation. As shown in Fig. 4.13, the number of states and the
amount of state transitions are both small.
Fig. 4.13. State diagram of BT-LE link layer
The state diagram has five states, namely: standby, scanning, initiating,
advertising and connecting. In the standby state, a device is inactive. The
device may transition to the scanning state, in which a device listens for
advertisers. From the standby state, a device may transition to the advertising state, in which a device sends advertisement messages for advertising itself, or to the initiating state, where a device wants to connect to
another device. A device in the initiating state (hereafter referred to as the
initiator) listens for advertisements. When such a message is received by
the initiator, this device sends a Connect Request message to the advertiser for initiating a connection and enters the connecting state as a master. When the advertiser receives this message, it enters the connecting
state as a slave.
157
6/9/10
09:59
Página 158
Sensors Everywhere
This procedure is more simple than that of Bluetooth, where a connection always has to be started by a device as a master, and if the device wants
to act as a slave during the connection, the roles of the devices have to be
switched, which consumes a significant amount of energy.
The Connect Request message includes information about the connection, such as the frequency of communication, the frequency hopping
sequence that will be used, etc.
4.7.2. Data transaction
BT-LE allows low latency transactions for data transmission. Fig. 4.14
illustrates the complete dialogue between two devices, where the advertiser
wishes to transmit data to the initiator. Once the initiator has become a master, it requests the data from the advertiser. The advertiser then sends the
data to the master, which replies with an acknowledgement if the data have
been correctly received. If the slave has no more data to transmit, it indicates that it wants to close the connection by sending a link layer (LL)
Terminate message.
Fig. 4.14. Connection and data transmission message chart
158
6/9/10
09:59
Página 159
The total time between the transmission of the advertisement and
the confirmation of the connection termination by the master is less
than 3 ms. During this time, the radio is actually turned on for less than
1.5 ms.
4.7.3. Frame format
This subsection presents the general frame format and some details
about the structure of the advertisement frame and for the data frame.
4.7.3.1. General frame format
Fig. 4.15 shows the general frame format of a BT-LE frame. The frame
starts with a one-byte preamble, which contains one of the following two
sequences: 01010101 or 10101010. These sequences allow receivers
performing automatic gain control at the physical layer to increase the
probability of correct reception of the frame. The next field is the Access
address, which is a 32-bit identifier of the destination device. In contrast,
Bluetooth addresses have 64 bits. In the advertising channel, the Access
address is set to a broadcast address, which is a fixed value. In data channels, the Access address is a random number chosen by the master and
transmitted in the Connect Request message. The random number is
chosen for each connection, which is beneficial for security. The next
field is the payload, which has a maximum size of 39 bytes. The last field
is a 24-bit CRC, which is larger than the 16-bit CRC used in other radio
technologies, such as IEEE 802.15.4. The use of a 24-bit CRC offers high
robustness in noisy environments.
Fig. 4.15. Format of a BT-LE frame
159
6/9/10
09:59
Página 160
Sensors Everywhere
4.7.3.2. Advertising frame format
An advertising frame includes a header field and a length field (see Fig.
4.16). The header indicates the type of advertising frame, which includes
information about the intent of the frame. The length field is needed because the payload has a variable length.
Fig. 4.16. Format of an advertising BT-LE frame
4.7.3.3. Data frame format
The data frame has the same general format as the advertising frame. The
header contains two relevant bits used for flow control, namely: the sequence
number and the next expected sequence number. Acknowledgements
actually use the same frame format, but do not contain the payload field.
4.7.4. Acknowledgment and flow control
In Bluetooth, an acknowledgment is sent after every data transmission.
To minimize the amount of frame transmissions, BT-LE introduces a sliding
window scheme. Data frames have a sequence number (which can be ‘0’ or
‘1’). Because data (and acknowledgment) frames contain the next expected
sequence number, an acknowledgment is not needed after the transmission of every data frame. This approach (also used in other protocols such
as TCP) contributes to energy-saving.
REFERENCES
[1] T. V. Dam, K. Langendoen, “An Adaptive Energy-Efficient MAC Protocol
for Wireless Sensor Networks,” 1st ACM Conf. Embedded Networked
Sensor Sys., Los Angeles, CA, November 2003.
160
6/9/10
09:59
Página 161
[2] W. Rabiner Heinzelman, A. Chandrakasan, H. Balakrishnan, “EnergyEfficient Communication Protocol for Wireless Microsensor
Networks”, in proceedings of the 33rd Hawaii International
Conference on System Sciences, Island of Maui, Hawaii, USA,
January 2000.
[3] N. Abramson, “Development of the ALOHANET”, IEEE Transactions on
Information Theory, Vol. 31, No. 2, pp. 119-123, March 1985.
[4] L. Kleinrock, F. Tobagi, “Packet switching in radio channels. Part I –
Carrier sense multiple access modes and their throughput delay characteristics”, IEEE Transactions on Communications, Vol. 23, No. 12, pp.
1400-1416, December 1975.
[5] K. Jamieson, H. Balakrishnan, and Y. C. Tay, “Sift: A MAC Protocol for
Event-Driven Wireless Sensor Networks,” MIT Lab. Comp. Sci., Tech. rep.
894, May 2003.
[6] I. Demirkol, C. Ersoy, F. Alagoz, “MAC Protocols for Wireless Sensor
Networks: a Survey”, IEEE Communications Magazine, pp. 115-121,
April 2006.
[7] W. Ye, J. Heidemann, D. Estrin, “Medium Access Control with
Coordinated Adaptive Sleeping for Wireless Sensor Networks”,
IEEE/ACM Transactions on Networking, Vol. 12, No. 3, pp. 493-506,
June 2004.
[8] P. Lin, C. Qiao, and X. Wang, “Medium Access Control with a Dynamic
Duty Cycle for Sensor Networks,” in proceedings of the IEEE WCNC,
March 2004.
[9] C. Schurgers, V. Tsiatsis, M Srivastava, “STEM: Topology Management for
Energy Efficient Sensor Networks”, in proceedings of the IEEE
Aerospace Conference, March 2002.
[10] C. C. Enz et al., “WiseNET: An Ultralow-Power Wireless Sensor Network
Solution”, IEEE Comp., Vol. 37, No. 8, pp. 62-70, August 2004.
[11] B. Latre et al. “Throughput and Delay Analysis of Unslotted IEEE
802.15.4”, Journal of Networks, Vol. 1, No. 1, pp. 20-28, May 2006.
161
6/9/10
09:59
Página 162
Sensors Everywhere
[12] IEEE 802.15 Task Group 4e web page:
http://www.ieee802.org/15/pub/TG4e.html
[13] J. Elson, D. Estrin, “Time synchronization for wireless sensor networks”,
in proceedings of IPDPS 2001, April 2001.
[14] V. Rajendran, K. Obraczka, J.J. Garcia-Luna-Aceves, “Energy Efficient,
Collision Free Medium Access Control for Wireless Sensor Networks”, in
proceedings of SenSys’03, Los Angeles, CA, USA, November 2003.
[15] G. Lu, B. Krishnamachari, and C. S. Raghavendra, “An Adaptive EnergyEfficient and Low-Latency MAC for Data Gathering in Wireless Sensor
Networks,” in proceedings of the 18th International Parallel and
Distributed Processing Symposium, April 2004.
[16] “Specification of the Bluetooth System”, Covered core package version:
4.0, December 2009.
162
2/7/10
13:19
Página 163
5
Sensor node platforms
2/7/10
13:19
Página 164
2/7/10
13:19
Página 165
Chapter 5. Sensor node platforms
5. Sensor node platforms
The origins of WSNs can be found in the eighties in the area of military
applications, but the origin of the concepts currently in use is the Smart
Dust project [12], also funded by the US military. The objectives of this project were pretty ambitious but some designs based on Commercial Off-TheShelf define the basic architectural principles of WSNs. A wireless sensor
node is composed of a set of hardware components that allow two carry out
tasks such as measurement, processing and transmission. These elements
are combined according to a general architecture, but nowadays there exists
a large variability of these components that can result in different solutions
optimised for certain applications. The content of this chapter presents the
different elements and the possible options.
5.1.
Sensor node architecture elements
A sensor or an actuator node has the ability to sense or activate an
element, process the related information and transmit it. Also, such
nodes are able to collaborate with other nodes in creating a network and
moving the information either within the WSN or to some external server
connected to another network like the Internet. To perform all these
functions, a minimum set of elements is needed. This set comprises a
processor (with the corresponding memory and input and output lines),
a transceiver for the communication, one or several sensors and actuators and power supply. Fig. 1.1 from chapter 1 presents a view of these
elements and their relationship.
165
2/7/10
13:19
Página 166
Sensors Everywhere
5.1.1. Processor
The element that controls the sensor node is the processor. Due to
limited processing capabilities, and as it includes memory and peripherals in addition to a Central Processing unit (CPU), the processing IC
is recognised as a Micro Controller Unit (MCU). As the final applications of
the sensor node are quite diverse, manufacturers offer a wide variety of
MCUs. The range goes from 8-bit processors based on the 8051 microprocessor to a 32-bit architecture based on the Advanced RISC Machine
(ARM) microprocessor, or newer versions such as ARM Cortex. These ARM
processors are adopted by several manufacturers and can offer 32 MIPS
(Million Instructions Per Second). In order to reduce the power consumption, these platforms use power sources as low as 1.8 V and support different clock rates.
Several manufacturers offer MCUs used in sensor nodes such as Atmel
[13], Chipcon [14] or Freescale [15].
5.1.1.1. Clocks
Clocks are required by the MCU and the radio part. The clock rate used
by the MCU is proportional to the processing power obtained, but at the
same time affects to the power consumption. Increasing the clock rate
results in an increase of processing capacity and power consumption. This
represents a dilemma since increasing processing and reducing power consumption are objectives for the sensor node designers. The approach adopted to solve this compromise is to distinguish between active and low power
modes and to use different clocks in each state. In active state, a high rate
clock allows processing quickly, while in low power state a low rate clock is
used. This clock can be provided by the IC itself or by an external clock. The
first option offers a bad accuracy so the second one should be used when
synchronisation is required. This clock, used in low power mode, usually has
a frequency of 32.768 kHz11.
11
This frequency is used since if applied to a 15 bits counter it reaches the maximum value
each second.
166
2/7/10
13:19
Página 167
5.1.1.2. Operation modes
As it has been said previously, MCUs used in sensor nodes have different
operation modes, from an active mode, with a fully operational MCU and low
power mode. The last mode has also some sub-modes that depend on the
manufacturer. The different modes are obtained by switching off different
parts of the MCU, such as parts of the RAM memory, timers or interruptions
and using different clocks. For example, it is quite common to lose part of
the RAM memory content or to keep only one active timer, certain interruptions and input lines. In low power mode it is possible to be in doze, sleep
and hibernate. The exact operation sub-modes depend on the manufacturers and the exact MCU model. With all these options, a duty cycle can be
implemented whereby the MCU is in low power mode most of the time, and
either awakes periodically or when an external event to the MCU is produced. The resulting power consumption result is tens of microAmperes in
sleep mode and several milliAmperes when it is fully active.
5.1.1.3. Inputs and outputs
MCU offers some lines to inputs or outputs that can be configured
through programming. As these lines can be used for different purposes,
they are called General Purpose Input/Output (GPIO). It is even possible to
configure them as interruption inputs or as a Direct Memory Access (DMA).
Output signals are limited by the supply voltage, but some of them accept
5-Volt TTL levels as inputs without being damaged.
5.1.1.4. ADC/DAC
It is quite common that sensor nodes have several analog to digital converters that can be multiplexed in different channels. One of these channels
is devoted to the battery voltage monitoring to anticipate any problem with
the power source. The minimum sampling rate is in the range of 20 ms and
provides 12 bits per sample, with an effective number of bits from 8 to 9 due
to the noise level of the input signal.
Digital to analog conversion is also provided with similar parameters, in
terms of response time and precision to the ones encountered in the ADC
167
2/7/10
13:19
Página 168
Sensors Everywhere
5.1.1.5. Serial interfaces
Most peripherals that can be connected to a MCU use serial interfaces.
There are simple serial ports such as Universal Asynchronous
Receiver/Transmitter (UART) and others that can be multiplexed, such as
the Inter-Integrated Circuit (I2C) bus or the Serial Peripheral Interface (SPI)
bus.
The I2C bus uses only two bidirectional lines and the ground. One
line is for the clock and the other one is for data. Each device has a unique
address of 7 bits. As some of the addresses are reserved, it is possible
to have one master and up to 112 slaves. The master sends the clock
and the address of the slave. It offers transfer rates up to
3.4 Mbps.
The SPI bus follows also a master-slave approach. The MCU has the role
of a master and the devices connected to it are the slaves. The interface has
four lines: one is the serial clock given by the master, two lines are used for
full duplex bit transmission and another one is used by the master to select
the slave. If several SPI ports are defined, the clock and the transmission
lines can be used by all the ports and only an individual selected line is
needed (see Fig. 5.1).
Fig. 5.1. Typical SPI bus with one master and three slaves
168
2/7/10
13:19
Página 169
The UART interface uses 3 lines (i.e. transmit, receive and ground) and
optionally uses control lines for flow control, such as RTS and CTS.
5.1.1.6. Timers
MCU has several timers to generate timed events. They are based on a
counter that is increased/decreased each clock tick. In some MCUs, timers
can be used even in sleep mode to trigger the wake-up of the device.
5.1.1.7. Interruptions
Interruptions are notifications such as an input line transition or a timer
reaching a certain value, that should be treated immediately as soon as possible the processor stops doing the current task. Interruptions should be a
short task that requires a quick response. Interruptions can be used to perform periodic operations (e.g. triggered by a timer) or to treat an event (e.g.
triggered by an input line).
5.1.1.8. Reset
A reset is a basic operation intended to bring the system to a totally
known state. It corresponds to an initial state. A reset can be generated by a
specific line, which is called a hard reset, or as a result of some special event,
which is known as software reset. There is a special timer, known as watchdog timer, which is intended to remove the processor from a blocked state.
If the watchdog timer reaches a limit value, a reset is generated. The application running on the MCU should update the watchdog timer in order to
avoid reaching the limit. If the application is blocked, the timer is not updated and a reset is generated for bringing the system to an initial state.
It is also possible to generate a reset if the MCU suspects it has corrupted information. For example, a short decrease in the source voltage may not
generate a reset of the system but it may result in an unpredictable alteration of the memory. In this case, if the program continues it can produce
incorrect results. To avoid this problem, some MCUs have a facility know as
brown-out detector that in case of a voltage decrease can generate auto-
169
2/7/10
13:19
Página 170
Sensors Everywhere
matically an MCU reset. This brings the MCU to an initial state avoiding the
possible danger of this supply voltage change.
5.1.2. Memory
The system requires memory to store programs and variables. Memory
can be located inside the MCU and it can also be added externally. The system requires a ROM memory where the basic instructions are loaded. ROM
usually stores the interruption handler and a boot loader. In some designs,
which provide the transceiver and the processor in the same chip or package, the ROM contains also the communication protocols and an Application
Programming Interface (API) to facilitate the access to the network from the
programmed applications. In some systems, this memory can be replaced or
complemented with a flash or Electrically-Erasable Programmable Read-Only
Memory (EEPROM) that allows storing the application program and volatile
variables. Working with flash memory is slow and requires significant power
when writing data (even the total number of writing operations is limited). The
amount of flash memory provided can be up to 256 kB.
Usually, when the system starts, it executes an application called boot
loader, that has the code stored at the ROM. This application loads the user
programmed code from the flash memory to the RAM memory. Once this is
done, the user application is executed from the RAM. The flash memory is not
used during the application execution. The amount of RAM memory varies
significantly between MCUs. The minimum RAM size that can be found in
present systems is 1 kB, and the maximum one is 128 kB. Some manufacturers offer the same basic designs with different amounts of RAM memory.
It is also common to find models with a small memory inside the MCU to
store configuration variables such as the node address or a security key.
These variables are not changed when the developer updates the flash
memory. This approach is called One Time Programmable (OTP) memory.
External memory, such as flash memory, can be connected and mapped
onto the address and data buses, but it is more common to use a serial port.
This option simplifies the PCB layout and reduces the number of pins of the
MCU.
170
2/7/10
13:19
Página 171
5.1.3. Radio transceiver
It has been assumed that the sensor node accounts with wireless communication capabilities. Most of the information presented in this chapter
holds as well with a wired connection, but a wireless connection is the most
common and flexible way of operation for sensor nodes. There are different
usable frequency bands, such as the usually known as 433 MHz, 868 MHz,
915 MHz and 2.4 GHz (see chapter 3, section 3.2). With the aim to obtain a
small and cheap sensor node, radio transceivers are mostly integrated in an
IC. To justify the costs of IC development, the solutions are oriented either
towards a standardised solution such as IEEE 802.15.4 or Bluetooth Low
Energy, or towards a general purpose ones that can be customised, such as
the family of nRF products from Nordic Semiconductor [17].
5.1.3.1. IEEE 802.15.4 transceivers
At present, the radio interface that is attracting more interest in terms of
number of alternatives is the IEEE 802.15.4. Most of the manufacturers focus
on the 2.4 GHz band, but there are also products for the 868 MHz, 915 MHz
and even the new 780 MHz band, available in China. Manufacturers of IEEE
802.15.4 transceivers are, for example Chipcon, Atmel, Freescale or
Radiopulse [20].
The transceiver implements the radio interface and some functions
required by the MAC such as the encryption and the CRC computation. The
rest of the MAC functionality, such as ACK generation and the access algorithm are commonly implemented by the MCU, which is controlling the
transceiver.
5.1.3.2. General purpose transceivers
There are a number of transceiver chips in the market that are able
to implement a specific radio interface. These devices permit to build
simple radio interfaces used by proprietary solutions. The low power RF
products from Texas Instruments [16] or the nRF series from Nordic
Semiconductors [17] are good examples. In general, these types of
171
2/7/10
13:19
Página 172
Sensors Everywhere
devices are divided in sub-GHz products (315, 433, 868, 915 MHz
bands) and the ones covering the 2.4 GHz band. They offer different
modulations (FSK, GFSK, MSK, ASK and OOK) and different channels, in
terms of both location in the band and widths. They incorporate common mechanisms such as radio channel sensing, RSSI measure of the
received signal, synchronization word detecting, address check, and
automatic CRC generation and verification.
The radio transceivers offer maximum transmitted powers from 0
dBm to 20 dBm. It is quite common to use an external power amplifier
to reach the high range of the transmitted power. The power consumption is related with the transmitted power, for example, a 0 dBm
transmission may require a current of 27 mA, while at 20 dBm the consumption reaches 150 mA. The voltage used varies between 1.8 V and
3.6 V.
5.1.4. Antennas
The antenna is the most important passive element in a wireless
sensor node. The key parameters for an antenna design are the frequency of operation and bandwidth, the radiation pattern, the antenna gain and radiation efficiency, the radiation resistance 12 and the
antenna size [21]. The antenna gain is an indication of the performance
of the antenna radiation compared to an isotropic antenna. The radiation pattern provides information on the transmitted power in each
direction in the space. A simple antenna presents regularities that can
be used to represent the radiation pattern in one or two planes. For
example, the three-dimensional radiation pattern of a dipole antenna
can be represented by its corresponding radiation patterns in the vertical plane and in the horizontal plane as shown in Fig. 5.2.
12
Also it is common to refer to the antenna impedance. The resistance is the part of the
impedance that produces radiated power.
172
2/7/10
13:19
Página 173
Fig. 5.2. Dipole antenna and the horizontal (in green) and vertical radiation
pattern (in red)
The polarisation is also a performance parameter used in the characterization of the antenna and it is recommended that the transmitter and receiver antennas have the same polarisation. However, the polarisation of the
radio signal is distorted due to propagation in a multipath environment, due
mainly to multiple reflections, like for example an indoor signal propagation
scenario. At the receiver, a mixture of the two possible polarisations is received making the polarisation of the receiver antenna not so relevant. In
order to maximise the power transfer, and the transmitted power in consequence, the resistance at the emitter and the antenna should be matched.
The antenna size is related to the wavelength of the RF signal transmitted. A
size equal to half the wavelength is the optimum one since it offers good
radiation and small size. It is possible to reduce this size using different
dielectric materials (different from the air) and folding the antenna, but
performance may decrease.
5.1.4.1. Dipole based antennas
There are different types of antennas, but most of them are based on the
dipole antenna concept. A dipole is a straight piece of wire cut in the centre
and fed with a balanced transmission line13. For a 2.4 GHz the half wavelength
dipole measures 6 cm and presents a resistance close to 73 Ohms. It is possi13
A balance line has two conductors, with equal currents in opposite directions, such as a
twisted pair cable.
173
2/7/10
13:19
Página 174
Sensors Everywhere
ble to use a monopole antenna that consists in replacing one part of the dipole by an infinite ground plane that ideally mirrors the monopole offering a
virtual dipole. This type of antenna reduces the resistance by one half and the
antenna becomes unbalanced14, also referred as single-ended antenna. The
most common implementation is a whip antenna (see Fig. 5.3) mounted in a
metallic structure that acts as a ground plane (the PCB or the metal case).
Fig. 5.3. Whip antenna used to be mounted on a metallic structure. In this
model the connector can be folded to facilitate the transport of the
equipment
Monopoles and dipoles can be folded resulting in a loop or a helix (see
Fig. 5.4 for some examples).
Fig. 5.4. From left to right: a) Folded monopole, b) Meander antenna, c)
Helix antenna (the total length of the wire is close to a quarter of
wavelength), d) Full wave loop
Resistance may be affected by the changes in the geometry. Some additional modifications can be introduced as in the case of an inverted F-antenna (see Fig. 5.5).
14
An unbalance line has just one conductor and one ground, such as a coaxial cable.
174
2/7/10
13:19
Página 175
Fig. 5.5. Inverted F-antenna (IFA). It is based on a folded monopole by
with an additional segment to modify the resistance offered by the
antenna
Another possibility is a patch antenna. It consists in a very low profile
metal structure able to work very close to the ground plane. This type of
antenna can be built in the PCB used and occupies part of the available
space.
5.1.4.2. Ceramic antennas
These types of antennas, also known as chip antennas, which are
intended to minimise the space occupied by the antenna and they are
usually mounted on the PCB. They use a ceramic material with a higher
dielectric constant (compared to the one of the air) and lower losses.
They present usually low antenna gain (poor radiation efficiency) since
they perform worse than an isotropic antenna in terms of gain. Also, they
are very sensitive to surrounding components, so it is very important to
follow the recommendations from the manufacturer for mounting it on a
PCB.
Fig. 5.6. Chip antenna used for a 2.4 GHz band
175
2/7/10
13:19
Página 176
Sensors Everywhere
5.1.4.3. Baluns
The balun is an element used to convert a single-ended (unbalanced)
input signal to a balanced output signal with impedance transformation.
Therefore, a balun solves the connection of lines with different impedances
and provide a balanced output. Baluns can be built using the PCB itself or as
a small ceramic component. Some SiP chips incorporate the balun reducing
the number of external components.
5.1.4.4. Antenna connectors
If the antenna is not made on the PCB or soldered directly, an antenna
connector is required. If the antenna is separated from the board, an RF
cable is needed.
The usage of a cable facilitates the location of the antenna in relation to
the board. A special attention should be paid to the losses and cost of the
cable. They are usually manufactured as small length cables (e.g. 5 to 10 cm
long) with connectors and are referred to as “pigtail” cables.
The most common connectors are the SubMiniature version A (SMA) and
the miniature RF connector called “U.FL”. See Fig. 5.7 for an example of both
connectors.
Fig. 5.7. At the upper part of the image an UF-L connector and at lower
part a SMA connector
176
2/7/10
13:19
Página 177
5.1.5. Sensor and actuator devices
The availability of sensor devices that can be used in a sensor node
is increasing thanks to miniaturisation and price reduction. The main
problem related to sensors is the different formats and interfaces required. Each sensor requires a supply voltage and delivers the data in
analog or digital format. If analog measurement is provided, this can be
in the form of voltage or current. The relevant data for the user (substance concentration, temperature, acceleration, etc.) should be derived thanks to a curve provided by the manufacturer. In some cases,
this relation is linear and then the conversion is quite simple, but is
quite common to find non-linear functions. It is also common to give
this curve in relative changes, so the sensor node should be calibrated.
If the sensor has to be changed after a first calibration, a new curve
should be adjusted with a new calibration. There are initiatives to avoid
most of these problems, such as the IEEE 1451 standard [22] and the
offering from manufacturers to give a wide set of sensors with a unique
interface such as phidgets [23].
5.1.5.1. Sensors
There is a large variety of sensors (and actuators). The following is a nonexhaustive list that aims at introducing the most common sensors.
• Temperature. This type of sensor can be based in a thermistor (a device able to change the resistance according to the temperature) or a
thermocouple that is a junction of metals that produces a voltage
when they have different temperature.
• Air humidity. Also known as hydrometer, it measures the relative
humidity of the air. At present, it can be implemented using a
resistive material that changes according to the humidity of the
air.
• Light. It measures the amount of visible light. It can be based on a photodiode or a photo resistor.
177
2/7/10
13:19
Página 178
Sensors Everywhere
Fig. 5.8. Boards for the Mica2, MicaZ and Iris with sensors
• Acceleration. It measures the acceleration produced by a movement. It is
based on piezoelectric, magnetic induction or capacity effect to mention
the most common ones. It can provide information from one dimension,
two or three. It can be used to measure vibration or as mobility detector.
Also, as the gravity force appears as a type of acceleration it is possible to
use this type of sensor to measure the inclination of the sensor.
• Presence. It is implemented mainly using passive infrared (PIR). It consists in an integrated circuit able to receive infrared light and to measure differences between them. If a person enters in the range of the
sensor, the heat differences (that result in an infrared emission) will be
detected indicating the presence of a person.
• Force. It measures the force applied to the sensor. It can be based on
the variation of resistance when pressure is applied.
• Sound. This consists in a microphone able to transform an audible
pressure signal into an electrical magnitude.
• Soil moisture. Used in gardening and agriculture, this type of device
should provide the content of water in soil. One of the most common
solutions for this type of sensor is based on the capacitance variation
at different frequencies.
• Proximity. This is a sensor able to detect the presence of a close object
without getting in touch with it. It is based on an electrostatic or magnetic field that is modified by the nearby object. It is clear that the last
one is only affected by metallic objects.
178
2/7/10
13:19
Página 179
• Magnetic field. Also called magnetometer, it measures the magnetic
field strength. It can be used as a compass based on the magnetic field
of the earth or to detect the proximity of a metallic object that modifies the magnetic field. This type of sensor can be scalar (measuring
the total magnetic field) or vectorial (measuring values of each component of the field).
• Ultrasound receiver. Similar to a microphone, this device is able to convert an ultrasound (higher than 20 kHz) pressure wave into an electrical signal. Usually, this type of sensor uses the 40 kHz frequency, but
it is also possible to find devices working at the frequency of 235 kHz.
They are used to receive reflections from pulses generated by an ultrasound transmitter and detecting the presence of obstacles.
• Infrared receiver. It produces a signal proportional to the amount of
infrared radiation received. It is based on a photodiode.
• Gas sensors. They can be implemented in several ways, but the most
attractive ones are the chemical ones, which require low power consumption and present small size. A drawback is that they require replacement after several years of usage. Common gas sensors are able to
detect a variety of gases such as CO, CO2, NO2, CH4, NH3, O2 or smoke.
5.1.5.2. Actuators
The following is a non-exhaustive list of actuators.
• Electric switch. It can be based on a simple on-off switch or a dimmer able to control the power supply to the controlled device.
The simplest controlled device can be a light bulb, but for example door locks, blinds or a heater can be controlled with this simple device.
• Ultrasound transmitter. This is a device able to send an ultrasound signal when commanded. This device is used in combination with an
ultrasound sensor to detect obstacles or to perform distance measurements.
179
2/7/10
13:19
Página 180
Sensors Everywhere
• Infrared transmitter. This is a device able to send an infrared signal
when commanded. This device is used in combination with an infrared
sensor to detect obstacle or to perform distance measurements.
5.1.5.3. Analog interfaces
As it has been mentioned, there exists a variety of interfaces for sensors.
One of the most used is the 4-20 mA loop for analog signals. It is particularly
interesting to transport signals through long lines. The 0 value from the analog signal corresponds to a current of 4 mA. This trick allows verifying the
loop and detecting when it breaks.
Another analog interface used is the 0-1 Volt one. The voltage level
represents the measured magnitude.
5.2.
Sensor node router and gateway
The sensor nodes platforms are able to be adapted to offer either routing
within the WSN or gateway functionality towards networks outside the WSN.
The common gateway modules available support: USB , WiFi, serial port,
GSM/GPRS, Bluetooth connectivity, etc.
5.3. Sensor node platforms
To facilitate size and price reduction, sensor nodes should be based on
integrated circuits (ICs), reducing the additional components needed (which
is also known as lowering the system BOM15). With this aim, some manufacturers offer one single IC with the processor, memory and the radio
transceiver. This approach is named System on Chip (SoC) and allows very
compact designs, but combining radio elements with processing elements
results in suboptimal designs. Fig. 5.9 is an example of a SoC from Chipcon
(now Texas Instruments) [19].
15
BOM stands for Bill Of Materials and refers to the component count and cost of the whole
system.
180
2/7/10
13:19
Página 181
Fig. 5.9. Sensor node made with a single chip (SoC) CC2430 made by
Texas Instruments
Another approach that allows optimising the IC technologies for the specific purpose is the System in Package (SiP). Different ICs are mounted on
the same substrate and encapsulated as a single IC. An example of this solution is offered by Freescale with the MC13224V IC.
Other wireless sensor providers, which are not IC manufacturers, mount
the different elements on a Printed Circuit Board (PCB) to build a module. The
module has a set of connectors to facilitate the integration to a main PCB and
requires no additional components to work. Some of these modules offer a
simple communications serial interface based on AT commands. Fig. 5.10
shows a module made by MeshNetics (now Atmel) [1]. This module uses one
processor and a transceiver from Atmel. Other modules are the Xbee family
from Digi [5] and the modules from Jennic [6], Radiocraft [7], Telegesis [8], or
from RF Monolitics [9] to mention some of the currently available ones.
Fig. 5.10. Module MNZB-900-BO from MeshNetics. At the right the
module showing the upper side. At the left the module mounted on a
board
181
2/7/10
13:19
Página 182
Sensors Everywhere
There exist other manufacturers in the market that offer a fully operational sensor node including batteries, antenna and some sensor devices.
The most well known family of systems is the one developed by University
of California (UC) Berkeley such as Rene, Mica, MicaDot, Mica2 and MicaZ [2]
(see Fig. 5.11). Some of them are commercialised by Crossbow. Another
evolution from the designs of UC Berkeley is the MoteIV, known as TelosB.
[2] In fact some of these designs, such as TelosB, are an open hardware platform and there exist some similar platforms from several manufacturers
such as Zolertia [3] or MAXFOR [4]. These platforms are intended mainly as a
platform for educational purposes and development. Another quite popular
platform is iMote2 [2], developed initially by Intel and commercialised by
Crossbow. This platform represents an evolution on performance offering
more processing power than the previously mentioned nodes.
Fig. 5.11. Images of different full operational platforms. From left to right:
the MicaDot, MicaZ and Iris sensor nodes
Other families of sensor nodes worth to mention are:
• Arduino platform. This is also an open hardware platform with multiple
designs [10] and a large developers community.
• SunSpot is a platform used to develop research projects [24].
• WaspMote is a general platform with multiple available sensors and
communications facilities [11].
• Sensinode [25] and Arch Rock [26] are companies offering a complete
solution including sensor nodes and gateways. The most relevant
aspect of these companies is the support of IP connectivity using
6LoWPAN.
182
2/7/10
13:19
Página 183
REFERENCES
[1]
Meshnetics modules: http://www.meshnetics.com/zigbee-modules/
[2] Crossbow sensor nodes:
http://www.xbow.com/home/wHomePage.aspx
[3]
Zolertia website: http://www.zolertia.com/
[4]
MAXFOR website: http://www.maxfor.co.kr/eng/index_en.html
[5]
Modules from Digi Networks: http://www.digi.com/products/wireless/
[6]
Modules from Jennic: http://www.jennic.com/products/modules/
[7]
Modules from Radiocraft: http://www.radiocrafts.com/
[8]
Modules from Telegesis: http://www.telegesis.com/
[9] Modules from RF Monolitics:
http://www.rfm.com/products/oem_standalone.php
[10] Arduino project website: http://www.arduino.cc/
[11] WaspMote from Libelium: http://www.libelium.com/products/waspmote
[12] Smart Dust project:
http://robotics.eecs.berkeley.edu/~pister/SmartDust/
[13] Atmel MCUs: http://support.atmel.no/bin/customer
[14] Chipcon MCUs:
http://focus.ti.com/mcu/docs/mcuhome.tsp?sectionId=101
[15] Freescale MCUs: http://www.freescale.com
[16] RF circuits from TI.
http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=a
nalog&familyId=368&uiTemplateId=NODE_STRY_PGE_T
[17] RF circuits from Nordic.
http://www.nordicsemi.com/index.cfm?obj=menu&act=displayMenu
&men=2
183
2/7/10
13:19
Página 184
Sensors Everywhere
[18] SiP from Freescale.
http://www.freescale.com/files/rf_if/doc/data_sheet/MC1322x.pdf?p
spll=1
[19] SoC from Chipcon. http://focus.ti.com/lit/ds/symlink/cc2430.pdf
[20] RF transceiver from Radiopulse.
http://www.radiopulse.co.kr/eng/main.html?mode=02_05
[21] Sensor node antennas.
www.freescale.com/files/rf_if/doc/app_note/AN2731.pdf
[22] IEEE 1451 web page. ieee1451.nist.gov
[23] Phidgets. http://www.phidgets.com/
[24] SunSpot platform. http://www.sunspotworld.com/
[25] Sensinode platform. http://www.sensinode.com/EN/company.html
[26] Arch Rock platform. http://www.archrock.com/
184
2/7/10
13:19
Página 185
6
Topology control
2/7/10
13:19
Página 186
2/7/10
13:19
Página 187
Chapter 6. Topology control
6. Topology control
Topology control is an important technique used in WSNs for optimizing
key performance parameters, such as network lifetime or throughput, while
maintaining other performance parameters such as network connectivity.
The main topology control approaches can be classified into two categories:
i) topology control techniques based on the use of hierarchical networks,
and ii) topology control techniques based on the use of dynamic transmission range adjustment. It must be noted, however, that while topology control may be integrated with other mechanisms (e.g. MAC or routing protocols), it is actually a cross-layer function and is not related with any layer in
particular.
In the first case, there exists a hierarchy within the network whereby certain mechanisms do not employ all the nodes in the network. Instead, such
mechanisms involve only a subset of nodes according to the network hierarchy. In addition, some special nodes may alleviate certain tasks of other
nodes. In the second case, whether or not a network hierarchy exists, the
transmission range is appropriately (and dynamically) tuned according to a
particular goal. Since transmission and reception are two dominant components of energy consumption in a sensor node, transmission range adjustment is a relevant technique for meeting performance requirements in
terms of parameters such as energy consumption and connectivity. Note
that combinations of the two categories of topology control techniques
may exist.
Topology control requires the use of topology control protocols, which
aim at building and maintaining network topologies. Ideally, these protocols
187
2/7/10
13:19
Página 188
Sensors Everywhere
should be asynchronous, fully distributed, and should use locally available
information (i.e. information about the network should be obtained by a
node by communicating only with its neighbours).
This chapter is organized as follows: Section 6.1 presents topology control techniques based on the use of hierarchical networks. Section 6.2 focuses on topology control techniques aimed at dynamically adjusting the transmission range of the WSN nodes. Finally, Section 6.3 focuses on topology
control solutions for the construction and maintenance of faulttolerant topologies.
6.1.
Topology control techniques based on hierarchical networks
The mechanisms for data transmission on a given network can make use
of a flat approach (whereby all nodes are at the same level) or a hierarchical
one (whereby nodes are organized into different hierarchical levels).
In a typical WSN for data collection, a flat network approach may lead to
a reduced network lifetime. Let us assume that a multi-hop routing protocol
(see Chapter 7) is used in all the WSN nodes for data delivery from the sensor nodes towards the sink. Since the nodes close to the sink would relay
more traffic than those far from the sink, the former ones would rapidly
become unavailable due to battery depletion. An opposite approach would
be to assume that all sensor nodes can directly transmit their data to the
sink. In this case, the nodes distant from the sink would run out of battery
quickly, due to the use of higher transmission power.
One solution is to establish a hierarchy in the network based on the use of
clusters. In a cluster-based network, nodes organize themselves into local
clusters. One of the nodes of the cluster is selected as the cluster-head, which
acts as the gateway of the cluster for communication between nodes that do
not belong to the same cluster (see Fig. 6.1). The cluster-head may communicate with other cluster-heads (of other clusters) or may directly transmit data
to a particular destination (e.g. a sink node). In data collection WSNs, a clusterhead may also perform data processing in order to minimize the redundancy
of the information collected by the sensor nodes of the cluster.
188
2/7/10
13:19
Página 189
Fig. 6.1. Nodes of a network organized into clusters. The cluster-head acts
as a gateway for the nodes that belong to its cluster
In WSN applications where the traffic is mainly between arbitrary nodes
(e.g. as in building automation), clustering can also be useful for limiting the
scope of certain mechanisms in order to avoid involving the whole network.
One example may be the transmission of routing protocol messages. In
effect, clustering favours network scalability.
6.1.1. LEACH
The Low Energy Adaptive Clustering Hierarchy (LEACH) protocol [2] is an
adaptive clustering protocol for data collection WSNs16. In this protocol, sensor nodes collect information and transmit it to the corresponding clusterhead. The latter carries out data fusion operations and then transmits the
information directly to a sink node (see Fig. 6.2). While transmission from a
cluster-head to the sink may require high transmission power (especially for
cluster-heads distant to the sink), only a small percentage of nodes are elected as cluster-heads. The overall result is that network lifetime is significantly
longer than that obtained without the use of clustering mechanisms. A key
16
Note that the description of the MAC mechanisms used in LEACH can be found in
Chapter 4.
189
2/7/10
13:19
Página 190
Sensors Everywhere
element in LEACH is that in order to avoid fast battery depletion of clusterheads, these cluster-heads are randomly chosen, taking into account the
remaining energy at the nodes. On the other hand, sensor nodes attach
themselves to the cluster that minimizes communication energy.
Fig. 6.2. Example of a network with LEACH. The cluster-heads receive
data from the nodes of their clusters, and after being processed the data
are transmitted by the cluster-heads directly to the sink
LEACH operation is organized into rounds. Each round starts with an
advertisement phase in which nodes elect themselves as cluster-heads with
a certain probability. The algorithm used for cluster-head election takes into
account the percentage of cluster-heads required for the network (which
has to be set a priori) and whether a node has recently been a cluster-head
or not. Once a node has become a cluster-head, it broadcasts an advertisement message to the other nodes. On the basis of the received signal
strength of the advertisement, the sensor nodes decide to which cluster
they will belong. Subsequent to this decision, each sensor node informs the
cluster-head that it will be a member of the cluster. The cluster-head then
creates a TDMA schedule for transmission of the sensor nodes (see
Chapter 4). After receiving all the data, the cluster-head performs signal processing operations to avoid redundant information and transmits the data
to the sink node. After a certain period of time, a new round starts.
190
2/7/10
13:19
Página 191
6.2.
Topology control techniques based on dynamic transmission
range adjustment
A taxonomy of topology control techniques based on dynamic transmission range adjustment is proposed in [1] (see Fig. 6.3). First, these techniques
can be divided into homogeneous and non-homogeneous approaches. In
the first case, nodes are assumed to use the same transmission range, while
in the second one nodes may use different transmission ranges. In nonhomogeneous topology control, the topology can be computed using location information (assuming that the positions of the nodes are known),
direction information (whereby nodes do not know their position, but they
can estimate the relative direction of their neighbours) and neighbourbased information (where nodes know the identities of their neighbours and
can order them according to parameters such as distance and link quality).
A brief overview of some types of the three categories is shown below.
Fig. 6.3. A taxonomy of topology control techniques based on dynamic
transmission range assignment (reproduced from [1])
6.2.1. Location-based topology control protocols
The authors in [3] propose a distributed topology control algorithm that
uses location information obtained by low-power GPS receivers. The algorithm minimizes the energy needed for communication with a central node.
191
2/7/10
13:19
Página 192
Sensors Everywhere
Local Minimum Spanning Tree (LMST) [4] is a protocol that generates a
strongly connected communication graph with a node degree17 bounded by
6, that is, high network connectivity is achieved with a maximum number of
neighbours per node equal to 6. In LMST, each node builds its own Minimum
Spanning Tree (MST) (i.e. the minimum topology that connects all the network nodes) and keeps one-hop on-tree nodes as its neighbours in the
topology. LMST outperforms other protocols, such as [3], in terms of average
node degree and node transmitting range. LMST assumes that the location
of nodes is known (e.g. thanks to the use of a system like GPS).
6.2.2. Direction-based topology control protocols
Cone Based Topology Control (CBTC) [5] is a distributed topology control
based on directional information. Each node transmits with minimum power
such that there is at least one neighbour in every cone of angle α centred
at the node. The authors demonstrate that connectivity is ensured if
α ≤ 2π/3 and, if α ≤ π/2, every node in the final communication graph has
a node degree of at most 6.
6.2.3. Neighbour-based topology control protocols
Neighbour-based topology control protocols are based on connecting
each node to its k closest neighbours. The MobileGrid protocol [6] and the
Local Information No Topology (LINT) protocol [7] try to keep the number of
neighbours of a node within a range centred on an optimal value. The transmission range is tuned accordingly. These protocols estimate the number of
neighbours by overhearing control and data messages, which does not
generate control overhead but rather depends on the transmission activity
of the nodes.
The k-NEIGH protocol [8] maintains the node degree at a value smaller
than or equal to a given value k. A simulation-based study has shown that
k=9 is sufficient to obtain high network connectivity for a range of node
densities [8]. The same simulation results show that the topology gener17
The node degree is defined as the number of neighbours of a node.
192
2/7/10
13:19
Página 193
ated by k-NEIGH is on average 20% more energy efficient than that generated by CBTC.
6.3.
k-connectivity
One of the main goals of topology control is the construction and maintenance of a connected network topology. This includes the problem of
assuring a k-connected network topology, where k is the number of different paths between any two nodes. Such a topology would still assure
connectivity between any two nodes, even if k-1 nodes became unavailable.
Path redundancy is indeed an important feature required in WSNs, which are
subject to node unavailability (e.g. due to battery depletion), node mobility
(in some scenarios) and the dynamics of radio propagation. Another relevant factor to take into consideration is the active and sleep time schedules
that may be used by the WSN nodes, which may also affect network connectivity.
There exist some extensions to protocols like LMST and CBTC that offer
k-connectivity [9, 10].
REFERENCES
[1] P. Santi, “Topology Control in Wireless Ad hoc and Sensor Networks”,
ACM Computing Surveys, Vol. 37, No. 2, pp. 164–194, June 2005.
[2] W. Rabiner Heinzelman, A. Chandrakasan, H. Balakrishnan, “EnergyEfficient Communication Protocol for Wireless Microsensor Networks”,
in proceedings of the 33rd Hawaii International Conference on System
Sciences, Island of Maui, Hawaii, USA, January 2000.
[3] V. Rodoplu, T. Meng, “Minimum energy mobile wireless networks”, IEEE
J. Selected Areas Communications. 17, 8, pp.1333–1344.
[4] N. Li, J. Hou, L. Sha, “Design and analysis of an mst-based topology control algorithm”, in Proceedings of the IEEE Infocom, pp. 1702–1712,
2003.
193
2/7/10
13:19
Página 194
Sensors Everywhere
[5] R. Wattenhoffer, L. Li, P. Bahl, Y. Wang, “Distributed topology control for
power efficient operation in multihop wireless ad hoc networks”, in
Proceedings of IEEE Infocom., pp. 1388–1397, 2001.
[6] J. Liu, B. Li, “Mobilegrid: Capacity-aware topology control in mobile ad
hoc networks”, in Proceedings of the IEEE International Conference on
Computer Communications and Networks, pp. 570–574, 2002.
[7] R. Ramanathan, R. Rosales-Hain, “Topology control of multihop wireless
networks using transmit power adjustment”, in Proceedings of IEEE
Infocom, pp. 404–413, 2000.
[8] D. Blough, M. Leoncini, G. Resta, P. Santi, “The k-neighbors protocol for
symmetric topology control in ad hoc networks”, in Proceedings of the
ACM MobiHoc 03, pp. 141–152, 2003.
[9] N. Li, J. Hou, “Flss: a fault-tolerant topology control algorithm for wireless networks”, in Proceedings of ACM Mobicom, pp. 275–286, 2004.
[10] M. Bahramgiri, M. Hajiaghayi, V. Mirrokni, “Fault-tolerant and 3-dimensional distributed topology control algorithms in wireless multihop networks”, in Proceedings of the IEEE International Conference on
Computer Communications and Networks, pp. 392–397, 2002.
194
2/7/10
13:19
Página 195
7
Routing
2/7/10
13:19
Página 196
2/7/10
13:19
Página 197
Chapter 7. Routing
7. Routing
As in other types of wireless multi-hop networks, in WSNs, if the
receiver is not within the transmission range of the sender, the sender
can take advantage of intermediate nodes which can route the data
towards the receiver. This reduces the amount of energy required to
transmit data between two nodes. In addition, communication path
redundancy is commonly present in WSNs to some extent, which provides reliability.
Network routing is the process of selecting a path for the relaying of a
message from a source device to the intended destination.
Ideally, data should be routed through good paths. Routing protocols are
in charge of finding and maintaining such paths. The constraints of WSNs
pose a set of requirements for the routing protocols, which should aim at
finding a good trade-off between a number of performance parameters,
such as delivery ratio, latency and energy consumption. Scalability is particularly important, given the potential large number of nodes in a network
and their memory and energy limitations.
This chapter focuses on routing protocols for WSNs. Section 7.1
presents various types of routing protocols which were designed for or
are particularly suitable for WSNs. Section 7.2 focuses on adaptations
of IETF Mobile Ad Hoc Network (MANET) routing protocols for WSNs.
Finally, Section 7.3 is devoted to the routing protocol work carried out
within the IETF, specifically for WSNs and similar networks. The reader
may note that, with regard to ZigBee routing, part of its functionality is
described in Section 7.2, while more details about the routing solutions
197
2/7/10
13:19
Página 198
Sensors Everywhere
that ZigBee offers can be found in Chapter 11. However, the formation
of multi-hop networks composed of BT-LE links is beyond the scope of
the technology specification.
7.1.
Routing protocols designed for WSNs
This section presents some of the most relevant routing protocols specifically designed for WSNs. Depending on the underlying structure of the
network, these can be classified into flat, hierarchical and geographic routing protocols.
7.1.1. Flat routing
In flat routing, all devices essentially play the same role and collaborate
in the tasks carried out by the WSN. Flat routing protocols are essentially
data centric, which means that in contrast to the address centric communication paradigm that exists for example in the Internet (whereby pairs of
devices communicate with each other), the main goal is to obtain some data
at a sink node, irrespective of the sensor nodes involved in the collection of
those data.
7.1.1.1. Directed Diffusion and its variants
Directed Diffusion [1] was one of the first routing paradigms developed
for WSNs. In this protocol, a sink node broadcasts interests (i.e. requests) for
certain data. As interests are propagated through the network, gradients (i.e.
routes) towards the sink node are set up. Data is then transmitted to the sink
node and a limited number of paths (e.g. one path) are reinforced (i.e. selected) based on certain rules (e.g. delivery delay). Fig. 7.1 illustrates this procedure.
During the process of data transmission from the sensor nodes to the
sink node, intermediate nodes may aggregate information. This scheme
reduces energy consumption when compared with transmitting a packet
from each individual sensor node involved in a given sensing task.
198
2/7/10
13:19
Página 199
Chapter 7. Routing
Fig. 7.1. Basic operation of Directed Diffusion: a) Interest propagation, b)
initial gradients set up, c) data delivery along reinforced path
A number of Directed Diffusion variants have been proposed:
• Rumour Routing [2] aims at reducing the energy consumption of
Directed Diffusion due to request broadcasts. When the number of
events is small and the number of requests is large, the queries can be
routed to the nodes that have observed an event, instead of flooding
the whole network. This is achieved by means of the transmission of
special packets called agents, which are generated by the nodes that
detect an event. Agents flood the network, which allows distant nodes
to know the route towards the nodes that have detected an event.
Hence, in this way request flooding can be avoided.
• Constrained Anisotropic Diffusion Routing (CADR) [3] aims at maximizing
the information gain while minimizing latency and bandwidth consumption. To do so, CADR uses information criteria which allow the selection
of sensors that can obtain the data of interest. Only the sensors that are
close to a particular event are activated, and routes are adjusted accordingly. Each node evaluates an information/cost objective, and routing is carried out based on this objective and end-user requirements.
• Energy Aware Routing (EAR) [4] is based on Directed Diffusion, but in
contrast to the latter it maintains a set of paths. These paths are selected for communication depending on a probability, which is calculated
from the energy consumption of each path. In this way, energy consumption is balanced among various paths, which increases network
survivability. EAR uses flooding for finding all routes between each
source and destination pair. Forwarding tables are then created and
paths with a high cost are discarded. Non-discarded paths are used to
send data to a destination with a probability which depends inversely
on their energy cost.
199
2/7/10
13:19
Página 200
Sensors Everywhere
7.1.1.2. SPIN
Sensor Protocols for Information via Negotiation (SPIN) constitute a
family of protocols that disseminate the information collected at each
node to the whole network. This allows a user to query any node in the
network and obtain a fast response. SPIN was designed to address
various problems:
• Implosion: in classical network flooding, all the nodes transmit the
data to their neighbours, which may have already received this information from another node.
• Overlapping: sensor nodes whose coverage ranges overlap will transmit packets that contain overlapping information.
• Unnecessary waste of energy and bandwidth, due to the implosion
and overlapping problems.
The problems presented above are solved in SPIN by a negotiation
procedure, by which a node advertises that it has new data (including
appropriate metadata about it) and only the neighbours of this node
that have not already received the data will receive the corresponding
data packet.
Fig. 7.2 illustrates the basic operation of SPIN. In Fig. 7.2.a), node A has
data to send and advertises this fact by broadcasting an Advertise (ADV)
message. In Fig. 7.2.b), node B, which is a neighbour of node A, replies to this
message with a Request (REQ) message, which indicates that it is interested
in the data. It is assumed that these negotiation packets are smaller than
data packets themselves. In Fig. 7.2.c), node A transmits the DATA packet,
which contains the actual data to node B. In Fig. 7.2.d) the process starts
again, but in this case node B broadcasts an ADV message to let its neighbours know that it has new data to transmit. In Fig. 7.2.e), only three of these
neighbours require the data. For this reason, in Fig. 7.2.f), the DATA packet is
only transmitted to them.
200
2/7/10
13:19
Página 201
Chapter 7. Routing
Fig. 7.2. Example of SPIN basic operation
7.1.1.3. Routing protocols that follow a distributed database
approach
COUGAR [5] and ACtive QUery forwarding In sensoR nEtworks (ACQUIRE)
[6] are two routing protocols that view the WSN as a distributed database.
COUGAR defines a query layer between the network and application
layers. In COUGAR, the sensor nodes select a leader node that is in charge of
aggregating and transmitting data to the sink node. The sink node creates a
query plan that indicates the information needed plus the required in-network
computation for the query, and sends it to the relevant nodes. The query plan
201
2/7/10
13:19
Página 202
Sensors Everywhere
also includes the method for leader selection. COUGAR requires the use of a
synchronization mechanism for transmission of data to the leader.
In ACQUIRE, the sink node sends a query, which is forwarded by the sensor nodes that receive the query. Sensor nodes attempt to reply to this
query by using cached information. If the query cannot be resolved
completely, then it is forwarded to another sensor node (including any partial
information obtained from the last sensor node). Sensor nodes may also
obtain information from their d-hop neighbours in order to update their
cached information. Hence, d is a relevant parameter for optimizing performance of ACQUIRE. When the query is fully resolved, it is then transmitted
back to the sink. The choice of the next node for forwarding the query can either be made randomly or based on maximum potential of query satisfaction.
7.1.2. Hierarchical routing
In a hierarchical network, nodes play different roles depending on their
category. The assignment of different tasks for different roles helps to limit
the scope of certain operations and has benefits in terms of scalability and
energy consumption.
7.1.2.1. LEACH
The LEACH protocol [7] was already introduced in Chapters 4 and 6,
where its MAC and topology control mechanisms were described. In addition to that functionality, LEACH includes a multi-hop transmission functionality. In LEACH, the transmission from sensor nodes to a sink node takes
place in a two-hop communication. First, the sensor node transmits the
collected data to its cluster head. Secondly, the cluster head (after aggregating data from the sensor nodes of its cluster) transmits the data to the sink
node.
7.1.2.2. PEGASIS
Power-Efficient Gathering in Sensor Information Systems (PEGASIS) [8] is
an improvement over LEACH. PEGASIS forms a chain which is composed of
202
2/7/10
13:19
Página 203
Chapter 7. Routing
the nodes that are closest to each other and constitute a path towards the
sink node. In fact, the nodes adjust their transmission power so as to have a
single neighbour (which minimizes the amount of energy consumed for
transmitting to its nearest neighbour). The nodes in the chain take turns for
directly transmitting the data to the sink node. In this way, the network lifetime is increased, and, since clusters are not formed, the related cluster formation and maintenance overhead are avoided. However, PEGASIS may
incur long end-to-end delays for nodes distant from the base station in the
chain, and the protocol only assumes that the sensor nodes are static. Fig.
7.3 illustrates an example of the PEGASIS approach.
Fig. 7.3. PEGASIS operation: a) data collected by node A follow the path
ABC and then C transmits directly to the sink, b) in another turn, data
collected by node A follow the path ABCD and then D transmits directly
to the sink
7.1.2.3. TEEN
The Threshold-sensitive Energy Efficient sensor Network protocol (TEEN)
[9] follows a hierarchical clustered scheme. A cluster head informs the
members of its cluster about two thresholds: a hard threshold and a soft
threshold. The first is the absolute value of the attribute being sensed, that
is, the value beyond which the node sensing this value must report it to the
cluster head. The second is a small change of the value being sensed that
triggers the node to transmit the value. These two thresholds control the
trade-off between energy efficiency and data accuracy. The TEEN protocol
is well suited for time critical applications, as the sensors can immediately
203
2/7/10
13:19
Página 204
Sensors Everywhere
reply to the messages transmitted by their cluster heads as long as the
sensed values are within the range of interest.
7.1.3. Geographic routing
In geographic routing, data is transmitted to a geographic region and the
routing decisions are essentially carried out based on distance criteria.
These protocols take advantage of the knowledge of the relative or absolute
locations of nodes. In the first case, the positions can be estimated according to RSSI of received messages. In the second, the node locations can
be obtained from positioning systems such as GPS, or can be preconfigured
in the sensor nodes prior to deployment. Various geographic routing protocols have not been specifically developed for WSNs, but they are suitable for
these scenarios given their scalability properties and potential benefits in
energy conservation.
7.1.3.1. GFG and GPSR
Greedy-Face-Greedy (GFG) [10] and Greedy Perimeter Stateless
Routing (GPSR) [11] are very similar geographic routing protocols which
are widely accepted for WSNs. In GFG/GPSR, the packets sent by a
source node include the location of the intended destination. If a node
knows the location of its neighbours, then it can forward the packet to
the node which is geographically closer to the destination. This process, which is known as greedy forwarding, is repeated until the packet
reaches the destination.
In GPSR, all nodes know the positions of their one-hop neighbours by
means of a simple beaconing mechanism. Each node periodically transmits
beacons which include their own position (hence, in GPSR, it is assumed that
all nodes are aware of their own position).
One of the major advantages of greedy forwarding is the fact that the
routing state (i.e. the information a node has to store to enable routing)
depends only on the number of neighbours of a node. Hence, this approach
scales well with the number of nodes of the network.
204
2/7/10
13:19
Página 205
Chapter 7. Routing
However, greedy forwarding fails in some situations when voids (i.e.
regions without intermediate nodes) are present between a node and its
destination. An example is shown in Fig. 7.4. A path between node A and
node D exists (the path is ABCD). However, because node B is further
from node D than node A, node A will not forward the data to node B, and
consequently node D cannot be accessed from node A with this routing
protocol.
Fig. 7.4. Example of a greedy forwarding failure. The dotted line indicates
the coverage range of node A
The problem described above can be solved with the application of the
right-hand rule. According to this rule, a node that receives a packet forwards it to its first neighbour counter-clockwise about itself. Intuitively, the
packet routes around the void. Greedy forwarding can be used again once a
node whose distance to the destination is smaller than the distance between the destination and the greedy failure node is found. Other possibilities exist in this regard [12].
Simulation results show that GFG/GPSR approximates shortest-path
routing in dense networks (where voids are infrequent).
205
2/7/10
13:19
Página 206
Sensors Everywhere
7.1.3.2. Other protocols
The Geographic Adaptive Fidelity (GAF) protocol [13] divides the area
where sensor nodes are deployed into zones by defining a virtual grid. This
grid is defined in such a way that the nodes within a zone are equivalent for
routing. Under such a condition, a single node within a zone can remain
awake to carry out the routing tasks on behalf of the others, which may be
sleeping to conserve energy. The control message overhead of the GAF protocol is comprised of discovery messages, which are broadcast by each
node to find other nodes within the same zone.
The Geographic and Energy Aware Routing (GEAR) protocol [14] is essentially an improvement over Directed Diffusion, whereby the interests are
transmitted to a certain geographic region instead of flooding the whole
network. In consequence, the energy consumption of the network is reduced. In addition, all nodes maintain the cost of reaching the destination
through their neighbours, which also takes into account the residual energy
of the neighbours. In GEAR, it is assumed that the nodes are aware of their
location.
7.2.
MANET routing protocols adapted for WSNs
One approach followed in many cases to provide multi-hop capabilities
to WSNs consists in reusing routing protocols developed by the IETF MANET
WG. While MANET routing protocols have been designed for scenarios with
limitations due to wireless communication and mobility, WSNs constitute a
further constrained scenario, especially in terms of the hardware capabilities
of the devices and available network resources. In consequence, the MANET
routing protocols considered for WSNs have required an adaptation process,
which has mainly consisted in a simplification of the protocols by the removal of non-core mechanisms.
Given the constraints of WSNs, and in order to minimize energy and
bandwidth consumption, only reactive routing solutions have been taken
into account. In particular, several solutions are based on the Ad-hoc Ondemand Distance Vector (AODV) routing protocol [15] (a relevant case is the
206
2/7/10
13:19
Página 207
Chapter 7. Routing
mesh routing solution of ZigBee, which is essentially based on AODV, as will
be seen in section 11.1.1.1). Some attention has also been devoted to the
Dynamic MANET On-demand (DYMO) routing protocol [16].
7.2.1. AODV-based routing protocols
This subsection first provides an overview of basic AODV operation. Then,
two AODV-based routing protocols for WSNs are presented. These protocols
are TinyAODV and Not So Tiny AODV (NST-AODV). Finally, other AODVbased proposals are also briefly introduced.
7.2.1.1. AODV basic operation
AODV is a reactive routing protocol. When a node requires a route, it initiates
a route discovery procedure by broadcasting Route Request (RREQ) messages
(see Fig. 7.5). Each node rebroadcasts RREQs, unless it has a valid route entry to
the destination or it is the destination itself. In this case, it sends a Route Reply
(RREP) message back to the originator node and ignores any subsequent
RREQs transmitted through alternative routes. Backward or forward next-hop
routing entries are created at each node that receives a RREQ or a RREP, respectively. Route entries expire after a specified time if the route becomes inactive (i.e., it is not used for data transmission). For each route entry of a node,
there is a precursor list containing the nodes that use this node as the next hop
in the path to a given destination. The loop-freedom of routes towards a destination is guaranteed by means of a destination sequence number, which is
updated when new information about that destination is received.
When a link in an active path breaks, the upstream node that detects this
break may try to repair the route locally if the destination is close to the
node. This is an optional mechanism. If local repair cannot be completed
successfully or it is not supported, the node that detects the link break creates a Route Error (RERR) message, which reports the set of unreachable
destinations. This message is sent to precursor nodes. If a route to the destination is still needed, the source of the active path then starts a new route
discovery phase. Data packets waiting for a route should be buffered during
route discovery.
207
2/7/10
13:19
Página 208
Sensors Everywhere
Fig. 7.5. Route Discovery in AODV: node S intends to find a path to node
D. Node S broadcasts a RREQ message; when a RREQ reaches the
destination, this node replies back to the source with a RREP message,
which is transmitted backwards to the source and creates routing entries
to node D in the intermediate nodes and the source node
An AODV node belonging to an active route may periodically broadcast
local Hello messages for connectivity management. However, this approach
may be expensive if nodes are battery-powered. Other strategies for detecting link failures include link layer mechanisms. For example, unsuccessful
link layer transmissions may be used as an indication of a link break for
AODV. This method is known as Link Layer Notification (LLN).
7.2.1.2. TinyAODV
TinyAODV [17] is a minimalist AODV implementation for devices running
TinyOS. In TinyAODV Release 2, only one node, namely a sink node, can be
the destination of any data transmission. TinyAODV Release 3 enables communication between any pair of nodes in the network. The following description corresponds to TinyAODV Release 3.
If a data packet must be sent and no route entry exists for the intended
destination, route discovery is performed, but the packet requiring the route is
discarded. The next packet will be the first one using the discovered route. A
number of route discovery retries (equal to 3 by default) can be performed.
In TinyAODV, only the destination generates RREP messages. A LLN
mechanism is supported for detecting link failures, assuming the usage of
208
2/7/10
13:19
Página 209
Chapter 7. Routing
an acknowledged mode at layer two. However, LLN is not enabled by
default. Thus, TinyAODV is targeted for static topology networks, where link
failures are not expected. In any case, the data packet undelivered due to a
link break is discarded. An RERR is then generated and locally broadcast by
the upstream node detecting the link failure. In any case, local repair is not
supported. Finally, hop count is the routing metric used in the TinyAODV
implementation.
7.2.1.3. NST-AODV
NST-AODV is a routing solution implemented in nesC18 language for
devices running TinyOS. It was developed on the basis of TinyAODV (Release
3), to which several features were added to improve its reliability and to provide better support for dynamic topologies [18]. The main characteristics of
NST-AODV are summarized below:
• An LLN mechanism is enabled by default. This requires the protocol to
run on top of the IEEE 802.15.4 reliable mode (where a node that
correctly receives a data frame sends an acknowledgement frame to
the sender).
• After an unsuccessful link layer transmission, up to two additional
retries triggered by layer three can be performed.
• When a packet leads to link failure detection due to three consecutive,
unsuccessful layer three transmission attempts, it is buffered and
transmitted if a new route can be found. This may happen if the node
that detects the break is the originator itself, or if it is an intermediate
node that locally repairs the route.
The implementation consumes 957 bytes of RAM and 4664 bytes of
ROM. According to experiments in a real IEEE 802.15.4 environment, each
hop in a path contributes 20 ms to the Round Trip Time (RTT) when a
route is available, and 30 ms when the route discovery time is included.
The Route Change Latency (RCL) incurred when a link fails and a new
18
nesC is a programming language based on the C language developed for TinyOS devices
(see Chapter 10).
209
2/7/10
13:19
Página 210
Sensors Everywhere
route has to be found is below 100 ms in many topologies. For a detailed
comparison of NST-AODV and other routing solutions, the reader is referred to [18].
7.2.1.4. Other proposals
AODVjr [19] and AODVbis [20] are the first two AODV proposals
aimed at reducing implementation complexity and leaving some features as optional. LoWPAN-AODV [21] and 6LoWPAN Ad Hoc On-Demand
Distance Vector Routing (LOAD) [22] were two proposals developed by
the IETF 6LoWPAN WG [23], which assumes use of IEEE 802.15.4 as the
radio interface. However, both proposals expired when another IETF WG,
the IETF Routing Over Low-power and Lossy networks (ROLL) WG [24],
was created with the aim of developing routing protocol solutions for
WSNs, making initial routing proposals from 6LoWPAN obsolete (see
section 7.3).
7.2.2. DYMO-based routing protocols
DYMO is a reactive routing protocol for MANETs which inherits most of
its essential functionality from AODV. The main new feature in DYMO
(when compared with AODV) is path accumulation. With this mechanism,
RREQ messages record the path they traverse. When a RREQ message
reaches the destination, the corresponding RREP that is transmitted back
to the source includes the path recorded in the RREQ. In this way, all the
intermediate nodes that transmit the RREP back can store the full route
from the source to the destination. Intermediate nodes can then make
use of this stored route if necessary, thus avoiding the Route Discovery
message overhead.
DYMO has also been considered for WSNs. A proposal called DYMOlow, which was a DYMO simplification developed by the IETF 6LoWPAN
WG, expired recently due to the reasons already given for LoWPAN-AODV
and LOAD expiries. A TinyOS implementation of the DYMO protocol is
called TYMO [25].
210
2/7/10
13:19
Página 211
Chapter 7. Routing
7.3
ROLL routing protocols
7.3.1. IETF ROLL WG scope and routing requirements
The IETF Routing Over Low power and Lossy Networks (ROLL) Working
Group [24] was created in late 2007 with the aim of analyzing and eventually developing solutions for IP-based Low power and Lossy Networks
(LLNs). LLNs are defined as networks composed of embedded devices with
limited power, memory and processing capabilities. LLNs include wireless
low power radios (e.g. IEEE 802.15.4) and wired solutions with similar characteristics, such as powerline communication (PLC) links.
The ROLL WG first elaborated a list of requirements for a routing protocol
on top of LLNs in each of the following application domains: home automation, commercial building automation, industrial automation and urban
automation. Based on these requirements, the WG carried out an analysis of
existing routing protocols within the IP domain with regard to their applicability to LLNs. The general requirements that can be derived from the requirements specific to each application domain are as follows [26]:
• The routing state of a node must not increase linearly with the number
of nodes in the network or in the neighbourhood. A routing state that
depends linearly on the number of unique destination is acceptable.
• Local events, such as the failure of a link between two nodes, must not
lead to flooding broadcast messages to the whole network.
• The rate at which the routing messages are sent or received must be
bounded by the rate of data packets.
The first requirement is a consequence of the need for scalability with
the network size and density. However, it precludes those WSNs where any
device can communicate with another (such a network may be found in the
building of automation applications, for instance [27]).
According to the analysis, none of the existing IP routing protocols would
fulfill all the criteria without modification. In consequence, the ROLL WG
started to work on the specification of a new routing protocol suitable for
211
2/7/10
13:19
Página 212
Sensors Everywhere
LLNs. This routing protocol is called IPv6 Routing Protocol for Low power
and Lossy Networks (RPL19) [28]. As of the writing of this book, the RPL specification is still being developed. The next subsection overviews RPL, based
on the latest version of its specification.
7.3.2. RPL
RPL maintains Directed Acyclic Graphs (DAGs), which may be rooted at
sink nodes or gateways to the rest of the Internet. The main difference between a DAG and a tree is the fact that, in a DAG, a node may select multiple neighbours as its parents (see Fig. 7.6). An important property of DAG is
loop-freedom. This is achieved in RPL by ensuring that any node must always
have a higher rank than any of its parents. A rank expresses the relative
position of a node within a DAG. The rank may (or may not) be related with the
routing cost for reaching the DAG root.
RPL naturally supports multipoint-to-sink and sink-to-multipoint communications. Point-to-point communications are also supported, but routes
between arbitrary nodes may not be optimal, since they are constrained to
the DAG structures.
RPL nodes build and maintain DAGs by periodically multicasting the DAG
Information Object (DIO) message to their neighbours. The DIO message
includes the rank of a node, the values used to calculate the routing cost
towards the DAG root and the DAG identifier, among other fields. In order to
join a DAG, a node listens to the DIO messages sent by its neighbours and
selects a subset of these messages as their parents in the DAG. A node may
also identify siblings, which are neighbours of this node having the same
rank as this node (but does not necessarily share a common parent with this
node). This allows path diversity to be increased, as a node can decide to
forward a packet to a sibling in RPL. A node might select one preferred
parent. The rank of this node would then be computed as the rank of the
preferred parent plus an increment which depends on the cost of the link
between the node and its preferred parent.
19
RPL is pronounced as ‘Ripple’.
212
2/7/10
13:19
Página 213
Chapter 7. Routing
Fig. 7.6. An example of a DAG in RPL. Note that Node 7 has two parents,
which are Nodes 2 and 3. Assuming that Nodes 4 and 6 are neighbours
of Node 5, Node 5 can choose both of them as siblings
In RPL, the path to be used in a DAG is determined by a certain objective
function, which specifies the routing metric and a certain objective. For
example, this objective may specify constraints with regard to the power
mode used by the nodes.
The period between transmitted DIO messages is computed using the
Trickle algorithm [29]. Each node maintains an interval I, which may vary
between Imin and Imax. During each interval, a counter k is incremented
every time a DIO advertising the same rank and cost as the last one is
received from a parent. The timer fires at a random time between I/2 and
I. Then, if k is smaller than a certain threshold, the node generates a new
DIO message, doubles the value of I and restarts the timer. If at any
moment a node receives a DIO message which is not consistent with the
node’s own rank, or which advertises a different rank or cost from the previous one, this node sets I to the minimum value and restarts the timer. In
consequence, in a stable DAG, the interval grows exponentially towards Imax
and the DIO message rate becomes low. When changes in the DAG occur,
the DIO messages are generated faster so as to allow a rapid convergence
to the new situation. The counter k offers a method to control the amount
of DIO overhead.
213
2/7/10
13:19
Página 214
Sensors Everywhere
7.3.3. IETF 6LoWPAN WG routing requirements
The IPv6 Low Power WPAN (6LoWPAN) WG, which has developed the
mechanisms for transmitting IPv6 packets on top of IEEE 802.15.4 networks
(see Chapter 11), has also specified a set of requirements and useful information for the design of routing protocols for these environments [30].
These requirements take advantage of the characteristics and services offered by IEEE 802.15.4. Some of these include:
• Avoidance of fragmentation due to IEEE 802.15.4 message size.
• Exploiting IEEE 802.15.4 ACKs as a method to check the connectivity
with a one-hop neighbour.
• Exploiting the LQI as an input to the routing metric.
• Considering the byte overhead of IEEE 802.15.4 security and the fact
that ACKs are not secure.
As of the writing of this book, RPL is a likely candidate routing protocol
for 6LoWPAN.
REFERENCES
[1] C. Intanagonwiwat, R. Govindan, D. Estrin, J. Heidemann, F. Silva,
“Directed Diffusion for Wireless Sensor Networking”, ACM/IEEE
Transactions on Networking, 11 (1 ), pp. 2-16, February, 2002.
[2] D. Braginsky, D. Estrin, “Rumor Routing Algorithm For Sensor Networks”,
in Proceedings of WSNA’02, Atlanta, USA, September 2002.
[3] M. Chu, H. Haussecker, F. Zhao, “Scalable Information-Driven Sensor
Querying and Routing for ad hoc Heterogeneous Sensor Networks”,
Xerox Palo Alto Research Center Technical Report, July 2001.
[4] R. C. Shah, J. M. Rabaey, “Energy Aware Routing for Low Energy Ad Hoc
Sensor Networks”, in Proceedings of the IEEE Wireless
Communications and Networking Conference 2002 (WCNC’02),
Orlando, USA, March 2002.
214
2/7/10
13:19
Página 215
Chapter 7. Routing
[5] Y. Yao, J. Gehrke, “Cougar Approach to In-Network Query Processing in
Sensor Networks”, SIGMOD Record, Vol. 31, No. 3, September 2002.
[6] N. Sadagopan et al., “The ACQUIRE mechanism for efficient querying in
sensor networks”, in the Proceedings of the First International
Workshop on Sensor Network Protocol and Applications, Anchorage,
USA, May 2003.
[7] W. Rabiner Heinzelman, A. Chandrakasan, H. Balakrishnan, “EnergyEfficient Communication Protocol for Wireless Microsensor Networks”,
in Proceedings of the 33rd Hawaii International Conference on System
Sciences, Island of Maui, Hawaii, USA, January 2000.
[8] S. Lindsey, C. S. Raghavendra, “Power Efficient Gathering in Sensor
Information Systems”, in Proceedings of the IEEE Aerospace
Conference 2002, Big Sky, Montana, USA, March 2002.
[9] A. Manjeshwar, D. P. Agrawal, “TEEN: A Routing Protocol for Enhanced
Efficiency in Wireless Sensor Networks”, 2001.
[10] P. Bose, P. Morin, I. Stojmenovic, J. Urrutia, “Routing with Guaranteed
Delivery in ad hoc Wireless Networks”, Workshop on Discrete
Algorithms and Methods for Mobile Computing and Communications,
Seattle, USA, 1999.
[11] B. Karp, H.T. Kung, “GPSR: Greedy Perimeter Stateless Routing for
Wireless Networks”, In Proceedings of the Seventh Annual ACM/IEEE
International Conference on Mobile Computing and Networking
(MOBICOM), Rome, Italy August 2000, Boston, USA.
[12] H. Frey, I. Stojmenovic, “On delivery guarantees of face and combined
greedy-face routing algorithms in ad hoc and sensor networks,” in
Proceedings of the Twelfth ACM Annual International Conference on
Mobile Computing and Networking (MOBICOM). Los Angeles, CA, USA,
September 2006.
[13] Y. Xu, J. Heidemann, D. Estrin,”Geography-informed Energy
Conservation for Ad-hoc Routing," In Proceedings of the Seventh
Annual ACM/IEEE International Conference on Mobile Computing and
Networking (MOBICOM), Rome, Italy 2001.
215
2/7/10
13:19
Página 216
Sensors Everywhere
[14] Y. Yu, D. Estrin, R. Govindan, “Geographical and Energy-Aware Routing:
A Recursive Data Dissemination Protocol for Wireless Sensor
Networks", UCLA Computer Science Department Technical Report,
UCLA-CSD TR-01-0023, May 2001.
[15] C. Perkins, E. Belding-Royer, S. Das, “Ad hoc On Demand Distance
Vector Routing (AODV)”, RFC 3561, July 2003.
[16] I. D. Chakeres, C. E. Perkins, "Dynamic MANET On-demand Routing
Protocol". draft-ietf-manet-dymo-14.txt, IETF Internet Draft (Work in
Progress), June 2008.
[17] TinyAODV implementation, TinyOS source code repository,
h t t p : / /c v s . s o u rc e f o u rg e . n e t / v i e w c v s . p y / t i n y o s / t i n y o s 1.x/contrib/hsn/
[18] C. Gomez, P. Salvatella, O. Alonso, J. Paradells, "Adapting AODV for
IEEE 802.15.4 Mesh Sensor Networks: Theoretical Discussion and
Performance Evaluation in a Real Environment", in Proceedings of
the 7th IEEE International Symposium on a World of Wireless, Mobile
and Multimedia Networks (WOWMOM 2006), Niagara Falls, USA, June
2006.
[19] I. Chakeres, L. Klein-Berndt, “AODVjr, AODV Simplified”, Mobile
Computing and Communications Review, Vol. 6, No. 3, pp. 100-101,
July 2002.
[20] C. E. Perkins, E. Belding-Royer, I. Chakeres, “Ad hoc On-Demand
Distance Vector (AODV) Routing”, draft-perkins-manet-adovbis-01,
IETF Internet Draft (Work in progress), February 2004.
[21] G. Montenegro, “AODV for IEEE 802.15.4 Networks”, draft-montenegrolowpan-aodv-00, IETF Internet Draft (Work in progress), July 2005.
[22] K. Kim, S. D. Park, G. Montenegro, S. Yoo, “6LoWPAN Ad Hoc On-Demand
Distance Vector Routing (LOAD)”, draft-daniel-6lowpan-load-adhocrouting-01, IETF Internet Draft (Work in progress), July 2005.
[23] IETF 6LoWPAN WG charter: http://www.ietf.org/dyn/wg/charter/6lowpan-charter.html
216
2/7/10
13:19
Página 217
Chapter 7. Routing
[24] IETF ROLL WG charter: http://www.ietf.org/dyn/wg/charter/roll-charter.html
[25] R. Thouvenin, “Implementing and evaluating the Dynamic MANET Ondemand (DYMO) routing protocol”, June 2007.
[26] P. Levis, A. Tavakoli, S. Dawson-Haggerty, “Overview of Existing Routing
Protocols for Low Power and Lossy Networks”, draft-ietf-roll-protocolssurvey-07, (Work in progress) April 2009.
[27] J. Martocci, P. De Mil, W. Vermeylen, N. Riou, “Building Automation
Routing Requirements in Low Power and Lossy Networks”, draft-ietfroll-building-routing-reqs-08, (Work in progress) December 2009.
[28] T. Winter et al., “RPL: IPv6 Routing Protocol for Low power and Lossy
Networks”, draft-ietf-roll-rpl-05, (Work in progress) December 2009.
[29] P. Levis, E. Brewer, D. Culler, D. Gay, S. Madden, N. Patel, J. Polastre, S.
Shenker, R. Szewczyk, A. Woo, “The emergence of a networking primitive in wireless sensor networks,” Communications of the ACM, Vol. 51,
No. 7, pp. 99–106, July 2008.
[30] E. Kim, D. Kaspar, C. Gomez, C. Bormann, “Problem Statement and
Requirements for 6LoWPAN Routing”, draft-ietf-6lowpan-routingrequirements-04, (Work in progress) July 2009.
217
2/7/10
13:19
Página 218
2/7/10
13:19
Página 219
8
Transport
2/7/10
13:19
Página 220
2/7/10
13:19
Página 221
Chapter 8. Transport
8. Transport
The transport layer is in charge of offering services such as end-to-end
reliability for data transmission. In some cases, transport layer protocols also
fulfil the requirements of congestion control mechanisms (e.g. congestion
avoidance in TCP [22]). However, WSNs exhibit different requirements from
those of traditional networks. Certain applications may require event detection, independently of the sensor nodes in the area that actually detect the
event. In this case, the transport protocol has to guarantee event reliability
rather than data reliability. On the other hand, in contrast to the traditional
operation of TCP, congestion control may be better performed hop-by-hop,
which conserves more energy and bandwidth. These facts have motivated
the design of a family of new transport and congestion control protocols for
WSNs.
Nevertheless, initiatives have been taken towards adapting protocols
such as TCP or UDP for WSNs. The availability of such protocols in WSNs has
significant benefits in terms of interoperability with the Internet and its protocols. However, TCP requires appropriate adaptation for its use in WSNs. As
of writing, 6LoWPAN-based WSNs use adaptations of TCP or UDP at the
transport layer.
This chapter is organized as follows. Section 8.1 focuses on the use of traditional transport protocols like TCP and UDP in WSNs. Section 8.2 presents
protocols specifically designed for congestion control in WSNs. Section 8.3
presents protocols that offer reliability in WSNs. Section 8.4 is devoted to
protocols that offer both congestion control and reliability in WSNs. Section
8.5 presents transport layer mechanisms in ZigBee. The reader may note
221
2/7/10
13:19
Página 222
Sensors Everywhere
that the Bluetooth specification does not specify transport layer20 mechanisms.
8.1.
Use of traditional transport protocols in WSNs
TCP can be used in WSNs that require reliability and/or congestion control. However, some controversy surrounds this topic, since several drawbacks and benefits have been claimed when using TCP in WSNs. These are
presented in subsections 8.1.1 and 8.1.2, respectively. A modified version of
TCP for WSNs called Distributed TCP Caching [26] is presented in 8.1.3. The
use of UDP is discussed in subsection 8.1.4. Finally, subsection 8.1.5 presents the use of transport layer proxies for WSNs.
8.1.1. Drawbacks of using TCP in WSNs
It has been argued that the Internet model is unsuited for WSNs because
of the specific requirements and the extreme communication conditions
that WSNs may exhibit [20]. TCP was indeed not designed for WSNs, but rather for networks composed mainly of wired links providing end-to-end packet reliability and congestion control. Several drawbacks have been documented about the use of TCP as a transport protocol in WSNs [7]:
• TCP connection establishment overhead might not be justified for
data collection in most event-driven applications.
• Flow and congestion control mechanisms in TCP may result in unfair
bandwidth for sensor nodes that are far away from the sink node in a
data collection application.
• It is well known that TCP has a degraded throughput in wireless systems, especially in situations with a high packet loss rate, because TCP
assumes that packet loss is due to congestion and reduces its transmission rate whenever packet loss is detected.
20
Here, ‘transport layer’ refers to the fourth layer in the OSI reference model. Nevertheless,
Bluetooth does specify mechanisms denoted ‘transport layer’, but these are link layer
mechanisms in terms of the OSI reference model.
222
2/7/10
13:19
Página 223
• In contrast to hop-by-hop control, end-to-end congestion control in
TCP requires a longer time to mitigate congestion, and in turn leads to
higher packet loss when congestion occurs.
• TCP relies on end-to-end retransmission to provide reliable data transport, which consumes more energy and bandwidth than hop-by-hop
retransmission.
• TCP guarantees successful transmission of packets, which is not
always necessary for event-driven applications in sensor networks.
Taking all the identified drawbacks into consideration, it can be concluded that TCP may not perform optimally in WSNs. In addition, significant
simplification effort is required to remove unnecessary TCP functionality
and make its operation feasible over constrained devices. For these reasons,
several transport protocols have been specifically designed for WSNs. These
protocols can be categorized into three types [7]: i) congestion control protocols, ii) protocols for reliability, and iii) protocols considering both congestion control and reliability. Sections 8.2, 8.3 and 8.4 focus on the main proposals of each type, respectively.
8.1.2. Advantages and initiatives toward the use of TCP in WSNs
The main advantage of using TCP (on top of IP) in WSNs is that it offers
straightforward end-to-end interoperability with other TCP/IP-based networks like the Internet. Another advantage of using TCP is that it offers compatibility with a large set of well known application layer protocols used in
the Internet (e.g. HTTP, FTP, etc.). On the other hand, it is worth pointing out
that although TCP may not perform optimally in WSNs, it has proved itself as
a protocol capable of operating adequately on top of a huge variety of different networking environments. For all these reasons, many efforts have
been made at using TCP in WSNs.
TCP can be used for tasks that require reliability (such as configuration
and monitoring of individual nodes and downloads of binary code) [1].
Despite the complexity of a protocol like TCP, it has been shown that an
implementation of the TCP/IP stack can be run on 8-bit micro-controllers
with only a few hundred bytes of RAM [2]. Other TCP/IP stacks have been
223
2/7/10
13:19
Página 224
Sensors Everywhere
developed with comparable code size [3]. Some of the most reduced TCP/IP
stacks described in the literature are the uIP stack [2], which has a size between 4 and 5 kB; nanoIP [4], with a size of 1 kB and PICNIC [5], with less than
2 kB. Some other reduced IPv6-based open-source and commercially available stacks have a footprint of around 10 kB [6].
The absence of TCP in WSNs might limit the availability of application
protocols that depend on or are implemented using TCP. Initial efforts
towards addressing this problem have been made within the IETF [21].
8.1.3. DTC
Distributed TCP Caching (DTC) [26] is a modified TCP for WSNs. The aim
of DTC is to reduce the energy consumption of WSN nodes by decreasing
the number of end-to-end retransmissions within the WSN, while offering
the interoperability advantages of using TCP/IP. In fact, DTC is based on a
hop-by-hop retransmission scheme.
In DTC, the end devices operate by using regular TCP. However, intermediate nodes cache segments of end-to-end communications if they have
available memory space. If node A is an intermediate node and has been
able to cache a TCP segment, it forwards the segment to the next hop, starts
a timer and waits for the reception of a link-layer acknowledgment sent by
the corresponding next hop. If the timer expires and the acknowledgment
has not been received, node A retransmits the segment. These mechanisms
enable the number of times in which the retransmission time-out of the TCP
sender expires to be reduced.
In effect, DTC adapts the main idea behind Snoop [25] for WSNs. Snoop was
designed as a TCP proxy placed at the base station for wireless cellular networks. Snoop caches TCP segments transmitted in the downlink (i.e. to the
mobile client) and maintains local timers so as to locally retransmit the lost
data segments. In this way, losses in the wireless link can be hidden from the
sender and its retransmission and congestion control mechanisms can be
avoided. While in DTC the described mechanisms may be present in various
intermediate nodes between sender and receiver, Snoop resides only in the
base station, that is, a single element between sender and receiver.
224
2/7/10
13:19
Página 225
8.1.4. Use of UDP in WSNs
UDP is a lightweight protocol that mainly adds source and destination
port information to IP datagrams. It offers neither reliability nor congestion
control. For this reason, UDP can be used in WSNs for applications that do
not require reliability in contexts of low congestion, while offering interoperability with IP networks (e.g. the Internet). Furthermore, as an alternative
to the use of TCP, UDP has been used for WSN devices running IP, augmented with acknowledged and numbered packet delivery. This approach
provides reliability and may be simpler than adapting TCP21. UDP can also be
suitable when application layer protocols offer reliability.
8.1.5. Use of transport layer proxies
A proxy is an entity placed between the endpoints of a communication
and is designed for improving degraded performance caused by the nature
of specific environments [24].
When the nodes of a WSN run a special transport layer protocol (e.g. a
simplified version of a traditional transport protocol or a new protocol specifically designed for WSNs), the communication with devices in another
network (e.g. hosts in the Internet) may benefit from the use of a proxy operating at the transport layer. Such proxies are referred to as transport layer
proxies.
A proxy may either be centralized (e.g. in a gateway that connects the
WSN with the Internet) or distributed between two or more devices (e.g. a
gateway and the WSN nodes). Some types of proxies break the end-to-end
principle, which is one of the fundamentals of the Internet architecture, but it
has been shown that they can dramatically enhance the performance of
Internet communications over limited environments [24]. On the other hand,
a transport layer proxy may enable the sensors within a WSN to be seen as
devices fully compliant with protocols such as TCP, while the sensors may run
a simplified version of those protocols or completely different ones.
21
As an example, the Compact Application Protocol (CAP) proposes running the ZigBee
Application Protocol on top of UDP/IP networks (see Section 13.3.3, Figure 13).
225
2/7/10
13:19
Página 226
Sensors Everywhere
8.2.
Protocols for congestion control in WSNs
Congestion may occur in WSNs due to two main causes: i) the packet
arrival rate at a node exceeding the node’s service rate, and ii) PHY/MAC
layer phenomena such as interference, errors and contention. This section
presents various protocols designed for congestion control in WSNs. They
basically differ in congestion detection, congestion notification and congestion mitigation mechanisms.
In the following, it is assumed that in a tree configuration of a sink-based
WSN (as in Fig. 8.1) the downstream direction means that source node is the
sink node and destination node is the sensor node, while the upstream
direction refers to the reverse direction. Thus, downstream traffic may be
one-to-many (e.g. the sink node disseminates a request or an update to
more than one sensor node) or one-to-one (if a message is transmitted from
the sink node to a specific sensor node), while in the upstream direction traffic is generally many-to-one (e.g. various sensors of the same type transmit
the data they collect to the sink).
Typically, the protocols presented in this section are defined to overcome
congestion issues in the upstream direction of a tree WSN topology.
In some WSN scenarios (e.g. control networks for building automation),
one-to-one communication between arbitrary nodes may be a significant
fraction of the traffic. The protocols presented in this section do not assume
such scenarios.
Fig. 8.1. Downstream vs. upstream traffic directions in a typical WSN
226
2/7/10
13:19
Página 227
8.2.1. CODA
Congestion Detection and Avoidance (CODA) [10] is a congestion control
scheme for WSNs. In particular, CODA was designed for event-driven WSNs,
where congestion may take place once a certain event has been detected.
CODA is composed of three mechanisms (coping with congestion detection,
notification and mitigation features respectively): i) receiver-based congestion detection, ii) open-loop hop-by-hop backpressure messages, and iii)
closed-loop multi-source regulation.
i) Queue occupancy may be used as a measurement to detect
congestion. However, it may only be accurate when a queue is
completely empty or nearly overflowing [10]. For this reason, CODA
uses a channel load measurement and compares it with a certain level.
In order to minimize the energy cost of such approach, this task is
carried out only at certain moments. More specifically, CODA assumes
the use of a CSMA MAC and takes advantage of the Clear Channel
Assessment procedure of this MAC, which requires a sensor node to put
the radio in receiver mode and listen to the medium before transmitting, and hence incurs no extra cost.
ii) Once a sensor node detects congestion, it broadcasts backpressure
messages to its neighbours. The sensor node may continue transmitting
these messages every certain period if congestion persists. Backpressure
messages are transmitted toward the source. When a node receives a backpressure message, it decides whether or not to forward the message
towards the source, according to its local conditions. On the other hand, this
sensor node may perform actions according to the local congestion policy,
such as dropping incoming data packets or Adaptive Increase Multiplicative
Decrease (AIMD) rate adjustment.
iii) When the event detection rate of a sensor node is greater than a
certain threshold, the sensor node activates the so-called ‘regulate bit’ in the
event packets that it transmits to the sink node. When the sink node receives a packet with the regulate bit set, it sends ACKs to all the sources related with that event. Reception of such ACKs by the sources allows them to
maintain the same transmission rate. If the sources do not receive the ACKs,
227
2/7/10
13:19
Página 228
Sensors Everywhere
they reduce their transmission rate. ACKs may be lost in the network due to
congestion. On the other hand, the sink node may stop transmitting ACKs
according to its own local congestion measurements.
8.2.2. Fusion
Fusion [9] is a congestion control scheme for WSNs that combines three
techniques for detection, notification and mitigation of congestion: i) hopby-hop flow control, ii) rate limiting, and iii) a prioritized MAC.
i) The goal of hop-by-hop flow control in Fusion is to avoid packet
transmission if packets are to be discarded due to congestion in the paths
towards the destination. This mechanism comprises two significant components: congestion detection and congestion mitigation. Congestion can be
detected by monitoring the occupancy of the sensor node queue or by
measuring the utilization of the channel. In Fusion, once congestion is
detected, a congestion bit is set in the header of data packets (which are
transmitted to the sink). Congestion mitigation is performed as follows: Let
us assume that a parent is the next hop of a given sensor node in the path
towards the sink; this sensor node is a child of the parent node. If a sensor
node overhears a packet from its parent with the congestion bit set, then it
stops forwarding data. If this sensor node and other children of that parent
become congested in turn, they are allowed to transmit once (with the congestion bit set) so that their own children can learn that they are congested.
ii) The rate limiting mechanism in Fusion is based on the use of a
token bucket to regulate the rate of each sensor node. This mechanism
is described next. Every time a sensor node hears that its parent forwards N packets, its token count is incremented by one. The sensor
node can only transmit when there are tokens available, and each
transmission decreases the token count by one. In this way, each sensor node sends at the same rate as each of its descendants. This
mechanism reduces the probability of congestion points occurring as
well as increasing fairness.
iii) Finally, Fusion uses a MAC layer technique that prioritizes the transmission of congested nodes. In particular, a CSMA MAC is assumed, and the
228
2/7/10
13:19
Página 229
back-off window of congested nodes is one fourth the size of a non-congested sensor’s back-off window. With this technique, the probability of
winning the contention period of a congested sensor node increases.
8.2.3. CCF
The algorithm for Congestion Control and Fairness (CCF) [16] also aims at
eliminating congestion in a WSN while assuring fair packet delivery to a sink
node. It operates at the transport layer on top of any MAC layer. Note that
this is not always so, as is the case in CODA or Fusion (which run on top of
a CSMA MAC layer).
The algorithm deals with two types of congestion. The first occurs
when several sensor nodes within the same range wish to transmit at the
same time. To reduce this kind of congestion, jitter (i.e. a small random
delay variation before transmission) is introduced. Secondly, queue occupancy is monitored in order to detect congestion within a specific sensor node. If the occupancy of the queue that holds packets before they
are transmitted exceeds a certain threshold (before the queue becomes
full), the downstream sensor nodes are informed in order to reduce their
transmission rates.
To implement the aforementioned ideas, the algorithm measures
the actual rate r at which packets can be transmitted from a given sensor node, which is the inverse of the total service time required by the
transport layer. This service time includes all the congestion effects
that a node may suffer. It then calculates the maximum rate at which
the nodes of its complete sub-tree can transmit, rdata, as the rate r divided by the number of devices in the sub-tree. Every sensor node also
calculates the rate rdata,qfull, at which its queues are about to overflow, as
well as the sensor node’s data generation rate, rdata,parent. parent. The children nodes are then periodically informed of the maximum transmission rate they are allowed to use, which is set to min{r data, rdata,qfull,
rdata,parent.}. Note that with this algorithm, the rate assignment for each
node is fair.
229
2/7/10
13:19
Página 230
Sensors Everywhere
The mechanism described constitutes a closed loop that is in constant oscillation. Fig. 8.2 illustrates an example. If the shaded sensor
node (Fig. 8.2.a)) experiences congestion, it informs its children nodes
in order to reduce their transmission rate (Fig. 8.2.b)). This information
is propagated throughout the network, and because smaller rates are
used, node queues become empty and the time to transmit a packet
successfully decreases (Fig. 8.2.c)). The shaded node disseminates the
new (increased) rate (Fig. 8.2.d)) again, which in turn may cause congestion and thus the cycle repeats.
Fig. 8.2. CCF operation (adapted from [16])
Because rate updates reach the nodes with a time proportional to the
hop count from the parent node (e.g. the shaded node in the example), sensor nodes of different depths experience phase shifts in their transmissions,
which are equivalent to the jitter that it was desirable to introduce, as explained above.
230
2/7/10
13:19
Página 231
8.2.4. PCCP
Priority-based Congestion Control Protocol (PCCP) [12] aims at controlling congestion in a WSN, while addressing the fact that nodes may have
different priorities depending on their location and/or function. PCCP is
composed of three main components: i) Intelligent Congestion Detection
(ICD), ii) Implicit Congestion Notification (ICN), and iii) Priority-based Rate
Adjustment (PRA).
ICD detects congestion according to packet inter-arrival and packet
service times at the MAC layer of a node. Packet inter-arrival is defined
as the time between two consecutive arriving packets, which can either
be generated by a different node, required to be forwarded by this
node, or alternatively can be packets created by this node. The packet
service time is defined as the time difference between the instant at
which the packet arrives at the MAC layer and the instant at which the
last bit of the packet is transmitted. PCCP uses a parameter called congestion degree, which is the ratio of average packet service time over
average packet inter-arrival time. If the congestion degree is greater
than one, the node experiences congestion.
In order to propagate congestion information, PCCP uses ICN, which is
based on piggybacking congestion information in the header of data packets. The transmission of these packets can be overheard by the nodes within the range of the corresponding sender. Hence, the children of a node can
know when their parent is congested.
Finally, PRA requires the introduction of a scheduler with two subqueues between the network layer and MAC layer (see Fig. 8.3). One
sub-queue is for traffic generated in the node and the other is for transit traffic. On the basis of three priority index values, the scheduler gives
the appropriate weight to each sub-queue and the scheduling rate is
calculated in order to avoid or mitigate congestion. This calculation
uses the congestion degree and priority index values for accurate rate
adjustment.
231
2/7/10
13:19
Página 232
Sensors Everywhere
Fig. 8.3. Node model that includes sub-queues between MAC and network
layer (adapted from [12])
Simulation results show that PCCP outperforms CCF in terms of throughput. This happens because CCF does not take into account the packet interarrival time (recall that CCF is based on measuring the packet service time).
When errors take place in the wireless links, inter-arrival time increases, leading to channel under-utilization. CCF erroneously treats such under-utilized
links as congested links.
8.2.5. Siphon
Siphon [18] was also developed assuming a WSN used for data
collection from sensor nodes to a sink node. In particular, it was designed as an alternative to other congestion control mechanisms,
which are based on decreasing transmission rates and even dropping
packets when congestion occurs. In effect, application data delivery
ratio at the sink node may be compromised by these mechanisms in
certain scenarios.
Siphon comprises a set of algorithms that enable congestion to be
detected and then mitigated by using virtual sink nodes, which are
equipped with at least a secondary, long range, radio in addition to the
primary one (e.g. cellular packet data services). The virtual sink nodes
are defined as nodes with a different purpose than that of the physical
sink node. The latter is the sink that typically exists in data collection
WSNs. When congestion is detected in some area of the WSN, part of
the traffic is transmitted to the virtual sink nodes, which forward the
232
2/7/10
13:19
Página 233
traffic to the physical sink node using the secondary radio. Hence, the
virtual sink nodes fool the rest of nodes since they appear as new destination devices (i.e. additional sinks), but they actually by-pass traffic to
the physical sink node using the secondary radio. Authors of Siphon
justify that the benefits of the presence of some devices with two
radios within a WSN can compensate their financial cost.
In Siphon, congestion can be detected either by a sensor node or by the
physical sink node. In the first case, the techniques used are similar as those
in CODA (i.e. measurement of channel load and buffer occupancy). In the
second , the physical sink node monitors the fidelity and quality of the data
received, and activates the use of virtual sink nodes. One advantage of this
technique is that it does not require the sensor nodes to execute congestion
detection tasks. Virtual sink node discovery is based on the transmission of
periodic control traffic from the physical sink node.
8.2.6. Summary
Table 8.1 summarizes the main characteristics of congestion control protocols presented in the previous sections 8.2.1 to 8.2.5.
233
2/7/10
13:19
Página 234
Sensors Everywhere
Protocol
Congestion
detection
CODA
Buffer occupancy
-Queue length
monitoring and
channel load
measurements
-Take advantage of
Clear Channel
Assessment
Procedure(CSMA MAC
at lower layer)
Buffer occupancy
-Queue length
monitoring and
Channel load
measurements
Hop-by-hop broad
casting of back–
pressure messages
towards the
source
End-to-end AIMD
rate adjustment
-Close loop multisource event
detection rate
regulated at sink
node (ACK procedure)
Hop-by-hop
transmission
back (towards
the source)
of packets with
congestion bit set.
CCF
Buffer occupancy
-Packet service time
and queue length
monitoring
PCCP
Congestion degree
calculated as the
ratio of packet inter
-arrival time to packet
service time at
MAC layer
Buffer occupancy
(as in CODA)
Hop-by-hop periodical
information back
(towards the
source) of the
maximum allowed
transmission rate
Hop-by-hop
piggybacking
information in the
header of data
packets
End-to-end / stop -and
-start rate adjustment
-Based on a token
bucket mechanism
Nodes transmission
prioritisation
-Reduction of the backoff windows of congested
nodes (CSMA MAC
at lower layer)
Exact rate adjustment
-Fair assignment for
the nodes of a
complete sub-tree
Fusion
Siphon
Congestion
Notification
No notification
Congestion Mitigation
(Reaction Mechanism)
Exact rate adjustment
-Own traffic and
transit traffic are
assigned different
priorities at each node
No rate adjustment
-Traffic redirection to
“virtual links” using a
secondary radio interface
control (adapted from [7])
234
2/7/10
13:19
Página 235
8.3.
Protocols for reliability in WSNs
Reliability in WSNs can be classified into two categories: i) packet reliability, where applications require all packets to be successfully received,
and ii) event reliability, where applications require event detection, but
reception of all packets is not needed. This section presents various protocols of each category.
8.3.1. ReInForM
Reliable Information Forwarding (ReInForM) [23] is a protocol that offers
stochastic packet reliability in WSNs, that is, packets are delivered with a certain probability. ReInForM uses neither Automatic Repeat reQuest (ARQ)
mechanisms nor queues.
ReInForM requires that nodes know some network parameters, such as
the hop distance between themselves and the sink node, as well as the hop
distance between their neighbours and the sink node. In addition, a node
must know the channel error probability. In order to do this, the sink node
periodically broadcasts a packet called routing update. When a node receives this packet, the node can learn from this packet what the hop distance is from the sink, since a field in this packet is updated accordingly
every time it is forwarded by a node. Through this packet, the node also discovers who its neighbours are and their hop distance from the sink node.
When a node has a packet to transmit to the sink node, the first step is to
assign a priority level. ReInForM defines n priority levels, each one of which
corresponds to a certain delivery probability. According to the hop distance
between the node and the sink node and the channel error probability, the
node calculates the number of copies of the packet that are required. The
copies are primarily sent to one of the neighbours of the node which are one
hop closer to the sink node, should such neighbours exist. Otherwise, they
are sent to one of the neighbours that are at the same distance from the sink
node, should they exist. Finally, if all neighbours are one hop further from
the sink node than this node, the copies of the packet are sent to one of
these neighbours. In each of these three options, the selected next hop is
235
2/7/10
13:19
Página 236
Sensors Everywhere
chosen randomly, which allows the load for the network nodes to be balanced and node lifetime to be maximized.
8.3.2. RMST
Reliable Multi-Segment Transport (RMST) [14] is a transport layer designed to operate in conjunction with the Directed Diffusion routing protocol [19] (see Chapter 7). RMST benefits from Directed Diffusion in two ways.
First, after the failure of a node, a new path is found by Directed Diffusion.
Secondly, Directed Diffusion finds paths from source to sink node which are
exploited by RMST as reverse paths. RMST provides two transport services:
fragmentation and reassembly of long data units and guaranteed end-toend packet delivery. RMST offers two mechanisms for the latter.
One option for guaranteeing packet delivery in RMST is based on a
hop-by-hop scheme. Nodes may cache the fragments of a larger data
unit on the path from source to sink node. This option allows nodes that
identify that a fragment is missing to send a repair request to the previous
node. The repair request, which is equivalent to a selective Negative
Acknowledgment (NACK), indicates what fragment is missing. If such a
fragment is in the local cache of the previous node, it is retransmitted.
Otherwise, the repair request is forwarded by the previous node to its
own previous node.
The other mechanism for reliability in RMST is a pure end-to-end approach, where the sink nodes, which receive data from the sources, transmit
selective NACKs to the sources.
Losses in RMST are detected upon timer expiration. RMST adds little
overhead since the only control message introduced by RMST is the NACK.
8.3.3. RBC
Reliable Bursty Converge-cast (RBC) [15] was designed for WSN applications where the detection of an event generates a large burst of packets
which need to be transported reliably to a sink node and with low delay. The
need for transmitting a large number of packets in a short time leads to
236
2/7/10
13:19
Página 237
channel contention, which is magnified by the fact that packets are transmitted several times via multi-hop routes until they reach the sink node.
RBC takes advantage of the fact that bursty converge-cast does not
require in-order delivery. RBC uses a hop-by-hop, window-less block acknowledgment scheme that guarantees continuous packet forwarding
independent from packet or ACK losses. Otherwise, window-based mechanisms may suffer transmission stalls that lead to throughput decrease.
RBC uses virtual queues at each node, which are managed without any
window-based control and allow newly arrived packets to be sent immediately, instead of waiting for the previously sent packets to be acknowledged. A node R that forwards data packets received from node S, includes
in each transmitted packet the maximal sequence of packets without any
loss in the middle. Node S can then overhear node R’s transmissions and
learn which packets have been correctly received. After sending a packet,
the sender starts a retransmission timer. If the timer expires and the packet
has not been acknowledged, it is retransmitted.
RBC has a mechanism for detecting and dropping duplicate packets.
Duplicate packets may be generated when ACKs for correctly received
packets are lost and the same packets are retransmitted. To enable this
mechanism, each queue has a counter that is incremented every time a new
packet is stored in the queue. Nodes maintain the last counter value piggybacked in the last packet from that queue.
When channel contention occurs, retransmissions can further contribute
to that contention. To ameliorate this, RBC accounts with a distributed contention control scheme that schedules packet retransmissions. Within a
node, the retransmission of a packet experiences a delay that grows with the
number of times the packet has already been retransmitted. Across nodes,
those having more packets to transmit of similar freshness (which is piggybacked to the data packets it sends) are allowed to transmit earlier.
8.3.4. PSFQ
Pump Slowly, Fetch Quickly (PSFQ) [17] is a transport protocol designed to
provide reliability in one-to-many communications in WSNs. An example of
237
2/7/10
13:19
Página 238
Sensors Everywhere
this application is the transmission of code from a source to a group of sensor
nodes for reprogramming them. The approach in PSFQ is a slow data transmission from a source node to the sensor nodes (“pump slowly”) and an aggressive recovery of missing segments from neighbours (“fetch quickly”).
The authors of PSFQ assumed a scenario where packet losses occur due
to errors in the wireless links. In PSFQ, error recovery is performed hop-byhop, which offers better scalability and performance in the presence of
errors than the end-to-end approach. Hence, all nodes are in charge of loss
detection and recovery. In fact, nodes cache the data they forward (which is
reasonable for the class of applications for which PSFQ is designed, since
nodes are in many cases receivers of the same data).
The pump operation is performed as follows: a source node broadcasts
data packets to its neighbours at a controlled rate until all the data have
been transmitted. For each received packet, neighbours check if the packet
has been received before, discarding any duplicates (packets include
sequence numbers). Otherwise, the packet is stored and then broadcast
after being purposefully delayed.
When a node finds a gap in the sequence of received packets, it initiates
the fetch operation. The node requests a retransmission from neighbouring
nodes once loss is detected. The request, which constitutes a NACK message, signals as many gaps within the same message as possible. NACKs are
retransmitted if the missing segments cannot be recovered. Only if the number of NACK retransmissions reaches a certain maximum and the missing
segments have not been recovered, is the NACK then relayed by the neighbours of the node. This technique controls the problem of message implosion, whereby the message would be retransmitted by all the nodes and
might cause the network to collapse.
Because PSFQ is based on a NACK approach, and hence the data source
has no explicit feedback about data reception in the destinations, PSFQ
additionally supports a report operation by which the furthest node from
the source transmits a report message (back to the source) on a hop-by-hop
basis. Other nodes en route toward the source may append their own report
to this message. This mechanism allows the source to have some feedback
while the amount of messages involved in the operation is controlled.
238
2/7/10
13:19
Página 239
8.3.5. Summary
Table 8.2 summarizes the main characteristics of reliability control protocols presented in the previous sections 8.3.1 to 8.3.5. Some transport protocols for WSNs manage upstream reliability (i.e. from sensor nodes to a sink
node), while others operate on downstream reliability.
Protocol
Packet Loss Detection
and Notification
Reliability
ReINForM
No mechanisms
Upstream reliability
Packets delivered with a
certain probability
RMST
– Selective NACK in
conjunction with timerdriven mechanisms
– Directed Diffusion
Routing Protocol
(after node failure)
Upstream reliability
– Fragmentation &
reassembly of long
data units
– Guaranteed end
– to-end packet
delivery. Two options:
a. Hop-by-hop
loss recovery
b. Pure end-to-end approach
RBC-
– Window-less block
acknowledgment with
implicit ACK
The same as RMST
PSFQ
NACK-based loss detection
and notification, and local
retransmission for loss
recovery
Downstream reliability
– Hop-by-hop errors
recovery
–“Pump Slowly Fetch Quickly”
approach
Table 8.2. Main characteristics of transport protocols for reliability
239
2/7/10
13:19
Página 240
Sensors Everywhere
8.4.
Protocols for congestion control and reliability in WSNs
This section describes the most relevant protocols that have been designed for both congestion control and reliability in WSNs. Both protocols
assume a WSN where data are collected by sensor nodes and are transmitted to the sink node, as well as coping with congestion control and reliability for this traffic pattern.
8.4.1. STCP
Sensor Transmission Control Protocol (STCP) [8] was designed as a transport layer for WSNs which is generic in terms of the underlying protocols
(e.g. MAC protocols) and the applications on top of it.
In STCP, each data flow from a sensor node to the sink node may have
different characteristics in terms of flow type, transmission rate and reliability. These characteristics are codified in a session initiation packet, which is
transmitted by a sensor node before transmitting packets. Different flows
may exist between a sensor node and the sink node.
Two different reliability mechanisms are used, depending on the nature
of flows, which can be classified as i) continuous flows, and ii) event-driven
flows.
• In continuous flows, the transmission rate of the source is known by
the sink node. Hence, the sink node can calculate the expected arrival
time of successive packets. If the sink node does not receive a packet
in the expected time, the sink node transmits a Negative
Acknowledgment (NACK) for that packet to the source. Upon receipt of
a NACK, the source retransmits the corresponding packet. To solve the
problem of NACK loss, the sink node periodically checks a record of the
packets that have not yet been received and retransmits NACKs if
necessary.
• In event-driven flows, the sink node cannot know a priori the packet
arrival times. Hence, in this case, the sink node transmits a positive acknowledgment (ACK) to inform the source that a packet has been
240
2/7/10
13:19
Página 241
correctly received. Transmitted packets are buffered by the source until
their reception is acknowledged by the sink node. The sensor nodes
maintain a timer so that buffered packets are retransmitted when the
timer expires.
STCP controls variable reliability as follows.
• For continuous flows, the sink node calculates the ratio of successfully
received packets. If a packet is not received at the expected time, but
current reliability satisfies the one required, then the sink node does
not send a NACK to the sensor node. A NACK is only sent if current
reliability is below the one required.
• For event-driven flows, where instead of reliable transmission of each
packet it is only relevant to assure that the event has been reported to
the sink, STCP does not transmit acknowledgments. This is because
data from different sensor nodes that detect the same event are correlated. Hence, the energy consumption due to transmission of acknowledgments is avoided.
Congestion detection and congestion mitigation mechanisms in STCP
are similar to CODA mechanisms (see section 8.2.1). However, congestion
notification is carried out differently. In STCP, when the load is greater
than a lower threshold (but smaller than a higher threshold), then a congestion notification bit is activated in some randomly chosen packets. If
the load becomes greater than the higher threshold, then all packets are
transmitted with the congestion notification bit set. When the sink node
receives a packet with the congestion bit set, it activates a congestion bit
in the acknowledgment. Upon receipt of such acknowledgment, the sensor node may route data through a different path or may reduce the
transmission rate.
8.4.2. ESRT
The Event-to-Sink Reliable Transport (ESRT) protocol [13] was designed
to achieve reliable event detection in a WSN, while aiming at conserving
energy. ESRT is suitable for WSN applications that require a certain event to
be detected, instead of end-to-end packet reliability. Most of the ESRT func-
241
2/7/10
13:19
Página 242
Sensors Everywhere
tionality runs on the sink node. ESRT assumes that sensor nodes periodically report the data they collect at a reporting frequency, f, and the sink
node is in charge of processing the reports transmitted by the sensor nodes
for detecting an event
In ESRT, the sink node compares the observed event reliability, r, defined
as the number of received packets during a certain interval, with the desired
event reliability, R, defined as the required number of received packets
during that interval for reliable event detection.
ESRT aims at achieving the desired reliability while at the same time
avoiding network congestion. Sensor nodes monitor local buffer levels in
order to detect congestion. If a sensor node detects congestion, it signals
this fact in the next data packet it transmits to the sink node. If the sink
node measures event reliability almost equal to the desired one, and no
congestion notification takes place, then the WSN is operating optimally.
Otherwise, the sink node computes a new reporting frequency, f, for the
next interval, which is broadcast to the source nodes. The new reporting
frequency may be greater, equal to or smaller than the previous one,
depending on the particular network state determined by the sink node
according to its measurements.
Table 8.3 shows the different network states defined in ESRT and the
corresponding actions taken by the sink node in each case. The process is
repeated until the measurements made by the sink node indicate that the
WSN is operating optimally. The sink node detects congestion on the basis
of local buffer occupancy measurements.
242
2/7/10
13:19
Página 243
Network state
ESRT Action
No congestion, low reliability
Multiplicatively increase f
Achieve required reliability as soon as
possible
No congestion, high reliability
Decrease f conservatively
Cautiously reduce energy consumption
so as not compromise on reliability
Congestion, high reliability
Decrease f aggressively to relieve congestion
Congestion, low/equal reliability
Decrease f exponentially
Relieve congestion as soon as possible
Optimal operating region
f remains unchanged
Table 8.3. Summary of ESRT actions (adapted from [13])
8.4.3. Summary
Both transport protocols discussed in previous Sections 8.4.1 and 8.4.2
are generic end-to-end upstream protocols. The main differences are that
while ESRT offers event reliability by means of an end-to-end source reporting frequency adjustment, STCP implements a controlled variable reliability
utilizing the diversity in applications (continuous flows and event-driven
flows). Table 8.4 summarises the key characteristics of these two transport
protocols.
243
2/7/10
13:19
Página 244
Sensors Everywhere
Protocol Congestion
Detection
Congestion
Notification
Congestion
Mitigation
Reliability
STCP
Load
monitoring
Percentage of
packets (which
depends on
load) with
congestion
notification bit
activated
Source node
may reduce
data rate or
may route
traffic through
another path
Controlled variable
reliability
utilizing the
diversity in
applications:
-Continuous
flows: NACK
-based end-to-end
retransmission
-Event-driven
flows: ACKbased end-to-end
retransmission
ESRT
Buffer
occupancy
Congestion is
signalled in the
next packet
transmitted to
the sink
Decrease the
reporting
frequency f
aggressively (in
high reliability
conditions) or
exponentially
(in low/equal
reliability
conditions)
-Focused on
guarantees
event reliability
-End-to-end
source
reporting
frequency
adjustment
control and reliability
8.5.
Transport mechanisms in ZigBee
ZigBee offers support for reliable data transport between two end devices. Because ZigBee does not define a transport layer, reliability is achieved
at the application layer as follows: application layer data units in ZigBee
include an acknowledgment request bit. The recipient of such a data unit
244
2/7/10
13:19
Página 245
must send an ACK back to the source. If the ACK is not received by the source,
then the data unit is retransmitted. ZigBee does not provide congestion control
mechanisms.
REFERENCES
[1] A. Dunkels, J. Alonso, T. Voigt, “Making TCP/IP Viable for Wireless Sensor
Networks”, in proceedings of the 1st European Workshop on Wireless
Sensor Networks (EWSN’04), Berlin, Germany, June 2004.
[2] A. Dunkels, “Full TCP/IP for 8-bit architectures”, in proceedings of
Mobisys’03, San Francisco, USA, May 2003.
[3] L. Casals, J. Paradells, “Internet en las Cosas”; in proceedings of XV
Jornadas Telecom I+D, 2005. (in Spanish)
[4] Z. Shelby, “NanoIP: The Zen of Embedded Networking”, in proceedings
of the IEEE International Conference on Communications, Anchorage,
USA, May 2003.
[5] picnic – bringing pic and nic together (Ethernet). http://picnic.sourceforge.net.
[6] A. Dunkels, J.P. Vasseur, “IP for Smart Objects”, Internet Protocol for
Smart Objects (IPSO) Alliance White Paper #1, September 2008.
[7] C. Wang et al., “A Survey of Transport Protocols for Wireless Sensor
Networks”, IEEE Network, pp. 34-40, May/June 2006.
[8] Y. G. Iyer, S. Gandham, and S. Venkatesan, “STCP: A Generic Transport
Layer Protocol for Wireless Sensor Networks,” Proc. IEEE ICCCN 2005,
San Diego, CA, Oct. 17–19, 2005.
[9] B. Hull, K. Jamieson, and H. Balakrishnan, “Mitigating Congestion in
Wireless Sensor Networks,” Proc. ACM Sensys ’04, Baltimore, MD, Nov.
3–5, 2004.
[10] C.-Y. Wan, S. B. Eisenman, and A. T. Campbell, “CODA: Congestion
Detection and Avoidance in Sensor Networks,” Proc. ACM Sensys ’03,
Los Angeles, CA, Nov. 5–7, 2003.
245
2/7/10
13:19
Página 246
Sensors Everywhere
[11] S.-J. Park et al., “A Scalable Approach for Reliable Downstream Data
Deliveryin Wireless Sensor Networks,” Proc. ACM MobiHoc ’04,
Roppongi, Japan, May 24–26, 2004.
[12] C. Wang et al., “Priority-Based Congestion Control in Wireless Sensor
Networks”, IEEE Int’l. Conf. Sensor Networks, Ubiquitous, and
Trustworthy Comp., Taichung, Taiwan, June 5–7, 2006.
[13] Y. Sankarasubramaniam, O. B. Akan, and I. F. Akyildiz, “ESRT: Event-toSink Reliable Transport in Wireless Sensor Networks,” Proc. ACM
Mobihoc ’03, Annapolis, MD, June 1–3, 2003.
[14] F. Stann and J. Heidemann, “RMST: Reliable Data Transport in Sensor
Networks,” Proc. IEEE SNPA ’03, Anchorage, AK, May 11, 2003.
[15] H. Zhang et al., “Reliable Bursty Convergecast in Wireless Sensor
Networks,” Proc. ACM Mobihoc ’05, Urbana-Champain, IL, May 25–28,
2005.
[16] C.-T. Ee and R. Bajcsy, “Congestion Control and Fairness for Many-toOne Routing in Sensor Networks”; Proc. ACM Sensys ’04, Baltimore,
MD, Nov. 3–5, 2004.
[17] C.-Y. Wan and A. T. Campbell, “PSFQ: A Reliable Transport Protocol for
Wireless Sensor Networks,” Proc. ACM WSNA ’02, Atlanta, GA, Sept. 28,
2002.
[18] C.-Y. Wan, A. T. Campbell, S. B. Eisenmann, J. Crowcroft, “Siphon:
Overload Traffic Management using MultiRadio Virtual Sinks in Sensor
Networks”, in proceedings of ACM SenSys’05, San Diego, November
2005.
[19] C. Intanagonwiwat, R. Govindan, and D. Estrin. “Directed Diffusion: A
Scalable and Robust Communication Paradigm for Sensor Networks”.
In Proceedings of ACM/IEEE International Conference on Mobile
Computing and Networking, pp. 56-67, Boston, MA, USA, August
2000.
[20] D. Estrin, R. Govindan, J. Heidemann, and S. Kumar, “Next century
challenges: scalable coordination in sensor networks”. In MobiCom
’99: Proceedings of the 5th annual ACM/IEEE international confe-
246
2/7/10
13:19
Página 247
rence on Mobile computing and networking, pp. 263–270, New York,
USA, 1999.
[21] C. Bormann, D. Sturek, Z. Shelby, “6LowApp: Problem Statement for
6LoWPAN and LLN Application Protocols”, Internet Draft, (Work in progress) July 2009 .
[22] W. Stevens, “TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms”, RFC 2001, January 1997.
[23] B. Deb, S. Bhatnagar, B. Nath, “ReInForM: Reliable Information
Forwarding Using Multiple Paths in Sensor Networks”, in proceedings of
IEEE LCN, Bonn, Germany, October 2003.
[24] C. Gomez, M. Catalan, D. Viamonte, J. Paradells, A. Calveras, "Web browsing optimization over 2.5G and 3G: End-to-end mechanisms vs. usage
of performance enhancing proxies", Wireless Communications &
Mobile Computing Journal 2008.
[25] H. Balakrishnan et al. “Improving TCP/IP Performance Over Wireless
Networks”, in proceedings of Mobicom’95, Berkeley, California, USA,
November 1995.
[26] A. Dunkels et al. “Distributed TCP Caching for Wireless Sensor
Networks”, in proceedings of the Third Annual Mediterranean Ad Hoc
Networking Workshop, Turkey, June 2004.
247
2/7/10
13:19
Página 248
2/7/10
13:19
Página 249
9
Security
2/7/10
13:19
Página 250
2/7/10
13:19
Página 251
Chapter 9. Security
9. Security
The broadcast nature of wireless communications opens the door to a
wide range of security attacks, and WSNs are no exception. In fact, some
WSN applications may be very sensitive to security attacks. For instance, the
introduction of erroneous messages in an industrial WSN, or even sometimes in a residential environment, may cause serious problems.
Security mechanisms such as encryption, authentication or communication integrity are based on cryptographic methods. These mechanisms are
processing-hungry and contribute significantly to implementation code
size. Hence, there is a trade-off between security functionality and hardware
capabilities.
This chapter is organized as follows. Section 9.1 presents a set of security
functions which may be required in WSNs. Section 9.2 focuses on how those
functions are implemented in the IEEE 802.15.4 standard. Section 9.3 presents the architecture and functional description of the security services provided by ZigBee. Section 9.4 concludes the chapter with a brief overview of
the current status of security mechanisms of other WSN solutions.
9.1.
Security services
The main security services that may be required in any network comprise
the following ones:
• Confidentiality: this service has the goal of keeping information in a
secret way so that only authorized entities share this information. It is
251
2/7/10
13:19
Página 252
Sensors Everywhere
typically achieved by using cryptographic mechanisms, like ciphering,
which ideally should prevent an adversary to obtain even partial information.
• Authentication: the goal of this service is to make sure that a data
source is the one who claims to be. In many contexts this may correspond to verifying the identity of a data source.
• Integrity: this service aims at detecting when an adversary modifies an
in-transit message and hence preventing information from being
changed. To achieve this goal, a Message Authentication Code (MAC) is
used in each message, which constitutes a cryptographically secure
checksum. Because the MAC is “signed” with a secret key that is owned
only by the parties involved in the communication, the MAC provides
authentication at the same time.
• Non-repudiation: this service assures that an entity involved in a communication cannot deny having taken part in that communication (as
the receiver or as the sender).
9.2. Security of IEEE 802.15.4
This section is divided into two subsections. Subsection 9.2.1 presents
security suites of IEEE 802.15.4-2003, while subsection 9.2.2 shows the relevant elements with regard to security introduced by IEEE 802.15.4-2006.
9.2.1. Security suites of IEEE 802.15.4
IEEE 802.15.422 specifies eight security suites, which are summarized in
Table 9.1. Such suites may be classified into four groups, depending on their
characteristics: no security, cipher only, authentication only and cipher plus
authentication. All security suites employ the Advanced Encryption
Standard (AES) [2] as the basis for the related cryptographic operation. The
22
In this chapter, unless explicitly mentioned, the term IEEE 802.15.4 refers to the original
version of the specification (published in 2003).
252
2/7/10
13:19
Página 253
Chapter 9. Security
cipher-only functionality is provided by the AES Counter (AES-CTR) mode.
Authentication/integrity only is obtained by use of the AES Cipher Block
Chaining MAC (AES-CBC-MAC) [3]. Finally, cipher plus authentication/integrity is provided by using the Counter with CBC-MAC (CCM) approach [4],
which in the considered context is referred to as AES-CCM. The specification
only mandates support of the AES-CCM-64 suite and the no security suite.
On the other hand, IEEE 802.15.4 defines two mechanisms for better
support of authentication and communication integrity:
• Access control: this service has the goal of avoiding the participation of
non-authorized nodes in the network. Each device of the network maintains an Access Control List (ACL) which includes authorized devices.
• Replay protection: the goal of this function is to prevent an adversary
from capturing a message transmitted by an authorized device before
it is received by the corresponding authorized node, and replay the
message later. Since such a message would have a valid MAC, sequence numbers are typically assigned to frames in such a way that a
receiver can discard frames received with a smaller sequence number
than those seen at a certain moment.
Security service
Cipher
Frame
Replay
integrity and protection
authentication
Security
Group
Name of the
suite
Access
control
No security
No security
No
No
No
No
Cipher only
AES-CTR
Yes
Yes
No
Yes
Authentication AES-CBC-MAC-128
/integrity Only AES-CBC-MAC-64
AES-CBC-MAC-32
Yes
Yes
Yes
No
No
No
Yes
Yes
Yes
No
No
No
Cipher plus
Authentication
/integrity
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
AES-CCM-128
AES-CCM-64
AES-CCM-32
Table 9.1. IEEE 802.15.4 security suites
253
2/7/10
13:19
Página 254
Sensors Everywhere
More details on the several security suites are shown below:
• No security. This suite constitutes the identity function and does not
provide security services.
• AES-CTR. This suite provides confidentiality using the AES block cipher
algorithm. The sender breaks the clear-text into 16-byte blocks and
computes the ci = pi ⊕ Ek (xi) operation, pi being a clear text block, ci the
corresponding ciphered text and xi the value of a counter used for i-th
block.
• AES-CBC-MAC. This kind of suite provides authentication and integrity by means of the CBC-MAC algorithm. The sender may compute a 4-, 8- or 16-byte MAC. This MAC may be calculated by entities sharing a symmetric key. The sender appends the MAC to the
clear text. The receiver verifies this code by calculating it from the
received frame and comparing it with the value included in that
frame.
• AES-CCM. This kind of security suite uses CCM mode for confidentiality
(cipher), authentication and integrity. Roughly, integrity protection is
first applied using CBC-MAC, and after that data are ciphered together
with the 4-, 8- or 16-byte MAC, using AES-CTR mode.
A relevant fact about IEEE 802.15.4 security is that it does not specify
key management mechanisms. Hence, higher layer functionality must carry
out key management tasks. For instance, ZigBee defines key management
functionality on top of an IEEE 802.15.4 network [5].
9.2.2. Security of IEEE 802.15.4-2006
The IEEE 802.15.4-2006 [6] specification uses AES-CCM*, a minor
modification of the AES-CCM mode used in the original IEEE 802.15.4
specification. AES-CCM* includes all the features of AES-CCM and
includes also the cipher only and integrity only. These extra functionalities simplify the security operations. ZigBee uses IEEE 802.15.4-2006
security at MAC layer.
254
2/7/10
13:19
Página 255
Chapter 9. Security
9.3.
Security services of ZigBee
ZigBee offers various security services that comprise key establishment,
key transport, frame protection and device management [5]. Subsection
9.3.1 presents the architecture of the security services offered by ZigBee.
Subsections 9.3.2 to 9.3.4 present security mechanisms at ZigBee MAC,
NWK and APL layers, respectively. Subsection 9.3.5 offers a functional description of security services in a ZigBee network.
9.3.1. ZigBee security architecture
9.3.1.1. ZigBee security design guidelines
The ZigBee security architecture is based on an open trust model for
each device: the layers and all applications that run in a device can trust
each other. This model allows key material23 to be reused at several layers of
the same device and makes end-to-end security possible between devices.
This approach leads to the following ZigBee security principles:
• The layer that originates a frame is responsible for securing the frame.
• Only source and destination have access to a key shared by them.
• All devices of a network will use the same security level.
9.3.1.2. Security keys
Security between devices of a ZigBee network is based on link keys and
a network key. Unicast communication between two APL entities is secured
by means of a 128-bit link key shared by both devices, while broadcast communications are secured by means of a 128-bit network key shared by all
devices of the network. A receiver always knows which key has been used
to protect a frame.
23
For instance, the active network key is used to secure APS layer broadcast frames or
NWK layer frames. Reuse of keys contributes to reducing storage requirements.
255
2/7/10
13:19
Página 256
Sensors Everywhere
A device may obtain link keys via key transport service, key establishment service or pre-installation. The first two mechanisms are APL layer
mechanisms (see 9.3.4). The link key establishment technique is based on
the use of a master key. A device obtains the master key through the use of
key transport or pre-installation. A device may obtain the network key via
key transport service or pre-installation.
As a precautionary measure, the reuse of a key by different security services is avoided. For this reason, different services use different keys
obtained with a one-way function from the link keys. The network key may
be used by MAC, NWK and APL layers. The link and master keys may be used
solely by the APL layer. Subsection 9.3.5 provides more details about key
management in a ZigBee network.
A device may store two network keys: the active key (the one which is
being used at a given moment) and the alternative key, which may become
the active key in certain situations.
9.3.1.3. Security architecture
The ZigBee architecture includes security mechanisms in three layers of
the ZigBee protocol stack: MAC, NWK and the APS sublayer, all of which are
responsible for the secure transport of their respective frames. In addition,
the APS sublayer provides services for establishment and maintenance of
secure end-to-end communications. The ZigBee Device Object (ZDO)24
manages the security policies and configuration in a device.
9.3.1.4. Security levels
MAC, NWK and APS each comply with eight security levels. These security levels are equivalent to those shown in Table 9.1, that is, no security, cipher only, authentication/integrity only (with 32-, 64- and 128-bit MAC25
options) and cipher plus authentication/integrity (with 32-, 64- and 128-bit
MAC options).
24
See Chapter 11
25
Here, MAC stands for Message Authentication Code.
256
2/7/10
13:19
Página 257
Chapter 9. Security
9.3.2. MAC layer security
When a MAC frame requiring security is generated, ZigBee uses the MAC
layer security specified in IEEE 802.15.4-2006, complemented with additional mechanisms26. The use of CCM* in ZigBee allows the reuse of the
same key material by MAC, NWK and APS layers. The MAC frame is responsible for its own security, but upper layers specify which security level must
be used by the MAC layer.
Fig. 9.1 shows the fields involved in the use of MAC layer security in a
ZigBee frame.
Fig. 9.1. Payload of the ZigBee frame (MAC payload), when MAC layer
Authentication Code. The size of each field is expressed in bytes
9.3.3. NWK layer security
When a frame generated at the NWK layer requires security, or when a
frame is generated by an upper layer and requires NWK security, ZigBee
uses the AES and CCM* algorithms. Upper layers determine the key and the
security level to be used.
Fig. 9.2 shows the fields involved in the use of security at NWK layer in
a ZigBee frame. The NWK header may have a size of 8, 16 or 17 bytes,
which correspond to the following situations: i) absence of source and
destination IEEE addresses; ii) presence of such addresses, and iii) use of
multicast. When NWK layer security is used, a 14-byte auxiliary header is
employed.
26
See clause 4.3 of ZigBee specification [5]
257
2/7/10
13:19
Página 258
Sensors Everywhere
Fig. 9.2. Payload of the ZigBee frame (MAC payload), when NWK layer
9.3.4. APL security
When a frame generated by the APL layer requires security, the APS
sublayer manages the security mechanisms needed. The APS sublayer
provides frame security based on link keys or network keys. This sublayer
is also responsible for offering functionality such as key establishment,
key transport and device management services to the ZDO and applications. In order to do this, the APS sublayer uses special data units called
commands.
Fig. 9.3 shows the fields involved in the use of an APS sublayer security in a ZigBee frame. The APS header may be composed of 8 or 9 bytes,
depending on whether the destination corresponds to a single
destination endpoint or a group address (that is, an address that identifies
the members of a group). When an APS sublayer security is used, a
5- or 6-byte auxiliary header is employed. This size depends on the use
of an optional parameter.
Fig. 9.3. Payload of a ZigBee frame (MAC layer payload), when APS
258
2/7/10
13:19
Página 259
Chapter 9. Security
9.3.4.1. Key establishment
The APS sublayer provides the mechanism by which a ZigBee device can
establish the link key, which is a shared secret key, with another ZigBee device. The Symmetric-Key-Key Establishment (SKKE) protocol is used for that
purpose and requires the use of a master key. Recall that link keys may also
be pre-installed.
9.3.4.2. Key transport
The key transport service provides both secure and insecure mechanisms to transport a key from one device to one or more different devices.
• The secure key transport mechanism is used to transport a master key,
a link key or a network key from a key source to other devices.
• The insecure key transport mechanism is based on the use of out-ofband channels (which are beyond the scope of the ZigBee specification) that guarantee secrecy and authentication. In this case, security is
provided by non cryptographic methods.
9.3.4.3. Device update
The device update service provides a secure method to inform the trust
center (which is an entity that all ZigBee devices trust, see 9.3.5.1) that a
third device has changed its status (e.g. it has joined/left the network or
does not fulfil the security requirements of the trust center). This is the
mechanism by which the trust center maintains an accurate list of the number of active devices.
9.3.4.4. Key recovery and key update
The key recovery service provides the devices with a secure way of soliciting the current network key or an end-to-end master key to another
device (e.g. the trust center). On the other hand, the key update service
offers the devices a secure way to inform another device that it should
switch to using a different network key.
259
2/7/10
13:19
Página 260
Sensors Everywhere
9.3.5. Functional description
This subsection offers a functional description of the security services in a ZigBee network. First, the security tasks of three network
entities are presented. These elements are the ZigBee coordinator, the
trust center and routers. Secondly, the following procedures are described: secure network join, authentication, network key update, network key recovery, end-to-end key establishment and leaving a network.
9.3.5.1. Security tasks of ZigBee coordinator, trust center and
router
First, the ZigBee coordinator configures the network security level. It also
configures the trust center address, which is by default the ZigBee coordinator itself or a device designated by the ZigBee coordinator.
The trust center is a device that all ZigBee network devices trust and is in
charge of network key management as well as end-to-end communications management. The trust center can help to establish end-to-end application keys by sending link keys or master keys. The keys must be randomly
generated. It may operate in two modes, the commercial mode and the residential mode:
• The commercial mode has been developed for high security commercial applications. In this mode, the trust centre maintains a list of devices, master keys, link keys and network keys that are needed for network admission control and key update policies.
• The residential mode is targeted to low security residential applications. In this mode, the trust centre maintains the network key and controls the network admission control, but the device list and key maintenance are relaxed.
Finally, in the ZigBee security context, a router is a ZigBee device that, in
addition to carrying out routing tasks, accepts network join requests sent by
other devices.
260
2/7/10
13:19
Página 261
Chapter 9. Security
9.3.5.2. Secure network join
Fig. 9.4 shows the messages involved in the procedure by which a device
communicates with a router to join a secure ZigBee network.
Fig. 9.4. Message exchange between a router and a new device that aims
at joining a secure ZigBee network
The device that aims at joining the network may start the join procedure
by transmitting a non-secure beacon request. This same device receives
beacons from the surrounding neighbours, which include information about
the security level of the network. In accordance with these parameters, the
device decides which WSN intends to join by sending an association request
command to the corresponding router. If the device already has a network
key for a specific WSN, the association request includes parameters that
allow the router to discover this fact. At this point, the router knows the device address and the network key used to generate the association request.
The router then transmits an association response command. When this
command is received, the device is declared as joined, but not authenticated.
Subsequently, the authentication phase follows (see 9.3.5.3) except for
261
2/7/10
13:19
Página 262
Sensors Everywhere
when the device is not a router. In this situation, the device is immediately
declared as joined and authenticated.
9.3.5.3. Authentication
If the router that securely joins the new device) is not the trust centre it
initiates the authentication procedure by transmitting the update device
command (see 9.3.4.3) to the trust center.
In the residential mode, the trust center sends the network key to the
joined device. This is done by means of the insecure key transport mechanism from the router to the device (see Section 9.3.4.2).
Fig. 9.5. Message chart for the authentication of a new device in a secure
ZigBee network, in residential mode
In commercial mode, if the trust center does not share a master key with
the joined device, it sends a master key to the device through the router. The
transmission of this key from the router to the device is done by means of
an insecure key transport mechanism (see 9.3.4.2). The trust center then
starts the establishment of a link key between the trust center and the device using the SKKE protocol. Once the link key has been established, the
262
2/7/10
13:19
Página 263
Chapter 9. Security
trust center sends the network key to the new device by means of the secure key transport mechanism. Fig. 9.6 illustrates the sequence of messages
described.
Fig. 9.6. Message exchange for the authentication of a new device in a
secure ZigBee network, in commercial mode
9.3.5.4. Network key update
In residential mode, the trust center may update the network key for all
the devices of the network. To do so, the trust center sends the network key
through a transport-key command in broadcast mode.
In commercial mode, the trust center maintains a list of all the devices of
the network. To update the network key, the trust center transmits the new
network key to each device of the list and then requests that each device
uses this new key through the switch-key command. Fig. 9.7 presents an
example showing the related message exchange.
263
2/7/10
13:19
Página 264
Sensors Everywhere
Fig. 9.7. Message exchange for the network key update in a secure
ZigBee network (commercial mode)
9.3.5.5. Network key recovery
A device may request the network key from the trust center by sending
the request-key command.
In residential mode, after reception of this command, the trust center
assumes that the device belongs to the network.
In commercial mode, the trust center checks that the device is on the
list of network devices. In this case, the trust center transmits the network key by using the transport-key command, and indicates that the
device should use this key by means of the switch-key command, as
shown in Fig. 9.8.
264
2/7/10
13:19
Página 265
Chapter 9. Security
Fig. 9.8. Messages of the network key recovery procedure in a secure
ZigBee network (commercial mode)
9.3.5.6. End-to-end key establishment
The device that intends to establish a link key with another device
sends a request-key to the trust center indicating that it requests a link
key and the remote device with which this link key should be shared.
Depending on the configuration of the trust center, it can provide link
keys or master keys by offering the corresponding key to the two devices
for which an end-to-end key is going to be established. If the trust center
provides a master key, the initiator starts the key establishment procedure by transmitting the SKKE-1 command of the SKKE protocol. If the
remote device accepts this command, the protocol is run with the transmission of SKKE-2, SKKE-3 and SKKE-4 commands. Fig. 9.9 illustrates the
sequence of messages described.
265
2/7/10
13:19
Página 266
Sensors Everywhere
Fig. 9.9. Sequence of messages for the network key establishment in a
secure ZigBee network
9.3.5.7. Secure network leave
A device may leave a network by its own decision or by decision of the
trust center:
• In the former case, the device communicates its decision to its router
by transmitting the disassociation notification command. The router will
then transmit an update-device command to the trust centre, which
will erase the device from its list of devices in the network. Fig. 9.10
shows the described message exchanges.
• In the latter case, the trust center transmits a remove-device to the
router, which in turn transmits a disassociation notification to the device so that it abandons the network. Fig. 9.11 shows the described
message exchanges.
266
2/7/10
13:19
Página 267
Chapter 9. Security
network, initiated by the device itself
network, initiated by the trust center
9.4.
Security services of other solutions
Although ZigBee defines a complete security architecture that adds the
security functionality that is not defined in IEEE 802.15.4, the same has yet
to be developed for 6LoWPAN. Nevertheless, the need for it has already
been identified [7]. With regard to BT-LE, the link layer provides encryption
and authentication by using AES-128 and CCM [8].
267
2/7/10
13:19
Página 268
Sensors Everywhere
Security
service
ZigBee
6LoWPAN
BT-LE
Fully specified
(including key
management, which
IEEE 802.15.4 lacks)
Security analysis
currently under
development. So
far, 6LoWPAN
relies on IEEE
802.15.4 security
Encryption and
authentication.
Table 9.2. Summary of security service provided by ZigBee, 6LoWPAN
and BT-LE
Other solutions, such as Z-Wave, INSTEON or Wavenis offer encryption
services. In particular, the 200 and 300 series Z-Wave chips do not offer
security mechanisms, but the 400 series Z-Wave chip supports 128-bit key
AES encryption. INSTEON supports various encryption techniques, but
recommends the use of simple rolling codes, as used in garage door openers. Wavenis supports encryption algorithms such as Triple Data Encryption
Standard (3DES) and 128-bit key AES.
REFERENCES
[1] IEEE 802.15.4, “Wireless Medium Access Control (MAC) and Physical
Networks (LR-WPANs)”, May 2003.
[2] V. Rijmen, J. Daemen, “The Block Cipher Rijndael”, Smart Card Research
and Applications, LNCS 1820, pp. 288-296, Springer-Verlag, 2000.
[3] M. Bellare, J. Kilian, P. Rogaway, “The Security of the Cipher Block
Chaining Message Authentication Code”, Journal of Computer and
System Sciences, 61(3) pp. 362-399, December 2000.
[4] D. Whiting, R. Housley, N. Ferguson. “Counter with cbc-mac (ccm)”, RFC
3610, September 2003.
[5]
268
“ZigBee Specification”, r17 version, January 2008.
2/7/10
13:19
Página 269
Chapter 9. Security
[6] IEEE Computer Society, "IEEE Std. 802.15.4-2006", September 2006.
6LoWPAN and LLN Application Protocols”, Internet Draft, (Work in progress) July 2009 .
[8] “Specification of the Bluetooth System”, Covered core package version:
4.0, December 2009
269
2/7/10
13:19
Página 270
6/9/10
10:15
Página 271
10
Operating systems
6/9/10
10:15
Página 272
6/9/10
10:15
Página 273
Chapter 10. Operating systems
10. Operating systems
As it has been mentioned in Chapter 5, a sensor node includes a processor that executes tasks which require access to hardware elements such as
memory, input/output and communications. The operating system (OS) is
another task that allows coordinating the use of resources and offers an
interface with the hardware to make it independent from the applications
that the sensor node executes.
10.1.
Basic features
The basic functions the OS is responsible for are the following: processor
management, device management, execution time scheduling and concurrency management. In addition, the capability of code download, as well as
offering an interface for application access to hardware elements are desirable features for an OS. In particular, an OS for sensor nodes should also
account with energy management functionality in order to minimize energy
consumption.
An OS is a program of vital importance in any processor because it makes
easy to develop applications, but it must not degrade the features that the processor should offer. In environments where there are plenty of resources, this
requirement is not important. However, as sensor nodes are limited devices in
memory and processing capabilities, this requirement is fundamental [1].
Because WSNs are a distributed scenario, the OS may offer additional capabilities related to distributed application execution. This aspect is generally sol-
273
6/9/10
10:15
Página 274
Sensors Everywhere
ved with the usage of a concept known as ‘middleware’, which is software that
may be placed in the elements of the network. Some middleware are a task
executed by the nodes and some OSs include this functionality.
There exists a large range of OSs for sensor nodes. Some of them are
adaptations of existing solutions for limited platforms, while others have
been developed for sensor nodes. OSs can be classified in terms of basic
features such as the architecture, the reprogramming facilities, the execution model and the scheduling.
The architecture of an OS refers to the organization of the OS and the applications that are executed. There exists a type of architecture called monolithic
architecture, whereby the OS and the applications are integrated in the same
program. Other types of OS architectures are the modular architecture and the
virtual machine-based architecture. In the latter, the OS includes application
components which allow making compact applications and hiding the network.
The execution model of an operating system indicates in which way the
applications are executed. The most common execution model is based on
events, but there exists another model that is based on threads. In the former, applications generate events which are dealt with sequentially. There
exist other options, such as an execution model based on a state machine.
Reprogramming refers to the possibility of modifying the software which
is executed in the OS. This feature has special interest in WSNs as access to
the nodes may be limited in some environments.
With regard to scheduling, the processor is shared by the different tasks.
The most common scheduling approaches in WSNs are periodical/nonperiodical one and critical/non-critical one. For instance, a temperature
measurement corresponds to a periodical event, while the generation of an
alarm is non-periodical.
10.2.
Existing operating systems for wireless sensor nodes
There exists a great amount of OSs in the literature [2]. The most accepted ones are TinyOS and Contiki, all of them being open-source OSs.
274
6/9/10
10:15
Página 275
10.2.1. TinyOS
TinyOS [3] is a popular free source code multi-platform OS for constrained
devices, which is used in several hardware platforms from Crossbow (e.g. MICA,
TelosB, Cricket or Shimmer). TinyOS was created by researchers from the
University of Berkeley in the frame of the SmartDust project. It has no kernel to
interface with the hardware. It is based in three functional abstractions, which
are, in a decreasing order of priority: events, commands and tasks. TinyOS supports only five priority levels, which is a reduced value in comparison with those
supported by other OSs. It restricts the maximum number of tasks to 255. Only
one simultaneously active task is allowed and it can only be preempted by
events or commands. TinyOS is written in nesC, a dialect of the C language and
the behaviour of an application can be simulated using TOSSIM and
PowerTOSSIM. TinyOS has embedded communication facilities such as the
concept of active message. The message has a handler address that is used on
the arrival of the message to call the handler. In addition, TinyOS has functionalities to support multi-hop communication, instead of single-hop communication, which is the default one in most OSs. TinyOS has a small footprint of 178
bytes of memory. As of the writing, the last version of TinyOS is 2.1.0.
10.2.2. FreeRTOS
FreeRTOS [4] is a free real-time multiplatform OS. It supports tasks and
co-routines. Communication and synchronization among tasks or between
tasks and interruptions is performed by queues and semaphores.
Development tools are available for several processor platforms, including
Cortex-M3, ARM7, MSP430, H8/S, AMD, AVR, x86 and 8051. It neither poses
constraints on the maximum number of tasks which can be created nor
limits the number of priority levels which can be used. The same priority
level can be assigned to different tasks.
10.2.3. RETOS
RETOS [5] is a free source code multiplatform OS developed by the
Mobile Embedded System research group of Yonsei University. It supports
275
6/9/10
10:15
Página 276
Sensors Everywhere
threads which communicate between them using mutex and monitor functionality. As FreeRTOS, it does not restrict the number of tasks which can be
created. It allows up to ten priority levels. The same priority level can be
assigned to different tasks.
10.2.3. uC/OS II
uC/OS II [6] is a multiplatform OS developed by Micrium. This is a preemptive real time multitasking OS intended for embedded systems. This OS
can manage up to 255 tasks and specifies up to 64 priority levels, where 56
of them can be used by applications. The same priority can be specified to
different tasks. Synchronization and communication among tasks or between tasks and interruptions is based on queues, mailboxes and semaphores.
It is not freely available and requires licensing from Micrium Inc, but it is free
for educational purposes. It has ports for most of the popular processors and
boards available in the market.
10.2.4. AMBIENT RT
AMBIENT RT [7] is an OS developed by Ambient Systems which allows
managing up to 72 tasks (each one of them requires ten additional bytes of
RAM). It does not limit the number of priorities to be used and it allows assigning the same priority to different tasks. Synchronization and communication among tasks or between tasks and interruptions is based on a data
centric architecture and automatic mutual exclusion techniques, thus avoiding the use of semaphores or monitors. A limited version of this OS is available for free. One of the main disadvantages of this operating system is its
complexity.
10.2.5. Nano-Qplus
Nano-Qplus [8] is a sensor network multithreaded operating system
developed by Korea’s Electronics and Telecommunications Research
Institute (ETRI). The architecture of Nano-Qplus follows a layered modular
design which consists of dynamically-loaded modules in the following three
276
6/9/10
10:15
Página 277
parts: Hardware, Nano OS and Application. Nano-Qplus assumes an ATMEL
Atmega128 MCU and a CC2420 RF module. The Nano OS part has a role as
kernel scheduler and network protocol stack. Nano-Qplus uses the notion
of task and provides a variety of schedulers including FIFO scheduler, preemptive Round Robin scheduler, etc.
10.2.6. MantisOS
MantisOS is an open source, light –weighted and energy– efficient, multithreaded OS [9]. The name of the OS comes from MultimodAl NeTworks of
In-situ micro Sensor (MANTIS). The OS is preemptive and multi-threading
with a power efficient scheduler that sleeps the microcontroller. It has a network protocol stack and supports remote management with dynamic reprogramming and remote login. The OS is written in C language and presents a
small footprint requiring less than 500 bytes.
10.2.7. SOS
The Sensor Operating System (SOS) [10] is optimized towards reconfigurability. It can add, modify, and delete software modules at runtime. This
allows incrementally updating a node once it is deployed and remove unused modules. It uses a kernel to access system resources such as timers,
memory, sensors and actuators. It provides a mechanism for communication between modules based on the usage of messages. The OS is written in
C language. As of the writing, the development of SOS has been discontinued.
10.2.8. Contiki
Contiki [11] is an open-source, highly portable, multi-tasking operating
system for constrained embedded systems. Contiki offers most of the standard features of an OS such as threads, timers, random number generations,
file system and command line shell. Contiki consists of an event-driven kernel. Programs are dynamically loaded and unloaded on top of this kernel.
Contiki processes use lightweight protothreads, which offer a linear, thread-
277
6/9/10
10:15
Página 278
Sensors Everywhere
like programming on top of the event-driven kernel. Contiki also supports
per-process optional preemptive multithreading and inter-process communication using message passing through events. Contiki uses C as a programming language and the behaviour can be simulated using COOJA
(Contiki OS Java Simulator). Contiki incorporated an IP stack (the uIP stack,
developed to be used in resource constrained platforms). Contiki runs on a
variety of platforms including TelosB, with AVR MCU and MSP430 MCU
among others.
10.2.9. Microsoft .NET Micro
The Microsoft .NET Micro [12] is a solution from Microsoft for embedded
platforms which are too resource-constrained to run other solutions from
the same company. It offers the advantages of .NET programming for this
type of platforms. It has a small footprint (about 300 kB) considering the
type of solution. It supports full Visual Studio Integration, with live debugging of code running in the objective device. This OS requires a significant
amount of resources, such as for example ARM7 or ARM9 CPUs, but it does
not offer real time support. The IMote 2.0 node uses this OS.
REFERENCES
[1] Adi Mallikarjuna V. Reddy, A.V.U. Phani Kumar, D. Janakiram, G. Ashok
Kumar, “Wireless sensor network operating systems: a survey”,
International Journal of Sensor Networks, Vol. 5, No. 4, pp. 236-255,
2009
[2] A.K. Dwivedi, M.K. Tiwari, O.P. Vyas, “Operating systems for tiny networked sensors: a survey”, Internatonal Journal of Recent Trends in
Engineering, Vol. 1, No. 2, May 2009.
[3]
TinyOS website, http://www.tinyos.net
[4]
FreeRTOS website, http://www.freertos.org,
[5]
RETOS website, http://www.retos.yonsei.ac.kr/index.html
278
6/9/10
10:15
Página 279
[6] uC/OS II website.
http://www.micrium.com/products/rtos/kernel/rtos.html
[7]
AMBIENT RT website.
http://smart-surroundings.com/ambient/technology-rtos.htm
[8] S. Park et al. “A Nano Operating System for Wireless Sensor Networks”,
ICACT 2006, February 2006.
[9] S. Battti et al. “MANTIS OS: An Embedded Multithreaded Operating
System for Wireless Micro Sensor Platforms”, Mobile Networks and
Applications, Springer, Vol. 10, No. 4, pp. 536-579, August 2005
[10] SOS website.
https://projects.nesl.ucla.edu/public/sos-2x/doc/index.html
[11] Contiki web site. http://www.sics.se/contiki/
[12] Microsoft .NET Micro web site.
http://www.microsoft.com/netmf/default.mspx
279
6/9/10
10:15
Página 280
6/9/10
10:15
Página 281
11
Wireless sensor network
architectures and
techologies
6/9/10
10:15
Página 282
6/9/10
10:15
Página 283
Chapter 11. Wireless sensor network architectures and technologies
11. Wireless sensor network
architectures and technologies
In the last decade, WSNs have received significant attention mainly from
academia, but also from private companies, industry alliances and standardization organizations. Some WSN solutions have been developed for specific
applications, while others have been designed for general purpose. These
design goals have strong implications for the performance and characteristics of each solution.
This chapter presents a non-exhaustive set of architectures and technologies for WSNs, including some of the main current ones as well as those
that are emerging. Section 11.1 presents general purpose WSN solutions.
Section 11.2 overviews solutions for the home automation, building automation and Automatic Meter Reading (AMR) / Advanced Metering
Infrastructure (AMI) domains. Section 11.3 gives an overview of the main
solutions for Industrial Automation. Finally, Section 11.4 is devoted to other
solutions.
11.1.
General purpose solutions
This section presents the three main WSN architectures and technologies that have been developed for a broad range of applications.
Subsections 11.1.1, 11.1.2 and 11.1.3 overview ZigBee, 6LoWPAN and
Bluetooth Low Energy, respectively.
283
6/9/10
10:16
Página 284
Sensors Everywhere
11.1.1. ZigBee
ZigBee [1] is a standard that defines a protocol architecture on top of IEEE
802.15.4, which is used for physical and MAC layers. ZigBee defines network,
security and application functionality. The goal of this technology, which is
promoted by the ZigBee Alliance, is to enable wireless, reliable and lowpower products for control and monitoring [2] in all the scenarios for which
IEEE 802.15.4 is suitable, such as industrial, structural, medical, home automation, intelligent vehicular systems, agriculture, environment, etc. At the
time of writing, ZigBee is based on the IEEE 802.15.4-2003.
The protocol architecture of ZigBee follows a layered approach, as
shown in Fig. 11.1. The ZigBee protocol stack is composed of four main
layers, namely: the physical (PHY) layer, the Medium Access Control
(MAC) layer, the Network (NWK) layer and the Application (APL) layer. In
addition, ZigBee provides security functionality across layers. The two
lower layers of the ZigBee protocol stack are defined by the IEEE
802.15.4 standard, while the rest of the ZigBee protocol stack is defined
by the ZigBee specification.
Fig. 11.1. ZigBee protocol stack (adapted from [1])
284
6/9/10
10:16
Página 285
ZigBee defines three device roles: i) the ZigBee coordinator, which
corresponds to an IEEE 802.15.4 PAN coordinator, ii) the ZigBee router, and
iii) the ZigBee end device. The latter is normally a simple device with very
low capabilities and is the only one which corresponds to an RFD.
11.1.1.1. ZigBee NWK layer
The NWK layer provides management and data services. The management tasks comprise network formation (which includes the configuration
of a new device, starting, joining and leaving a network) and routing.
The ZigBee NWK layer specifically supports addressing and routing
for the tree and mesh topologies. The tree topology is rooted at the
ZigBee coordinator. This scheme includes a mechanism for address
assignment, which also facilitates multi-hop data delivery. In a mesh
topology, routes are created on demand and are maintained by using a
set of mechanisms based on the Ad-hoc On-demand Distance Vector
(AODV) routing protocol [3]. With this approach, once a path is found,
the relaying nodes store the next hop information in their routing
tables. Source routing is another option offered by the ZigBee NWK
layer. This option relaxes memory requirements of intermediate nodes,
since in this case the source includes the path to be followed by a packet while the devices route the packet according to that path. The
ZigBee PRO solution (see section 11.1.1.4) also offers many-to-one
routing for communication between several devices and a central controller or sink node. This node may reply to the devices by means of
source routing. Only ZigBee coordinators and routers participate in
routing operations.
The ZigBee NWK layer allows unicast, multicast and broadcast communications. NWK layer addresses have a size equal to 16 bits and are assigned
by the ZigBee coordinator, on the basis of the IEEE 802.15.4 address of each
device. The NWK layer header includes a one-byte field called radius that
limits the number of hops for the packet. The recommended maximum
value for this parameter is 30 for mesh routing, 10 for tree routing and 5 for
source routing.
285
6/9/10
10:16
Página 286
Sensors Everywhere
11.1.1.2. ZigBee APL layer
The APL layer is composed of three sections: the application support (APS)
sublayer, the ZigBee Device Objects (ZDOs) and the application framework.
The applications themselves are called application objects and are developed
by manufacturers for customizing a device for specific applications.
The APS sublayer offers management services and also provides data
services to application objects. The management services include the binding of two end devices. The data services include the support of reliable data
transport by means of end-to-end ACKs and control of duplicate data units.
The APS sublayer supports unicast, multicast and broadcast, and in addition,
offers indirect addressing, which allows a device with limited resources to
communicate with a destination without knowing its address. In this case,
data is transmitted to the ZigBee coordinator, which retransmits the message to the destination.
The ZDOs are entities that contain common functionality for all applications operating on a ZigBee device, such as configuring the device in one of
the ZigBee device types. The ZDO provides mechanisms to discover other
nodes and services in the network and is responsible for the current state
of a node in the network.
The ZigBee application framework is the environment that hosts application objects. A single device can accommodate up to 240 application
objects. An application object is addressed through its corresponding endpoint. The endpoints range from 0 to 240 (the endpoint 0 identifies the
ZDO). The 255 is for broadcast and the rest are reserved for future use. The
development of a ZigBee application can make use of application profiles,
which are sets of agreements on message formats and processing actions.
An application profile includes clusters and device descriptions. Clusters are
sets of attributes and commands. The device descriptions include settings
such as the frequency band to be used, buffer and message size, APS capabilities, etc. The cluster space and the device type space have a size of
65536 clusters and devices, respectively.
Finally, the ZigBee Cluster Library (ZCL) is a set of common functions on
which to build ZigBee applications and profiles can be built.
286
6/9/10
10:16
Página 287
11.1.1.3. Application profiles
There are three types of ZigBee application profiles: public (standard), private and published. Public profiles are managed by the ZigBee Alliance.
Private profiles are defined by ZigBee vendors for restricted use. A private
profile can become a published profile if the owner decides to publish it. The
ZigBee Device Profile is a collection of device descriptions and clusters27 that
correspond to the Application Profile of the ZDO.
The ZigBee Alliance published the ZigBee Home Automation Public
Application Profile [4]. This document defines device descriptions, the
appropriate use of clusters specified in the ZCL, and other standard practices
for ZigBee applications in a residential or light commercial environment. The
main application areas considered are lighting, HVAC, window shades and
security. Some recommendations for the use of ZigBee in home scenarios
include: the use of channel masks to avoid the most commonly used WiFi
channels; the use of large routing tables to account for the high density
expected in a residential scenario and the discouragement of broadcast
transmissions, except when invoking scenes. A scene is a situation for which
a set of devices are configured in a particular way (e.g. lights and HVAC are
turned down and window shades are closed when the user goes out).
The ZigBee Smart Energy public Profile [5] focuses on energy demand response and load management applications. With regard to the home area, this
profile focuses on communication between home devices and the Energy
Service Portal (ESP), which connects a ZigBee Smart Energy Wireless Home
Area Network (WHAN) with the communication network of an energy supply
company. A ZigBee Smart Energy WHAN has higher security requirements
than a regular ZigBee WHAN. Hence, nodes of the latter cannot interoperate
with those of the former unless they support the Smart Energy profile.
Finally, the ZigBee Radio Frequency For Consumer Electronics (RF4CE)28
specification offers a simple device-to-device remote control solution for
27
28
A cluster is a set of commands and attributes. They are defined as application objects.
In March 2009, the RF4CE Consortium agreed to work with the ZigBee Alliance to jointly
deliver a specification for radio frequency-based remote controls [41].
287
6/9/10
10:16
Página 288
Sensors Everywhere
consumer electronics, which will not use full-featured mesh networking
capabilities.
Other ZigBee application profiles that are being developed as of the writing of this book are the following:
• Building Automation
• Healthcare
• Telecommunications Services
• Retail Services
11.1.1.4. ZigBee versions
Some commercial products exist which fulfill all the requirements of the
ZigBee certification. There also exist ZigBee-compliant development platforms.
To date, ZigBee Alliance has defined several versions of the ZigBee standard: the ZigBee 2004 (nowadays considered deprecated), ZigBee 2006,
and ZigBee 2007. The latest version of the standard has two feature sets
identified as ZigBee and ZigBee PRO. These feature sets are identified as
stack profiles29 and are motivated to cope with different requirements in
terms of hardware platforms and functionalities. The stack profile labelled
0x01 corresponds to the basic one while 0x02 defines the one associated
with ZigBee PRO. The basic stack profile (0x01) is recommended for small
networks (e.g. less than 10 hops between a source and its destination).
While ZigBee PRO does not include tree routing30, it does have source routing. This stack is recommended for larger networks (up to 30 hops between
a source and its destination) and supports multicast and source routing.
ZigBee PRO also uses a new address assignment algorithm called stochas29
According to the ZigBee specifications, a stack profile is an agreement by convention
outside the scope of the ZigBee specification on a set of additional restrictions with respect to features declared optional by the specification itself.
30
Tree routing comes together with hierarchical address assignment. This routing protocol
is very simple but oriented to a source (sensor node)-to-sink (gateway) communication.
288
6/9/10
10:16
Página 289
tic assignment, which means that a ZigBee device randomly picks up an
address when joining the network. ZigBee requires a significant number of
resources, compared to other stacks, and ZigBee PRO in particular is the
most demanding.
Some application profiles such as Smart Energy require fragmentation31,
and only ZigBee2007 and ZigBee PRO support these features. Table 11.1
shows the main differences between ZigBee stacks.
Feature
Size in ROM/RAM
Stack Profile
Maximum hops
Maximum nodes in network
Mesh networking
Broadcasting
Tree routing
Frequency agility32
Bandwidth used by protocol
Fragmentation
Multicasting
Source routing
Symmetric links
Standard Security (AES 128 bits)
High security
ZigBee 2006 ZigBee 2007 ZigBee PRO
Smallest
0x01
10
31.101
√
√
√
–
Least
–
–
–
–
√
–
Small
0x01
10
31.101
√
√
√
√
More
√
–
–
–
√
–
Bigger
0x02
30
65.540
√
√
–
√
Most
√
√
√
√
√
√
Table 11.1. Comparison of ZigBee stacks [6]
ZigBee stack is patent free, in the sense that the technologies used, such
as the AES encryption algorithm or the routing algorithm, are freely avail31
Fragmentation means the partitioning of large packets into smaller packets for transmission. The destination node will reassemble the packets.
32
Frequency agility is a feature whereby a device can select a frequency channel among a
set of several available frequency channels.
289
6/9/10
10:16
Página 290
Sensors Everywhere
able. All participants in the ZigBee Alliance should ensure that no patent
protected technology is used in the specification.
By mid-2009, ZigBee had announced the incorporation of IETF standards
into its specification portfolio, including the specifications developed by the
6LoWPAN and ROLL WGs [44].
11.1.2. 6LoWPAN
Despite the initial scepticism of many researchers regarding the suitability of the Internet architecture for sensor networks, today good performance implementations of IPv6 stacks exist for these environments [7]. In
fact, IPv6 has solutions ready for network auto-configuration and statelessness as well as satisfying the large address space needed for such networks.
Other expected benefits from the use of IP in the aforementioned scenarios
are [8]:
• IP technology is freely available and has open specifications, which has
let to it being better known and understood by a larger audience than
that of proprietary solutions.
• IP-based devices can easily be connected to other IP-based networks
(such as the Internet) without the use of intermediate elements
(e.g. proxies).
At the same time, the IETF has been carrying out standardization of
the mechanisms for extending the Internet for WSNs. Furthermore, the
use of IP for these devices is being promoted by the recently founded
IP for Smart Objects (IPSO) Alliance. While the work done by the IETF
is currently in progress, IP-based sensor networks are emerging which
could dramatically increase the capillarity of the Internet. Fully standardized IP-based solutions for WHANs will be available in the near
future.
The IETF IPv6 over Low power WPAN (6LoWPAN) Working Group
(WG) has defined an adaptation layer that specifies the frame format
and several mechanisms needed for the transmission of IPv6 packets
on top of IEEE 802.15.4 networks. These networks are referred to as
290
6/9/10
10:16
Página 291
LoWPANs. The mechanisms offered by 6LoWPAN are: i) fragmentation,
since IPv6 mandates support for 1280-byte packets and the maximum
IEEE 802.15.4 frame size is 127 bytes; ii) header compression, which
can compress a common 40-byte IPv6 header to a 2-byte header;
iii) IPv6 address auto-configuration and iv) IPv6 Neighbour Discovery
for LoWPANs. There also exist open and publicly available 6LoWPAN
implementations [9, 10].
Moreover, different types of 6LoWPAN devices exist. An Edge Router
interconnects a LoWPAN with another network. A Mesh Node and a
Router perform routing tasks in the “mesh under” and “route over”
configurations, respectively. A Host is a device that only sources or sinks
IPv6 packets.
If a LoWPAN follows the mesh topology, a routing protocol is needed. Two schemes are envisaged for routing in LoWPANs, namely: mesh
under and route over. In mesh under (see Fig. 11.2.a)), routing is performed below IP using IEEE 802.15.4 addresses. In this configuration, the
whole LoWPAN appears as a single IP link. In route over (see Fig.
11.2.b)), every radio hop is equivalent to an IP hop and routing occurs
at the IP layer.
As of the writing of this book, the IETF Routing Over Low power and
Lossy networks (ROLL) WG is developing the IPv6 Routing Protocol for
Low power and lossy networks (RPL), which is a likely candidate protocol
for the route over configuration. RPL maintains Directed Acyclic Graphs
(DAGs), which may be rooted at sink nodes and naturally support multipoint-to-sink and sink-to-multipoint communications. Point-to-point
communications are also supported, but routes between arbitrary nodes
may not be optimal, since they are constrained to the DAG structures
(see Chapter 7).
291
6/9/10
10:16
Página 292
Sensors Everywhere
Fig. 11.2. 6LoWPAN architecture: a) mesh under, b) route over
Application layer functionality, such as commands and attributes, does
not currently exist for 6LoWPAN (nor for other types of IP networks with
similar characteristics). Moreover, traditional application layer Internet protocols (e.g. HTTP and SNMP) and data encoding formats are not naturally
suited to this kind of networks, given the constraints of the devices and the
50-to-60-byte transport layer payloads available in LoWPANs. The new IETF
Constrained RESTful Environments (CoRE) WG will develop new or adapted
application-layer protocols and data encoding formats [11]. Other areas
within the IETF where work should be done are transport and security. It is
likely that future working groups will develop protocols and solutions for
these areas.
A major deployment of 6LoWPAN and the future CoRE protocols will be
the Smart Energy Version 2 (SE 2) effort. SE 2 aims at providing end-to-end
connectivity between energy providers and consumers, and it has been
recognized as part of the Smart Grid roadmap of the US NIST [12].
11.1.3. Bluetooth Low Energy
When the IEEE began the discussion on the technology to be used
as low bit rate WPAN, several proposals were presented. One of them
292
6/9/10
10:16
Página 293
intended to offer the same radio as Bluetooth but required less power
offering lower bit rate. This proposal was not accepted, and latterly was
pushed in the Wibree Forum as a solution for short distance communication under the name of “Wibree”. The Wibree Forum merged with
Bluetooth SIG by mid 2007 and since that date, a low energy Bluetooth
wireless feature has been developed as part of the Bluetooth specification with the name BT-LE. A key milestone in the specification process
was reached in December 2009, with the announcement of the adoption of this technology feature as part of the Bluetooth Core
Specification Version 4.0 [36, 37].
The current version of Bluetooth Core Specification contains two forms
of Bluetooth wireless technology systems: Basic Rate (BR) and Low Energy
(LE). Both systems include device discovery, connection establishment and
connection mechanisms. The Basic Rate system includes optional
Enhanced Data Rate (EDR) and Alternate MAC and PHY (AMP) layer extensions33.
The LE system includes features designed to enable lower current consumption, lower complexity and lower cost than the BR/EDR system. The LE
system is also designed for applications with lower data rates and has lower
duty cycles. In consequence, depending on the application, one system
including any optional parts may be more optimal than the other.
There may be devices implementing either BR/EDR and LE systems
(dual mode) or only one of them (stand-alone), allowing compatibility and
interoperability with existing devices.
The stand-alone LE system is intended for small devices (like watches
and sports sensors) and it will enable new button cell battery operated devices. Many applications such as healthcare, sports and fitness, security, and
home automation will be enhanced with the availability of small coin-cell
battery powered BT-LE wireless technology.
33
The Basic Rate system offers synchronous and asynchronous connections with data
rates of 721.2 kbps for Basic Rate, 2.1 Mbps for Enhanced Data Rate and high speed operation up to 24 Mbps with the 802.11 AMP [37].
293
6/9/10
10:16
Página 294
Sensors Everywhere
The key technical features of BT-LE are shown next [38]. Very short
data packets (8- octet minimum up to 27-octets maximum) are transferred at 1 Mbps. All connections use advanced sniff-subrating34 to
achieve low active duty cycles. The adaptive frequency hopping
common to all versions of Bluetooth technology is used to minimize
interference from other technologies in the 2.4 GHz ISM Band. BT-LE
places a significant amount of intelligence in the controller, which
allows the host to sleep for longer periods of time and be woken up by
the controller35 only when the host needs to perform some action. This
allows for the greatest energy savings. BT-LE can support connection
setup and data transfer as low as 3 ms, allowing an application to form
a connection and then transfer authenticated data in few milliseconds
for a short communication burst before quickly tearing down the connection. Increased modulation index36 provides a possible range for
BT-LE of over 100 meters. BT-LE uses a strong 24 bit CRC on all packets
ensuring the maximum robustness against interference. Full AES-128
encryption using Counter with Cipher block chaining-Message authentication code (CCM) to provide strong encryption and authentication of
data packets. BT-LE uses a 32 bit access address on every packet for
each slave, allowing billions of devices to be connected. The technology is optimized for one-to-one connections while allowing one-tomany connections using a star topology. With the use of quick connections and disconnections, data can move in a mesh-like topology without the complexities of maintaining a mesh network.
34
Sniff sub-rating is a technique that reduces the active duty cycle, enhancing the powersaving capability of Bluetooth sniff mode [37].
35
The Bluetooth core system consists of a Host and one or more Controllers. A Host is a
logical entity defined as all of the layers below the non-core profiles and above the Host
Controller Interface (HCI). A Controller is a logical entity defined as all of the layers below
HCI [37]
36
The Bluetooth BR system employs GFSK (Gaussian Frequency Shift Keying) modulation.
The Modulation index can be between 0.28 and 0.35. For LE system, this index increases
between 0.45 and 0.55.
294
6/9/10
10:16
Página 295
As mentioned above, BT-LE places a significant amount of intelligence in the controller, allowing the greatest energy savings. The reason
why is because the link layer, which is part of the controller function, is
in charge of providing ultra low power idle mode operation, simple device discovery and reliable point-to-multipoint data transfer with advanced power-save. The energy saving mainly comes from the ability of
this layer to switch off the connection when not in use. Fig. 11.3 shows
three possible Bluetooth Host and Controller Combinations: LE Only
Primary Controller, BR/EDR only Primary controller and BR/EDR and LE
primary controller [37]. The Figure 11.4 describes the protocol stack
within the Host and Controller entities for the latest dual mode
Bluetooth operation [37].
Fig. 11.3. Three possible Bluetooth Host and Controller Combinations [37]
295
6/9/10
10:16
Página 296
Sensors Everywhere
Fig. 11.4. BT-LE protocol stack overview for the dual mode [37]
Finally, note that the Bluetooth specification defines a star topology for
the communication between Bluetooth devices. A mesh network composed of Bluetooth devices can be built, but it is beyond the scope of the
Bluetooth specification.
296
6/9/10
10:16
Página 297
11.2.
Home/Building automation and AMR/AMI solutions
This section presents WSN solutions that are mainly used in the domains
of home automation, building automation or AMR/AMI. The solutions presented are Z-Wave, Wavenis, EnOcean, INSTEON and One-Net, which are
shown in subsections 11.2.1 to 11.2.5.
11.2.1. Z-Wave
Z-Wave is a wireless protocol architecture developed by ZenSys (now a
division of Sigma Designs) and promoted by the Z-Wave Alliance for automation in residential and light commercial environments. The main purpose
of Z-Wave is to allow reliable transmission of short messages from a control
unit to one or more nodes in the network [13].
Z-Wave is organized according to an architecture composed of five main
layers: the Physical layer, the MAC layer, the Transfer layer, the Routing layer
and the Application layer (see Fig. 11.5).
The Z-Wave radio operates in the 900 MHz ISM bands (e.g. 868 MHz in
Europe and 908 MHz in the United States). This feature has two benefits:
i) larger physical propagation range (or smaller power consumed for the
same range) than that available when the 2.4 GHz band is used, and
ii) avoidance of interference issues with other systems operating in the 2.4
GHz band, such as WiFi or Bluetooth. Typical ranges claimed by Z-Wave are
30 m indoors and 100 m outdoors. Z-Wave allows transmission at 9.6 kbps
and 40 kbps data rates using Binary Frequency Shift Keying (BFSK) modulation. The recent Z-Wave 400 series single chip supports the 2.4 GHz band
and offers bit rates up to 200 kbps. This chip has a frequency agility mechanism whereby the receiver simultaneously listens on three different channels and the transmitter can use the one with least interference.
The MAC layer of Z-Wave defines a collision avoidance mechanism that
allows the transmission of a frame when the channel is available. Otherwise,
the transmission attempt is deferred for a random period of time. The
Transfer layer manages the communication between two consecutive
nodes. This layer provides frame integrity verification by means of an 8-bit
297
6/9/10
10:16
Página 298
Sensors Everywhere
checksum and an optional retransmission mechanism based on ACKs,
which is only defined for unicast transmissions. Multicast and broadcast
modes are supported.
Z-Wave defines two types of devices, namely: controllers and slave
nodes. Controllers send commands to the slaves, which reply to these commands and execute them. Z-Wave uses a 32-bit unique identifier for each
network referred to as Home ID (i.e. one network corresponds to one home).
Each node of a Z-Wave network is uniquely identified by an 8-bit Node ID. A
Z-Wave network can be composed of up to 232 devices.
The Z-Wave Routing layer specifies routing operations on the basis of a
source routing approach. When a controller transmits a packet, it includes
the path to be followed in the packet. A packet can be transmitted over up
to four hops. A controller maintains a routing table that represents the full
topology of the network. The routing table is a binary bitmap, which is simple and easy to compress. A portable controller (e.g. a remote control), first
tries to reach the destination via direct transmission. If that option fails, then
the controller estimates its location and calculates the best route to the destination accordingly. A static controller has the advantage of always knowing
its own location in the network. Slaves act as routers and have limited
knowledge of the network topology. Routing slaves are a particular type of
slave storing static routes and are allowed to send messages to other nodes
of the network without being requested to do so.
The Z-Wave routing layer is also in charge of ensuring that a routed packet is correctly forwarded along the end-to-end path. For that purpose, the
destination sends an ACK to the source, which is forwarded through the
path followed by the data packet in the reverse direction.
The Z-Wave application layer is responsible for the coding and execution
of commands in the Z-Wave network. This layer defines application layer
messages, which codify a command and its related parameters. Z-Wave also
defines command classes, which are groups of commands. There can be up
to 128 command classes used by applications and 256 commands per
class. Security services are supported in some Z-Wave products by the use
of encryption engines.
298
6/9/10
10:16
Página 299
While the Z-Wave 200 and 300 series chips do not offer security services
(which entail significant implementation size savings), the 400 series chip
supports 128-bit AES encryption.
Z-Wave recently announced the launch of the Z/IP program to drive convergence of Z-Wave and TCP/IP, with the goal of facilitating remote home
monitoring from Internet enabled devices. By mid-2009, Sigma Designs had
introduced the IP-Wave chip, which runs an IP stack on the Z-Wave singlechip solution.
Fig. 11.5. Z-Wave protocol stack
11.2.2. Wavenis
Wavenis is a wireless protocol stack developed by Coronis Systems
(an Elster Group Company) for control and monitoring applications in
several environments, including automatic meter readings and home
and building automation [14]. Wavenis is currently being promoted
and managed by the Wavenis Open Standards Alliance (Wavenis-OSA)
[15].
Wavenis defines functionality of physical, link and network layers.
Wavenis services can be accessed from upper layers through an application
programming interface (API) (see Fig. 11.6).
299
6/9/10
10:16
Página 300
Sensors Everywhere
Wavenis operates at 433 MHz, 868 MHz and 915 MHz bands, which are
ISM bands in Asia, Europe and the US, respectively. The 2.4 GHz band is also
supported [39]. The minimum and maximum data rates offered by Wavenis
are 4.8 kbps and 100 kbps, respectively, 19.2 kbps being the typical value.
Data are modulated using Gaussian Frequency-Shift Keying (GFSK). A fast
Frequency-Hopping Spread Spectrum (FHSS) is used over 50 kHz bandwidth channels. Unlike other spreading techniques, this solution allows
transmissions to be performed in a narrow band with improved sensitivity
and, in consequence, it offers long range link capabilities. In fact, Wavenis
features an indoor range of 200 m and an outdoor line-of-sight range of
1 km. Other data processing techniques are BCH (32,21) Forward Error
Correction (FEC) encoding, data interleaving, scrambling and, optionally,
data encryption.
Wavenis devices are identified by 6-byte MAC addresses. Unicast, broadcast and multicast communications are supported. The Wavenis MAC sublayer offers synchronized and non-synchronized schemes. Synchronization
is generally performed at preselected times that depend on the application.
For example, lighting applications may require more frequent synchronization than metering applications.
In a synchronized network, nodes are provided with a mixed
CSMA/TDMA mechanism if feedback is requested after a broadcast or multicast message. In such a case, a node allocates a timeslot which is pseudorandomly calculated according to its address. Before transmission in that
slot, the node performs Carrier Sense (CS). If the channel is busy, the node
computes a new timeslot for the transmission. For non-synchronized networks, in applications where reliability is a critical requirement (e.g. alarms,
security, etc.), CSMA/CA is used.
The Wavenis Logical Link Control (LLC) sublayer manages flow and error
control by offering per-frame or per-window ACKs. Unreliable communication (i.e. without ACKs) is an available option.
In contrast with other technologies, Wavenis defines only one type of
device. (For example, IEEE 802.15.4 defines two device types, RFDs and
FFDs; Z-Wave defines two device types also, which are controllers and
slaves).
300
6/9/10
10:16
Página 301
Wavenis network layer specifies a four-level hierarchical tree. The root of the
tree may play the role of a data collection sink or a gateway, for instance. A device
that joins a Wavenis network broadcasts a request for a device of a certain level
and a sufficient QoS value. The QoS value is obtained by taking into consideration
parameters like Received Signal Strength Indicator (RSSI) measurements, battery
energy and the number of devices that are already attached to this device.
Wavenis systems support self organising and self healing networking
capabilities. In addition peer to peer (P2P), star, tree, mesh, broadcast and
repeater operating modes can be enabled [39].
In mid-2009, members of the Wavenis-OSA board of directors declared
that IP was being considered as layer three for future Wavenis specifications.
Wavenis supports various encryption algorithms, such as Triple Data
Encryption Standard (3DES) and 128-bit AES.
Fig. 11.6. Wavenis protocol stack
11.2.3. EnOcean
EnOcean is a proprietary technology developed by a homonymous company [16], which is being promoted by the EnOcean Alliance [17]. EnOcean
is based on a self-powered WSN solution for various environments and has
been successful in the building automation area. The energy used by
EnOcean products is mainly harvested from motion, light and thermal
sources [40] (see Chapter 14 for details about energy harvesting).
301
6/9/10
10:16
Página 302
Sensors Everywhere
EnOcean uses the 315 MHz and 868 MHz bands, which are available in
North America and Europe, respectively. Data are modulated using
Amplitude Shift Keying (ASK), which means that energy is only consumed
for transmission of the “1” symbol. Data rates are 125 kbps and 120 kbps,
respectively, while the transmission range is 200 and 300 meters in free
field, respectively. The packet size is 14 bytes, and the payload size is
4 bytes.
EnOcean devices are identified by 32-bit serial numbers. Typical
EnOcean deployments have been point-to-point or point-to-multipoint, although it is also possible to use repeaters or a simple proprietary mesh networking solution.
Some of the main applications for EnOcean include lighting, shading,
presence detection, window monitoring, and room temperature sensing and
measured data acquisition.
11.2.4. INSTEON
INSTEON is a protocol architecture developed by SmartLabs for home
automation [18]. INSTEON is promoted by the INSTEON Alliance. One of the
distinctive features of INSTEON is the fact that it defines a mesh topology
composed of RF and Power Line Communication (PLC) links. Devices can be
RF-only, power-line-only, or can support both types of communications.
INSTEON RF signals use Frequency-Shift Keying (FSK) modulation with a
64 kHz deviation frequency at the 904 MHz center frequency, with a raw
data rate of 38.4 kbps. The typical range in outdoor environments is roughly
45 m.
INSTEON offers unicast, multicast and broadcast communications services. Messages are protected with an 8-bit CRC. ACKs (either positive or
negative ones) are sent in response to unicast messages and may piggyback
information about the status of the acknowledging device. The devices are
identified by 3-byte unique numbers.
INSTEON devices are peers, which means that any device can play the
role of a sender, a receiver, or a relayer. Communication between devices
302
6/9/10
10:16
Página 303
that are not within the same range is achieved by means of a multihop
approach, which differs in many aspects from more traditional routing
techniques used in other technologies. All devices retransmit the
messages they receive, unless they are the destination of the messages.
The source specifies the maximum number of hops for each message,
which cannot exceed four hops, as in Z-Wave. The multihop transmission
is performed using a timeslot synchronization scheme, by which
transmissions are permitted at certain timeslots and devices within the
same range do not transmit different messages at the same time. These
timeslots are defined by a number of powerline zero crossings37. RF
devices not attached to the powerline can transmit asynchronously, but
the messages will be retransmitted synchronously by RF devices
attached to the powerline. In contrast with classical collision avoidance
mechanisms, devices within the same range are allowed to transmit the
same message simultaneously. This approach, which is called simulcast,
relies on the very low probability of multiple simultaneous signals being
cancelled, either using the powerline or RF media. In fact, simulcasting
increases communications reliability. The source of a message may
perform up to five retransmissions if an ACK from the destination is not
received in response to that message.
INSTEON messages contain two bytes that codify the command to be
executed by the receiver. INSTEON defines 16 different device categories,
and for each category there may be up to 4096 devices. Two types of messages are defined: 10-byte standard messages and 24-byte extended messages. Extended messages can contain encrypted payloads.
INSTEON was developed by keeping compatibility with X-10 systems38,
which gives INSTEON the possibility of being installed in many residential
environments where X-10 devices are already deployed.
37
Powerline zero crossings are the periods whereby the electrical signal value is equal or
very close to zero. This feature helps to keep compatibility with the X-10 home automation system (see next footnote).
38
X-10 is an old home automation system with limited functionality that uses the power
lines to communicate between nodes.
303
6/9/10
10:16
Página 304
Sensors Everywhere
11.2.5. ONE-NET
ONE-NET has been developed by a group of companies to offer an open
standard for low power wireless connectivity [19]. The protocol is intended
for developing control applications for home and small office environments.
ONE-NET can be used in the 868 MHz and 915 MHz bands (any of the
25 channels available in the US can be used). The nominal data rate is
38.4 kbps, but throughput is limited to 6 kbps. The distance between two
nodes is up to 60 – 100 m indoors. CSMA is used as the MAC mechanism.
The devices are assigned 48-bit identifiers, which are called system IDs,
and are compose of a 36-bit network ID and a 12-bit device ID.
ONE-NET offers several topologies, including star, peer-to-peer and
mesh. Security is supported by means of the Extended Tiny Encryption
Algorithm (XTEA), which is a cipher that uses a 128-bit key. Data transactions
are protected against spoofing and replay attacks by means of nonces39.
11.3.
Industrial automation networks
This section focuses on the main WSN solutions for the Industrial
Automation domain. An overview is presented for the Time Synchronized
Mesh Protocol (TSMP), a protocol developed by Dust Networks, which has
been used as a core component of WirelessHART and ISA100.11a.
Subsection 11.3.1 focuses on TSMP, while sections 11.3.2 and 11.3.3 present WirelessHART and ISA100.11a, respectively.
11.3.1. TSMP
TSMP [20, 21] is a protocol developed by Dust Networks [22], which provides services with the aim of contributing to end-to-end reliability at the
MAC, network and transport layers, particularly for industrial automation
networks. TSMP also provides physical layer enhancements.
39
A nonce is a number or bit string used only once, in security engineering.
304
6/9/10
10:16
Página 305
TSMP has been implemented in the 2.4 GHz band on IEEE 802.15.4
radios and in the 900 MHz band on proprietary radios. TSMP assumes the
use of FHSS in conjunction with DSSS in order to achieve greater robustness
against interference than when DSSS alone is used. Due to the use of FHSS,
consecutive transmissions between a node and its next hop are performed
by using different frequencies.
TSMP, on the other hand, is based on a TDMA approach. Hence, consecutive transmissions between two nodes take place in different frequencies
as well as in different timeslots. A node can participate in different frames
(which comprise a number of timeslots) of different sizes for performing different tasks at once. For a given task, the transmission rate of a node
depends on the corresponding frame size. Note that TDMA naturally allows
duty cycling. In TSMP, nodes are synchronized with a scheme that is based
on message exchanges between a node and its neighbours.
In TSMP, all devices are capable of routing data. A TSMP node joins a network by discovering neighbours, which requires the node to listen at the frequencies available and to measure the RSSI corresponding to each neighbour. The node obtains synchronization and frequency hopping information, and subsequently establish links with its neighbours.
TSMP relies on spatial and temporal diversity to assure data delivery.
Spatial diversity is achieved by the use of mesh topologies, which offer path
redundancy between a source and its corresponding destination (which is in
general a sink node). Temporal diversity is achieved by the use of link layer
ACKs and NACKs (which are generated when the receiver’s buffer is full). If
an ACK is not received after the transmission of a frame, a retransmission
attempt takes place in the next available slot.
The routing paradigm used in TSMP is called graph routing. A graph is a
structure that represents the nodes of a network and the connections
among them. TSMP uses directed acyclic graphs towards certain destination
nodes (e.g. a special node called a network manager). A network may have
multiple graphs if several destinations are defined. A node includes the identifier of a graph in the packets that it transmits. This identifier is used by intermediate nodes for retransmitting the packets towards their next hops.
305
6/9/10
10:16
Página 306
Sensors Everywhere
TSMP offers encryption and authentication/integrity at the network
layer, as well as frame authentication/integrity at the link layer. The cryptographic operations employ the 128-bit key AES algorithm in CCM* mode
(see chapter 9, section 9.2.2). The following types of keys are used:
• Join keys, which are assigned to each device prior to deployment, and
are used in the process of authenticating the joining device with the
network manager, which maintains an access control list.
• Network keys, which are shared by all network devices and are used for
MAC layer frame authentication/integrity.
• Session keys, which are used to provide end-to-end confidentiality and
data integrity.
When a node joins a network, it sends a join request message encrypted
with its Join key. The network manager checks the identity and the key used
by the new device. If these parameters correspond to a valid device, the new
device is admitted and the network manager sends a Session key and the
shared Network key to the device. The dialogue between the network
manager and the new node is encrypted with the node’s original join key.
Dust Networks currently offers the family of SmartMesh products [42],
which were developed for various applications, with a special focus on
industrial automation. These products use an IEEE 802.15.4 radio and have
a 200 m range in an outdoor environment, with a consumption of 50 mA.
The manufacturer also offers WirelessHART compatible devices based on
the SmartMesh platform.
11.3.2. WirelessHART
WirelessHART is a wireless communication technology designed for
industrial plant applications, which is included in the Highway Addressable
Remote Transducer (HART) 7 specification. It is developed by the HART
Communication Foundation, which specifies the standards for the HART
communication protocol [23]. This protocol is a bi-directional communication protocol that offers communication between intelligent field instruments and host systems [24].
306
6/9/10
10:16
Página 307
WirelessHART is compatible with 2.4 GHz IEEE 802.15.4-2006 physical
layer and MAC frame format. The MAC mechanism used is a combination of
CSMA and TDMA, where a timeslot has duration of 10 ms. Frequency hopping
is used on a message by message basis. Channel blacklisting is supported in
order to avoid the use of interfered channels. Various types of superframes
can be defined, which support fast (i.e. transmission every second), slow (i.e.
transmission period in the order of minutes), cyclic and acyclic network traffic.
Messages have different priorities, depending on their nature. In a decreasing
order of priority, the message categories are command (which contains
network management payloads), process data, normal and alarm.
At the network layer, WirelessHART defines a full mesh network, where all
devices source and sink packets and route data for other devices. Unicast, broadcast and multicast are supported. Communication paths are continuously verified for reliability. Two routing paradigms are supported. The main one is graph
routing (as in TSMP), whereby each device stores a network graph generated by
a device called the network manager the source of a packet includes a graph ID
in the packet header and intermediate devices must know which devices the
packet can be forwarded to. Source routing is another available option.
Network bandwidth for a communication is assigned in an on-demand
basis. A simple transport layer offers reliable and unreliable end-to-end
communication. In the reliable mode, automatic retries are supported.
WirelessHART uses the standard HART Application Layer, which is command-based.
WirelessHART provides security services which are essentially those offered in TSMP. One difference is the use of public keys, which are used at the
MAC layer to offer frame authentication/integrity for devices aimed at joining a network and which are not yet authenticated. Key management is the
responsibility of the network administrator/engineer.
11.3.3. ISA100.11a
In 2005, the International Society of Automation (ISA) [25] created a committee called SP100 / Wireless Systems for Automation, which was chartered with
the goal of creating an open standard for industrial wireless monitoring and con-
307
6/9/10
10:16
Página 308
Sensors Everywhere
trol. The result is a standard focused on industrial automation, including feedback loop control within its scope. The generic name of the standard is ISA100
and the specific standard covering the wireless access is called ISA100.11a,
which was finally released in September 2009. Despite the publication of
WirelessHART, the ISA justified the development of ISA100.11a because of the
limited application of WirelessHART, the lack of formal support (WirelessHART is
promoted by a group of companies) and the possibility of ISA100.11a transporting information from different buses such as Profi, HART, Mod or FF.
ISA100.11a defines a protocol stack which covers the functionality of the
physical layer, the data link layer, the network layer, the transport layer and
the application layer. Security is also provided. Like WirelessHART,
ISA100.11a is based on the functionality defined by TSMP. ISA100.11a uses
IEEE 802.15.4-2006 as the physical and MAC layers. A relevant factor is that
the frame format defined by 6LoWPAN in RFC 4944 [26] is used at the network layer. This layer also provides addressing, routing, quality of service
and management functions. The transport layer offers services that include
both reliable (i.e. acknowledged) and unreliable data transport, secure transport, flow control and segmentation and reassembly. The application layer
provides support for enabling an open and interoperable ISA100.11a application environment, which includes legacy and non-legacy ISA100.11a
applications. ISA100.11a also offers a tunnelling object, which provides
generic services for protocol translation and can be used in a gateway, that
is, the element which connects an ISA100.11a network with another network. Security services are provided at the MAC and transport layers.
11.4.
Other solutions
This section presents the following WSN solutions: SensiNet, XMesh, ANT,
DigiMesh, Ambiosystems, Ambient Systems and RuBee.
11.4.1. SensiNet
A company called SENSICAST [27] has developed a proprietary solution
called SensiNet. The 900 MHz and 2.4 GHz bands are available. In the first
308
6/9/10
10:16
Página 309
case, FHSS is used, while in the second one the radio used is IEEE 802.15.4,
with the addition of Distributed Frequency Spread Spectrum (DFSS). DFSS is
a technique which is able to change a channel if it is busy and offers better
resistance to interference than the default IEEE 802.15.4 PHY.
The transmitted power is limited to 15 dBm and offers a range up to
212 m in the 2.4 GHz band outdoors. SensiNet defines two types of devices:
Mesh Routers [43] and Smart Sensors. The former ones perform are in
charge of routing. SensiNet defines a self-healing network.
Due to the physical layer enhancements against interference, SensiNet is
particularly appropriate for industrial environments.
11.4.2. XMesh
XMesh is a multi-hop networking protocol stack developed by Crossbow
for low-power networks [28]. Some of the features of XMesh include time
synchronization, flexible topologies, support for various QoS levels, integrated network health messages and partial support of ZigBee.
XMesh developers claim that XMesh enables reliable routing links to third
party ZigBee devices [29]. However, some researchers have found interoperability issues between XMesh and ZigBee [30].
XMesh is offered as a software library, on top of devices that have IEEE
802.15.4 radio interface and run TinyOS.
11.4.3. ANT
ANT [31] is a wireless networking protocol developed by a company
called Dynastream Innovations Inc. that operates in the 2.4 GHz band.
Multiple frequencies can be used within this band. The raw data rate is
1 Mbps and the transmission range is up to 30 m. Acknowledged transmission is supported, yielding a net data rate of up to 20 kbps.
All devices in ANT perform the same roles and there is no coordinator
node. ANT allows peer-to-peer, star, tree and mesh networks, besides formation of other topologies. An ANT network may be composed of up to
309
6/9/10
10:16
Página 310
Sensors Everywhere
232 devices. ANT technology has a significant market share in sports & fitness
applications. Fig. 11.7 shows a chip-based solution that includes the ANT
protocol stack.
Dynastream plans to get into markets related to home automation and
industrial automation.
Fig. 11.7. nRF24AP2 chip-based solution that includes the ANT protocol
stack [31]
11.4.4. DigiMesh
DigiMesh is a proprietary solution (peer-to-peer networking topology
for use in wireless end-point connectivity) developed by Digi [32]. This
solution operates in the 900 MHz and 2.4 GHz bands, where FHSS and
DSSS are used, respectively. In the first band the data rates available are
10, 125 and 150 kbps, while in the second one the data rate is 250 kbps.
DigiMesh supports long transmission range (up to 64 km in the Xtend
product). In some products, the data payload is up to 256 bytes. DigiMesh
device identifiers are 64-bit MAC addresses. DigiMesh supports only one
type of node. DigiMesh offers security based on the application of the
AES algorithm.
11.4.5. AmbioSystems
AmbioSystems offers a proprietary WSN solution based on the
AmbioMote platform [33] (see Fig. 11.8); which operates in the 2.4 GHz band
at a raw data rate of 2 Mbps and with an application layer data rate of
500 kbps. This solution has been designed on the assumption that energy is
310
6/9/10
10:16
Página 311
harvested from vibration, strain or light, although a back-up battery can also
be used. The transmission range is up to 80 m and a simple star topology is
supported.
Fig. 11.8. AmbioMote 24-A platform [33]
11.4.6. Ambient Systems
The so-called Ambient Product Series 3000 is a WSN solution developed
by Ambient Systems [34]. The device radio is based on the 2.4 GHz IEEE
802.15.4 interface. Three types of devices are defined: SmartPoints,
MicroRouters (see Fig. 11.9) and a Gateway. The first are battery-enabled,
include various types of transducers, are capable of determining their own
location and have additional storage capabilities for performing active RFIDlike tasks (e.g. information tracing). The MicroRouters carry out multi-hop
routing operations. The Gateway collects the information obtained by the
SmartPoints.
For data transmission, a SmartPoint communicates with a MicroRouter.
The latter transmits beacons periodically, while a SmartPoint selects the
MicroRouter it will communicate with according to the signal strength of the
beacons received. The SmartPoint uses CSMA as the MAC mechanism.
311
6/9/10
10:16
Página 312
Sensors Everywhere
Fig. 11.9. Ambient Systems MicroRouter [34]
11.4.7. RuBee
RuBee is a bidirectional, on-demand, peer-to-peer network protocol
which uses a low-frequency carrier [35]. The default frequency band is
131 kHz, but RuBee can operate in other frequencies, e.g. 450 kHz. The
protocol is targeted on tagging networks offering speeds from 300 to
9600 baud and using IP addresses. The IEEE P1902.1 standard is based on
the RuBee protocol.
One of the main advantages of RuBee is its ability to operate in harsh
environments due to the physical properties of the low frequencies used by
the protocol (in an area range of up to 15 metres).
REFERENCES
[1]
“ZigBee specification”, r17, ZigBee Alliance, October 2007.
[2]
ZigBee Alliance website: http://www.zigbee.org/en/about/.
[3] C. Perkins, E. Belding-Royer, S. Das, “Ad hoc On Demand Distance
Vector Routing (AODV)”, RFC 3561, July 2003.
[4] “ZigBee Home Automation Public Application Profile”, Revision 25,
Version 1.0, ZigBee Alliance, October 2007.
312
6/9/10
10:16
Página 313
[5] “ZigBee Smart Energy Profile Specification”, Revision 15, ZigBee
Alliance, December 2008.
[6]
D. Gislason, “ ZigBee Wireless Nerworking”, Elsevier. Inc, 2008.
[7] J. Hui, D. Culler, “IP is dead, long live IP for wireless sensor networks”, in
Proceedings of the 6th ACM Conference on Embedded Networked
Sensor Systems, pp. 15-28, Raleigh, NC, USA, November 2008.
[8] N. Kushalnagar, G. Montenegro, C. Schumacher, "IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals", RFC 4919, August 2007.
[9] 6LoWPAN protocol stack data sheet from Jennic.
http://www.jennic.com/files/support_files/6LoWPAN_PB_1v0.pdf.
[10] 6LoWPAN development platform from Sensinode.
http://www.sensinode.com/media/whitepapers/sensinode-wp2developing_6lowpan.pdf.
[11] C. Bormann, D. Sturek, Z. Shelby, “Problem Statement for 6LoWPAN and
LLN Application Protocols”, Internet Draft, (Work in progress) July 2009.
[12] US NIST Smart Grid home page: http://www.nist.gov/smartgrid
[13] “Z-Wave protocol overview”, Version 4, May 2007.
[14] C. Dougas, “Configuring and managing a large-scale monitoring network: solving real world challenges for ultra-low powered and longrange wireless mesh networks”, International Journal of Network
Management, 15: 269–282, 2005.
[15] Wavenis Open Standard Alliance website: www.wavenis-osa.org
[16] EnOcean website: http://www.enocean.org
[17] EnOcean Alliance website: http://www.enocean-alliance.org/
[18] “INSTEON. The Details”, August 2005.
[19] “ONE-NET Specification”, Version 1.5.0, February 2009.
[20] “Technical Overview of Time Synchronized Mesh Protocol (TSMP)”,
Dust Networks.
313
6/9/10
10:16
Página 314
Sensors Everywhere
[21] K. Pister, L. Doherty, “TSMP: Time Synchronized Mesh Protocol”, in
Proceedings of the International Symposium on Distributed Sensor
Networks (DSN 2008), Florida, USA, November 2008.
[22] Dust Networks website: www.dustnetworks.com
[23] HART Communications Foundation (HCF) website:
http://www.hartcomm.org/
[24] WirelessHART Technical Datasheet, May 2007.
[25] ISA website: http://www.isa.org
[26] N. Kushalnagar, G. Montenegro, J. Hui, D. Culler, "Transmission of IPv6
Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[27] SENSICAST website: http://www.sensicast.com/
[28] Crossbow Technology: Mesh Networking website
http://www.xbow.com/Technology/MeshNetworking.aspx
[29] M. Turon, M. Horton, J. Hill, A. Broad, “XMesh Routing Layer”, February 2005.
[30] J.-S. Lee, Y.-C. Huang, “ITRI Zbnode: A ZigBee/802.15.4 Platform for
Wireless Sensor Networks”, 2006 IEEE Conference on Systems, Man
and Cybernetics, Taipei, Taiwan, October 2006.
[31] ANT website: http://www.thisisant.com
[32] Digi Networks website: http://www.digi.com
[33] AmbioSystems website: http://www.ambiosystems.com/
[34] Ambient Systems website: http://www.ambient-systems.net/
[35] J. K. Stevens, “RuBee Visibility Networks – IEEE P1902.1”, November
2006.
[36] Bluetooth Special Interest Group web site: http://www.bluetooth.org/
[37] Bluetooth Specification Version 4.0 [Vol 0]; Publication date: 17
December 2009
[38] “The Official Bluetooth Technology Info site”:
http://www.bluetooth.com/
314
6/9/10
10:16
Página 315
[39] C. Dugas, “Wavenis ULP long range wireless platforms, sensing, and
M2M monitoring solutions”; presented at M2M Workshop ETSI, Sophia
Antipolis, June 04-05, 2008.
[40] EnOcean, “Energy harvesting made easy with the EnOcean wireless
standard”.
[41] ZigBee web site: http://www.zigbee.org
[42] SmartMesh XT 2.4 GHz M2030 details, from Dust Networks web site:
http://www.dustnetworks.com/products/SmartMesh_XT_2_4_GHz/
M2030
[43] SensiNet Mesh Router details, from SENSICAST web site:
http://www.sensicast.com/mesh_nodes.php
[44] D. Sturek, “ZigBee IP Stack Overview”, ZigBee Alliance, 2009.
315
6/9/10
10:16
Página 316
6/9/10
10:16
Página 317
12
Sensed data
management
6/9/10
10:16
Página 318
6/9/10
10:16
Página 319
Chapter 12. Sensed data management
12. Sensed data management
WSNs have a great potential for collecting data, but without additional
context information the data cannot be transformed into information.
Sensor data have to be correlated in time and space in order to derive conclusions and provide useful information. To make this kind of processing
possible, data has to be tagged with additional information (e.g. time, location, source, user, type of attribute, etc.). This kind of metadata is quite verbose and contrary to the memory and transmission capabilities of the sensor nodes. To reconcile these opposing interests, it is possible to use specific
compact formats or intermediate nodes40 capable of providing semantic
content to the raw data provided by the sensor node.
Data collected by sensors can be sent directly to a sink node or to
any neighbour in order to process the data from different sources. To
save battery and bandwidth, it is convenient to minimise the number of
data transmissions41, although this approach may come at the expense
of losing capacity to detect any change in the parameters monitored by
the WSN. This can be done by comparing the data from different sensor
nodes in order to avoid errors or reinforce decisions by sending only
relevant data to the sink node. It is also possible to bring the data from
different sources together and send them using one single transmission. Some of these optimisations can only be done once the data are
processed, which requires application processing at the sensor node.
40
41
Note that such intermediate nodes will generally exist in typical deployments.
Chapter 14 shows how local data processing in sensor nodes is preferred rather than
data transmissions in order to save energy consumption.
319
6/9/10
10:16
Página 320
Sensors Everywhere
Full categorized data can be stored efficiently in a database (to minimize storage capacity and facilitate data correlation).
This chapter is devoted to WSN data management and encoding. Section
12.1 discusses in-network collaboration storage management techniques.
Section 12.2 focuses on semantic mechanisms to describe the attributes of
data collected by a sensor network. Section 12.3 describes a standardisation
initiative called “Sensor Web” aiming to provide enhanced descriptions and
meaning to sensor data in a broad sense, and facilitating the transport
through the Internet. Finally, Section 12.4 gives an overview of the IEEE
1451, a family of standards which includes syntax and semantics for the
information exchange between different transducers and a central information system.
12.1.
In-network storage management
Sensor network applications exist in which sensed information is not
collected in real time. In such applications, the data must be (temporarily)
stored within the network and used in response to queries performed by an
observer. Some example applications include [1]:
• Offline monitoring: sensors are deployed to collect detailed information about a phenomenon for later playback and analysis. One example of this kind of application is ZebraNet, where sensors are attached
to animals [2].
• Dynamic augmented reality42: in this type of application, the sensors
store data about ongoing events. The data is dynamically queried by
users within the network.
In such applications, the data must be stored in the network. The size of
the overall data to be stored can be reduced if neighbour nodes collaborate.
42
Augmented Reality refers to the improvement of certain reality aspects by a combination of “virtual” and real elements. “Virtual” elements are those created on the basis of
the sensor data collected from the real environment in order to complement the user
perception with extra information. This technology aims at boosting user experience.
320
6/9/10
10:16
Página 321
In addition, the storage can be loadbalanced among collaborating nodes.
Two approaches are possible [1]:
• Aggregation43: neighbouring sensors can exploit the spatial correlation
of data to reduce the overall size of the stored data. Data exchange between neighbours is needed.
• Coordination for redundancy control. Coordination between
neighbours may allow the redundancy of data sampled to be estimated.
Several collaborative storage protocols are presented in [1]. These protocols are variants of the two protocols mentioned next. The first one is the
Cluster Based Collaborative Storage (CBCS) protocol, in which clusters are
formed and the cluster head is in charge of receiving the observations of
sensors within the cluster and of performing data aggregation and storage.
The second is the Coordinated Local Storage (CLS), where the sensors coordinate periodically and adjust their sampling schedules to reduce the overall redundancy.
In the context of real-time monitoring sensors, aggregation is one of the
main techniques applied [3, 4].
12.2.
Data interpretation
Sensors encoding of observed phenomena are by nature opaque
(often in binary or proprietary formats). Hence, metadata play an
essential role in managing sensor data. A semantically rich WSN would
provide spatial, temporal and thematic information essential for
discovering and analyzing sensor data [5]. These metadata may also be
added to the data obtained from sensors once the data have been
transmitted through the WSN and received by database or tagging
equipment.
43
Aggregation is defined as any kind of operation performed over a set of data, which leads
to a result obtained by taking into consideration the whole set of data.
321
6/9/10
10:16
Página 322
Sensors Everywhere
It is interesting to handle complex data for either processing the data in
the network or for storing the information in a central data base. There exist
several efforts aimed at providing protocols for exchange of complex structured data information capable of adding enhanced descriptions and meaning to sensor data. One set of protocols are adaptations of the eXtensible
Markup Language (XML), the de facto standard for data format to exchange
structured information over the Web. These are discussed in subsection
12.2.1. One such example is the Extended Environments Markup Language
(EEML), which is introduced in section 12.2.2. A standardisation initiative is
carried out by the Open Geospatial Consortium (OGC) [6], which has developed an enhanced data encoding format also based on XML for metadata
description of sensors, called SensorML, which makes any sensor device discoverable and accessible by using a common mechanism. This is presented
in subsection 12.2.3.
Finally, the NIST has recently created the Harmonization of Sensor
Standards Working Group [14] in order to develop a common sensor ontology based on data formats of sensors domain, including IEEE 1451 [15],
ANSI N42.42 [16] and CBRN data model [17], among others.
12.2.1. Use of XML in WSNs
A highly exchangeable and extensible data format is XML, which has
become the facto standard for data format for exchanging structured information over the Web. The usage of XML in WSNs may solve the problem
heterogeneity and information coding.
Due to the limited resources on sensor nodes, native XML support is not
offered. Several proposals tend to simplify the processing and transmission
of XML coded data in nodes. This can be achieved with efficient XML compression [8] or by preparing the software of the node to be optimised for processing XML [9].
Compact data encodings based on XML have been defined. The W3C
specified Efficient XML Interchange (EXI) [20], a very compact representation for XML information. EXI allows for a simple mode of operation
called schema-informed mode, which is suitable for severely con-
322
6/9/10
10:16
Página 323
strained devices. Binary XML (BXML) has also been defined [21]. The
main drawback of these kinds of compressed formats is that they may
require more resources, in terms of memory and CPU, than the processing of the XML file itself.
12.2.2. EEML
EEML [22] is an XML-based protocol that describes sensors (and
actuators) data collected in a structured form. It can be used to facilitate direct connections between any two environments. For example, it
has been implemented in the Pachube44 web service [23], to facilitate
many-to-many connections. EEML is in fact a markup language that
describes the data output of sensors and actuators according to its
geospatial position.
12.2.3. SensorML
Members of the Open Geospatial Consortium (OGC) have defined a standard XML encoding scheme called Sensor Model Language (SensorML) for
metadata describing sensors, sensor platforms, sensor tasking interfaces as
sensor generated data. The objective of this initiative is to make any sensor
device (from a flood gauge to a heart monitor or a web cam) discoverable
and accessible using a common mechanism. As the proposal is originated
by OGC, geolocation of the sensor measurements is a key functionality.
Furthermore, ease in publishing the sensor data on a web is also a design
objective.
SensorML provides a complete description of the sensor capabilities and
gives information on how to process and locate the measured data. It also
provides performance characteristics (e.g. accuracy) and facilitates the
archiving of the information. Fig. 12.1 shows an example of a sensor using
SensorML.
44
Pachube is a web service that enables people “to connect, tag and share real time sensor data from objects, devices, buildings and environments around the world” [23].
323
6/9/10
10:17
Página 324
Sensors Everywhere
Fig. 12.1. Example of the SensorML description of a sensor [10]
SensorML uses XML, which is a verbose description language. An example of the coding is provided in Fig. 12.2.
Fig. 12.2. Response Example – YSI45 Wind Speed Sensor [10]
45
YSI is a developer and manufacturer of sensors, instruments, software, and data collection platforms for environmental monitoring and testing [http://www.ysi.com/]
324
6/9/10
10:17
Página 325
12.3.
Sensor Web
The Sensor Web initiative has been created by the OGC and the Semantic
Web Activity of the World Wide Web Consortium (W3C) to provide enhanced
descriptions and meaning to sensor data and facilitate transport through
Internet [11]. In this way, the Sensor Web facilitates access to sensor information and the usage of the information for a different purpose than that originally foreseen. Remarkably, the Sensor Web initiative deals with sensors in a
broad sense. For example, complex systems such as satellites are considered
as sensors. Note that such a device does not match the characteristics of the
nodes making up the WSNs that fall within the scope of this book.
The OGC has established the Sensor Web Enablement (SWE) in order to
address the lack of standardization by developing a suite of specifications related to sensors, sensor data models, and sensor Web services that will make
sensors accessible and controllable via the Web. This suite includes three types
of coding: Observation and Measurement (O&M), Sensor Model Language
(SensorML) and Tranducer Model Language (TransducerML). The suite also has
four services: Sensor Observation Service (SOS), Sensor Planning Service (SPS),
Web Notification Service (WNS) and Sensor Alert Service (SAS).
Formal definitions of the semantics of information are captured in ontologies, making it possible for machines to interpret and relate data content
more effectively [12]. The semantic web employs the Resource Description
Framework (RDF) [13] data representation model, the ontology representation languages RDF Schema and the Web Ontology Language (OWL).
12.4.
IEEE 1451
The IEEE 1451 is a standard that was not developed with the aim of creating data representation for sensor information. Rather, it tries to facilitate
the connectivity of different transducers (sensors or actuators) to a central
information system. In support of this, IEEE 1451 has defined a syntax and
semantics. The IEEE 1451 also supports remote connectivity, although the
main interest of the standard lies in the data encoding.
325
6/9/10
10:17
Página 326
Sensors Everywhere
The integration of a processing unit, a communication interface and a
digital or analog sensor or actuator results in a smart transducer. In response to the industry need for a set of sensor interfaces, the IEEE has sponsored the development of IEEE 1451, a suite of standard smart transducer
interfaces for sensors and actuators. IEEE 1451 smart transducers have
capabilities for self-identification, self-description, self-diagnosis, self-calibration, location awareness, time-awareness, data processing, data fusion,
alert notification, standard format presentation and communication protocols. To provide all these functionalities, the smart transducer architecture is
divided into modules and interfaces (see Fig. 12.3).
Fig. 12.3. Smart Transducer model with modules and interfaces [18]
The architecture presented in IEEE 1451 is designed to facilitate the connection of the transducer with the application processor and with a central element
through the network. The Transducer Interface Module (TIM) performs signal
conditioning and data conversion, and is able to connect up to 255 transducers.
The Transducer Independent Interface (TII) defines the communication medium
and the protocol for transferring the information to the application processor
326
6/9/10
10:17
Página 327
located at the Network Capable Application Processor (NCAP). The TII provides
a set of commonly used operations, such as read, write and responses.
A key aspect of the IEEE 1451 is the standardisation of the Transducer
Electronic Data Sheets (TEDS). The TEDS represents information about the
transducer stored in ROM or EEPROM (depending on whether the information can change or not) that enables the specifications of the transducer to
be known electronically.
IEEE 1451 defines three possible ways to access sensors and actuators
from a network:
• IEEE 1451.1. The IEEE 1451.1 defines the information model for smart
transducers [19], including the syntax and semantics for the information exchange.
• Using the Hyper Text Transfer protocols defined in IEEE 1451.
• Using some type of Web service.
The physical interfaces between the NCAP and the TIM cover the following options:
• Point to point interface according to IEEE 1451.2.
• Distributed multi-drop interface defined in IEEE 1451.3.
• Wireless interface (WiFi, Bluetooth and ZigBee) as defined in IEEE 1451.5.
The IEEE 1451.5 defines the communication between TIM and NCAP
using wireless specific protocols. It defines the usage of IEEE 802.11 (WiFi),
IEEE 802.15.1 (Bluetooth), and ZigBee and 6LoWPAN for using IEEE
802.15.4. Different wireless protocols can be used to talk with one NCAP.
• Using CANopen46 following IEEE 1451.6.
• Using RFID according to IEEE 1451.7. The usage of IEEE 1451.7, based
on RFID, has for its purpose identification and tracking as well as allowing new application combinations of RFID and sensors.
46
CANopen is a set of protocols above link layer (including the network layer) that uses the
lower layers provided by Controller Area Network (CAN), a solution used for connecting
devices in automation.
327
6/9/10
10:17
Página 328
Sensors Everywhere
The IEEE 1451.4 defines for specific cases the interface between the
transducer and the signal conditioning and conversion circuits.
REFERENCES
[1] S. Tilak, N. B. Abu-Ghazaleh, W. Heinzelman, “Collaborative storage
management in sensor networks”, International Journal of Ad hoc and
Ubiquitous Computing, Vol. 1, Nos 1/2, pp. 47 – 58, 2005.
[2] P. Juang, H. Oki, Y. Wang, M. Martonosi, L.S. Peh, D. Rubenstein, “Energyefficient omputing for wildlife tracking: design tradeoffs and early experiences with zebranet”, Proc. of ASPLOS 2002, ACM Press, San Jose,
CA, pp. 96–107, 2002.
[3] A. Boulis, S. Ganeriwal, M. Srivastava, “Aggregation in sensor networks:
an energy-accuracy trade-off”, Proc. Of the First IEEE Internation
Workshop on Sensor Network Protocols and Applications (SNPA),
pp.128–138, 2003.
[4] C. Intanagonwiwat, D. Estrin, R. Govindan, J. Heidemann, “Impact of network density on data aggregation in wireless sensor networks”, Tech.
Rep. TR-01- 750, University of Southern California, November 2002.
[5] A. Sheth, M. Perry, “Traveling the Semantic Web through Space, Time,
and Theme”, IEEE Internet Computing, Vol. 12, No. 2, pp. 81-86, 2008.
[6]
Open Geospatial Consortium website: http://www.opengeospatial.org.
[7] Semantic Web Activity of the World Wide Web Consortium website:
http://www.w3.org/2001/sw.
[8] C. J. Augeri, D. A. Bulutoglu, B. E. Mullins, R. O. Baldwin, R. O, L.C. Baird,
“An analysis of XML compression efficiency”, in Proceedings of the
2007 Workshop on Experimental Computer Science (San Diego,
California, ExpCS '07, ACM, New York, USA, June 2007.
[9] N. Hoeller, C. Reinke, J. Neumann, S. Groppe, D. Boeckmann, V.
Linnemann ”Efficient XML Usage within Wireless Sensor Networks”, in
Proceedings of the Fourth International Wireless Internet Conference
(WICON 2008), ACM, Maui, Hawaii, USA, November 2008.
328
6/9/10
10:17
Página 329
[10] M. Botts, “SensorML: XML description of In-situ and Remote Sensors“,
NIST Workshop on Data Exchange Standards at the Construction
Jobsite, Gaithersburg, USA, May 2003.
[11] A. Sheth, “Semantic Sensor Web”, Intelligent Sensors, Sensor Networks
and Information Processing – ISSNIP., Melbourne, Australia, August
2008.
[12] A. Sheth, C. Henson, S. S. Sahoo, “Semantic Sensor Web”, IEEE Internet
Computing, 2008.
[13] Resource Description Framework (RDF) / W3C Semantic Web Activity
web site http://www.w3.org/RDF/
[14] Semantic Community Wiki web site: http://semanticommunity.wik.is/
[15] D. Wobschall, “IEEE 1451 – A Universal Transducer Protocol Standard”,
2007.
[16] G. Lasche, B. Huckins, “An Introduction to the ANSI N42.42 Data File
Format”, August 2006.
[17] W. Snee, T. Johnson, “CBRN Data Model Implementation Approach”,
October 2005.
[18] E. Y. Song, K. Lee, “Understanding IEEE 1451 – Networked Smart
Transducer Interface Standard”, IEEE Instrumentation & Measurement
Magazine, April, 2008.
[19] K. Lee, “The Smart Transducer Interface Standard (IEEE 1451)”, NIST
Workshop on Data Exchange Standards at the Construction Jobsite,
Gaithersburg, USA, May 2003.
[20] T. Kamiya, J. Schneider, "Efficient XML Interchange (EXI) Format 1.0",
World Wide Web Consortium LastCall WD-exi-20080919, September
2008.
[21] Open Geospatial Consortium, "Binary Extensible Markup Language
(BXML) Encoding Specification, Version 0.0.8", January 2006.
[22] EEML web site: http://www.eeml.org/
[23] Pachube web site: http://www.pachube.com/
329
6/9/10
10:17
Página 330
6/9/10
10:17
Página 331
13
Interoperability between
wireless sensor networks
and other networks
6/9/10
10:17
Página 332
6/9/10
10:17
Página 333
Chapter 13. Interoperability between wireless sensor networks and other networks
13. Interoperability between wireless
sensor networks and other networks
WSNs require connectivity with other networks for several reasons which
include remote control, remote access to collected data, software updates, etc.
To assure the interoperability across networks, different aspects need to be
solved, but in general, transport and semantic interoperability should be
guaranteed. Although there are some trends in WSNs towards cross-layering,
the use of an architecture for WSNs based in layers can be advantageous in
terms of interoperability since conventional networks use the layered approach.
The obvious network to which a WSN may be connected is the Internet.
Hence, connecting WSNs to IP networks has attracted the attention of the
research community.
WSNs often run specialized, non-standardized communication protocols.
In such conditions, it is not possible to directly connect a WSN with an IP network. Two options have been proposed for solving this [1]: i) to use Delay
and Disruption-Tolerant Interoperable Networking, or shortly, Delay Tolerant
Networking (DTN) architecture and ii) to place a Protocol Translation
Gateway (PTG), also referred to as ‘proxy’ in some contexts, between the
WSN and the IP network. A different approach, which is gaining relevance as
the related technology evolves and becomes available, is to directly connect the WSN to an IP network by running an IP stack in the WSN nodes
themselves (see also chapter 11). This last approach facilitates the seamless
inclusion of WSNs into the ip Multimedia Subsystem (IMS) framework, and
consequently into evolved telecommunication networks and services
infrastructures, like 3G and beyond cellular mobile networks.
333
6/9/10
10:17
Página 334
Sensors Everywhere
This chapter is devoted to interoperability between WSNs and other networks
(in particular, IP networks). Section 13.1 presents the use of a DTN architecture for
this purpose. Section 13.2 is devoted to the use of Protocol Translation Gateways
(PTGs). Section 13.3 focuses on the use of IP in WSNs. Section 13.4 presents a set
of high level session/application protocols that facilitate the interoperability of
WSNs with external TCP/IP-based networks. Finally, section 13.5 outlines the key
aspects and research works related to the integration of WSNs into IMS.
13.1.
DTN for WSNs
This section first presents an overview of the DTN architecture and how
a WSN can be connected to an IP network following a DTN-based architecture. Secondly, the advantages and drawbacks of this approach are discussed.
13.1.1. DTN overview
DTN is a specific communication protocol architecture designed for
‘challenged networks’47 [2]. These environments are characterized by high
and variable end-to-end delays, potentially high bit-error rates and frequent
network partitioning. Some examples are deep space communications and
mobile networks with intermittent connectivity. The latter ones include certain forms of sensor networks [2]. In fact, the DTN architecture takes into
account that the characteristics of end systems may include limited longevity, low duty cycle operation and limited resources [8], which are features
encountered in WSNs.
DTN creates an overlay store-and-forward message switching on top of
the transport (or another) layer and is independent of the underlying bearer
protocols and addressing schemes. The messages are called ‘bundles’. A
DTN comprises a set of regions. The devices in each region use the same
protocol stack up to the transport layer within that region. The different
regions share a common layer on top of the transport layer called the bun47
For example; see Chapter 2, section 2.1.9.4 Rubbish Selective Recollection.
334
6/9/10
10:17
Página 335
dle layer. This layer is in charge of persistent storage of messages when
communications links are not available, and provides also message fragmentation and optional end-to-end reliability mechanisms.
The DTN architecture assumes the presence of one or more DTN gateways in each region. The DTN gateway interfaces two or more different
regions and therefore supports the protocol stacks (up to the transport
layer) of those regions. The DTN gateway forwards bundles between regions
and maps globally significant identifiers called ’name tuples’ to locally resolvable identifiers. Devices within a region can communicate between
them without the need of a DTN gateway.
Bundle forwarding assumes an underlying reliable delivery service with
message boundaries. In consequence, a convergence layer is needed for each
underlying transport protocol so as to augment its capability. For example, TCP
must be augmented with message boundaries, while UDP needs reliability
and sequencing in addition. On the other hand, the convergence layers support signalling for fragmentation and connection re-establishment [7].
A DTN overlay has been proposed for the connection between a WSN
and an IP network [1, 7]. For this, a DTN gateway is needed between the WSN
and the IP network, where the WSN constitutes one region and the IP network is another region. Fig. 13.1 depicts such architecture.
Fig. 13.1. A DTN-based architecture for connecting a WSN to the Internet
335
6/9/10
10:17
Página 336
Sensors Everywhere
13.1.2. DTN discussion
One advantage of DTN for connecting WSNs to other networks is the fact
that the design principles of DTN consider the characteristics of WSNs. In addition, DTN is a generic purpose architecture, independent (through the appropriate convergence layers) on the underlying protocol stacks. However, this
approach has not been widely adopted. Because DTN is delay-tolerant, it does
not guarantee data delivery within a bounded latency, which reduces the
scope of WSN applications it can be suitable for. Furthermore, the implementation of bundle and convergence layers adds complexity to the protocol
stack of a sensor, which ideally should be kept as simple as possible.
13.2.
Protocol translation gateways
This section introduces first the concept of Protocol Translation
Gateways (PTGs) and discusses their benefits and drawbacks.
13.2.1. PTG overview
A PTG is a device which is able to communicate with both the sensors in
the WSN and the hosts on another network (e.g. the Internet). For this, the
gateway requires the support of two or more, possibly different, PHY interfaces and the semantics and functionality of two or more protocol stacks.
Two examples of a PTG which allows communication between a ZigBee
domain and an IP domain are the commercially available ConnectPort X2 [3]
from Digi and the patent referenced in [4].
Fig. 13.2 shows the protocol architecture of the gateway proposed in [4], where
an IEEE 802.11-based interface is assumed in the IP domain. In this case, the user
data from the IP client are first encapsulated in the corresponding application layer
Protocol Data Unit (PDU), which is in turn encapsulated in the transport layer PDU,
which then constitutes the payload of an IP packet. An IEEE 802.11x frame is then
built for transporting the IP packet and the frame is transmitted using IEEE 802.11x
MAC and PHY mechanisms. The frame is received by the gateway via its IEEE
802.11x interface and the user data are de-encapsulated once each layer entity
336
6/9/10
10:17
Página 337
has processed its corresponding data unit. User data are then encapsulated in the
ZigBee stack data units and are finally transmitted to the ZigBee client via IEEE
802.15.4 MAC and PHY mechanisms. When the IEEE 802.15.4 frame is received by
the ZigBee client, the user data are de-encapsulated once each layer entity has
processed its corresponding data unit. In the communication from the ZigBee
client to the IP client, the opposite operation takes place.
Fig. 13.2. A proposed ZigBee-to-IP gateway architecture [4]
13.2.2. PTG discussion
The use of a PTG allows the WSN to use a protocol architecture optimized
for a specific purpose, while still being connected to another network like
the Internet. However, PTGs exhibit a number of disadvantages. The first one
is lack of end-to-end consistency, which makes difficult to perform tasks
such as transport or QoS efficiently. In fact, the use of PTGs may require the
adoption of a “least common denominator” approach to allow interoperation of the two sides of the gateway [5]. On the other hand, the fact that the
WSN constitutes one domain and the IP network is another domain poses
risks in terms of security, because there is a different security sphere at each
side of the gateway. Furthermore, gateways add management complexity,
because ad-hoc functionality is needed for different WSN architectures.
Fig. 13.3 illustrates the connection of various WSNs to the Internet using
PTGs, because each WSN uses its own protocol architecture. Interestingly,
this picture is similar to that of the 80s, where various proprietary protocol
architectures were proposed for Local Area Networks (LANs), but required
337
6/9/10
10:17
Página 338
Sensors Everywhere
PTGs for their connection to other networks like the Internet. The reasons
why many non-IP-based WSN architectures have appeared in the market
include the following ones: first, for certain applications, optimized and specialized architectures may offer improved performance compared with that
of generic purpose stacks; secondly, for many years, many researchers
argued that the Internet model was not suitable for the particular characteristics of WSNs.
Fig. 13.3. Various WSNs connected to the Internet by means of PTGs
13.3.
IP for WSNs
This section presents first the benefits of the use of IP (and IPv6) in a WSN
in terms of interoperability. Then, the section presents the trends in adoption of IP for WSNs and points out open issues at the time of writing this
book.
13.3.1. Benefits of IP
IP is by nature a good protocol for interoperability between networks.
In fact, IP was designed to connect various different physical networks so
338
6/9/10
10:17
Página 339
as to create a single (logical) network. More specifically, there are reasons
that can be enumerated in favor of using IP in WSNs in terms of interoperability [5].
• IP is open and freely available. It can reach a larger audience than a proprietary protocol [13], which favors interoperability.
• IP is a universal protocol in terms of the variety of applications, devices,
operating systems and underlying networking technologies that it supports. In fact, IP accommodates a wide range of applications with significantly different QoS requirements, such as e-mail, bulk data transfers,
high definition television or voice over IP (VoIP).
• IP successfully runs on high-end servers, desktops, mobile phones and
severely constrained devices like sensors. On the other hand, IP was
designed for connecting physical networks with different characteristics. The Internet is a good example of the success of IP in this regard.
• IP offers end-to-end communication between devices, which does not
require PTGs. Fig. 13.4 represents the end-to-end IP vision for connecting WSNs to the Internet.
Fig. 13.4. Various WSNs connected to the Internet by means of IP routers: the
end-to-end IP vision
339
6/9/10
10:17
Página 340
Sensors Everywhere
13.3.2. Benefits of IPv6
In addition to the benefits of IP in terms of interoperability between networks, IP version 6 (IPv6) [14] is particularly suitable for WSNs. First, it defines
a large address space, where the size of addresses is 128 bits, that satisfies
the requirements of WSNs in terms of their potentially large number of devices. Second, it has many auto-configuration and discovery mechanisms,
which match the unattended operation required by WSNs. Finally, it uses
compact headers that allow the definition of new options when new functionality is needed. However, IPv6 does require an adaptation for optimized
performance on top of WSNs. This work has been carried out by the IETF
6LoWPAN WG. For a detailed description of how IPv6 is used in WSNs, the
reader may refer to Chapter 11 (section 11.1.2).
13.3.3. Adoption of IP for WSNs
In the last years, relevant industry alliances in the area of WSNs, such as
Z-Wave and ZigBee, have announced their intention to adopt IP technology:
• In May 2007, the Z-Wave Alliance announced the Z/IP program to drive
convergence of Z-Wave and TCP/IP and “to take Z-Wave to the next
level of worldwide adoption” [9]. In May 2009, the IP-Wave single chip
solution, which runs an IP stack on a Z-Wave chip, was announced. The
manufacturer recognized that interoperability between IP and Z-Wave
was “a crucial step in the process” because “it is [...] imperative that
home control networks be able to interface with the Internet” [10].
• On the other hand, in April 2009, ZigBee announced that “it will incorporate global IT standards from the Internet Engineering Task Force
(IETF) into its specification portfolio of low-power wireless networking
standards” [11]. Further information from the ZigBee Alliance confirms
the ZigBee plans with regard to IP protocols [21]. Previously, an adaptation of the ZigBee Application Protocol called Compact Application
Protocol (CAP) had been proposed for its use on top of UDP/IP [15]
(see Fig. 13.5). These announcements and activities show a tendency
in the WSN industry to adopt IP and take advantage of its benefits.
340
6/9/10
10:17
Página 341
Fig. 13.5. ZigBee adaptation to IETF 6LoWPAN protocol stack
13.3.4. IETF work in progress and future work
While the IETF 6LoWPAN WG has developed mechanisms for the transmission of IPv6 packets on top of IEEE 802.15.4 networks (see Chapter 11)
and the IETF ROLL WG is currently developing a routing protocol for LLNs
(see Chapter 7), upper layer functionality for these environments has only
started to attract the attention of the IETF community very recently [12]. For
this reason, although it is feasible to run full IP stacks in typical embedded
devices using standard Internet protocols [6], many implementers are
currently using special, ad-hoc, transport and application layer protocols
within the WSN. This approach currently limits the interoperability between
WSNs and the Internet. Work within the IETF in this area is only in a preliminary stage. Hence, the study, development or adaptation of transport and
application layer protocols based on IP for WSNs is an open area as of the
writing of this book.
13.3.5. Usage of existing session/application protocols for WSN
This section discusses the use of various session or application protocols
for the interconnection of WSNs with external TCP/IP based networks like
341
6/9/10
10:17
Página 342
Sensors Everywhere
the Internet; such as SIP, XMPP, MQTT-S, HTTP or web services. Note that it
may be difficult to distinguish session and application protocols due to the
terminology used or the protocols themselves that implement session and
application functionalities.
13.3.5.1 SIP
The Session Initiation Protocols (SIP) was originally created to control
multicast conferences and later evolved as a control protocol for multimedia communications like voice and video. In fact, SIP has become the standard protocol to support voice over IP by the IETF and also by the 3GPP. SIP
offers the possibility to register an IP address with an identification known
as a uniform resource identifier (URI) and to establish a session for the continuous exchange of information. SIP has been extended to be used as an
instant messaging protocol and also to exchange status information also
known as presence information. SIP has defined the role of the user that
provides information when a change is produced using the PUBLISH or the
NOTIFY command when another user is interested in the information. The
user can express its interest in a status variation with the SUBSCRIBE command. Information about the status (including location) is coded using an
XML format. Also SIP defines mechanisms to send a command to a group
of users with the forking function48 or merging different replies. All these
facilities are quite in line with the requirements of high level communication of a WSN. The possibility of using SIP has been analysed [22], but the
complexity of the protocol suggested the using of a simplified version
called TinySIP [23].
13.3.5.2. XMPP
The eXtensible Messaging and Presence Protocol (XMPP) [36] is an alternative to SIP as a presence protocol and it has been proposed as WSN communication protocol [24, 25]. XMPP has been developed by the Jabber open
48
The forking request of SIP means that multiple dialogs can be established from a single
request
342
6/9/10
10:17
Página 343
source community and has been accepted by the IETF (see RFC 3920 [37]).
XMPP uses as a core transport protocol layer an eXtensible Markup
Language (XML) streaming protocol49 (see chapter 12). This permits two
entities to exchange XML elements over the network. The protocol is based
in three stanza types: <presence/>, <message/> and <iq/>. The first stanza
is used as a publish/subscribe mechanism for subscribing to a status event
and receive information about it. The second one is used as a push mechanism for real time delivery and the last one is used to make request and
receive responses. Jabber uses a naming approach that allows identifying a
sensor node or the sensor itself. One of the main distinction characteristics
of XMPP is the federation that allows communication between different
domains quite easily.
The usage of XML based protocols has received certain criticism due to
the verbosity and the processing requirements, but it has proven the feasibility of the solution using simplified approaches such the mXMPP [26] or
compressing the XML with EXI (Efficient XML Interchange)50.
XMPP has been used in solutions such as OpenSpime [27], a proposal
from WideTag to support data collection and encrypted messaging between
entities.
13.3.5.3 MQTT-S
The publish/subscribe mechanism is also used in the protocol MQTT-S of
IBM [30, 35]. This protocol is a light weight implementation or extension of
the Message Queueing Telemetry Transport (MQTT) protocol for WSNs. The
MQTT is a protocol used in resource-constrained devices. The implementation in the client side is very simple. Most of the complexity resides in the
server side (the broker side according to MQTT terminology). The protocol
49
XML is used on top of a persistent connection such as the one provided by TCP. It is possible to transport the XML messages using HTTP but this requires the usage of an XMPP
Enhancement Proposal (XEP). One example is the XEP 0124 “Bidirectional-streams Over
Synchronous HTTP (BOSH)”, which is suitable for WSN.
50
EXI is a proposal from the EXI Working Group of the W3C to optimise the usage of XML.
The proposal includes a more compact coding for XML structures.
343
6/9/10
10:17
Página 344
Sensors Everywhere
assumes an underlying network providing point-to-point connection, session oriented and in-order delivery. MQTT-S, opposed to MQTT does not
assume any functionality from the network and requires an MQTT-S gateway to support the connectivity with the broker. A sensor node publishes its
data to the broker and an entity interested in the data registers its interest in
the broker by means of a subscription. Any published data that matches
with the existing subscriptions will be propagated by the broker to the interested entities.
MQTT-S uses streaming of binary data at higher level protocol (instead of
streaming of XML data).
13.3.5.4. HTTP
Due to the popularity of the web, the usage of HTTP has a significant
acceptance in WSNs. HTTP can be used to get data from a sensor, in a
similar manner data is obtained by a web browser from a web server [44].
Also, web service techniques can be used for interacting with a sensor
node. This last option has two implementations [41]. The first one is the
classical one [43] and implies the usage of SOAP (Simple Object Access
Protocol) to define the format of the messages exchanged when invoking
a service and Web Services Description Language (WSDL) to describe the
syntaxes of the interfaces. SOAP and WSDL are based on XML instances.
Handling this implementation of a web service can be considered complex for a limited resource sensor node and an alternative has been
developed based on the Representational State Transfer (REST) principle
[38]. According to this model, four commands can be used (GET, PUT,
POST and DELETE), the web service is stateless so commands result to be
idempotent. Information exchanged can be encoded using XML, but
other formats are possible. One example is Java Script Object Notation
(JSON), which allows the exchanging and serializing of data structures.
Although JSON is quite common, XML or HTML can also be used. The
format used in data exchange should be used by both sides of the communications since no mechanism similar to WDSL is available. REST additionally allows leveraging all the features intended for HTTP such as
caching, authoring, encryption and compression.
344
6/9/10
10:17
Página 345
With REST, a GET is used to obtain data from a sensor or a PUT to send
data from a sensor. This approach is followed by Pachube [28]. With this system, a sensor can feed information to the Pachube web server (making an
input) or collect information from the web server (making an output). The
data exchanged is coded with Extended Environments Markup Language
(EEML) [29] or using Comma-Separated Values (CSVs). The first one is intended to describe data collected from a device, building, system or space
in a structured form. EEML is similar to SensorML, but it extends its capability describing the environment of the sensor node (see chapter 12). The
CSV is more simple but less flexible than EEML.
The IETF CoRE working group, which is intended to standardise session
and application protocols for constrained networks51 using IP, proposes the
use of RESTful solutions [39]. There are implementations of RESTful solutions for different wireless sensor plataforms [40], [42].
Another HTTP-based alternative is the use of web feeds such as Really
Simple Syndication (RSS) or Atom to publish the information from a sensor.
13.4.
SCADA for WSN applications
Supervisor networks or control networks such as Supervisory Control
And Data Acquisition (SCADA) systems are intended to be used for industrial
control, infrastructure usage or large facility control. A SCADA system is built
with a human machine interface to interact with an operator, a supervisory
system (a computer) for gathering data and sending commands, Remote
Terminal Units (RTUs) to support the data acquisition and control,
Programmable Logic Controllers (PLCs) to distribute the control functions
and a communication infrastructure. This type of networks shares some
aspects with wireless sensor and actuator networks. In fact, a SCADA system
can be used as a replacement of a WSN, since they include all the elements
and functionalities of a WSN, but the cost of elements and complexity of installation of a SCADA system do not fulfil the requirements of a WSN. A
51
WSNs are an example of such considered constrained networks.
345
6/9/10
10:17
Página 346
Sensors Everywhere
SCADA system offers guaranties related to the delay and availability, in particular in the control of actuators, more restrictive than the ones offered by
present WSNs. Even though, WSNs are being used to complement a SCADA
system [31, 32] or even to replace it [33].
SCADA systems use their own specific communication protocols with
the intention to provide the required reliability and availability. The protocols
used include Modbus, RP-570, Profibus or Conitel. IEC 60870-5-101, IEC
60870-5-104 or DNP3 are standard SCADA protocols. Most of the protocols
have extensions to work over IP, but control applications refuse to use the
public Internet. Modbus is used in some WSN deployments due to the fact
that it is royalty-free, it is publicly available and it is simple. Modbus can
transport data in binary format and in ASCII. In addition, there are Modbus
gateways able to use SMS or GPRS.
13.5.
Integration of WSNs into IMS
The 3GPP standardization body has done an important effort in specifying stand-alone network architecture for offering IP-based multimedia
services to mobile users; that is to say IP Multimedia Subsystem (IMS)
[16]. By means of IMS, the network is aware of the service and as a result
controls the service. IMS has been also adopted as a key subsystem in
the ETSI TISPAN architecture (where TISPAN stands for “Telecoms and
Internet Services and Protocols for Advanced Networks”). Therefore, IMS
can be seems as a key piece of convergence of the wireless and the
Internet worlds. IMS is an access agnostic technology, hence it is not just
for UMTS or GPRS, but will also support WLAN, fixed line, etc. IMS can be
optimised by other “All-IP components”52, but IMS does not require the
other components of All-IP.
The seamless integration of WSNs into IMS capable networks, like for
example 3G mobile communication networks, might enable the deploy-
52
All-IP refers to the complete set of technologies to optimise the provision of IP services
(IP core and transport networks, IP radio access network and radio interface, IMS).
346
6/9/10
10:17
Página 347
ment of new application and services to the users based on getting efficient
access to real time contextual information from the sensors. Some integrated architecture solutions based on this idea are proposed in [17, 18].
Another approach considers the Presence architecture (an integral part
of IMS) for the integration, focusing on how the information is conveyed
from the sensor network to the presence infrastructure (i.e. the inbound
interface) [19].
A third approach proposes an interworking architecture between Session
Initiation Protocol (SIP) and ZigBee protocols, and the mapping between the
ZigBee binding mechanisms and publish/subscribe/notify mechanisms of
SIP [20] (see Fig. 13.6).
Fig. 13.6. SIP/ZigBee proposed architecture [20]
REFERENCES
[1] A. Dunkels et al., “Connecting Wireless Sensornets with TCP/IP
Networks”, in Proceedings of the 2nd International Conference on
Wired/Wireless Internet Communications (WWIC'04), Frankfurt,
Germany, February 2004.
[2]
V. Cerf et al., “Delay-Tolerant Networking Architecture”, RFC 4838, April
2007.
347
6/9/10
10:17
Página 348
Sensors Everywhere
[3] ConnectPort X Gateways Product Datasheet.
http://www.digi.com/pdf/ds_connectportx.pdf
[4] W. R. Osborn, J.W. Benett, “ZigBee/IP gateway”, WO/2008/027615,
March 2008.
[5] A. Dunkels, J.P. Vasseur, “IP for Smart Objects”, Internet Protocol for
Smart Objects (IPSO) Alliance, White Paper #1, September 2008.
[6] J. Hui, D. Culler, “IP is Dead, Long Live IP for Wireless Sensor Networks”,
in Proceedings of the 6th ACM Conference on Embedded Networked
Sensor Systems (SenSys’08), Raleigh, USA, November 2008.
[7] M. Ho, K. Fall, “Poster: Delay Tolerant Networking for Sensor
Networks”, in Proceedings of the First IEEE Conference on Sensor and
Ad Hoc Communications and Networks (SECON 2004), Santa Clara,
USA, 2004.
[8] K. Fall, “A Delay-Tolerant Network Architecture for Challenged
Internets”, in Proceedings of SIGCOMM’03, Karlsruhe, Germany, August
2003.
[9] “Z-Wave Converges with TCP/IP to Become the Global Standard for
Wireless Home Control”, http://www.newswireless.net, 16 May 2007.
[10] “Sigma Designs Introduces IP-Wave Single Chip Solution”,
http://www.tradingmarkets.com, 27 May 2009.
[11] ZigBee Alliance, “ZigBee plans further integration of Internet Protocol
standards”, April 2009.
6LoWPAN and LLN Application Protocols”, draft-bormann-6lowpan6lowapp-problem-01, IETF Internet draft, (Work in progress) July 2009 .
[13] N. Kushalnagar, G. Montenegro, C. Schumacher, “IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement and Goals”, RFC 4919, August 2007.
[14] S. Deering, R. Hinden. “Internet protocol, version 6 (ipv6) specification”,
RFC 2460, December 1998.
348
6/9/10
10:17
Página 349
[15] G. Tolle. “A UDP/IP Adaptation of the ZigBee Application Protocol”;
draft-tolle-cap-00, IETF Internet Draft, (Work in progress) October 2008.
[16] 3rd Generation Partnership Project 3GPP, TS 23.228 V8.1.0: IP
Multimedia Subsystems (IMS); Stage 2. June 2007.
[17] A. Gluhak, W. Schott, “A WSN System Architecture to Capture Context
Information for beyond 3G Communication Systems”, 3rd Intelligent
Sensors, Sensor Networks and Information Processing (ISSNIP) conference, Melbourne, Australia, December 2007.
[18] D. Das, “Exploring Integration of Sensor Applications with IMS”,
International Conference on IP Multimedia Subsystems, Architecture
and Applications (IMSAA), Bangalore, India, December 2007.
[19] M. El Barachi, A. Kadiwal, R. Glitho, F. Khendek, R. Dssouli, “A Presence
based Architecture for the Integration of the Sensing Capabilities of
Wireless Sensor Networks in the IP Multimedia Subsystem”, Wireless
Communications and Networking Conference 2008 (WCNC' 08), Las
Vegas, USA April 2008.
[20] S. Tomic, P. Todorova. “SIP meets ZigBee”, Mobile and Wireless
Communications Summit, 2007. 16th IST, Budapest, Hungary, July
2007.
[21] D. Sturek, “ZigBee IP Stack Overview”, ZigBee Alliance, 2009.
[22] S. Tomic, P. Todorova. “SIP meets ZigBee”, Mobile and Wireless
Communications Summit. 16th IST, 2007.
[23] S. Krishnamurthy, “TinySIP: Providing Seamless Access to Sensor-based
Services”, Mobile and Ubiquitous Systems - Workshops, 2006. 3rd
Annual International Conference, pp.1-9, July 2006.
[24] A. Hornsby, P. Belimpasakis, I. Defee, “XMPP-based wireless sensor network and its integration into the extended home environment”,
Consumer Electronics, 2009. ISCE '09. IEEE 13th International
Symposium on, pp. 794-797, 2009.
[25] C. Pastrone , M. A. Spirito, R. Tomasi, F. Rizzo, “Jabber-based management framework for heterogeneous sensor network applications”,
349
6/9/10
10:17
Página 350
Sensors Everywhere
International Journal of Software Engineering and Its Applications, Vol.
2, No. 3, pp. 9 – 24, July, 2008.
[26] A. Hornsby, E. Bail, “micro-XMPP: Lightweight Implementation for Low
Power Operating System Contiki”, SASN '09, The International
Workshop on Scalable Ad Hoc and Sensor Networks, Saint Petersburg
(Russia), October 2009.
[27] OpenSpime architecture definition.
http://openspime.org/files/openspime_architecture.pdf
[28] Pachube Web site: http://www.pachube.com/
[29] EEML Web site: http://www.eeml.org/
[30] U. Hunkeler, H. Linh Truong, A. Stanford-Clark, “MQTT-S - A publish–
/subscribe protocol for Wireless Sensor Networks”, Communication
Systems Software and Middleware and Workshops, 2008. COMSWARE
2008. 3rd International Conference on. Bangalore (India), pp. 791 –
798, Jan. 2008.
[31] F. J. Molina, J. Barbancho, J. Luque, “Automated Meter Reading and
SCADA Application for Wireless Sensor Network”, Ad-Hoc, Mobile, and
Wireless Networks, Springer. Vol. 2865. pp. 223 – 234, 2003
[32] B. Xingzhen, M. Xiangzhong, D. Zhaowen, G. Maofa, H. Zhiguo, “Design
of Wireless Sensor Network in SCADA system for wind power plant”,
Automation and Logistics, 2008. ICAL 2008. IEEE International
Conference on, pp. 3023-3027, Sept. 2008.
[33] C. Amarawardhana, K. S. Dayananada, H. Porawagama, C. Gamage,
“Case study of WSN as a replacement for SCADA,’’ Industrial and
Information Systems (ICIIS), 2009 International Conference on,
pp. 49-54, Dec. 2009.
[34] http://xmpp.org/extensions/
[35] A. Stanford-Clark, H. Linh Truong, “MQTT For Sensor Networks (MQTTS) Protocol Specification Version 1.1 August 18, 2008. Available at:
http://mqtt.org/MQTT-S_spec_v1.1.pdf
350
6/9/10
10:17
Página 351
[36] P. Saint-Andre, “Streaming XML with Jabber/XMPP”, IEEE Internet
Computing, Vol. 9, No. 5, pp. 82-89.
[37] P. Saint-Andre, “RFC: 3920. Extensible Messaging and Presence
Protocol (XMPP): Core”, http://www.ietf.org/rfc/rfc3920.txt
[38] R. T. Fielding, R. N. Taylor. “Principled design of the modern Web architecture”. Proceedings of the 2000 International Conference on
Software Engineering (ICSE 2000), Limerick, Ireland, June 2000, pp.
407–416.
[39] Z. Shelby, M. Garrison Stuber, D. Sturek, B. Frank, R. Kelsey. “CoAP
Feature Analysis”, http://tools.ietf.org/html/draft-shelby-6lowappcoap-01. IETF Internet Draft (Work in progress) April 2010.
[40] T. Luckenbach, P. Gober, S. Arbanowski, A. Kotsopoulos, K. Kim. “Tinyrest
- a protocol for integrating sensor networks into the Internet”,
Stockholm, Sweden, 2005.
[41] C. Pautasso, O. Zimmermann, F. Leymann, “RESTful Web services vs.
"big" Web services: making the right architectural decision”, in proceedings of the 17th international conference on World Wide Web. (WWW
'08) ACM, 2008.
[42] D. Guinard, V. Trifa, T. Pham, and O. Liechti, “Towards Physical Mashups
in the Web of Things,” in Proceedings of the 6th International
Conference on Networked Sensing Systems (INSS 2009), 2009.
[43] Y. Kim, Y.-S. Jeong, J.-H. Hwang, K.-J. Lee, R. S. Tolentino, S.-H. Lee, G.-C.
Park, "A Design and Implementation of USN-Based Mobile Web
Services Framework," Future Generation Communication and
Networking, Second International Conference on Future Generation
Communication and Networking, pp. 19-23, 2008.
[44] S. Duquennoy, G. Grimaud, J.-J. Vandewalle, “The Web of Things: interconnecting devices with high usability and performance,” in 6th
International Conference on Embedded Software and Systems
(ICESS’09), Hangzhou, Zhejiang, China, May 2009.
351
6/9/10
10:17
Página 352
6/9/10
10:17
Página 353
14
Energy consumption
and harvesting
6/9/10
10:17
Página 354
6/9/10
10:17
Página 355
Chapter 14. Energy consumption and harvesting
14. Energy consumption and harvesting
At present, a key aspect for a full deployment of a WSN is power consumption and the corresponding power supply. Traditional solutions based
on connectivity to the power supply network or the usage of batteries are
feasible for some limited set of possible usages. For a wide acceptance of
WSNs, the power supply lifetime should be identical to the sensor node lifetime. Once a sensor node is deployed it should work unattended, while battery replacement may not be practical or feasible. Considering the energy
constraint as a key performance parameter results in a new set of crosslayer design considerations different to those found in traditional networks.
Significant efforts have been made to reduce energy consumption by
redesigning the communication paradigms and by improving the efficiency
of circuits. The technology trend in this area is based in reducing the voltage,
making circuits able to work at different clock frequencies and using analogue circuits to perform some parts of the radio processing. However, the
use of batteries as the only source of energy may not be sufficient. There are
several cases where alternative sources of energy can be used. The most
common one is solar energy, but other sources such as movement, pressure
or even differences of temperature can be used to provide energy for feeding very low power sensors.
This chapter is devoted to energy consumption and harvesting or scavenging for WSNs. Section 14.1 presents an energy consumption model for
WSNs, which includes a description of the energy consumed by data communication and data processing. Section 14.2 presents the range of power
sources available for sensor networks.
355
6/9/10
10:17
Página 356
Sensors Everywhere
14.1.
Energy consumption model
Power consumption in a sensor network can be divided into three
domains: communication, data processing and sensing. This section focuses
on the first two domains, since sensing depends greatly on the particular
sensing application and platform.
14.1.1. Power consumption for data communication
Communication is the dominant factor for energy consumption in WSNs.
A model that describes power consumption for communication is shown
next [1]. The parameters in the left column of Table 14.1 should be defined
in accordance with the descriptions in the right column of the same table.
Parameter
Pc
Pte
Pre
Po
Ton
Ron
Tst
Rst
NT
NR
Definition
Power consumed in communications
Power consumed by transmitter
Power consumed by receiver
Output power of transmitter
Transmitter “on” time
Receiver “on” time
Start-up time for transmitter
Start-up time for receiver
Number of times transmitter is switched on per unit of time
Number of times receiver is switched on per unit of time
data communications
An expression for the power consumption due to data communications
of a sensor is as follows [1]:
Pc = NT • (Pte • (Ton + Tst ) + Po • Ton) + NR • (Pre • ( Ron + Rst ))
356
(8)
6/9/10
10:17
Página 357
where Ton is obtained as the ratio of the length of the data unit transmitted (L) and the data rate at which the data is transmitted (R):
Ton = L / R
(9)
Note that the power consumed depends linearly on the frequency of
transmitter switch on (NT) and receiver switch on (NR). The values of these
parameters actually depend on MAC and application layers.
Furthermore, start-up times are necessary to ramp up phase locked
loops or voltage controlled oscillators. During start-up time, no data
transmission or reception is possible. The start-up time dominates
power consumption when data units are short. To minimize power consumption, the MAC protocol used must take the start-up times into
account, maintaining the transceiver in a sleep mode as long as possible, but also taking into consideration that turning the transceiver on
and off also consumes energy to prepare it for transmission or reception.
Finally, Pre is typically greater than Pte since more circuitry is required to receive a signal. Table 14.2 shows details on the current consumption of a range of WSN chips on the market [2]. Note that in most
cases, reception current consumption is equal to or greater than that of
transmission53. The power consumed when transmitting depends significantly on the transmission power. An IEEE 802.15.4 radio interface
consumes 25 mA at 3.3 V for a transmitted power of 1 mW, and increases up to 150 mA for transmitted power up to 100 mW. On the
other hand, typical consumption of idle states is in the order of
microAmperes [3].
53
Note that the transmission current depends on the transmission power used.
357
6/9/10
10:17
Página 358
Sensors Everywhere
Corporation RF module Sensitivity Rx current,
Description
(dBm)
Tx current (mA)
Texas
Instruments
Freescale
Radio Pulse
Ember
Jennic
OKI
Nanotron
ZenSys
CC2420
CC243x
MC1319x
MC132x
MG2400
EM250
JN513x
ML7222
NA5TR1
ZW0201
- 95
- 94
- 92
- 92
- 99
- 97.5
- 97
- 90
- 95
- 101
19, 17.4
27, 25
37, 30
38, 31
26, 33
35.5, 35.5
39, 39
26, 24
27, 23
21, 23
Transceiver
SoC, 8051 CPU
Transceiver
SiP, HCS08
SoC, 8051 CPU
SoC, 16bit CPU
SoC, 32bit CPU
SoC, 8bit CPU
IEEE 802.15.4a
Z-Wave
Table 14.2. Characteristics of WSN chips [2]
14.1.2. Power consumption in data processing
A model for describing the power consumed in data processing operations in the StrongARM SA-1100 processor is presented in [4]. Table 14.3
provides a definition of the parameters involved in the model, which is
expressed by the following equation:
2
Pp = N• C • Vdd + Vdd • (Io e v
Parameter
Pp
N
C
Vdd
VT
n
Io
f
dd /
) (N / f)
n vT
(10)
Definition
Power consumed in processing
Number of clock cycles per task
Average capacitance switched per cycle
Supply voltage
Thermal voltage
Value equal to 21.26
1.196 mA
switching frequency
data processing
358
6/9/10
10:18
Página 359
The second term of equation (10) indicates the power loss due to leakage currents between power and ground [4].
Besides data processing, memory power consumption may be another
contributor to energy consumption. While power for RAM is almost negligible, Flash memory writing and erasing is expensive. For example, in
Crossbow MICA motes, reading and writing consume 1.1 nAh per byte and
83.3 nAh per byte, respectively.
14.1.3. Power consumption modes
A key technique in power consumption minimization in WSNs is to keep
sensor nodes at low power consumption modes when no activity requires
them to be at full operation. Some typical consumption modes of microcontrollers include ‘active’, ‘idle’ and ‘sleep’ modes. Regarding the radio, ‘on’ and
‘off’ states apply for the transmitter, the receiver, or both.
However, multiple consumption modes may exist, depending on the
hardware platform under consideration [5]. For instance, Texas Instruments
MSP 430 defines four different sleep modes. ATMEL ATMega defines up to
six modes. Different modes generally correspond to different parts of chip
that can be switched off (timers, interruptions, etc.). Some modes lead to
loss of part of the data stored in the RAM.
14.1.4. Communication vs. computation energy consumption
While it is difficult to perform a strict comparison between communication and computation energy consumption of a sensor node, several
attempts leading to reference results are available in the literature. In particular, the energy ratio of “sending one bit” vs. “computing one instruction”
has been found in the literature to be between 220 and 2900 [5]. According
to these figures, communicating (i.e. sending and receiving) one kilobyte
consumes as much energy as computing three million instructions. This is a
trend followed by new devices that show significant improvement in Million
Instructions Per Second (MIPS) and small reduction in the transmitting
power (up to an half).
359
6/9/10
10:18
Página 360
Sensors Everywhere
In consequence, in-network processing techniques are a must in sensor
networks: computation should be given as much priority as possible over
communication for the sake of energy efficiency. In particular, local data
processing is crucial in minimizing power consumption in multi-hop WSNs.
14.2.
Power sources for sensor networks
Power sources for sensor networks can be classified into two categories:
i) energy reservoirs and ii) energy scavenging methods. Some of the most
relevant technologies of each category are presented below.
14.2.1. Energy reservoirs
Since it is difficult to ensure a constant power source capable of attending to the instantaneous demand from the sensor node circuit, a power
storage element is recommended. This can be built based on a battery or a
capacitor. Since conventional capacitors offer a very limited capacity,
enhanced capacitors, known as super-capacitors or ultra-capacitors, have
appeared on the market in recent years. Batteries and capacitors offer different performance and can be used individually for specific scenarios or
even combined as hybrid solutions.
14.2.1.1. Primary and secondary batteries
Macro- and micro-scale electrochemical batteries have been the dominant form of power storage and delivery for electronic devices over the past
100 years. They can be considered for use as primary or secondary (i.e.
rechargeable) batteries. They have a fairly stable voltage, which precludes
the extra power consumption required by power supply conditioning electronics. Table 14.4 and Table 14.5 show the energy density of three primary
and secondary battery chemistries, respectively. Zinc-air batteries have the
highest energy density among the chemistries considered, but they have a
very short lifetime in comparison with Lithium or Alkaline batteries.
360
6/9/10
10:18
Página 361
Chemistry
Zinc-air
Lithium
Alkaline
Energy (J/cm3)
3780
2880
1200
Table 14.4. Energy density of three primary battery chemistries
Chemistry
NiMH
(Nickel Metal Hydride)
NiCd (Nickel Cadmium)
Energy (J/cm3)
1080
860
650
Table 14.5. Energy density of three secondary battery chemistries
Batteries are the dominant technology for powering sensor nodes.
Alkaline battery nominal shelf life is 5 years. Long life batteries can last 20
years, but they offer a voltage range from 5 to 2 Volt. Most of the sensor
node chips do not support this voltage range, so the real sensor lifetime will
be significantly shorter. In fact, the capacity of a battery is estimated by
using a model that assumes an idealized current. In a practical situation, the
sensor node voltage range is smaller than that provided by the battery, and
the current required is bursty with peaks over-passing the ideal discharge
current. The practical result is a shorter battery lifetime compared to the
theoretical one.
All batteries suffer from a self-discharge effect. Primary batteries can lose
between 8% and 20% of their capacity per year, even if they are not connected to any device. Secondary batteries lose capacity at a higher rate. For
this reason, these types of batteries may limit the application lifetime without human intervention for battery replacement. The number of times a
battery can be recharged depends on the technology. Low capacity Nickel
Metal Hydride (NiMH) batteries can be recharged 1000 times, while high
capacity ones can only be recharged 500 times.
Hydrocarbon based micro-fuel cells have very high energy densities
compared to batteries. Hence, these cells could potentially be very attractive for sensor nodes requiring high power outputs for limited periods of
time. One drawback, however, is the high temperatures at which energy
conversion must take place and the volume of the conversion mechanism
361
6/9/10
10:18
Página 362
Sensors Everywhere
[6]. On the other hand, current prototypes are bulky. Nevertheless, it has
been claimed that the energy density of fuel cells is ten times the energy
density of comparably sized lithium-ion batteries [16]. Another problem with
micro-fuel cells is that they are based on the use of inflammable substances, which poses risks and hazards.
14.2.1.2. Ultra-capacitors
Ultra-capacitors store ionic charge in an electric double layer to increase
their effective capacitance. Because of their increased lifetimes, short charging times, and high power densities, ultra-capacitors could be very attractive for some WSN applications [6]. However, ultra-capacitors currently suffer
from drain currents that make them unsuitable for long lifetime applications.
Fig. 14.1 shows an ultra-capacitor used in a module for WSNs.
Fig. 14.1. Illustration of an energy harvesting and storage module that
uses an ultra-capacitor [17]
Super-capacitors can be used when the power source is unpredictable,
such as when power harvesting methods are used.
14.2.2. Energy harvesting
Extracting energy from the environment and subsequently storing it for
a later use is known as energy harvesting or energy scavenging. This approach is attracting more interest as low power devices are become more
common. This type of power source suffers from low, variable and unpredictable levels of available power. Because of these characteristics, energy har-
362
6/9/10
10:18
Página 363
vesting is typically used in conjunction with secondary batteries that may
supply energy when scavenging energy is not possible. The sources from
which energy can be harvested include ambient light, mechanical energy
(movement, vibration and pressure), temperature gradients, wind flows and
ambient electromagnetic (radiofrequency) radiation.
One example of a self-powered wireless sensors solution collecting and
saving energy from a wide set of ambient sources is provided by EnOcean
[19]. This system makes use of energy created from slight changes in
motion, light, temperature, rotation or vibration.
14.2.2.1. Photovoltaic cells
Photovoltaic technologies are commonly used to charge secondary batteries. The power density of the incident sunlight at noon on a sunny day is
roughly 100 mW/cm3. Some silicon solar cells exhibit efficiencies of up to
20% [6]. Fig. 14.2 shows an example of a node that uses photovoltaic cells.
Fig. 14.2. A node that uses photovoltaic cells
14.2.2.2. Vibration
Several researchers have developed devices to scavenge power from
vibrations. Although the power signal obtained from vibrations requires significant conditioning to be useful in electronics, low level mechanical vibra-
363
6/9/10
10:18
Página 364
Sensors Everywhere
tions are present in many environments and can provide on the order of
hundreds of microwatts per cubic centimetre, which is quite competitive
compared to other power scavenging sources. There are three methods to
produce energy with vibrational harvesters: electromagnetic (inductive)
ones, electrostatic (capacitive) ones and piezoelectric ones. Current products are bulky and expensive [7, 8, 9] (see Fig. 14.3) and those based on piezoelectric effect exhibit a short life. Additionally, they should be tuned to the
vibration frequency for maximum performance.
Fig. 14.3. Example of energy harvesting using vibration
14.2.2.3. Temperature gradients
Energy can be scavenged from the environment when temperature
variations occur. The efficiency of power conversion is proportional to the
temperature variation. The power available is modest; a micro-engineered
device reported below 1 µW/cm3 for a difference of temperature of 10º K
[11]. The main difficulty of the technology when applied to sensor nodes is
the small size of the devices, which makes it difficult to obtain a significant
thermal gradient. Nevertheless, a thermal harvesting platform that has been
demonstrated to drive an IEEE 802.15.4 node is shown below ( Fig. 14.4).
364
6/9/10
10:18
Página 365
Fig. 14.4. Thermal harvesting platform able to drive an IEEE 802.15.4
sensor node with a thermal difference of 3.5º K [12]
14.2.2.4. Wind flows
The potential power from moving air is proportional to v3, where v is the
speed of the air. This seems to be a good option for several applications
where wind can be exploited. However, wind energy harvesters are bulky
and typically exhibit lower energy conversion efficiency than solar ones [13].
An example of a wind energy harvester is shown in Fig. 14.5.
Fig. 14.5. A system that harvests from wind energy
365
6/9/10
10:18
Página 366
Sensors Everywhere
14.2.2.5. Electromagnetic radiation
This energy harvesting method is based on the use of existing ambient
electromagnetic radiation available in the spectrum and generated for a different purpose than that of feeding the device. Energy densities of 0.1 µW/cm2
and 1 µW/cm2 have been reported for GSM and WiFi signal radiation, respectively [18]. On the other hand, the most widely used power distribution method for embedded devices (besides wires) is RF radiation. Many passive devices
such as RFID tags and smart tags are powered by an energy source that transmits RF energy to the passive device [10]. Such power supply requires the use
of infrastructure, and the supply source should also be supplied with power.
This approach leads to the concept of Wireless Passive Sensor Networks
(WPSNs), whereby the energy for sensor nodes is supplied via RF from an
external source [14]. One advantage of this scheme when compared with
other energy harvesting methods (which mainly rely on unpredictable
ambient energy sources) is the fact that power supply can be controlled.
Fig. 14.6 shows a device that supplies power to sensor nodes via RF.
Fig. 14.6. RF power transmitter by Powercast [15]
REFERENCES
[1] E. Shih et al., “Physical Layer Driven Protocols and Algorithm Design for
Energy-Efficient Wireless Sensor Networks”, ACM Mobicom, Rome,
Italy, July 2001.
366
6/9/10
10:18
Página 367
[2] Z. Pei, Z. Deng, B. Yang, X. Chang, “Application-Oriented Wireless Sensor
Network Communication Protocols and Hardware Platforms: a Survey”,
IEEE International Conference on Industrial Technology, Chengdu,
China, April 2008.
[3] “Measuring power consumption with CC2430 and Z-stack”,
Application Note 053, Texas Instruments.
[4] Wang, A. Chandrakarasan, “Energy Efficient DSPs for Wireless Sensor
Networks”, IEEE Signal Processing Magazine, July 2002.
[5]
I.F. Akyildiz, “Wireless Sensor Networks”, 2007. Website:
http://www.ece.gatech.edu/research/labs/bwn/ee8863/ece8863.html
[6] H. Karl et al., “Power Sources for Wireless Sensor Networks”, European
Workshop on Wireless Sensor Networks (EWSN) 2004.
[7] KCF Technologies. Vibration Power Harvesting for Wireless Sensors.
http://www.kcftech.com/research/wireless_sensors.shtml.
[8] MIDE Piezoelectric Energy Harvesters. http://www.mide.com/products/volture/volture_catalog.php
[9] Perpetuum (Vibration Power Harvesting). Website: http://www.perpetuum.co.uk
[10] D. Friedman, H. Heinrich, D.-W. Duan, “A Low-Power CMOS Integrated
Circuit for Field-Powered Radio Frequency Identification”, IEEE SolidState Circuits Conference, 1997.
[11] M. Strasser et al. “Miniaturized thermoelectric generators based on
poly-Si and poly-SiGe surface micromachining”, Sensors & Actuators,
2002.
[12] Jennic Wireless Microcontrollers. Applications. Thermal Energy Harvesting.
http://www.jennic.com/applications/thermal_energy_harvesting.
[13] S. Sudevalayam, P. Kulkarni, “Energy Harvesting Sensor Nodes: Survey
and Implications”, Technical Report, December 2008.
[14] O. B. Akan, M. T. Isik, B. Baykal, “Wireless Passive Sensor Networks”, IEEE
Communications Magazine, August 2009.
367
6/9/10
10:18
Página 368
Sensors Everywhere
[15] http://www.powercastco.com/
[16] http://www.reghardware.co.uk/2008/10/08/toshiba_restates_–
fuel_cell_goal/
[17] EasySen website: http://www.easysen.com/products.htm
[18] M. Raju, “ULP meets energy harvesting: A game-changing combination
for design engineers”, Texas Instruments, 2008.
[19] http://www.enocean.com
368
6/9/10
10:18
Página 369
15
Localization techniques
and wireless sensor
networks
6/9/10
10:18
Página 370
6/9/10
10:18
Página 371
Chapter 15. Localization techniques and wireless sensor networks
15. Localization techniques and
A sensor node is capable of obtaining one or more physical magnitudes
such as the temperature or humidity of a certain place. This value has to be
interpreted, either at the moment in which it is captured or later. In either
case, the more information about the context of the measurement, the better will be the interpretation of the measurement. For example, if the measurements are taken by close sensor nodes, the measurements may be
correlated to reinforce the sensed data, to eliminate faulty sensor nodes or
to identify an estrange event (for example an increase in the temperature in
one sensor can identify a localised fire). Location itself can be considered
one of the most important context parameters to improve the usage of
sensed data. In fact, the location of a node can constitute a sensed parameter. A sensor node can be used to provide location to other sensed physical
variables, but also location can used to provide location to objects or persons carrying the sensor node or being sensed.
Location can either be physical (e.g. geographic coordinates, distance,
etc.) or logical (e.g. the third floor of the C3 building, a campus, etc.). Logical
location is more useful and, commonly, location applications derive logical
locations from physical ones. In order to know the location of a node, there
must exist a reference. If the reference is absolute, the location that can be
derived will be absolute. Otherwise, the location obtained will be a relative
parameter. One of most popular physical location techniques is based on
the GPS system. However, it is not an adequate solution for certain type of
WSNs applications because it is inaccurate (i.e. it exhibits higher error than
371
6/9/10
10:18
Página 372
Sensors Everywhere
required), it cannot work indoors and it is power-hungry. The last limitation
is disappearing as ultra low power receivers are being introduced in the market [1].
Location can be obtained by proximity, positioning or fingerprinting
methods [2, 3]. Proximity relies on relating the node location with that of its
closest reference or a set or close references. Positioning aims at determining the coordinates of the object. For this purpose, measurement of distance, angle or a combination of both can be used. Three-dimensional
location requires three of these magnitudes (see Fig. 15.1 for examples of
positioning). Fingerprinting is based on relating signal patterns to locations.
Fig. 15.1. Positioning using a) three distances (trilateralization), b) three
angles (triangularization) and c) mixing measures of distance and angle
The types of signals used in location are radio, infrared and ultrasound
signals. Radio signals are available from the communications interface, while
the other ones have to be transmitted and received on purpose.
372
6/9/10
10:18
Página 373
Sections 15.1, 15.2 and 15.3 are devoted to the description of proximity,
positioning and fingerprinting methods respectively.
15.1.
Proximity location
The simplest location approach is based on receiving reference signals
and deciding the reference to which the signal with highest strength is received. The location of the node is the one of the reference. The signals used
for this purpose are radio and infrared signals. As an infrared signal is not
able to go across walls, this type of signal is used to assure the node is inside
a room. The usage of radio signals in indoor environments has to pay special attention to two physical phenomena . The first one is the propagation
of the signal across walls and ceilings, and the second one is the relation
between signal strength and distance. Depending on the gain of the antennas (of both receiver and transmitter) and the effect on the surroundings
(i.e obstacles, reflections), the received signal presents different signal
strengths for locations at the same distance. With this uncertainty, it is difficult to map signal strength to distance, and as a consequence with proximity.
It is possible to combine more than one close reference to improve the
precision in the location of a person of object by these type of system. For
example, with three close references the location can be approximated by
the center of mass or barycenter of the triangle defined by the three references (see figure 15.2).
Fig. 15.2. Location estimation based on the proximity criteria and using
the three strongest signals
373
6/9/10
10:18
Página 374
Sensors Everywhere
15.2.
Positioning
Location by positioning is done using distances, angles or a combination
of both. The usage of three distances is known as trilateralisation and the
usage of three angles is known as triangularisation. As measured distances
and angles have errors, it is quite common to use more than three signals to
compensate errors using a multilateralisation. Fig. 15.3 gives an example of
zone error when trilateralization is done with erroneous distances.
Fig. 15.3. Representation of the error area in a trilateralization with
distances erroneously measured
When using measures with error is quite common to employ a mean
least square algorithm to provide an estimated location.
Measuring distances is done mainly performed by using radio and ultrasound signals. It is easy to measure absolute times or differences of times
(by taking advantage of the sensor nodes clocks) with ultrasound signals, as
they are characterized by a low propagation speed, equal to 330 m/s. These
times can be converted into reception angles and distances, which in turn
374
6/9/10
10:18
Página 375
can be combined to offer the position with regard to references. Ultrasound
signals cannot penetrate walls, their maximum range is typically fifteen
meters and transmitters are quite directive. Location by using ultrasound
signals requires the presence of at least three references per room.
However, they offer centimeter precision.
The measurement of the propagation time is commonly done with the
help of a radio signal that is used to synchronize transmitter and receiver.
The ultrasound transmitter sends an ultrasound pulse and a radio signal
towards its neighbours at the same time. As the propagation time for radio
signals can be neglected in comparison to the employed by ultrasounds and
also the short distances involved (several meters), the radio signal triggers a
timer at the receivers that will count the time employed by the ultrasound
signal to reach each neighbour node. This approach is used by systems like
Cricket [4]-[6], which is shown in Fig. 15.4.
Fig. 15.4. Cricket node
The directivity of the ultrasound transmitters and receivers with aperture
angles from 30º to 60º is solved in some systems using different receivers
and transmitters pointing to different directions. Systems such the one proposed in [7] use this solution.
Ultrasound receiver and transmitter can be integrated in the same device, but it is more common to used separate devices for each purpose.
Fig 15.5 shows an ultrasound device with separated transmitter and receiver.
375
6/9/10
10:19
Página 376
Sensors Everywhere
Fig. 15.5. Ultrasound ranger (to measure distances) with separated
transmitter and receiver
When using narrowband radio signals, such as IEEE 802.15.4 ones, to
measure distance, the most common approach is to use the relationship
between attenuation and distance to estimate the distance from a reference. Commonly, this approach is also called RSSI-based. With three
measurements of distance to a reference, a position can be calculated.
Because there are phenomena, in addition to distance, that affect signal propagation (see Chapter 3), distance estimation may be affected by errors of
several meters if correction techniques are not applied. The Texas
Instruments CC2431 chip provides software implementing this approach [8].
The RSSI based method can be used with short distances (several meters).
When a larger range is required the precision degrades. There exists an IC
from Jennic, the JN5148 [9] that offers a function for the measurement of
the time of flight of the signal radio. The manufacturer claims the solution
can be used as a complement to the RSSI method for larger ranges.
In order to obtain distance measurements based on the time of flight
with centimeter precision, the IEEE 802.15.4a specification was developed,
but at the time of writing this book, DecaWave announces a product [10]
which is not commercialised.
When the number of references required is not available, it is possible to
use mutual or derived location (also called multi–hop location in contrast to
376
6/9/10
10:19
Página 377
the presented location approaches classified as a one hop). This approach
aims at finding the location of a number of sensor nodes based on a limited
number of references and the relative locations that the nodes obtain
among them. There exist several algorithms (see section 6 of [3]) that implement this technique, but they are too complex for sensor node capabilities.
15.3.
Fingerpinting
Location by patterns, also known as fingerprinting, mainly uses radio signals, but the method can be used for any type of signal. It is based on a number of references which transmit different signals (generally at different frequencies) which cover the space where location has to be carried out.
Transmitters have to be placed in such a way that any place where a node can
be located should receive the signals from different references. Systems using
this method require a two phased procedure. In a first phase, the system has
to be trained by creating a data base that includes the locations and signals
received in a given point. This requires to take measurements at any place a
node should be located, as well as to inform manually about the location associated with this set of measures. After this phase, the device to be located
must continuously measure the reference signals and reports the signal levels
to a central element. This element will search for similarities between the
reported measurements and the ones stored in the data base for several positions. The location assigned to the object will be the one that has the measurements stored in the data base most similar to the current measurements.
The accuracy of this method depends on the calibration carried out and
the number of reference signals. If the environment of radio propagation
suffers changes, the location system must be calibrated again. Existing systems offer precision of various meters.
REFERENCES
[1] Vicontech GPS receiver.
http://www.vincotech.com/download/file/gps/products/A1084-AB.pdf
377
6/9/10
10:19
Página 378
Sensors Everywhere
[2] A. Boukerche, H.A.B.F. Oliveira, E.F. Nakamura, A.A. Loureiro,
“Localization systems for wireless sensor networks”, IEEE Wireless
Communications – Special Issue on Wireless Sensor Networks Vol. 14,
2007, pp. 6–12.
[3] G. Mao, B. Fidan, B. D. Anderson, “Wireless sensor network localization
techniques”. Comput. Netw. Vol. 51, No 10, Jul. 2007, pp. 2529-2553..
[4] H. Balakrishnan, R. Baliga, D. Curtis, M. Goraczko, A. Miu, B. Priyantha, A.
Smith, K. Steele, S. Teller, and K. Wang, “Lessons from developing and
deploying the Cricket indoor location system” MIT Computer Science
and Artificial Intelligence Laboratory (CSAIL), 2003.
[5] N. B. Priyantha, A. Chakraborty, H. Balakrishnan, “The cricket locationsupport system,” in MobiCom ’00: Proceedings of the 6th annual international conference on Mobile computing and networking, (New York,
NY, USA), pp. 32–43, ACM, 2000.
[6] Harry S. Sameshima, Edward P. Katz, Experiences with
Cricket/Ultrasound Technology for 3-Dimensional Locationing within
an Indoor Smart Environment, 2009.
[7] A. Nishitani, Y. Nishida, and H. Mizoguch, “Omnidirectional ultrasonic
location sensor,” IEEE Sensors, Oct. 30, Nov. 3, 2005, pp. 684 - 697.
[8]
cc2431 datasheet, http://focus.ti.com/lit/ds/symlink/cc2431.pdf
[9] JN5148 datasheet:
http://www.jennic.com/files/product_briefs/JN-DS-JN5148-1v2.pdf
[10] DecaWave ScenSor datasheet:
http://www.decawave.com/pdfs/D0801004DS5_ProductBrief.pdf
378
6/9/10
10:19
Página 379
16
Middleware
6/9/10
10:19
Página 380
6/9/10
10:19
Página 381
Chapter 16. Middleware
16. Middleware
WSN middleware can be defined as a software entity which uses several
communications and functional mechanisms, such as the ones described
throughout this book, to facilitate the communication and coordination of
distributed components in order to offer good service and correct operation
to the applications running on top of a WSN. Therefore, middleware deals
with management functionality (e.g. self-management, self-configuration),
network reliability, quality of service, data management, energy management, etc. In short, middleware facilitates the development, maintenance,
deployment and execution of WSN applications.
This chapter presents the current state of the art of middleware for
WSNs. The contents are organized as follows: Section 16.1 points out the
main differences between middleware for WSNs and middleware for
traditional environments; Section 16.2 describes the components of a
generic middleware solution for WSNs; Section 16.3 presents the main
middleware system services; Section 16.4 shows examples of middleware
solutions for WSNs and finally, Section 16.5 discusses the current status of
middleware for WSNs.
16.1. Middleware for WSNs vs. middleware for traditional
environments
As previously explained (e.g. see Chapter 1), a WSN is a distributed system composed of nodes with limited resources (e.g. memory, processing
power, link rate and battery). Programming such a network efficiently re-
381
6/9/10
10:19
Página 382
Sensors Everywhere
quires low level programming, which may be very complex. To deal with of
this situation, new paradigms and tools have been developed by means of
adding middleware software infrastructure, which constitutes the most
common solution to facilitate the execution for a wide set of sensor applications on top of a wide set of heterogeneous underlying hardware platforms.
Thus, middleware in distributed systems (like a WSN) lies between the operating system and applications running on each node of the system, but
also covers any device, network, database or application development
framework connected to the WSN. This type of software has been compared
to a “glue” that joins hardware, operating systems, network stacks and applications [1].
Middleware research is a well known topic in traditional computing environments. However, it is quite new in the area of WSNs and exhibits several
key differences from the traditional middleware. Some of them are as
follows:
Traditional middleware tries to hide context information to make an
application independent of the scenario where it is used. WSNs constitute
the opposite case, since applications usually require context-awareness.
Mobile computing middleware is focused on facilitating applications running in the terminal, with the aim of maximizing the interests of the user. In
WSNs, the objective is to facilitate the development of sensor based applications, which can be consumed anywhere, and from which the generated
data need to be collected and processed, so a whole network should be
optimised.
Traditional middleware is focused on the end-to-end paradigm of the
Internet54 . In WSNs, it is assumed that sensor nodes, sink nodes or gateways
might have a relevant role in the communication; therefore the middleware
needs to adapt the different functions of these nodes.
Middleware in WSNs should be light due to the limited resources of the
nodes. This is not the general case in traditional middleware.
54
According to the end-to end paradigm, communications protocol entities should be placed at the end-points of a communications system.
382
6/9/10
10:19
Página 383
In the recent years, several researchers have tried to give a general
view of middleware for WSNs [1, 2, 3, 4, 5], but they provide only partial
views (system architecture, programming paradigms and run-time support, etc.) and hence do not cover all aspects. The problem is probably
related with the availability of different middleware proposals for different
specific applications, and the close relationship between application,
middleware and WSN. This situation makes it difficult to state which components should be present in a middleware solution. The only valid
approach is to take a general view, in the knowledge that in a real implementation only the required components and the most efficient approach should be used.
16.2.
Components of a generic middleware solution for WSNs
Middleware functions can be located in different places, either individually or in a distributed approach, such as sensor nodes, sink nodes, high
level application terminal, etc.
A complete middleware solution should at least include the following
four components:
• Programming abstraction: this defines the interfaces to the middleware
for the application programmer.
• System services: implemented functions to enable programming abstractions.
• Run time support: extensions to the embedded operating system to
support middleware services.
• QoS mechanisms: they define the QoS constraints of the system.
16.2.1. Programming abstractions
A WSN should be offered to the application programmer through the
middleware. The way the programmer views the system is referred to as the
abstraction level. The model used to program the application is known as
383
6/9/10
10:19
Página 384
Sensors Everywhere
the programming paradigm. Finally, the programming interface used corresponds to the mechanism used by the application to access the middleware functions.
16.2.1.1. Abstraction level
The system can be seen at different levels, offering more or less insight
into the WSN, as for example:
Local (i.e. node level abstraction): this allows the individual node to be
reached and presents the system as a collection of distributed nodes. This
approach is useful for building efficient communications between nodes
and is flexible, depending on the application. One disadvantage is that it
requires certain knowledge of the sensor node from the programmer.
Global (i.e. system level abstraction): this abstracts the WSN as a single
virtual system and allows the single centralized program to be expressed
into subprograms that can be executed on local nodes. It also allows the
programmer to concentrate on the application, while avoiding the details of
the nodes. Applications might prove to be less efficient in terms of resources consumed in the WSN.
16.2.1.2. Programming paradigms
Programming depends on the application to be carried out by the WSN.
Since some of the most widely used applications are related to data collection, the WSN can be seen as a database where sensor data is the information stored in the database, or as a publish/subscribe service where data
from sensors generate an event for the application. To cope with the mobility of the WSNs, or with the phenomena the WSN wants to capture, mobile
agents are also proposed as a programming paradigm. Another approach is
the use of rule-based declarative languages for command execution. On the
other hand, because the sensor node operating systems do not provide
enough support for middleware services, virtual machines are used to support runtime. Finally, some middleware solutions come with graphical user
interfaces, which include a query-builder and result display.
384
6/9/10
10:19
Página 385
16.2.1.3. Interface type
The way the application relates with the middleware can either be:
i) declarative, providing data about which information is required and
ii) imperative, offering commands that should be carried out. The first one
may be based on Structured Query Language (SQL) languages or XML, and
is used for database programming paradigms. The second is used for
publish/subscribe programming paradigms.
16.2.2. System services
WSN middleware is based on a set of functionalities that form the
middleware core. They are offered to the application programmer through
the abstraction interface and provide the support for application deployment, execution and WSN management. System services, which are the key
middleware services, can be divided into two categories:
• Common services: basic services shared by all WSN applications. A
detailed description of the common services is presented in Section
16.3.
• Domain services: services that facilitate the development of an application in a specific domain. They use the common services and add
application oriented functions.
It is quite common to define the middleware in two layers. The lower one
corresponds to common services, whilethe upper layer has the application
specific functionalities.
16.2.3. Run-time support
Run-time support may be regarded as an extension of the functionalities provided by the operating system of the sensor node needed to
support the functionalities of the middleware. Some of these functions
are: scheduling of tasks, process communication, memory control and
power control (with voltage scaling or component activation and deactivation).
385
6/9/10
10:19
Página 386
Sensors Everywhere
16.2.4. QoS mechanisms
The QoS for WSNs is an open issue, mainly due to the lack of understanding about the QoS concept in WSNs and how it can be implemented. In
addition to the traditional QoS parameters (such as delay, jitter or bandwidth), there exist other QoS parameters in WSN, such as data accuracy,
aggregation delay or system lifetime. This fact makes the implementation of
QoS techniques even more complex. The positive point of view for supporting QoS is the role of the middleware between the application and the
WSN. The middleware can act as a broker by collecting the requirements of
applications and status of the WSN and allocating resources to offer the
demanded QoS.
16.3.
Middleware system common services
As mentioned above, the system services are the key functionalities of
the middleware. They can be classified into code management, data management, data storage, resource and information discovery, resource management, integration and security.
16.3.1. Code management
A distributed WSN uses pieces of code that are allocated to certain nodes
and are executed. This code should be installed and updated, and even
moved according to the QoS criteria or the location of the phenomena the
WSN is monitoring. Code migration can be implemented at OS level, as in
some specific OSs such as BertaOS or MagnetOS. However, since WSN OSs
do not support code interpretation, this code migration is difficult to implement in a heterogeneous network. Some middleware support task migrations such as in SensorWare (with Tool Command Language (TCL) Scripts),
SINA55 (with SQL Scripts) or TinyLime56 (with Java Objects) [4] . Mobile Agent
55
SINA stands for Sensor information networking architecture [6]
56
TinyLime is an extension of Lime for the sensor network environment [7]
386
6/9/10
10:19
Página 387
is a further approach where the code, the state and the data are encapsulated and moved from one node to another. Code management is offered
on top of a virtual machine to hide the sensor node heterogeneity.
16.3.2. Data management
As previously mentioned, WSNs are data-oriented and must support the
following functions: data acquisition, data processing and data storage.
The first task, data acquisition, implies collecting relevant and accurate
data. Most of the WSN middleware proposed solutions use mechanisms that
are event based [4], such as TinyDB, DSware, Mires or Impala. Other solutions
use a query based model [4] such as TinyDB, Cougar or SensorWare.
Data processing can either be done in a centralised manner (i.e. in a node
outside the WSN), at node level, and hence delivering processed data to the
rest of the network, or at a network level, also known as distributed processing. There is a compromise between communication costs and computation
costs. However, it is well known that processing is much cheaper than communication in terms of power consumption.
Data fusion and data aggregation are interesting functionalities supported in a network level data processing implementation. These functions
can be supported at lower layers, but placing them in a middleware layer
seems the best solution since data can thereby be fully analysed.
Finally, data from the WSN can be stored externally, either in the sensor
node where the data have been generated or in the node where the data
have significance.
16.3.3. Discovery of nodes, resources and characteristics
These types of service are responsible for discovering newly joined sensors, resources associated to the nodes and information about the network
and nodes (network topology, neighbour nodes and node locations). Some
WSNs re-use existing discovery services protocols such as Service Location
Protocol (SLP) or Bluetooth Service Discovery Protocol (SDP).
387
6/9/10
10:19
Página 388
Sensors Everywhere
Resource and information discovery middleware provides underlying
network information to applications that are required to be adaptive. It also
provides information to the underlying network to support the adaptive
resource management services.
16.3.4. Resource management
Resource management is related to the usage of resources according to
applications and lower layer protocols. Resource management is responsible
for cluster service (for organizing nodes into groups), schedule service (to
decide the order and time for using the network) and data routing service
(offering an upper layer or selecting a routing protocol at network layer).
16.3.5. Integration
WSNs do not work in isolation from the rest and require to be connected
to other networks, in particular to the Internet. Several approaches are offered through middleware. The most popular one employs a proxy server
that translates the protocols between the two networks. A service oriented
approach is also possible, based on Web Services Description Language
(WSDL) and Simple Object Access Protocol (SOAP).
16.3.6. Security
It provides all the security mechanisms not available by the WSN. In particular, key management is one of the more important aspects.
16.4.
Examples
A significant number of middleware solutions have been proposed. Some
of them have been built as a prototype and tested, while others have only
been simulated. Tables 16.1 and 16.2 summarize the features of the most
relevant solutions.
388
6/9/10
10:19
Página 389
Programming abstraction features
Proposal
Interface
type
Middleware
Abstraction Programming common
level
paradigm
services
Sensor Ware Declarative Local
MagnetOS
Imperative Global
Database
Virtual
machine
Virtual
machine
Mate
Imperative Local
MiLAN
None
SINA
TinyDB
Declarative Global
Declarative Global
Cougar
Impala
Declarative Global
None
None
Database
Database
Graphic UI
Graphic UI
Mobile agent
Agilla
FACTS
Imperative Local
Declarative Global
Mobile agent
Rule based
AutoSec
None
None
None
DSWare
Declarative Global
None
Mire
Enviro Track
Imperative Local
Imperative Global
Graphic UI
None
None
None
CodeManagement
CodeManagement
ResourceManagement
CodeManagement
ResourceManagement
Security
ResourceManagement
Resource discovery
DataManagement
DataManagement
ResourceManagement
DataManagement
CodeManagement
ResourceManagement
Storage supporting
Security
CodeManagement
CodeManagement
DataManagement
Service discovery
ResourceManagement
DataManagement
ResourceManagement
Storage supporting
Real-time
Reliability
Data Management
Data Management
Resource Discovery
Resource Management
Table 16.1. Middleware proposals and their main characteristics
(adapted from [4])
389
6/9/10
10:19
Página 390
Sensors Everywhere
Proposal
Sensor Ware
MagnetOS
Test
environment
Prototype
Simulation and
testing tools
(see Note 1)
SensorSim
Custom simulator
Mate
Java Virtual
Machine (JVM)
Prototype
MiLAN
SINA
None
Simulation
None
GloMoSim
TinyDB
Simulation
prototype
Custom
environment
Cougar
Impala
None
Simulation
None
ZnetSim
Agilla
FACTS
AutoSec
Prototype
None
Simulation
Mica 2
None
Custom
environment
DSWare
Simulation
GloMoSim
Mire
Enviro Track
None
Prototype
None
Mica 2
TOSSIM
Evaluated performance
metrics
Framework size, execution
delays, energy consumption
Internal algorithm,
comparison in simulator
Byte code overhead,
installation costs, code
infection performance
None
SINA networking overh
ead, application performance
Query routing
performance in simulation,
sample accuracy and
sampling frequency in
prototypes
None
System Implementation
and Overhead, Impala event
processing time, software
transmission volume
None
None
Information collection
overhead, overall
performance efficiency
Performance in reduction of
communication, impact of
node density, performance
in reaction time
Case study
Communication
performance data, effect
of sensory radius on
maximum trackable speed
Note1: SensorSim, TOSSIM, GloMoSim, ZnetSim and Mica2 are general purpose simulation and
testing tools
Table 16.2. Development status of some of the middleware proposals
available for WSNs (adapted from [4])
390
6/9/10
10:19
Página 391
In general, the different middleware proposals are not yet sufficiently
mature. The global objective is too complex and solutions only address one
set of requirements. Existing proposals require a bandwidth and a processing power that are currently not available in WSNs. This limitation will tend
to disappear in the future as advances are made in processor development.
As technology evolves, better processors with the same power consumption will emerge on the market.
REFERENCES
[1] S. Hadim, N. Mohamed, “Middleware for Wireless WSNs: A survey”,
Journal of Computer Science and Technology, 23(3), pp. 305-326, May
2008.
[2] K. Henricksen, R. Robinson, “A survey of Middleware for WSNs: State-ofthe-Art and Future Directions”, in proc. of MidSens’06, Melbourne,
Australia, December, 2006.
[3] E. Yoneki, J. Bacon, “A survey of Wireless WSN Technologies: Research
Trends and Middleware’s Role”, Technical Report Number 646,
University of Cambridge, September 2005.
[4] M. Wang, J. Cao, J. Li, S. K. Das, “Middleware for Wireless WSNs: A
Survey”, Journal of Computer Science and Technology. Vol. 23, Nº 3,
pp. 305 – 326, May 2008.
[5] I. Chatzigiannakis, G. Mylonas and S. Nikoletseas “50 ways to build your
application: A Survey of Middleware and Systems for Wireless Sensor
Networks” in proc. of MidSens’06, Melbourne, Australia, December,
2006.
[6] C. Srisathapornphat, C. Jaikaeo, C. Shen; “Sensor information networking architecture”. In Proc. the Int. Workshop Parallel, IEEE CS Press, pp.
23-30, 2000
[7]
[http://lime.sourceforge.net/tinyLime/]
391
6/9/10
10:19
Página 392
6/9/10
10:19
Página 393
17
Future directions in
6/9/10
10:19
Página 394
6/9/10
10:19
Página 395
Chapter 17. Future directions in wireless sensor networks
17. Future directions in wireless sensor
networks
After the comprehensive review of WSN technologies provided in
previous chapters, this chapter is devoted to outlining future directions
in the field. Section 17.1 discusses how sensors are increasingly
becoming a reality in everyday life. Section 17.2 focuses on the limitations (e.g. energy, memory, etc.) that characterize sensor nodes (in
which those sensors are embodied). Section 17.3 discusses the current
fragmented WSN ecosystem and the need for few standardised wireless sensor network solutions. In Section 17.4, the use of IP in WSNs
and its relationship with the Internet of Things [1, 2] is analysed. Finally,
Section 17.5 discusses open application development framework enablement.
17.1.
More and more sensors in everyday life
A key future direction is fast becoming a reality now: “Sensors will be
everywhere around you”, which basically means that people could carry
wearable sensors (implants, textile sensors, sensors attached to the body,
etc.); they will have more and more sensors in their phone (e.g. accelerometers, light sensors, proximity sensors, humidity sensors, etc.), and many
remote sensors will found in their vicinity to provide various services (e.g. for
providing people location, environmental monitoring, public safety, urban
planning, etc.).
395
6/9/10
10:19
Página 396
Sensors Everywhere
Emerging small, low-cost, and low-power consumption sensor technologies are becoming a reality, enabling a massive deployment of sensors in the
spaces where people live and in the objects they use in their daily life. State
of the art of chip manufacturing technologies are currently producing these
types of devices; for example, surface micro-machining will lead to industrial
mass-production for Micro-Electro-Mechanical Systems (MEMS).
Another key future direction is the incorporation of sensor devices into
their corresponding “nodes” (for instance, embedded in materials like textiles, plastics or glass; built-in mobile phones or remote sensor nodes placed
in any location around the user), thus creating efficient short range wireless
system operations.
17.2.
Efficient energy harvesting sensor nodes
From initial research initiatives in the WSN area, energy supply and conservation has been identified as being of utmost importance.
In recent years, energy harvesting has been investigated as a promising
strategy for palliating the problem of feeding the nodes. However, more
research is needed in this direction, since current energy harvesting mechanisms are limited. Design for energy constrained nodes will still be indispensable in WSNs, at least in the foreseeable future.
Another typical characteristic of sensor nodes that requires improvement
is hardware constraints. Even so, the capabilities of recent hardware platforms
are on the increase. This suggests that future WSN applications will benefit
from enhanced processing capabilities, thereby enabling enhanced quality
and functionality. Some of the protocol design principles (e.g. with regard to
storage capacity of a node) may have to be revisited in due course.
17.3.
Standardised WSN solutions
Sensor nodes need to be interconnected and able to communicate with
each other, preferably by implementing wireless mesh technologies in most
396
6/9/10
10:19
Página 397
Chapter 17. Future directions in wireless sensor networks
cases. A key factor for future success is to avoid fragmentation of the WSN
ecosystem with a multitude of proprietary solutions focused on specific
applications. A future direction towards fewer standardised short-range
wireless systems able to cope with a wide set of sensor based applications
is envisaged.
Short range network topologies and protocols will be influenced by the
evolution of processing power, as previously discussed.
17.4.
IP-based WSNs and the Internet of Things
While most networking solutions for WSNs were first conceived without
IP support, it is interesting to observe that convergence towards IP is a
current major trend in the industry. Indeed, IP support offers significant
advantages for WSNs in terms of interoperability, reuse of existing tools and
remote access. While protocol overhead might be argued as a drawback for
IP-based approaches, good performance IP solutions for WSNs already
exist. Nevertheless, more effort is required in order to adapt existing protocols or to develop new ones (e.g. in the application, transport and security
areas). The IETF will play a key role in defining the mechanisms for the use
of IP in WSNs, which will add to those already developed by the 6LoWPAN
and ROLL WGs.
On the other hand, WSNs will play a significant role in the Internet of
Things. It is expected that many of the “next billion nodes” to be connected
to the Internet will be WSN nodes. These nodes (i.e. “machines”) will outnumber the amount of users (i.e. “humans”) currently connected to the
Internet. The convergence of WSNs towards IP may be a key technology factor enabling the Internet of Things vision.
Finally, the design of new architectures for the Internet (sometimes referred to as Post-IP initiatives [3]) may benefit from considering the solutions
that already exist for WSNs. In fact, sensor nodes may become the dominant
type of device in the Internet of the future. On the other hand, sensor nodes
will be the most limited devices in the Internet. In consequence, it is reasonable to design the future Internet protocols and mechanisms in order for
397
6/9/10
10:19
Página 398
Sensors Everywhere
them to work properly on sensor nodes, since they will also work well on
more powerful devices.
17.5.
Applications development
The development of a large amount of applications for WSNs will be
made possible by adequate middleware and supporting platforms. These
platforms should constitute the basic reference for a framework, thus allowing the development of a wide range of applications supported by an
ecosystem in which the service creation, composition and reuse of modules
are facilitated. This is a “horizontal” approach, aligned with the web 2.0
model successfully run for software applications.
On the other hand, a “vertical” approach where end to end solutions
based on middleware platforms developed for one or few specific applications will also exist, especially for massive applications utilising this investment.
REFERENCES
[1]
http://www.itu.int/osg/spu/publications/internetofthings/
[2]
ITU-T Technology Watch Briefing Report Series, No. 4 (February 2008).
[3] R. Tafazolli, “e.Mobility Post-IP Working Group White Paper”, December
2006. http://meshup.org/eMobility_PostIP
398
6/9/10
10:19
Página 399
GLOSSARY
6/9/10
10:19
Página 400
6/9/10
10:19
Página 401
Glossary
Glossary of Terms and Abbreviations in
Alphabetical Order
Constants and numeric items
3DES
3G
Triple Data Encryption Standard
Third Generation
3GPP
268,301
333, 346
Third Generation Partnership Project
6LoWPAN
342, 346
IPv6 over Low power Wireless Personal Area Networks
working group 86, 210, 214, 221, 268, 283, 290-292, 327,
340-341, 397
Edge router 291
Host 291
Mesh node 291
A
AAL Ambient Assisted Living 74,
ACL Access Control List 253
Access control 253
ACK Acknowledgement 139, 150-154, 171, 239-240, 244-245, 298,
303, 305
ACQUIRE ACtive QUery forwarding In sensoR nEtworks 201-202
Active state 141. 166
Actuator 59-60, 80, 165, 177, 326, 345
Electric switch 179
401
6/9/10
10:19
Página 402
Sensors Everywhere
Infrared transmitter 180
Ultrasound transmitter 179
ADC Analog to Digital Converter 167
Address assignment algorithm 288
Address auto-configuration 291
ADV message Advertise Message 200
AES Advanced Encryption Standard 252-245, 257, 267, 268 298-299,
301, 306, 310
AES-CBC-MAC AES - Cipher Block Chaining - Message Authentication
Code 253, 254
AES- CCM AES - Counter with CBC-MAC 253, 254
AES-CTR AES- Cipher Counter 253, 254
Agents 199
Aggregation 321, 386-387
AIMD Adaptive Increase Multiplicative Decrease 227, 234
ALOHA protocol 134
Ambient Systems 276, 311-312
AmbioSystems LLC 311
AMI Advanced Metering Infrastructure 78-79, 283, 297
AM Amplitude Modulation 103
AMR Automatic Meter Reading 78-79, 283, 297
ANSI American National Standards Institute 322
ANSI N42.42 Data format standard for radiation detectors used for
Homeland Security 322
ANT 308, 309-310
Antenna 172-177
Balun 176
Ceramic 175, 176
Connector 176
Dipole 172, 173-174
Folded Monopole 174, 175
Full wave loop 174
Helix Antenna 174
IFA Inverted F Antenna 175
Isotropic 98, 178
402
6/9/10
10:19
Página 403
Glossary
Meander Antenna 174
Whip 174
AODV Ad-hoc On-demand Distance Vector 206-210, 285
AODVbis 210
AODVjr 210
API Application Programming Interface 170, 299
APL Application Layer 255-256, 258, 284, 286
Application framework 286
Application object 286
APS APplication Support sub-layer 286
Arch Rock Corp. 182
Arduino 182
ARQ Automatic Repeat reQuest 235
ARM Advanced RISC Machine processor 166
ARM Cortex 166
ARM7 275, 278
ARM9 278
ASCII American Standard Code for Information Interchange 346
ASK Amplitude Shift Keying 104, 112-114, 172, 302
AT command ATtention command 181
Atmel Corporation 166, 171, 181
Attenuation 97, 99, 376
Augmented reality 320
Authentication 251-261, 262, 294, 306-307
B
Back-off procedure 135, 149, 229
Backpressure messages 227
BCH codes Bose, Chaudhuri, Hocquenghem error correcting codes
BR Basic Rate 293-295
Beacon-enabled network 148-152
BFSK Binary Frequency Shift Keying 297
Bluetooth 283, 292, 292-297, 327, 387
Controller 285, 294-295
300
403
6/9/10
10:19
Página 404
Sensors Everywhere
Core spec 293-294
HCI Host Controller Interface 294
Host control 294
Low energy 88, 121, 156, 171, 292-293
SDP Service Discovery Protocol 387
SIG Special Interest Group 85, 88,107, 293
BOM Bill of Materials 180
BOSH Bidirectional-streams Over Synchronous HTTP 343
BPM-BPSK Burst Position Modulation BPSK 117-118
BPSK Binary PSK 104-105, 108-110
Broadcast communications 285, 302
BT-LE Bluetooth - Low Energy 88, 97, 121, 156-160, 171, 198, 267-268,
293-295
Buffer occupancy 233, 234
Building automation 283, 288, 297, 299, 301
BXML Binary XML 323
C
CADR Constrained Anisotropic Diffusion Routing 199
CAN Controller Area Network 327
CANOpen 327
CAP Contention Access Period 149, 153
CAP Compact Application Protocol 255, 340
CBCS Cluster Based Collaborative Storage protocol 321
CBRN Chemical, Biological, Radiological, and Nuclear 322
CBRN data model 322
CBTC Cone Based Topology Control 192-193
CCA Clear Channel Assessment 112
CCM Counter with Cipher block chaining-Message authentication code 294
CCM* CCM variant 254, 257, 306
Checksum 298
Chipcon AS 166, 171, 180
CCF Congestion Control and Fairness 229-230, 232, 234
CSMA Carrier Sense Multiple Access 11
404
6/9/10
10:19
Página 405
Glossary
CFP Contention Free Period 149
Channel blacklisting 307
Child node 228
Children node, 228-231
CLS Coordinated Local Storage 321
Cluster-based network 188
Cluster head 133, 188, 202-203, 321
CoAP Constrained-node/network Application Protocol 86
CODA Congestion Detection and Avoidance 227-234
Coexistence 123-126
Collision avoidance 112, 135, 138, 297, 303
Collision detection 135
Commercial Building Automation 211
Confidentiality 251, 254, 306
Congestion control protocols 221-225, 226, 227-232, 233-240, 244-245
Congestion detection 226-241
Congestion mitigation 226-241
Congestion notification 226, 231, 241
Conitel 346
Continuous flow 240-244
Contention-based protocols 133, 134
Contention window schemes 137
Convolutional coding 117
COOJA Contiki OS Java Simulator 278
CoRE Constrained RESTful Environments working group 86, 292, 345
Coronis S.A.S. 299
COUGAR routing protocol 201-202
CPU Central Processing Unit 166, 323
CRC Cyclic Redundancy Check 171-172, 294, 302
Cricket 275, 375
Crossbow Technology 182, 275, 309, 359
CS Carrier Sense 300
CSMA Carrier Sense Multiple Access 112, 134, 300, 311
CSMA/CA CSMA with Collision Avoidance algorithm 112, 135, 149155, 300
405
6/9/10
10:19
Página 406
Sensors Everywhere
CSMA/CD CSMA with Collision Detection algorithm
CSK Chirp-Shift Keying 120
CSS Chirp Spread Spectrum 115, 119-120
CSV Comma-Separated Values 345
135,
D
DAA Detect and Avoid mechanism 113
DAG Directed Acyclic Graph 212-213, 291
DAG Identifier 212
DAG root 212
Data encoding and aggregation protocols 322
Data interpretation 321
DATA message 192
DAC Digital to Analog Converter 167
DecaWave 376
Destination sequence number 207
Device ID 304
DFSS Distributed Frequency Spread Spectrum 309
Diffraction 99-100
Digi International Inc. 181, 310, 336
DiGiMesh 308, 310
DIO DAG Information Object 212-213
Directed diffusion routing protocol 198-199, 236, 239
DMA Direct Memory Access 167
DMAC 141-142, 146
DNP3 Distributed Network Protocol 3 346
Downstream 226, 229, 239
Doze mode 167
DQPSK Differential QPSK 119
DSMAC Dynamic Sensor-MAC protocol 139-140, 146
DSSS Direct Sequence Spread Spectrum 106, 108-115, 305, 310
DS-UWB Direct-Sequence UWB 107, 115
DTC Distributed TCP Caching 224
DTN Delay Tolerant Networking 333-336
406
6/9/10
10:19
Página 407
Glossary
Duration field 138
Dust Networks, Inc. 304, 306
Duty-cycle-based protocols 138
DYMO Dynamic MANET On-demand routing protocols
DYMO-low 210
Dynastream Innovations Inc. 309-310
207, 210
E
EAR Energy Aware Routing 199
ED Energy Detection 111-112
EDR Enhanced Data Rate 293, 295
EEML Extended Environments Markup Language 323, 345
Energy conservation 61, 131, 204
Energy saving 143, 160, 295
Energy consumption 121, 131, 187, 197, 199, 202, 224, 243, 355-359
Encryption 171, 251, 267-268 273
Encryption algorithm 289, 304
EnOcean GmbH 89, 297, 301-302
EnOcean Alliance Inc. 85, 89, 301-302
EEPROM Electrically-Erasable Programmable Read-Only Memory 170
ECG ElectroCardioGraph 72-73
Error Control 150, 300
ESP Energy Service Portal 287
ESRT Event-to-Sink Reliable Transport protocol 241-244
ETSI European Telecommunications Standards Institute 87, 346
Event-driven flow 240-241, 243-244
EXI Efficient XML Interchange 322, 343
Exposed terminal problem 135-136, 139
F
FCC Federal Communications Commission 101-107
FCS Frame Check Sequence 153
FEC Forward Error Correction technique 117, 300
407
6/9/10
10:19
Página 408
Sensors Everywhere
FFD Full Function Device 148
FHSS Frequency Hopping Spread Spectrum 106, 123, 300, 305
Fingerprinting 372, 377
Flat Routing 198
FM Frequency Modulation 103
Forwarding interruption problem 141
Fragmentation 289, 291, 335, 397
Frame integrity 297
Freescale Semiconductor, Inc. 166, 171, 181
FreeRTOS Free Real-Time Operating System 275-276
Frequency
Agility 289
Bands 97, 101, 286, 312
Hopping 294, 300, 305, 307
FSK Frequency Shift Keying 101, 117, 155, 172, 302
FTP File Transfer Protocol 223
Fuel Cell 361-362
Fusion 228, 234
G
GAF Geographic Adaptive Fidelity protocol 206
GEAR Geographic and Energy Aware Routing protocol 206
Geographic Routing 198, 204
GET command 344
GFG Greedy-Face-Greedy 204, 205
GFSK Gaussian FSK 123, 172, 294, 300
GPIO General Purpose Input/Output 167
GPRS General Packet Radio Service 180, 346
GPS Global Positioning System 132, 160, 191, 204, 371
GPSR Greedy Perimeter Stateless Routing 204-205
Graph routing 305, 307
Greedy forwarding 204-205
GSM Global System for Mobile Communications 180
GTS Guaranteed Time Slot 149, 152
408
6/9/10
10:19
Página 409
Glossary
H
HART Highway Addressable Remote Transducer 306-308
Communication Foundation 306
Harvesting 301, 355, 362-366
HCI Host Controller Interface 294
Header compression 291
HFB High Frequency Band 115-116
Hibernate mode 167
Hierarchical Routing 202
Hidden terminal problem 135-136
Home automation 211, 283-284, 287, 302-303, 310
Hop-by-hop flow control 228
Host Chapter 291
6lowPAN 291
Bluetooth 294-295
HTTP HyperText Transfer Protocol 223, 342-345
HVAC Heating, Ventilating, and Air Conditioning 75-76, 287
I
I2C Inter-Integrated Circuit IBM Corp. 343
IC Integrated Circuit 119, 166, 171, 180-181, 376
ICD Intelligent Congestion Detection 231
ICN Implicit Congestion Notification 231
ID Identifier 298, 304, 307
Idle listening 131, 143
IEC International Electro-technical Commission 84, 86-87, 346
IEEE Institute of Electrical and Electronics Engineers 84-85, 257, 292
802.11 122, 124, 125, 135, 145, 293, 327
802.11b and g 124-125
802.15.1 327
802.15.4 85-88, 97-112, 120-131, 148-155, 171, 209-214, 251268, 284-291, 300-311, 337, 341, 357-365
802.15.4 a, c, d, f and g 115-117, 119, 120, 358, 376
409
6/9/10
10:19
Página 410
Sensors Everywhere
1451 85, 177, 320, 322, 325-327
1451 Chapters 2, 5, 12
P1902.1 312
IETF Internet Engineering Task Force 85-86, 197, 206, 210-211, 124,
224, 290-292, 340-343, 345, 397
IFS InterFrame Space 150
Implosion 200, 238
IMS IP Multimedia Subsystem 333-334, 346-347
Indirect addressing 286
Industrial automation 60, 77, 211, 283, 304, 306, 308, 310
In-network storage 320
INSTEON 268, 297, 302-303
INSTEON Alliance 85, 88, 302
Integrity 251-254, 256, 297, 306-307
Intel Corporation 182
Internet of Things 86, 395, 397
IP Internet Protocol 182, 211, 223, 225, 278, 290-292, 301, 312, 333346, 395-398
IPSO IP for Smart Objects alliance 290
IPv6 IP version 6 86, 212, 214, 224, 290, 291, 338, 340, 341
VoIP Voice over IP 339 IP-Wave chip 299
Iris 178, 182
ISA International Society of Automation 307-308
ISM Industrial, Scientific and Medical 35, 101-102, 121, 123, 294, 297, 300
ISO International Organization for Standardization 84, 86, 87
JTC ISO/IEC Joint Technical Committee 87
ITS Intelligent Transportation Systems 79
ITU International Telecommunication Union 84, 86, 102
ITU-T Telecommunication Standardization Sector 86, 150
J
Jabber 342-343
Java objects 286
Jennic Ltd. 181, 358, 376
410
6/9/10
10:19
Página 411
Glossary
Jitter 229, 230, 386
Join keys 306
JSON Java Script Object Notation 344
JVM Java Virtual Machine 344, 390
K
K-connectivity 193
Key transport service 256, 259
K-NEIGH protocol 192, 193
L
LAN Local Area Network 337
LEACH Low Energy Adaptive Clustering Hierarchy protocol
133, 144, 189, 190, 202
LFB Low frequency Band 115, 116
LFSR Linear Feedback Shift Register 117
LIFS Long IFS 150
LINT Local Information No Topology protocol 192
Listen/sleep scheme 138, 139
LLC Logical Link Control 300
LLN Link Layer Notification 208, 209
LLNs IP-based Low power and Lossy Networks 86, 211, 212
LMST Local Minimum Spanning Tree protocol 192, 193
LOAD 6LoWPAN Ad Hoc On-Demand Distance Vector routing 210
Load monitoring 244
Location Methods 372-377
Proximity 373
Positioning 374-377
Fingerprinting 377
Loop-freedom 207, 212
LOS Line Of Sight 76, 99
LoWPAN Low power WPAN 182, 210, 214, 221, 267, 268
Local hello messages 208
411
6/9/10
10:19
Página 412
Sensors Everywhere
LQI
M
Link Quality Indication
111, 112, 214
M2M Machine to Machine 87
MAC Medium Access Control layer 67, 71, 85, 109, 110, 112, 120, 131160, 171, 187, 189, 226-232, 234,
240, 252-258, 284, 293, 297, 300,
304, 306, 308-311, 336, 337, 357
Authentication 252, 256, 257, 258
Protocols 131-160, 240
MANET Mobile Ad Hoc Network routing protocols 197, 206, 207, 210
MANTIS MultimodAl NeTworks of In-situ micro Sensor 277
MAXFOR Technology, Inc. 182
MB-OFDM Multiband –OFDM 107
MCU Microcontroller Unit 166-171, 277, 278
Mean least square algorithm 374
MeshNetics 181
Mesh routing 285
Mesh topology 64, 66, 285, 291, 302
Mesh under 291, 292
Metadata 192, 321-323
MFR MAC footer 152
MHR MAC header 152
Mica 182, 275
Mica2 178, 182
MicaDot 182
MicaZ 178, 182
Micrium, Inc. 276
Micro-fuel cells 361, 362
Microsoft Corporation 278
Middleware 274, 381-391, 398
Programming abstractions 383
Proposals 383, 389-391
SensorWare 386-387
MagnetOS 386, 389, 390
412
6/9/10
10:19
Página 413
Glossary
Mate 389, 390
MilAN 389, 390
SINA 386, 389, 390
TinyDB 387, 389, 390
Cougar 387, 389, 390
Impala 387, 389, 390
Aguilla 389, 390
FACTS 389, 390
AutoSec 389, 390
DSWare 387, 389, 390
Mire 387, 389, 390
Enviro Track 389, 390
QoS mechanisms 383, 386
Run time support 383, 385
System services 381, 383, 385, 386
MIPS Million Instructions Per Second 166, 359
Mobile agent 384, 386
MobileGrid protocol 192
Modbus Chapter 11, 346
Modulation techniques 103-106, 111
Mote 62
MoteIV 182
MQTT-S Message Queuing Telemetry Transport – Sensor 342-344
MSDU MAC Service Data Unit 152-154
MSK minimum-shift keying 172
MSP430 processor 275, 278
MST Minimum Spanning Tree 192, 193
MTS More To Send 142
Multicast communications 300
Multicasting 212
Multi-hop communication schemes 61, 81, 112, 196-214, 275, 285, 309,
311, 360, 376
Multipath 115, 118
Multipoint-to-sink 212
413
6/9/10
10:19
Página 414
Sensors Everywhere
N
NACK Negative Acknowledgment 236, 238-241, 305
nanoIP 224
Nanotron Technologies GmbH. 120
NAV Network Allocation Vector 138, 139
NCAP Network Capable Application Processor 327
Neighbour discovery 291
nesC language 209, 275
Network ID Network identification 304
Network formation 285
Network keys 306
Network routing 197
NI Network Interface 326
NIST National Institute of Standards and Technology 292, 322
Harmonization of Sensor Standards Working Group 322
NO2 Nitrogen dioxide 72
Non-beacon-enabled network 148, 149, 151, 152
Nonce 304
Non-persistent CSMA 134, 135, 143, 145
Nordic Semiconductor 171
NST AODV Not So Tiny AODV 207, 209, 210
Nuri Telecom Corp. 78
NWK Network Layer 255-258
O
O&M Observation and Measurement 325
ONE-NET 297, 304
OFDM Orthogonal Frequency Division Multiplex- 107, 124
OGC Open Geospatial Consortium 322, 323, 325
OOK On/Off Key 172
Open trust model 255
OpenSpime 343
O-QPSK Offset-Quadrature PSK 33, 109, 111-113, 115, 120
414
6/9/10
10:19
Página 415
Glossary
OS Operating system 273, 278, 382-385
Architecture 274
Monolithic 274
Modular 274
Virtual machine 274, 384
Execution model 274
Events 274, 275, 278
Threads 274, 276, 277
State machine 274
Reprogramming 274, 277
Scheduling 273, 274, 385
Periodical/non-periodical 274
Critical/non- critica 274l
Symtems 274-278
AMBIENT RT 276
BertaOS 386
Contiki 277, 278
FreeRTOS 275, 276
MagnetOS 386, 389, 390
MantisOS 277
Microsoft .NET Micro 278
Nano-Qplus 276, 277
RETOS 275
SOS Sensor Operating System 277
TinyOS 274, 275, 309
uC/OS II 276
OSI Open Systems Interconnection 66
OTP One Time Programmable memory 170
Overlapping 200
OWL Web Ontology Language 325
P
P2P Peer to Peer 301
Pachube 323, 325, 345
415
6/9/10
10:19
Página 416
Sensors Everywhere
PAN Personal Area Network 148, 153, 285
Path accumulation 210
Path diversity 212
Parent node 65, 212, 213, 228, 229, 230, 231
Path loss 98
PCB Printed Circuit Board 181
PCCP Priority-based Congestion Control Protocol 231, 232, 234
PDU Packet Data Unit 336
PEGASIS Power-Efficient Gathering in Sensor Information Systems 202, 203
PER Packet Error Ratio 108, 125
Phidgets 177
PHP PHY Payload 109, 110
PHR PHY Header 109
PHY Physical Layer 67, 97, 108, 111, 113, 121, 155, 159
Physical layer protocols 67
Photovoltaic cells 363
PICNIC PIC Network Interface Controller 224
Piggyback information 231, 234, 237, 302
PIR 76
PLC Power Line Communications 302
PLC Programmable Logic Controller 345
PM Phase Modulation 103
Point-to-point 291, 302, 344
Point-to-multipoint 295, 302
Post-IP 397
Power consumption modes 359
Powerline zero crossings 303
PPDU PHY Protocol Data Unit 109, 110, 117
p-persistent CSMA 134, 135
PRA Priority-based Rate Adjustment 231
Prioritized MAC 228
Profibus PROcess FIeld BUS 346
Propagation 61, 97, 99, 101
Proxy server 388
PSD Power Spectral Density 125
416
6/9/10
10:19
Página 417
Glossary
PSFQ Pump Slowly, Fetch Quickly 237-239
PSDU PHY Service Data Unit 110, 117, 118
PSK Phase Shift Keying 104
PSSS Parallel Sequence Spread Spectrum 106, 112-114
PTG Protocol Translation Gateway 333-339
PUT Command 344, 345
Q
QoS Quality of Service 383, 386
QPSK Quadrature PSK 104, 111
R
Radiocrafts AS 181
Radiopulse 171
Radio Transceivers 171, 172
RAM Random Access Memory 62, 167, 170, 209, 223, 276, 289
Rank of a node 212, 213
Rate limiting 228
RBC Reliable Bursty Converge-cast 236, 237, 239
RCL Route Change Latency 209
RDF Resource Description Framework 325
Reactive routing protocol 206, 207, 210
Receiver sensitivity 97, 108
Reed-Solomon coding 117
Reflection 98, 99, 101, 106
Regulate bit 227
ReInForM Reliable Information Forwarding 235, 239
Reliability protocols 223, 235-239
Reliable event detection 241, 242
Rene Chapter 182
Repair request 236
Replay attacks 304
Replay protection 253
Reporting frequency 242, 243
417
6/9/10
10:19
Página 418
Sensors Everywhere
REQ message Request Message 200
RERR Route Error 207
REST Representational State Transfer 344, 345
RESTful 292, 345
RETOS Resilent, Expandable and Threaded Operating System 275
RF Radio Frequency 76, 97, 121
RF4CE consortium Radio Frequency for Consumer Electronics
consortium 287
RFC Request for Comment 308, 343
RFD Reduced Function Device 148, 285, 300
RFID Radio Frequency IDentification 75, 102, 120, 311, 327, 366
Active 311
RF Monolitics, Inc. 181
Right-hand rule 205
RISC Reduced Instruction Set Computer 166
RMST Reliable Multi-Segment Transport 236, 239
ROLL Routing Over Low power and Lossy networks working group
86, 210, 211, 341, 397
ROM Read Only Memory 170, 209, 327
Root node 65, 66
Routing protocols 197-214
Route discovery 207-210
Route over 291, 292
Routing 197-214, 285, 287-289, 297, 298, 303, 305, 307-309, 311
Update 235
RPL IPv6 Routing Protocol for Low power and lossy networks
212-214
RREP Route Reply 207, 208, 210
RREQ Route Request 207, 208, 210
RSS Really Simple Syndication 345
RSSI Received Signal Strength Indicator 101, 172, 204, 301, 305, 376
RTS/CTS Request-To-Send/Clear-To-Send 137, 139, 145
Medium Access control mechanism 137, 139, 145
Flow control mechanism 169
RTU Remote Terminal Unit 345
418
6/9/10
10:19
Página 419
Glossary
RTT Round Trip Time 209
Rubee 308-312
RUC Road Usage Charging 82
Rumour routing 199
Run time support 385
S
SAS Sensor Alert Service 325
SCADA Supervisory Control And Data Acquisition protocol 345-346
Scattering 99-100
Scavenging 362-364
Scheduling-based MAC protocols 132-133, 144
SDP Service Discovery Protocol 387
SECDED Single Error Correction, Double Error Detection coding 117
Security 251-269
Semantic Web 325
Sensicast Systems, Inc 308
SensiNet 308-309
Sensinode Ltd. 182
Sensor 59-60, 165
Acceleration 178
Air humidity 71-72, 177
Barometric 72
Light 72, 76-77, 82, 84, 177
Force 178
Gas 78, 179
CO Carbon monoxide 179
CO2 Carbon Dioxide 179
NO2 Nitrogen dioxide 179
NH3 Ammonia 179
CH4 Methane 179
O3 Ozone 179
Smoke 76, 179
Infrared receiver 178-179
Magnetic field 178-179
419
6/9/10
10:19
Página 420
Sensors Everywhere
Pollen concentration 71-72
Presence 178-179
Proximity 178
Soil moisture 178
Sound 178
Temperature 71-72, 177
Ultrasound receiver 81, 179
Ultraviolet Radiation 72
SensorML Sensor Model Language 322-324, 345
Sensor network applications 60
Categories 71-84
Automotive 75
Building automation 77
Contextual awareness 84
Disaster Recovery 82
Environmental monitoring 71
Gaming 84
Healthcare, sports and fitness, Assisted living 72-73
Home automation 75-76
Industrial monitoring and control 77
Logistics 75
Robotics 84
RUC Road Usage Charging 82
Rural monitoring and control 82
Smart utility 78
Structural monitoring 74
Telecommunication applications 83
Urban monitoring and control 79-80
Sensor network gateway 60
Sensor node 59
Sensor node architecture 62-63, 165-180
Sensor web 325
Session keys 306
SHIMMER RESEARCH 73, 275
SHR Synchronization header 109-110
420
6/9/10
10:19
Página 421
Glossary
Sibling node 65, 212-213
SIFS Short IFS 150
Sift 137, 145
Sigma Designs, Inc 297, 299
Simulcast 303
Sink Node 60
Sink-to-multipoint 212
SINR Signal to Interference and Noise Ratio 107
SiP System in Package 176, 181, 358
SIP Session Initiation Protocol 342
NOTIFY Command 342
PUBLISH Command 342
SUBSCRIBE Command 342
TinySIP 342
Siphon Chapter 8
SKKE Symmetric-Key-Key Establishment 259, 262, 265
Sleep mode 131, 138, 141, 143, 146, 167, 169
Slotted ALOHA 134, 142, 145
SLP Service Location Protocol 387
SMA SubMiniature version A connector 176
S-MAC Sensor-MAC protocol 138-143, 146-147
Smart Grid 79
Smart transducer module 326-327
SMS Short Message Service 346
Sniff-subrating 294
SNMP Simple Network Management Protocol 292
Snoop 224
SNR Signal to Noise Ratio 112
SOAP Simple Object Access Protocol 344, 388
SoC System on Chip 180-181, 358
SOS Sensor Observation Service 325
SOS Sensor Operating System 277
Source routing 285, 288-289, 298, 307
Spatial diversity 305
SPI Serial Peripheral Interface 168
421
6/9/10
10:19
Página 422
Sensors Everywhere
SPIN Sensor routing Protocols for Information via Negotiation 200-201
Spoofing 304
Spreading techniques 105-106, 109, 113
SPS Sensor Planning Service 325
SQL Structured Query Language 385
SQL scripts 386
Star network topology 64-65, 294, 296, 311
STCP Sensor Transmission Control Protocol 240-241, 243-244
STEM Sparse Topology and Energy Management protocol 142-143, 147
Stochastic (address) assignment 288-289
SunSpot 182
Super-capacitors 360, 362
Super-frame structure 148, 153
SYNC Synchronisation 138, 140, 146
System ID System Identification 304
SWE Sensor Web Enablement 325
T
TCP
Transmission Control Protocol 67, 160, 221-225, 299, 334-335,
340-341
TCL scripts Tool Command Language scripts 386
TDMA Time Division Multiplex Access 132-133, 144, 156, 190, 300,
305, 307
TEDS Transducer Electronic Data Sheets 327
TEEN Threshold-sensitive Energy Efficient sensor Network protocol 203
Telegesis Ltd. 181
Telos B 182, 275, 278
Temporal diversity 305
Texas Instruments, Inc. 171, 180-181, 358-359, 376
TFTP Trivial File Transfer Protocol
TII Transducer Independent Interface 326-327
TIM Transducer Interface Module 326-327
Time critical applications 203
Timestamps 132
422
6/9/10
10:19
Página 423
Glossary
TinyAODV 207-209
TISPAN Telecommunications and Internet Services and Protocols for
Advanced Networking 346
T-MAC Timeout-MAC protocol 139-141, 146
Topology Control 187-193
TOSSIM TinyOS SIMulator 275, 390
PowerTOSSIM 275
TRAMA TRaffic-Adaptive Medium Access 133, 144
Transducer 62-63, 85, 311, 320, 325-328
TransducerML Tranducer Model Language 325
Transfer layer 297
Transport layer proxies 222, 225
Transport protocols 221-244
Tree routing 285, 288-289
Tree topology 64-66, 226, 285, 301, 309
Triangularisation 374
Trilateralisation 374
Trickle algorithm 213
TSMP Time Synchronized Mesh Protocol 304-308
TTL Transistor-Transistor Logic 167
Tunnelling Chapter 308
TYMO TinyOS DYMO 210
U
UART Universal Asynchronous Receiver/Transmitter 168-169
UC Berkley University of California Berkley 182
Smart Dust Project 165, 275
TinyOS 208-210, 274-275, 309
UDP User Datagram Protocol 221-222, 225, 335, 340
U.FL Connector 176
uIP stack 224, 278
Ultra-capacitors 360, 362
UMTS Universal Mobile Telecommunications System 346
Unicast communications 255, 285-286, 298, 300, 302, 307
423
6/9/10
10:19
Página 424
Sensors Everywhere
Upstream 207, 209, 226, 239, 243
Urban automation 211
URI Uniform Resource Identifier 342
USB Universal Serial Bus 180
USN Ubiquitous Sensor Networks 86
UV Ultraviolet 72
UWB Ultra Wideband 103, 106-107, 115-119
V
Virtual sink nodes
232-233
W
W3C World Wide Web Consortium 322, 325, 343
WaspMote 182
Wavenis 268, 297, 299-301
Wavenis OSA Open Standards Alliance 85, 88, 299, 301
WG Working Group 86, 206, 210-211, 214, 290-292, 340-341, 397
WHAN Wireless Home Area Network 287, 290
Wibree 293
WideTag, Inc. 343
WiFi Wireless Fidelity 180, 287, 297, 327, 366
Window-based mechanisms 237
WirelessHART 304, 306-307
WiseMAC protocol 143, 147
WNS Web Notification Service 325
WLAN Wireless Local Area Network 102
WPAN Wireless Personal Area Networks 102, 107, 120, 156, 290, 292
WSDL Web Services Description Language 344, 388
WSN Wireless Sensor Network 59-67
X
X-10 systems
Xbee 181
424
303
6/9/10
10:19
Página 425
Glossary
XEP XMPP Enhancement Proposal 343
XMesh 308-309
XML eXtensible Markup Language 322-324, 342-344, 385
XML compression 322
XMPP eXtensible Messaging and Presence Protocol 342-343
Jabber open source community 342-343
Publish/subscribe mechanism 343
µXMPP 343
XTEA extended Tiny Encryption Algorithm 304
Y
Z
ZCL ZigBee Cluster Library 286-287
ZDO ZigBee Device Object 256, 258, 286-287
ZebraNet 320
ZigBee 85, 88, 197-198, 207, 221, 244-245, 251-268, 283-290, 309, 327,
336-337, 340-341, 347
Application profiles 286-289
Building Automation 288
Health Care 288
Home Automation 284, 287
Remote Control 287
Retailers Services 288
Smart Energy 287, 289
Telecommunication Services 288
Coordinator 260
Device Update 259
End Device 244, 285-286
Key Request 9
Link Keys Chapter 9
Network Keys 9
PRO 11
425
6/9/10
10:19
Página 426
Sensors Everywhere
Request-key, 264-265
RF4CE 287
Router 180, 260-262, 266, 285
Stack Profile 288-289
Trust Center 259-266
Zolertia 182
Z-Wave 85, 88, 268, 297-300, 303, 340, 358
Command classes 298
Controller node 298
Home ID 298
Routing Slaves 298
Slave Node 298
Z/IP Programme 299, 340
426
Proyecto1
7/9/10
10:17
Página 1

Sensors Everywhere 01 - Fundación Vodafone España

Transcripción

Documentos relacionados

07102016 Bulletin - Corpus Christi Catholic Church

12th Sunday Ordinary Time

Web Dynpro Controllers