evaluación del rendimiento en el nivel de red rpl en...

Evaluación del Rendimiento en el nivel de red RPL en WSN

Equation Chapter 1 Section 1

Trabajo Fin de Grado

Ingeniería de Telecomunicación

Evaluación del rendimiento en el nivel de red RPL

en WSN

Autor: Antonio Morillo Canalejo

Tutor: Rafael María Estepa Alonso

Dpto. Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2017

Evaluación del rendimiento en el nivel de red RPL en WSN


iii

Trabajo Fin de Grado

Ingeniería de Telecomunicación

Evaluación del rendimiento en el nivel de red RPL

en WSN

Autor:

Antonio Morillo Canalejo

Tutor:

Rafael María Estepa Alonso

Profesor titular

Dpto. Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2017


v

Trabajo Fin de Grado: Evaluación del rendimiento en el nivel de red RPL en WSN

Autor: Antonio Morillo Canalejo

Tutor: Rafael María Estepa Alonso

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2017

El Secretario del Tribunal


vii

A mis padres, a mi abuela y a todos mis

amigos que nunca dejaron que me rindiera, el

esfuerzo mereció la pena.

Cree en ti mismo y todo lo que eres. Reconoce

que hay algo dentro de ti que es más grande

que cualquier obstáculo.

Christian D. Larson


ix

Agradecimientos

Este trabajo refleja todos estos años en los que cada gota de sudor cuenta para conseguir la meta que uno se

propone, es por eso que mientras escribo este fragmento no puedo evitar acordarme principalmente de mis

padres, quienes siempre han estado apoyándome cada vez que me desanimaba y no quería continuar con mis

estudios, y por todos esos sacrificios que han hecho por verme llegar a donde estoy.

También a mis amigos que conocí al empezar el primer año de curso. Cada uno de ellos me ha aportado esas

ganas para continuar con mis sueños, conseguir mis metas y superar cada obstáculo que encontraba en la

carrera, porque sin su apoyo diario, esto nunca hubiera sido posible.

Agradecer a mi gran amigo Miguel Nájera Benítez, con el que he compartido muchísimas vivencias y

experiencias durante todos estos años y no nos separamos ante nada. Gracias por todos esos sabios consejos

que me has dado.

Acordarme de Reyes, quien siempre me ha animado y se ha mantenido a mí lado en los momentos difíciles

durante la elaboración de este proyecto.

A mis compañeros del karate, los cuales aguantaban mis días en los que necesitaba desahogarme y agradecer

también a todas las personas que me he cruzado durante estos siete años de mi etapa en la universidad. Daros

las gracias por cada granito de arena aportado.

Por último, agradecer profundamente a mi tutor Rafael Estepa Alonso, por sus consejos y su ayuda en todo el

proceso de desarrollo y por todo el conocimiento transmitido a lo largo de la carrera.

Antonio Morillo Canalejo

Sevilla, 2017


xi

Resumen

Desde que, en 2010 el MIT identificase las redes de sensores inalámbricas (WSN) como una de las

tecnologías más punteras por desarrollar, sus avances e investigaciones en numerosos campos han

ido en aumento casi de forma descontrolada, puesto que permiten cubrir las características de una

comunicación flexible (tiempo y espacio) y autónoma (autoconfiguración e independencia de una

estructura fija).

Gracias al desarrollo del IoT (Internet of Things), las redes de sensores inalámbricos han adquirido

un papel fundamental en las actividades de la vida diaria permitiendo conectar dispositivos

inteligentes de bajo coste y fácil implementación con protocolos estandarizados como IEEE 802.15.4

(capa enlace), 6LoWPAN (capa de red), RPL como protocolo de encaminamiento, CoAP (capa de

transporte) y MQTT (capa de aplicación), entre otros.

Para la realización de este trabajo de fin de grado se pretende realizar un estudio teórico/práctico de

un conjunto de sensores desplegados en una red WSN implementados por el protocolo de capa de

red RPL, añadiendo también la gran ventaja que aporta IoT junto con el protocolo de comunicación

6LoWPAN.

El objetivo final será observar, obtener y evaluar el rendimiento, evolución y posible ahorro

energético de cada uno de los sensores, así como las múltiples ventajas y limitaciones encontradas en

la creación y despliegue de una red de este tipo, así como en la programación de los nodos sensores.

Los resultados que se han obtenido para el desarrollo del presente trabajo empleando la metodología

posteriormente descrita, han permitido verificar que los protocolos 6LoWPAN y RPL son pilares

fundamentales para una red WSN eficiente y sólida.


Abstract

In 2010, MIT identified wireless sensors networks (WSN), one of the most advanced technologies to

develop, progress and research in many fields, it has been increasing almost out of control, because

they cover features related with a flexible communication (time and space) and range (a self-

configuration and an independence of a fixed structure).

Thanks to the concept of Internet of Things (IoT), WSNs have got a fundamental role in daily living

activities, allowing you to connect smart devices with low cost and easy implementation with

standarized protocols such as IEEE 802.15.4 (link layer), 6LoWPAN (network layer), RPL as

routing protocol, CoAP (transport layer) and MQTT (application layer), among others.

To carry out this final project, it’s going to perform a theorist/practical study related with a set of

sensors inside of a RPL Network, they are implementing the advantages of IoT with 6LoWPAN and

RPL, so the results are to observe, collect and evaluate the performance, evolution and energy

savings for the group of sensors as well as different advantages and limitations found in the design

and deployment of the WSN, as well as in the sensor nodes programming.

The results that have been obtained during the development of this work which uses the methodology that it

will be described later, it is allowed us to verify that the 6LoWPAN and RPL protocols are fundamental issues

for an efficient and robust WSN network.


xiii

Índice

Agradecimientos ix

Resumen xi

Abstract xii

Índice xiii

Índice de Tablas xvi

Índice de Figuras xvii

1 Introducción 11 1.1. Motivación 11 1.2. Objetivos 12 1.3. Estructura de la memoria 12

2 Redes WSN 14 2.1. Introducción 14 2.2. Aplicaciones 15

2.2.1. Asistencia médica por control remoto 15 2.2.2. Monitorización medioambiental 15 2.2.3. Monitorización preventiva 15 2.2.4. Agricultura 15 2.2.5. Automatización de edificios 16 2.2.6. Medición de contadores 16 2.2.7. Smart Cities 16 2.2.8. Ámbito militar 16

2.3. Características de diseño 17 2.3.1. Tolerancia a fallos 17 2.3.2 Escalabilidad 17 2.3.3 Costes de producción 18 2.3.4 Entorno de operación 18 2.3.5 Topología 18 2.3.6 Restricciones hardware 19 2.3.7 Medio de transmisión 19 2.3.8 Consumo energético 20

2.4. Estandarización de las redes de sensores 21 2.4.1. IEEE 802.15.4 21

2.5. Arquitectura Hardware 27 2.5.1. Nodos sensores 27 2.5.2. Gateway 33 2.5.3. Estación base 33 2.5.4. Topologías en una red WSN 33 2.5.5. Modelos de tráfico 36 2.5.6. Políticas para la selección de una ruta eficiente 37


3 Encaminamiento en redes WSN 40 3.1. Algoritmos de enrutamiento 43 3.2. Factores que afectan a los protocolos de encaminamiento 41 3.3. Clasificación de los protocolos de enrutamiento 44

3.3.1. Protocolos de estructura de red 46 3.3.2. Protocolos de modelo de comunicación 46 3.3.3. Protocolos basados en la topología 47 3.3.4. Protocolos de enrutamiento fiables 47

4 Arquitectura Software 49 4.1. Sistemas Operativos 49

4.1.1. TinyOS 51 4.1.2. ContikiOS 52 4.1.3. FreeRTOS 52 4.1.4. MantisOS 53 4.1.5. Nano-RK 53

5 Protocolo 6LoWPAN 55 5.1. Protocolo ZigBee 55 5.2. Protocolo 6LOWPAN 56

5.2.1. Pila de protocolos 58 5.2.2. Funcionalidad 58 5.2.3. Formato de transmisión 59 5.2.4. Direccionamiento mallado o mesh addressing 60 5.2.5. Fragmentación y reensamblado 60 5.2.6. Compresión de cabeceras 61 5.2.7. Descubrimiento de vecinos 63 5.2.8. Encaminamiento 64 5.2.9. Seguridad 65

6 Protocolo RPL 67 6.1. Diseño del protocolo 67 6.2. Topología usada 68 6.3. Flujo de tráfico en RPL 71

6.3.1 Storing Mode 71 6.3.2. Non-Storing Mode 72

6.4. Mensajes de control ICMPv6 RPL 73 6.4.1. DODAG Information Object (DIO) 74 6.4.2. Algoritmo Trickle 77 6.4.3. Destination Advertisement Object (DAO) 78

7 Simulación y evaluación de una red WSN 81 7.1. Selección de motas 87 7.2. Implementación de Contiki con la Z1 mote 88 7.3. Definición de aplicaciones en la mota Z1 92

7.3.1. Aplicación dispositivo móvil 92 7.3.2. Aplicación nodo WSN 96 7.3.3. Aplicación sumidero RPL 101

7.4. Herramienta Powertrace 104 7.4.1. Funcionamiento 105 7.4.2. Código implementado por la herramienta 108

7.5. Simulador Cooja 81 7.5.1. Crear una simulación 82


xv

7.6. Escenarios de simulación 85 7.6.1. Escenario 1 115 7.6.1.1. Gráficas de los estados del nodo frontera (id 4) 117

7.6.1.2. Gráficas de los estados del nodo sumidero (id 5) 125 7.6.2. Escenario 2 131

7.6.2.1. Gráficas de los estados del nodo sumidero (id 9) 132 7.6.2.2. Gráficas de los estados del primer nodo frontera (id 7) 139 7.6.2.3. Gráficas de los estados del segundo nodo frontera (id 8) 145

7.7. Extracción, modelado y representación de datos 152

8 Conclusiones 158 8.1. Líneas de avance 159

Referencias 160

Glosario 164

Anexo A. Tabla de protocolos de encaminamiento 162

Anexo B. Directorios en Contiki 171


ÍNDICE DE TABLAS

Tabla 2-1. Comparación de BLE con otros estándares 26

Tabla 2-2. Transceptores de radiofrecuencia 29

Tabla A-1. Flat Routing 162

Tabla A-2. Hierarchical Routing 163

Tabla A-3. Query-Based Routing 164

Tabla A-4. Coherent and Non-Coherent-Based Routing 165

Tabla A-5. Negotiation-Based Routing 166

Tabla A-6. Location-Based Routing 167

Tabla A-7. Mobile Agent-Based Routing 168

Tabla A-8. Multipath-Based Routing 169

Tabla A-9. QoS-Based Routing 170


xvii

ÍNDICE DE FIGURAS

Figura 1 0. Ejemplo de escenario WSN 25

Figura 2-1. Ejemplo de escenario WSN 27

Figura 2-2. Componentes de un nodo WSN 28

Figura 2-3. Tipos de sensores 31

Figura 2-4. Topología en estrella 34

Figura 2-5. Topología en malla 34

Figura 2-6. Topología hibrida estrella-malla 35

Figura 2-7. Modelos de tráfico en WSNs 36

Figura 3-8. Clasificación de protocolos de enrutamiento en WSNs 45

Figura 4-9. Capas de abstracción 50

Figura 5-10. Pila de protocolos ZigBee 55

Figura 5-11. Ejemplo de red WSN implementado con 6LoWPAN 57

Figura 5-12. Pila protocolos 6LoWPAN frente IPv6 58

Figura 5-13. Formato mensaje 6LoWPAN 59

Figura 5-14. Cabecera capa de adaptación 6LoWPAN 59

Figura 5-16. Formato cabecera continuación fragmentos 60

Figura 5-15. Formato cabecera 1er fragmento 60

Figura 5-17. Compresión de cabeceras HC1-HC2 61

Figura 5-18. Compresión de cabeceras IPHC-NHC 62

Figura 5-19. Procedimiento 6LoWPAN-ND 63

Figura 6-20. Formación grafo DODAG 70

Figura 6-21. Funcionamiento en modo storing 72

Figura 6-22. Funcionamiento en modo non-storing 73

Figura 6-23. Mensaje de control RPL 74

Figura 6-24. Formato de un mensaje DIO 74

Figura 6-25. Tipos de MOP 75

Figura 6-26. Configuración de un mensaje DODAG 76

Figura 6-27. Formato mensaje DAO 78

Figura 7-28. Interfaz gráfica de Cooja 82

Figura 7-29. Creando un escenario de simulación 82

Figura 7-30. Plugins implementados en Cooja 84

Figura 7-31. Carga de aplicaciones en los nodos (I) 84

Figura 7-32. Carga de aplicaciones en los nodos (II) 85

Figura 7-33. Aspecto de un Z1 Mote 87


Figura 7-34. Configuración de los drivers en los Z1 mote 89

Figura 7-35. Torre de protocolos del rol de cada mota Z1 91

Figura 7-36. Diagrama de flujo de la aplicación envia.c 92

Figura 7-37. Definición de las direcciones IPv6 93

Figura 7-38. Creación del conector 94

Figura 7-39. Datos del conector 94

Figura 7-40. Diagrama función unicast_send () de envia.c 95

Figura 7-41. Diagrama de flujo de la aplicación recibe.c 96

Figura 7-42. Definición de direcciones IPv6 en recibe.c 97

Figura 7-43. Creación de los conectores recibe_conn y client_rpl_conn 98

Figura 7-44. Datos del conector recibe_conn 98

Figura 7-45. Datos del conector client_rpl_conn 98

Figura 7-46. Diagrama función tcpip_handler() de recibe.c 99

Figura 7-47. Diagrama función send_packet() de recibe.c 100

Figura 7-48. Diagrama de flujo de la aplicación sink.c 101

Figura 7-49. Asignación de IPv6 al nodo sumidero 102

Figura 7-50. Creación del conector rpl_server_conn 103

Figura 7-51. Datos del conector rpl_server_conn 103

Figura 7-52. Diagrama del funcionamiento tcpip_handler 104

Figura 7-53. Rastreo de estados de potencia de la herramienta Powertrace 105

Figura 7-54. Proceso de envío de paquetes usando ContikiMAC 106

Figura 7-55. Obtención de medidas de la herramienta Powertrace 107

Figura 7-56. Proceso powertrace 108

Figura 7-57. Funciones para ejecutar y parar la aplicación Powertrace 109

Figura 7-58. Rastreo y obtención de la estimación energética de las capsulas de energía 110

Figura 7-59. Representación de valores de energía calculados para cada estado 112

Figura 7-60. Comprobación de pila de protocolos 113

Figura 7-61. Representación de información extra de cada nodo 114

Figura 7-62. Escenario de la simulación 1 115

Figura 7-63. Ejecución del escenario de la simulación 1 116

Figura 7-64. Representación temporal del estado de la CPU en modo activo y LPM del nodo 4 117

Figura 7-65. Representación temporal del estado de TX del nodo 4 (I) 118

Figura 7-66. Representación temporal del estado de TX (II) 119

Figura 7-67. Muestra de transmisión dispositivo móvil al nodo 4 119

Figura 7-68. Muestra de transmisión del nodo 4 al nodo 5 120

Figura 7-69. Representación temporal del estado de RX del nodo 4 120

Figura 7-70. Representación temporal del estado de la radio transmitida del nodo 4 (I) 121

Figura 7-71. Representación temporal del estado de la radio transmitida del nodo 4 (II) 122

Figura 7-72. Representación temporal del estado de la radio recibida del nodo 4 124


xix


Figura 7-74. Representación temporal del estado de TX 126

Figura 7-75. Muestra de transmisión de mensajes de control del nodo 5 al nodo 4 126


Figura 7-77. Representación temporal del estado de la radio transmitida del nodo 5 128

Figura 7-78. Representación temporal del estado de la radio recibida (I) 129

Figura 7-79. Representación temporal del estado de la radio recibida (II) del nodo 5 129

Figura 7-80. Estimación de energía de transmisión de los nodos de la red WSN del escenario 1 130

Figura 7-81. Escenario de la simulación 2 131


Figura 7-83. Representación temporal del estado de TX del nodo 9 133

Figura 7-84. Muestra de transmisión de mensajes de control del nodo 9 al nodo 7 y 8 134




Figura 7-88. Representación temporal del estado de la radio recibida del nodo 9 (I) 137

Figura 7-89. Representación temporal del estado de la radio recibida del nodo 9 (II) 138

Figura 7-90. Representación temporal del estado de la CPU en modo activo del nodo 7 139


Figura 7-92. Muestra de transmisión del nodo 7 al nodo sumidero 141


Figura 7-94. Representación temporal del estado de la radio transmitida del nodo 7 142

Figura 7-95. Representación temporal del estado de la radio recibida del nodo 7 144

Figura 7-96. Representación temporal del estado de la CPU en modo activo del nodo 8 145


Figura 7-98. Muestra de transmisión del nodo 8 al nodo sumidero 146


Figura 7-100. Muestra de recepción de los dispositivos móviles al nodo 8 148



Figura 7-103. Representación temporal del estado de la radio recibida del nodo (I) 150

Figura 7-104. Representación temporal del estado de la radio recibida del nodo 8 (II) 150

Figura 7-105. Estimación de energía de transmisión de los nodos 7 y 8 de la red WSN del escenario 2 (I)

151

Figura 7-106. Estimación de energía de transmisión del nodo 9 de la red WSN del escenario 2 (II) 151

Figura 7-107. Parte del código implementado en el script data_filter.sh 152

Figura 7-108. Función etl_datos_mota del script etl.py 153

Figura 7-109. Función etl_datos_proto del script etl.py 154

Figura 7-110. Ficheros generados de la primera simulación 154


Figura 7-111. Función plotting_state_mota del script plotting.py 155

Figura 7-112. Función plotting_energy_mota del script plotting_energy.py 156

Figura B-113. Estructura de carpetas de Contiki 1171


xxi


1 Introducción

a aparición de las redes WSNs ha supuesto un gran avance dentro de las tecnologías

inalámbricas ya existentes (Bluetooth, GPS, radiofrecuencia o WiFi, entre otros), que con el

fuerte auge y los avances en el campo del IoT ha supuesto una gran revolución tecnológica a nivel

mundial.

Cada vez más, la tendencia se enfoca en sistemas autónomos que trabajen por sí mismos y se

encuentren todos interconectados entre sí, pudiendo acceder al estado de cada uno sin necesidad de

tener tangible el dispositivo físico. Es por lo que este tipo de redes se definen como un concepto

relativamente nuevo dentro de la adquisición y tratamiento de datos, relacionándose con el

paradigma de los agentes inteligentes1 en busca del “entorno inteligente”.

Hay que tener en cuenta que hace unos 20 años, los que conocían Internet lo usaban principalmente

como herramienta para acceder a la información, mientras que, en los últimos 10 años, la evolución

de Internet ha sido de 360º, convirtiéndose todo en social, transaccional y móvil. Debido a los

cambios y aparición de nuevos modelos de negocios, productos y compañías que apuestan por el

ámbito del IoT, surge el interés especial en las redes WSNs por el amplio abanico de posibilidades

que pueden brindarse.

1.1. Motivación

El motivo de la realización de este trabajo es comprender cómo funciona una red WSN y los

elementos que la conforman. Estudiar la evolución de las redes que, de estar compuesta por un

número limitado de nodos conectados por medio de un cable a un equipo central, se han pasado a

usarse nodos que implementan mecanismos distribuidos más pequeños, baratos, de menor consumo,

capaces de procesar datos de forma local y transferirlos de manera inalámbrica.

La tecnología implementada en los sensores que se despliegan en estas redes ha cambiado

rápidamente, siendo capaces de asimilar las características de los sistemas embebidos hasta el punto

de que su comportamiento sea muy parecido al de un nodo computacional, y llegando incluso a

incorporar capacidades cognitivas y de comunicación para establecer redes inalámbricas con nodos

sensores que manejen un gran volumen de información a gran escala.

Asimismo, este trabajo tiene como propósito entender los protocolos que implementan los

dispositivos a nivel de red, como son el protocolo 6LoWPAN y sobretodo, el estudio del protocolo

de encaminamiento RPL del cual se medirá su rendimiento dentro de la red WSN, además, de cómo

afecta al gasto de energía en la actividad los nodos desplegados ya que la conservación de la energía

en los nodos de esta red ha sido su “talón de Aquiles”.

Por último, mostrar también una visión general de las capas inferiores que implementan los

1 Un agente inteligente, es una entidad capaz de percibir su entorno, procesar tales percepciones y responder o actuar en su entorno de manera racional, es decir, de manera correcta y tendiendo a maximizar un resultado esperado.

L

Dentro de 15 años se habrá instalado totalmente el

nuevo "Internet", irá por vía satélite y WiFi.

- Bill Gates -


12

dispositivos de la red WSN.

1.2. Objetivos

Los objetivos de este proyecto son:

Comprender los fundamentos teóricos de una red WSN, los protocolos normalizados que

se implementan y los aspectos más importantes para desplegar una red de este tipo.

Estudiar el sistema operativo ContikiOS que permite programar las funciones de cada

dispositivo dentro de una red WSN, así como cargar toda la configuración de las distintas

capas de protocolos y embeberlo todo dentro de cada nodo sensor.

Analizar la integración de los protocolos RPL y 6LoWPAN a nivel de red y cómo

condicionan a cada nodo de la red WSN en la decisión de rutas y comunicación entre ellos.

Simular una red WSN utilizando nodos configurados mediante un hardware virtual

para emular el comportamiento de los dispositivos reales.

1.3. Estructura de la memoria

La estructuración de este trabajo se ha repartido en ocho capítulos:

En el primer capítulo se pretende hacer una breve y concisa introducción sobre el tema que

pretende desarrollarse en el presente trabajo, así como los objetivos y la organización del

mismo.

En el segundo capítulo se presenta una visión general de las redes WSN resaltando sus

posibles aplicaciones, qué características hay que tener en cuenta al diseñarlas, el protocolo

que las estandariza y su arquitectura hardware.

El tercer capítulo se centra en el encaminamiento que se usa en este tipo de redes, los

algoritmos que implementan, los factores que afectan a la decisión de un protocolo de

encaminamiento y, para terminar, se expone una clasificación de los tipos de protocolos de

encaminamientos existentes.

En el cuarto capítulo, se explica la arquitectura software en la que se basan los nodos de una

red WSN y se describen los sistemas operativos más importantes que hoy día se

implementan, mostrando al final un cuadro comparativo donde se resaltan las principales

características de cada uno de ellos.

En el quinto capítulo, se desarrolla el protocolo de comunicación 6LoWPAN empleado para

conectar los nodos entre sí dentro de la red WSN resaltando los aspectos más importantes


13

como es el formato de transmisión, su direccionamiento con IPv6, su fragmentación y

reensamblado, su compresión de cabeceras, su descubrimiento de vecinos, su

encaminamiento y, por último, se realiza una pincelada acerca de la seguridad de este

protocolo.

En el sexto capítulo, se presenta el protocolo de encaminamiento RPL, los motivos por los

que fue diseñado, la topología que utiliza, el flujo de tráfico implementado y los mensajes de

control que se intercambian los nodos que incorporan este protocolo en su pila.

En el séptimo capítulo, se analiza el comportamiento de una red WSN. Para ello, se

seleccionará un tipo de mota, en concreto las del proveedor Zolertia. Se estudiará cómo

implementarla con el sistema operativo elegido y se crearán las aplicaciones que harán

funcionar estos dispositivos. Además, se explicará la herramienta Powertrace para obtener las

medidas temporales sobre el comportamiento de las motas y se simularán dos escenarios de

prueba para estudiar los datos obtenidos.

En el último capítulo, se exponen las conclusiones alcanzadas en la realización de este

proyecto, los aspectos que más dificultades han presentado y una visión sobre cómo orientar

a la realización de posibles mejoras.

Por último, se adjuntan un conjunto de anexos donde se pretende mostrar una visión más detallada de

los distintos protocolos de encaminamiento existentes en este tipo de redes.


14

2 Redes WSN

n este capítulo se explica el concepto de red WSN, las aplicaciones con las que actualmente

este tipo de redes pueden ser de gran utilidad, las características más importantes que deben

tenerse en cuenta al crear una red como ésta, así como las fases de despliegue y mantenimiento.

También se presenta el protocolo que proporciona soporte a nivel de enlace y por la que es posible

desplegar las redes WSN. Además, de la arquitectura hardware, los distintos tipos de topología

existente, el tipo de tráfico que puede usar y las políticas de selección de rutas para hacer lo más

eficiente a estos tipos de redes.

2.1. Introducción

Una red de sensores WSN se define como un conjunto de nodos sensores inalámbricos que presentan

una capacidad de energía limitada. Son capaces de monitorizar las magnitudes físicas de un entorno,

el cuál puede estar sujeto a cambios donde los datos recogidos de dicho medio pueden ser enviados a

uno o más nodos de la red. Éstos serán nodos de tipo sumidero y son los encargados de recolectar la

información obtenida llevando a cabo tareas programadas en respuesta a dichos datos.

Como consecuencia de estos cambios, debe escogerse una buena estrategia de orientación que

conlleve un envío eficiente de paquetes a su destino, ya que hay que tener en cuenta que los nodos

pueden ser móviles o estacionarios. Además, en casi todas las redes, esta estrategia tiene que

asegurar un consumo de energía mínimo para conseguir maximizar el tiempo de vida de la red.

Las primeras redes inalámbricas de sensores fueron diseñadas y desarrolladas a mediados de los años

70 con un propósito militar. Las WSNs se usaron por primera vez durante la guerra de Vietnam con

el objetivo de detectar y encontrar al ejército vietnamita, oculto en las zonas más remotas de la

jungla. Sin embargo, esta primera implementación originó demasiados problemas a causa del tamaño

de los sensores, el consumo de energía y el alcance limitado de la red.

Desde entonces, se ha trabajado mucho en el desarrollo de las redes WSNs destacando el diseño de

diferentes protocolos de enrutamiento orientados a la eficiencia energética, en función de la

arquitectura de red implementada y sus características especiales.

E

Internet es el primer invento de la humanidad que la

humanidad no entiende. El mayor experimento de

anarquía que hemos tenido

- Eric Schmidt -


15

2.2. Aplicaciones

Debido al desarrollo de las tecnologías y a proyectos como “SmartDust”, se ha conseguido asentar

las bases de las redes de sensores tanto a nivel conceptual como tecnológico. Casi al instante, la

aparición de nuevas aplicaciones ha obligado a nuevos requerimientos a nivel electrónico,

computacional y de bajo coste en la tecnología.

Actualmente, el mercado en el que es necesario implementar dichas redes WSNs resulta bastante

amplio.

A continuación, se presentan las aplicaciones más comunes que se han extraído de la referencia x.

Asistencia médica por control remoto: El uso de sensores capaces de medir parámetros

biométricos en personas que padezcan problemas de salud (ancianos, discapacitados,

personas con problemas de corazón, etc) puede permitir obtener un diagnóstico más

preciso, incluso una monitorización remota de forma constante acerca del estado de

salud, permite alertar a los servicios de emergencia y que éstos sean capaces de actuar

más rápidamente logrando salvar más vidas.

Monitorización medioambiental: Gracias al tamaño diminuto de estos dispositivos y la

gran autonomía que les confiere, permite que los sensores sean los elementos más ideales

para poder monitorizar cualquier entorno debido a que pueden camuflarse fácilmente.

Hoy día, son usados para la detección de fuegos en bosques porque permiten informar del

origen exacto del fuego a los usuarios o a las autoridades pertinentes, evitando así que se

extienda de forma descontrolada.

Otra implementación es colocar estos dispositivos en animales para así estudiar sus

hábitos o rutinas y comprobar la evolución que desarrollan a lo largo de un tiempo

determinado, puesto que los nodos pueden tener implementados células solares que hacen

que su autonomía sea mucho más duradera.

Monitorización preventiva: La aplicación de sensores a infraestructuras complejas

como son los sistemas mecánicos permite predecir la rotura de piezas o incluso el colapso

de un puente. Para ello, se implementan sensores que recogen vibraciones,

desplazamientos o niveles de temperatura, donde posteriormente con la ayuda de

software se extrapolará la información recogida.

Agricultura: La capacidad de predecir el momento exacto de regar un cultivo en zonas

con escasez de agua, impedir infecciones de hongos en plantas u obtener el nivel de

radiación solar adecuado para determinar el grado de madurez y proceder así a la

recolecta de la plantación, supone una mejora en la productividad agrícola, es por eso

que, gracias a este progreso en las técnicas de la agricultura se esté implantando más

frecuentemente esta tecnología.


16

Automatización de edificios: En lugares como oficinas, hospitales o edificios de

carácter público es habitual encontrar sensores, actuadores y dispositivos que han de

controlarse, La problemática de estos mecanismos, es que resulta costoso intentar regular

la climatización o tener una apropiada iluminación en todo momento. Para solventar

estos inconvenientes, con la instauración de sensores de una red WSN todos los controles

pueden llevarse a cabo mediante un solo nodo sensor, facilitando, mejoras de

funcionamiento y reducción de costes.

Medición de contadores: Muchas empresas dedicadas al suministro de agua, gas o

electricidad deciden instalar este tipo de sensores puesto que no solo permite obtener una

lectura de los contadores de cada uno de sus clientes, sino que también proporciona la

posibilidad de que, a través de estas redes, se acceda a una útil y beneficiosa interacción

con los equipos del cliente, con el objetivo de realizar un control de la demanda más

personalizada a través de servicios adicionales.

Smart Cities: Las redes de sensores WSNs se consideran las más adecuadas para

monitorizar y llevar a cabo una gestión urbana que englobe aspectos tan diversos como la

gestión de zonas verdes, recogida de basuras, transporte público, alcantarillado e

iluminación. Todo esto, permite una mejor organización del personal y conseguir mejorar

la imagen que se ofrece al ciudadano y a los turistas.

Ámbito militar: La capacidad de despliegue y las características de organización

automática y de tolerancia a fallos de las WSNs, permiten otorgarle un uso en el ámbito

militar ya sea para control, comunicaciones, informática, inteligencia, vigilancia,

reconocimiento o seguimiento. Algunas de estas aplicaciones son:

o Supervisión de fuerzas amigas

o Equipamiento y munición

o Vigilancia en el campo de batalla

o Reconocimiento del terreno y de fuerzas enemigas

o Evaluación de daños en incursiones

o Detección de ataques nucleares, biológicos y de sustancias químicas.


17

2.3. Características de diseño

Un buen diseño de cualquier red WSN es crucial para evitar que se originen problemas relacionados

con la tolerancia a fallos, la escalabilidad, los costes de producción, el entorno de operación, la

topología de red, las restricciones hardware, el medio de transmisión o el consumo de energía. Por lo

tanto, se va a proceder al estudio de estos factores (véase referencia 2).

2.3.1. Tolerancia a fallos

Algunas de las posibles causas que originan el fallo o bloqueo de los nodos sensores se deben a una

carencia energética, a cualquier daño físico recibido o a posibles interferencias en sus

comunicaciones. Todos estos fallos originados en un nodo individual de la red no deben afectar al

funcionamiento global de la red WSN.

La tolerancia puede medirse como fiabilidad Rk(t) y permite mantener el funcionamiento de la red

sin interrupciones, aun cuando se está produciendo fallos en los nodos. El parámetro Rk(t) se modela

a partir de una distribución exponencial que permite alcanzar la probabilidad de que no haya fallo

dentro de un intervalo de tiempo [0, t].

𝑅𝑘(𝑡) = 𝑒(−𝜆𝑘𝑡) [1]

[1] Ecuación tolerancia a fallos

Los parámetros 𝜆𝑘 y t son la tasa de fallo del nodo k y el periodo de tiempo, respectivamente.

Cada aplicación contendrá unos protocolos y algoritmos con un nivel de tolerancia a fallos distinto,

por lo que si se supone un entorno en el que hay nodos sensores desplegados y no existe un nivel de

interferencia apreciable, los protocolos que se implementen serán menos estrictos. En el caso de que

se considere de un entorno crítico para fines militares, la tolerancia a fallos será muy alta porque los

datos que se obtengan serán de vital importancia.

En definitiva, la tolerancia a fallos va a depender de la aplicación que se le otorgue a la red WSN

teniendo dicha característica en cuenta para realizar un buen diseño.

2.3.2 Escalabilidad

Según la aplicación que se le conceda a una red de sensores, el número de nodos a desplegar variará

de cientos, miles e incluso millones. Por consiguiente, los nuevos esquemas deben ser capaces de

trabajar con el número de nodos elegido teniendo presente la alta densidad, definida como:

µ(𝑅) = 𝑁/(𝐴/𝜋𝑅2) [2]

[2] Ecuación de escalabilidad

La ecuación anterior representa el nº de nodos contenidos dentro del radio de transmisión de cada

nodo en la región. El parámetro N es el número de nodos que hay desplegados en la región, y los

términos A y R son el rango de transmisión radio de un nodo.


18

Como conclusión, se puede afirmar que la densidad de nodos necesaria dependerá de la aplicación

que se les asigne a tales nodos.

2.3.3 Costes de producción

Dentro de una red WSN hay un gran número de nodos sensores desplegados. De modo, que el coste

de cada uno de ellos es vital para poder justificar el coste total de la red. Es decir, si dicho coste

superase al despliegue de una red de sensores tradicionales, la red WSN no podrá ser justificada a

nivel de coste.

Hoy en día, un dispositivo radio Bluetooth suele tener un coste alrededor de diez euros, mientras que

un nodo de la red WSN tendría que tener un coste inferior a un euro para que sea factible. Aun así,

estos nodos pueden estar compuestos por una serie de elementos adicionales (sensores integrados o

unidades de procesamiento de datos) que puedan incrementar su valor monetario.

Por consiguiente, el coste de cada nodo será una restricción importante a tener en cuenta en el diseño.

2.3.4 Entorno de operación

El entorno de operación se considera uno de los factores con más importancia que afectará al diseño

de los nodos, puesto que los nodos de una red WSN suelen desplegarse de forma densa y muy cerca

del fenómeno objetivo.

Estos tipos de redes son capaces de operar en entornos muy diversos, ya sea en intersecciones

transitadas, en el interior de máquinas de grandes dimensiones, en el fondo de un océano, dentro de

tornados, en edificios, conectados a animales, en campos de batalla, desagües o ríos.

Todas las situaciones anteriormente descritas obligan a adaptar el diseño del nodo sensor para cada

entorno en particular y no generalizarlo.

2.3.5 Topología

La topología de la red es una tarea difícil y ardua debido a que dependerá de cómo se ha producido el

despliegue de los nodos, ya que algunos de éstos podrán encontrarse desatendidos o inaccesibles,

siendo propensos a fallos o presentando una densidad de transmisión baja.

El mantenimiento y cambio de la topología, se clasificará en tres fases:

Fase previa al despliegue: en el transcurso de esta fase inicial, los nodos pueden ser

desplegados uno a uno alrededor del área objetivo o en masa de manera aleatoria. Esto

permite que puedan ser lanzados desde un avión, entregados en una cáscara de artillería,

cohete o misil, o simplemente ser ubicados por una persona o por un robot.

A lo largo de esta fase, hay que tener sumo cuidado de dónde quedan desplegados los nodos

sensores, puesto que así es posible reducir el coste de instalación, la necesidad de cualquier

organización y planificación previa, además de ser capaces de aumentar la flexibilidad de

arreglo, mejorar la tolerancia a fallos y disponer de una organización más automatizada.


19

Fase posterior al despliegue: El único cambio que se produce en esta etapa es la posición de

los nodos, la cual verá afectada su accesibilidad por el ruido, obstáculos o una posible

congestión.

Fase de despliegue de nodos adicionales: La posibilidad de añadir nuevos nodos puede

deberse a dos motivos:

- Sustituir nodos ya existentes

- Producción de un cambio en la funcionalidad de la red.

Incluir nuevos nodos provoca una nueva reorganización de la red WSN donde habrá que

tener en cuenta las restricciones de consumo energético existentes que quedarán solucionadas

por protocolos de encaminamiento especiales. Dichos protocolos se describirán más adelante.

2.3.6 Restricciones hardware

A pesar de las múltiples ventajas de las WSNs que permiten solucionar una gran cantidad de

problemas y aplicaciones, también existen varias limitaciones que están relacionadas con:

La energía que alimenta a los nodos

El corto rango de transmisión

El reducido ancho de banda

La capacidad limitada de procesamiento y almacenamiento

2.3.7 Medio de transmisión

En redes WSNs la comunicación entre nodos se elaborará mediante enlaces inalámbricos a través de

radiofrecuencia (RF), en vez de usar infrarrojos o comunicación óptica. Las razones son bastantes

sencillas:

Los transmisores ópticos consumen menos energía y proporcionan más seguridad que los

de RF, pero necesitan una línea de visión directa entre transmisor y receptor.

Los transmisores infrarrojos no necesitan antenas de grandes dimensiones, aunque se

encuentran limitados por su capacidad de difusión.


20

Además del tipo de transmisor elegido (en este caso transmisor por radiofrecuencia), el medio de

transmisión debe estar disponible a nivel mundial. Por lo que es esencial conocer que algunas bandas

de frecuencias ya son utilizadas por sistemas de telefonía inalámbricos y redes inalámbricas de área

local (WLANs) y que para las redes WSNs se requieren transceptores de pequeñas dimensiones, bajo

coste y muy baja potencia de transmisión, por lo que las restricciones hardware y el compromiso

entre la eficiencia de la antena y su consumo de energía ha obligado a desarrollar el estándar IEEE

802.15.4, que emplea bandas de 2.4 GHz, 915 MHz y 868 MHz para las comunicaciones gracias a la

facilidad de libertad de transmisión radio, su enorme asignación de espectro y disponibilidad global.

2.3.8 Consumo energético

Los nodos sensores son dispositivos electrónicos de pequeñas dimensiones que desempeñan una

doble función en una red WSN. Por un lado, actúan como fuente de datos y por otro, tienen que

encaminar dichos datos a otros nodos hasta llegar a su destino.

Una de las desventajas de usar un nodo sensor es que viene equipado con una fuente de alimentación

limitada, por ello, en algunas aplicaciones, sustituir esa batería resulta casi imposible porque crea una

fuerte dependencia entre el tiempo de vida útil del nodo sensor y la duración de su batería.

Conservar y gestionar la energía es muy importante en estas redes. Para ello se intentan diseñar

protocolos y algoritmos energéticamente eficientes. Existen protocolos de bajo consumo ya

implementados, pero para que sean eficientes es necesario tener en cuenta otros factores como el

retardo en las comunicaciones y la tasa de transmisión.

La tarea principal de un nodo será detectar eventos, realizar un procesado rápido de los datos

obtenidos en cada evento y, por último, transmitirlo a sus vecinos.

Un nodo sensor de una red WSN consumirá más energía durante el proceso de comunicación de

datos (transmisión y recepción), es por ello que unos niveles altos de ruido pueden causar una

degradación significativa aumentando la complejidad del algoritmo de detección y provocando un

mayor gasto energético.

Algunas técnicas para intentar minimizar el consumo de energía durante el procesamiento de los

datos son:

Reducir el voltaje de alimentación con el objetivo de disminuir el consumo de energía en

estado activo.

Reducir la frecuencia de trabajo del microprocesador durante periodo de baja actividad para

minimizar el consumo de energía

Sin embargo, intentar reducir demasiado el consumo de energía afectará probablemente al

rendimiento del procesador, por lo que el voltaje de alimentación y la frecuencia de trabajo deben

regularse según las exigencias de procesamiento en cada momento.


21

2.4. Estandarización de las redes de sensores

Desde que se descubrieron las redes WSNs, se ha estado mejorando continuamente la comunicación

entre los nodos a través del medio inalámbrico. Estas mejoras han consistido en desarrollar diferentes

protocolos con el objetivo de adaptarse a las características y limitaciones de dichas redes.

El valor de estas redes se basa en la facilidad de su despliegue gracias a su bajo coste. Esto se debe al

constante intento de estandarizar algunos elementos de las redes inalámbricas de sensores, para

lograr así, que tanto productos como fabricantes sean interoperables. Con este propósito, se han ido

estandarizando las distintas capas de los protocolos de comunicación de la red WSN, incluyendo la

carga útil de los datos enviados por sus sensores. Por dicho motivo, estas redes han logrado triunfar

como una tecnología donde los dispositivos son de bajo coste e interoperables entre sí, evitando

protocolos incompatibles que solo sean óptimos en un mercado más concreto y limitando así el

tamaño del mercado global de sensores inalámbricos.

Debido a que las aplicaciones de las redes de sensores son tan extensas, resulta imposible englobarlas

todas en un mismo estándar de protocolos, hardware, ni representación de datos, ya que las

tecnologías están en constante cambio y desarrollo. Sin embargo, entre las soluciones existentes se

encuentran algunas que tienen más fuerza con respecto a otras.

Los siguientes apartados pretenden describir los protocolos más implementados según los distintos

requerimientos que plantean las WSN para su funcionamiento.

2.4.1. IEEE 802.15.4

Este estándar [3] fue redactado en 2003 por el grupo 15 de trabajo del IEEE 802 (de ahí su nombre)

con el propósito de definir las comunicaciones en las capas físicas y de control de acceso al medio

(MAC) en las redes de sensores inalámbricos de área personal de baja velocidad (LR-WPAN).

Las LR-WPAN se caracterizaban por su baja tasa de datos que transportan, su bajo consumo de

energía para su funcionamiento, la variabilidad de la topología de red y el conocimiento de la

ubicación.

Por su parte, el 802.15.4 está diseñado para aplicaciones en WSNs que requieren de comunicaciones

de corto alcance para maximizar la duración de las baterías. Se pretende implantar en aplicaciones

domóticas e industriales donde el estándar 802.11 (WLAN) es caro de implementar.

Sus principales características con las redes WSNs son la flexibilidad de la red, bajo coste y bajo

consumo de energía.

El estándar soporta conexiones tanto en estrella (se comunicarán con un nodo coordinador central)

como en malla (redes ad hoc de configuración automática), por lo que es capaz de soportar una

amplia variedad de topologías de red y algoritmos de enrutamiento. En el caso de su implementación

en seguridad, los paquetes irán cifrados con AES-128.

Como se comentó anteriormente, el 802.15.4 pretende describir la capa física la cuál soporta tres

tipos de bandas de frecuencias:

2450 MHz con 16 canales y modulación O-QPSK

915 MHz con 10 canales con modulación BPSK

868 MHz con un solo canal con modulación BPSK


22

Todas estas frecuencias emplean técnicas de espectro ensanchado, en concreto, la DSSS (Direct

Squence Spread Spectrum)

La capa MAC controla el acceso al canal radio mediante el mecanismo de acceso múltiple CSMA-

CA (Carrier Sense Multiple Access with Collision Avoidance) y utiliza un campo de direcciones de

16 bits. Sin embargo, la norma incluye también la capacidad de enviar mensajes con direcciones

extendidas de 64 bits, permitiendo colocar en una única red casi un número ilimitado de dispositivos.

La transmisión de mensajes puede ser asentida mediante reconocimientos positivos, y tras cada trama

transmitida se podrá recibir un reconocimiento explícito (aunque es opcional), dando lugar a un

protocolo fiable. Esta sobrecarga causada por el reconocimiento explícito es aceptable dada la baja

tasa de datos típica de una red WSN.

Una de las principales características de esta norma es que permite la selección dinámica de canales

para conseguir no interferir con otros servicios que se encuentren en el mismo canal, de forma que el

nodo de red que controla la misma (se conoce como coordinador de red de área personal PAN)

explorará otros canales disponibles para elegir el más adecuado. Para ello, obtendrá una muestra del

nivel de energía de cada canal y la elegirá en función de los valores obtenidos.

Antes de cada una de las transmisiones de un nodo, éste realizara dos evaluaciones de canal (CCAs)

como parte del mecanismo CSMA-CA para garantizar que el canal esté desocupado antes de la

transmisión. De dicha manera, un byte de indicación de calidad del enlace (LQI) se adjuntará a cada

trama recibida por la capa física antes de que se envíe a la capa MAC, pudiendo usar el nodo

receptor esta información para diversos fines.

En definitiva, este estándar es el que más se adapta a las características físicas y de nivel de enlace en

las redes WSNs, Aunque fue definido para redes WPANs, intenta abarcar una gran cantidad de

posibilidades y métodos de comunicación siempre que no se use en aplicaciones muy restrictivas y

exigentes.

Esta dificultad, se pretendió paliar mediante el estándar 802.15.4ª de 2007 que añadió nuevas

posibilidades a la capa física como UWB (Ultra-wideband), DSSS y CSS (Chirp Spread Spectrum).

La última actualización del estándar IEEE 802.15.4 es la enmienda IEEE 802.15.4e (véase referencia

44) que ha sido desarrollado para ampliar y mejorar las especificaciones de nivel MAC del estándar

y para dar soporte y cobertura a mercados industriales. El estándar IEEE 802.15.4e incorpora nuevos

modos de operaciones que ofrecen servicios muy específicos que beneficia a las distintas

aplicaciones de la red tales como:

El modo DSME (Deterministic & Synchronous Multi-channel Extension): se ha diseñado

para aplicaciones cuyos requisitos sean alta disponibilidad, eficiencia, escalabilidad y

robustez.

El modo LLDN (Low Latency Deterministic Network): desarrollado para aplicaciones que

requieren muy poca latencia como robots, grúas, etc.

El modo TSCH (Time Slotted Channel Hopping): enfocado principalmente para entornos

industriales donde el consumo de energía tiene que ser reducido y la diversidad y robustez

frente a interferencias tiene que ser alta.

El modo RFID Blink (Radio Frequency Identification Blink): diseñado para la comunicación

con dispositivos aparte de identificadores que estos incorporan. Se usa para aplicaciones de

identificación de objetos o personas, localización o seguimiento de los mismos.

El modo AMCA (Asynchronous Multi-Channel Adaptation): es usado en redes de gran

tamaño y dispersión geográfica tales como las redes para smart utility, redes de


23

monitorización de infraestructuras y redes de control de proceso.

Como mejoras que incorpora este último estándar se define el protocolo Low Energy (LE) que

permite a los dispositivos operar bajo ciclos de trabajo (duty cycles) entorno al 1%. Este protocolo

incorpora dos mecanismos (referencia 45) que garantizan un consumo menor de energía:

Coordinated Samples Listening (CSL): mecanismo de ahorro de energía basado en escuchar

el canal de forma periódica por parte del receptor a la espera de solicitudes de transmisión.

Receiver Initiated Transmissions (RIT): mecanismo implementado en redes PAN que no

utilizan tramas beacons, de manera que es posible enviar tramas de forma periódica usando

CSMA/CA.

Hay que destacar que el modo de funcionamiento TSCH (Time Slotted Channel Hopping) es el

usado actualmente porque utiliza comunicaciones sincronizadas en el tiempo con saltos de canal en

frecuencia con el objetivo de dota a la red de una mayor robustez frente a fenómenos espectrales

tales como interferencias o multipath fading.

Este fenómeno puede resultar muy grave en determinados entornos dado que puede llegar a destruir

por completo las señales en el receptor por lo que la utilización de este modo de operación dota al

sistema de una mayor fiabilidad de comunicación en este tipo de entornos.

Además, TSCH permite dividir el tiempo en slots de uso predefinido, lo cual garantiza transmisiones

sin colisiones, permitiendo incrementar el rendimiento global de las comunicaciones. Incluso permite

utilizarse sin importar el tipo de topología de red usada, ya que su funcionamiento está basado en una

estructura conocida como slotframe o supertrama, la cual contiene un conjunto de timeslots que se

repiten en el tiempo.

Cada timeslot tiene una duración suficiente como para que un emisor envíe una trama de máximo

tamaño y que el receptor pueda enviar una trama de reconocimiento ACK.

En una red WSN implementada por el estándar IEEE 802.15.4e, los nodos deben sincronizarse con

la estructura de slotframe de la red, ya que, si no fuera así, sería imposible establecer la

comunicación entre ellos. Cada nodo tendrá una planificación que le indica qué debe hacer en cada

timeslot (transmitir o recibir datos o dormir), por lo que en un timeslot en el que el nodo deba

permanecer en modo sleep, no es necesario encender su interfaz radio, permitiendo mantener un gran

ahorro de energía, mientras que, en los timeslots activo, el planificador indicará al nodo qué nodo

vecino debe recibir los datos o transmitir, así como en qué canal.

Cuando un protocolo de una capa superior genere un paquete, éste es enviado a la capa MAC del

dispositivo a través del punto de acceso al servicio (SAP), donde se guarda el paquete en una cola

para ser transmitido. En cada timeslot de transmisión, la capa MAC comprobará si tiene algún

paquete en la cola de transmisión para algún nodo vecino en ese preciso timeslot, si fuera ese el caso,

la capa transmite el paquete y si no fuera así, el nodo permanece dormido sin encender su interfaz

radio.

En cada slot de recepción, el nodo enciende su radio antes del tiempo esperado de llegada del

paquete. Una vez comprobado que el paquete tiene como destinatario el mismo nodo receptor, se

envía un ACK al emisor y se apaga la interfaz radio. Por último, se envía el paquete a la capa

superior correspondiente para que sea procesado.

En definitiva, el IEEE 802.15.4e se define como la solución a las redes ultra-low-power para LLNs y

por supuesto, ha sido diseñado para dispositivos de baja potencia. Se centra en definir el


24

funcionamiento de la capa MAC de los dispositivos y no en definir aspectos de red, por lo que es

transparente para el resto de la pila de protocolos y esta soportado por protocolos como IPv6 y

6LoWPAN, RPL y CoAP.

Por último, mencionar la iniciativa 6TSCH que es un proyecto que está realizando el Working Group

del IETF y cuyo objetivo es utilizar IPv6 sobre el modo de funcionamiento TSCH del estándar IEEE

802.15.4e. IEEE 802.15.4e no define ningún método para construir y mantener el schedule o

planificador que utiliza TSCH. Dado que TSCH requiere mecanismos para gestionar el schedule,

este grupo de trabajo está definiendo una capa intermedia entre la capa MAC IEEE 802.15.4e con el

modo TSCH y la capa 6LoWPAN y tiene como nombre 6top, el cual ofrece interfaces de gestión y

datos para capas superiores.

Adicionalmente para los protocolos descritos anteriormente, existen en el mercado otras pilas de

protocolos ampliamente utilizadas en redes de sensores basadas en IEEE 802.15.4 como capa física y

MAC. En este sentido, cabe destacar la pila de protocolos ZigBee (se hablará de él más adelante),

definida por la ZigBee Alliance, la cual establece una serie de especificaciones propias a partir del

nivel MAC, pero que utiliza IEEE 802.15.4 en los niveles físico y acceso al medio.

Otro ejemplo de pila de protocolos es la pila de Bluetooth Low Energy (BLE), definida por el

Bluetooth SIG en la especificación Bluetooth v4.0 cuyo objetivo es reducir el consumo de energía en

los dispositivos, el tamaño y el coste, además de ser compatibles con el máximo número de

dispositivos posibles. Un aspecto clave de esta tecnología es el hecho de que los smartphones que ya

disponen de dispositivos Bluetooth podrán fabricarse con soporte también para BLE con bajo coste

adicional, dado que BLE reaprovecha parte de la circuitería de Bluetooth.

2.4.2. Bluetooth Low Energy

Bluetooth Low Energy (BLE) es la nueva especificación 4.0, 4.1 y 4.2 de la tecnología Bluetooth

existente (puede consultarse más a fondo en las referencias 46 y 47), desarrollado por Bluetooth

Special Interest Group (SIG). Esta nueva tecnología inalámbrica ha sido diseñada como una técnica

complementaria al Bluetooth clásico existente, para garantizar un consumo de energía bajo y un

menor tiempo de establecimiento en las conexiones.

BLE está diseñado para la transmisión de pequeñas cantidades de datos (tiempos de transmisión muy

pequeños) y por lo tanto está pensado para dispositivos ultra-low-power que consuman muy poca

energía. Su uso no está pensado para conexiones de larga duración entre dispositivos ni para que se

intercambien grandes cantidades de datos a alta velocidad, sino que los dispositivos se encuentren

activos solo cuando estos deseen transmitir datos.

BLE destaca por su topología de red en forma de estrella donde los dispositivos Master pueden tener

varias conexiones a nivel de enlace con periféricos (Slaves) y al mismo tiempo realizar búsquedas

con otros dispositivos. Además, un dispositivo puede enviar datos en modo Broadcast o eventos

conocidos como Advertising si necesidad de esperar ninguna conexión, permitiendo enviar datos a

los dispositivos que se encuentren en modo Scanning si tener que haberse establecido previamente la

conexión Master-Slave.


25

El SIG de Bluetooth define una pila de protocolos para BLE (véase Figura 1-0) para poder gestionar

los dispositivos, las conexiones y las interfaces de aplicación. Dicha pila se divide en:

Controller: dispositivo físico que permite transmitir y recibir las señales radio e interpretarlas

como paquetes con información. Comprende la capa física Physical Layer, Direct Test

Mode, la capa de enlace Link Layer y la interfaz de control de host Host Controller Interface.

Host: es la pila de nivel software que administra como los dispositivos se comunican entre sí.

No tiene ninguna interfaz superior definida, ya que cada S.O tiene su propia manera de

exponer APIs de Host para los desarrolladores, por lo que esta parte de la pila esta forma por

una capa de control de enlace lógico y de protocolo de adaptación (Logical Link Control and

Adaptation Protocol), administrador de seguridad (Security Manager, protocolo de atributo

ATT, perfil de atributo genérico GATT y perfil de acceso genérico GAP.

Application: cada aplicación usara a pila de software, y a su vez ésta utiliza el controlador.

Figura 1-0. Ejemplo de escenario WSN

Bluetooth Low Energy usa la banda de 2.4 GHz mediante modulación GFSK a 1Mbps, pero a

diferencia del Bluetooth clásico, implementan índices de modulación diferentes. BLE tiene 40

canales a diferencia del Bluetooth clásico que implementa 79 canales, pero hay dispositivos Dual

Mode que soportan las dos tecnologías conmutando los parámetros de modulación y los canales

donde se está radiando.

La capa física es la encargada de enviar las señales al aire, transmitiendo y recibiendo bits mediante

las ondas radio en la banda de frecuencia de 2.4GHz, donde la separación entre los 40 canales que

utilizan es de 2 MHz con 1MHz de anchura cada uno. Existen 3 canales dedicados para el

Advertising y 37 para la transmisión de datos, estos canales de Advertising están situados de forma

que no causen interferencias con otras tecnologías que coexisten en el mismo espectro que el IEEE

802 y ZigBee (que se verá más adelante junto con 6LoWPAN).


26

Además, en estado de conexión, BLE utiliza técnicas de FHSS (Frequency Hopping Spread

Spectrum) para reducir las interferencias.

La capa de enlace de la tecnología Bluetooth BLE es la responsable de los estados de Advertising,

Scanning, creación y mantenimiento de las conexiones y por supuesto de cómo se estructuran los

paquetes. Los estados y roles de BLE son.

Standby: en este estado, el dispositivo ni transmite ni recibe, por lo que está asociado a un

sistema durmiente para conservar energía.

Advertising: el dispositivo que entra en este estado es capaz de escuchar cualquier respuesta

(solicitud) de los paquetes que envía el dispositivo central. Es un modo crítico para analizar

desde el punto de vista de la potencia, puesto que el dispositivo periférico tarda un tiempo de

Advertising o anuncio dependiendo de la aplicación.

Hay que tener en cuenta que el tiempo de transmisión afecta al consumo de energía, por lo

tanto, el intervalo de Advertising afecta directamente al consumo de potencia y al ciclo de

vida de las baterías.

Scanning: en este modo el dispositivo escucha paquetes Advertising enviados a través de sus

canales y así encontrar los dispositivos cercanos a él.

Initiating: es el estado previo al estado de conexión donde el dispositivo central escucha los

Advertising de periféricos, pero una vez recibe el Advertising del periférico deseado, el

central debe conectar enviando los datos correctos.

Debe tenerse en cuenta que el modo Advertising para el dispositivo Slave se considera como un

estado inicial antes de la conexión, por lo que este modo es el que permite al Slave (periférico) y

Master (central) poder intercambiar datos.

Un dispositivo Advertiser es aquel dispositivo BLE que utilizara los canales Advertising para emitir

datos, anunciar que es conectable y detectable.

Por último, la tabla 2-2 permite comparar las características de BLE con otras tecnologías de

comunicación inalámbricas, que operan en la misma banda y se consideran sectores de competencia

directa, como son ZigBee y WiFi, que al igual que BLE utilizan la banda 2.4 GHz con

funcionalidades distintas.

Tabla 1-1. Comparación de BLE con otros estándares

BLE WiFi ZigBee

Banda de Frecuencia 2.4 GHz 2.4 / 5 GHz 2.4 GHz

Modulación GFSK OFDM, DSSS DSSS

Rango 100 m 100 m 200 m

Tipología de red Estrella Malla

Tasa 1 Mbps 1 Mbps – 7Gbps 250 Kbps

Consumo de Pico de

Corriente

< 15 mA 60 mA RX | 200 mA TX 19 mA RX | 35 mA TX

Corriente en Standby < 2 mA < 100 uA 5 uA


27

2.5. Arquitectura Hardware

En este apartado se realiza una descripción acerca de los diferentes nodos que pueden encontrarse en

una red WSN (véase Figura 2-1), las topologías que pueden formarse y las decisiones para escoger la

mejor ruta desde el punto de vista energético para comunicarse con otros nodos.

Figura 2-1. Ejemplo de escenario WSN

2.5.1. Nodos sensores

Reciben el nombre de motas o “motes” por su ligereza y reducido tamaño. Son dispositivos

electrónicos con diferentes dimensiones, los cuales trabajan de manera simultánea dentro de la

misma red con el objetivo de obtener datos de un nodo origen y transportarlo a un nodo destino

mediante el uso eficiente de protocolos de enrutamiento. Es por esto que diseñar una mota no se

reduce a miniaturizar un ordenador, puesto que se desea una ejecución elevada de programas y una

transmisión de datos eficaz con una amplia longitud de emisión.

Dado que cada nodo sensor puede tener un tamaño distinto, su diseño también será diferente, aunque

todos estarán constituidos por:

Un microcontrolador encargado de controlar la monitorización y procesar la información.

Un transceptor radio capaz de generar ondas de radio.

Distintos tipos de dispositivos para una comunicación inalámbrica.

Una batería como fuente de alimentación.


28

Los componentes de un nodo WSN se encontrarán agrupados en varios módulos tal como se muestra

a continuación:

Figura 2-2. Componentes de un nodo WSN

Tal y como se muestra en la Figura 2-2, una descripción general de los elementos que componen a

un nodo vendría dada por: un microcontrolador, una memoria, un transceptor radio, una antena, una

fuente de energía y sensores (o actuadores). Todos estos elementos pretenden minimizar el tamaño,

el coste y el consumo de energía de la mota.

Los tres módulos más importantes por los que está compuesto este dispositivo son:

Modulo sensor: se divide en un conjunto de sensores y un convertidor analógico digital

(ADC). Los sensores generaran unas señales analógicas en función del fenómeno observado,

donde posteriormente son convertidas a señales digitales por este convertidor y enviadas al

módulo de procesamiento.

Módulo de procesamiento: está formado por un microcontrolador encargado de manejar los

procedimientos que permiten al nodo colaborar con el resto de nodos de la red, y llevar a

cabo las funciones asignadas a la WSN. Normalmente suele llevar incorporada una pequeña

unidad de almacenamiento.

Módulo de comunicación inalámbrica: constituido por un transceptor radio que permitirá

conectar inalámbricamente el nodo a la red.


29

El funcionamiento del nodo sensor se basa en el circuito transceptor que genera las señales de

radiofrecuencia según la banda base digital elegida. Las bandas de frecuencias (según las ICM) de

mayor aceptación mundial son la de 2.4 GHz y 868 MHz (es la usada en Europa), de manera, que en

la placa del nodo debe venir integrado los transceptores necesarios de acuerdo a la banda de

frecuencia con la que se ha decidido operar.

Los transceptores actuales están compuestos por cuatros estados de operación que son: emitir,

recibir, dormir e inactividad.

Los transceptores radio que se implementen deben de seguir un estándar correcto. El estándar

elegido para este proyecto será el estándar IEEE 802.15.4 por ser el que mejor se adapta a las

necesidades que se pretenden conseguir. Sin embargo, también podrían usarse otros más genéricos

que permiten definir una interfaz radio según las necesidades, gustos o preferencias más específicas.

El medio radio será compartido, por lo que tal como se observó en la Figura 2-2 debe existir un

protocolo de acceso o MAC implementado entre el transceptor radio y el microcontrolador.

Algunos sistemas de comunicación radio usado en los nodos (se ha extraído parte de lo citado en la

referencia 2 en el capítulo 3) son los que se contemplan en la Tabla 2-3:

Tabla 2-2. Transceptores de radiofrecuencia

Features CC1200 CC1310 CC2420 TR1000 XE1205

Manufacturer Chipcon Chipcon Chipcon RFM Semtech

Operating

Frequency (MHz)

137-158.3/ 205-

237.5/ 274-316.6

863-930 2400 916 43/868/915

Bit Rate (kbps) 50 (-109 dBm)

1.2 (-123dBm)

50 250 1152 1.2-152.3

Power Supply

Voltage (V)

2.0-3.6

(typ 3.0)

1.8.3-3.8 (typ

3.0)

2.1-3.6 (typ

1.8)

2.2-3.7

(typ 3.0)

2.4-3.6

Sleep Mode (uA) 0.12

(osc.core off)

185 nA (core off) 1 0.? 0.2

Standby Mode

(uA)

0.5 0.6 426

(osc.running)

916 850

RX (mA)

19 (LPM)

23 (HPM)

5.5

19.7

3.8

(115.2kbps)

14

TX Min (mA) 33.6 (+10dBm) 12.9(-10dBm) 8.6 (-25dBm) 7 (-23dBm) 33

(-5dBm)

TX Max (mA) 46 (+14dBm) 22.9 (-14dBm) 17.4 (0dBm) 12 (+1.5dBm) 62 (+15dBm)


30

El componente inteligente del nodo es conocido como MCU (Microcontroller Unit) y engloba una

unidad de proceso simple, memoria e interfaces de entrada/salida.

Además de los microcontroladores existen otros tipos de productos como:

FPGA: presentan bastantes desventajas en su uso como consecuencia de su gran consumo

energético. Aunque hoy día, los hay de bajo consumo, pero no alcanzan los niveles

necesarios para ser implementados en nodos WSN.

Microprocesadores: han sido sustituidos por microcontroladores porque integran en su

interior un microprocesador y una memoria.

La gama de los microcontroladores es bastante extensa en fabricantes y modelos habiendo

dispositivos que usen procesadores desde 8 bits hasta los 32 bits con una arquitectura conocida como

RISC (Reduced Instruction Set Computer), la cual ofrece hasta 32 MIPS (Million Instructions Per

Second). Algunos de los más usados son:

Atmel AVR: pertenecen al conjunto de microcontroladores RISC de Atmel. Están diseñados

con una CPU que sigue una arquitectura Harvard con 32 registros de 8 bits.

Intel 8051: es un microcontrolador desarrollado por Intel en 1980 para uso en productos

embebidos. Su uso es tan popular que lo implementan fabricantes como Atmel, Dallas

Semiconductor o Phillips entre otros. Tiene una arquitectura Harvard y fue diseñado para

aplicaciones simples, el cual permite direccionar 64 kB de ROM externa y 64 kB de RAM

por medio de líneas separadas chip select para programa y datos.

TI MSP430: microcontrolador producido por Texas Instruments. Está constituido con una

CPU de 16 bits cuyo diseño va destinado a aplicaciones empotradas de bajo coste y bajo

consumo de energía.

PIC: son microcontroladores tipo RISC que se usan generalmente como controladores de

interfaz periféricos.

Intel Xscale: es un núcleo de microprocesador con implementación de Intel de 5ª generación

de la arquitectura ARM. El XScale usa un entero de 7 niveles y 8 niveles de memoria

Superpipeline de arquitectura RISC.

ATmega 128L: pertenece a la gama de microcontroladores AVR y es considerado uno de los

microcontroladores más potentes. Tiene todos los dispositivos y periféricos integrados y

destaca por su velocidad, amplia memoria de programa y RAM internas y, además, por la

necesidad fundamental de incorporar dos UART.


31

A nivel de almacenamiento, los nodos tendrán una memoria RAM que variará desde 1kB hasta los

128 kB, mientras que la memoria no volátil puede ser una memoria ROM o flash y estará

comprendida entre las pocas centenas hasta las decenas de kilobytes.

Los microcontroladores podrán encontrarse en un estado inactivo (sleep mode) con componentes

desconectados, o en un estado activo (active mode), cuyos relojes de frecuencia variarán desde los 32

kHz hasta decenas de MHz generando fluctuaciones de microamperios a miliamperios. Gracias a

esto, será posible la conexión de algunos sensores que manejan señales analógicas, aunque también

se dispone de puertos series o UARTs (Universal Asynchronous Receiver/Transmitter) y buses para

conectar varios dispositivos como los I2Cs (Inter-Integrated Circuit), el SPI (Serial Peripheral

Interface) o simplemente dispositivos de I/O, los cuales sólo algunos de ellos permitirán conectar

sensores que manejen información en formato digital para ser conectados a memorias flashes o a

transceptores radio.

Los sensores que incorporen un nodo serán dispositivos hardware capaces de producir una respuesta

medible ante un cambio en un estado físico, como puede ser la temperatura o la presión. La señal

analógica continúa detectada es digitalizada por convertidores AC/DC y enviada a un controlador

para ser procesada.

Los requerimientos que un sensor debería contener son: pequeño tamaño, bajo consumo de energía y

operar en densidades volumétricas altas, entre otras.

Una posible clasificación de sensores podría ser:

Sensores pasivos omnidireccionales: tienen la capacidad de captar los datos del entorno sin

que éste sea manipulado. Son capaces de autoalimentarse y sólo utilizan la energía para

ampliar su señal analógica captada.

Sensores pasivos unidireccionales: tienen definida la dirección desde dónde deben captar la

información. Un posible ejemplo sería una cámara.

Sensores activos: se encargan de sondear el ambiente. Un ejemplo de estos sensores sería un

radar o sonar que genera ondas expansivas a través de pequeñas explosiones.

En la Figura 2-3 se muestran los distintos tipos de sensores que pueden ser equipados en los nodos.

Figura 2-3. Tipos de sensores


32

Para los sensores se requerirán unos circuitos de adaptación de los cuales, se despliega una amplia

gama de interfaces, alimentaciones y señales de diferentes formatos. Debido a que los niveles de

señal y alimentación no suelen encajar con los de la MCU, comenzó una iniciativa de la

estandarización de las interfaces mediante el IEEE 1451, que establece un conjunto de interfaces para

hardware y software con el fin de separar el diseño de los transductores de la elección de las redes de

comunicación.

Al separar las dos entidades -transductores y redes- el modelo permite que el fabricante se centre en

su dispositivo de transducción, sin tener que preocuparse de su adaptación a diferentes redes, lo que

podría contribuir a mejorar la calidad de los transductores y a reducir sus precios. La familia IEEE

1451 [4] define un conjunto de interfaces de comunicación para conectar transductores inteligentes a

sistemas basados en microprocesadores, instrumentos y redes; y proporciona un conjunto de

protocolos para sistemas tanto cableados como inalámbricos.

Normalmente la fuente de alimentación que integran los nodos suelen ser baterías difíciles de

sustituir o transformadores con una salida adecuada para el nodo si se dispone de una toma de

corriente. Por esto, se está aumentando la frecuencia de implementar nodos sensores con células

solares que permitan su autoalimentación.

Existen también otras unidades que podrían ser incorporadas a un nodo en función del tipo de

aplicación. La mayoría de las aplicaciones requieren del conocimiento de la ubicación con un cierto

grado de precisión, por lo que sería necesario añadir un sistema de localización. Dicho sistema

tendría como principal objetivo informar en todo momento de la posición del nodo, siendo

imprescindible en despliegues aleatorios. Sin embargo, es un elemento bastante costoso que implica

que aumente el tamaño del sensor.

Las antenas serán omnidireccionales como consecuencia de que la ubicación de un nodo sensor y los

nodos con los que se comunican no resulta conocida a priori. Las bandas de frecuencias permiten

tener antenas monopolo, antenas whip y antenas chip (integrada en la placa de circuito impreso),

de manera que las primeras antenas ofrecerán una mejor ganancia, pero requieren de un conector y a

veces, de un cable coaxial; mientras que las segundas son bastante económicas y las antenas chip son

de tamaño reducido.

Los problemas que presentan estos tres tipos de antenas son los siguientes:

Directividad de la antena afectada por sus propios componentes. Ocurre en las antenas whip

y chip.

No pueden ser instaladas en compartimientos metálicos.

El movilizador será otro elemento que incorporarán las antenas, permitiendo desplazar los nodos

cuando se requiera llevar a cabo tareas determinadas.

La mayoría de estos componentes se encuentran ajustados en una placa de circuito impreso cuya

dimensión se estima del orden de un centímetro cubico, donde se ofrecen conectores a todos aquellos

elementos que pueden tener más variabilidad en la elección. Es el caso de la antena, los sensores o

actuadores y la fuente de alimentación.


33

A parte del tamaño, otras restricciones existentes en un nodo serán:

Uso de poca energía.

Funcionamiento en despliegues con una alta densidad de nodos.

Ser prescindibles y tener un bajo coste de producción.

Funcionar de manera autónoma.

Adaptarse al entorno en que se encuentran.

Como casi siempre, los nodos serán inaccesibles, de tal forma, que la vida útil de una WSN

dependerá de la duración de los recursos energéticos de los nodos. Así, el almacenamiento de energía

se verá directamente afectado y, por consiguiente, en aplicaciones que requieran un tiempo de vida

mayor para una WSN será necesario buscar alternativas. Por ejemplo, incluir componentes que

recojan energía del entorno para hacer al nodo autónomo (uso de células solares).

2.5.2. Gateway

Este tipo de nodo permite establecer una interconexión entre una red de sensores WSN y una red de

datos (TCP/IP). Principalmente, se caracterizan porque no llevan incorporados ningún elemento

sensor puesto que su único objetivo es actuar como un puente entre dos redes diferentes.

Los nodos gateway son los encargados de poder transmitir la monitorización o información obtenida

por la red de sensores al exterior como a Internet, redes de área local (LAN) o intranet privadas, de

ahí el motivo de su nombre.

2.5.3. Estación base

Son recolectores de datos que funcionan como un ordenador común o sistema empotrado. Permite

almacenar los datos obtenidos en un servidor y pueden ser accedidos de forma remota para observar

y estudiar dichos datos.

2.5.4. Topologías en una red WSN

Cuando se habla de topología, se hace referencia a la configuración de los componentes hardware de

un nodo dentro de una red WSN, y a cómo los datos son transmitidos a través de esa configuración.


34

2.5.4.1. Configuración en estrella

Este tipo de topología (Figura 2-4) admite presentar un sistema donde la información que se envía

solo dará un salto, permitiendo a los nodos sensores poder comunicarse de forma directa con el nodo

gateway (quien transmitirá los datos al exterior), usualmente a una distancia de 30-100 metros. Los

nodos finales no intercambiaran información entre ellos, sino que usaran la puerta de enlace si fuera

necesario.

Figura 2-4. Topología en estrella

Lo más característico de la configuración en estrella es su poco gasto de energía. Sin embargo, tiene

limitada la distancia de transmisión vía radio entre cada nodo y la gateway. Además, no presenta

rutas alternativas en el caso de que un nodo presente problemas de comunicación, perdiéndose así la

información.

2.5.4.2. Configuración en malla

Una topología mallada resultará ser un sistema multihop o multisalto (Figura 2-5) donde cada uno de

los nodos que conformen la red actuará como routers y serán todos iguales. Cada nodo podrá enviar

y recibir información del resto de nodos, incluyendo el nodo gateway. A diferencia de la topología en

estrella, los nodos sí pueden enviarse mensajes entre ellos.

Figura 2-5. Topología en malla


35

La propagación de los datos a través de los nodos hacia una Gateway conlleva crear una red con una

extensión posible ilimitada. Este tipo de configuración es altamente tolerante a fallos, ya que cada

nodo tiene diferentes rutas por las que comunicarse con el nodo Gateway. De modo que, si un nodo

falla, la red podrá configurarse alrededor de ese nodo automáticamente.

Sin embargo, el principal problema de una red mallada es su inconsistencia si aumenta demasiado. Si

este hecho ocurre, se originarían elevados tiempos de espera para mandar la información.

2.5.4.3. Configuración hibrida

El objetivo es combinar las ventajas de cada una de las topologías, simplicidad y bajo consumo de la

configuración en estrella, y la posibilidad de cubrir una gran extensión y reorganizarse ante fallos de

la configuración mallada, como se observa en la Figura 2-6.

Figura 2-6. Topología hibrida estrella-malla

El resultado final será una red WSN en estrella rodeada de routers pertenecientes a una red en malla

donde dichos routers permitirán ampliar la red y corregir los fallos de los nodos, mientras que los

nodos finales se conectarán a los routers más cercanos para ahorrar energía.


36

2.5.5. Modelos de tráfico

Las redes WSNs se caracterizan por seguir un modelo de tráfico asimétrico único [5] debido a

que el objetivo principal es la obtención de datos. Esto se consigue porque los nodos sensores

envían continuamente datos a una estación base, mientras que ésta responderá de forma

intermitente mediante mensajes de control.

El tráfico de las WSN puede ser de un solo salto o multisalto. Estos modelos de tráfico que se

muestran en la Figura 2-7 pueden estar basados en multisalto o multi-hop y pueden dividirse en

función del número de paquetes enviados y recibidos por un nodo, o si la red soporta un

procesamiento de intrared.

Figura 2-7. Modelos de tráfico en WSNs

Los distintos modelos de tráficos serán:

Comunicación local: usado por los nodos para indicar el estado en el que se encuentra

éstos a sus respectivos vecinos a través de mensajes de difusión. También permite

transmitir información entre dos nodos directamente conectados.

Punto a punto: modelo de encaminamiento utilizado para enviar un paquete desde un

nodo arbitrario a otro arbitrario de la red. Se implementa normalmente para redes LAN

inalámbricas.

Convergencia: distintos nodos envían paquetes a un mismo nodo base. Se usa con el fin

de recolectar datos en una WSN.

Agregación: los paquetes por un nodo podrán ser retransmitidos por otros nodos hasta

llegar a la estación base, quién agregará todos los datos y los enviará.

Divergencia: permite enviar una orden desde un nodo base al resto de nodos de la red.


37

2.5.6. Políticas para la selección de una ruta eficiente

Como ya se ha mencionado anteriormente, el consumo energético (véase referencia 5) es uno de

los problemas principales en las redes WSN. Para minimizar los daños ocasionados, se

implementan unos protocolos con el fin de reducir dicho consumo energético. Éstos son

protocolos de encaminamiento de energía eficiente que usan a veces energía residual, potencia

de transmisión o longitud (distancia) de enlace como métrica para escoger la ruta óptima.

Los dispositivos usados en una WSN tienen recursos limitados: como una velocidad de

procesamiento lento, una capacidad pausada de almacenamiento y un ancho de banda limitado,

por lo que la red tiene que operar durante un largo periodo de tiempo y la energía es limitada.

Para minimizar este consumo de energía, la mayoría de los componentes están formados por

recursos radios, el cual debería estar apagado generalmente.

Otra característica importante en los nodos sensores es su capacidad de procesamiento global y

no individual, es decir, es necesaria una organización, una administración y una gestión de la red

total, lo cual resulta más complejo que controlar los dispositivos de forma individual. También,

los cambios en el medio físico afectarán al retardo de la red, a la conectividad de los sensores y

los protocolos de red.

El principal objetivo de una red WSN no es la transmisión de datos desde un origen a un destino,

sino aumentar el tiempo de vida de la red mediante la implementación de protocolos de

encaminamiento eficiente, teniendo cuidado con las operaciones de estos protocolos puesto que

pueden afectar al gasto de energía en la transmisión de la información. Por esto, es primordial

centrarse en aquellos protocolos de encaminamiento que sean capaces de disminuir la energía y

aumentar el tiempo de vida de la red para cualquier área de investigación.

Las tres actividades que más energía consumen dentro de una red WSN son la detección,

procesamiento y comunicación de la información. Serán factores a tener en cuenta para el

desarrollo de cualquier protocolo de red eficiente en una red WSN.

La potencia generada por los protocolos de enrutamiento no es solo encontrar la ruta óptima que

garantice el menor derroche de energía, sino también localizar la forma de mantener todo el

tiempo posible la vida útil de la red.

Algunos términos relacionados con la eficiencia energética en las WSN para evaluar la calidad

de un protocolo de encaminamiento serán:

Energía por paquete: relacionado con la cantidad de energía que se gasta mientras se

envía un paquete desde un origen a un destino.

Energía y fiabilidad: se refiere a la forma con la que se compensa los diferentes

requisitos en una aplicación. Esto se debe a que, si surge un evento que necesita ser

tratado de forma inmediata, habrá un aumento significativo de energía ya que se

producirá una mayor redundancia de transmisión, además de la utilización de diferentes

rutas para que dicho evento llegue cuanto antes a su destino.

Tiempo de vida de la red: existen diferentes formas de medirlo. Puede corresponder al

tiempo que tarda el primer nodo en quedarse sin energía, o cuando en un cierto momento

los nodos de la red no responden, incluso cuando todos los nodos están “muertos”. En las

redes WSNs, este factor es muy importante puesto que significa incrementar el


38

funcionamiento de la red o prolongar el tiempo de vida de la batería de los nodos. Es por

ello, que debe escogerse los caminos más cortos posibles para transferir los paquetes.

Energía media disipada: está relacionada con el tiempo de vida de la red, y muestra la

energía media disipada por nodo para cada instante en la red durante la transmisión,

recepción, detección y agregación de datos.

Consumo bajo de energía: un protocolo de bajo consumo tiene que consumir menos

energía que un protocolo tradicional. Esto significa que el protocolo deberá seleccionar

aquellas rutas que permitan maximizar todo lo posible el tiempo de vida de la red WSN.

Número total de nodos activos: está relacionado con el tiempo de vida de la red y otorga

una idea del área que es capaz de cubrir la red.

Número total de datos recibidos en una estación base: esta métrica es equivalente a la

energía que ahorra el protocolo al no transmitir paquetes de forma continua (hello

messages), no siendo obligatorios.

Retardo medio por paquete: esta medida permite obtener el retardo medio cada vez que

se produzca la transmisión y recepción de un paquete por un nodo sumidero.

Ratio de paquetes entregado: mide el número de paquetes que recibe un nodo sumidero

en función del número de paquetes enviados por los nodos fuentes. Permite saber el

porcentaje de fiabilidad de paquetes entregados.

Tiempo hasta que el primer nodo muere: indica el tiempo de vida que tendrán el resto de

nodo de una red. Hay protocolos que son capaces de mantener la red operativa durante

bastante tiempo, una vez que el primer nodo se queda sin energía.

Energía consumida de ida-vuelta: muestra la cantidad de energía total que se consume

en encaminar mensajes ida y vuelta. Esta medida proporciona una idea acerca de la

eficiencia energética del protocolo.

Estado de escucha inactiva: un nodo sensor que se encuentre en este estado no enviará ni

recibirá datos, pero continuará consumiendo energía. En lugar de encontrarse en este

estado, es preferible que se halle apagado.

Tamaño de paquete: el tamaño de paquete determina el tiempo que tardará una

transmisión. Debe reducirse el tamaño del paquete fragmentándolos en varios trozos o

comprimiéndolo.

Distancia: la distancia entre el nodo que transmite y el nodo que recibe, afectará a la

potencia con la que se envían y reciben los paquetes. Los protocolos de encaminamiento

deberán elegir la ruta más corta entre los nodos para reducir el consumo de energía.


39


40

3 Encaminamiento en redes WSN

n este capítulo se intenta aportar una visión de los distintos protocolos de encaminamiento que

existen y pueden implementarse en una red WSN. Asimismo, se presenta los principales

problemas al elegir el protocolo de encaminamiento idóneo y los objetivos y los factores

fundamentales en la selección de un protocolo sobre otro en función de la finalidad con la que se

desee implementar una red WSN.

También va a presentarse de forma resumida y concisa la clasificación que existe de los distintos

protocolos de encaminamiento y los motivos por el cual se ha elegido el protocolo RPL para este

proyecto.

3.1. Objetivos y problemas de los protocolos de encaminamiento

Los protocolos de encaminamiento en una red WSN tienen como finalidad ser lo mas transparente

posible y adaptarse a los cambios generados por la red de forma rápida y eficiente. A diferencia de

una red móvil ad-hoc, las redes de sensores no necesitan un requerimiento alto de movilidad, ni un

gran alcance como las redes WLAN que requieren una fuente de energía constante.

A pesar de las innumerables aplicaciones de las redes de sensores inalámbricas, estas redes tienen

varias restricciones, como la limitación del suministro de energía, la limitación de la capacidad de

procesamiento y la limitación del ancho de banda de los enlaces inalámbricos entre nodos sensores.

Sin embargo, uno de los principales objetivos de los protocolos de encaminamiento, es llevar a cabo

la comunicación de datos mientras se intenta prolongar la vida útil de la red evitando la degradación

de la conectividad a causa del empleo de técnicas agresivas de gestión de energía.

E

Veo poco potencial comercial en Internet, al menos

durante diez años

- Bill Gates -


41

Los criterios de diseño para este tipo de redes, depende directamente de la aplicación, puesto que no

es lo mismo una aplicación de monitorización que de vigilancia., es por ello que a nivel de red, el

protocolo de encaminamiento elegido tenga como objetivo adaptarse a las necesidades de la

aplicación que se implementara posteriormente en la red WSN.

En las redes WSN la elección del protocolo de encaminamiento es el que va a condicionar el

comportamiento de los nodos en dicha red, independientemente del resto de capas de la pila de

protocolos implementada. Esto es debido a que el objetivo en general de un protocolo de

encaminamiento es dirigir el trafico de una fuente hacia su destino intentando maximizar el criterio

de rendimiento que se haya elegido, en concrento, para este tipo de redes, el objetivo es evitar que se

produzca una gran perdida de energía por parte de los dispositivos que conforman la red, de ahí la

difícil decisión de decidir el protocolo de encaminamiento.

Aunque el enfoque energético sea el principal problema y condicionante en la elección del protocolo

de encaminamiento, también debe tenerse en cuenta las condiciones de trafico, la estructura de la red

y los recursos empleados en ella, la movilidad y escalabilidad de los nodos y sobre todo los fallos

que puedan originarse en estos durante el despliegue de una red WSN. Para estas redes, los

protocolos de encaminamiento dinámicos o adaptativos (se explican en la clasificación) son los que

mejor se adaptan a las condiciones impuestas por estas redes, ya que el resto de protocolos que no

son dinámicos generan una falta de adaptabilidad frente a los frecuentes cambios de la topología de

la red, de las capacidades de los nodos, de los modelos de tráfico, de la carga o de la disponibilidad

de energía, entre otros, que acaban reduciendo notablemente el rendimiento de la red.

Por estos motivos comentados anteriormente, para este trabajo se ha elegido de entre todos los

protocolos de encaminamiento existentes el protocolo RPL (se explicará con más profundidad en el

capítulo 6), por ser de tipo dinamico y proactivo, el que mejor se adapta al protocolo de

comunicación 6LoWPAN y a la arquitectura TCP/IP y porque es el que implementa el sistema

operativo Contiki, que se usará para realizar los escenarios de prueba.

3.2. Factores que afectan a los protocolos de encaminamiento

Los algoritmos que anteriormente se han comentado pretenden minimizar el consumo de energía

dentro de los nodos de una red WSN, por lo que utilizarán enlaces multisalto más cortos, ya que es

una solución más ventajosa si solo se considera la transmisión de energía en el coste de las

comunicaciones.

Sin embargo, debería tenerse en cuenta que en los nodos sensores, se disipa energía cuando se

produce un retardo al recibir los mensajes o en cualquier medición de datos que se realice, por lo que,

en ocasiones, el uso de multisalto puede considerarse una desventaja en las redes WSN.

Todo esto dependerá de los factores que se tengan en cuenta en el diseño de los protocolos de

encaminamiento de eficiencia energética para conseguir una comunicación eficiente. Los principales

factores son:


42

Despliegue de los nodos: esta operación puede afectar al funcionamiento de los protocolos

de encaminamiento, precisamente, su eficiencia dependerá de ello. El despliegue puede ser

aleatorio o determinista.

Heterogeneidad en nodos/enlaces: la existencia de nodos heterogéneos incrementa los

problemas técnicos relacionados con el encaminamiento de los datos.

Modelo de reporte de datos: la detección, medición e informe de datos en las redes WSN

dependerán de la aplicación y del momento crítico en el que se presenten los datos.

Consumo de energía sin pérdida de precisión: en este caso, los mecanismos de

conservación de energía para la comunicación y procesamiento de datos son más que

necesarios.

Escalabilidad: tiene que existir ante la respuesta de cualquier evento como un posible

incremento del número de nodos dentro de la red.

Dinamicidad de la red: la movilidad de los nodos sensores es necesaria en muchas

aplicaciones a pesar de que la mayoría de las arquitecturas de red consideran los nodos como

estacionarios.

Tolerancia a fallos: la tarea global de la red de sensores no debe afectar al funcionamiento

de los nodos sensores.

Conectividad: dependerá de la distribución aleatoria de los nodos en la red.

Medio de transmisión: en una red WSN con multsaltos, la comunicación entre los nodos se

producirá a través de un medio inalámbrico.

Cobertura: en redes WSN, los nodos sensores estarán limitados en alcance y precisión,

pudiendo cubrir solamente un área limitada del medio.

Calidad de servicio: los datos deberían ser entregados en un cierto periodo de tiempo. Sin

embargo, en numerosas aplicaciones, la conservación de la energía es directamente

proporcional con el tiempo de vida de la red, la cual tendrá más importancia con respecto a la

forma en la que se envían los datos.

Agregación de datos: es la recopilación de datos de diferentes nodos origen con el objetivo

de agruparlos todos.


43

3.3. Algoritmos de encaminamiento

La elección del algoritmo de enrutamiento destinado a trasladar los paquetes enviados por los nodos

de una red WSN están asociados a una programación dinámica, donde se debe de analizar cada uno

de los escenarios dentro de la red, las fluctuaciones que se encuentren y las rutas cortas.

Estos algoritmos pueden ser centralizados o descentralizados y su objetivo es encaminar los paquetes

desde un nodo origen hasta un nodo destino seleccionando las rutas con el menor coste.

En el caso de que los nodos generasen datos constantemente, el ancho de banda también se verá

afectado, de manera que habrá una sobrecarga en los enlaces. Así que un protocolo de

encaminamiento debe tener en cuenta las limitaciones del ancho de banda e intentar no sobrecargar

los enlaces que contengan las rutas de mínimo coste.

Los algoritmos de encaminamiento (puede profundizarse más en el artículo de la referencia 5) de

coste mínimo más importantes son:

MCBCR: se conoce como Efficient Minimum-Cost Bandwidth-Constrained Routing y

proporciona una solución simple, escalable y eficiente que permite minimizar el coste de los

problemas de encaminamiento en redes WSNs. También intenta encontrar las rutas más

apropiadas para transferir los datos de los nodos sensores a las estaciones base, permitiendo

así poder minimizar el coste de encaminamiento siempre que la carga de cada uno de los

enlaces esté saturada.

SSMCF: se denomina Scalable Solution to Minimum-Cost Forwarding y es un algoritmo

que intenta minimizar el coste de que cualquier nodo origen envíe mensajes a un nodo

sumidero perteneciente a una red WSN de gran tamaño, teniendo en cuenta el coste mínimo

de la ruta.

Los nodos intermedios reenviarán el mensaje si ellos mismos forman parte de la ruta óptima

en función del estado de los costes, los cuales irán cambiando dinámicamente. El diseño de

este algoritmo se basa en estas características:

o Optimalidad: es la capacidad de lograr un reenvío de coste mínimo mientras que el

diseño de la mayoría de los protocolos de reenvío de datos se basa en un criterio de

Optimalidad ya elegido.

o Simplicidad: consiste en reducir al mínimo el número de operaciones realizadas, así

como los estados que mantienen cada nodo sensor cuando participan en el reenvío de

datos.

o Escalabilidad: esta solución tiene que ser escalable a redes de gran tamaño, sino no

se cumpliría uno de los principios de una red de sensores.


44

3.4. Clasificación de los protocolos de enrutamiento

Las razones por las que usar encaminamiento en las redes WSNs son:

Los nodos sensores deben manejar sus recursos con sumo cuidado puesto que poseen una

gran limitación de energía, procesamiento y capacidad de almacenamiento.

La mayoría de las aplicaciones WSN requieren de un flujo de procesamiento de datos

procedente de distintas fuentes hacia una estación base o nodo sumidero.

Los requisitos para diseñar la red WSN dependerá de su aplicación porque las redes WSNs

pretenden solventar problemas en aplicaciones específicas, en comparación con otros tipos

de redes como las redes móviles o ad-hoc que son capaces de solucionar tales

inconvenientes.

La mayoría de los nodos son estacionarios después de que hayan sido desplegados, de

manera que sus resultados son predecibles y no están sujetos a cambios topológicos.

La recolección de datos bajo condiciones normales dependerá de la ubicación, además de la

posición, que posean los nodos sensores. Esta posición se detecta mediante métodos de

triangulación tales como la unión de diferentes puntos de ondas de radio, aunque cabría

pensar que una primera aproximación podría ser aplicar la tecnología GPS en redes WSN.

Sin embargo, esto no es nada favorable por el gasto de energía que supone.

En redes WSNs existe una gran probabilidad de que los datos que han sido recolectados

presenten una cierta redundancia no deseable, por lo que es conveniente mejorar los

protocolos de enrutamiento para que utilicen la energía y el ancho de banda de la mejor

forma posible.

Debido al gran número de protocolos de red que pueden implementarse en una red WSN, se

procederá a estudiar las distintas categorías en las que se dividen tal como queda reflejado en la

Figura 3-8. Para un mayor estudio puede consultarse la referencia 5.


45

Figura 3-8. Clasificación de protocolos de enrutamiento en WSNs

La función principal de los protocolos basados en la estructura de la red (cuadro amarillo) es la

forma en la que los nodos están conectados entre sí. Por ejemplo, en los protocolos que siguen una

estructura jerárquica, los nodos de un nivel inferior han de mandar la información a los nodos de

niveles superiores, por lo que el resultado es una estructura equilibrada de la energía en toda la red.

Sin embargo, los protocolos orientados al modelo de comunicación (cuadro morado), tienen como

principal característica la forma en la que toman las decisiones para encaminar los datos sin tener en

cuenta la estructura de la red. Por lo tanto, una técnica oportuna podría ser, por ejemplo, una

negociación previa entre los nodos antes de transmitir los datos para lograr un mejor

encaminamiento.

Los protocolos basados en la topología de la red (cuadro verde) operan sin tener en cuenta las tablas

de encaminamiento de los nodos. En su lugar, cada nodo se intercambiará de forma periódica

mensajes HELLO que permite a los vecinos poder conocer sus posiciones dentro de la red. Unos

conjuntos de estos protocolos utilizan agentes móviles con el objetivo de desplazar los elementos de

procesamiento de datos hacia la ubicación de los datos detectados con el fin de reducir los gastos de

energía de los nodos.

Por último, los protocolos de encaminamiento fiable (cuadro rojo) pretenden conseguir un ahorro de

energía teniendo en cuenta las condiciones de encaminamiento de los datos. Para logarlo, intentarán

establecer múltiples rutas o incluso serán capaces de aplicar métricas QoS al encaminar desde un

origen a un destino.

A continuación, se explica con más detalle las diferentes categorías de protocolos que han sido

descritas brevemente (puede encontrarse más información en la referencia 5), así como un conjunto

de tablas con los diferentes tipos de protocolos que existe en cada categoría (las tablas de protocolos

de cada categoría se encuentran recogidas al final en el ANEXO I).


46

3.4.1. Protocolos de estructura de red

La estructura de una red se clasificará dependiendo de la uniformidad de los nodos, de manera que

podrán considerarse todos iguales o puede existir una posible jerarquía de nodos. Este hecho afectará

al funcionamiento de los protocolos de enrutamiento que supondrá la elección de las mejores rutas al

encaminar la información entre un origen y un destino.

Se diferencian dos tipos de categorías de protocolos:

Protocolos ligeros: se caracterizan porque todos los nodos de la red se comportarán con el

mismo rol. Esta arquitectura de red presenta muchas ventajas, como, por ejemplo, minimizar

la sobrecarga que se origina en las comunicaciones entre los nodos de la red.

Protocolos jerárquicos: los protocolos de encaminamiento que sigan este esquema presentan

una estructura que permite lograr una eficiencia energética, estabilidad y escalabilidad. Con

esta clase de protocolos, los nodos de la red se organizarán como clústeres en el que cada

nodo tiene una alta energía residual. El clustering permite reducir el consumo de energía,

permitiendo alargar el tiempo de la red, así los nodos podrán balancear su consumo de

energía, aunque los nodos más cercanos a una estación base consumirán más energía que el

resto de los nodos.

3.4.2. Protocolos de modelo de comunicación

El modelo de comunicación adaptado a un protocolo de encaminamiento está relacionado con la

forma en la que encaminarán los paquetes a través de la red. Los protocolos de este tipo de categoría

transferirán paquetes de datos para una cantidad de energía establecida. Asimismo, en términos de

ratio de difusión y usabilidad energética, esta clase de protocolos se comportan mejor en redes punto

a punto y broadcast.

El principal problema con estos tipos de protocolos es su fiabilidad para enviar los datos a su destino,

es decir, no son capaces de garantizar la entrega de datos.

Los protocolos con este esquema se clasifican en:

Protocolos de consultas (Query-Based Protocols): los nodos destino propagan una consulta

de datos a un nodo en concreto de la red, de forma que este nodo será el que envíe los datos

que se requieran en dicha consulta. En la Tabla 5 del ANEXO I queda reflejado alguna de

las características del protocolo Query-Based Routing

Protocolos coherentes y no coherentes (Coherent and Non-Coherent-Based Protocols): En

los protocolos coherentes los datos son reenviados por nodos agregadores después de

minimizar el procesamiento de los datos, mientras que, al realizar el procesamiento de los


47

datos con un encaminamiento no coherente, serán los mismos nodos los que procesen la

información de forma local antes de enviarlo al resto de los nodos. Los diferentes tipos de

protocolos se muestran en la Tabla 6 del ANEXO I.

Protocolos de negociación (Negotiation-Based Protocols): esta clase de protocolo de

enrutamiento usa metadatos como parte de una “negociación” previa para reducir todo lo

posible la información redundante que se intercambian entre los nodos (véase Tabla 7 del

ANEXO I).

3.4.3. Protocolos basados en la topología

Los protocolos de esta categoría se caracterizan porque cada nodo perteneciente a la red, conoce la

topología de la red.

Se clasifican de la siguiente forma:

Protocolos basados en la ubicación (Location-Based Protocols): se aprovechan de la

información que proporciona su ubicación con el fin de transmitir los datos recibidos de

ciertas regiones y no de toda la red WSN. Estos protocolos son capaces de encontrar una ruta

desde un origen a un destino y, además, minimizar el consumo de energía de los nodos

sensores. Sin embargo, tienen como limitación la escalabidad si los nodos son móviles,

aparte de que los nodos necesitan conocer o aprender donde se ubican el resto de los nodos

(ver Tabla 8 del ANEXO I).

Protocolos basados en agentes móviles (Mobile Agent-Based Protocols): se emplean en las

redes WSNs para encaminar los datos de una zona detectada hacia el destino. Están

compuestos por un agente móvil, el cual es el principal componente y se encarga de realizar

las tareas de los nodos de forma autónoma e inteligente según las condiciones del entorno.

Los protocolos basados en agentes móviles proporcionan una mayor flexibilidad a la red, en

contraste con las WSNs basadas en el modelo cliente-servidor (tal como se muestra en la

Tabla 9 del ANEXO I).

3.4.4. Protocolos de enrutamiento fiables

Los protocolos de esta categoría son capaces de recuperarse ante los errores que se originen en una

ruta, ya sea mediante el uso de balanceo de carga o mediante métricas QoS como el retardo, la

energía y el ancho de banda. El principal problema será la sobrecarga que sufrirán los nodos de red

en sus tablas de encaminamiento.

Estos protocolos se clasifican como:

Protocolos de múltiples rutas (Multipath-Based Protocols): son los protocolos más

persistentes ante fallos gracias al balanceo de carga, en este grupo de protocolos se encuentra

el protocolo RPL que será el elegido de entre todos los demás por las características que

presenta en la Tabla 10 del ANEXO I y que posteriormente en el capítulo 6 se ahondarán

profundamente.


48

Protocolos basados en la calidad de servicio (QoS-Based Protocols): estos protocolos

tienen como objetivo establecer un punto medio entre energía consumida y la calidad de los

datos. Cada vez que un nodo sumidero realice peticiones de datos a cualquier nodo sensor de

la red, la transmisión tiene que cumplir con un determinado nivel de calidad (tal como se

muestra en la Tabla 11 del ANEXO I).


49

4 Arquitectura Software

n este este capítulo se muestra una visión general de cómo es la arquitectura software soportada

por los nodos sensores que conforman una red WSN. También se detallan algunos de los sistemas

operativos que pueden integrar estos dispositivos y que permiten programar ejecutables para definir

cuál será el comportamiento y funciones a realizar por parte de cada nodo dentro de la red.

4.1. Sistemas Operativos

Como se ha comentado, cada nodo sensor se compone de un microprocesador que ejecuta un

conjunto de tareas que a su vez requieren el acceso al hardware del nodo, tales como la memoria, los

puertos de entradas/salidas y las comunicaciones.

Para que puedan coordinarse con éxito todas estas tareas, es necesario la implementación de un

sistema operativo, el cual será un software encargado de manejar los recursos del nodo y de ofrecer

una interfaz con el hardware para que sea independiente de las aplicaciones que se ejecutan en el

nodo sensor.

En la siguiente Figura 4-9, se puede apreciar el nivel que ocupa el S.O dentro de las diferentes capas

y niveles de abstracción.

E

La tecnología no es nada. Lo importante es que tengas

fe en la gente, que sean básicamente buenas e

inteligentes, y si les das herramientas, harán cosas

maravillosas con ellas.

- Steve Jobs -


50

Figura 4-9. Capas de abstracción

Las funciones que un sistema operativo tiene que realizar son:

Gestión del procesador

Gestión de la memoria

Gestión de los dispositivos

Planificación de los tiempos de ejecución

Gestión de la ejecución de tareas concurrentes

Ahorro de energía

Otras funcionalidades que no deben obviarse son la facilidad de carga y descarga de código y el

ofrecimiento de una interfaz para que las aplicaciones puedan acceder al hardware sin tener un

conocimiento detallado del mismo. Aunque las aplicaciones basadas en WSN no son tan interactivas

como las aplicaciones para PC, estos sistemas no necesitan incluir un soporte de interfaz de usuario.

En los nodos de una red WSN la capacidad de proceso y memoria están extremadamente limitados,

por lo que los sistemas operativos tienen que realizar una gestión eficiente de la energía con el

objetivo de minimizar el consumo. Estos sistemas operativos son diseñados teniendo en cuenta las

limitaciones y restricciones hardware que sufren los nodos sensores, ya que los sistemas operativos

orientados a sistemas empotrados no se adaptan a las restricciones de estos nodos, sobre todo con el

tamaño de memoria, consumo de energía y requisitos de las aplicaciones.

Investigando un poco, se puede encontrar una variedad bastante amplia de sistemas operativos que

pueden implementarse en nodos sensores. Algunos de ellos son modificaciones de soluciones

existentes para plataformas de limitadas prestaciones mientras que otros, han sido desarrollados

específicamente para los nodos de una red WSN.

Los sistemas operativos podrían clasificarse en función de las siguientes características básicas:

Arquitectura

Reprogramación

Modelo de ejecución

Planificación temporal (scheduling)


51

La arquitectura de un S.O puede ser bastante dispar dependiendo de su organización y de las

aplicaciones que ejecute. Así, se puede encontrar una arquitectura:

Monolítica: se basan en programas que integran el S.O y aplicaciones

Modular: divididos en módulos interconectados

Basada en una VM (Virtual Machine): en este tipo de arquitectura, el sistema operativo

incorporará los componentes de las aplicaciones que hacen que estas aplicaciones sean más

compactas y quede la red escondida, es decir, la persona que desarrolle las aplicaciones podrá

despreocuparse parcial o totalmente de los detalles de la red sobre la cual se ejecutarán las

aplicaciones.

El modelo de ejecución de los sistemas operativos en los nodos WSN puede estar basado en eventos,

aunque también se pueden usar hilos o threads. En este primer caso, las aplicaciones generan eventos

que son tratados uno detrás de otro y en el último, se basan en máquinas de estados.

En cuanto a la reprogramación, se refiere a la facilidad para modificar el software que se ejecuta en el

sistema operativo. En el supuesto de las redes de sensores se enfocará a la posible inaccesibilidad de

los nodos de red, que se realizaría de forma remota.

Desde el punto de vista de la planificación temporal, el procesador será quien reparta las diferentes

tareas, donde en las redes de sensores esto puede ser periódico o no periódico y critica o no critica.

Un ejemplo de evento periódico sería la temperatura del sensor, mientras que la generación de una

alarma resultaría ser no periódica, puesto que es programada para un caso concreto.

En la actualidad, cada vez se implementan más nuevos sistemas operativos para intentar cubrir

ciertas aplicaciones con las redes de sensores, además de que todos o casi todos se caracterizan por

ser de código libre. A continuación, se presentan los sistemas operativos más usados para

implementar los nodos que conforman una red WSN.

4.1.1. TinyOS

Es uno de los primeros sistemas operativos [6] creados concretamente para redes WSNs desarrollado

por la Universidad de Berkeley. Sus principales características son el uso de un reducido tamaño de

memoria, su bajo consumo de energía (bastante optimizado) y la ejecución de operación de

concurrencia intensiva (simultaneidad en la ejecución de múltiples tareas interactivas).

El sistema TinyOS está basado en un modelo de programación controlado por eventos en lugar de

multiprocesos. Los programas de TinyOS están compuestos por eventos y tareas guiadas, los cuales

están escritos en el lenguaje de programación conocido como NesC (extensión del lenguaje de

programación C).

El diseño del kernel de TinyOS está estructurado en dos niveles de planificación:


52

Eventos: son pequeños procesos pensados para interrumpir las tareas que se están

ejecutando. Por ejemplo, cuando el contador del timer (temporizador) se interrumpe, saltará

un evento que ejecutará las funciones que se hayan programado para ello.

Tareas: están realizadas para llevar la carga de procesamiento, por lo tanto, no serán críticas

en tiempo. Las tareas, a diferencia de los eventos, se ejecutarán en su totalidad, pero la

solicitud de iniciar una tarea y el término de ella son funciones separadas.

El diseño de TinyOS permite que los eventos se ejecuten rápidamente pudiendo interrumpir a las

tareas, que llevaran una mayor carga computacional.

4.1.2. ContikiOS

Es un sistema operativo de código abierto, multitarea y de elevada portabilidad [7] que fue

desarrollado para usarse en pequeños sistemas. Desde ordenadores de 8 bits a sistemas embebidos

sobre microcontroladores, incluyendo nodo de redes de sensores, además, dispone de un potente

simulador/emulador llamado COOJA/MPSim que simplifica bastante el desarrollo de las

aplicaciones. Su creador es Adam Dunkels, quien lo diseñó en el Instituto Sueco de Ciencias

Computacionales.

Contiki a pesar de ser multitarea, incluye una pila TCP/IP, y solo requiere de varios kilobytes de

código y unos cientos de bytes de memoria RAM. Destaca por ser un sistema totalmente completo

con una GUI (Interfaz de Usuario Grafica) que solo necesita de 30 kB de RAM.

Una configuración típica de Contiki es 2 kB de RAM y 40 kB de ROM, cuyo núcleo o kernel está

orientado a eventos que hace uso de protothreads, sobre el cual los programas son cargados y

descargados dinámicamente. También soporta multihilado apropiativo opcional por proceso, es

decir, comunicación entre procesos mediante el paso de mensaje a través de eventos.

El lenguaje de programación sobre el que está implementado es en C, por ello, funciona en una gran

variedad de plataformas, desde microcontroladores embebidos como el MSP430 y el AVR, a viejos

computadores domésticos.

Debido a estas características, ContikiOS será el sistema operativo usado para crear los nodos de la

red WSN de este proyecto.

4.1.3. FreeRTOS

Es un sistema operativo en tiempo real [8] de código abierto cuyo kernel es totalmente gratuito y esta

implementado en el lenguaje de programación C en su mayoría. Sin embargo, ciertos bloques se


53

encuentran escrito en ensamblador. Es líder del mercado de RTOS y esta soportado por 31

arquitecturas de sistemas embebidos.

FreeRTOS ofrece las siguientes características:

- Diseñado para ocupar poca memoria, ser simple y fácil de usar

- Tiene una estructura de código altamente portable

- Permite el uso de procesos y corrutinas por separados o ambos a la vez

- Ofrece un potente mecanismo de traza de ejecución y optimización

- Facilitan aplicaciones de prueba (demos) preconfiguradas para el RTOS

- Se puede considerar de tipo microkernel pues tan sólo nos ofrece un planificador y una API

para comunicar procesos entre si

Está diseñado para microcontroladores de limitados y medianos recursos, entre 32 kB y 512 kB de

memoria Flash y 16 kB y 256 kB de memoria RAM. También puede soportar microcontroladores de

9kB de RAM

4.1.4. MantisOS

Es un sistema operativo [9] que surge ante el incremento de la complejidad de las tareas que tienen

que realizar los nodos de una red de sensores como son la compresión, agregación y procesamiento

de señales.

Los multiprocesos de MantisOS (conocido también como MOS) permiten interpaginar complejas

tareas con tareas susceptibles al tiempo, para lograr mitigar los problemas en los saltos de buffers.

Para ello, MOS esta implementado para utilizar una pequeña cantidad de memoria RAM, donde con

menos de 500 bytes de memoria (incluyendo kernel, controladores de tiempo y pila de

comunicación) es capaz de obtener un ahorro de energía bastante considerable, consiguiendo que el

microcontrolador solo consuma unos pocos µA cuando pasa a modo sleep tras ejecutar todas las

tareas activas.

MantisOS destaca por lo siguiente:

Flexibilidad en el soporte de múltiples plataformas como PCs, PDAs y diferentes plataformas

de microsensores.

Soporte de control remoto

Reprogramación dinámica

Acceso remoto

4.1.5. Nano-RK

Se trata de un sistema operativo totalmente preventivo [10] basado en la reserva bajo tiempo real

(RTOS) con soporte para redes multisalto y adecuado para implementarse en redes WSN.

Nano-RK es capaz de realizar tareas preventivas con prioridad para asegurar que los plazos de las

tareas son conocidos, además de tener un soporte de CPU, red, sensores y actuadores.


54

Está compuesto por tareas que pueden especificar las demandas de recursos y el SO provee el acceso

controlado para los ciclos de CPU y paquetes de las redes, donde todos estos recursos forman la

reserva de energía virtual que permite a Nano-RK poder controlar el nivel de energía del sistema y de

las tareas.

Finalmente, una vez han sido descritos los diferentes sistemas operativos que pueden usarse en los

nodos de una red WSN, se ha creado la siguiente tabla para tener una visión más global de todos

ellos.

Tabla 4-12. Sistemas operativos soportados en WSN

Sistema

Operativo

Basado en

Tarea

Soporte para

Threads

Simulador

Asociado

Reprogramación

inalámbrica

Compatibilidad

TCP/IP

TINY OS X TOSSIM NO

CONTIKI X COOJA X SI

MANTIS OS X N/A X NO

NANO-RK X N/A X NO

Analizando la Tabla 4-12, se llega a la conclusión que el sistema operativo que cumple los requisitos

y es más completo para las pruebas de este trabajo es Contiki.


55

5 Protocolo 6LoWPAN

n este capítulo se describe el protocolo de comunicación 6LoWPAN que se va a implementar en

los nodos de la red WSN. También se explican los motivos por los que se ha elegido este

protocolo y no el de ZigBee, su similitud con el protocolo de direccionamiento IPv6, las

funcionalidades que proporciona dentro de la red, y, por último, la manera de empaquetar,

fragmentar y comprimir los paquetes que se transmitirán y recibirán en los nodos.

Incluso se explicará el tipo de seguridad que implementa este tipo de protocolo frente a posibles

vulnerabilidades.

5.1. Protocolo ZigBee

Este protocolo fue desarrollado por ZigBee Alliance [11] debido a que el estándar IEEE 802.15.4

sólo cubría hasta la capa de enlace (nivel 2 del modelo OSI) de la arquitectura de las redes WSNs.

Se diseñó para aplicaciones que requieren comunicaciones seguras con baja tasa de envío de datos y

maximización de la vida útil de sus baterías. De modo que ZigBee implementa las capas del IEEE

802.15.4 y añade sus propias capas de niveles superiores permitiendo obtener una pila de protocolos

con funcionalidades bastante completas (como se aprecia en la Figura 5-10). Por esto, se convierte en

un protocolo muy viable para implementar en las redes WSNs.

Figura 5-10. Pila de protocolos ZigBee

E

El gran mito de nuestro tiempo es que la tecnología es

la comunicación

- Libby Larsen -


56

Una de las principales características de ZigBee es que implementa la comunicación radio del

802.15.4 para transportar la información permitiendo que haya un bajo consumo y baja latencia en

las comunicaciones. Las principales ventajas según ZigBee Alliance son:

Seguridad basada en cifrado AES de 128 bits

Soporte para múltiples topologías de red (estática, dinámica, estrella y malla)

Capacidad de hasta 65000 dispositivos

Reduce tiempos de espera en el envío y recepción de paquetes

Proporciona larga duración de la batería

Ideal para conexiones P2P y P2MP

Sin embargo, ZigBee Alliance está formado por un conjunto de compañías que manufacturan

semiconductores, así que aprovechan que tienen las especificaciones para crear productos ya

terminados para vender, evitando que haya un desarrollo libre de aplicaciones propias y comerciales.

Es por esto, que a pesar de las características que posee presenta dos grandes inconvenientes:

No es compatible al intentar conectar con redes externas debido a que su esquema de

direccionamiento no es compatible con el protocolo IP impidiendo conexiones directas entre

los dispositivos.

No tiene implementado un protocolo de enrutamiento con capa de red ni de capa de

transporte.

Es un protocolo propietario, por lo que no puede desarrollarse aplicaciones comerciales con

dicho protocolo hasta que no se forme parte del grupo ZigBee Alliance.

5.2. Protocolo 6LOWPAN

El estándar 6LowPAN conocido como IPv6 over Low Power Wireless Personal Area Network

(consultar referencias [12], [13], [14], [15], [16] y [17]) fue desarrollado por la IETF con el objetivo

era encontrar una solución al transporte de paquetes IPv6 sobre tramas IEEE 802.15.4.

Es una alternativa al protocolo ZigBee, ya que implementa direccionamiento IPv6 (cumpliendo el

propósito de IoT) en vez de IPv4 debido a que ofrece mayores ventajas (espacio direccionamiento,

escalabilidad, autoconfiguración sin estado…) y logra la interconexión directa de las WSN con otras

redes externas. Sin embargo, su uso en este tipo de redes supone un incremento del tamaño de las

direcciones IPv6 y del MTU en 1280 bytes.


57

Este fue el motivo de la aparición del protocolo 6LowPAN y por esto, proporciona mecanismos de

encapsulación y compresión de cabeceras para la transmisión de paquetes permitiendo adaptarse a

las restricciones del protocolo 802.15.4 (máximo 127 bytes) llegando a alcanzar un tamaño de 4

bytes.

Figura 5-11. Ejemplo de red WSN implementado con 6LoWPAN

Las ventajas de este protocolo frente a las soluciones tradicionales y propietarias se resumen en que:

El uso de direcciones IP permite tener una infraestructura de red ya existente.

Es un estándar abierto.

Existen herramientas para el diagnóstico y gestión de redes IP.

Los dispositivos con IP pueden conectarse directamente a redes IP sin la necesidad de

entidades intermedias, como son proxies o gateways.

Soporta anchos de banda con tasas de transferencia de hasta 259 kbps, 40 kbps y 20 kbps

(según se defina en la capa física)

Soporta direcciones MAC de 16 bits cortas o 64 bits extendidos

Soporta un gran número de dispositivos conectados a la red

La localización de estos dispositivos no está predefinida en algunos casos ya que podrían

cambiar de posición dinámicamente


58

Los dispositivos en una red 6LowPAN suelen estar largos periodos de tiempo en modo de

hibernación (Sleep Mode) para ahorrar energía

5.2.1. Pila de protocolos

La pila de protocolos que presenta 6LoWPAN es bastante parecida a la de IPv6, pero con diferencias

notables en la capa física y de enlace, tal como se muestra en la Figura 5-12.

Figura 5-12. Pila protocolos 6LoWPAN frente IPv6

Este protocolo es compatible con IPv6 gracias a una pequeña capa de adaptación que permite

conexiones IPv6 sobre IEEE 802.15.4, de manera que puede ser mostrado como parte de la capa de

red.

En la capa de transporte, 6LoWPAN viene implementado por el protocolo de transporte UDP, el cual

puede ser comprimido, mientras que el protocolo TCP normalmente no es usado por motivos de

rendimiento, eficiencia y complejidad.

6LowPAN utiliza el protocolo de control de mensajes de Internet conocido como ICMPv6 para los

mensajes de control, descubrimiento de vecinos y detección de destinos inalcanzables. Esta

adaptación de IPv6 y el formato 6LowPAN se lleva a cabo en los routers frontera.

5.2.2. Funcionalidad

En una red LoWPAN los dispositivos desempeñarán distintos roles:

El edge router o router border es el encargado de encaminar el tráfico entre la red IPv6 y la

LoWPAN, por lo que es el responsable de la interacción entre los protocolos IPv6 y

6LowPAN a través de la compresión y descompresión de las cabeceras, así como del proceso

de descubrimiento de vecinos ND.

Los routers serán nodos con capacidad de encaminamiento, idóneos de enrutar los paquetes

6LowPAN hacia el resto de nodos que se encuentren a su alcance.


59

Los hosts son los nodos sensores de la red WSN que no necesitan estar siempre activos para

no malgastar la energía de sus baterías.

5.2.3. Formato de transmisión

El estándar permite encapsular paquetes de red IPv6 sobre tramas de enlace IEEE 802.15.4 siempre

que no supere los 127 bytes. Para ello, tiene que definirse la capa de adaptación, la cual será la

encargada de realizar las modificaciones y de añadir la información de cabareteras adicionales para

lleva a cabo el proceso de encapsulación.

Además, ofrece un mecanismo de soporte mesh-under, fragmentación o compresión de cabeceras de

capas superiores.

El formato de un paquete 6LowPAN se representa en la siguiente Figura 5-13:

Figura 5-13. Formato mensaje 6LoWPAN

Las cabeceras de adaptación comenzarán con un campo de 8 bits, que se conoce como dispatch byte

y permite indicar el tipo de cabecera del que se trata (ver Figura 5-14).

Figura 5-14. Cabecera capa de adaptación 6LoWPAN


60

5.2.4. Direccionamiento mallado o mesh addressing

Cuando se producen comunicaciones de nodos dentro de la misma red, será la capa de adaptación la

que se encargue del encaminamiento. En este caso se añadirá una cabecera 6LowPAN llamada mesh

header y en ella se incluirán las direcciones de nivel de enlace origen/destino y el nº de saltos.

Los nodos en función de sus tablas de encaminamientos constituirán la trama de nivel de enlace con

el propósito de que llegue la información al nodo destino en el menor número de saltos posible.

5.2.5. Fragmentación y reensamblado

Uno de los aspectos fundamentales del protocolo 6LowPAN y por el cual es implementado en las

redes WSNs, es la facilidad fragmentar las tramas IEEE 802.15.4 antes de su transmisión, siempre

que estas sean mayores a 127 bytes (longitud del tamaño de trama máximo).

En estas dos figuras se muestra cual es la estructura de trama y los formatos de cabecera definidos

por este protocolo para implementar satisfactoriamente la fragmentación.

Para poder optimizar el proceso de reensamblaje de los paquetes, se debe incluir el tamaño total del

paquete 6LowPAN en todos los fragmentos junto con el desplazamiento (offset), expresado en

múltiplos de 8 bytes indicando siempre el fragmento del paquete que se incluye.

Cada paquete tendrá un identificador único donde sus fragmentos se identificarán con la misma

etiqueta.

Figura 5-16. Formato cabecera 1er fragmento

Figura 5-15. Formato cabecera continuación fragmentos


61

5.2.6. Compresión de cabeceras

Uno de los principales problemas de 6LowPAN es que la encapsulación directa de un paquete de

tipo IPv6 sobre una trama IEEE 802.15.4 no resulta ser óptimo, debido a que la relación entre carga

útil y cabeceras es muy baja.

Actualmente 6LowPAN utiliza dos formatos de compresión de cabeceras, el primero se conoce

como Header Compression 1 (HC1)-Header Compression 2 (HC2) definido en el RFC 4944 [12],

el cual es bastante obsoleto, pero puede ser usado para descomprimir paquetes basados en la versión

antigua del estándar. El segundo formato de compresión definido en el RFC 6282 [14] se conoce

cómo IP Header Compression (IPHC)-Next Header Compression (NHC). Este presenta grandes

ventajas frente a la primera versión del estándar como la compresión de direcciones basada en

contexto.

5.2.6.1. Compresión HC1-HC2

Es el método de compresión de la RFC 4944 [12] cuyo principal objetivo es desechar la redundancia

existente en la cabecera IPv6 y para ello, se basará en la información que ofrece la cabecera MAC. A

parte, ofrece mecanismos de compresión para la cabecera de transporte UDP como se muestra en la

Figura 5-17.

Figura 5-17. Compresión de cabeceras HC1-HC2

Dentro de la cabecera de IPv6, hay un conjunto de campos que son considerados irrelevantes como

la clase de tráfico, la etiqueta de flujo, la próxima cabecera…, donde estos pueden ser eliminados,

salvo el número de saltos, el cual es estrictamente necesario.

Este mecanismo de compresión permite incluso comprimir los campos asociados al

direccionamiento (no siempre se puede) si se conocen las direcciones MAC (unívocas en cada uno

de los nodos). Aunque el uso de un segundo mecanismo de compresión permita reducir la cabecera

UDP, ésta deberá añadir una cabecera HC2 con la información asociada a la compresión.

23 – 44 1 40 8 – 20 20 – 53 2

23 – 44 2 – 3 1 3 - 56 24 – 97 2

1 1 1


62

Finalmente, todos los campos que no hayan sido comprimidos, deberán colocarse después del

contador del número de saltos, mientras que los que correspondan a IPv6 deben seguir el orden

impuesto por la cabecera HC1 y los correspondientes a UDP por la cabecera HC2. Con todo esto, se

permite aumentar de forma sustancial el tamaño de la información útil a base de eliminar

información redundante.

5.2.6.2. Compresión IPHC-NHC

Es un mecanismo que surge con el fin de optimizar la compresión de los prefijos de red, puesto que,

con el método de compresión anteriormente descrito, si un dispositivo 6LoWPAN quisiera

comunicarse con un nodo externo de su propia red, no sería suficiente con conocer las direcciones

MAC del nodo, puesto que habría que conocer el prefijo de la red para enrutar los paquetes que

intercambiasen.

El método de compresión basado en contexto está definido en la RFC 6282 [14], reemplazando a la

RFC 4944, el cual permite trabajar de forma paralela con el método HC1-HC2. Sin embargo, el

estándar recomienda que todas las implementaciones que se efectúen se lleven a cabo en el formato

de compresión IPHC-NHC, así como la compresión y trasmisión de paquete pudiendo usar sólo el

HC1-HC2 para la descompresión y favorecer a la interoperabilidad.

A diferencia del método anterior en el que se juntaban todas las cabeceras y a continuación todos los

campos no comprimidos, en este estándar, los últimos 5 bits del campo dispatch byte son usados para

la cabecera IPHC donde además de la agregación de diferentes cabeceras, le seguirán los campos

comprimidos por la misma.

Su formato general se visualiza en la Figura 5-18.

Figura 5-18. Compresión de cabeceras IPHC-NHC

23 – 44 40 8 – 20 n 2

23 – 44 ≥ n

2

1 1 1


63

La información de cómo se lleva a cabo la compresión de la cabecera quedara guardada en la

cabecera IPHC.

Para concluir, este mecanismo de compresión de cabeceras IPHC-NHC consigue lograr una mejora

significativa desde el punto de vista de la compresión de direcciones IPv6 cuando se desea establecer

comunicaciones con el exterior de una red.

5.2.7. Descubrimiento de vecinos

Uno de los problemas de implementación del protocolo 6LoWPAN es su descubrimiento de vecinos,

también conocido como Neighbors Discovery debido a que resulta muy poco eficiente.

Cuando se inicia el proceso de descubrimiento, el encargado de distribuir el prefijo de red al resto de

nodos para que estos puedan generar sus respectivas direcciones IPv6, será el border router.

El procedimiento consiste en que un nodo sensor desea adherirse a la red WSN y para ello debe

solicitar al router información de la red, a través del mensaje Router Solicitation (RS). El router le

responderá con el mensaje Router Advertesiment (RA), una vez que el host recibe dicho mensaje,

deberá enviar una solicitud al router para poder registrarse en la red, para ello mandara el mensaje

Node Registration (NR), en el que tiene que ir indicado la dirección de red con la que quiere ser

identificado el host (ya sea por autoconfiguración o manualmente).

Tras haber recibido el router el mensaje, tendrá que ejecutar un mecanismo de comprobación para

acreditar que no haya direcciones duplicadas y una vez sea así, responderá al nodo sensor con un

mensaje Node Confirmation (NC).

A continuación, en la Figura 5-19 se observan los pasos para el procedimiento de descubrimiento de

vecinos en 6LoWPAN.

Figura 5-19. Procedimiento 6LoWPAN-ND

Router Solicitation (RS)

(RA) Router Advertisement

Node Registration (NR)

(NC) Node Confirmation


64

Si los nodos de la red no fueran capaces de alcanzar al border router, serían los routers de la red los

que funcionarían como intermediarios en la comunicación, es decir, los encargados de encaminar los

mensajes que se intercambiarían los nodos sensores con el border router llegando incluso a

almacenar de forma temporal la información destinada a los nodos si estos estuvieran en modo sleep.

Como cambio de este nuevo protocolo ND respecto al implementado en IPv6, cabe destacar que se

han eliminado las direcciones multicast con el fin de reducir la energía en los dispositivos y obligar a

los nodos sensores a iniciar la comunicación para facilitar el estado sleep de estos.

5.2.8. Encaminamiento

Es uno de los principales problemas por las limitaciones en consumo y procesamiento de los nodos

de la red. Aunque existen distintos protocolos que pretenden solventar estos problemas con el fin de

adaptarse a este tipo de redes, pero se contemplarán más adelante.

Dependiendo de la capa en la que se lleve el encaminamiento se distingue entre:

Mesh-Under (nivel 2): este tipo de encaminamiento se caracteriza por ser la capa de

adaptación la que gestiona el encaminamiento a través de las direcciones de enlace, gracias a

la cabecera Mesh de 6LoWPAN. Cada nodo que decida enviar un paquete deberá escribir en

la capa de adaptación su dirección MAC y la del destino final.

Cuando la trama de enlace llegue a un dispositivo que no sea el nodo final, actualizara las

direcciones de cabecera MAC, a parte de decrementar el número de saltos de la cabecera

Mesh antes de encaminar hacia el próximo nodo.

La desventaja de este encaminamiento se genera al fragmentar la trama y uno de los

fragmentos se pierde, puesto que tiene que retransmitir el paquete IP desde el nodo principal,

aumentando el gasto de energía en toda la red. Además, este procedimiento impide

comunicar con redes al exterior que no sean WSNs.

Router-Over (nivel 3): se lleva a cabo en la capa de red, donde cada salto a nivel MAC se

computa como un salto a nivel IPv6, de forma que al producirse una fragmentación a nivel

IPv6, dichos fragmentos se envían al siguiente salto usando la información de las tablas de

encaminamiento. La capa de adaptación del siguiente salto es la encargada de comprobar que

todos los fragmentos sean correctos y los juntara para mandarlos a la capa de red.

Si un fragmento se perdiera, se retransmitiría desde el nodo anterior a diferencia del mesh-

under. Sin embargo, este método tiene un alto consumo de energía debido a los dominios

multicast de los enlaces IPv6.


65

Desgraciadamente estos tipos de encaminamiento no son apropiados para redes WSNs, por lo que el

IETF decidió crear el grupo de trabajo ROLL para diseñar el protocolo de encaminamiento RPL con

el objetivo de definir un protocolo de enrutamiento eficiente en estos tipos de redes.

5.2.9. Seguridad

Este estándar establece diferentes mecanismos de seguridad a través de cada una de las capas que

emplea.

En la capa de enlace hace uso del mecanismo de encriptación basado en el cifrado de bloques AES,

mientras que en la capa de red utiliza el protocolo IPsec (Internet Protocol security) y poder

garantizar la seguridad extremo a extremo.

Para la capa de transporte es recomendable basarse en el protocolo TLS (Transport Layer Security) o

en DTLS (Datagram Transport Layer Security) que es la versión adaptada al protocolo UDP.

A pesar de las distintas opciones, los mecanismos de seguridad siguen siendo un tema de debate

dentro del IETF.


66


67

6 Protocolo RPL

n este capítulo se otorga una visión general acerca del protocolo de enrutamiento de capa red

conocido como RPL resaltando sus características y su funcionamiento, así como los parámetros

que son tenidos en cuenta en la formación del grafo o árbol, sus diferentes mensajes de control, los

distintos tipos de tráfico que puede haber en la red, su implementación con 6LoWPAN y la seguridad

que permite incorporar en la red, entre otros puntos.

6.1. Diseño del protocolo

El protocolo RPL [18] fue diseñado con el objetivo de cubrir las necesidades de enrutamiento en

redes LLNs (Low-Power and Lossy Networks) (consultar referencias 19,20,21 y 22) desplegadas en

edificios automatizados, casas inteligentes, ciudades e industrias.

Para la creación de dicho protocolo, el organismo de la IETF decidió crear un grupo de trabajo

conocido como ROLL (Routing Over Low power and Lossy Networks) basado específicamente en

desarrollar un protocolo de encaminamiento unicast en IPv6 cuyo nombre fue RPL (Routing

Protocol for Low Power and Lossy Networks).

El objetivo de haber diseñado este protocolo se debe a que protocolos como AODV, DSR y FCP son

protocolos de tipo reactivo, es decir, buscan las rutas cuando es necesario transmitir datos dentro de

una red causando un derroche energético que incumple con los requisitos establecidos en una red

WSN.

RPL se caracteriza por ser un protocolo proactivo basado en vector de distancia, el cual define las

rutas antes de que sean necesarias por los nodos de la red. Su modo de funcionamiento está basado

en el intercambio de mensajes de control (enviados de forma periódica) para encontrar y propagar

rutas en la red, estos mensajes pueden ser a nivel local o de enlace permitiendo el envío de

información a los vecinos o a nivel global para propagar la información relacionada con la topología

a todos los nodos de la red.

Es un protocolo de red con arquitectura IP que separa las tareas de procesado y reenvío de paquetes

(son encaminados en base a la tabla de enrutamiento). Este protocolo como anteriormente se ha

comentado, está orientado a un enrutamiento de vector de distancia genérico que tiene definida una

Función Objetivo (OF) compuesta por una combinación de métricas y restricciones que permiten

elegir el “mejor camino”.

E

Tenemos un plan estratégico.

Se llama hacer las cosas bien.

- Herb Kelleher -


68

Otra de las ventajas de RPL es que no tiene una capa de enlace definida, por lo que está diseñado

para soportar diferentes capas de enlace. De todas ellas para este proyecto se ha decidido elegir la

proporcionada por el estándar IEEE 802.15.4.

La implementación de este protocolo requiere del uso de enlaces bidireccionales que permite crear

una estructura de red en forma de árbol donde los nodos de la red podrán unirse a múltiples

instancias RPL, pero solo podrán pertenecer a un DODAG por cada instancia y cada nodo raíz o root

node de la red construirá una instancia que será un árbol de encaminamiento.

6.2. Topología usada

Desde el punto de vista del protocolo RPL, la red se va a organizar en forma de grafo creando una

topología conocida como Direct Acyclic Graph (DAG) compuesto por uno o varios nodos raíces o

“root nodes” que actúan como nodos sumideros o “sink nodes”, donde a partir de estos nodos, el

grafo se irá dividiendo en nodos hijos o “leaf nodes” que se comunicarán con los nodos o nodo raíz a

través del mensaje DODAG (Destination Oriented DAGs), característico de cada root node.

Si el DAG contiene varios nodos raíz, estos deberán estar agrupados formando una federación.

Para la formación de un grafo RPL debe construirse un DODAG siguiendo el siguiente proceso:

1) Escoger aquellos nodos que estarán configurados como DODAG roots y contendrán la

configuración del DODAG.

2) Estos nodos deberán anunciar su configuración, su afiliación con un DODAG, y su coste de

encaminamiento a través de la difusión de mensajes DIO (DODAG Information Object).

La información mínima que debe transportar un mensaje DIO es la siguiente:

o RPLInstanceID: es un identificador único para una instancia RPL que identifica a

uno o más DODAGs. Una WSN puede estar formada por múltiples instancias donde

cada una de ellas identifica a un DODAG y tendrá definida su propia Función

Objetivo (OF).

El conjunto de DODAGs identificados por un RPLInstanceID se conoce como

RPLInstance y todos los DODAGs de una misma instancia RPL tendrán la misma

OF.

o DODAGID: este parámetro será una instancia RPL, en la que con la combinación del

RPLInstanceID y el DODAGID identificarán de forma unívoca a un DODAG dentro

de la red. Una instancia RPL podrá contener múltiples DODAGs, en el que cada uno

tendrá su propio ID.

o DODAG Version Number: es un parámetro usado por el nodo raíz para reconstruir el

DODAG.


69

o Rank: permite conocer la posición de cada nodo con respecto al DODAG root o nodo

raíz, de manera que su valor incrementará si se mueve desde el nodo raíz hasta los

nodos hijos. Dicho rank será calculado a partir de una Función Objetivo (OF), la cual

utilizará una métrica para determinar la conveniencia del nodo, por ejemplo, para

elegir el siguiente mejor salto para poder llegar al root node y minimizar su gasto

energético.

El root node para iniciar la formación del DODAG enviará mensajes DIOs de tipo broadcast

a sus vecinos, siendo el único capaz de llevar a cabo este proceso y ningún otro nodo podrá

realizarlo. Durante este proceso difusión de mensajes, los campos RPLInstanceID y el

DODAGID permanecerán sin cambios durante la formación de la topología, mientras que el

único campo que se verá alterado cada vez que un mensaje DIO atraviese la red, será el Rank.

El nodo raíz tendrá un valor Rank igual a 0, ya que la distancia a sí mismo es cero, mientras

que los nodos que reciban el mensaje de difusión DIO tendrán que calcular este valor en

función de la OF como el número de saltos o distancia hasta el nodo raíz contabilizando su

Rank a partir de 1.

3) El resto de nodos estarán a la escucha de estos mensajes DIOs y los usarán para unirse al

nuevo DODAG e iniciar el proceso de selección para elegir al mejor nodo padre o seguir

perteneciendo al DODAG anteriormente elegido. Las decisiones tomadas por cada nodo

dependerán de cómo hayan definido su Función Objetivo y su Rank y los de sus vecinos.

Cuando un nodo de la red reciba el mensaje DIO, éste mantendrá a un conjunto de nodos

vecinos candidatos eligiendo aquellos que tengan un valor de rank igual o inferior al suyo

propio, para que se conviertan en “nodos padres”. Si hubiera más de un “nodo padre”, se

elegirá a uno de entre todos ellos basándose en la OF permitiendo asignar el siguiente salto

para encaminar los datos hacia el nodo raíz.

4) Cada entrada de la tabla de encaminamiento de los nodos registrará los destinos

especificados según el mensaje DIO, así como el DODAG parent del DODAG Version. Los

nodos que decidan unirse a este DODAG deben elegir uno o más DODAG parents como

siguientes saltos para la ruta por defecto de esa instancia.

Una vez calculado el rank de un nodo, éste propagará el mensaje DIO actualizado al resto de

sus vecinos (dicho mensaje será descartado por el nodo raíz debido a que es el que contiene

el valor del Rank más pequeño de toda la red), los cuales repetirán el mismo proceso para

calcular el Rank en función del OF y reenviando el mensaje DIO actualizado al resto de

nodos vecinos.


70

La descripción de este procedimiento queda reflejada en la Figura 6-20.

Figura 6-20. Formación grafo DODAG

Cuando se haya formado el grafo DODAG, cada nodo debe seleccionar un nodo padre o parent node

de todos sus vecinos y calcular su propio rank, cuyo valor tendrá que ser mayor que los parent nodes

para evitar la formación de bucles al realizar el encaminamiento.

Cada nodo de la red WSN que esté implementado con el protocolo RPL tiene que venir definido por

una Función Objetivo (OF) que permite seleccionar y optimizar las rutas dentro de una instancia

RPL. La OF viene identificada por el Objetive Code Point (OCP), el cual forma parte de la

configuración de un mensaje DIO y permite calcular qué rutas son más ventajosas para un nodo

cuando tenga que enviar un paquete o reenviarlo porque él no sea el nodo destino.

Para definir una Función Objetivo hay que basarse en un conjunto de métricas como, por ejemplo, el

nivel de energía o potencia de un nodo, el cual puede ser usado en la OF para calcular el rank, de

manera que cuando un nodo seleccione a un parent node elegirá al vecino con el valor del rank más

bajo y a la vez con el nivel de energía y potencia más bajo también. Esto quiere decir que la OF

tendrá en cuenta el número de saltos como una de sus métricas.

(I) (II)

(III) (IV)

1

1

1 1

1

1

1

1

1

1

1

1

2

2

2

2

3 3

3

2

2 2

2

2

2 2

2

3 3

3

2

2

2

2

3 3

3


71

6.3. Flujo de tráfico en RPL

Por defecto, el protocolo RPL dispone de un mecanismo multipunto a punto (MP2P) para el envío de

los datos de los nodos de la red hacia el nodo raíz. Este tipo de tráfico se conoce como “upward” o

“tráfico hacia arriba” y esta implementado con el uso de mensajes DIO.

Sin embargo, RPL es capaz de funcionar mediante otro mecanismo denominado flujo de tráfico

“hacia abajo” o “downward” basado en una conexión punto a multipunto (P2MP). El

establecimiento de rutas downward se establece mediante el intercambio de mensajes DAO

(Destination Advertisement Object).

El trafico P2P (punto a punto) es encaminado mediante tráfico “upward” hasta encontrar un nodo

ancestro común que conozca una ruta del DODAG hasta su destino. Esta especificación permite

distinguir entre tráfico en modo storing y non-storing.

En el modo storing, todos los nodos almacenarán el estado de las rutas de los otros nodos, mientras

que en el modo non-storing, ningún nodo intermedio conocerá ninguna ruta downward, así que los

paquetes irán encaminados directamente al nodo raíz.

El Rank de un nodo permite definir su posición en el DODAG en relación con otros nodos con

respecto al DODAG raíz. El valor del Rank se incrementará conforme se vaya descendiendo por el

DODAG y se decrementará cada vez que se ascienda por el DODAG.

6.3.1 Storing Mode

El modo de operación storing se caracteriza porque los nodos no deben direccionar mensajes DAO

unicast a otros nodos que no sean nodos padres.

Los mensajes DAOs anunciarán direcciones destino y prefijos que un nodo tiene que ser capaz de

encaminar. Todos los nodos que no sean root ni nodos hijos deben ser capaces de almacenar en sus

tablas de encaminamiento las direcciones aprendidas por los mensajes DAOs, es decir, que cuando

un nodo reciba un paquete con una dirección destino, el siguiente paso será consultar su tabla de

encaminamiento.

Las reglas que tienen que seguir los nodos que implementen este modo serán las siguientes:

1. El subcampo DODAG Parent Address debe aparecer vacío.

2. Cuando se reciba un mensaje unicast DAO, el nodo debe calcular si dicho mensaje obligaría

a cambiar el conjunto de prefijos que el propio nodo ha anunciado. Esta comprobación es

llevada a cabo para determinar si el mensaje DAO contiene la información más actualizada

de la red.

3. Cada vez que un nodo genere un mensaje DAO, éste tiene que ser de tipo unicast para cada

uno de sus nodos padres.


72

La definición de estas reglas queda reflejada en la Figura 6-21.

Figura 6-21. Funcionamiento en modo storing

Si un nodo recibe un mensaje DAO que contiene la información más reciente, este deberá

retransmitirlo al resto de sus nodos vecinos. Dicho mensaje DAO tendrá que ser enviado vía unicast a

cada uno de los nodos padres.

6.3.2. Non-Storing Mode

Este modo de encaminamiento permite distribuir los mensajes hacia abajo o downward, pasando

siempre por el root node. A continuación, se describe las reglas que usan los nodos que implementan

este modo de funcionamiento:

1. El subcampo DODAG Parent Address debe tener almacenado una o más direcciones, las

cuales deben ser direcciones de los DAO parents.

2. Los mensajes DAO se enviarán directamente al nodo raíz a través de las rutas por defecto

configuradas en los nodos padres.

3. Cuando un nodo elimine su DAO parent, debe de generar un nuevo mensaje DAO para avisar

a sus vecinos de los cambios.


73

El funcionamiento de este modo se muestra en la Figura 6-22.

Figura 6-22. Funcionamiento en modo non-storing

En resumen, el modo Non-Storing, un nodo usara el mensaje DAO para avisar a sus nodos padres

dónde se encuentra el nodo raíz. El nodo raíz podrá reconstruir una ruta hacia abajo a través de los

nodos padres para llegar a un nodo especifico.

6.4. Mensajes de control ICMPv6 RPL

En este apartado, se describe cada uno de los mensajes intercambiados por los nodos que usen RPL

para la formación de la red, así como su formato y las reglas que se tienen que seguir para su

transmisión.

La mayoría de los mensajes de control descritos en este apartado tienen el alcance de un enlace, la

única excepción son los mensajes DAO y DAO-ACK en el modo non-storing que se intercambian

mediante una dirección única en múltiples saltos y, por lo tanto, debe usar direcciones globales o

locales únicas, tanto para dirección origen como destino.

Todos los mensajes ICMPv6 RPL implementaran una dirección de enlace local para hacer referencia

a la dirección origen de cada nodo, mientras que la dirección de destino será una dirección de

multidifusión RPL o una dirección local unicast.


74

El mensaje de control RPL se compone de una cabecera ICMPv6 seguida por un cuerpo de mensaje,

el cual está compuesto de una base de mensajes y opciones que dependerán del tipo de mensaje. A

continuación, se muestra en la Figura 6-23 el esquema de un mensaje de control RPL.

Figura 6-23. Mensaje de control RPL

6.4.1. DODAG Information Object (DIO)

Es el primer mensaje que recibe un nodo de la red cuando el root node envía la configuración del

DODAG por difusión, permitiendo al nodo descubrir la instancia RPL, aprender cómo están

configurados los parámetros e incluso establecer un DODAG parent o mantener el DODAG al que

pertenecía.

El formato de un mensaje DIO que es recibido por un nodo se muestra en la Figura 6-24.

Figura 6-24. Formato de un mensaje DIO


75

Grounded (G): es una bandera que indica si el DODAG es correcto para la aplicación

definida por el protocolo RPL.

Mode of Operation (MOP): es un campo que identifica el modo de operación de la instancia

RPL que se suministra y es distribuido por el nodo raíz del DODAG. Los nodos que se unan

al DODAG deben ser capaz de cumplir con el MOP para poder participar plenamente como

un router, o de lo contrario sólo podrán unirse como nodos hijos. Los tipos de MOP se

representan en la Figura 6-25.

Figura 6-25. Tipos de MOP

Prf (DODAGPreference): es un campo de 3 bits que define el nivel de preferencia del

DODAG del mensaje con respecto a otros DODAGs existentes.

Version Number: este campo de 8 bits indica el DODAG Version Number establecido por el

nodo raíz.

Rank: es un campo de 16 bits que indica el rank del nodo que envía el mensaje DIO.

Destination Advertisement Trigger Sequence Number (DTSN): este campo de 8 bits se

utiliza para almacenar las rutas downward.

RPLInstanceID: campo de 8 bits que indica la instancia RPL del DODAG al que pertenece

el nodo raíz.

Reserved: campo de 8 bits que debe estar inicializado a 0 y no es usado.

Flags: es un campo reservado de 8 bits, el cual debe ser inicializado a 0 por el nodo que

envía el mensaje DIO e ignorado por el que lo recibe.

DODAGID: dirección IPv6 de 128 bits del nodo raíz que identifica al DODAG.


76

El proceso de creación de un DODAG comienza cuando el nodo raíz envía mensajes DIO a través de

difusión multicast. Cuando el mensaje DIO es recibido por un nodo, este debe determinar si acepta o

no dicho mensaje dependiendo de:

- Si el mensaje DIO contiene algún error, en este caso el nodo debe descartarlo de forma

silenciosa.

- Si el nodo que envió el mensaje DIO pertenece al conjunto de vecinos candidatos a

establecerse como “nodo padre” y no presenta ningún error, entonces procesará el DIO.

Uno de los campos más importantes de un mensaje DIO será el Rank, puesto que permitirá calcular

el coste de cada nodo, así como el coste del nodo padre que haya sido elegido por este. Los mensajes

DIO que se reciban de nodos con un rank superior serán descartados.

RPL contiene una serie de reglas que restringe la capacidad de un router de cambiar el valor de su

Rank. Esto se debe a que un router puede asumir un Rank mucho más pequeño que el que había

anunciado si descubre un nodo padre con un valor de Rank mucho más inferior que el suyo

(descartando el resto de nodos padres), mientras que también puede incrementar el valor de su Rank

en el caso de que no haya ningún nodo padre. Ante cualquier problema al intentar establecer un

DODAG, el nodo raíz puede realizar un “global recalculation” con el objetivo de incrementar la

secuencia de los mensajes DIO.

La configuración del DODAG que es transportado por el mensaje DIO se muestra en la Figura 6-26.

Figura 6-26. Configuración de un mensaje DODAG


77

6.4.2. Algoritmo Trickle

La transmisión de los mensajes DIO está controlado por temporizadores trickle que se repiten de

forma periódica. Estos temporizadores o trickle timers están implementados por temporizadores

dinámicos que controlan el envío de mensajes DIO para intentar reducir la redundancia de mensajes.

El intervalo de tiempo en el que se lanza el mensaje de control aumentará de forma exponencial

hasta alcanzar un valor constante, el cuál será el intervalo máximo I_max, esto quiere decir que

cuando el DODAG se estabiliza, hay un descenso del número de mensajes DIO.

En el caso de detectarse un problema por inconsistencia, el valor del intervalo se reestablecería al

mínimo, volviéndose a generar mensajes DIO con el fin de propagar la nueva información del DAG.

Los problemas por inconsistencia pueden deberse a que:

El nodo se ha unido a un nuevo DODAG

El nodo cambia de posición dentro del DODAG

El nodo recibe un mensaje DIO de un nodo padre distinto

Un nodo padre reenvía un paquete, observa que es inconsistente y que puede formar un

posible bucle.

Una métrica del mensaje DIO no es válida para una ruta con unas condiciones especifica.

El Rank del nodo padre ha cambiado.

El temporizador trickle tiene tres parámetros a configurar:

- I_min: valor del intervalo mínimo

- I_max: valor del intervalo máximo

- I_doubling: número de veces que el intervalo se duplica para una redundancia constante k. Si

se conoce el valor de I_min e I_max se puede obtener el tamaño de duplicación del intervalo

mínimo.


78

Tal como se describe en la RFC 6206, el funcionamiento del algoritmo trickle es el siguiente:

1. Al comenzar la ejecución del algoritmo, se establece un valor I comprendido entre el rango

[I_min, I_max], el cual será mayor o igual a I_min y menor o igual que I_max. El algoritmo

empezará en este intervalo.

2. Cuando un intervalo se inicia, se resetea a 0 el contador y establece un tiemplo aleatorio para

dicho intervalo, cuyo valor estará comprendido entre [I/2, I] y terminará en I.

3. Si se obtiene una transmisión consistente, el algoritmo incrementará su contador.

4. En un momento t del intervalo, se transmitirá si y sólo si el contador es menor que la

constante de redundancia k.

5. Cuando el intervalo I expire, se duplicará el tamaño del intervalo. Si el nuevo tamaño del

intervalo es mayor que el tiempo especificado en I_max, se actualizará el tamaño del

intervalo I por el valor de I_max.

6. Si se detectase una transmisión inconsistente y el intervalo I es menor que I_min, se reseteará

el temporizador del algoritmo. Una vez reseteado, se establecerá el valor de I_min al que

tenía I volviéndose al paso 2. Si el valor de I es igual al de I_min y la transmisión es

inconsistente, no se hará nada, aunque podría resetearse el temporizador si ocurriera un

evento externo.

6.4.3. Destination Advertisement Object (DAO)

Durante la formación del DODAG los nodos de la red tendrán que comunicar al nodo raíz que han

decidido unirse al DODAG que éste ha ofrecido a través del mensaje DIO.

Para ello se propagará el mensaje DAO siguiendo las rutas upward o hacia arriba hasta llegar al root

node. En el modo storing, el mensaje DAO será un mensaje unicast enviado desde un nodo hijo hasta

el nodo padre, mientras que en el modo non-storing el mensaje DAO será un mensaje unicast con

destino final el nodo raíz.

Cuando un nodo padre o el nodo raíz reciban un mensaje DAO, tendrán que responder con un

paquete unicast que contendrá un asentimiento DAO-ACK.

A continuación, se muestra el formato de un mensaje DAO en la Figura 6-27.

Figura 6-27. Formato mensaje DAO


79

El formato de un mensaje DAO está compuesto por los correspondientes campos:

La bandera K que indica si el receptor desea recibir un DAO-ACK.

La bandera D indica que se está usando el campo DODAGID.

Flags: es un campo de 6 bits reservado que debe estar iniciado a 0 cuando se va a enviar un

mensaje de este tipo.

Reserved: es un campo de 8 bits sin utilizar.

DODAGID (opcional): es un identificador único de 128 bits sin signo fijado por el nodo raíz de

DODAG.


80


81

n este capítulo se describen las herramientas y hardware que se han usado para llevar a cabo las

simulaciones y poder estudiar el potencial de ContikiOS, el funcionamiento de la mota elegida, los

protocolos de comunicación y encaminamiento, así como las herramientas de simulación empleadas

para la obtención de resultados.

7.1. Simulador Cooja

Para entender cómo se han creado los escenarios en el cual se han realizado las pruebas pertinentes

para este proyecto, debe describirse el funcionamiento del simulador Cooja que proporciona el

sistema operativo Contiki, puesto que su entendimiento es fundamental para las pruebas realizadas

en el apartado 7.7.

El simulador Cooja brinda la posibilidad de emular cada mota o nodo sensor a nivel hardware sin

tener que testearlas y ser capaces de observar de manera bastante precisa su comportamiento a la vez

que facilita la comunicación con otros nodos pertenecientes a la misma red. Para poder usar Cooja,

es necesario haber instalado Contiki. En este caso, no ha sido necesario debido a que ya viene

incorporado en el entorno virtual que proporciona los desarrolladores de Contiki [36].

Arrancar dicha herramienta es tan sencillo como ejecutar en un terminal Linux los siguientes

comandos:

» cd /contiki_version/tools/cooja

» ant run

E

La mejor manera de empezar algo es dejar de hablar

de ello y empezar a hacerlo.

- Walt Disney -

7 Simulación y evaluación de una red

WSN


82

La herramienta ant leerá el archivo de configuración build.xml y compilará todos los códigos

fuentes, creará empaquetados .jar, etc. Tras finalizar dicha carga, se ejecuta la interfaz gráfica de

Cooja como se muestra en la Figura 7-28.

Figura 7-28. Interfaz gráfica de Cooja

7.1.1. Crear una simulación

Con este apartado se procura dar una breve explicación de cómo crear una simulación y describir las

herramientas que proporciona Cooja para sacar el máximo provecho en un escenario de prueba.

Una vez se crea una nueva simulación (Figura 7-29), primero se configura el medio radio que va a

utilizarse, después la semilla de aleatoriedad y el delay de cada mota.

Figura 7-29. Creando un escenario de simulación


83

Tras haber elegido la opción Create, aparecerán una serie de subventanas donde cada una de ellas

representa un plugin de la herramienta descritos a continuación (véase Figura 7-30):

Simulation Control [1]: plugin que proporciona el control de inicio, detección o avance en

pequeños pasos de la simulación en tiempo de milisegundos. Permite también elegir el

tiempo total que durará la simulación o incluir retrasos en la simulación e intentar obtener

resultados más próximos a la realidad.

Network [2]: sirve para mostrar ciertas características de los nodos que van a simularse,

como son el tipo de nodo, la posición espacial que ocuparía, el rango de alcance radio e

interferencias, el número de paquetes transmitidos y recibidos, el estado de los LEDs y el

direccionamiento IP o Rime usado, etc.

Mote Output [3]: muestra los eventos producidos a lo largo de la simulación de cada uno de

los nodos desplegados. Estos mensajes pueden ser procedentes del propio código que se está

ejecutando o por los diversos componentes del sistema operativo involucrados en dicha

simulación.

Timeline [4]: representa una línea temporal para cada nodo en la simulación donde se

definen los eventos que se producen en la simulación. Algunos de estos eventos pueden ser:

o Estado de la radio del transceptor: será de color blanco si está apagada y gris si está

encendida.

o Eventos relacionados con la radio: como son transmisiones y recepciones de

paquetes. Si hay una marca de color azul indica que el paquete fue transmitido, si

fuera verde se traduce como recibido y si fuera rojo significa que hubo una

interferencia provocada por una colisión de dos paquetes o que el nodo se encuentra

fuera del rango de cobertura del otro extremo de la comunicación.

o Estado de los LEDs


84

Figura 7-30. Plugins implementados en Cooja

Por último, queda explicar cómo se incorporan los nodos a una simulación para poder formar una red

WSN. Para ello, cada nodo será cargado con un programa programado previamente en lenguaje C

que es ejecutado al iniciar la simulación, mostrados en las Figuras 7-31 y 7-32 respectivamente.

Figura 7-31. Carga de aplicaciones en los nodos (I)

[1]

[3]

[4]

[2]


85

Figura 7-32. Carga de aplicaciones en los nodos (II)

Cargado y compilado la aplicación en el nodo, éste aparecerá en la subventana Network y se podrá

cambiar la posición espacial del nodo si se desea. Concluida la configuración previa, se comenzará a

simular el escenario creado ejecutando el botón Start de la subventana Simulation Control.

7.2. Escenarios de simulación

Una vez descrita la herramienta Powertrace y mostrado el funcionamiento del simulador Cooja, en

este apartado se describen los escenarios de simulación que se han creado para poder estudiar el

funcionamiento de la red WSN y los protocolos 6LoWPAN y RPL que son la principal causa de la

realización de este proyecto.

Para cada simulación se mostrarán un conjunto de gráficas significativas de cada nodo en el que se

estudiará su comportamiento. En la representación de la estimación de energía de los nodos se ha

utilizado el modelo on-line de energía que puede consultarse en la referencia 38. Seguidamente, se ha

realizado una extrapolación de las fórmulas del modelo y se han presentado del siguiente modo.

𝐸𝑇

𝑉= 𝐼𝐶𝑃𝑈 ∗ 𝑡𝐶𝑃𝑈 + 𝐼𝐿𝑃𝑀 ∗ 𝑡𝐿𝑃𝑀 + 𝐼𝑇𝑋 ∗ 𝑡𝑇𝑋 + 𝐼𝑅𝑋 ∗ 𝑡𝑅𝑋 + ∑ 𝐼𝑐𝑖

∗ 𝑡𝑐𝑖𝑖 [3]

[3] Fórmula del modelo de energía

Con este modelo puede obtenerse la energía total consumida por el nodo. Obsérvese que si el voltaje

fuese constante puede quedarse en la igualdad de la izquierda. El sumatorio de la fórmula es opcional

debido a que depende si el nodo incorpora sensores o componentes tipo LEDS.


86

De la fórmula anterior, se puede abstraer la energía consumida por el nodo en cada estado.

𝐸𝐶𝑃𝑈 = 𝑡𝐶𝑃𝑈 ∗ 𝑃0,𝐶𝑃𝑈 [𝑚𝐽]

𝐸𝐿𝑃𝑀 = 𝑡𝐿𝑃𝑀 ∗ 𝑃0,𝐿𝑃𝑀 [𝑚𝐽]

𝐸𝑇𝑋 = 𝑡𝑇𝑋 ∗ 𝑃0,𝑇𝑋 [𝑚𝐽]

𝐸𝑅𝑋 = 𝑡𝑅𝑋 ∗ 𝑃0,𝑅𝑋 [𝑚𝐽]

[4]

[4] Ecuaciones de energía de cada estado

Los valores de potencia que se muestran en la formula anterior se definen como:

𝑃0,𝐶𝑃𝑈 = 𝐼𝐶𝑃𝑈 ∗ 𝑉 [𝑚𝑊]

𝑃0,𝐿𝑃𝑀 = 𝐼𝐿𝑃𝑀 ∗ 𝑉 [𝑚𝑊]

𝑃0,𝑇𝑋 = 𝐼𝑇𝑋 ∗ 𝑉 [𝑚𝑊]

𝑃0,𝑅𝑋 = 𝐼𝑅𝑋 ∗ 𝑉 [𝑚𝑊]

[5]

[5] Ecuaciones de potencia de cada estado

Como se comentó con anterioridad, el modelo de motas seleccionado para este estudio ha sido del

fabricante Zolertia Z1, por lo que los valores de corriente y tensión de la fuente que se han elegido

fueron extraídos de su ficha técnica, la cual se puede consultar en la referencia 4 y son los siguientes:

𝑉𝑓𝑢𝑒𝑛𝑡𝑒 = 3 𝑉

𝐼𝐶𝑃𝑈 = 4.2 𝑚𝐴

𝐼𝐿𝑃𝑀 = 0.0545 𝑚𝐴

𝐼𝑇𝑋 = 17.4 𝑚𝐴

𝐼𝑅𝑋 = 18.8 𝑚𝐴

[6]

[6] Valores de tensión y corriente elegidos


87

Todos los valores que se han definido anteriormente se van a considerar constantes en las pruebas

que se van a realizar.

En las posteriores secciones, va a analizarse los resultados obtenidos de cada una de las simulaciones

que se han realizado. Para ello, se presentarán las gráficas que se han considerado más importantes

resaltando aquellos aspectos más característicos, aunque el resultado obtenido de cada una de ellas

no se puede contrastar con los datos que se obtendrían de un escenario real debido a que no se

dispone de los dispositivos físicos necesarios.

Por último, la explicación del análisis y tratamiento de los datos, junto con el procedimiento de

extracción se reserva para el siguiente apartado de este trabajo.

7.3. Selección de motas

Para las pruebas que se llevaron a cabo en el simulador-emulador Cooja se han elegido motas del

proveedor Zolertia [23], en concreto las Z1 mote [24] que fueron las primeras en ser comercializadas

en todo el mundo y proporcionan una plataforma de desarrollo para la investigación en redes WSN

bastante asentada y consistente. El aspecto de esta mota es la que aparece en la Figura 7-33.

Figura 7-33. Aspecto de un Z1 Mote

Como características importantes a resaltar en estas motas son:

Microcontrolador MSP430F217 de bajo consumo.

CPU con una velocidad de 16MHz.

Memoria RAM de 8KB y memoria Flash de 92 KB.

Radio transceptor o transceiver CC2420 (véase referencia 3).

Soporte con el estándar IEEE 802.15.4

Operabilidad a 2.4Ghz con una tasa de 250Kbps.


88

Las motas Z1 del proveedor Zolertia soportan IPv6 que se implementa a través de 6LoWPAN

permitiendo a los dispositivos poder comunicarse entre ellos ya sea vía WiFi/Ethernet, conexión con

sistemas de tipo cloud o “en la nube”, y aplicaciones distribuidas a nivel global a través de un

direccionamiento global o único.

Para que esto sea posible, las motas se unen formando una red de sensores que se comunican

mediante el protocolo de encaminamiento RPL que permite encontrar la mejor ruta hacia el resto de

nodos vecinos, teniendo en cuenta siempre la limitación del alcance de la radio.

Estos dispositivos están proyectados para ejecutar sistemas operativos embebidos como el sistema

Contiki OS, de libre distribución y código abierto, que se usa en sistemas de red con restricciones de

memoria y están enfocados a los dispositivos de bajo consumo para el IoT. De ahí, que su pila de

protocolos de red soporte tanto IPv4 como IPv6 y otros protocolos estándar como son UDP, TCP,

HTTP y los nuevos estándares de bajo consumo como 6LoWPAN, RPL y CoAP.

7.4. Implementación de Contiki con la Z1 mote

En los dos escenarios elegidos para hacer las simulaciones se ha utilizado el hardware simulado de la

mota Z1 proporcionado por Contiki OS y la herramienta Cooja que contiene todas las librerías

necesarias para que estos escenarios se puedan desarrollar adecuadamente. Además, se han

implementado las aplicaciones que han sido desarrolladas para definir el comportamiento de cada

mota.

El sistema operativo Contiki usa como lenguaje para programar las aplicaciones en el lenguaje C y

funciona mediante Protothreads, que son procesos que permiten al microcontrolador ser capaz de

funcionar usando una mínima parte de su memoria. La idea consiste en varios hilos ejecutándose en

paralelo, los cuales se encuentran a la espera de activarse al generarse un evento que satisfaga las

condiciones establecidas, y una vez activados realizarán sus tareas para que cuando finalicen se

queden a la espera de nuevo hasta que se produzca otro evento que los active. Hay que tener en

cuenta que los eventos son los encargados de activar y enviar la información a los hilos para que

estos se ejecuten.

Para la implementación con Contiki, se ha elegido una máquina virtual extraída de la página oficial

Contiki [27] que usa una imagen de Ubuntu 2016 muy completa, puesto que incluye los ficheros del

kernel del sistema, los diferentes microcontroladores soportados y las adaptaciones de las diferentes

librerías según la plataforma hardware que se emplee desarrolladas por la comunidad de Contiki OS.

La principal herramienta de Contiki es el simulador de redes Cooja [28] hecho en Java que permite

desarrollar, ejecutar y validar el funcionamiento de aplicaciones en las distintas plataformas sin

necesidad de disponer el hardware físicamente, de ahí que se haya decidido implementar el hardware

virtual de las motas Z1.


89

La configuración de drivers que se carga en cada mota viene definida en un fichero de configuración

que se denomina project-conf.h y se ubica en el directorio donde se almacenan las aplicaciones en

extensión .c junto con el archivo Makefile, que es el encargado de compilar todos los ficheros junto

con la configuración de cada mota. La configuración de los drivers que se van a cargar en las motas

Z1 es la que se aprecia en la Figura 34 siguiente:

Figura 7-34. Configuración de los drivers en los Z1

mote

Cada módulo definido en el fichero de configuración hace posible el despliegue de la red de sensores

basadas en el estándar RPL [22] y 6LOWPAN [13]. Para ello, los matices a tener en cuenta son:

Capa Radio: se encarga de la transmisión y recepción de tramas a través del medio

inalámbrico por medio de los drivers de cada plataforma. Se ha elegido el driver

cc2420_radio_driver que opera en la banda de 2.4 GHz según el estándar IEEE 802.15.4 y

es el soportado por los Z1 mote.

Capa Framer: es la encargada de dar formato a los paquetes del estándar IEEE 802.15.4

mediante el framer_802154. En caso contrario podría usarse el framer_nullmac, aunque si se

desea implementar 6LoWPAN no sería posible esta opción.

Capa RDC: esta capa controla el transceptor radio permitiendo que se apague siempre que

sea posible para ahorrar energía e incrementar la vida útil de la batería. Aunque no todas las

radios son compatibles con este driver, se ha seleccionado el driver contikimac_driver porque


90

proporciona un gran ahorro y eficiencia de la radio sobre los dispositivos y permite pasar a

modo sleep los dispositivos.

Capa MAC: es implementado por el driver contikimac_driver y se encarga de procesar las

tramas de nivel de enlace recibidas por la radio de la mota.

Capa Network: se usa con sicslowpan_driver para poder utilizar la arquitectura uIP con los

protocolos RPL y 6LoWPAN que siguen las directrices fijadas por las RFCs 4944 [12] y

6282 [14].

Las redes WSN implementadas con Contiki OS pueden incorporar dos tipos de pilas de

comunicaciones con la que se comunicaran las motas. Por una parte, la pila Rime [29] es una pila de

comunicación lightweight diseñada para dispositivos radio de baja potencia, la cual se encuentra

estructurada en capas de protocolos con cabeceras de tamaño mínimo y de forma totalmente opuesta,

aunque bastante relevante para los objetivos de este proyecto. Contiki OS implementa como soporte

la pila de comunicación TCP/IP con el nombre de uIP [30] que está adaptado a uIP6 convirtiendo a

Contiki OS al único sistema operativo embebido con pila TCP/IP robusta con certificación IPv6

Ready Logo. Por estas razones se ha elegido la pila uIP porque permite establecer una comunicación

entre motas usando IPv6, 6LOWPAN y RPL.

Una vez elegida el tipo de pila de comunicación que va a usarse en los Z1 mote, se va a describir la

pila de protocolos que van a tener cada una de las motas dentro de la red WSN, teniendo en cuenta

que cada mota poseerá una función específica que será definida a nivel de aplicación. En el escenario

elegido para las simulaciones, habrá tres roles o funcionamientos diferentes que son descritos a

continuación:

Rol dispositivo móvil: debido a que no es posible cargar la configuración de un dispositivo

móvil en Cooja, se ha optado por usar una mota Z1 y definir una aplicación para que envíe

datos acerca del estado de la temperatura del dispositivo y conseguir que esté monitorizado

en todo momento para observar posibles comportamientos extraños.

Rol nodo RPL: son motas Z1 que se encuentran en el borde de la red conectando en todo

momento con los dispositivos móviles y capturando su estado mediante intercambio de

mensajes, de forma que almacenan temporalmente los datos de cada dispositivo para reenviar

al nodo sumidero de la red WSN utilizando el algoritmo de encaminamiento Triggle que

proporciona el protocolo RPL.

Rol sumidero RPL: es un nodo de la red WSN que se encarga de recibir la información que

envía cada nodo con la información de los dispositivos móviles, es decir, es una mota Z1 que

se comporta como un sumidero que almacena los datos para posteriormente analizarlos.


91

Para aclarar el comportamiento que tendrá cada mota Z1 según su rol se muestra la torre de

protocolos (véase Figura 7-35) que se define para cada caso.

Figura 7-35. Torre de protocolos del rol de cada mota Z1

Como se aprecia en la Figura 7-35, cada dispositivo móvil se comunicará con los nodos frontera de

la red WSN a través de IPv6, transmitiendo paquetes de información vía UDP como se ha

programado en la capa de aplicación.

Los nodos frontera de la red WSN deberán ser capaces de entender los mensajes que envían los

dispositivos móviles a través de IPv6 y luego usando la capa de adaptación de 6LoWPAN poder

enviar la información recogida al nodo sumidero de la red WSN usando el camino más eficiente

mediante el uso del protocolo de encaminamiento RPL.

El nodo sumidero como dialoga 6LoWPAN es capaz de recibir los paquetes entrantes que recibe de

los nodos fronteras.


92

7.5. Definición de aplicaciones en la mota Z1

El rol de cada mota viene definida a nivel de aplicación por el fichero .c que compila el simulador

Cooja al desplegar el escenario de la simulación. Para poder comprender el comportamiento de cada

mota se procede a describir el funcionamiento de cada aplicación. Todas las funciones que aparecen

se pueden consultar en la documentación de Contiki [31] y [32].

7.5.1. Aplicación dispositivo móvil

Estas motas están configuradas para comportarse como dispositivos móviles conectadas a una

estación de la red WSN transmitiendo en todo momento su estado actual de temperatura. Esto es

posible gracias a la aplicación envia.c que es cargada en las motas y establece toda la configuración

necesaria para que funcionen de esta forma. A continuación, se muestra un diagrama de su

funcionamiento en la Figura 7-36:

Figura 7-36. Diagrama de flujo de la aplicación envia.c

Sí

Sí

No No


93

La explicación del diagrama se divide en bloques:

[1] Cada aplicación, tal y como se describió anteriormente está programada en C, por lo que

se comienza definiendo un conjunto de librerías y macros que serán ejecutadas en un

proceso. Este proceso se define como envia_process que contiene una pequeña descripción

acerca de su funcionamiento. En este caso se trata del envío de mensajes UDP a un destino

conocido.

Para indicar al planificador cuál es el proceso a ejecutar, se usa la función

AUTOSTART_PROCESSES que necesita como argumento el nombre del proceso que

anteriormente se ha definido para que lo inicie.

[2] Todas las funciones que sean necesarias llamar en el hilo del proceso principal deben ser

definidas antes para evitar fallos de compilación y puedan ser usadas en el hilo principal. Una

vez que el planificador carga el proceso envia_process se ejecuta lo siguiente:

Se declaran las variables que se van a utilizar en el código. En esta cuestión se trata

del temporizador et_start, la dirección IPv6 ipaddr_node que se va a asignar en la

mota y la dirección IPv6 ipaddr_server del nodo de la red WSN que recibirá los

mensajes.

Se llama a PROCESS_BEGIN (), que es una función interna del PROTOTHREAD

para iniciar un subproceso que inicia la configuración interna de la mota, es decir, el

hardware y sus sensores. Una vez terminado se enciende el transceptor radio con la

función NETSTACK_MAC.off (1) para que pueda comunicarse en el medio físico.

Con esta función se activa el driver CC2420 que se había definido para la radio en el

fichero de configuración.

Posteriormente, se define la comunicación IPv6 con las variables ipaddr_node e

ipaddr_server. Para definir la dirección unicast del dispositivo se usará la

configuración EUI-64, es decir, se usa su propia dirección MAC para construir la IP,

mientras que para la IP del nodo WSN se ha elegido una representativa como se

muestra en la Figura 7-37.

Figura 7-37. Definición de las direcciones IPv6

//Configuración direcciones IPv6 necesarias en el dispositivo

móvil

uip_ip6addr(&ipaddr, UIP_DS6_DEFAULT_PREFIX,0,0,0,0,0,0,0);

uip_ds6_set_addr_iid(&ipaddr,&uip_allddr);

uip_ds6_addr_add(&ipaddr,0,ADDR_AUTOCONF);

//Se incluye dirección IPv6 del nodo servidor

uip_ip6addr(&ipaddr_known, 0xfe80,0,0,0,0,0x89,0xABCD);


94

Una vez terminada la configuración de las IPs, se crea la conexión UDP entre el

dispositivo móvil y el nodo de la red WSN donde deben definirse los puertos entre

cliente (5000) y servidor (3000). Para ello, se necesita un conector que ha sido

definido como variable global anteriormente y denominado unicast_conn. Este

servirá para almacenar el resultado de la función udp_new que necesita la dirección

IPv6 del nodo servidor definida anteriormente y su puerto para crear la conexión.

Seguidamente, se llama a la función udp_bind () a la que se le define como

argumentos el conector y el puerto del dispositivo móvil, para obtener como resultado

final un conector que se usará en la función unicast_send.

Las Figuras 7-38 y 7-39 muestran el uso de las funciones nombradas anteriormente y

el resultado del conector ya creado con toda la información.

Figura 7-38. Creación del conector

unicast_conn

Figura 7-39. Datos del conector

IP Origen: fe80::c30c::x

Puerto Origen: 5000

IP Destino: fe80::89:ABCD

Puerto Destino: 3000

//Creación del conector

unicast_conn = udp_new(&ipaddr_known, UIP_HTONS(3000),NULL);

udp_bind(unicast_conn, UIP_HTONS(5000));


95

A continuación, se configura el temporizador et_start, encargado de crear el evento

para enviar mensajes con la información de la temperatura del dispositivo. Se define

mediante la función etimer_set (&et_start, SEND_TIME) que prepara al timer que en

función de los segundos que se configure llame a la función unicast_send () y envíe

dicha información.

Por último, se crea un bucle en el que se define la función PROCESS_YIELD () que

captura el evento del timer y comprueba si el timer ha expirado o si el dispositivo no

ha enviado más de 100 paquetes. En el caso de que se cumplan estas dos condiciones

se resetea el timer para la siguiente iteración del bucle y se llama a la función

unicast_send ().

[3] En este último bloque se explica la función unicast_send () encargada de que el

dispositivo móvil envíe la información al nodo de la red WSN, definida en la Figura 7-40.

Figura 7-40. Diagrama función unicast_send () de envia.c

Como se aprecia en la figura del diagrama, para preparar el paquete que se desea transmitir se

usa las funciones memset y memcpy. La primera función permite crear el paquete en el que se

almacenarán los datos y la segunda copiará esos datos que se indican como argumento en la

función uip_udp_packet_send, necesitando el conector unicast_conn que se había definido en

el proceso principal para la comunicación entre dispositivo y nodo WSN y el tamaño del

paquete. Una vez es enviado dicho paquete al nodo de la red WSN vía UDP se incrementa el

contador de paquetes enviados devolviéndose el control al proceso envia_process.


96

7.5.2. Aplicación nodo WSN

Cada nodo de la red WSN usará esta aplicación recibe.c para comunicarse con los dispositivos

móviles y con el nodo raíz o sumidero a través del protocolo RPL para enviar los mensajes que han

recolectado de los dispositivos ajenos a la red WSN.

Para comprender de forma visual cómo funciona esta aplicación se elabora la Figura 7-41.

Figura 7-41. Diagrama de flujo de la aplicación recibe.c

Sí No

Sí

No

No

Sí

Sí


97

Como se realizó con la aplicación envia.c, se divide el diagrama por bloques para facilitar su mejor

entendimiento.

[1] Al igual que con la aplicación de envia.c, primeramente, se carga el conjunto de librerías

y macros que serán ejecutadas en el proceso, llamadas ahora recibe_process, y que se va a

encargar de recibir mensajes UDP de orígenes conocidos. Con la función

AUTOSTART_PROCESSES se indicará al planificador que el proceso que tiene que ejecutar

es recibe_process.

[2] Para esta aplicación las variables usadas en el programa serán de carácter global debido a

su utilización en el proceso principal y en las funciones que se definieron. Una vez que el

planificador carga el proceso recibe_process se ejecuta lo siguiente:

Se designa a la herramienta Powertrace, encargada de tomar muestras de tiempo de

los valores de CPU en modo activo, LPM (Low Power Mode), TX y RX del nodo.

Para que la herramienta se ejecute hay que llamar a la función powertrace_start e

indicar cuál es el periodo de muestreo que va a utilizarse para obtener las medidas.

Debido a que esta herramienta es usada también en el nodo sumidero de la red WSN,

se explicará con más detalle en el siguiente apartado.

Después de esta función, se ejecuta el subproceso PROCESS_BEGIN () que inicia la

configuración interna de la mota. Una vez terminado, se enciende el transceptor radio

con la función NETSTACK_MAC.off (1) para que pueda comunicarse con los

dispositivos móviles y el nodo sumidero de la red WSN.

Posteriormente, se define el tamaño de la variable data_buffer que es el buffer de

aplicación donde se guardarán los paquetes que vaya recibiendo el nodo de los

distintos dispositivos móviles que tengan conexión con él y se resetean los contadores

de recepción y reenvío.

Similar a envia.c hay que definir las direcciones IPv6 (Figura 7-42) que se usarán en

el nodo para comunicarse con el resto. Estas van a ser addr_rpl, addr y

server_rpl_addr donde todas ellas serán direcciones unicast.

Figura 7-42. Definición de direcciones IPv6 en recibe.c

//Configuración direcciones IPv6 necesarias en el nodo de la red

WSN

uip_ip6addr(&addr_rpl, UIP_DS6_DEFAULT_PREFIX,0,0,0,0,0,0,0);

uip_ds6_set_addr_iid(&addr_rpl,&uip_allddr);

uip_ds6_addr_add(&addr_rpl,0,ADDR_AUTOCONF);

//Dirección IPv6 del nodo para comunicarse con los dispositivos

móviles

uip_ip6addr(&addr, 0xfe80,0,0,0,0,0x89,0xABCD);

uip_ds6_addr_add(&addr,0,ADDR_AUTOCONF);

uip_ip6addr(&server_rpl_addr,

UIP_DS6_DEFAULT_PREFIX,0,0,0,0x0250,0xc2ff,0xfea8,0xcd1a);


98

Una vez terminada la configuración de las IPs, se tienen que crear las conexiones

UDP entre el nodo de la red y el dispositivo móvil, y el nodo con el nodo sumidero

dentro de la red WSN. Para ello, van a usarse los conectores recibe_conn y

client_rpl_conn juntos con las funciones udp_new y udp_bind obteniéndose las

imágenes mostradas en las Figuras 7-43, 7-44 y 7-45:

Figura 7-43. Creación de los conectores recibe_conn y client_rpl_conn

recibe_conn

Figura 7-44. Datos del conector recibe_conn

client_rpl_conn

Figura 7-45. Datos del conector client_rpl_conn

IP Origen: : fe80::89:ABCD

Puerto Origen: 3000

IP Destino: fe80::c30c::x

Puerto Destino: 0

IP Origen: fe80::c30c::x

Puerto Origen: 27017

IP Destino: fe80::250:c2ff:fea8:cd1a


//Creación del conector con el dispositivo móvil

recibe_conn = udp_new(NULL, UIP_HTONS(0),NULL);

udp_bind(recibe_conn, UIP_HTONS(3000));

//Creación del conector con el nodo sumidero de la red WSN

client_rpl_conn = udp_new(&server_rpl_addr,

UIP_HTONS(5432),NULL);

udp_bind(client_rpl_conn, UIP_HTONS(27017));


99

[3] En la creación del bucle se define de nuevo la función PROCESS_YIELD () que tiene

como objetivo capturar aquellos eventos de tipo tcpip_event que se refieren cuando un

dispositivo móvil envía un mensaje y la radio del nodo de la red WSN lo captura, por lo que

se comprueba que se han eventos de este tipo.

Si ocurre este evento hay que comprobar que el buffer de nivel de aplicación no esté lleno

porque si no se perdería el paquete. Si sucede, se llama a la función tcpip_handler que

almacenará el paquete en el buffer de aplicación. En el caso de que el buffer estuviera lleno,

se pierde el paquete y se ejecuta mediante un bucle la función send_packet a través de un

callback hasta que el buffer quede vaciado.

La descripción de estas funciones se hará con la ayuda de las Figuras 7-46 y 7-47.

Figura 7-46. Diagrama función tcpip_handler() de recibe.c

Cuando se llama a la función tcpip_handler () de la aplicación recibe.c lo primero que se

comprueba es si hay un nuevo paquete entrante. Si esto ocurre, se tiene que contabilizar

como un nuevo paquete recibido y seguidamente, queda almacenado en el buffer de

aplicación donde se incrementará en una posición más su tamaño y devolviendo el control al

hilo del proceso principal. Si no hubiera un nuevo paquete entrante se devuelve el control al

proceso principal sin realizar ninguna acción, por lo que el paquete queda descartado.

Sí

No


100

Figura 7-47. Diagrama función send_packet() de recibe.c

La Figura 7-42 describe la llamada a la función send_packet y se debe a que se han dado las

condiciones de que el buffer de aplicación está lleno y el nodo tiene que enviar la

información que ha ido almacenando al nodo sumidero de la red WSN.

Cada paquete del buffer será copiado a un paquete de salida que será enviado cada 5

segundos mediante la función uip_udp_packet_sendto que necesitará los siguientes

argumentos:

Conector client_rpl_conn definido anteriormente

El paquete que es almacenado en la variable buf

La dirección IPv6 del servidor que se encuentra en la variable server_rpl_addr

El puerto al que está escuchando el nodo sumidero de la red WSN

Una vez haya sido enviado el paquete se tiene que contabilizar como un nuevo paquete

enviado y se devuelve el control al proceso principal.


101

7.5.3. Aplicación sumidero RPL

Por último, se describe la aplicación sink.c que se instala en el nodo sumidero de la red WSN y se

encarga de tener monitorizado todos los estados de los dispositivos móviles que se encuentran

conectados con los nodos “frontera” de la red WSN que se ha desplegado. Este nodo sumidero tiene

que implementar 6LoWPAN y RPL para poder dialogar con el resto de nodos conectados a la red y

para ello, tiene que informar a todos los nodos que va a comportarse como el nodo raíz o root de la

red WSN.

Para poder entender dicha aplicación se muestra el siguiente diagrama en la Figura 7-48.

Sí

Sí

No

No

Figura 7-48. Diagrama de flujo de la aplicación sink.c


102

La mejor forma de explicar este diagrama es subdividirlo por partes al igual que se ha realizado con

las aplicaciones envia.c y recibe.c

[1] Como ya se ha descrito en las aplicaciones anteriores es necesario cargar todas las

librerías y macros que van a ejecutarse. El nombre que se ha definido para este proceso es

rpl_udp_server porque es el nodo que recibirá todas las transmisiones UDP que se envíen

dentro de la red WSN y porque es el que se asigna como nodo raíz del árbol definido por la

topología RPL. El nombre de este proceso al llamarse la función AUTOSTART_PROCESSES

es tratado por el planificador, que será el que lance la ejecución del proceso pasado como

argumento.

[2] En la ejecución del proceso rpl_udp_server al igual que ocurrió con recibe_process, tiene

que ejecutarse la función powertrace_start con un periodo de muestreo de 1 us para capturar

el comportamiento del nodo ante los eventos que se ve expuesto durante la ejecución del

proceso.

De entra todas las funciones que realizará el nodo sumidero, una de ellas es recibir los

mensajes que envían los nodos de la red WSN. Es por eso, que tiene que encender el

transceptor radio para estar escuchando en todo el momento el canal a la espera de datos

entrantes. Por lo tanto, este nodo será de tipo crítico porque no tendrá apagada su radio en

ningún momento.

Para configurar la dirección IPv6 de este nodo, se define la variable rpl_addr que se enviará

mediante difusión a los demás nodos para informar de que se establece como nodo root. Esto

es posible gracias a la función rpl_set_root, que se le entrega como argumento la dirección

que se ha definido antes y una macro para indicar la función objetivo que se va a seguir en la

formación de la topología RPL (Figura 7-49).

Figura 7-49. Asignación de IPv6 al nodo sumidero

//Configuración dirección IPv6 necesaria en el nodo sumidero de la

red WSN

uip_ip6addr(&rpl_addr,

UIP_DS6_DEFAULT_PREFIX0,0,0,0x0250,0xc2ff,0xfea8,0xcd1a);

uip_ds6_addr_add(&rpl_addr,0,ADDR_MANUAL);


103

Tras esto, se crea el conector cuya información se almacenará en la variable rpl_server_conn

(Figura 7-50 y 7-51).

Figura 7-50. Creación del conector rpl_server_conn

rpl_server_conn

Figura 7-51. Datos del conector rpl_server_conn

[3] Al igual que ocurría en la aplicación de recibe.c se debe de crear un bucle y definir la

función PROCESS_YIELD () para poder establecer la captura de los eventos de tipo

tcpip_event, que posteriormente son tratados en la llamada a la función tcpip_handler. A

diferencia del resto de aplicaciones, el nodo sumidero tiene que incorporar la funcionalidad

de reparar la topología RPL creada entre sus nodos en el caso de que hubiera un cambio de

rutas. Se realiza con la función rpl_repair_root.

En la función tcpip_handler de la aplicación sink.c se ejecutan los siguientes pasos:

Comprobación de la existencia de un nuevo paquete de datos entrante mediante la

función uip_newdata ()

En el caso de que así se monitorizará desde un output de la herramienta Cooja, el

nuevo paquete recibido indicará el valor de temperatura medida en el dispositivo

móvil.

Por último, contabilizar ese paquete como recibido correctamente por el nodo.

IP Origen: fe80::250:c2ff:fea8:cd1a

Puerto Origen: 5432

IP Destino: fe80::c30c::x


//Creación del conector con los nodos RPL

rpl_server_conn = udp_new(NULL, UIP_HTONS(27017),NULL);

udp_bind(rpl_server_conn, UIP_HTONS(5432));


104

La explicación anterior queda plasmada en el siguiente diagrama de la Figura 7-52.

Figura 7-52. Diagrama del funcionamiento tcpip_handler

7.6. Herramienta Powertrace

En redes WSN de bajo consumo, las comunicaciones y el consumo de energía están muy

relacionadas ya que el dispositivo de comunicación es el componente que más energía consume,

aunque no se esté transmitiendo.

La causa principal se debe a la radio de cada nodo, la cual consume energía cada vez que se realiza

una transmisión o una recepción, a menos que se encuentre apagada, pero entonces surge el

inconveniente de que en entornos críticos los dispositivos tienen que estar encendidos en todo

momento.

La herramienta Powertrace [33] fue creada con la finalidad de medir aspectos de potencia y energía

en las redes WSN de baja potencia (low-power). Ésta es la que se ha elegido implementar para las

pruebas realizadas en este proyecto debido a su alto porcentaje de acierto, a pesar de que no se

disponga del hardware real y sean solo simulaciones.

Powertrace utiliza el seguimiento del estado de potencia para estimar el consumo de cada nodo a

nivel local. Para ello, registrará el consumo de energía de cada actividad del nodo y lo almacena en

“capsulas de energía” que contienen medidas aproximadas de la energía empleada por cada

componente del nodo, como puede ser la recepción o transmisión de paquetes. Además, contempla

las cápsulas de energía procedentes de las actividades a nivel de red tales como aplicaciones

individuales o protocolos individuales, tráfico de enrutamiento, reenvío o control.


105

Un ejemplo de su esquema de rastreo de energía es el mostrado en la Figura 7-53.

Figura 7-53. Rastreo de estados de potencia de la herramienta Powertrace

7.6.1. Funcionamiento

El objetivo es obtener los valores de energía y potencia de las aplicaciones que hayan desplegadas en

una red WSN, aunque existe una dificultad en su uso debido a varios motivos, como el diseño

hardware del nodo que no permite obtener medidas fiables, la no implementación a nivel de red, etc.

De ahí, que surgiera dicha herramienta que se ha incluido en el sistema operativo ContikiOS y es la

que se ha implementado en cada nodo para medir sus estados de CPU en modo activo, LPM (Low

Power Mode), TX (Transmission) y RX (Reception).

El propósito del Duty Cycling de la radio es mantener ésta apagada todo el tiempo posible, pero

conservando la capacidad de comunicación. Si el transceptor radio no estuviera encendido, el nodo

no sería capaz de recibir transmisiones vecinas. Es por ello, que debe desconectarse la radio tanto

como sea posible y despertarse periódicamente para recibir los paquetes de los nodos vecinos.

Cuando un nodo decide transmitir, a priori no conoce si el nodo receptor está despierto en ese

momento, por lo que envía un paquete de tipo preámbulo indicando al receptor que se quiere

establecer una transmisión. De forma paralela, el nodo receptor puede transmitir paquetes indicando

que su radio se encuentra activada para escuchar transmisiones entrantes.

La comunicación de los nodos a nivel de enlace se realiza mediante el protocolo de ContikiMAC

(véase Figura 7-54 y para más información referencia 37) que tiene configurado un mecanismo

periódico para despertar la radio del nodo basado en intervalos de tiempo constantes y uniformes. Su

configuración se debe a dos canales de radio consecutivos, los cuales tienen que estar sincronizados

para poder capturar las transmisiones que hagan los nodos vecinos. De manera, que si un nodo

vecino decide realizar una transmisión deberá transmitir cada paquete de forma periódica hasta que

este sea capturado por el transceptor radio del nodo receptor. Entonces, este nodo tiene que mantener

su radio encendida para que sea posible el intercambio de datos.


106

Una vez se haya completado la transmisión, el nodo receptor tiene que responder con un paquete del

tipo ACK indicando si se recibió el paquete correctamente, de forma que el nodo remitente al recibir

dicha notificación para su envío periódico de paquetes, registra el intervalo en el que recibió dicho

ACK para poder sincronizarse con el receptor la próxima vez que tenga que enviar información.

Para entender mejor el funcionamiento, se muestra Figura 7-54, que ha sido extraída de la referencia

15.

Figura 7-54. Proceso de envío de paquetes usando ContikiMAC

Powertrace se encarga de rastrear los estados de energía del sistema midiendo el tiempo durante el

cual los componentes se encuentran en dicho estado.

Los controladores de dispositivos o device drivers son los encargados de registrar las marcas o

intervalos de tiempo en el que un componente cambia a un estado nuevo. Cuando esto ocurre, se ha

de calcular la diferencia de tiempo y sumarlo a un contador de tiempo que será la salida que devuelva

la herramienta en función del periodo de muestreo asignado en su ejecución.

El motivo de haberse utilizado esta herramienta para medir el estado de cada nodo de la red WSN se

debe a que no hay que implementar ningún hardware adicional, solamente añadir parte del código

del software en el funcionamiento de cada nodo. Sin embargo, presenta ventajas e inconvenientes

con respecto a las mediciones de energía que se obtendrían usando un hardware adicional como se

aprecia en la referencia [34], pero que en resumen se fundamentan en no tener en cuenta factores

ambientales que alteran el consumo de energía del sistema, como son la temperatura y la humedad

que afectarían al hardware de cada nodo.

A continuación, se explica el funcionamiento de la herramienta Powertrace representado en la Figura

7-55, en la que se ha definido una línea temporal donde el sistema se despierta de forma periódica e

intenta transmitir un paquete, pero que no es posible porque detecta que la radio de un vecino está

realizando una transmisión. Por lo tanto, tiene que volverse a retransmitir el mismo paquete un

intervalo de tiempo más tarde hasta que lo consiga y finalmente vuelva a despertarse de nuevo.


107

Figura 7-55. Obtención de medidas de la herramienta Powertrace

En la Figura 7-55, se observa que la transmisión de paquetes se inicia por primera vez después de

aproximadamente 40 ms. El transceptor radio muestrea el canal, pero encuentra que hay una

transmisión de un vecino y, en consecuencia, establece un temporizador de retransmisión que

expirará 60 ms. Por lo tanto, la cápsula de energía se cierra y se abre de nuevo para la siguiente

transmisión. La radio se pone de nuevo en modo de escucha para comprobar las transmisiones de los

vecinos, pero esta vez el paquete puede ser enviado. La capa de ciclo de servicio de la radio

transmitirá ahora el paquete de forma repetitiva hasta obtener un paquete ACK o acuse de recibo

procedente de la capa de enlace del receptor.

Entre las transmisiones se tiene que ajustar la radio al modo de escucha para poder recibir dicho

ACK. Cuando se recibe este ACK, la radio se tiene que apagar y por consiguiente la cápsula de

energía se cierra.

Una vez terminado, se tiene que devolver el control a la capa de red que mantendrá a la CPU en

modo activo cierto tiempo más para realizar sus operaciones a este nivel, pero hay que tener en

cuenta que esta energía no se atribuye a la capsula de energía que midió la estimación de energía del

componente puesto que no forma parte de la transmisión de la radio.

Como se ha visto en la gráfica de la Figura 7-55, una cápsula de transmisión puede contener

información de la energía que necesitó la radio para transmitir, así como el estado de escucha de la

radio. Por lo que el término capsula de energía en Powertrace se usa para indicar la cantidad de

energía que necesitó un componente para llevar a cabo una actividad, ya fuera transmisión o

recepción de un paquete, o lectura de un bloque de datos de un fichero almacenado en una memoria

flash interna. Cada cápsula de energía tendrá asociada un conjunto de estados de potencia que han

sido registradas cuando la actividad comienza y acaba. Un conjunto de cápsulas de energía se puede

combinar para formar un agregado de cápsulas de energía que contiene la suma de la energía de

todas sus cápsulas. Esto lo utiliza la herramienta Powertrace para obtener el consumo de energía

empleada en la comunicación de protocolos de red que pueden identificarse por su número de

protocolo según el estándar.


108

Para concluir, la herramienta Powertrace muestreará los estados de energía del sistema de cada una

de las actividades que ha realizado en ese instante de tiempo, repitiéndolo de forma periódica, por lo

que para cada actividad deberá de tener un registro que almacene la estimación energética de la

capsula de energía en ese instante. Además, con la información suministrada por Powertrace se

puede tomar decisiones en función de los costes de energía, desde monitorizar a tiempo real cómo

evoluciona, hasta implementar dicha información en la tabla de enrutamiento de los protocolos de

red y así basar sus decisiones de encaminamiento en función de la energía de transmisión promedio

para conseguir que estos sean más eficientes.

7.6.2. Código implementado por la herramienta

A continuación, se presenta el código de la herramienta Powertrace utilizado para la obtención de las

medidas conseguidas en el apartado de simulaciones y que se puede consultar en el repositorio git de

Contiki [35].

En la Figura 7-56, se representa el proceso de ejecución de la aplicación Powertrace que necesita

como parámetro de entrada el periodo con el que realizar el muestreo de medición. El periodo se

obtiene de la variable data, un parámetro de entrada que se indica en cada aplicación de los nodos

anteriores mediante la función powertrace_start (periodo), como se observa en la próxima Figura 7-

57. Una vez se comprueba dicho parámetro, se inicializa un temporizador que se repetirá de forma

periódica y se hace una llamada a la función powertrace_print.

Figura 7-56. Proceso powertrace


109

En la siguiente Figura 7-57 se define la función powertrace_start que es donde se indica el periodo

de muestreo (en µs) y se ejecuta una llamada al proceso principal importando como argumento de

entrada el valor del periodo.

Figura 7-57. Funciones para ejecutar y parar la aplicación Powertrace


110

En la función powertrace_print (Figura 7-58) se realiza el rastreo y obtención de las capsulas de

energía, y se representa la información obtenida de cada estado dependiendo de la actividad ejercida

de cada componente.

Figura 7-58. Rastreo y obtención de la estimación energética de las capsulas de energía


111

Destacar que se ha omitido la definición de variables y sólo se ha representado la parte más

importante del código.

Lo primero a efectuar, es una llamada a la función energest_flush para activar los tiempos registrados

por las capsulas de energía. Seguidamente, mediante la función energest_type_time se obtienen los

tiempos de cada estado del nodo que son los siguientes:

ENERGEST_TYPE_CPU: estimación temporal de energía de CPU en modo activo.

ENERGEST_TYPE_LPM: estimación temporal de energía de LPM (Low Power Mode).

ENERGEST_TYPE_TRANSMIT: estimación temporal de energía cuando el nodo transmite.

ENERGEST_TYPE_LISTEN: estimación temporal de energía cuando el nodo está

escuchando.

compower_idle_activity.transmit/listen: son valores que al tener un hardware simulado no

pueden tenerse en cuenta.

Con esta información es posible obtener valores de energía acumulados y también instantáneos, de

ahí, que se haga la diferencia entre all_cpu-last_cpu para comprobar si se sigue realizando la misma

actividad (por ejemplo, cuando el nodo transmite) o si se ha terminado dicha actividad (el nodo

termina de transmitir). Después, con los valores obtenidos y almacenados en las variables cpu, lpm,

transmit, listen, all_cpu, all_lpm, all_transmit y all_listen se calcula el porcentaje radio acumulado e

instantáneo conocido como Duty Cycle.

La variable time que se utiliza para la obtención de la radio (%) es la suma de las variables cpu + lpm

debido al comportamiento del nodo como se recalcó anteriormente, que consiste en estar ejecutando

un conjunto de instrucciones de cómo sería transmitir, descubrir rutas de posibles vecinos, atender

mensajes de difusión, etc. Pero cuando no ejecuta ninguna actividad, el nodo no se apaga por

completo, sino que entra en modo ahorro de energía o modo LPM, por lo que el tiempo total es el

que se computa cuando la mota se encuentra en modo activo de CPU y en modo LPM.


112

La Figura 7-59 es la forma con la que la aplicación Powertrace devuelve las medidas obtenidas y

sirve para poder representarlas gráficamente y estudiar el comportamiento de cada estado.

Figura 7-59. Representación de valores de energía calculados para cada estado

Esta información se imprime como salida estándar en el plugin Mote Output del simulador Cooja

que se describe posteriormente. El orden de impresión de estos valores para su posterior

manipulación es el siguiente:

Variable char str: indica que se está imprimiendo una cadena de la aplicación powertrace

para diferenciarlo del resto de información que aparezca en el Mote Output.

clock_time: es el tiempo de reloj interno de la mota.

linkaddr_node: identifica la dirección IP del nodo que se ha extraído las medidas de

estimación energética.

seqno: es un número de secuencia que contabiliza el número de cadenas que se ha

imprimido. Es útil si se tiene que buscar una línea en concreto.

all_cpu / all_lpm / all_transmit / all_listen: representan los valores acumulados de cada

estado en términos de tiempo (en ms).

all_idle_transmit / all_idle_listen: estos valores en las pruebas realizadas no se han tenido en

cuenta al no disponer de hardware real pero aun así se muestran.

cpu / lpm / transmit / listen: son los valores instantáneos de cada intervalo de tiempo medido.

Servirán para averiguar si una actividad terminó y empezó otra, y cómo afectó a cada estado

de la mota.


113

all_radio_total / all_radio_transmit / all_radio_listen: valores acumulados de la radio total,

transmitida y recibida.

radio_total / radio_transmit / radio_listen: valores instantáneos de la radio total, transmitida

y recibida.

En el caso de que se hubiera implementado en las motas una configuración diferente a IPv6, es decir,

no se haya usado la arquitectura µIP, la aplicación powertrace lo comprueba previamente como se

indica en la Figura 7-60.

Figura 7-60. Comprobación de pila de protocolos


114

De verificarse que se esté implementando IPv6 en los nodos de la red WSN, la herramienta

powertrace imprime lo comentado anteriormente en la Figura 7-60 y, además, información adicional

sobre los protocolos que están utilizando en la mota, canal radio usado, peticiones entrante y salientes

de paquetes, etc (Figura 7-61).

Figura 7-61. Representación de información extra de cada nodo


115

7.7. Resultados de las simulaciones

En este apartado se presentan los dos escenarios de simulación que se han montado para el estudio

del protocolo RPL y 6LoWPAN usando las herramientas de Contiki. Para cada escenario se

detallarán las gráficas obtenidas de cada nodo y sus comportamientos.

7.7.1. Simulacion del escenario 1

En la creación del escenario de la simulación 1 se han desplegado los siguientes nodos que se

visualizan en el plugin Network, como se observa en la Figura 7-62.

Figura 7-62. Escenario de la simulación 1

Cada nodo viene resaltado por un color e identificador diferente:

Nodo 5: representa al nodo sumidero de la red WSN en el que se ha cargado la aplicación

sink.c

Nodo 4: es el nodo frontera de la red WSN que se comunica con el nodo sumidero y los

dispositivos móviles. En este nodo se ha cargado la aplicación recibe.c

Nodos 1, 2 y 3: son los dispositivos móviles que se encuentran fuera de la red WSN, en

ellos se ha cargado la aplicación envia.c y tendrán como función informar al nodo 4 sobre

las variaciones de temperatura producidas.


116

En este primer escenario se han modificado los tiempos de transmisión de los dispositivos móviles y

de los nodos frontera de forma, que cada dispositivo móvil transmitirá cada 20s teniendo en cuenta la

aleatoriedad de si transmite o no y los nodos fronteras transmitirán los paquetes cuando su buffer de

aplicación se encuentre colapsado cada 2 s.

El tiempo de simulación para poder estudiar el comportamiento de los nodos en este primer

escenario ha sido de aproximadamente 2 ∗ 106 ms. Una vez terminada la simulación (Figura 7-63),

se ha generado un fichero en texto plano con el nombre simulacion1.txt donde se almacena toda la

información proporcionada en el plugin Output de Cooja para poder analizar los datos obtenidos y

representarlos gráficamente.

Figura 7-63. Ejecución del escenario de la simulación 1

Las gráficas que se mostrarán posteriormente pertenecen a los datos obtenidos en el nodo sumidero

que se identifica con el id 5 y en el nodo frontera de la red WSN que tiene el id 4. Para cada uno de

estos nodos se representará su estado para cada actividad (medida en ms) mientras se ha llevado a

cabo la simulación, así como el comportamiento de la radio (expresado en %).

A continuación, se enseñará una estimación de la evolución energética de estos nodos teniendo en

cuenta los valores de su datasheet.


117

7.7.1.1. Gráficas de los estados del nodo frontera (id 4)

En la Figura 7-64 es posible apreciar el tiempo de ejecución de CPU en modo activo y el tiempo

LPM (Low Power Mode) que es el tiempo en que el nodo tiene su CPU en modo ahorro. Estos

valores están medidos ambos en milisegundos (del orden de 106 ) y se han recolectado del nodo 4.

Se observa que los valores de CPU y LPM conforme aumenta la simulación crecen rápidamente,

pero hay que resaltar que, en función de los valores obtenidos en estas gráficas, el nodo se encuentra

más tiempo en modo ahorro o power saving que en modo activo, donde los valores extraídos al final

de la simulación son de 2 ∗ 106ms con respecto al tiempo de CPU (gráfica izquierda) frente al 70 ∗106ms del tiempo de LPM (grafica derecha). En consecuencia, a estos datos, los porcentajes de duty

cycle de la radio del nodo se verán afectados y se comentarán más adelante.

Figura 7-64. Representación temporal del estado de la CPU en modo activo y LPM del nodo 4


118

Durante la simulación, el nodo frontera de la red WSN solamente transmitirá cuando su buffer de

nivel de aplicación esté lleno. Una vez se encuentre en este estado, el nodo tiene que vaciar los

paquetes que tiene almacenados enviándolos de forma secuencial.

La forma escalonada de la gráfica de la Figura 7-65 se debe a que durante un periodo de tiempo el

nodo está recibiendo paquetes y confirmando la recepción, de ahí que no aparezca régimen

permanente, pero cuando tiene que vaciar la cola de paquetes se produce un incremento en el tiempo

de transmisión porque su principal tarea es el envío secuencial y continuo de todos los paquetes hasta

vaciar su buffer por completo.

Figura 7-65. Representación temporal del estado de TX del nodo 4 (I)

Como puede observarse el valor máximo del tiempo de transmisión llega a casi 450000 ms y el

número de paquetes que envía el nodo 4 al nodo sumidero en total es 140.


119

Aunque en la gráfica de la Figura 7-65, pueda notarse que el comportamiento del nodo es siempre el

mismo porque aumenta de forma escalona, en la Figura 7-66 se ha acotado una pequeña muestra que

va desde el intervalo 60000-100000 ms para entender cuál es el comportamiento del nodo.

Figura 7-66. Representación temporal del estado de TX (II)

En el intervalo 83000 ms se comienza a apreciar un leve incremento que se va haciendo cada vez

más notable conforme transcurre la simulación. Esto se debe a que el nodo está vaciando su buffer de

paquetes y por lo tanto está obligado a transmitir. La Figura 7-67 expresa un ejemplo de un

dispositivo móvil realizando una transmisión con origen el nodo 4 utilizando para ello una

comunicación IPv6.

Figura 7-67. Muestra de transmisión dispositivo móvil al nodo 4


120

En la Figura 7-68 se comprueba el por qué del incremento que se había producido en la Figura 7-66

y es debido a que el nodo 4 tiene que enviar los paquetes que tiene almacenado en su buffer al nodo

sumidero con id 5. Como aclaración, la comunicación en este caso es usando 6LoWPAN porque el

paquete se comprime usando la técnica IPHC descrita en el Capítulo 5 de este protocolo.

Figura 7-68. Muestra de transmisión del nodo 4 al nodo 5

En la Figura 7-69 se puede apreciar que el tiempo de recepción del nodo frontera es totalmente

creciente a medida que transcurre la simulación.

Figura 7-69. Representación temporal del estado de RX del nodo 4


121

Este resultado es a causa de diferentes factores ocurridos durante la simulación:

Hay 3 dispositivos móviles desplegados en el escenario cuyo único nodo visible que tienen

es el que está en la frontera de la red WSN. Cada nodo envía de forma simultánea su

información utilizando un canal CSMA-CD. Esto quiere decir que el primero que ocupe el

canal es el que consigue transmitir, y mientras tanto este nodo frontero irá almacenando cada

paquete entrante en su buffer de aplicación hasta que se llene. Una vez ocurre esto, se

descarta el resto de paquetes entrantes porque tiene que vaciar su cola.

El nodo frontera al pertenecer a la red WSN tiene que estar a la escucha de los mensajes de

difusión que envíe el nodo sumidero, puesto que al implementar RPL tiene que conocer en

todo momento a su nodo raíz. Entonces, durante la simulación se produce un solape entre los

paquetes que llegan procedentes del nodo raíz con los paquetes de los dispositivos móviles y

al haber prioridad del nodo raíz este nodo tiene que contestar, por lo que se genera una

pérdida de paquetes aún mayor.

Cada dispositivo móvil enviará aproximadamente 100 paquetes, que se traduce en 300 paquetes

enviados entre los tres. Este nodo en su registro tiene contabilizado que ha recibido 140 paquetes de

los 3 dispositivos móviles, por lo que se produce una pérdida de 160 paquetes en total, es decir, hay

un poco más del 50% en pérdidas de paquetes.

En la representación del porcentaje del duty de la radio cuando el nodo transmite (véase Figura 7-

70), se aprecia un incremento muy elevado del duty al inicio de la simulación y cómo va

estabilizándose poco a poco conforme va transcurriendo el tiempo de simulación del escenario.

Figura 7-70. Representación temporal del estado de la radio transmitida del nodo 4 (I)


122

El motivo se debe a que para calcular el porcentaje del duty de la radio cuando el nodo está

transmitiendo se necesitan los datos de tiempo de transmisión (TX), de CPU en modo activo y de

LPM que expresado en forma matemática:

𝐷𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒(%)𝑇𝑋 = 𝑡𝑇𝑋

𝑡𝐶𝑃𝑈+𝑡𝐿𝑃𝑀∗ 100 [7]

[7] Formula del Duty Cycle (%) cuando la radio transmite

Conforme aumentan los valores de los tiempos de CPU, LPM y TX, se advierte que hay un

incremento del valor del parámetro LPM mucho más grande que el resto a causa de que el nodo está

más tiempo en bajo consumo que activo, donde su valor final ronda aproximadamente el 0.7%-0.6%.

En la Figura 7-71 se resalta el pico de crecimiento tan elevado que ha sufrido el nodo, donde se

alcanza aproximadamente el valor del 4% del duty de la radio en el intervalo 13515 ms.

Posteriormente, su valor va mermando porque el nodo entra en modo power saving.

Figura 7-71. Representación temporal del estado de la radio transmitida del nodo 4 (II)

La explicación de este fenómeno se traduce a que al comienzo de la simulación el nodo tiene que

sincronizarse con la fase de la radio del nodo sumidero, es decir, durante todo ese intervalo se están

enviando paquetes preámbulo para intentar conectar con el nodo raíz.

Una vez que se consigue establecer la transmisión entre ambos, la capa de enlace del nodo guarda el

intervalo de tiempo de conexión permitiendo sincronizarse con la fase de despertar del nodo

sumidero para próximas transmisiones.


123


124

En la figura 7-72 se presenta el % radio del nodo cuando está escuchando el canal radio.

Figura 7-72. Representación temporal del estado de la radio recibida del nodo 4

Como se muestra, el funcionamiento del duty cuando el nodo está en modo recepción es menor al

inicio de la simulación que en la gráfica del porcentaje del duty cuando el nodo está transmitiendo

(Figura 7-70).

Hay que tener en cuenta la expresión matemática para este caso:

𝐷𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒(%)𝑅𝑋 = 𝑡𝑅𝑋

𝑡𝐶𝑃𝑈+𝑡𝐿𝑃𝑀∗ 100 [8]

[8] Formula del Duty Cycle (%) cuando la radio está en modo escucha

Al igual que antes, los valores del tiempo LPM son mucho mayores que los del resto de datos. Sin

embargo, desde el intervalo 1200000 ms hasta el final de la simulación, el valor del duty alcanza el

0.92 %, que es mayor que el 0.6 % del duty cuando la radio está transmitiendo. Su motivo es que el

tiempo de recepción RX es mayor que el de transmisión TX.

Aunque el nodo entre en modo power saving, su radio se encontrará a la escucha del canal para

recibir transmisión entrante, ya sea de un dispositivo móvil o del propio nodo sumidero.


125

7.7.1.2. Gráficas de los estados del nodo sumidero (id 5)

El tiempo de funcionamiento CPU y LPM es el que se visualiza en la Figura 7-73. Se representa en el

orden de 106 milisegundos y al igual que en el nodo 4, en el nodo 5 hay un incremento bastante

significativo porque el nodo tiene que procesar los paquetes entrantes que envía el nodo 4 con la

información de cada dispositivo móvil y posteriormente analizarlo. Además, tiene que registrar cada

paquete que ha llegado correctamente y sobre todo atender las peticiones de mensajes de control del

protocolo RPL al ser el nodo raíz de la malla que conforman ambos nodos en la red WSN. Es por ello

que este nodo tiene que ejecutar tantas tareas en paralelo.

Sin embargo, el nodo sólo se despierta cuando es necesario y el resto del tiempo de la simulación se

encuentra en modo de bajo consumo, de ahí que el valor de CPU sea de 0.9 ∗ 106 ms y el de LPM sea

de 65 ∗ 106ms aproximadamente al finalizar la simulación.



126

El funcionamiento del nodo sumidero es escuchar los paquetes entrantes que provienen del nodo

frontera de la red WSN que conforman. Sin embargo, al ser el nodo raíz de la malla RPL creada entre

ambos, debido a que tienen implementado el protocolo RPL durante cierto intervalo de tiempo entre

400000-100000 ms, es donde se produce un mayor envío de mensajes de control al nodo con id 4 cuya

variación va de entre 20000-25000 ms. Esto es debido a que el nodo tiene que actualizar su estado como

raíz de la malla creada con el nodo 4 y como consecuencia se produce una exponencial creciente

observada en la gráfica de la Figura 7-74.

Figura 7-74. Representación temporal del estado de TX

En la Figura 7-75 se aprecia una captura de un mensaje del nodo sumidero al nodo frontera a través

del medio radio.

Figura 7-75. Muestra de transmisión de mensajes de control del nodo 5 al nodo 4


127

Es un mensaje de control porque aparece el campo ICMPv6 indicando que se trata de un mensaje del

protocolo RPL. En concreto, un paquete de tipo DIO cuya intencionalidad es avisar al nodo frontera que

el nodo sumidero sigue siendo el nodo raíz de la malla RPL a pesar que se envíe en modo multicast.

Se observa justo después de los mensajes que envía el nodo sumidero que se encuentra la respuesta del

nodo frontera de la red WSN mediante un paquete de control de tipo DAO.Al igual que ocurre con el

nodo frontera, en la Figura 7-76 se representa la gráfica del estado del nodo sumidero cuando se

encuentra recibiendo transmisiones. Es monótona creciente puesto que su radio siempre se encuentra

escuchando el canal radio en busca de transmisiones cuyo destino sea él, a pesar de cambiar de modo

active a modo low power.


Cómo es el nodo raíz del árbol RPL, tiene que recibir la respuesta de los mensajes de control que le

envía al nodo frontera cada vez que se actualiza una ruta o simplemente para indicarle que sigue siendo

todavía el nodo raíz de la red. Además, como es el nodo sumidero de la red WSN precisa recibir los

paquetes que los dispositivos móviles envían al nodo frontera para poder monitorizarlos y analizarlos

posteriormente.

Durante la simulación, este nodo sumidero ha recibido un total de 140 paquetes procedentes del nodo

frontera. Como se ha explicado en el análisis de las gráficas del nodo frontera, había transmitido un total

de 140 paquetes con destino al nodo sumidero de la red WSN.

El margen de pérdida de paquetes se puede considerar nulo dentro de la red WSN gracias al mallado del

protocolo RPL que implementa en los nodos de la red.


128

En la Figura 7-77 se aprecia el duty cycle del nodo cuando su radio está transmitiendo. Los valores

que se obtienen en la gráfica van disminuyendo conforme va aumentando el tiempo de simulación

debido a que el nodo no realiza un número elevado de transmisiones al nodo con id 4 de la red WSN.

Únicamente le está enviando mensajes de control y por lo tanto se encuentra más tiempo en el modo

LPM que en modo activo de CPU.

Aplicando la Fórmula 7 anteriormente descrita, el resultado obtenido es el siguiente.

Figura 7-77. Representación temporal del estado de la radio transmitida del nodo 5

El pico inicial de la gráfica cuyo valor es del 2.4% aproximadamente es debido a que el nodo tiene

que mantener la radio encendida y enviar paquetes preámbulos hasta conseguir iniciar la conexión

con el otro nodo. Una vez que lo consigue, el protocolo ContikiMAC de la capa de enlace se encarga

de sincronizar la fase de despertar del nodo destino al que se envían los paquetes de control.

Al igual que en el nodo frontera, el nodo sumidero de la red WSN se considera un nodo crítico

porque recibe la información del estado de temperatura de los dispositivos móviles, es decir, es el

encargado de monitorizar sus estados y activar alguna alerta si se produjera algún cambio brusco.


129

Con los valores obtenidos de los tiempos de recepción RX, de CPU activa y en modo LPM,

aplicando la fórmula anteriormente descrita en el nodo 4 (ecuación 8) el resultado obtenido es el

representado en la Figura 7-78.

Figura 7-78. Representación temporal del estado de la radio recibida (I)

Con el fin de estudiar el intervalo inicial del duty de la radio en modo recepción, se ha ampliado para

poder explicar cuál es el motivo de dicho comportamiento (Figura 7-79)

Figura 7-79. Representación temporal del estado de la radio recibida (II) del nodo 5


130

El instante de tiempo 13649 ms es donde se alcanza el valor máximo con casi el 1 % del duty en

tiempo de recepción. Esto indica que en ese momento el nodo se encuentra ejecutándose en el modo

activo de CPU, ya que tiene que sincronizar su fase de recepción con la fase de transmisión del nodo 4

para que se pueda establecer una conexión.

Como finalización al análisis de este primer escenario de simulación, se muestra en la Figura 7-80 la

estimación energética de los nodos 4 y 5 durante el tiempo de transmisión.

Figura 7-80. Estimación de energía de transmisión de los nodos de la red WSN del escenario 1

El nodo 4 (gráfica izquierda) ha consumido hasta un total de 24000 mJ y el nodo 5 (gráfica derecha)

ha consumido alrededor de 1430 mJ en total. Su explicación se debe a que el nodo 4 es el nodo

frontera de la red WSN y durante la simulación ha almacenado los paquetes que enviaban los

dispositivos móviles para transmitírselos al nodo 5 que es el nodo sumidero de dicha red.

En cambio, los valores de energía tan bajos del nodo 5 son a causa de que este nodo solamente envía

paquetes de control al nodo 4 para informar y actualizar su estado como nodo raíz de la malla RPL.


131

7.7.2. Simulación escenario 2

Para el escenario de la simulación 2 se ha procedido a desplegar los siguientes nodos como aparecen

en la Figura 7-81.

Figura 7-81. Escenario de la simulación 2

Los nodos que aparecen en la figura anterior se definen con los siguientes identificadores:

Nodo 9: es el nodo sumidero de la red WSN cuyo funcionamiento se ha cargado en la

aplicación sink.c

Nodos 7 y 8: son los nodos frontera de la red WSN que se comunicarán con el nodo

sumidero, con los dispositivos móviles y entre ellos para intercambiar rutas de

encaminamiento. En estos nodos se ha cargado la aplicación recibe.c

Nodos 1-6: son los dispositivos móviles que se encuentran fuera de la red WSN y tienen

como objetivo transmitir su estado de temperatura a los nodos 7 y 8 durante la simulación.

Para este segundo escenario se han modificado los tiempos de transmisión de los dispositivos

móviles y de los nodos fronteras. Cada dispositivo móvil hará una transmisión cada 10s teniendo en

cuenta la aleatoriedad de si transmite o no, y los nodos fronteras transmitirán los paquetes cuando su

buffer de aplicación se encuentre colapsado cada 0.5 s.

Como consecuencia a estos cambios, el tiempo de esta segunda simulación ha sido de alrededor 11 ∗106 ms (menor que el registrado en el primer escenario). Una vez terminada la simulación, se genera

el fichero simulacion2.txt con los datos obtenidos del plugin Output de Cooja para poder analizar y

representar dicha información.


132

Las representaciones de los datos obtenidos al igual que en la simulación anterior van a centrarse en

el nodo sumidero que se identifica con el id 9 y los nodos frontera con los ids 7 y 8 respectivamente.

Todos estos nodos conforman la red WSN.

Para estos nodos se pretende representar cada uno de sus estados teniendo en cuenta la actividad que

han realizado durante la simulación (medida en ms) y, además, el comportamiento del componente

radio (expresado en %).

Después se expondrán gráficamente los cálculos de la estimación de la evolución energética de estos

nodos, donde ha sido necesario consultar sus valores de tensión y corriente en su correspondiente

datasheet [véase referencia 7].

7.7.2.1. Gráficas de los estados del nodo sumidero (id 9)

En la Figura 7-82 se presenta una comparativa de tiempos de CPU en modo activo y LPM (modo

low power) en ms.


El tiempo de CPU es un poco más bajo que el del nodo 5 (ver Figura 7-73) debido a que el tiempo de

simulación en este escenario es menor. También, al ser el nodo sumidero de la red WSN y al estar

esperando a recibir transmisiones de los nodos que conforman la red, se encuentra más tiempo en

modo power saving (gráfica derecha). Sin embargo, este nodo tendrá que ejecutar las siguientes

tareas en paralelo:

Procesar los paquetes entrantes de los nodos frontera de los dispositivos móviles e ir

almacenándolos en su buffer de nivel de aplicación para posteriormente enviarlos al nodo

sumidero.

Comprobar que cada paquete recibido proviene de un dispositivo móvil y contabilizarlo

como paquete recibido.

Preparar los mensajes de control que tiene que enviar a cada nodo frontera de la red WSN


133

Por último, destacar que los valores de CPU y LPM son muy dispares, hecho que puede apreciarse

en los valores acumulados de las gráficas.

En el caso de la CPU el valor de tiempo total ha sido de casi 0.7 ∗ 106 ms, mientras que el de LPM

es de alrededor 35 ∗ 106 ms porque el nodo sólo se despertará cuando sea necesario,

permaneciendo el resto del tiempo de la simulación en modo de bajo consumo.

En la representación gráfica de la Figura 7-83 se estima que el tiempo de transmisión del nodo

sumidero ha transmitido menos mensajes de control si se compara con el esquema gráfico de la

imagen 45 que hace referencia al nodo sumidero del primer escenario de simulación.

Figura 7-83. Representación temporal del estado de TX del nodo 9

La gráfica muestra una forma escalonada que cada vez tarda más en variar, como se observa en el

intervalo 500000 – 1000000 ms cuyo valor es de 21000 ms. Es a causa de que el nodo ha disminuido

el número de mensajes de control que remite a los nodos de la red WSN.

Este fenómeno puede deberse a que la tasa de recepción de transmisiones procedentes de los nodos

de la red sea muy elevada y que al tratarse de un canal CSMA-CA, la ventana de transmisión para el

nodo sumidero se encuentre más tiempo colapsada que libre.


134

En la Figura 7-84, se muestra un intento de envío de mensajes de control del nodo 9 al resto de nodos

de la red WSN. Este envío se inicia en el intervalo 1010000 ms donde se aprecian constantes

reintentos de transmisión de mensajes de control de tipo DIO por parte del nodo sumidero a los

nodos fronteras.

Figura 7-84. Muestra de transmisión de mensajes de control del nodo 9 al nodo 7 y 8

Se confirma que son reintentos puesto que no se ha obtenido una respuesta mediante un mensaje de

control de tipo DAO de estos nodos fronteras.

En la Figura 7-85, se estima el tiempo de recepción en el nodo sumidero, el cual parece ser menor

que los nodos frontera de la red. Esto se debe a que al ser nodo raíz de la malla RPL que conforman

los tres nodos solamente tiene que atender los mensajes de control que envíen el resto de nodos de la

red y monitorizar los paquetes de información entrantes con la monitorización de temperatura de los

dispositivos móviles.

Durante esta simulación, el número de paquetes recibidos por el nodo registrados a nivel de red ha

sido de 219 paquetes, cuya procedencia pertenece a los nodos 7 y 8.


135



136

Cuando se ha analizado el tiempo de transmisión del nodo sumidero en la Figura 7-83, se observa

que el número de mensajes de control ha disminuido. Esto se verifica en la Figura 7-86 que muestra

el duty cycle de la radio cuando el transceptor está transmitiendo. Su valor es del 0.12 % en el

instante de tiempo 500000 ms que es cuando el tiempo de transmisión se está haciendo constante

hasta el final de la simulación, el cual alcanza un 0.07%. Se comprueba, por tanto, que es inferior al

valor del nodo sumidero en la simulación del primer escenario que era del 0.5%.



137

Analizando el inicio de la gráfica del duty cycle cuando la radio está transmitiendo se confirma la

fórmula matemática (ecuación 7) descrita en el escenario 1. El resultado queda plasmado en la Figura

7-87 donde el valor máximo que alcanza el nodo es del 2.4%, pero al estar más tiempo en el estado

de power saving su valor va disminuyendo.

Se comprueban que los picos en forma de sierra de la gráfica indican que el nodo ha pasado al modo

activo de CPU para proceder a transmitir los mensajes de control.


En cuanto al duty cycle de la radio en modo recepción (ver Figura 7-88), hay que recordar la fórmula

matemática del duty cycle (ver ecuación 6) y los valores de tiempo que se han presentado en las

gráficas de CPU en modo activo, LPM y recepción RX.

Figura 7-88. Representación temporal del estado de la radio recibida del nodo 9 (I)


138

El valor del duty al finalizar la simulación es del 0.8%. Este valor que se repite en casi toda la gráfica

es consecuencia a que el valor de LPM siempre es mayor que el de CPU y también porque el nodo 9

mantiene la radio encendida aunque se encuentre en bajo consumo para poder atender las peticiones

entrantes del resto de nodos de la red WSN.

En la Figura 7-89, se ha ampliado la gráfica anterior para estudiar el inicio de la simulación que es

donde se alcanza el valor máximo del porcentaje del duty cycle de la radio en modo de recepción y

cuyo valor es 1.42 %.

Figura 7-89. Representación temporal del estado de la radio recibida del nodo 9 (II)

Como se ha explicado anteriormente, los valores LPM son los que condicionan el resultado de la

gráfica aunque la forma de sierra que adquiere la gráfica es indicativo de que el nodo sumidero está

pasando del modo activo de CPU al modo ahorro de energía LPM.


139

7.7.2.2. Gráficas de los estados del primer nodo frontera (id 7)

En la Figura 7-90 se van a comparar los tiempos de funcionamiento de la CPU en modo activo y el

de LPM del nodo 7 medidos ambos en milisegundos.

Figura 7-90. Representación temporal del estado de la CPU en modo activo del nodo 7

El valor de CPU máximo es de casi 1.4∗ 106 ms mientras que el de LPM casi llega a alcanzar el

valor de 35∗ 106 ms. Como ocurre en el nodo 4, se produce un incremento bastante significativo

porque tiene como función el procesado de los paquetes que recibe de los dispositivos móviles,

donde posteriormente los encolará en su buffer de aplicación para finalmente enviarlos al nodo

sumidero. Además, tiene que procesar los mensajes de control que llegan por difusión a través del

canal radio.

A pesar de eso, como se aprecia en la gráfica de la derecha, el valor del tiempo de LPM es mucho

mayor que el tiempo de CPU, por lo que refleja que el nodo se encuentra más tiempo en modo bajo

consumo y como se percibirá más adelante, estos datos afectarán al porcentaje del duty cycle de la

radio del nodo.


140

Si se presta atención a la Figura 7-91, el tiempo de transmisión de este nodo es mucho mayor que el

del nodo frontera en el intervalo 1 ∗ 106 ms. Esto ocurre porque hay dos nodos frontera que se

encuentran transmitiendo paquetes de datos procedente de los dispositivos móviles al nodo sumidero

de la red. Entonces, se generarán más colisiones en el medio radio y el número de intentos para

conseguir transmitir un paquete será mayor como es posible distinguir entre los intervalos 300000-

600000 ms aproximadamente, donde se produce un incremento de 150000 ms a casi 200000 ms.

Esto ocurre porque el número de intentos de transmisión es muy elevado ya que la ventana de

transmisión está ocupada todo ese tiempo.


En el resto de intervalos se observa que el vaciado del buffer de aplicación es similar, por lo que

únicamente en ese instante de tiempo anteriormente comentado es dónde se ha producido la

anomalía.

Para este nodo, el número total de paquetes transmitido es de 89 paquetes. Un número menor que el

número de paquetes transmitido por el nodo frontera de la primera simulación.

El motivo principal de ese hecho se debe a que se han modificado los parámetros de tiempo de

transmisión del nodo frontera y porque probablemente ha habido un mayor número de colisiones,

generando que el nodo gaste mayor tiempo para poder transmitir a través del canal de radio.


141

En la Figura 7-92 se presenta un ejemplo de transmisión del nodo frontera 7 al nodo sumidero, donde

se aprecia que se está enviando información relacionada con el estado de temperatura del dispositivo

móvil con id 2 utilizando para ello una comunicación 6LoWPAN a través del protocolo de transporte

UDP.

Figura 7-92. Muestra de transmisión del nodo 7 al nodo sumidero

Como ocurre en los nodos de la red WSN, el tiempo de recepción es muy alto convirtiéndose en una

gráfica en forma de rampa, que va aumentando a medida que se avanza en el tiempo de simulación

(véase Figura 7-93). Estos valores tan elevados de tiempo de recepción se deben a la suma de los

mensajes de control de difusión con origen el nodo sumidero y también a los mensajes de control

intercambiados entre ambos nodos frontera de la red WSN, ya que si uno no puede enviar un paquete

de información, lo intentaría reenviar usando la ruta del otro nodo frontera (el problema es que no

queda registrado como paquete enviado, puesto que no sería el remitente del mensaje) y además, a

los paquetes recibidos por cada uno de los dispositivos móviles que haya desplegados.



142

Sin embargo, a causa de que el medio radio en este escenario se encuentra más colapsado que en el

anterior, hay un mayor incremento en el tiempo de recepción si se compara con la gráfica del nodo

frontera anterior en el intervalo 1 ∗ 106ms. El número de paquetes recibidos en total es de 96 y

proceden de los 3 dispositivos móviles que se desplegaron. Este valor es inferior al descrito en el

nodo frontera del escenario 1 porque se han originado más colisiones en el medio radio.

Teniendo en cuenta que el número de paquetes transmitidos al nodo 9 sumidero es 89 y que el

número de paquetes recibidos por los dispositivos móviles es 96, se puede verificar que ha habido un

aumento del número de colisiones dentro de la red WSN y una pérdida de 7 paquetes durante la

simulación en este nodo.

En el estado de transmisión del duty de la radio aparecen picos de diferentes valores. En este análisis

no se tiene en cuenta los picos iniciales ya que todavía no se ha producido la sincronización con la

fase de despertar del nodo sumidero.

Figura 7-94. Representación temporal del estado de la radio transmitida del nodo 7

Como se ha notado en la gráfica del tiempo de transmisión de la Figura 7-94, el porcentaje de

transmisión del duty cycle de la radio del nodo ha ido disminuyendo conforme ha aumentado el valor

del tiempo LPM. Aunque los picos que aparecen en ciertos instantes de tiempo se deben a que el

nodo pasa al estado activo para transmitir luego, vuelve al estado de power saving.

En el intervalo inicial se alcanzó el máximo valor del duty llegando al 7% de su capacidad ya que

aún no había conseguido una sincronización con la fase de despertar del nodo 9 y el número de

reintentos es mucho más elevado. Posteriormente, tras ese valor tan elevado, el porcentaje del duty

de la radio va decreciendo cada vez más debido a que son menos los reintentos que el nodo hace para

transmitir cada paquete.


143


144

La Figura 7-95 muestra de nuevo el porcentaje del duty del nodo cuando su radio se encuentra en

modo escucha. Estos valores son más elevados si se comparan con el nodo frontera del primer

escenario, puesto que el nodo 7 a parte de escuchar las transmisiones entrantes de los dispositivos

móviles, tiene que intercambiarse mensajes de control de tipo RPL entre el nodo 9 y por supuesto

con el otro nodo frontera con id 8 para mantener actualizada el mallado RPL de la red WSN.

Figura 7-95. Representación temporal del estado de la radio recibida del nodo 7

Para finalizar el análisis, los picos iniciales se deben a que el nodo al principio de la simulación

mantiene su ventana de recepción abierta más tiempo para poder sincronizarse con los mensajes de

control que se envían por la red WSN y formar así el mallado del protocolo RPL con el resto de

nodos.


145

7.7.2.3. Gráficas de los estados del segundo nodo frontera (id 8)

Al igual que en el nodo 7, en la Figura 7-96 se refleja la comparación de las gráficas del tiempo de

CPU y de LPM del nodo 8. Los valores máximos que alcanzan al final de la simulación es de

aproximadamente 1.8 ∗ 106 ms (resultado de la gráfica izquierda) y 34 ∗ 106 ms (datos obtenidos

de la gráfica derecha). En ambas gráficas se observa un incremento de valores bastante notable, pero

hay que resaltar que el nodo permanece más tiempo en el modo de ahorro de energía que en estado

activo a pesar de la sobresaturación que experimenta al tener que atender las peticiones de cada

dispositivo y dialogar con los nodos 7 y 9 a través de los mensajes de control que se intercambian

para mantener las rutas de la malla RPL.

Figura 7-96. Representación temporal del estado de la CPU en modo activo del nodo 8

Como última apreciación, estos valores tan altos condicionan al comportamiento del duty cycle de la

radio.

A diferencia de lo que ocurría en el nodo frontera con id 7, en la representación del tiempo de

transmisión del nodo frontera con id 8 (véase en Figura 7-97), se ha observado que hay un mayor

incremento temporal, pero se aprecia que hay menos intentos de retransmisión debido a que las

longitudes de los escalones de la gráfica son más pequeños que en la gráfica del tiempo de

transmisión del nodo 7.



146

Para contrastar esta disminución de retransmisiones en comparación con el otro nodo frontera del

escenario, se resalta que el número de paquetes totales transmitidos durante la simulación ha sido de

129 paquetes, valor mucho mayor que el número de paquetes del nodo 7, de ahí que este nodo haya

ocupado durante más tiempo la ventana de transmisión del canal radio.

El intervalo donde ha habido un aumento más significativo ha sido en el 600000-800000 ms donde

los valores de transmisión aumentaron de 350000 ms a 450000 ms. El motivo es que el nodo frontera

ha vaciado su cola de paquetes y ha permanecido más tiempo transmitiendo a través del canal radio

que el nodo frontera 7.

Con la Figura 7-98 se intenta respaldar lo comentado en la anterior gráfica. Aquí se demuestra que el

nodo 8 consigue realizar más transmisiones que en el nodo 7 de forma seguida, puesto que es capaz

de transmitir a través del canal radios dos veces consecutivas.

Figura 7-98. Muestra de transmisión del nodo 8 al nodo sumidero


147

De la misma condición que se ha analizado el primer nodo frontera, este segundo nodo frontera

presenta unos valores de tiempo de recepción elevados y que van creciendo conforme aumenta el

tiempo de simulación (véase Figura 7-99). El motivo es semejante al ocurrido en el primer nodo

frontera: el tiempo de recepción de este nodo es la suma del tiempo de los mensajes de control que

recibe del nodo sumidero, el tiempo de interconexión entre los dos nodos frontera donde se

intercambian mensajes de control del protocolo RPL, y el tiempo de los paquetes recibidos por los

dispositivos móviles informando de su estado.


Cabe resaltar que el tiempo de recepción recogido en el nodo 8 es de casi 500000 ms, mientras el

monitorizado en el nodo 7 es alrededor de 400000 ms. La causa de este hecho es que este segundo

nodo frontera ha procesado un total de 137 paquetes frente a los 96 paquetes recibidos en el primer

nodo frontera. Sin embargo, hay que denotar que cada dispositivo móvil ha enviado un total de 100

paquetes durante la simulación, por lo que 163 paquetes se perdieron a causa de las colisiones que

hubo en el medio radio, es decir, ha habido una pérdida de más del 50 % entre el nodo frontera y los

dispositivos móviles.

Aunque si se analiza que de los 137 paquetes que ha recibido el nodo frontera con id 8 y el número

de paquetes transmitidos en la red WSN con destino el nodo sumidero con id 9 ha sido de 129

paquetes, puede afirmarse que el porcentaje de paquetes perdidos dentro de la red es ínfimamente

menor gracias a la implementación de la malla generada por el protocolo RPL.


148

En la Figura 7-100 se ha resaltado aquellos paquetes que ha recibido el nodo 8 procedente de los

dispositivos móviles identificados con los ids 6 y 7.

Figura 7-100. Muestra de recepción de los dispositivos móviles al nodo 8

A diferencia de la comunicación dentro de la red WSN, los dispositivos móviles usan IPv6

supeditado al protocolo UDP.

A continuación, se va analiza el duty cycle de la radio cuando el nodo está transmitiendo los

paquetes que tiene almacenado en su buffer. Como se distingue en la Figura 7-101, en los primeros

instantes de la simulación se registran valores muy altos, registrándose el máximo valor en el 6 %

aproximadamente al inicio de la simulación. Esto se debe porque el nodo tiene que mantener la radio

en este estado hasta conseguir que la radio del nodo sumidero se haya despertado y esté disponible

para iniciar una transmisión.



149

También debe destacarse que el porcentaje del duty cycle del nodo cuando su radio está

transmitiendo está por encima del 1.5 % ya que es el nodo frontera que más transmisiones ha

realizado, por lo que a pesar de que el valor del LPM sea muy elevado, se estabiliza con el valor del

tiempo de transmisión TX tal y como se ha mostrado en la fórmula del duty cycle de la ecuación 6.

Conforme hay menos paquetes que transmitir, su valor va decreciendo durante la simulación.

En la Figura 7-102 se aprecia que los niveles del duty cycle disminuyen de manera progresiva debido

a que el nodo en los primeros instantes tiene que realizar más intentos de retransmisión puesto que

aún no ha sincronizado su fase de despertar con la del nodo sumidero de la red WSN.



150

En la Figura7-103, el comportamiento del duty cycle de la radio cuando el nodo está en modo

recepción es bastante similar al nodo 7, nodo frontera que conforma la red WSN. La radio del nodo

se encuentra funcionando casi todo el tiempo de la simulación alrededor del 1.5-1.4 % de capacidad,

donde se observa que este dato es mayor que en el otro nodo frontera. Esto es consecuencia de que

los tiempos de recepción RX del nodo 8 son mayores que los del nodo 7 debido a que como se ha

comentado en la Figura 7-99, el número de paquetes que recibe este nodo por parte de los

dispositivos móviles es claramente más alto que en el nodo 7 a pesar de que el nodo cambie su

estado al modo power saving.

Figura 7-103. Representación temporal del estado de la radio recibida del nodo (I)

En la Figura 7-104, se muestra un zoom de la gráfica anterior para recalcar que el valor del duty al

2.5% alcanzado por el nodo frontera es causado por la desincronización de la fase del nodo en el

canal radio dentro de la red WSN.

Figura 7-104. Representación temporal del estado de la radio recibida del nodo 8 (II)


151

Para finalizar el estudio realizado en el segundo escenario de simulación, se presentan los resultados

de la estimación de energía calculada de los nodos 6, 7 y 8 que se muestran en las Figuras 7-105 y 7-

106 para respaldar el trabajo temporal que se ha realizado anteriormente con cada uno de los nodos.

Figura 7-105. Estimación de energía de transmisión de los nodos 7 y 8 de la red WSN del escenario 2 (I)

En la Figura 7-105, se están comparando los valores de energía cuando los nodos frontera 7 y 8 están

transmitiendo los paquetes almacenados en su buffer con destino al nodo sumidero. Se observa que

el nodo 8 (gráfica de la derecha) ha consumido más energía (~32000 mJ) frente al nodo 7 (~21000

mJ). El motivo se debe a que el segundo nodo frontera (id 8) ha conseguido transmitir con éxito un

mayor número de paquetes procedente de los dispositivos móviles con destino el nodo sumidero y

colateralmente ha podido producirse un mayor número de colisiones cuando ambos nodos han

coincidido al transmitir a través del canal radio.

En cambio, en la Figura 7-106, el consumo de energía en el nodo 9 es mucho menor a causa de que

sólo ha transmitido mensajes de control y asentimientos de los paquetes recibidos del resto de nodos

de la red WSN. Su valor máximo de energía consumida es de aproximadamente 1300 mJ.

Figura 7-106. Estimación de energía de transmisión del nodo 9 de la red WSN del escenario 2 (II)


152

7.8. Herramientas para extracción, modelado y representación de los datos

En este apartado se detalla el procedimiento que se ha realizado una vez terminada la simulación y

generado el correspondiente fichero con los datos.

A partir de los datos se realiza un proceso llamado ETL basado en la extracción, tratamiento y

limpieza de los datos obtenidos, donde al terminar este procedimiento se realiza la representación

gráfica de los datos que han sido tratados en el análisis anteriormente descrito.

Antes de la generación del fichero de simulación hay que tener en cuenta que con el plugin Mote

Output de la herramienta Cooja se puede seleccionar o filtrar aquellos mensajes que se estimen

relevantes para cada nodo en función de su id. Una vez se ha filtrado, se exportan los datos en un

fichero de texto plano, el cual podrá abrirse usando un editor de texto como el Emacs, Vim o Gedit.

Existen muchas formas de realizar el proceso ETL, pero la manera elegida por su sencillez ha sido el

uso del scripting para automatizar el procedimiento de forma rápida y cómoda.

Se ha creado el script data_filter.sh que contiene una serie de cadenas de filtrado implementado por

los comandos cat, grep y tr cuya documentación puede encontrarse en las referencias [39], [40] y

[41] para el significado de cada opción usada en ellos. En la Figura 7-107 se puede ver parte del

código implementado.

Figura 7-107. Parte del código implementado en el script data_filter.sh


153

Como resumen del funcionamiento de este script, lo único que necesita son los ficheros que se

obtienen de la simulación. Cuando se ejecuta el .sh va leyendo y extrayendo aquellos datos que

coinciden con el id de cada nodo y se almacenan en un fichero temporal con nombre tempnodeidx.txt

para continuar con su extracción. Posteriormente, se elimina de este fichero temporal los datos que

no fueron anulados en la primera extracción, y los datos que se consideran como válidos se guardan

en el fichero nodeidx.txt. Tras esto, cada fichero se almacena en el directorio correspondiente a su

simulación.

Este fichero de datos ya procesado se pasa como argumento de entrada a un script realizado en

Python llamado etl.py que gracias a la librería Pandas y Numpy junto con el uso de Dataframes

(véase en [42]), se procesan y organizan en columnas para transformarlos finalmente a un fichero en

formato .csv, facilitando la legibilidad y representación de los datos de forma eficiente y ligera. Parte

del código que se utiliza se aprecia en la Figura 7-108.

Figura 7-108. Función etl_datos_mota del script etl.py

Su funcionamiento consiste en definir un conjunto de columnas que van a ser la cabecera de los

datos y después, leer el fichero indicando que cada dato se separa de un guión. Tras esta operación,

se obtiene la variable df que es una tabla de datos separados por columnas con sus respectivas

cabeceras. Lo último que se realiza es eliminar las columnas que no se necesitan en la representación

de los datos.


154

Este mismo procedimiento se hace también con los datos recolectados por la herramienta Powertrace

de los protocolos implementados en cada nodo, como se muestra en la Figura 7-109.

Figura 7-109. Función etl_datos_proto del script etl.py

Sin embargo, al analizar los ficheros .csv, se observa que casi todas las columnas tienen valores nulos

por lo que no se puede obtener una representación gráfica de estos datos.

Una vez se termina la ejecución del script etl.py se obtienen los ficheros nodeidxtime.csv, los cuales

tienen que ser analizados uno por uno para poder extraer los valores significativos que se

representarán. Esto se hace con las funciones de filtrado que proporciona la herramienta Libre Office,

de manera, que el conjunto de ficheros que se obtiene para cada nodo de cada una de las

simulaciones es la mostrada en la Figura 7-110.

Figura 7-110. Ficheros generados de la primera simulación


155

Finalmente, después de todo el proceso llevado a cabo queda la representación de los datos

almacenados en los ficheros con extensión .csv. Para ello, se ha optado por implementar la librería

mathplotlib de Python [43], creándose el script plotting.py que al ejecutarse mostrará gráficamente

los datos de los nodos de la simulación realizada para poder hacer un mejor análisis del protocolo

RPL y su nivel de rendimiento en la red WSN desplegada. Parte del código implementado en ese

script se muestra en la Figura 7-111.

Figura 7-111. Función plotting_state_mota del script plotting.py

La función de este script visualizará datos en función del tipo de fichero que se esté leyendo (datos

de transmisión o recepción). Cuando se genera cada gráfica se almacenará en formato .png para

poderse analizar y comparar con el resto de gráficas.


156

Para terminar, se ha creado el fichero plotting_energy.py para representar las estimaciones de energía

de cada nodo teniendo en cuenta los valores de tensión y corriente de su datasheet. El código

implementado en este script es muy parecido al del script plotting.py como se demuestra en la Figura

7-112.

Figura 7-112. Función plotting_energy_mota del script plotting_energy.py

Por ultimo, en el directorio Paquetes_recolectados se almacenan los ficheros csv usados para la

generación de las gráficas por los scripts plotting_pkt_sim1.py y plotting_pkt_si21.py


157


158

8 Conclusiones

on este proyecto, se ha conseguido un contacto más cercano al tema de las Redes de Sensores

Inalámbricos (WSN) partiendo de un estudio genérico sobre su funcionamiento hasta ahondar en los

elementos que la componen, la lógica de cómo funcionan estos dispositivos entre ellos, así como los

distintos protocolos que son necesarios para que la red WSN sea eficaz y esté consolidada.

1. Se ha podido comprobar que la elección del sistema operativo es clave para asegurar el

funcionamiento del sistema, a pesar de la elevada curva de aprendizaje que ha supuesto.

2. Los resultados de las simulaciones se consideran aproximaciones de cómo se comportaría los

nodos dentro de una red WSN, aunque no se han tenido en cuenta factores de entorno y no se

ha probado con dispositivos reales.

3. En las dos simulaciones realizadas, el protocolo RPL ha garantizado la comunicación,

reconfiguración y eficiencia de la red de manera sencilla quedando estos hechos contrastados

por la baja tasa de paquetes perdidos que han sufrido los nodos que usaron dicho protocolo.

4. Haber implementado RPL y 6LoWPAN en los nodos de los escenarios de simulación ha

permitido observar que es posible reconstruir las comunicaciones entre los nodos. Si se diera

el caso de que llegaran a dañarse, se gastaran las baterías que los sustentan o si tuvieran que

ser reemplazados en “caliente”, esto no afectaría al funcionamiento de la red.

5. Con el resultado de las simulaciones se aprecia que el protocolo RPL, además de conservar la

energía de cada nodo, permite tener una jerarquía de nodos desplegados donde cada uno

conoce su función y saber qué hacer con los datos que obtienen del resto de la red.

6. La herramienta Powertrace ha sido esencial para poder estudiar el comportamieno de los

nodos en tiempo real y observar el impacto que sufren frente a diversos factores durante la

ejecución.

C

La perfección se alcanza, no cuando no hay nada más

que añadir, sino cuando ya no queda nada más que

quitar.

- Antoine de Saint-Exupery -


159

7. Complementar Powertrace con una base de datos en el nodo sumidero de cada simulación

puede permitir generar un histórico de los datos monitorizados y preveer posibles estados de

los dispositivos móviles.

8. Durante las simulaciones, el elevado número de paquetes perdidos que sufren los nodos

fronteras se deben a que habría que ampliar el tamaño del buffer de nivel de aplicación, pero

esto solo puede contrastarse si se disponen de los dispositivos reales.

8.1. Líneas de avance

Debido a la rápida evolución que están atravesando las redes WSNs, son muy diversas las distintas

vías de mejoras e investigación que se pueden escoger. A continuación, se van a remarcar las más

importantes:

Adquirir los dispositivos físicos para desplegar una red WSN en un entorno real y poder

estudiar el impacto que sufren ante los factores que pueden ir apareciendo y cómo son sus

comportamientos.

Verificar el correcto funcionamiento de la red WSN cuando se despliegan decenas o

centenares de nodos.

Comprobar que es posible la comunicación con diferentes tipos de nodos que incoporen

microcontroladores y transceptores distintos.

Aplicar hacking ético para comprobar la robustez de la seguridad en las comunicaciones de

6LoWPAN y RPL para prevenir ataques y manipulación de datos.

Incorporar en los dispositivos de la red protocolos como CoAP y MQTT que son soportados

por el protocolo RPL y 6LoWPAN para crear una aplicación de tipo web o móvil con la que

poder gestionar de forma remota el funcionamiento de cada nodo y monitorizar su estado en

todo momento, pudiendo llegar a decidir cuándo un nodo se despierta o deja de atender

peticiones.

Aplicar algoritmos de Machine Learning sobre redes WSNs para que las motas sean capaces

de aprender por sí solas ante posibles cambios que puedan originarse dentro de la red y sean

capaces de tomar decisiones de forma autónoma en tiempo real.

Implementación de la tecnología Big Data en los nodos sensores para desplegar una red

WSN que sea capaz de analizar y monitorizar datos en tiempo real.


160

Referencias

[1] Wireless Sensor Networks: Technology, Protocols, and Applications

http://www.tfb.edu.mk/amarkoski/WSN/Kniga-w02

[2] Shuang-Hua Yang. Wireless Sensor Networks [Recurso electrónico]: Principles, Design and

Applications

[3] Protocolo IEEE 802.15.4:

http://ecee.colorado.edu/~liue/teaching/comm_standards/2015S_zigbee/802.15.4-2011.pdf

[4] Protocolo IEEE 1451:

http://ieee1451.nist.gov/Workshop_04Oct01/1451_overview.pdf

[5] Nikolaos A. Pantazis, Stefanos A. Nikolidakis and Dimitrios D. Vergados. A survey on

Energy-Efficient Routing Protocols in Wireless

[6] Página official de TinyOS:

www.tinyos.net/

[7] Adam Dunkels, Oliver Schmidt, Nicolas Finne, Joakim Eriksson, Fredrik Österlind,

Nicolas Tsiftes, and Mathilde Durvy. The contiki os: The operating system for the Internet of

Things. 2011.

[8] Página oficial de FreeRTOS:

http://www.freertos.org/

[9] Shah Bhatti, James Carlson, Hui Dai, Jing Deng, Jeff Rose, Anmol Sheth, Brian Shucker,

Charles Gruenwald, Adam Torgerson, Richard Han. MANTIS OS: An Embedded Multithreaded

Operating System for Wireless Micro Sensor Platforms.

[10] Página oficial de NANO RK:

http://www.nanork.org/projects/nanork/wiki

[11] Protocolo ZigBee:

http://www.elandroidelibre.com/2015/08/todo-sobre-zigbee-la-tecnologia-ultrabarata-para-

comunicacion-inalambrica.html

http://www.tfb.edu.mk/amarkoski/WSN/Kniga-w02

http://ecee.colorado.edu/~liue/teaching/comm_standards/2015S_zigbee/802.15.4-2011.pdf

http://ieee1451.nist.gov/Workshop_04Oct01/1451_overview.pdf

http://www.tinyos.net/

http://www.freertos.org/

http://www.nanork.org/projects/nanork/wiki

http://www.elandroidelibre.com/2015/08/todo-sobre-zigbee-la-tecnologia-ultrabarata-para-comunicacion-inalambrica.html

http://www.elandroidelibre.com/2015/08/todo-sobre-zigbee-la-tecnologia-ultrabarata-para-comunicacion-inalambrica.html


161

[12] RFC 4944. Transmission of IPv6 Packets over IEEE 802.15.4 Networks

[13] RFC 4919. IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

[14] RFC 6282. Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks

[15] RFC 6568. Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area

Networks (6LoWPANs)

[16] RFC 6606. Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal

Area Network (6LoWPAN) Routing

[17] RFC 6775. Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal

Area Networks (6LoWPANs).

[18] Tsvetko Tsvetkov. RPL: IPv6 Routing Protocol for Low Power and Lossy Networks. 2011.

[19] RFC 5673.The ROLL Design Team. Industrial Routing Requirements in Low-Power and Lossy

Networks.

[20] RFC 5826.The ROLL Design Team. Home Automation Routing Requirements in

Low-Power and Lossy Networks.

[21] RFC 5867. The ROLL Design Team. Building Automation Routing Requirements

in Low-Power and Lossy Networks.

[22] RFC 6550. RPL: IPv6 Routing Protocol for Low Power and Lossy Networks

[23] Proveedor Zolertia: https://github.com/Zolertia/Resources/wiki

[24] Características Zolertia Z1: https://github.com/Zolertia/Resources/wiki/The-Z1-mote

[25] Transceptor radio CC2420: http://www.ti.com/product/CC2420

[26] Datasheet Zolertia Z1: http://zolertia.sourceforge.net/wiki/images/e/e8/Z1_RevC_Datasheet.pdf

[27] Contiki MV Image: https://sourceforge.net/projects/contiki/files/Instant%20Contiki/

[28] Cooja Simulator: http://anrg.usc.edu/contiki/index.php/Cooja_Simulator

[29] The Rime communication stack: http://contiki.sourceforge.net/docs/2.6/a01798.html#_details.

[30] Adam Dunkels. The uIP embedded TCP/IP Stack. 2006.

[31] Contiki 3.x Documentation: http://www.eistec.se/docs/contiki/

[32] Contiki 2.6 Documentation: http://contiki.sourceforge.net/docs/2.6/a01780.html

https://github.com/Zolertia/Resources/wiki

https://github.com/Zolertia/Resources/wiki/The-Z1-mote

http://www.ti.com/product/CC2420

http://zolertia.sourceforge.net/wiki/images/e/e8/Z1_RevC_Datasheet.pdf

https://sourceforge.net/projects/contiki/files/Instant%20Contiki/

http://anrg.usc.edu/contiki/index.php/Cooja_Simulator

http://contiki.sourceforge.net/docs/2.6/a01798.html#_details

http://www.eistec.se/docs/contiki/

http://contiki.sourceforge.net/docs/2.6/a01780.html


162

[33] Adam Dunkels, Joakim Eriksson, Niclas Finne, Nicolas Tsiftes.

Powertrace: Network-level Power Profiling for Low-power Wireless Networks

[34] H. Ritter, J. Schiller, T. Voigt, A. Dunkels, and J. Alonso. Experimental Evaluation

of Lifetime Bounds for Wireless Sensor Networks. In Proceedings of the European

Conference on Wireless Sensor Networks (EWSN), Istanbul, Turkey, January 2005

[35] Official git repository for Contiki.: https://github.com/contiki-os/contiki

[36] Introduction in Cooja: https://github.com/contiki-os/contiki/wiki/An-Introduction-to-Cooja

[37] A. Dunkels. The ContikiMAC Radio Duty Cycling Protocol. 2011.

[38] Adam Dunkels, Fredrik -Osterlind, Nicolas Tsiftes, Zhitao He.

Software-based On-line Energy Estimation for Sensor Nodes

[39] Cat command: http://www.linfo.org/cat.html

[40] Grep command: https://www.gnu.org/software/grep/manual/grep.html

[41] Tr command: http://www.computerhope.com/unix/utr.htm

[42] Pandas dataframe in Python: http://pandas.pydata.org/pandas-docs/stable/dsintro.html

[43] Matplotlib in Python: http://matplotlib.org/

[44] IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT):

https://tools.ietf.org/html/rfc7554

[45] Energy Consumption and Performance of IEEE 802.15.4e TSCH and DSME:

https://hal.archives-ouvertes.fr/hal-01287512/document

[46] Bluetooth Low Energy (BLE): http://s2is.org/Issues/v8/n2/papers/paper27.pdf

[47] Official Bluetooth Web:

https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works/low-energy

https://github.com/contiki-os/contiki

https://github.com/contiki-os/contiki/wiki/An-Introduction-to-Cooja

http://www.linfo.org/cat.html

https://www.gnu.org/software/grep/manual/grep.html

http://www.computerhope.com/unix/utr.htm

http://pandas.pydata.org/pandas-docs/stable/dsintro.html

http://matplotlib.org/

https://tools.ietf.org/html/rfc7554

https://hal.archives-ouvertes.fr/hal-01287512/document

http://s2is.org/Issues/v8/n2/papers/paper27.pdf

https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works/low-energy


163


164

Glosario

6LoWPAN: IPv6 over Low power Wireless Personal Area Network

AES-128: Advanced Encryption Standard de 128 bits

AODV: Ad hoc On-Demand Distance Vector Routing

BPSK: Modulador digital basado en el Binary Phase Shift Keying

CCA: Clear Channel Assessment

CSMA-CA: Carrier Sense Multiple Access with Collision Avoidanc

DAO: Destination Advertisement Object

DIO: Directed Information Option

DIS: DODAG Information Solicitation

DODAG: Destination Oriented Directed Acyclic Graph

DSR: Dynamic Source Routing

EUI-64: Extended Unique Identifier - 64

FCP: Fibre Channel Protocol

ICMPv6: Internet Control Message Protocol version 6

IETF: Internet Engineering Task Force

IoT: Internet of Things

IPv6: Internet Protocol version 6

ITU: International Telecommunications Union

LR_WPAN: Low-Rate Wireless Personal Area Network

MAC: Medium Access Control

MTU: Maximun Transmission Unit

O-QPSK: Modulador digital basado en el Offset Quadrature Phase Shift Keying

P2MP: Point-to-Multipoint

P2P: Point-to-Point

RPL: Routing Protocol for Low power and Lossy Networks

UDP: User Datagram Protocol

WLAN: Wireless Local Area Network

WSN: Wireless Sensor Network


Esquema Ventajas Desventajas Escalabilidad Movilidad Routing Tipo de

mensaje

periódico

Robustez

WRP Elimina los bucles y proporciona una

ruta alternativa cuando un enlace se

cae

No es compatible con redes

inalámbricas de gran tamaño

Limitada Limitada Camino

más corto

Intercambio de

tablas

Baja

TBRPF Actualiza la topología con menos

frecuencia que otros protocolos de

este tipo

No soporta redes con baja

movilidad

Limitada Buena Camino

más corto

Mensajes

HELLO

Buena

TORA Minimiza la sobrecarga en la

comunicación, soporta múltiples rutas

y direccionamiento multicast

No incorpora multicast Buena Buena Camino

más corto

Mensajes de

Control IMEP

Baja

Gossiping Evita problemas de implosión Tarda bastante en propagar el

mensaje a todos los nodos de la

red

Buena Buena Aleatorio Ninguno Buena

Flooding Usa una técnica simple y robusta Puede enviar mensajes multicast

duplicados al mismo nodo

Limitada Baja Camino

más corto

Ninguno Buena

RR Es capaz de manejar los fallos de un

nodo, disminuyendo su tasa de

ejecución linealmente en función del

número de nodos fallidos

Puede enviar mensajes duplicados

al mismo nodo

Buena Baja Camino

más corto

Mensajes

HELLO

Buena

E-TORA Minimiza el consumo de energía y la

energía consumida por el balanceo en

los nodos

No incorpora multicast en sus

operaciones

Buena Buena El mejor

camino

Mensajes de

Control IMEP

Baja

Tabla A-1. Flat Routing

Anexo A. Tabla de protocolos de encaminamiento

165


12

162


Esquema

Ventajas

Desventajas

Escalabilidad

Movilidad

Routing

Tipo

Mensaje

Periódico

Robustez

LEACH Distribuido, baja energía y ad-

hoc

No soportado para redes

de gran tamaño y

clustering que genere

sobrecarga

Buena Fija Camino más corto Ninguno Buena

LEACH-C La energía en la transmisión de

datos es menor que en LEACH

Sobrecarga Buena Fija Mejor camino Ninguno Buena

TEEN Funciona bien en condiciones de

medidas que varían mucho

como la temperatura

Consume mucha energía

y se sobrecarga en redes

de gran tamaño

Buena Fija Camino más corto Ninguna Limitada

APTEEN Consumo de energía bajo Gran retardo Buena Fija Mejor camino Mensaje Control

IMEP

Buena

VGA Ahorro de energía y maximiza la

vida de la red

Problema al seleccionar

los óptimos agregadores

locales

Buena No Selecciona el camino más

usado

Ninguna Buena

TTDD Permite el uso de sumideros

móviles para nodos sensores

estacionarios

El nodo origen tiene que

crear una estructura

virtual para enviar los

datos a los sumideros

Baja No Selecciona el camino más

usado

Ninguna Buena

BCDCP Consumo bajo de energía Limitada No Mejor camino Ninguno Limitada

MIMO Ahorra energía e implementa

QoS

Rendimiento bastante

bajo

Buena No Los datos son recolectados

por multime nodos y luego

enviamos a un sumidero

Ninguna Limitada

Sleep/Wake Identifica el cuello de botella y

maximiza el tiempo de vida de

la red

Deficiencias en la

sincronización y

scheduling en toda la red

Buena No Mejor camino Ninguna Limitada

DHAC Alarga el tiempo de vida de la

red

En redes con mucho

tráfico su rendimiento

disminuye

Buena No Mejor camino Mensajes

HELLO

Limitada

Tabla A-2. Hierarchical Routing

166


Tabla A-3. Query-Based Routing

Esquema Ventajas Desventajas Escalabilidad Movilidad Routing Tipo

Mensaje

Periódico

Robustez

DD

Aumenta el tiempo de vida de la red

No permite el envío

continuo de datos

Buena

Limitada

La mejor

ruta

Peticiones

Baja

COUGAR

Para un flujo elevado de datos

minimiza el consumo de transmisión

Experimenta mucha

sobrecarga, complejidad y

falta de sincronización

Limitada

No

La mejor

ruta

Peticiones

Baja

ACQUIRE

Es ideal para consultas complejas

entre los nodos

Flooding

Limitada

Limitada

El

camino

más corto

Peticiones

Baja

167


Tabla A-4. Coherent and Non-Coherent-Based Routing


Mensaje

Periódico

Robustez

SWE

Construye un spanning tree

minimizando el número de

salto entre nodos

Presenta bastante

complejidad

Buena

No

Camino

más corto

Mensajes

HELLO

Baja

MWE

Cada nodo sensor de la red

establece un conjunto de rutas

de mínima energía entorno a

los nodos origen

Baja

escalabilidad y

elevado tiempo

de delay

Baja

No

Camino

más corto

Mensajes

HELLO

Baja

168


Tabla A-5. Negotiation-Based Routing


Mensaje

Periódico

Robustez

SPIN-PP

Simplicidad y bajo coste de despliegue

No asegura la entrega de los

datos y consumo de potencia

innecesario

Buena

Si

Cada nodo envía

los datos a su

vecino más

cercano

Envía un mensaje

a todos sus vecinos

para avisar de que

va a transmitir

Buena

SPIN-EC

Permite reducir la participación de los

nodos cuando sus umbrales de energía

son bajos

No impide que los nodos

reciban mensajes de solicitud

cuando presentan un nivel bajo

de energía

Buena

Si

Cada nodo envía

datos a su vecino

más cercano

Envía un mensaje

a todos sus vecinos

para avisar de que

va a transmitir

Buena

SPIN-BC

Es mejor que SPIN-PP para redes

broadcasts

Tiene que esperar cierto tiempo

antes de enviar el mensaje de

solicitud, incrementando el

retardo en las comunicaciones

Buena

Si

Cada nodo envía

datos a su vecino

más cercano

Envía un mensaje

a todos sus vecinos

para avisar de que

va a transmitir

Buena

SPIN-RL

Disemina los datos, aunque haya un

evento de difusión en la red para

impedir que los paquetes se pierdan o

cuando la comunicación es asimétrica

Tiempo de consumo

Buena

Si

Cada nodo envía

datos a su vecino

más cercano

Envía un mensaje

a todos sus vecinos

para avisar de que

va a transmitir

Buena

169


Tabla A-6. Location-Based Routing


Mensaje

Periódico

Robustez

DREAM Transmisión eficiente de los

paquetes de datos

Malgasta el ancho de

banda de la red

Limitada Buena Los caminos que

minimiza la potencia

total

Mensajes de control Limitada

GEAR Balancea la energía que se

consume para ampliar la vida de

la red

Intercambia la tabla de

forma periódica

Limitada Limitada El mejor camino Mensajes HELLO Buena

GEM Permite que los mensajes sean

enrutado eficientemente gracias a

que los nodos solo conocen las

etiquetas de sus vecinos

Sobrecarga los nodos

inferiores de la jerarquía

Buena Limitada El camino más corto Ninguna Buena

IGF Rendimiento robusto, distribución

de la carga de trabajo

Depende de las tablas de

los vecinos

Limitada Buena El mejor camino Ninguna Buena

GDSTR Encuentra los caminos más cortos

y genera poco trafico

Sobrecarga la red Limitada Ninguna El camino más corto Mensajes HELLO Buena

OGF Alto rendimiento en términos de

energía consumida y escalabilidad

Depende de las tablas de

los vecinos

Buena Limitada El mejor camino Ninguna Buena

PAGE-M Logra que haya poca sobrecarga

de routing y baja energía

consumida

Localización sin estados Buena Buena El camino más corto

usando el algoritmo

greedy

Mensajes HELLO Buena

HGR Combina tanto distancia y

dirección basado en una estrategia

muy flexible

No garantiza que haya

retardo

Buena Buena Los caminos que

minimiza la potencia

total

Ninguna Buena

170


Tabla A-7. Mobile Agent-Based Routing

Esquema Ventajas

Desventajas Escalabilidad Movilidad Routing Tipo

Mensaje

Periódico

Robustez

MIP

Consume menos

energía cuando el nº

de nodos de una red

es alto

Genera grandes

retardos

Limitada

Buena

Elige el camino

que minimiza la

potencia total

consumida

Ninguna

Buena

IEMF/IEMA

Selecciona los

nodos que

consuman menos

energía para llegar a

un nodo destino

No es escalable para un

elevado número nodos

Limitada

Buena

Los caminos que

minimizan la

potencia total

Ninguna

Buena

171


Tabla A-8. Multipath-Based Routing


Mensaje

Periódico

Robustez

ROAM Permite avisar a los nodos routers cuando un destino no es

alcanzable y evita que estos envíen paquetes

Necesita enviar un mensaje Hello para

comprobar si los nodos están activos

Limitada Limitada Cualquier camino Mensajes

HELLO

Limitada

LMR

Usa etiquetas en los paquetes para reducir la carga de

encaminamiento

Si no hay sobrecarga no puede encontrar

las mejores rutas para encaminar

Buena

Buena

Cualquier camino

Ninguna

Buena

GRAB

Se basa en el esfuerzo colectivo de múltiples nodos para

entregar los datos

Envía datos redundantes

Buena

Buena

Selección de ruta

que mejor se

adapte a las QoS

del nodo

Mensaje

HELLO

Buena

HMRP Escalable, simple y minimiza el tiempo de vida de la red Solo envía un único paquete por difusión Buena Baja Cualquier camino Ninguna Limitada

CBMPR

Bajas interferencias y simplicidad

Problemas al añadir nuevas rutas

Limitada

Baja

El mejor camino

Mensajes

HELLO

Limitada

DGR

Permite la transmisión de video en streaming en redes WSN

Tiene que optimizar el tráfico de video

frente a otros

Alta

No

La ruta más

próxima al nodo

vecino

Ninguna

Alta

DCF

Convergencia y expansión de rutas además de balanceo de

carga

Tiene que seleccionar el nodo fuente más

optimo

Alta

Alta

El mejor camino

Ninguna

Buena

RPL

Bajo consumo de energía

Soporta solo trafico unicast

Buena

Buena

Camino más corto

Mensaje DIO

Buena

172


Tabla A-9. QoS-Based Routing


Mensaje

Periódico

Robustez

SAR Proporciona un modo de bajo consumo

manteniendo multiples rutas hacia el

destino

Sobrecarga de mantenimiento de

las tablas y estados en cada nodo

sensor especialmente cuando el

número de nodos es enorme

Limitada Ninguna El camino que

minimiza el promedio

QoS ponderada a lo

largo de la vida útil de

la red

Mensajes

HELLO

Baja

SPEED Tiene un buen desempeño en términos de

retraso de extremo a extremo

Su rendimiento empeora ante

retrasos elevados

Limitada Ninguna Se basa en la ruta sin

estado no determinista

Mensajes

HELLO

Baja

MMSPEED Puede proporcionar la diferenciación QoS

tanto en la fiabilidad y los ámbitos de

oportunidad y mejora significativamente

la capacidad efectiva de una red de

sensores

En una red de alta carga, no puede

cumplir con los requisitos de

retardo de extremo a extremo

Limitada Ninguna Se basa en la ruta sin

estado no determinista

Mensajes

HELLO

Baja

MGR Minimiza el consumo de energía y

satisface las limitaciones del retardo

medio

Se trata el retraso garantizando

como la meta con la máxima

prioridad

Buena Buena El camino con que

minimiza el retraso

Ninguna Baja

173


Anexo B. Directorios en Contiki

La siguiente figura muestra la estructura de carpetas en la que se organiza Contiki.

Figura B-113. Estructura de carpetas de Contiki

apps: esta carpeta las aplicaciones, que sirven como programas auxiliares y pueden ser

usados en el programa principal. Hay que tener cuidado de que no se puede usar cualquier

aplicación con cualquier protocolo. Por ejemplo, hay muchas aplicaciones que están

diseñadas para la pila Rime y no para uIP.

core: en esta carpeta se encuentra el core del sistema operativo, el cual no es recomendable,

puesto que contiene la implementación de los protothreads, los timers, uIP, Rime, RPL y

todo lo que refiere al sistema operativo.

cpu: en este directorio se encuentra todo el código que depende del microcontrolador.

Algunos ejemplos pueden ser la configuración de los timer o temporizadores, el módulo

serial, la memoria flash, las instrucciones para que el microcontrolador entre y salga del low-

power mode, etc. En nuestro caso se usa el x msp430 F1611, por lo que se utiliza la carpeta

msp430. Se puede cambiar fácilmente de microcontrolador eligiendo que se compile el

código de una carpeta diferente.

doc: hace referencia a la documentación del código.

examples: contiene programas desarrollados por la comunidad de Contiki que sirven de

ejemplo para implementarlo en el sistema operativo.

platform: en esta carpeta se encuentra todo el código que depende de la plataforma, como

podría ser la configuración de los botones y los sensores. Además, para cada plataforma hay

una rutina main.

tools: esta carpeta almacena varias herramientas extras que no forman parte del sistema

operativo Contiki y sirven para la depuración, simulación y la mejora de las aplicaciones. A

modo de ejemplo, este directorio contiene software complementario como es el collect-view

y el simulador COOJA, los cuales se compilan por separado al sistema operativo Contiki.

174

evaluación del rendimiento en el nivel de red rpl en...

Documents