Sensors Everywhere 01 - Fundación Vodafone España
Transcripción
Sensors Everywhere 01 - Fundación Vodafone España
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 Sensors Everywhere 01 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). Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 4 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 13 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 15 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 17 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 19 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 21 Sensores en todas partes 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 security is used. The last field, denoted by MAC, is the Message Authentication Code. The size of each field is expressed in byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fig. 9.3. Payload of a ZigBee frame (MAC layer payload), when APS security is used. The last field, denoted by MAC, is the Message 191 199 201 203 205 208 213 226 230 232 257 258 21 Sensors Everywhere 01 6/9/10 09:58 Página 22 Sensors Everywhere Authentication Code. The size of each field is expressed in 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 . . . . . . . . . . . . . . . . . . . . . . . . Fig. 9.11. Message sequence for a device that leaves a secure ZigBee 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 Sensors Everywhere 01 6/9/10 09:58 Página 23 Sensores en todas partes 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 Sensors Everywhere 01 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]) . . . . . . . . . . . . . . . Table 8.4. Main characteristics of transport protocols for congestion 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] . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 14.3. Definition of parameters of a power consumption model in 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 Sensors Everywhere 01 6/9/10 09:58 Página 25 Summary in Spanish Sensors Everywhere 01 6/9/10 09:58 Página 26 Sensors Everywhere 01 6/9/10 09:58 Página 27 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 29 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 31 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 33 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 35 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 37 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 39 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 41 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 43 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 45 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 47 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 49 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 51 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 53 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 55 Sensores en todas partes 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 57 1 Introducción to Wireless Sensor Networks Sensors Everywhere 01 6/9/10 09:58 Página 58 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 61 Chapter 1. Introduction to Wireless Sensor Networks 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 Sensors Everywhere 01 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 unatten- ded 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 Sensors Everywhere 01 6/9/10 09:58 Página 63 Chapter 1. Introduction to Wireless Sensor Networks 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:58 Página 65 Chapter 1. Introduction to Wireless Sensor Networks 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 67 Chapter 1. Introduction to Wireless Sensor Networks 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 69 2 Applications of WSNs and standardization initiatives Sensors Everywhere 01 6/9/10 09:59 Página 70 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 73 Chapter 2. Applications of WSNs and standardization initiatives 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 75 Chapter 2. Applications of WSNs and standardization initiatives 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 77 Chapter 2. Applications of WSNs and standardization initiatives 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 79 Chapter 2. Applications of WSNs and standardization initiatives 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 81 Chapter 2. Applications of WSNs and standardization initiatives 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 83 Chapter 2. Applications of WSNs and standardization initiatives 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 85 Chapter 2. Applications of WSNs and standardization initiatives 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 87 Chapter 2. Applications of WSNs and standardization initiatives 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 89 Chapter 2. Applications of WSNs and standardization initiatives 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 91 Chapter 2. Applications of WSNs and standardization initiatives [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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 93 Chapter 2. Applications of WSNs and standardization initiatives [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 Sensors Everywhere 01 6/9/10 09:59 Página 94 Sensors Everywhere 01 6/9/10 09:59 Página 95 3 Physical layer Sensors Everywhere 01 6/9/10 09:59 Página 96 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 99 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 101 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 103 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 105 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 107 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 109 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 111 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 113 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 115 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 117 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 119 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 121 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 123 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 125 Chapter 3. Physical layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 127 Chapter 3. Physical layer [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 Layer (PHY) Specifications for Low-Rate Wireless Personal Area 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 Sensors Everywhere 01 6/9/10 09:59 Página 128 Sensors Everywhere 01 6/9/10 09:59 Página 129 4 MAC layer Sensors Everywhere 01 6/9/10 09:59 Página 130 Sensors Everywhere 01 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 133 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 135 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 137 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 139 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 141 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 143 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 145 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 147 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 149 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 151 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 153 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 155 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 157 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 159 Chapter 4. MAC layer 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 Sensors Everywhere 01 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 Sensors Everywhere 01 6/9/10 09:59 Página 161 Chapter 4. MAC layer [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 Sensors Everywhere 01 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 Sensors Everywhere 02 2/7/10 13:19 Página 163 5 Sensor node platforms Sensors Everywhere 02 2/7/10 13:19 Página 164 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 167 Chapter 5. Sensor node platforms 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 169 Chapter 5. Sensor node platforms 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 171 Chapter 5. Sensor node platforms 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 173 Chapter 5. Sensor node platforms 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 175 Chapter 5. Sensor node platforms 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 177 Chapter 5. Sensor node platforms 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 179 Chapter 5. Sensor node platforms • 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 181 Chapter 5. Sensor node platforms 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 183 Chapter 5. Sensor node platforms 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 185 6 Topology control Sensors Everywhere 02 2/7/10 13:19 Página 186 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 189 Chapter 6. Topology control 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 191 Chapter 6. Topology control 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 193 Chapter 6. Topology control 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 195 7 Routing Sensors Everywhere 02 2/7/10 13:19 Página 196 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 218 Sensors Everywhere 02 2/7/10 13:19 Página 219 8 Transport Sensors Everywhere 02 2/7/10 13:19 Página 220 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 223 Chapter 8. Transport • 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 225 Chapter 8. Transport 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 227 Chapter 8. Transport 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 229 Chapter 8. Transport 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 231 Chapter 8. Transport 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 233 Chapter 8. Transport 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 Sensors Everywhere 02 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 Table 8.1. Main characteristics of transport protocols for congestion control (adapted from [7]) 234 Sensors Everywhere 02 2/7/10 13:19 Página 235 Chapter 8. Transport 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 237 Chapter 8. Transport 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 239 Chapter 8. Transport 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 241 Chapter 8. Transport 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 243 Chapter 8. Transport 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 Sensors Everywhere 02 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 Table 8.4. Main characteristics of transport protocols for congestion 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 Sensors Everywhere 02 2/7/10 13:19 Página 245 Chapter 8. Transport 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 247 Chapter 8. Transport 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 Sensors Everywhere 02 2/7/10 13:19 Página 248 Sensors Everywhere 02 2/7/10 13:19 Página 249 9 Security Sensors Everywhere 02 2/7/10 13:19 Página 250 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 security is used. The last field, denoted by MAC, is the Message 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 Sensors Everywhere 02 2/7/10 13:19 Página 258 Sensors Everywhere Fig. 9.2. Payload of the ZigBee frame (MAC payload), when NWK layer security is used. The last field, denoted by MAC, is the Message Authentication Code. The size of each field is expressed in bytes 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 security is used. The last field, denoted by MAC, is the Message Authentication Code. The size of each field is expressed in bytes 258 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 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 Sensors Everywhere 02 2/7/10 13:19 Página 267 Chapter 9. Security Fig. 9.10. Message sequence for a device that leaves a secure ZigBee network, initiated by the device itself Fig. 9.11. Message sequence for a device that leaves a secure ZigBee 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 Sensors Everywhere 02 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 Layer (PHY) Specifications for Low-Rate Wireless Personal Area 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. Sensors Everywhere 02 2/7/10 13:19 Página 269 Chapter 9. Security [6] IEEE Computer Society, "IEEE Std. 802.15.4-2006", September 2006. [7] C. Bormann, D. Sturek, Z. Shelby, “6LowApp: Problem Statement for 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 Sensors Everywhere 02 2/7/10 13:19 Página 270 Sensors Everywhere 03 6/9/10 10:15 Página 271 10 Operating systems Sensors Everywhere 03 6/9/10 10:15 Página 272 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:15 Página 275 Chapter 10. Operating systems 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:15 Página 277 Chapter 10. Operating systems 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:15 Página 279 Chapter 10. Operating systems [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 Sensors Everywhere 03 6/9/10 10:15 Página 280 Sensors Everywhere 03 6/9/10 10:15 Página 281 11 Wireless sensor network architectures and techologies Sensors Everywhere 03 6/9/10 10:15 Página 282 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 285 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 287 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 289 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 291 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 293 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 295 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 297 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 299 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 301 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 303 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 305 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 307 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 309 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 311 Chapter 11. Wireless sensor network architectures and technologies 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 313 Chapter 11. Wireless sensor network architectures and technologies [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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 315 Chapter 11. Wireless sensor network architectures and technologies [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 Sensors Everywhere 03 6/9/10 10:16 Página 316 Sensors Everywhere 03 6/9/10 10:16 Página 317 12 Sensed data management Sensors Everywhere 03 6/9/10 10:16 Página 318 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 321 Chapter 12. Sensed data management 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:16 Página 323 Chapter 12. Sensed data management 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 325 Chapter 12. Sensed data management 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 327 Chapter 12. Sensed data management 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 329 Chapter 12. Sensed data management [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 Sensors Everywhere 03 6/9/10 10:17 Página 330 Sensors Everywhere 03 6/9/10 10:17 Página 331 13 Interoperability between wireless sensor networks and other networks Sensors Everywhere 03 6/9/10 10:17 Página 332 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 335 Chapter 13. Interoperability between wireless sensor networks and other networks 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 337 Chapter 13. Interoperability between wireless sensor networks and other networks 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 339 Chapter 13. Interoperability between wireless sensor networks and other networks 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 341 Chapter 13. Interoperability between wireless sensor networks and other networks 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 343 Chapter 13. Interoperability between wireless sensor networks and other networks 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 345 Chapter 13. Interoperability between wireless sensor networks and other networks 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 347 Chapter 13. Interoperability between wireless sensor networks and other networks 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 Sensors Everywhere 03 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. [12] C. Bormann, D. Sturek, Z. Shelby, “6LowApp: Problem Statement for 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 Sensors Everywhere 03 6/9/10 10:17 Página 349 Chapter 13. Interoperability between wireless sensor networks and other networks [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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:17 Página 351 Chapter 13. Interoperability between wireless sensor networks and other networks [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 Sensors Everywhere 03 6/9/10 10:17 Página 352 Sensors Everywhere 03 6/9/10 10:17 Página 353 14 Energy consumption and harvesting Sensors Everywhere 03 6/9/10 10:17 Página 354 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Table 14.1. Definition of parameters of a power consumption model in 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) Sensors Everywhere 03 6/9/10 10:17 Página 357 Chapter 14. Energy consumption and harvesting 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 Sensors Everywhere 03 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 Table 14.3. Definition of parameters of a power consumption model in data processing 358 Sensors Everywhere 03 6/9/10 10:18 Página 359 Chapter 14. Energy consumption and harvesting 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:18 Página 361 Chapter 14. Energy consumption and harvesting 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:18 Página 363 Chapter 14. Energy consumption and harvesting 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:18 Página 365 Chapter 14. Energy consumption and harvesting 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:18 Página 367 Chapter 14. Energy consumption and harvesting [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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:18 Página 369 15 Localization techniques and wireless sensor networks Sensors Everywhere 03 6/9/10 10:18 Página 370 Sensors Everywhere 03 6/9/10 10:18 Página 371 Chapter 15. Localization techniques and wireless sensor networks 15. Localization techniques and wireless sensor networks 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:18 Página 373 Chapter 15. Localization techniques and wireless sensor networks 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:18 Página 375 Chapter 15. Localization techniques and wireless sensor networks 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:19 Página 377 Chapter 15. Localization techniques and wireless sensor networks 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:19 Página 379 16 Middleware Sensors Everywhere 03 6/9/10 10:19 Página 380 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:19 Página 383 Chapter 16. Middleware 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:19 Página 385 Chapter 16. Middleware 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:19 Página 387 Chapter 16. Middleware 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:19 Página 389 Chapter 16. Middleware 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:19 Página 391 Chapter 16. Middleware 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 Sensors Everywhere 03 6/9/10 10:19 Página 392 Sensors Everywhere 03 6/9/10 10:19 Página 393 17 Future directions in wireless sensor networks Sensors Everywhere 03 6/9/10 10:19 Página 394 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 6/9/10 10:19 Página 399 GLOSSARY Sensors Everywhere 03 6/9/10 10:19 Página 400 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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 Sensors Everywhere 03 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