Protocolos para redes inalámbricas de sensores

Protocolos para redes inalámbricas de sensores
Tesis de Ingenierı́a en Informática
Jimena Garbarino
[email protected]
Directora
Lic. Adriana Echeverrı́a
Universidad de Buenos Aires
Facultad de Ingenierı́a
7 de noviembre de 2011
2
Agradecimientos
A mi mamá Isabel Ubiedo y a mi papá Eduardo Antonio Garbarino.
A Sergio.
A mi directora de tesis, Lic. Adriana Echeverrı́a.
A toda mi familia, que hace tiempo que no los veo porque estaba estudiando.
A mi hermana Florencia por insistir con que me reciba para reunirnos en
una fiesta.
A todos los que me dieron aliento y me ayudaron de distinta manera: Maxi,
Julia, Ale, Mariano MP y Naranjita, Valeria, Marcela, Agustı́n.
A los profesores que me inspiraron en los comienzos: Ing. Jorge Álvarez Juliá,
Ing. Ricardo Sirne, Lic. Rina Lombardi, Ing. Osvaldo Clúa, Ing. Leopoldo
Carranza. A mis primeros tres jefes.
A todos mis otros compañeros de facultad o del trabajo, a los que perseguı́ por los pasillos o por e-mail con alguna pregunta, especialmente a los
que me ayudaron a aprobar la última materia.
3
4
Índice general
1. Introducción
17
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3. Organización . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2. Redes inalámbricas de sensores
2.1. Introducción . . . . . . . . . . . . . . . . . . . .
2.1.1. Topologı́a . . . . . . . . . . . . . . . . .
2.1.2. Nodo sensor . . . . . . . . . . . . . . . .
2.1.3. Cuestiones de diseño . . . . . . . . . . .
2.2. Tipos de aplicación . . . . . . . . . . . . . . . .
2.2.1. Detección y reporte de eventos . . . . .
2.2.2. Recolección de datos y reporte periódico
2.2.3. Consulta iniciada por sumidero . . . . .
2.2.4. Seguimiento . . . . . . . . . . . . . . . .
2.2.5. Resumen . . . . . . . . . . . . . . . . .
2.3. Estándares de comunicación . . . . . . . . . . .
2.3.1. Bluetooth y Wi-Fi . . . . . . . . . . . .
2.3.2. Estándar IEEE 802.15.4-2006 . . . . . .
2.3.3. ZigBee . . . . . . . . . . . . . . . . . . .
2.3.4. WirelessHART . . . . . . . . . . . . . .
3. Protocolos de red
3.1. Problema del encaminamiento . . . . . . . .
3.2. Encaminamiento jerárquico . . . . . . . . .
3.2.1. Caracterı́sticas . . . . . . . . . . . .
3.2.2. LEACH . . . . . . . . . . . . . . . .
3.3. Encaminamiento geográfico . . . . . . . . .
3.3.1. Caracterı́sticas . . . . . . . . . . . .
3.3.2. Por coordenadas virtuales . . . . . .
3.4. Encaminamiento centrado en los datos . . .
3.4.1. Caracterı́sticas . . . . . . . . . . . .
3.4.2. Energy-Aware Data-Centric Routing
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
23
24
26
29
29
31
32
32
33
33
33
35
40
47
.
.
.
.
.
.
.
.
.
.
55
55
57
57
59
62
62
64
69
69
70
ÍNDICE GENERAL
3.5. Diseminación de interés . .
3.5.1. Caracterı́sticas . . .
3.5.2. SPIN . . . . . . . .
3.6. Consciencia de la energı́a .
3.6.1. Introducción . . . .
3.6.2. Métricas de energı́a .
3.6.3. Flow Augmentation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
74
77
82
82
83
85
4. Diseño de la simulación con Omnet++
4.1. ¿Qué es Omnet++? . . . . . . . . . . . . . . .
4.1.1. Introducción . . . . . . . . . . . . . . .
4.1.2. Conceptos de modelado . . . . . . . . .
4.1.3. Descripción de red . . . . . . . . . . . .
4.1.4. Conceptos de simulación . . . . . . . . .
4.1.5. Ambiente de desarrollo . . . . . . . . . .
4.1.6. Definición de un módulo simple . . . . .
4.1.7. Simulación . . . . . . . . . . . . . . . .
4.1.8. Herramientas de análisis . . . . . . . . .
4.2. Diseño de la red . . . . . . . . . . . . . . . . .
4.2.1. MiXiM 2.1 . . . . . . . . . . . . . . . .
4.2.2. Modelo de dispositivo . . . . . . . . . .
4.2.3. Topologı́a . . . . . . . . . . . . . . . . .
4.2.4. Tamaño del terreno y densidad de nodos
4.2.5. Modelo de despliegue . . . . . . . . . .
4.2.6. Modelo de aplicación . . . . . . . . . . .
4.2.7. Resumen del diseño . . . . . . . . . . .
4.3. Métricas de evaluación . . . . . . . . . . . . . .
4.3.1. Vida útil del sistema . . . . . . . . . . .
4.3.2. Eficiencia . . . . . . . . . . . . . . . . .
4.3.3. Uso de la energı́a . . . . . . . . . . . . .
4.3.4. Calidad de servicio . . . . . . . . . . . .
4.3.5. Métricas no consideradas . . . . . . . .
4.3.6. Métricas seleccionadas . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
89
89
90
90
92
94
94
97
97
100
100
102
105
105
106
107
108
108
108
109
110
111
112
113
.
.
.
.
.
.
.
.
.
115
. 115
. 116
. 116
. 118
. 129
. 131
. 135
. 138
. 138
5. Implementación de módulos de red
5.1. Definiciones . . . . . . . . . . . . . .
5.2. Diseminación de interés con M-SPIN
5.2.1. Caracterı́sticas . . . . . . . .
5.2.2. Especificaciones . . . . . . . .
5.2.3. Complejidad M . . . . . . . .
5.2.4. Detalles de implementación .
5.2.5. Pseudocódigo . . . . . . . . .
5.3. Consciencia de recursos con SAMF .
5.3.1. Caracterı́sticas . . . . . . . .
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE GENERAL
5.3.2. Especificaciones . . . . . . . .
5.3.3. Complejidad M . . . . . . . .
5.3.4. Detalles de implementación .
5.3.5. Pseudocódigo . . . . . . . . .
5.4. Módulo de técnica mixta: EA-SPIN .
5.4.1. Diseño . . . . . . . . . . . . .
5.4.2. Especificaciones . . . . . . . .
5.4.3. Complejidad M . . . . . . . .
5.4.4. Detalles de implementación .
5.4.5. Pseudocódigo . . . . . . . . .
5.5. Resumen de módulos desarrollados .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6. Simulación y conclusiones
6.1. Escenarios . . . . . . . . . . . . . . . . . . . . .
6.2. Resultados . . . . . . . . . . . . . . . . . . . . .
6.2.1. Complejidad M . . . . . . . . . . . . . .
6.2.2. Métricas obtenidas . . . . . . . . . . . .
6.2.3. Análisis de confiabilidad . . . . . . . . .
6.2.4. Consciencia de energı́a . . . . . . . . . .
6.2.5. Experiencia con MiXiM 2.1 y Omnet++
6.3. Conclusiones . . . . . . . . . . . . . . . . . . .
6.4. Resumen de aportes del trabajo . . . . . . . . .
6.5. Trabajo futuro . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
. . .
4.1 .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
142
146
147
149
153
153
154
160
161
164
167
.
.
.
.
.
.
.
.
.
.
169
. 170
. 170
. 170
. 172
. 188
. 189
. 191
. 192
. 193
. 193
Apéndices
194
A. Glosario
197
B. Métricas
203
B.1. Recopilación de métricas . . . . . . . . . . . . . . . . . . . . . 203
B.2. Métricas de simulaciones especı́ficas . . . . . . . . . . . . . . 206
C. Modificaciones a MiXiM
C.1. Energı́a de transmisión
C.2. Total de mensajes . .
C.3. Energı́a residual . . . .
C.4. Sensibilidad . . . . . .
2.1
. . .
. . .
. . .
. . .
.
.
.
.
Referencias
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
209
. 209
. 209
. 211
. 212
213
7
ÍNDICE GENERAL
8
Índice de figuras
2.1. Infraestructura de una red inalámbrica de sensores .
2.2. Componentes de hardware del nodo sensor . . . . . .
2.3. Componentes de software del nodo sensor . . . . . .
2.4. Pila genérica de protocolos del nodo sensor . . . . .
2.5. Nodo sensor MicaZ de MEMSIC . . . . . . . . . . .
2.6. Tipos de aplicación . . . . . . . . . . . . . . . . . . .
2.7. Estructura del paquete de capa fı́sica IEEE 802.15.4
2.8. Superframe de IEEE 802.15.4 CSMA ranurado . . .
2.9. Capas de protocolos de ZigBee . . . . . . . . . . . .
2.10. Red ZigBee estrella . . . . . . . . . . . . . . . . . . .
2.11. Red ZigBee malla . . . . . . . . . . . . . . . . . . . .
2.12. Pila de protocolos WirelessHART . . . . . . . . . . .
2.13. Malla WirelessHART . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
25
26
27
28
34
36
37
41
41
42
48
50
3.1. Jerarquı́a virtual en una red de sensores . . . . . . . .
3.2. Topologı́a de red en LEACH . . . . . . . . . . . . . . .
3.3. Encaminamiento geográfico . . . . . . . . . . . . . . .
3.4. Encaminamiento geográfico en presencia de obstáculos
3.5. Nodos perı́metro . . . . . . . . . . . . . . . . . . . . .
3.6. Máquina de estados del nodo EAD . . . . . . . . . . .
3.7. De estado indefinido a estado hoja . . . . . . . . . . .
3.8. Ejemplo de agregación de datos camino al sumidero .
3.9. Implosión . . . . . . . . . . . . . . . . . . . . . . . . .
3.10. Superposición . . . . . . . . . . . . . . . . . . . . . . .
3.11. Negociación SPIN pasos 1 y 2 . . . . . . . . . . . . . .
3.12. Negociación SPIN pasos 3 y 4 . . . . . . . . . . . . .
3.13. Negociación SPIN pasos 5 y 6 . . . . . . . . . . . . . .
3.14. Desempeño no óptimo de FA . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
59
62
63
66
71
72
73
76
76
79
80
80
87
4.1.
4.2.
4.3.
4.4.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
91
91
94
97
Vista de diseño de una red Omnet++ . . . . . . .
Diseño del nodo como módulo compuesto . . . . .
Perspectiva de Simulación de Omnet++ en Eclipse
Configuración de ejecución en Omnet++ . . . . . .
9
.
.
.
.
.
.
.
.
ÍNDICE DE FIGURAS
4.5.
4.6.
4.7.
4.8.
Gráfico de secuencia en Omnet++ . . . . . . . . .
Navegador de vectores y escalares en Omnet++ . .
Gráfico de barras en Omnet++ . . . . . . . . . . .
Potencia de transmisión del tranceptor TI CC2420
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 98
. 99
. 99
. 104
5.1. Etapa de descubrimiento de distancia al sumidero . . . . . . . 117
5.2. Jerarquı́a de módulos de diseminación . . . . . . . . . . . . . 132
6.1. Escenario
6.2. Escenario
6.3. Escenario
6.4. Escenario
6.5. Escenario
6.6. Escenario
6.7. Escenario
6.8. Escenario
6.9. Escenario
6.10. Escenario
6.11. Escenario
6.12. Escenario
6.13. Escenario
6.14. Escenario
6.15. Escenario
6.16. Escenario
6.17. Escenario
6.18. Escenario
6.19. Escenario
6.20. Escenario
6.21. Escenario
6.22. Escenario
6.23. Escenario
6.24. Escenario
6.25. Escenario
6.26. Escenario
6.27. Escenario
6.28. Escenario
6.29. Escenario
6.30. Escenario
1 - Latencia media en el sumidero . . . . . . . . . . 172
1 - Tasa de éxito . . . . . . . . . . . . . . . . . . . 172
1 - Overhead . . . . . . . . . . . . . . . . . . . . . . 173
1 - Total de energı́a de transmisión . . . . . . . . . 173
1 - Media y máxima de saltos . . . . . . . . . . . . 174
1 - Media y desviación de energı́a de transmisión . 174
2 - Latencia media en el sumidero . . . . . . . . . . 175
2 - Tasa de éxito . . . . . . . . . . . . . . . . . . . 175
2 - Overhead . . . . . . . . . . . . . . . . . . . . . . 176
2 - Total de energı́a de transmisión . . . . . . . . . 176
2 - Media y máxima de saltos . . . . . . . . . . . . 177
2 - Media y desviación de energı́a de transmisión . 177
3 - Latencia media en el sumidero . . . . . . . . . . 178
3 - Tasa de éxito . . . . . . . . . . . . . . . . . . . 178
3 - Overhead . . . . . . . . . . . . . . . . . . . . . . 179
3 - Total de energı́a de transmisión . . . . . . . . . 179
3 - Media y máxima de saltos . . . . . . . . . . . . 180
3 - Media y desviación de energı́a de transmisión . 180
4 - Latencia media en el sumidero . . . . . . . . . . 181
4 - Tasa de éxito . . . . . . . . . . . . . . . . . . . 181
4 - Overhead . . . . . . . . . . . . . . . . . . . . . . 182
4 - Total de energı́a de transmisión . . . . . . . . . 182
4 - Media y máxima de saltos . . . . . . . . . . . . 183
4 - Media y desviación de energı́a de transmisión . 183
1 - Total de energı́a vs. distancia al sumidero . . . 184
2 - Total de energı́a vs. distancia al sumidero . . . 184
3 - Total de energı́a vs. distancia al sumidero . . . 185
4 - Total de energı́a vs. distancia al sumidero . . . 185
2: Promedio de energı́a de transmisión por distancia 190
4: Promedio de energı́a de transmisión por distancia 190
10
Índice de cuadros
2.1.
2.2.
2.3.
2.4.
2.5.
Funciones de la pila de protocolos WSN . . . . . . . .
Resumen de tipos de aplicación y caracterı́sticas . . .
Campos de la tabla de encaminamiento ZigBee . . . .
Campos de la tabla de descubrimiento de ruta ZigBee
Campos de la tabla de nodos vecinos ZigBee . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
33
43
44
45
4.1. Módulos MiXiM utilizados . . . . . . . . . . . . . . . . . . . . 103
4.2. Densidad mı́nima de nodos . . . . . . . . . . . . . . . . . . . 106
4.3. Resumen de la red a simular . . . . . . . . . . . . . . . . . . . 108
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
Métricas de M-SPIN . . . . . . . . .
Atributos de cada enlace SAMF . . .
Atributos de cada nodo SAMF . . .
Métricas de SAMF . . . . . . . . . .
Contadores para el análisis de SPIN
Módulos desarrollados . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
117
140
140
142
163
167
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
6.8.
Escenarios simulados . . . . . . . . . . . . . . . . . . .
Cantidad total de paquetes enviados en cada escenario
Métricas de escenario 1 . . . . . . . . . . . . . . . . .
Métricas de escenario 2 . . . . . . . . . . . . . . . . .
Métricas de escenario 3 . . . . . . . . . . . . . . . . .
Métricas de escenario 4 . . . . . . . . . . . . . . . . .
Total de frames descartados por interferencia . . . . .
Consumo total de energı́a en transmisiones . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
170
171
186
186
187
187
189
189
B.1.
B.2.
B.3.
B.4.
B.5.
B.6.
Métricas de evaluación de protocolos . . . . . . . .
Otras métricas de desempeño . . . . . . . . . . . .
Métricas de una revisión de criterios de evaluación
Métricas de evaluación del protocolo SPIN . . . . .
Métricas de evaluación del protoclo PBR . . . . . .
Métricas de evaluación del protocolo EAD . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
203
204
205
206
206
207
11
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE DE CUADROS
12
Fragmentos de código
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
5.1.
5.2.
5.3.
C.1.
C.2.
C.3.
C.4.
C.5.
C.6.
C.7.
C.8.
Modelo de protocolo de capa . . . . . . . . . . . . . .
Definición de red . . . . . . . . . . . . . . . . . . . . .
Configuración del decider . . . . . . . . . . . . . . . .
Actividades de capa fı́sica . . . . . . . . . . . . . . . .
Configuración del nodo sumidero . . . . . . . . . . . .
Dimensiones del terreno . . . . . . . . . . . . . . . . .
Paquete M-SPIN . . . . . . . . . . . . . . . . . . . . .
Paquete SAMF . . . . . . . . . . . . . . . . . . . . . .
Paquete EA-SPIN . . . . . . . . . . . . . . . . . . . .
Método getActivityTotal() . . . . . . . . . . . . . . . .
Redefinición del módulo de rastreo . . . . . . . . . . .
Herencia pública de ImNotifiable para SimTracer . . .
Total de paquetes a partir de notificaciones . . . . . .
SPIN publica paquetes envı́ados y de sobreescucha . .
Grabación de la energı́a residual al finalizar . . . . . .
Grabación del consumo por actividad . . . . . . . . . .
Descarte por baja intensidad en Decider802154Narrow
13
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
96
100
101
105
105
105
133
147
161
209
210
210
210
211
211
211
212
FRAGMENTOS DE CÓDIGO
14
Algoritmos
1.
Ciclo de evento . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
M-SPIN Procesar paquete de aplicación . . . . . . . . . . . . . 135
M-SPIN Procesar paquete STARTUP . . . . . . . . . . . . . . 135
M-SPIN Procesar paquete ADV de anuncio . . . . . . . . . . . 136
M-SPIN Procesar paquete REQ de pedido . . . . . . . . . . . 136
M-SPIN Procesar paquete DATA de datos . . . . . . . . . . . 137
M-SPIN Expira temporizador de repetición o supresión de pedido137
SAMF Procesar paquete de aplicación . . . . . . . . . . . . . . 150
SAMF Procesar paquete INTEREST . . . . . . . . . . . . . . 150
SAMF Procesar paquete DATA . . . . . . . . . . . . . . . . . 151
SAMF Recalcular restricciones de enlace . . . . . . . . . . . . 151
SAMF Actualizar enlace en la tabla . . . . . . . . . . . . . . . 152
SAMF Obtener la mejor ruta a destino . . . . . . . . . . . . . 152
EA-SPIN Procesar paquete de aplicación . . . . . . . . . . . . 164
EA-SPIN Procesar paquete STARTUP . . . . . . . . . . . . . 164
EA-SPIN Procesar paquete ADV de anuncio . . . . . . . . . . 165
EA-SPIN Procesar paquete REQ de pedido . . . . . . . . . . . 165
EA-SPIN Procesar paquete DATA de datos . . . . . . . . . . . 166
EA-SPIN Expira temporizador pedido . . . . . . . . . . . . . . 166
EA-SPIN Expira temporizador de repetición de anuncio . . . . 167
15
93
ALGORITMOS
16
Capı́tulo 1
Introducción
1.1.
Motivación
Una red inalámbrica de sensores, o Wireless Sensor Network, es una red
de un gran número de pequeños dispositivos capaces de medir diferentes
variables de ambiente en el que se encuentran, y de procesar y comunicar la
información de manera inalámbrica [1][2].
Existen varios tipos de aplicaciones de esta tecnologı́a. Por ejemplo, en
defensa, la detección de ataque nuclear, biológico y quı́mico. En medio ambiente, el monitoreo de microclimas, detección de fuego, detección de inundaciones, agricultura [3]. En salud, monitoreo de médicos y pacientes, y de
información fisiológica. En el hogar, lectura automática de medidores, y automatización del hogar. Entre sus aplicaciones comerciales se encuentran el
control de inventario, el seguimiento y detección de vehı́culos, el monitoreo
de tráfico, el control del medio ambiente en oficinas y edificios industriales.
Tı́picamente, la red de sensores será administrada por una entidad civil, comercial, industrial o del gobierno [4].
El modelo de red, en la mayorı́a de los casos, está compuesto por una
estación base, que es un dispositivo con recursos de energı́a y cómputo no
acotados, y un número de pequeños dispositivos homogéneos, los nodos sensores [5].
Un nodo sensor generalmente embebe capacidad de procesamiento y almacenamiento, y puede tener uno o más sensores acústicos, sı́smicos, de radio, infrarrojos, ópticos, magnéticos, y quı́micos o biológicos. El nodo cuenta
también con una unidad de comunicación inalámbrica, y una baterı́a, y posiblemente es capaz de conocer su posición geográfica apoyándose en un GPS
o en un algoritmo de posicionamiento. Invariablemente el nodo se encuentra
restringido en energı́a, ancho de banda y en recursos en general [4]. Para
17
1.1. MOTIVACIÓN
poder ser operados, los nodos necesitan un sistema operativo especı́fico para
redes de sensores. Tı́picamente, se tienen cinco subsistemas o componentes de software: el sistema operativo, controladores de sensor, procesadores
de comunicación, controladores de comunicación y pequeñas aplicaciones de
procesamiento de datos [4].
El estándar de comunicación adoptado en los últimos años por el mercado fue desarrollado por la ZigBee Alliance [4] y define una arquitectura de
capas para la comunicación inalámbrica. Cada capa brinda un conjunto de
servicios especı́ficos a la capa superior. La capa fı́sica, responsable del manejo de la interfaz inalámbrica (frecuencia de operación, tipo de modulación,
codificación) y la capa de enlace responsable del manejo de la comunicación con nodos vecinos (dentro del radio de un salto) están definidas por
el estándar IEEE 802.15.4-2003. La capa de red, responsable del encaminamiento de paquetes dentro de la red de sensores, y cuya principal restricción
de diseño es la eficiencia energética [4], soporta, en esta arquitectura, tres
topologı́as: estrella, árbol y malla.
Para definir el costo de una ruta, el algoritmo de encaminamiento utiliza
una métrica de costo para comparar caminos alternativos. Para calcular el
valor de la métrica para un determinado camino, se asocia un costo a cada
enlace entre dos nodos, y se suma el costo de cada uno de los enlaces utilizados por el camino. El costo de cada enlace individual se define como una
función que depende de la probabilidad de que el paquete sea entregado si
se utiliza ese enlace. En el estándar se plantea que la cuestión de estimar o
definir esta probabilidad es un problema de implementación, para el cual,
los implementadores son libres de aplicar su ingenio [6]. El algoritmo es muy
similar al algoritmo AODV (Ad hoc On-Demand Distance Vector ) el cual
no tiene consideraciones respecto de la optimización de la energı́a [7].
AODV es un protocolo para redes ad hoc donde los nodos se consideran
móviles y se favorecen rutas que utilizan la menor cantidad de enlaces o saltos [8]. Aunque las redes inalámbricas de sensores tienen aspectos en común
con las redes cableadas y ad hoc, tienen también caracterı́sticas propias que
plantean importantes desafı́os de diseño. La densidad de nodos de la red y
el área de cobertura pueden variar ampliamente, pudiendo ser instalada de
manera no supervisada con una distribución de nodos al azar en terrenos
inaccesibles [4][9]. La red debe organizarse a sı́ misma y preservar la energı́a,
para perdurar su vida útil operando con limitadas reservas de baterı́a.
Dado que gran parte de la energı́a se emplea en la transmisión de paquetes de información en topologı́as multi-salto (multi-hop), numerosas técnicas
para protocolos de red han sido estudiadas, con el objeto de mejorar la eficiencia en las comunicaciones en las redes inalámbricas de sensores. Se ha
18
CAPÍTULO 1. INTRODUCCIÓN
identificado un conjunto de paradigmas que permite clasificar los protocolos
según la estructura de red (plana o jerárquica), por el tipo de direccionamiento (basado en la ubicación geográfica), por la funcionalidad provista
(que mantienen más de una ruta, basado en la calidad de servicio, que utilizan agregación de datos) [10], por utilizar modelos de flujo de red y/o por
ser centrados en los datos (basados en consulta, basados en diseminación de
información) [11]. Algunos protocolos que modelan el flujo de red incluyen,
en su diseño, el objetivo de maximizar la vida de la red [12][13][14][15]. Pero
existen varios puntos de vista para definir el tiempo de vida de la red, siempre influidos por el tipo de aplicación para el cual se diseña. Para algunos
autores, se define como el tiempo hasta que se agota la baterı́a del primer
nodo [2][12]. Para otros, esta definición es muy restrictiva y puede flexibilizarse para extender aún más la vida útil de la red [13][14].
Una estrategia de maximización de la vida de la red consiste en seleccionar rutas no óptimas de manera de posponer la muerte de sus nodos,
basando la selección en el conocimiento de diferentes métricas de energı́a de
los nodos de la red [9][16]. Los algoritmos que utilizan este tipo de información para seleccionar la ruta son conscientes de la energı́a.
Los protocolos que se centran en los datos encaminan datos por demanda, reaccionando a una consulta iniciada por la estación base [10]. Intentan
ahorrar energı́a disminuyendo las tareas de mantenimiento de la red, por
lo que sugieren una topologı́a de red plana. El establecimiento de rutas es
dinámico, utilizando diferentes estrategias para controlar el proceso de flooding o inundación de la red en la etapa de descubrimiento, y para diseminar
el interés por un tipo de información [4][17][18].
1.2.
Objetivos
Los objetivos generales de la tesis son el estudio de redes inalámbricas
de sensores y paradigmas de encaminamiento de vanguardia, y la simulación
y análisis de protocolos que utilizan técnicas de diseminación y consciencia
de energı́a.
En este marco se llevó a cabo el siguiente trabajo:
estudio general de las redes inalámbricas de sensores
estudio de los tipos de aplicación
estudio de las principales paradigmas de vanguardia en encaminamiento, focalizando en las técnicas de diseminación y consciencia de la
energı́a
evaluación de Omnet++ como simulador para este tipo de red
19
1.3. ORGANIZACIÓN
configuración de una red ejemplo, de un sumidero y muchos nodos
que ejecutan una aplicación de tipo consulta, y una pila de protocolos
IEEE 802.15.4, incluyendo al canal compartido en el modelo
construcción de módulos de red para los protocolos SAMF, M-SPIN, y
un módulo que combina las técnicas de ambos; construcción de módulos de utilidades de recolección de estadı́sticas y métricas no incluidas
en la herramienta
simulación de los tres protocolos a partir de varios escenarios de consulta
comparación de su desempeño, análisis y observaciones sobre las técnicas seleccionadas
1.3.
Organización
En el capı́tulo 2 se presenta una introducción a las redes inalámbricas
de sensores en términos generales, una clasificación y caracterización de los
tipos de aplicación según su modelo de entrega de datos y una revisión de
los estándares y tecnologı́as de comunicación adoptados para este tipo de red.
El capı́tulo 3 introduce los problemas del encaminamiento y revisa los
tres paradigmas más comúnmente utilizados en taxonomı́as de protocolos
de red, ilustrando cada paradigma con la descripción de un protocolo de la
familia. Luego, se describen las técnicas de diseminación y consciencia de
energı́a, también con protocolos ejemplo.
El cuarto capı́tulo trata de la herramienta de simulación Omnet++, describe el diseño de la red a simular y se enumeran las métricas a obtener para
la evaluación de los protocolos.
En el capı́tulo 5 se detalla la implementación los módulos de red para
los protocolos M-SPIN, SAMF y un protocolo que combina las técnicas de
ambos, sus especificaciones, análisis de complejidad y pseudocódigo.
Finalmente, el capı́tulo 6 expone los resultados de las simulaciones y las
conclusiones del trabajo.
20
Capı́tulo 2
Redes inalámbricas de
sensores
2.1.
Introducción
Una red de sensores es una infraestructura compuesta por elementos
de cómputo, medición y comunicación, que permiten al administrador instrumentar, observar y reaccionar a eventos y fenómenos en un ambiente
especı́fico [4]. Tı́picamente el administrador será una entidad civil, comercial, gubernamental o industrial. El ambiente puede ser un sistema espacio
o sistema biológico, y existen variadas aplicaciones [19]:
Medioambiental
Algunos ejemplos son el seguimiento de aves, pequeños animales, insectos; monitoreo de condiciones ambientales que afectan cultivos y
ganado; irrigación; macroinstrumentos para monitoreo a gran escala
y exploración planetaria; detección quı́mica y biológica; agricultura
de precisión; detección de incendios en bosques; investigación meteorológica o geofı́sica; detección de inundaciones; estudio de la contaminación.
Medicina
Provisión de interfaces para discapacitados, monitoreo integrado de
pacientes, diagnóstico, administración de drogas en hospitales, telemonitoreo de información fisiológica.
Hogar
Automatización del hogar, administración local y remota de electrodomésticos, ambientes inteligentes.
Comercial
Monitoreo de fatiga de material, administración de inventario, cali21
2.1. INTRODUCCIÓN
dad de producto, oficinas inteligentes, control ambiental de edificios,
control robot en manufactura automatizada, juguetes interactivos, museos interactivos, control y automatización de procesos, monitoreo de
área de desastre, diagnóstico de maquinaria, transporte, seguimiento
de vehı́culos.
Figura 2.1: Infraestructura de una red inalámbrica de sensores
La infraestructura comprende los siguientes componentes básicos (figura 2.1 obtenida de [20]):
1. un conjunto de nodos sensores
2. una red de interconexión inalámbrica
3. un punto central de recolección de información o estación base
4. un conjunto de recursos para procesar la información recolectada
Los sensores o nodos inalámbricos, a veces llamados motes, son dispositivos inteligentes multifuncionales y baratos, equipados con múltiples elementos de sensado. Existe tecnologı́a de sensado para realizar mediciones de
22
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
campo eléctrico y magnético; de frecuencia; óptico, electro-ópticos e infrarrojos; radares; láseres; de posición/navegación; sı́smicas y de ondas de presión;
de medio ambiente (viento, humedad, calor). Este tipo de dispositivo posee recursos restringidos de energı́a, comunicación, memoria y capacidad de
cómputo [4].
2.1.1.
Topologı́a
Dentro del área de sensado, los sensores se interconectan por medio enlaces inalámbricos multi-salto, de corta distancia y baja potencia de transmisión, para enviar información a estaciones recolectoras o de monitoreo.
Tı́picamente se despliegan en grandes cantidades y con una distribución
densa. Hay dos tipos de redes [21]:
no estructuradas
Comprende una colección de nodos densa, desplegados ad hoc, posiblemente al azar. Una vez desplegados, la red opera desatendida,
monitoreando y reportando información. El mantenimiento, la administración de la conectividad y detección de fallas son difı́ciles por la
gran cantidad de nodos.
estructuradas
Todos o algunos de los nodos son desplegados de manera pre-planificada,
colocados en posiciones fijas. Tienen la ventaja de requerir una menor
cantidad de nodos para lograr la cobertura del área, con un menor
costo de administración y mantenimiento.
Existen varias configuraciones de redes de sensores [22]. Un nodo fuente
es una entidad en la red que puede proveer información, el nodo sensor. Por
otro lado, un sumidero es la entidad que requiere la información. El sumidero puede pertenecer a la red de sensores (y es otro sensor), ser una entidad
externa a la red o ser un gateway a otra red más grande, como Internet.
Comúnmente, el sumidero o estación base es un dispositivo que posee recursos de energı́a y capacidad computacional no acotados [5]. El modelo de red
tı́pico comprende un sumidero y múltiples nodos fuente o sensores, pero en
muchas aplicaciones se utilizan también múltiples sumideros.
Dadas las limitaciones de alcance de radio, las redes inalámbricas de
sensores en general son multi-salto, y los nodos sensores actúan como encaminadores, ahorrando la necesidad de dispositivos adicionales. El multi-salto
permite superar problemas con distancias largas y obstáculos, y mejora la
eficiencia de la comunicación. Asimismo, la topologı́a de red puede ser plana
o jerárquica, dependiendo de la aplicación y el tipo de encaminamiento que
23
2.1. INTRODUCCIÓN
mejor se adecue a sus requerimientos.
La movilidad en las redes de sensores puede aparecer en tres formas principales [22]:
movilidad del nodo sensor
La movilidad del nodo sensor depende de la aplicación. Por ejemplo,
en el monitoreo medioambiental, los nodos son estacionarios. Sin embargo, en el monitoreo de ganado, el sensor está sujeto al animal y por
lo tanto se mueve. Cuando hay movilidad, la red debe reorganizarse
frecuentemente.
movilidad del sumidero
El aspecto importante es la movilidad de un sumidero que no es parte
de la red, por ejemplo, un humano con un dispositivo personal solicita
información mientras se desplaza dentro de un edificio inteligente. El
sumidero móvil puede solicitar la información en un lugar de la red
y luego moverse a otro lugar, y la red debe lograr que los datos lo
alcancen.
movilidad del evento
En aplicaciones de seguimiento, los objetos o evento a seguir pueden ser
móviles. En este escenario, es importante que los eventos sean cubiertos
por una suficiente cantidad de sensores al mismo tiempo. A medida que
el objeto se desplaza a través de la red, es acompañado por un área
de actividad dentro de la misma. Los nodos que no detectan nada,
alternan a estados de sueño hasta que se requieran transmisiones de
la zona en que se encuentran.
2.1.2.
Nodo sensor
Hardware
Un nodo sensor básico comprende los siguientes cuatro subsistemas de
hardware[4][22] (ver figura 2.2 obtenida de [4]):
Energı́a
Suministro o infraestructura de energı́a para poder operar desde unas
horas hasta meses o años.
Lógica computacional y almacenamiento
Para el procesamiento de datos, almacenamiento temporal, cifrado,
modulación y transmisión.
24
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
Figura 2.2: Componentes de hardware del nodo sensor
Sensor
La interfaz entre el medioambiente y el nodo es el sensor. Puede ser
de humedad, luz, flujo magnético, temperatura, etc.
Comunicación
Se requiere un dispositivo para poder enviar y recibir información a
través de un canal inalámbrico.
Software
Los sensores generalmente operan con cinco subsistemas de software [4]
(ver figura 2.3 obtenida de [4]):
Sistema operativo
El microcódigo o sistema operativo, también llamado middleware, es
el microcódigo común del dispositivo, utilizado por todos los programas de alto nivel, residentes en el nodo. Usualmente, presentan una
arquitectura que permite una rápida implementación con un tamaño
mı́nimo de código. TinyOS es un ejemplo [23].
Controladores de sensores
Módulos de software que administran funciones básicas de los tranceptores de sensores (sensor transceiver ).
Procesadores de comunicación
Módulos que administran funciones de comunicación, encaminamiento,
almacenamiento y reenvı́o de paquetes, mantenimiento de la topologı́a
de red, control de acceso al medio, cifrado, corrección de errores, etc.
25
2.1. INTRODUCCIÓN
Figura 2.3: Componentes de software del nodo sensor
Controladores de comunicación
Módulos que administran las tareas de utilización del enlace de transmisión por radio, sincronización, codificación de señales, recuperación
de errores, modulación.
Mini-aplicaciones de proceso de datos
Aplicaciones básicas soportadas a nivel nodo para procesamiento de
datos en la red.
Protocolos
Los controladores y procesadores de comunicación, piezas de software
que asisten a la interconexión entre nodos, son componentes arquitectónicos
de mayor relevancia. Se ha realizado mucha investigación para desarrollar
protocolos especialmente diseñados para las redes inalámbricas de sensores.
En la figura 2.4 (obtenida de [4]) se ilustra un modelo de protocolos genérico
que comúnmente es utilizado para describir el aparato de comunicación [4].
En la tabla 2.1 (obtenida también de [4]) se caracterizan brevemente las
funciones de cada capa de la pila.
2.1.3.
Cuestiones de diseño
Para que las redes de sensores lleguen a ser verdaderamente omnipresentes se deben encontrar soluciones a problemas propios de diseño, entre
ellos[4]:
26
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
Figura 2.4: Pila genérica de protocolos del nodo sensor
Capas superiores
Capa 4
Capa 3
Capa 2
Capa 1
Aplicaciones residentes en la red,
procesamiento, agregación, procesamiento de consultas externas, y
base de datos externa.
Transporte, incluyendo diseminación y acumulación de datos, cache
y almacenamiento.
Red, administración dinámica de la
topologı́a y encaminamiento
Enlace, administración del canal
compartido, competencia por el canal, y acceso al medio, sincronización y localización
Fı́sica, canal de comunicación, procesamiento de señales
Cuadro 2.1: Funciones de la pila de protocolos WSN
Restricciones de hardware
Un sensor podrı́a tener que caber en un módulo de unos pocos centı́metros cúbicos de volumen. Los sensores podrı́an también tener que ser
desechables, autónomos y adaptativos al ambiente. Se necesita lograr
un empaque confiable a pesar de estas restricciones de hardware. La
figura 2.5, obtenida de la hoja de datos del nodo MicaZ [24]), corresponde a un nodo de 58 mm de largo, 32 mm de ancho y 7 mm de
altura, excluyendo la baterı́a.
27
2.1. INTRODUCCIÓN
Figura 2.5: Nodo sensor MicaZ de MEMSIC
Consumo de energı́a
La vida útil del sensor depende mucho de la duración de la baterı́a,
y en muchos casos es limitada y no se puede recargar. Por lo tanto,
se deben diseñar algoritmos y protocolos conscientes de la energı́a.
Se pueden definir tres dominios funcionales de consumo de energı́a:
sensado, comunicación y procesamiento; todos requieren optimización
para minimizar la utilización de energı́a.
Costo
Casi por definición, la red inalámbrica de sensores consiste de un gran
conjunto de nodos sensores, por lo que el costo de cada unidad afecta
crı́ticamente el costo de la red.
Ambiente
Se espera que las redes de sensores operen de manera desatendida en
lugares geográficos remotos, con grandes desafı́os de administración, o
densamente desplegados, o dentro del ambiente observado.
Canales de transmisión
Los medios de comunicación inalámbricos utilizados son restringidos
en ancho de banda y desempeño en general. Para facilitar la operación
global de estas redes, el canal seleccionado debe estar disponible en
todo el mundo.
Conectividad y topologı́a
Se necesitan protocolos ad hoc diseñados para soportar cambios de
topologı́a debido a la movilidad, disponibilidad de recursos, pérdidas
de información, apagones, mal funcionamiento, interferencia, etc.
Estándares
Un conjunto de protocolos y estándares abiertos son necesarios para las
28
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
capas fı́sica, enlace, red y transporte. Históricamente, se han utilizado
protocolos especı́ficos de cada aplicación, con el efecto de retardar la
comercialización a gran escala.
2.2.
Tipos de aplicación
Por la variedad de aplicaciones que pueden tener las WSNs, existe la
necesidad de desarrollar protocolos especı́ficos del tipo de aplicación, con el
riesgo de desarrollar un protocolo diferente para cada aplicación [25]. Por
ello es importante poder clasificar las aplicaciones, para diseñar soluciones
de clase. Una clasificación no será exhaustiva, puesto que puede haber superposición de clases en algún aspecto, sin embargo, lo más importante es
que permite organizar el diseño.
En [26] se presenta una clasificación de nueve dimensiones taxonómicas,
entre ellas:
Vida útil
Si bien existe una variedad de métricas relacionadas al consumo de
energı́a, se propone que la medida fundamental debe estar relacionada
con el concepto de vida útil de la red, es decir el tiempo que dura
funcionando de manera operativa. Puede ser simple o de duración fija,
compleja o de fases múltiples.
Latencia
La latencia, esto es, el tiempo que tarda en recibirse un paquete, es
un requerimiento temporal cuantificable en las redes inalámbricas de
sensores. Puede ser despreciable, moderada o estricta.
Ancho de banda
Abarca dos aspectos del patrón de tráfico. Se refiere al volumen de datos requerido y a la frecuencia de las transmisiones. Puede ser episódicobajo, episódico-alto, continuo-bajo o continuo-alto.
En [25] se presenta una clasificación algo más simplificada y basada en
los objetivos de la aplicación, los requerimientos de entrega de datos y el
patrón de tráfico, definiendo cuatro tipos de aplicación descriptos en la siguientes secciones. Para cada tipo, se especifican los requerminetos de vida
útil, latencia, ancho de banda y encaminamiento. Un clasificación similar se
ha tratado en [27].
2.2.1.
Detección y reporte de eventos
Patrón de tráfico: Episódico
Latencia: Estricta
29
2.2. TIPOS DE APLICACIÓN
Vida útil: Compleja
El objetivo de este tipo de aplicación es la detección de un evento infrecuente, como pueden serlo la presencia de un intruso, una anomalı́a o falla
mecánica, un incendio en un bosque. Una vez detectado, el evento debe ser
prontamente reportado al sumidero. La aplicación instalada estará inactiva
casi todo el tiempo, y se producirán ráfagas de actividad cuando un evento
sea detectado. Este tipo de aplicación tiene dos problemas importantes. El
primero es la necesidad de disminuir la tasa de falsas alarmas que puedan
producirse, posiblemente utilizando el consenso de un grupo de nodos para
detectar el evento, en lugar de un único nodo. El segundo problema, más
importante aún, es el encaminamiento del evento al vuelo, hacia el sumidero.
Por la infrecuencia de los eventos, el principio de diseño que predomina es
el de minimizar el consumo de energı́a del resto de las actividades. Entonces,
dado que se espera que el volumen de tráfico sea muy bajo, la equidad o las
colisiones en el enlace no son muy importantes, pero la escucha ociosa y el
intercambio de mensajes de control deben optimizarse.
Direccionamiento y encaminamiento
Para el encaminamiento en este tipo de aplicaciones, en [25] se destaca
la necesidad de un mecanismo de direccionamiento especial, la construcción
de rutas de manera reactiva y la utilización de un ciclo de servicio del tranceptor que permita el ahorro de energı́a.
Un esquema de direcciones es necesario para el enlace y el encaminamiento, y para etiquetar los datos con información sobre el lugar donde fueron
generados. Por la gran cantidad de nodos, no resulta conveniente utilizar
una dirección para cada nodo, ya que se necesitarı́a un tamaño de dirección
bastante grande. Además, los nodos en general se comunican sólo localmente (con los vecinos) o al sumidero, por lo que no se necesita direccionar de
cualquier nodo a cualquier nodo.
En aplicaciones de detección de eventos, es más adecuado utilizar encaminamiento reactivo, pues la transmisión de datos es infrecuente, y si se
utiliza encaminamiento proactivo, el mantenimiento de rutas genera un costo innecesario.
En general, una gran cantidad de energı́a es consumida en escucha ociosa. Como es raro que ocurra un evento, los nodos utilizan muy poca energı́a
en transmitir realmente la información. Por ello, se busca que los nodos
funcionen en modo ahorro de energı́a, apagando sus radios periódicamente
en forma independiente o coordinada, ejecutando un ciclo domir-servir. Co30
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
mo la comunicación es multi-salto, es necesario que el nodo esté despierto
periódicamente para reenviar datos de otros nodos, aunque no tenga información propia para transmitir.
2.2.2.
Recolección de datos y reporte periódico
Patrón de tráfico: Continuo
Latencia: Despreciable
Vida útil: Simple
Esta clase incluye a las aplicaciones de monitoreo. Por ejemplo, el monitoreo de cultivos o ganado, o del ambiente (temperatura, humedad y luz) de
un edificio. En estos casos, cada sensor produce una cantidad de información de manera periódica y constante que debe ser encaminada al sumidero.
También, el sumidero podrı́a requerir el cómputo distribuido de alguna función de las lecturas de los nodos sensores. Esta agregación de datos puede
ser implementada utilizando una topologı́a de red jerárquica o plana, en
donde la comunicación es multi-salto y los nodos intermedios van agregando
la información salto a salto.
Direccionamiento y encaminamiento
Para esta clase de aplicación, es importante que las rutas permitan optimizar la vida útil de la red [25].
Al haber un flujo constante de información, la mayor parte de la energı́a
del nodo se gasta en la transmisión. Por ello es importante que las rutas
sean seleccionadas de manera de maximizar la vida útil de la red. En este
sentido, en distintos trabajos se ha comprobado que seleccionar la ruta que
requiere menor energı́a total de transmisión, hace que se agote la baterı́a
de los nodos a lo largo del camino, pudiendo acortar el tiempo que la red
funciona sin particionarse. Por ello, se buscan mecanismos para balancear la
carga del encaminamiento entre los nodos.
En redes de topologı́a jerárquica de clúster, la cabecera de clúster recolecta datos de los nodos y los envı́a agregados al sumidero. Ası́, el gasto de
energı́a en transmisión es mucho más alto en la cabecera que en los nodos,
y para uniformizar el patrón de agotamiento de energı́a, el rol de cabecera
puede rotarse. También, pueden utilizarse nodos con mejores capacidades
para llevar a cabo las tareas de cabecera, simplificando las funciones en los
nodos ordinarios, que ya no podrı́an cumplir también ese rol. Para transmitir a la cabecera, los nodos podrı́an utilizar comunicación multi-salto o de
salto-único, y un esquema hı́brido permite, nuevamente, agotar la energı́a
de la red de manera más uniforme.
31
2.2. TIPOS DE APLICACIÓN
2.2.3.
Consulta iniciada por sumidero
Patrón de tráfico: Episódico
Latencia: Moderada
Vida útil: Compleja
En este escenario, el sumidero puede requerir consultar la medición de
un conjunto de sensores en un determinado momento. Esto permite extraer
información con diferentes grados de resolución, de diferentes regiones en
el espacio. Desde el punto de vista del encaminamiento, se requiere poder
enviar datos a un conjunto dinámico de nodos. Para poder consultar selectivamente un subconjunto de datos, el sumidero debe poder expresar el interés
con algún esquema de metadatos de la información. La consulta se difunde
a un grupo de nodos que buscarán coincidencias y eventualmente enviarán
sus respuestas.
Una funcionalidad adicional de las redes basadas en consulta puede ser la
reprogramación de nodos, si la mayor parte del hardware puede ser controlado por software, las actividades de generación de datos del nodo pueden
ser modificadas por el sumidero.
Direccionamiento y encaminamiento
En este tipo de aplicaciones, el esquema de direcciones debe permitir
hacer broadcast a una región espacial en particular [25]. Tı́picamente, el
sumidero requerirá consultar un subconjunto de nodos localizados en una
región especı́fica, en lugar de un nodo en particular, de lo que se deriva la necesidad de un mecanismo de direccionamiento especial que lo permita. Para
poder difundir una consulta a un grupo de nodos, el encaminamiento debe
poder soportar el broadcast limitado a una región, utilizando información de
posición.
2.2.4.
Seguimiento
Patrón de tráfico: Episódico, Continuo
Latencia: Estricta
Vida útil: Compleja
El seguimiento con redes inalámbricas de sensores tiene muchas aplicaciones en la vigilancia militar o de frontera, donde interesa rastrear el
movimiento de objetos. En medio ambiente las aplicaciones incluyen el seguimiento de patrones de movimiento de pequeños animales.
Esta clase de aplicaciones combinan caracterı́sticas de las tres anteriores.
Cuando se detecta un evento, debe ser prontamente reportado al sumidero. El sumidero puede iniciar consultas a la región en donde el evento fue
detectado, para poder calcular la trayectoria del objeto. Una cuestión de
32
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
diseño importante es determinar un balance entre el costo de calcular rutas
al vuelo o mantener alguna topologı́a para facilitar el proceso de seguimiento.
El posicionamiento tiene incidencias en dos niveles: el sensor debe determinar su propia posición, para luego colaborar en la localización del objetivo
en varios momentos. El esquema de posicionamiento deberá balancear robustez y eficiencia, es decir, la exactitud de la posición al menor costo energético
posible.
Para el seguimiento se ha propuesto la utilización de clústeres dinámicos,
formados por agrupaciones de nodos, según sus mediciones. Las cabeceras
colaboran de manera de activar el clúster más próximo al objetivo para la
recolección de datos.
Direccionamiento y encaminamiento
Para facilitar la detección del objetivo, nuevamente, la estrategia de encaminamiento deberá estar basada en la posición geográfica de los nodos, en
lugar de sus identidades de hardware.
2.2.5.
Resumen
A continuación se resumen las caracterı́sticas de cada clase de aplicación
WSN presentada en [25], utilizando algunas de las dimensiones taxonómicas
de [26].
Tipo de aplicación
Detección y reporte de eventos
Recolección de datos y reporte periódico
Consulta iniciada por sumidero
Seguimiento
Vida útil
Compleja
Simple
Latencia
Estricta
Baja
Ancho de banda
Episódico
Continuo
Compleja
Compleja
Moderada
Estricta
Episódico
Episódico
Cuadro 2.2: Resumen de tipos de aplicación y caracterı́sticas
Las figuras 2.6a y 2.6b corresponden a tipos de aplicaciones ofrecidas
por una compañı́a real, y fueron obtenidas de su sitio web [3].
2.3.
2.3.1.
Estándares de comunicación
Bluetooth y Wi-Fi
Los sistemas Bluetooth y Wi-Fi (IEEE 802.11) son dos opciones muy
populares y comercialmente disponibles cuya utilización en redes inalámbricas de sensores ha sido evaluada.
33
2.3. ESTÁNDARES DE COMUNICACIÓN
(a) Detección de incendios en un bosque
(b) Monitoreo de cultivos
Figura 2.6: Tipos de aplicación
Bluetooth es un sistema diseñado como una red inalámbrica de área personal, su principal aplicación es la conexión de dispositivos a una computadora personal. Se han hecho prototipos de redes de sensores basadas en
Bluetooth, los nodos organizados en picoredes con un nodo maestro y un
máximo de siete nodos esclavos activos. El maestro elije la secuencia de
hopping que deben seguir los esclavos. Puede haber varios nodos esclavos en
estado pasivo en la picored, el maestro interroga los nodos esclavos activos
continuamente.
Hay varios inconvenientes de la aplicación de Bluetooth a redes inalámbricas
de sensores [22]:
la necesidad de tener un nodo maestro constantemente, con el costo
de interrogar sus esclavos
la cantidad limitada de esclavos por picored que soporta
para el caso de redes de sensores densas, se necesitarı́a un número
enorme de nodos maestros
un esclavo activo debe permanecer siempre encendido, ya que no puede
predecir cuando será interrogado por el maestro
un esclavo pasivo debe postularse con el maestro para cambiar a activo,
y si ya hay siete nodos activos, será rechazado
se requiere que cada nodo pueda asumir el rol de maestro o esclavo,
agregando una complejidad considerable
los rápidos saltos de frecuencia requieren una sincronización estricta
entre los nodos de la picored s
En la familia de protocolos IEEE 802.11 se especifican varios tipos de
capa fı́sica que comparten un único protocolo de capa MAC (DCF). En
34
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
términos generales, el estándar de protocolos IEEE 802.11 tiene los siguientes inconvenientes [22]:
requiere que los nodos estén permanentemente escuchando el medio,
ya que podrı́an tener que recibir un frame en cualquier momento
los nodos deben sobre-escuchar paquetes RTS y CTS para ajustar sus
temporizadores NAV adecuadamente
si bien se proveen algunas funcionalidades de ahorro de energı́a, en
general está orientado a altas tasas transmisión, y los tranceptores
disponibles requieren una cantidad de energı́a que es órdenes de magnitud mayores que lo aceptable en aplicaciones de redes de sensores
es un protocolo de salto-único para redes ad-hoc, cuando lo común en
redes de sensores es el encaminamiento de salto-múltiple
2.3.2.
Estándar IEEE 802.15.4-2006
El estándar IEEE 802.15.4, finalizado en el 2003 por el Instituto de Ingenieros Eléctricos y Electrónicos, define la capa fı́sica y MAC para redes
inalámbricas de área personal (WPAN ) de baja tasa de transmisión. A veces se confunde el estándar con ZigBee, otro estándar que agrega servicios
de red, seguridad y aplicación, y está basado en los servicios ofrecidos por
IEEE 802.15.4. Los tipos de aplicación a los que está orientado el estándar
comprenden las redes inalámbricas de sensores, la domótica, las redes hogareñas, la conexión de dispositivos a una computadora personal, seguridad,
etc. La mayorı́a de estas aplicaciones requieren tasas de transmisión bajas
a medias, retardos de transmisión moderados con requerimientos no muy
estrictos, y es muy deseable la reducción al mı́nimo del consumo de energı́a
en los nodos.
Capa fı́sica
El diseño de la capa fı́sica está dirigido por los requerimientos de bajo
costo y eficiencia, de aplicaciones de control y monitoreo sensibles al costo y
de baja tasa de transmisión [4]. Bajo el estándar 802.15.4, se pueden operar
enlaces inalámbricos en tres bandas de frecuencias no licenciadas: 858 MHz,
902 a 928 MHz, y 2.4 GHz. Basados en estas frecuencias, se definen tres
medios fı́sicos:
1. DSSS (Direct Sequence Spread Spectrum) usando modulación BPSK
en la banda 868 MHz a una tasa de 20 Kbps (único canal)
35
2.3. ESTÁNDARES DE COMUNICACIÓN
2. DSSS usando modulación BPSK en la banda de 915 MHz a una tasa
de 40 Kbps (10 canales)
3. DSSS usando modulación O-QPSK en la banda 2.4 GHz a una tasa
de 250 Kbps (16 canales)
El estándar IEEE 802.15.4-2007 es una enmienda que especifica las siguientes alternativas adicionales de capa fı́sica (PHY) [28]:
1. Ultra-wide band (UWB) a frecuencias 3 a 5 GHz, 6 a 10 GHz, y < 1
GHz
2. CSS (Chirp Spread Spectrum) a 2450 MHz
Figura 2.7: Estructura del paquete de capa fı́sica IEEE 802.15.4
La estructura del frame IEEE 802.15.4, ilustrada en la figura 2.7 (obtenida de [4]), comprende los siguientes campos:
1. preámbulo: 32 bits que se utilizan para sincronización de sı́mbolos
2. delimitador: 8 bits que se utilizan para sincronizar la recepción del
frame
3. cabecera: 8 bits que especifican la longitud de la unidad de datos
(PSDU, PHY Service Data Unit)
4. datos: hasta 127 bytes de datos
Capa de acceso al medio
Arquitectura de red
El estándar distingue dos tipos de nodo [4]:
36
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
FFD (Full Function Device)
dispositivo de funcionalidad completa, que puede operar como coordinador de la red PAN, coordinador a secas, o dispositivo
RFD (Reduced Function Device)
dispositivo de funcionalidad reducida, sólo opera como dispositivo
Un dispositivo debe estar asociado a un nodo coordinador FFD formando una red de topologı́a estrella. Los coordinadores pueden comunicarse
punto a punto y varios coordinadores pueden formar una red PAN. La red
se identifica con un identificador PAN de 16-bits y uno de sus coordinadores
es designado como coordinador PAN.
El coordinador:
mantiene la lista de dispositivos asociados
asigna direcciones cortas a sus dispositivos asociados
en modo ranurado, transmite regularmente el beacon (mensaje baliza),
anunciando el identificador de red PAN, y las ranuras reservadas
intercambia frames de datos con dispositivos y con coordinadores
Modo ranurado (beaconed mode)
En modo ranurado, el coordinador de la red estrella organiza el acceso
al canal y la transmisión de datos especificando un superframe. El superframe describe un ciclo de actividades que se repite en forma periódica. El
coordinador arranca cada superframe transmitiendo el frame de señalización (beacon packet), que incluye la especificación del superframe, con
la duración de cada actividad.
Figura 2.8: Superframe de IEEE 802.15.4 CSMA ranurado
Como se observa en la figura 2.8 (obtenida de [4]), el superframe se divide
en dos perı́odos, cuya duración es configurable:
37
2.3. ESTÁNDARES DE COMUNICACIÓN
1. Perı́odo activo
Se divide en 16 ranuras de tiempo (de duración configurable), la primera ocupada en transmitir el frame de señalización, y las restantes
se reparten en dos fases: CAP (Contention Access Period ), el acceso
es por competencia y GTSs (Guaranteed Time Slots), el acceso es exclusivo por ranuras de tiempo garantizadas. El coordinador debe estar
activo durante la totalidad del perı́odo, y los dispositivos asociados
están activos en las ranuras de tiempo GTS que le fueron asignadas.
En la fase CAP el nodo también puede apagar el tranceptor si no tiene
nada que transmitir o recibir.
2. Perı́odo inactivo
Durante este perı́odo, todos los nodos incluyendo el coordinador pueden apagar el tranceptor y ponerse a dormir. Los nodos deberán despertar justo antes de la transmisión del frame de señalización para
recibirlo.
Los coordinadores hacen mucho más trabajo que los dispositivos, el protocolo está diseñado para una topologı́a de sensores restringidos en energı́a
que se comunican con nodos de energı́a no acotada.
El coordinador asigna ranuras de tiempo garantizadas a los dispositivos
que han enviado paquetes de solicitud durante la fase CAP. Una marca en
la solicitud indica si el GTS es para transmitir al coordinador o para recibir
datos del coordinador, y otro campo indica la cantidad de ranuras de tiempo
contiguas que se desean reservar.
La respuesta del coordinador ocurre en dos pasos. El primero es una
confirmación inmediata de la recepción de la solicitud. Al recibir la confirmación, el dispositivo debe rastrear los beacons por un determinado tiempo.
Cuando el coordinador tiene suficientes recursos para otorgar las ranuras
solicitadas, inserta un descriptor GTS en el siguiente beacon. El descriptor
contiene la dirección del nodo solicitante, y la cantidad y posición de las
ranuras otorgadas dentro de la fase GTS. El dispositivo puede utilizar las
ranuras asignadas cada vez que son anunciadas por el coordinador. Asimismo, las ranuras permanecen asignadas hasta que el dispositivo solicita su
liberación con un frame de control especial, o el coordinador detecta que
no han sido utilizadas durante una determinada cantidad de superframes y
las cancela con un descriptor GTS que contiene una posición inválida. Si
el coordinador no tiene los suficientes recursos, también transmite un descriptor GTS especificando una posición inválida y los recursos que sı́ están
disponibles, pudiendo el dispositivo renegociar el GTS.
La transmisión de información del dispositivo al coordinador ocurre en
ranuras GTS, o en la fase CAP utilizando CSMA-CA ranurado. En la dirección opuesta, la transmisión de información del coordinador al dispositivo
ocurre también en ranuras GTS, y si no se han reservado, se hace de la
siguiente manera:
38
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
1. el coordinador anuncia que tiene datos para un dispositivo incluyendo
la dirección del dispositivo en el campo pending address field del frame
beacon
2. cuando el dispositivo encuentra su dirección en el campo, envı́a una
petición de datos durante la fase CAP
3. el coordinador responde con un acuse de recibo y luego envı́a el dato
4. cuando el dispositivo recibe el acuse, deja el tranceptor encendido y se
prepara para la recepción del dato
5. al recibir los datos, el dispositivo responde con un acuse de recibo
6. si el dispositivo no recibe el acuse, repite la petición durante los siguientes superframes o apaga el tranceptor hasta el siguiente beacon
Para la transmisión de datos del dispositivo al coordinador durante la
fase CAP se usa el protocolo CSMA. Para evitar colisiones, no se utiliza
el esquema RTS/CTS (Request To Send / Clear To Send ), sino que usan
retardos al azar. Las ranuras de tiempo de la fase CAP están a su vez subdivididas en ranuras más pequeñas, llamadas perı́odos de backoff. Un perı́odo
de backoff dura lo mismo que la transmisión de 20 sı́mbolos. El dispositivo
que desea transmitir espera al comienzo del siguiente perı́odo de backoff y a
partir de allı́ espera un número al azar (del intervalo [0, 2BE −1]) de perı́odos
siguientes. Luego, en cada perı́odo censa el medio (ejecutando la operación
CCA, Clear Channel Assesment), durante dos perı́odos seguidos. Si las dos
veces el canal está ocioso, ha ganado la competencia y comienza la transmisión de los datos. Si alguna de las veces que el dispositivo censa el medio el
canal está ocupado, comienza el proceso nuevamente con la espera, eligiendo un número al azar de perı́odos de un intervalo mayor (incrementando el
exponente BE). Si es necesario repetir el proceso más de una determinada
cantidad de veces, el dispositivo descarta el frame y declara que se ha producido una falla.
Modo no ranurado (nonbeaconed mode)
En el modo no ranurado el coordinador no transmite frames beacon, ni
hay fase GTS. Todos los paquetes de los dispositivos se transmiten utilizando
CSMA-CA no ranurado, por lo que no hay sincronización con perı́odos de
backoff, y sólo ejecuta una operación CCA antes de transmitir. Si el canal
está ocioso, el dispositivo transmite los datos. Los dispositivos pueden seguir
su propio programa de sueño, despertando para transmitir al coordinador
o para recibir datos del coordinador. El dispositivo envı́a la solicitud de
datos usando CSMA-CA no ranurado, y el coordinador responde el acuse
39
2.3. ESTÁNDARES DE COMUNICACIÓN
de recibo inmediatamente. Luego, cuando el coordinador tiene datos para
el dispositivo, los transmite usando CSMA-CA y el dispositivo responde el
acuse inmediatamente. En este modo, el ciclo de recepción depende de la
aplicación.
2.3.3.
ZigBee
ZigBee [29] es un estándar de comunicación orientado a aplicaciones cuyos requerimientos principales son bajas tasas de transmisión, bajo costo y
larga duración de baterı́a. Algunos sistemas para los que existen perfiles de
aplicación definidos [30] son:
Domótica
Control remoto (home theatre, media center, etc)
Monitoreo de consumo energético y de agua en el hogar
Monitoreo de pacientes crónicos no agudos, salud personal y de la
tercera edad
Los estándares ZigBee son desarrollados por la organización ZigBee Alliance, conformada por cientos de compañı́as, y formada en el 2002 como una
organización sin fines de lucro. Algunas empresas promotoras (con el nivel de
participación más influyente y representación en el directorio) son Philips,
Emerson y Texas Instruments. Las empresas participantes son numerosas,
entre ellas se encuentran AT&T, Cisco, Huawei, Indesit, LG, Samsung, Siemens, Whirpool, Intel, GE.
El estándar ZigBee está definido en capas de protocolos, basadas en el
modelo de referencia OSI. Adoptando la capa fı́sica (PHY) y de acceso al
medio (MAC) IEEE 802.15.4, define capas de servicios de red, aplicación y
seguridad.
La figura 2.9 (obtenida del estándar [6]) esquematiza las capas de la
arquitectura ZigBee.
Las caracterı́sticas fı́sicas de la red están determinadas por la capa fı́sica
IEEE 802.15.4 descripta en la sección 2.3.2.
Arquitectura de red
Los roles de los nodos en ZigBee se corresponden con los del estándar
IEEE 802.15.4, aunque tienen diferente denominación:
Coordinador ZigBee (coordinator ) (Coordinador PAN IEEE 802.15.4)
40
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
Figura 2.9: Capas de protocolos de ZigBee
Encaminador ZigBee (router ) (Coordinador IEEE 802.15.4)
Dispositivo Final ZigBee (end device) (Dispositivo IEEE 802.15.4)
Se soportan las topologı́as de red estrella o punto a punto, como se
especifica en IEEE 802.15.4.
Figura 2.10: Red ZigBee estrella
En la red estrella, esquematizada en la figura 2.10 (obtenida de [29]),
todos los dispositivos de la red se comunican a través del coordinador, que
al activarse selecciona un identificador de red único dentro de su alcance de
radio y establece la red.
En la red punto a punto, todos los dispositivos pueden comunicarse directamente entre sı́. Los dispositivos de funcionalidad reducida participan
41
2.3. ESTÁNDARES DE COMUNICACIÓN
Figura 2.11: Red ZigBee malla
de la red comunicándose con un coordinador o un encaminador ZigBee, pero
no encaminan mensajes. En este caso, el encaminador también puede tomar
el rol de coordinador.
La red punto a punto puede tomar diferentes formas:
Malla
No hay restricción sobre los dispositivos que pueden comunicarse entre
sı́ (figura 2.11, obtenida de [29]).
Árbol
El coordinador establece la red inicial. Los encaminadores forman las
ramas y los dispositivos finales, que no encaminan datos, las hojas
del árbol. Los encaminadores pueden agregar más nodos a la red, más
allá de la red inicial.
Capa de aplicación y seguridad
La capa de aplicación es la más alta en la pila ZigBee, y aloja los objetos de aplicación. Los fabricantes desarrollan objetos de aplicación para
personalizar los dispositivos para su aplicación. Estos objetos controlan y
administran las capas de protocolos del dispositivo. El estándar ZigBee ha
definido perfiles de aplicación, un conjunto de acuerdos sobre formatos de
mensajes y acciones de procesamiento para promover la interoperabilidad
entre diferentes vendedores [30].
ZigBee también provee mecanismos para garantizar la confidencialidad
y autenticidad de la información transmitida. El estándar IEEE 802.15.4 soporta el uso de cifrado AES (Advanced Encryption Standard) de los paquetes
salientes. La autenticación de los datos se puede comprobar incluyendo un
código de integridad de mensaje (MIC) en cada frame.
42
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
Capa de red
La capa de red es responsable de la administración de la red y del encaminamiento. El coordinador establece la nueva red, selecciona la topologı́a,
y asigna direcciones al resto de los dispositivos. Los coordinadores y encaminadores son los que descubren y mantienen las rutas en la red.
La capa de red mantene los siguientes 3 tipos de tablas:
1. encaminamiento
2. descubrimiento de ruta
3. nodos vecinos
Las rutas se mantienen en tablas de encaminamiento, que se utilizan para
determinar el siguiente nodo al que se debe reenviar un mensaje, camino a
un destino particular.
Campo
Dirección destino
Estado
Tamaño
2 bytes
3 bits
Muchos a uno
1 bits
Grabación de ruta requerida
1 bit
Flag de id de grupo
1 bit
Dirección de siguiente nodo
2 bytes
Descripción
La ruta conduce a este destino.
Activo, descubrimiento en curso,
descubrimiento fallido, inactivo, validación en curso.
Si el destino ha solicitado encaminamiento muchos a uno, toma valor
1.
Si está prendido, la ruta seguida por
el paquete será grabada y entregada
al dispositivo de destino.
Está prendido si la dirección de destino es un id de grupo.
La dirección de 16 bits del siguiente
nodo en la ruta.
Cuadro 2.3: Campos de la tabla de encaminamiento ZigBee
En la tabla 2.3 se listan los campos de cada entrada de la tabla de
encaminamiento.
43
2.3. ESTÁNDARES DE COMUNICACIÓN
Campo
Id de petición de ruta
Tamaño
1 byte
Dirección origen
2 bytes
Dirección de emisor
2 bytes
Costo de reenvı́o
1 byte
Costo residual
1 byte
Descripción
El número de secuencia que identifica la petición de ruta. Cada ruta
se identifica por un id único de petición.
16 bits de dirección del dispositivo
origen, quien inicia la petición de
ruta.
16 bits de dirección del dispositivo
emisor, el que ha enviado la petición de ruta en favor del dispositivo
origen. Esta dirección es utilizada
para enviar la respuesta de ruta al
dispositivo origen. Si la misma petición de ruta es recibida de múltiples emisores, la dirección del emisor con el costo total de ruta más
bajo será mantenida.
El costo de ruta acumulado desde
el dispositivo origen. Este campo se
actualiza cuando se envı́a la petición de ruta hacia el dispositivo destino.
El costo de ruta acumulado desde
este dispositivo al dispositivo destino. Este campo se actualiza cuando se envı́a la respuesta de ruta al
dispositivo origen.
Cuadro 2.4: Campos de la tabla de descubrimiento de ruta ZigBee
44
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
Campo
Dirección extendida
Dirección de red
Tipo de dispositivo
En ocio, receptor encendido
Relación
Falla de transmisión
LQI
Marca de tiempo
del último frame de
señalización recibido
Padre potencial
Descripción
64 bits de dirección IEEE 802.15.4
16 bits de dirección de red
Coordinador, encaminador o dispositivo final ZigBee
Si el dispositivo mantienen encendido el receptor cuando está ocioso,
este campo toma valor verdadero.
Este campo determina la relación
con el vecino. Padre, hijo, hermano,
hijo anterior o ninguna.
Un valor alto indica que muchos de
los intentos de transmisión anteriores fallaron.
La calidad de enlace estimada
Opcional.
Si el vecino es un padre potencial,
opcional.
Cuadro 2.5: Campos de la tabla de nodos vecinos ZigBee
Otra tabla utilizada en el encaminamiento es la tabla de descubrimiento
de ruta (tabla 2.4). El contenido de esta tabla es temporario y expira cada
cierta cantidad de milisegundos.
El costo de ruta se calcula como la suma de los costos de cada enlace
que forma parte de la ruta:
C(P ) =
L−1
P
C(li )
i=1
L = longitud de la ruta
P = ruta (path)
li = enlace i (link )
La ruta con el menor costo tiene la mejor chance de entrega exitosa de
paquetes. El estándar ZigBee calcula el costo de enlace como un entero en
el intervalo [0..7] con la siguiente fórmula [6]:
C(l) =
7,
min(7,round(
1
))
(pl )4
El costo es o bien constante (7), o bien el mı́nimo entre 7 y el recı́proco de
pl . Se define a pl como la probabilidad de entrega con buen éxito si se utiliza
45
2.3. ESTÁNDARES DE COMUNICACIÓN
el enlace l.
El estándar menciona que los implementadores pueden optar por utilizar
un costo constante de 7 o un valor que refleje la probabilidad pl de recepción,
especı́ficamente el recı́proco de esa probabilidad (a mayor probabilidad, menor costo), que a su vez refleja la cantidad esperada de intentos requeridos
para pasar un paquete cada vez que se utiliza el enlace. Se plantea la cuestión de cómo estimar o medir pl , y se deja abierta a los implementadores,
pero se sugiere como manera más directa y siempre disponible, la estimación basada en la promediación del indicador LQI (Link Quality Indicator )
(por frame) que provee el estándar MAC y PHY IEEE 802.15.4-2003. Si
se utiliza algún otro método de estimación de pl , el costo inicial debe estar
basado en el LQI promedio. La medida LQI es una caracterización de la calidad del paquete recibido [31], que se implementa utilizando una estimación
de la intensidad recibida (ED, Energy Detection), una estimación de la relación señal/ruido (SNR, Signal to Noise Ratio), o una combinación de ambos.
Como el método para calcular el costo sugerido no tiene en cuenta el
consumo de energı́a, el encaminamiento básico no puede considerarse consciente de la energı́a [29]. La eficiencia del encaminamiento, y la definición
del costo del enlace, dependen de la definición de vida útil de la red, que
está determinada por el tipo de aplicación.
El dispositivo ZigBee mantiene también una tercera tabla de nodos vecinos, que contiene información sobre los dispositivos que se encuentran
dentro del alcance, actualizándose cada vez que se recibe un paquete. Cada
entrada tiene campos requeridos y campos opcionales, algunos listados en
la tabla 2.5.
La aplicación puede solicitar el descubrimiento de ruta para tres patrones
de comunicación [29]:
unicast
Una ruta unicast comienza en un dispositivo y termina en otro.
multicast
El descubrimiento multicast se realiza si la dirección destino es un
identificador de grupo.
muchos a uno
Si la aplicación no provee una dirección destino, se inicia el descubrimiento muchos a uno, donde el dispositivo solicitante es el sumidero.
Si la aplicación solicita descubrimiento de ruta para la dirección broadcast, la petición se toma como inválida.
46
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
El descubrimiento unicast se realiza de la siguiente manera:
1. Un dispositivo O (origen) requiere hallar una ruta a un dispositivo D
(destino), entonces inicia el descubrimiento emitiendo por broadcast el
comando de petición de ruta, que contiene el identificador de petición
de ruta, la dirección destino, y el costo de la ruta, inicialmente en cero.
2. El comando de petición de ruta es recibido por todos los dispositivos
dentro del alcance de O. Si el dispositivo es un dispositivo final, ignora
el comando. Si es un encaminador, lo procesa.
3. El encaminador E que recibe el comando y no tiene la tabla de encaminamiento llena, agrega el costo de O a E al comando de petición de
ruta y lo vuelve a emitir por broadcast. Además, agrega el identificador
de petición de ruta y la dirección origen a la tabla de descubrimiento
de ruta, si no existen.
4. Si el encaminador E que recibe el comando tiene la tabla de encaminamiento llena, y la dirección destino no existe en la tabla, asumiendo que
se utiliza encaminamiento jerárquico, y la petición de ruta proviene de
una ruta válida, E reenviará el comando a lo largo del árbol.
5. Si E tiene la tabla de encaminamiento llena, y la petición de ruta no
proviene de una ruta válida, se ignora.
6. Cada encaminador o coordinador C que recibe la petición, la vuelve
a emitir por broadcast. Si la recibe por duplicado, actualiza la tabla
de descubrimiento de ruta con el costo más bajo desde el dispositivo
emisor hasta C.
7. El reenvı́o continua hasta que el dispositivo final D recibe la petición.
De entre todas las peticiones de ruta que recibe D, selecciona la ruta
óptima según el costo acumulado con que llegan, y emitirá el comando
respuesta de ruta.
ZigBee también soporta encaminamiento en origen (source routing), donde el nodo origen especifica la lista de dispositivos por los cuales debe encaminarse el paquete, y cuando un encaminador lo recibe, simplemente obtiene
la dirección del siguiente nodo de la lista.
2.3.4.
WirelessHART
WirelessHART (Wireless Highway Addressable Remote Transducer ) es
el primer estándar abierto de comunicación inalámbrica especı́ficamente diseñado para aplicaciones de control de procesos, oficialmente liberado en el
año 2007 [32].
47
2.3. ESTÁNDARES DE COMUNICACIÓN
Conceptualmente, las redes WirelessHART son un tipo especial de redes
inalámbricas de sensores. A diferencia de las redes de sensores genéricas, que
asumen que los sensores son desplegados al azar y de manera abundante, el
despliegue de las redes WirelessHART es preciso y con redundancia limitada. Los nodos WirelessHART están conectados a dispositivos de campo para
recolectar datos ambientales especı́ficos de los procesos, por ejemplo, velocidades de flujo, niveles de fluido, o temperaturas. Una lectura de un sensor
quizá no puede reemplazarse por la lectura de otro sensor cercano. Las redes genéricas son auto-configurables y no tienen requerimientos estrictos de
tiempo y confiabilidad, como sı́ lo requieren las aplicaciones inalámbricas
industriales.
Capas WirelessHART
Figura 2.12: Pila de protocolos WirelessHART
La arquitectura de WirelessHART, de acuerdo con el modelo de referencia OSI, se muestra en la figura 2.12 (obtenida de [32]). La pila de protocolos
comprende cinco capas: fı́sica, enlace, red, transporte y aplicación.
La capa fı́sica está mayormente basada en la capa fı́sica DSSS 2.4 GHz
definida en el estándar IEEE 802.15.4-2006, operando en la banda ISM (Industrial, scientific and medical ) de uso no licenciado 2400-2483.5 MHz, con
una tasa de transmisión de 250 Kbits/s y 16 canales con 5 MHz de separación entre cada canal adyacente.
48
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
La capa de enlace es propia y opera de manera sincronizada, con ranuras estrictas de 10 ms y tecnologı́a TDMA (Time-Division Multiplexed
Access) para proveer un sistema de comunicación determinı́stico y libre de
colisiones. El superframe comprende un grupo de ranuras consecutivas y se
repite sobre la base de su perı́odo (que es la suma de la duración del conjunto
de ranuras).
Se utiliza el concepto de transacciones que ocurren en una ranura de
tiempo, descriptas por el vector:
(FID, I, T, SA, DA, COFF)
FID = Identificador de superframe
I = Índice de ranura dentro del superframe
T = Tipo de ranura (transmisión, recepción, ocio)
SA = Dirección origen
DA = Dirección destino
COFF = Desplazamiento dentro del canal, canal lógico para usar en la
transacción
WirelessHART también introduce el concepto de lista negra de canales,
el administrador puede deshabilitar canales que sufren constantes interferencias.
Para soportar el salto de frecuencias, cada dispositivo mantiene una lista
de canales activos. El canal verdadero se calcula a partir número absoluto de
ranura y el desplazamiento dentro del canal. El número absoluto de ranura
toma valor cero al iniciarse la red, y se incrementa constantemente.
La capa de enlace mantiene una colección de tablas [33]:
tabla de superframe
Almacena atributos del superframe.
tabla de enlace
Almacena atributos de cada enlace.
tabla de vecinos
Almacena la lista de dispositivos dentro del alcance de radio.
tabla del grafo
Almacena la lista nodos siguientes legales para propagar un paquete
hacia su destino.
Las capas de red y transporte colaboran para proveer comunicación
confiable y segura extremo a extremo. La capa de aplicación define varios
49
2.3. ESTÁNDARES DE COMUNICACIÓN
comandos que procesa para generar respuestas, tipos de datos y reportes de
estado del dispositivo.
WirelessHART además incluye servicios de seguridad en el enlace y
a nivel de red. La capa MAC provee integridad nodo a nodo usando MIC
(código de integridad de mensaje). A nivel de red, los dispositivos y el administrador de red emplean varias claves para garantizar la confidencialidad e
integridad de las conexiones extremo a extremo: públicas, de red, de unión,
de sesión. El dispositivo y el administrador de red son dos de los tipos de
nodo WirelessHART, descriptos en la siguiente sección.
El dispositivo utilizará la clave de unión para generar el MIC del paquete
de red y encriptar la petición de unión, y la clave pública para generar el
MIC de enlace. Luego de ser autenticado, el administrador de red creará una
clave de sesión que utilizarán para comunicarse. Para el tráfico normal, los
datos del frame (enlace) se autentican con la clave de red y en la capa de
red el paquete se autentica y encripta con la clave de sesión.
Arquitectura de red y encaminamiento
Figura 2.13: Malla WirelessHART
Una red WirelessHART se compone de los siguientes nodos (ver figura 2.13 obtenida de [34]):
50
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
Dispositivo de campo
Conectados a un proceso de planta.
Dispositivo de mano
Computadora portátil compatible con WirelessHART, utilizada para
configurar dispositivos, realizar diagnósticos y calibraciones.
Gateway
Conecta aplicaciones de computadora con dispositivos de campo.
Administrador de red
Responsable de configurar la red, programar y mantener la comunicación entre los dispositivos WirelessHART.
Para soportar la topologı́a de red malla, todos los dispositivos deben poder reenviar paquetes en favor del resto.
Se definen dos protocolos de encaminamiento:
Encaminamiento por grafo
Un grafo puede pensarse como una colección de caminos dirigidos, que
conecta los nodos de la red. Una única red puede tener múltiples grafos,
y algunos pueden solaparse. El administrador de red crea las rutas
asociadas a cada grafo y las almacena en cada dispositivo de la red.
Para enviar un paquete, el dispositivo origen especifica un identificador
de grafo en su encabezado. Todos los dispositivos camino al destino
deben ser preconfigurados con la información de encaminamiento, para
poder determinar el siguiente nodo al cual reenviar el paquete.
Encaminamiento en origen
Complementa el encaminamiento por grafo para asistir al diagnóstico
de la red. El dispositivo origen especifica la lista de dispositivos por
los cuales debe viajar el paquete en el encabezado. Cada dispositivo
utiliza la lista para determinar el siguiente nodo al cual debe reenviar
el paquete.
La capa de red mantiene también un conjunto de tablas propias:
tabla de sesión
Cada entrada identifica una sesión segura entre dos dispositivos.
tabla de transporte
Utilizada para dar soporte a transacciones extremo a extremo, con confirmación. Junto con un número de secuencia se almacena la última
petición o respuesta, para poder reenviarlos cuando expira el temporizador.
51
2.3. ESTÁNDARES DE COMUNICACIÓN
tabla de encaminamiento
Para cada destino pueden existir más de una entrada en esta tabla,
con un identificador de grafo diferente.
Basándose en la información de enlace provista por cada nodo, el administrador de red crea el grafo total de la red, siguiendo las siguientes reglas
en el orden en que se enumeran:
1. minimizar la cantidad de saltos
2. encaminar a través de dispositivos conectados a la red eléctrica si es
posible
3. utilizar la intensidad de señal para seleccionar las mejores rutas
4. utilizar una combinación de intensidades de señal ponderadas para
seleccionar entre rutas alternativas
5. podar la cantidad de vecinos a 4 nodos o menos
Luego de crear el grafo total, el administrador crea un grafo que describe
rutas desde cada dispositivo hasta el gateway, un grafo de broadcast desde el
gateway hasta cada dispositivo, grafos desde el gateway a cada dispositivo
individualmente. El administrador de red asigna ranuras de tiempo a cada
dispositivo de acuerdo con los grafos derivados.
Comparación con ZigBee
Los principales argumentos en contra de la utilización de ZigBee para
aplicaciones industriales son [35]:
ZigBee utiliza un único canal, lo que lo hace muy susceptible a interferencias intencionales o no. La grave atenuación selectiva de frecuencia
debido al ambiente rico en metales propio de las plantas podrı́a, potencialmente, detener toda comunicación. El canal único aumentará la
interferencia con otros sistemas, tales como una red local inalámbrica,
y aumentará el retardo al crecer la red, además de producirse una mayor cantidad de colisiones y retransmisiones. En este sentido, WirelessHART es más robusto, ya que utiliza saltos de frecuencia y retransmisiones en diferente frecuencia para reducir los efectos de interferencias.
ZigBee no mantiene diversidad de rutas, si se rompe un enlace, se debe
establecer una nueva ruta de origen a destino, produciendo retardos y
52
CAPÍTULO 2. REDES INALÁMBRICAS DE SENSORES
costos indirectos, y el descubrimiento de ruta puede llegar a consumir
todo el ancho de banda en ambientes con rutas inestables. El encaminamiento por grafo de WirelessHART provee la redundancia de ruta
que permite reducir los efectos de enlaces rotos.
Los encaminadores ZigBee con muchos vecinos deben mantener el receptor encendido durante una gran parte del superframe, en la fase
CAP por utilizar CSMA/CA. En cambio, los dispositivos WirelessHART solo mantienen la radio encendida durante las ranuras de tiempo asignadas.
Aún con las caracterı́sticas de robustez y confiabilidad mencionadas de
WirelessHART para aplicaciones industriales, en [35] se sugiere su utilización
en procesos lentos y no crı́ticos.
53
2.3. ESTÁNDARES DE COMUNICACIÓN
54
Capı́tulo 3
Protocolos de red
3.1.
Problema del encaminamiento
Uno de los principales desafı́os de diseño en WSNs es la comunicación
de datos intentando al mismo tiempo prolongar la vida útil de la red, empleando técnicas agresivas de administración de energı́a. En [10] se resumen
algunas cuestiones de diseño que afectan el proceso del encaminamiento:
Despliegue
El despliegue de los nodos depende de la aplicación y afecta el desempeño del protocolo. Cuando el despliegue es determinı́stico, los datos
se encaminan a través de rutas predefinidas. Cuando es al azar, la estructura de red se crea ad hoc y probablemente las rutas se compongan
de múltiples saltos de enlaces inalámbricos.
Conservación de energı́a
Los nodos sólo cuentan con su limitado suministro de energı́a para
procesar y comunicar datos en un ambiente inalámbrico, por lo que se
deben buscar maneras de optimizar esas actividades.
Modelo de reporte de datos
El sensado y reporte de datos depende de la aplicación y sus requerimientos temporales, y pueden clasificarse en continuos, por evento,
por consulta o hı́bridos. En el modelo continuo, los sensores sensan y
transmiten periódicamente. En los modelos de reporte por evento y
por consulta, los sensores reaccionan a un cambio drástico y repentino
del valor sensado por haber ocurrido un evento, o para responder a una
consulta iniciada por la estación base. El protocolo de encaminamiento
está fuertemente influido por el modelo requerido.
Heterogeneidad de nodos o enlaces
Los nodos pueden ser homogéneos en capacidad o pueden diferir in55
3.1. PROBLEMA DEL ENCAMINAMIENTO
cluso en el rol. Por ejemplo, una aplicación puede requerir una combinación de diversos sensores para monitorear temperatura, presión y
humedad del ambiente, detectando movimiento con señales acústicas,
y capturando video de objetos en movimiento. Los sensores pueden
ser desplegados independientemente, o las diferentes funcionalidades
pueden ser incluidas en los mismos nodos sensores.
Tolerancia a fallas
Cuando los nodos fallan, por falta de energı́a, daño fı́sico o interferencia, no deberı́an afectar el funcionamiento de la red. Los protocolos
de acceso al medio y encaminamiento deben formar nuevos enlaces
y rutas al sumidero, lo que puede requerir el ajuste de la intensidad
de transmisión y el encaminamiento de paquetes a regiones de la red
de mayor energı́a. Pueden requerirse múltiples niveles de redundancia
dependiendo de los requerimientos de tolerancia a fallas.
Escalabilidad
La cantidad de nodos sensores desplegados en una determinada área
puede ser del orden de los cientos o miles. El esquema de encaminamiento debe ser capaz de operar con una gran cantidad de nodos.
Movilidad
Muchas arquitecturas asumen nodos estacionarios, pero algunas aplicaciones requieren nodos y sumideros móviles. Cuando hay movilidad,
la estabilidad de la ruta presenta mayor desafı́o.
Canal de transmisión
Los problemas tradicionales de un canal inalámbrico, atenuación y alta
tasa de errores, también afectan a las redes de sensores. En general el
ancho de banda requerido es bajo.
Conectividad
Por la gran densidad de nodos se espera que la red esté altamente
conectada, aunque habrá cambios de topologı́a debido a fallas en los
nodos.
Cobertura
Cada nodo obtiene una cierta vista del ambiente, limitada en alcance
y exactitud.
Agregación de datos
Dado que los nodos pueden generar una cantidad importante de información redundante, la agregación de datos permite reducir la cantidad
de transmisiones. La agregación es la combinación de diferentes fuentes de acuerdo a una cierta función, por ejemplo, mı́nimo, promedio,
56
CAPÍTULO 3. PROTOCOLOS DE RED
máximo. Algunos métodos de procesamiento de señales se pueden utilizar para combinar señales y reducir su ruido, técnica que se conoce
como fusión de datos.
Calidad de servicio
Algunas aplicaciones tienen requerimientos temporales y de latencia.
Sin embargo, en muchas otras, la conservación de energı́a, relacionada
con la vida útil de la red, es considerada mucho más importante que la
calidad de servicio. Para cumplimentar este requerimiento se requieren
protocolos conscientes de la energı́a.
En la literatura y artı́culos de investigación se pueden encontrar varias
maneras de clasificar protocolos para redes inalámbricas de sensores, según
las premisas de diseño con que se definen y los problemas que intentan
resolver. Cada paradigma a menudo se describe respondiendo a las siguientes
preguntas:
¿Qué modelo de red y tipo de aplicación asume?
¿Cómo se elige el siguiente nodo en la ruta?
¿Qué fases de operación tiene?
¿Qué cuestiones resuelve?
¿Cuáles son sus desventajas?
Asimismo, se han propuesto protocolos que no son exclusivos de un paradigma, sino que aplican más de una técnica, combinándolas de manera
conveniente para algún tipo de aplicación. Es por ello que, al analizar un
protocolo, probablemente el mismo pertenezca a más de una categorı́a.
A continuación, se describirán tres de los paradigmas más mencionados
en las taxonomı́as analizadas [36][11][5][10][25][22].
3.2.
3.2.1.
Encaminamiento jerárquico
Caracterı́sticas
Los algoritmos de esta clase se caracterizan por establecer una topologı́a
de red jerárquica. La jerarquı́a virtual se construye dividiendo la red en
niveles, utilizando un criterio conveniente, por ejemplo, por funcionalidad o
por ubicación de los nodos [36]. En la figura 3.1 se esquematiza esta división.
El objetivo de la misma es reducir la carga que se produce en el sumidero
si se utiliza una topologı́a plana y la densidad de nodos es muy alta, ya que
57
3.2. ENCAMINAMIENTO JERÁRQUICO
cada dato sensado se comunicarı́a directamente a la estación base. Además,
en general, los nodos no tienen un alcance de radio muy largo como para
poder llegar al sumidero en un área muy amplia [11]. En una jerarquı́a, los
nodos colaboran dentro de un clúster para transmitir los datos, utilizando
un esquema multi-salto, permitiendo hacer un uso más eficiente de la energı́a
disponible. Ocasionalmente se aprovecha la topologı́a para utilizar también
la técnica de fusión o agregación de datos, y el rol de cabecera o de fusionador
puede ser asignado dentro del clúster teniendo en cuenta el nivel de residual
de energı́a que posee el nodo.
Figura 3.1: Jerarquı́a virtual en una red de sensores
Este tipo de protocolos es adecuado para aplicaciones que requieren un
tráfico periódico, donde todos los sensores se encuentran sensando el ambiente a una tasa de tiempo fija, por lo que continuamente se genera información
a ser enviada a la estación base o sumidero. También existen algoritmos
dentro de este paradigma especialmente diseñados para aplicaciones de detección de eventos [11]. El mantenimiento de la topologı́a de red tiene un
costo indirecto asociado, pero esta misma jerarquı́a permite reducir el tráfico
de mensajes de control para el cálculo de rutas, lo que implica un ahorro
de energı́a. Es recomendable utilizar esta técnica en aplicaciones en donde
se despliega una gran cantidad de nodos y se requiere escalabilidad, ya que
en general la jerarquı́a se construye dinámicamente, y puede extenderse o
adaptarse.
58
CAPÍTULO 3. PROTOCOLOS DE RED
El paradigma frecuentemente se ilustra presentando el algoritmo LEACH
(Low Energy Adaptive Clustering Hierarchy), aunque haya sido propuesto
hace ya 10 años.
3.2.2.
LEACH
Introducción
LEACH es un protocolo que propone el uso de clústeres de nodos permitiendo distribuir el consumo de energı́a de manera más uniforme entre los
sensores de la red. Se caracteriza por hacer rotar al azar el rol de cabecera de
clúster. Dentro de un clúster, la cabecera coordina localmente la transmisión
y fusión de datos para comprimir la información luego transmitida directamente a la estación base [37], reduciendo el ancho de banda requerido. La
topologı́a resultante se esquematiza en la figura 3.2 (obtenida de [4]).
Figura 3.2: Topologı́a de red en LEACH
Modelo de red
El modelo de red para el cual se desarrolla LEACH comprende cientos o
miles de nodos sensores económicos y eficientes en términos de energı́a. Los
nodos son homogéneos y se encuentran restringidos en cuanto a la duración
de la baterı́a. La calidad de de la información se mejora con la utilización
de un gran número de nodos. Una estación base fija recibe la información
sensada en lugares distantes.
59
3.2. ENCAMINAMIENTO JERÁRQUICO
Fases de operación
LEACH opera en rondas. Cada ronda consta de las siguientes cuatro
fases:
1. Anuncio
Al comienzo, cada clúster decide si se vuelve cabecera dependiendo del
porcentaje de cabeceras que debe tener la red (definido a priori) y el
número de veces que el nodo ya ha tenido el rol. Cada nodo que se elige
a sı́ mismo como cabecera, hace broadcast del anuncio al resto de los
nodos, utilizando CSMA. Los nodos que no son cabecera mantienen
su radio encendida, y elijen su cabecera sobre la base de la fuerza de
la señal recibida de los anuncios que escuchan (eligen la cabecera cuya
señal se recibe con mayor intensidad, porque es la que estarı́a más
cerca).
2. Armado del clúster
Los nodos eligen la cabecera que requiere la menor energı́a de transmisión e informan a la cabecera seleccionada que se harán miembro
del clúster usando el protocolo CSMA.
3. Planificación del canal
Una vez que la cabecera recibe todos los mensajes de nodos miembros,
crea un schedule TDMA asignando un perı́odo de tiempo de transmisión a cada nodo y lo informa a los nodos haciendo broadcast.
4. Transmisión de datos
Cada nodo envı́a la información durante la franja de tiempo de transmisión que le fue asignada. Mientras el nodo no está transmitiendo,
puede apagar su radio. Cuando el nodo cabecera recibe los datos de
todos los nodos del clúster, puede combinarlos para comprimir la señal
que se enviará a la estación base en una transmisión de alta energı́a.
Luego de un determinado tiempo de transmisión, comienza una nueva
ronda. Para minimizar el costo indirecto asociado al mantenimiento
de la jerarquı́a, la fase de transmisión es mucho más larga que la de
armado de clústeres.
Rotación al azar de la cabecera de clúster
A partir del análisis de primer orden del modelo de radio que se realiza en [37], para determinados parámetros de radio, los protocolos deben
intentar reducir las distancias de transmisión, pero también la cantidad de
operaciones de transmisión y recepción por cada mensaje.
Si todos los nodos se comunican directamente con la estación base, se requerirá una gran cantidad de energı́a de transmisión. Por otro lado, si todos los
nodos intentan transmitir a la más baja energı́a posible, es decir, al nodo
60
CAPÍTULO 3. PROTOCOLOS DE RED
vecino más cercano, la suma de la energı́a consumida en cada salto puede
terminar siendo mayor que la empleada en la transmisión directa. Cuando
la energı́a de transmisión es del mismo orden que la de recepción, la transmisión directa es más eficiente a escala global. Pero debe aclararse que de
utilizarse transmisión directa, los nodos más distantes de la estación base
morirán primero (por ejemplo, en la figura 3.1, los nodos en el nivel n).
Asimismo, con un encaminamiento de energı́a mı́nima, son los nodos más
cercanos a la estación base los que se agotan primero, porque encaminan
datos provenientes de todos los otros nodos de la red (en la figura 3.1, los
nodos en el nivel 0).
Sobre la base del análisis anterior, se propone agrupar nodos en clústeres,
de manera que los nodos que no son cabecera no están muy distanciados de
ella, y emplean menos energı́a de la necesaria para transmitir directamente
a la estación base. Como el nodo que tiene rol de cabecera sı́ realiza transmisiones de alta energı́a a la base, LEACH introduce la rotación del rol al
azar.
Cada nodo decide si toma el rol de cabecera o no en la ronda n eligiendo
un valor al azar entre 0 y 1. Si el valor es menor a un umbral U (n), el nodo
se vuelve cabecera. En [37] se muestra que existe una porcentaje óptimo
de cabeceras P, tal que se reduce al mı́nimo posible la energı́a disipada en
la transmisión. Para LEACH, P es 0.05, es decir, en una ronda, el 5 % de
los nodos es cabecera. Entonces, se necesitan al menos P1 = 20 rondas para
que todos los nodos tengan el rol de cabecera una vez. El umbral U (n) se
define de manera que en la ronda 0 tiene valor P, y el valor se incrementa
hasta llegar a 1 en la ronda P1 − 1. Pero una vez que el nodo tomó el rol, no
podrá volver a tomarlo por P1 rondas.
Problemas que resuelve
LEACH es un algoritmo distribuido y no requiere coordinación de la
estación base ni conocimiento global de la topologı́a de red. Es eficiente al
distribuir el consumo de energı́a de manera uniforme a lo largo de la red,
lo que incrementa la vida útil de la misma. Dado que las cabeceras pueden
comprimir o fusionar los datos recibidos de los nodos locales, contribuye a
reducir el tráfico global.
Desventajas
En su primera versión, la probabilidad de tomar el rol de cabecera no
tiene en cuenta la energı́a residual en el nodo. Además, la comunicación de
cabecera a estación base es de salto-único [11], lo cual en realidad es una
limitación, ya que en áreas amplias puede que el alcance de la radio no sea
suficiente.
61
3.3. ENCAMINAMIENTO GEOGRÁFICO
3.3.
3.3.1.
Encaminamiento geográfico
Caracterı́sticas
A este paradigma pertenecen los algoritmos que utilizan una posición
geográfica o coordenada, real o virtual, para encaminar datos hacia un punto en la red, seleccionando como siguiente nodo al vecino que más cerca
esté del destino [36], minimizando la distancia restante que se debe recorrer
[22]. En aplicaciones de recolección de datos por demanda, la coordenada
permite difundir una consulta a una determinada región de la red, los nodos que no están en la región de interés descartan el mensaje, reduciendo
ası́ tráfico innecesario [11]. Este tipo de algoritmos permite utilizar tablas
de encaminamiento más pequeñas, porque la coordenada geográfica tiene
implı́cita la información sobre a qué nodo debe enviarse el mensaje para
encaminarlo al destino.
Figura 3.3: Encaminamiento geográfico
En la figura 3.3 (obtenida de [22]) se esquematiza cómo el encaminamiento básico selecciona cada vez, de manera ávida, el nodo más cercano al
punto de destino. En el ejemplo, el camino seleccionado desde la estación
base comprende los nodos c, f, g y nodo destino. En la figura puede observarse una importante deficiencia: si se ignora la topologı́a, la ruta seleccionada
puede no ser la más corta en saltos [22].
Otro problema para el cual se han propuesto numerosas soluciones es el del
camino sin salida. En la figura 3.4 (obtenida de [22]), se muestra que aunque
la estación base tiene conectividad con el nodo destino, si se utiliza el algoritmo ávido, el mensaje llega al nodo situado a menor distancia restante,
pero a partir de allı́ el obstáculo impide que el encaminamiento progrese,
porque no hay conectividad con ningún otro nodo más cercano a la posición
final.
62
CAPÍTULO 3. PROTOCOLOS DE RED
Una solución intuitiva al problema del camino sin salida es utilizar la regla
de la mano derecha para escapar del laberinto. Si se detecta que un mensaje
no puede progresar, se lo encamina rodeando la cara definida por los nodos
alrededor del obstáculo, usando la regla de la mano derecha. Aun ası́, no es
trivial determinar a partir de qué momento conviene pasar del modo ávido
al modo perimetral.
Figura 3.4: Encaminamiento geográfico en presencia de obstáculos
El sistema de localización es un requisito para poder realizar encaminamiento geográfico. En algunas taxonomı́as [36][11], dentro del paradigma se
enumeran protocolos que asumen nodos con capacidades de posicionamiento
muy variadas, donde el nodo:
Es consciente de su posición y no se aclara qué sistema de localización
utiliza
Calcula una posición virtual dentro de un sistema de coordenadas
Utiliza un sistema de GPS impreciso
Utiliza un sistema de GPS de bajo consumo
En la mayorı́a de los casos, los nodos sensores no cuentan con GPS,
debido a sus limitaciones de recursos y energı́a inherentes [25][4], por lo que
existe un conjunto de técnicas de triangulación que permiten al nodo conocer
su posición. En [38] se propone un algoritmo de encaminamiento geográfico
basado en coordenadas virtuales, que no requiere conocer la posición real de
los nodos de la red.
El encaminamiento geográfico es escalable, los nodos sólo deben mantener el estado de sus vecinos [38] (no global) y se soporta la comunicación any
63
3.3. ENCAMINAMIENTO GEOGRÁFICO
to any sin ser necesario establecer la ruta. Este tipo de protocolos es adecuado para aplicaciones en donde la estación base inicia consultas dirigidas
a un subconjunto de nodos, o una región en el espacio en particular[25].
3.3.2.
Por coordenadas virtuales
Introducción
El encaminamiento geográfico requiere que los nodos conozcan su posición. Como se ha mencionado anteriormente, existen muchas configuraciones
en donde la información de posición no está disponible. El protocolo presentado en [38] hace foco en la asignación de coordenadas virtuales a los nodos
de la red, para utilizar un esquema de encaminamiento geográfico estándar.
No es necesario que estas coordenadas virtuales sean representaciones exactas de la geografı́a de los nodos, mientras reflejen la conectividad entre los
nodos, en particular la conectividad local o entre nodos vecinos, como se
explicará más adelante [38]. En el encaminamiento geográfico por coordenadas virtuales, los paquetes de red son encaminados de manera ávida. De la
tabla de encaminamiento, siempre se reenvı́a al nodo que esté más cerca del
destino, y que también está más cerca del destino que el nodo actual. Si el
nodo actual es el más cercano al destino, y la capa superior determina que
en efecto el paquete debe ser entregado al nodo actual, entonces se considera que el paquete ha llegado a destino. Pero si el paquete no ha llegado a
destino y no puede progresar en forma ávida, se ha llegado a un punto sin
salida, por lo que el nodo ejecuta el algoritmo expanding ring search o ERS
hasta encontrar un nodo más cerca del destino.
Modelo de red
El modelo de red del trabajo original consta de miles de nodos, y una
densidad media, donde cada nodo tiene 16 vecinos [38].
Fases de operación
Arranque (Bootstrap)
El arranque comprende 4 pasos.
1. Descubrimiento de nodos perı́metro
Dos nodos predeterminados como baliza (beacon nodes) inundan la red
con mensajes HELLO. El mensaje contiene un contador de saltos que
se incrementa en cada nodo que lo reenvı́a. Al recibirlo, cada nodo
descubre su distancia en saltos a cada nodo baliza, siendo esta el menor valor de contador de entre todos los mensajes recibidos. Entonces,
64
CAPÍTULO 3. PROTOCOLOS DE RED
una vez determinada la distancia a la baliza, los nodos deciden si son
perimetrales utilizando el criterio del nodo de perı́metro. Si el nodo
es el más alejado del beacon, de entre todos sus vecinos a dos saltos,
entonces está en el perı́metro.
2. Vector perı́metro
Cada nodo perimetral inunda la red para permitir al resto de los nodos calcular su vector perı́metro, es decir, la distancia a cada nodo
perimetral.
3. Coordenadas normalizadas
Cada nodo perı́metro y baliza inunda la red con sus propios vectores
perı́metro. El resto de los nodos utilizan este vector para normalizar
las coordenadas propias y de los nodos perı́metros. Luego, los nodos
perı́metro proyectan las coordenadas en un circulo exterior.
4. Relajación de coordenadas
Los nodos perı́metro quedan ahora fijos, mientras todos los otros nodos
ejecutan el algoritmo de ajuste de coordenadas.
Régimen (Steady State)
Una vez completo el arranque, uno de los nodos beacon inunda periódicamente la red, cada 50 segundos, con mensajes HELLO. De esta manera,
los nodos descubren su distancia a cada beacon y cada nodo decide si es un
nodo perimetral o no, utilizando el criterio del nodo de perı́metro. Periódicamente también, cada nodo hace broadcast de la lista de sus vecinos a dos
saltos, dentro del área de alcance de su radio. Si un nodo no recibe el latido
de un vecino por tres intervalos, lo elimina de su lista de vecinos.
Normalización de coordenadas
En la normalización de coordenadas, todos los nodos calculan las coordenadas virtuales normalizadas de los nodos perı́metro. El proceso se realiza
en dos pasos. A partir de la recepción de los vectores perı́metro, primero se
triangulan coordenadas iniciales, y luego se normalizan con respecto a un
eje de coordenadas definido por los nodos baliza.
1. Triangulación
Al recibir los vectores perı́metro, cada nodo perimetral conoce las distancias entre cada par de nodos perı́metro. Dichos valores se utilizan
en un algoritmo de triangulación para calcular las coordenadas iniciales. El algoritmo define las coordenadas de manera de minimizar la
diferencia entre la distancia en saltos y la distancia euclı́dea entre cada
nodo perimetral.
65
3.3. ENCAMINAMIENTO GEOGRÁFICO
P
minimizar{
(H(i, j) − D(i, j))2 }
i,jperámetro
H es la distancia en saltos entre el nodo i y el nodo j
D es la distancia euclı́dea entre las coordenadas virtuales del nodo i y j
Esto significa que las coordenadas virtuales deben conservar las relaciones de distancia entre los nodos.
Figura 3.5: Nodos perı́metro
Para simplificar, por ejemplo, supongamos que sólo se descubren tres
nodos de perı́metro en una red como la de la figura 3.5, P1, P2 y P3,
y sus respectivos vectores perı́metro son los siguientes:
P 1 = (0, 2, 3)
P 2 = (2, 0, 3)
P 3 = (3, 3, 0)
Entonces, la triangulación trata de minimizar la siguiente suma:
p
2
2 )2
( 2 − (xp
1 − x2 ) + (y1 − y2 )
+ ( 3 − p(x1 − x3 )2 + (y1 − y3 )2
+ ( 3 − (x2 − x3 )2 + (y2 − y3 )2
)2
)2
Como los nodos que no están en el perı́metro igual reciben el broadcast
de vectores perı́metro, utilizan el mismo algoritmo de triangulación
66
CAPÍTULO 3. PROTOCOLOS DE RED
para calcular sus propias coordenadas iniciales normalizadas.
2. Normalización
Cualquier las coordenadas de cualquier conjunto que minimice las suma de la sección anterior pueden ser rotadas y trasladadas, y aún
ası́ continuar satisfaciendo la condición. Por lo anterior, las coordenadas iniciales se normalizan de manera que todos los nodos lleguen a
obtener los mismos valores. La normalización se realiza con respecto
un nuevo eje de coordenadas, que se forma a partir del centro de gravedad de las posiciones de los nodos perı́metro y baliza. Desde el centro
de gravedad, la posición de una baliza define el eje de ordenadas, y la
posición de la otra, el eje de abscisas. Si bien el cálculo no se muestra
en [38], se deduce lo expuesto a continuación.
Supongamos que tenemos las siguientes coordenadas iniciales para n
nodos perı́metro:
Pn = (xn , yn )
Entonces, el centro de gravedad, o mejor dicho, el centroide del conjunto finito de estos n puntos en <2 es:
P
(xn ,yn )
(c, d) =
n
n
Luego, para normalizar las coordenadas (x, y) del nodo perı́metro P1 ,
se calcula (x0 , y 0 ), realizando un cambio de base, de la base canónica a
la base definida por b01 = (xb1 , yb1 ) − (c, d) y b02y = (xb2 , yb2 ) − (c, d):
(xb1 , yb1 ) = coordenadas del nodo baliza 1
(xb2 , yb2 ) = coordenadas del nodo baliza 2
0
B =
xb1 − c xb2 − c
yb1 − d yb2 − d
0
(x, y) − (c, d) = B ·
x’
y’
Se lleva el centro de gravedad al origen, y las nuevas coordenadas
se calculan para los ejes definidos por el centro de gravedad y las
posiciones de los dos nodos baliza.
67
3.3. ENCAMINAMIENTO GEOGRÁFICO
Luego de la triangulación, los nodos perı́metro proyectan sus coordenadas en un cı́rculo con origen en el centro de gravedad los nodos
perı́metro, y radio igual a la distancia promedio de los nodos perı́metro al centro de gravedad calculado. Esta técnica permite mantener un
sistema de coordenadas consistente en presencia de fallas en los nodos
o movilidad [38].
Relajación de coordenadas
En este paso los nodos que no están en el perı́metro ajustan sus coordenadas virtuales, en unas pocas iteraciones de cálculo, partiendo de las
coordenadas iniciales normalizadas, y las coordenadas de los nodos perı́metro proyectadas en un cı́rculo, cuyo radio es igual a la distancia promedio de
estos nodos al centro de gravedad. Puede hacerse una analogı́a del proceso
con la teorı́a de grafos embebidos, donde cada enlace (arista) representa una
fuerza que trata de unir los nodos vecinos.
P
xi =
P
xk
kVi
|Vi |
yi =
yk
kVi
|Vi |
Vi es el conjunto de vecinos del nodo i
|Vi | es la cantidad de vecinos del nodo i
En cada iteración, el nodo ordinario actualiza sus coordenadas virtuales,
x e y, con el promedio del valor de coordenada de sus vecinos. Las coordenadas de los nodos perı́metro quedan fijas. En [38] se muestra que luego de
unas pocas iteraciones (del orden de 10), las coordenadas convergen a tasas
de encaminamiento exitoso muy altas.
Conceptualmente, la relajación produce que todos los nodos que no están
en el perı́metro, pero que tienen un nodo perı́metro entre sus vecinos, se
muevan hacia el nodo perı́metro más cercano en términos de cantidad de
saltos.
Problemas que resuelve
En presencia de obstáculos o agujeros, se encontró que el encaminamiento ávido tiene mejor desempeño al utilizar coordenadas virtuales, porque
ellas reflejan mejor la conectividad de la red que las posiciones reales [38].
Por ejemplo, si bien en coordenadas geográficas reales un nodo puede estar
muy cercano a otro, ambos pueden estar desconectados o fuera de alcance
debido a la presencia de algún obstáculo, como puede verse en la figura 3.3.
El algoritmo es escalable, porque luego de la fase de arranque, el costo de
mantenimiento en cantidad de mensajes, si bien no es despreciable, es independiente del tamaño de la red.
68
CAPÍTULO 3. PROTOCOLOS DE RED
Desventajas
En [38] sugiere como desventaja que en régimen, el algoritmo tiene un
costo indirecto asociado bastante alto debido a que todos los nodos inundan
periódicamente la red.
3.4.
3.4.1.
Encaminamiento centrado en los datos
Caracterı́sticas
En aplicaciones en las se instala una gran cantidad de nodos sensores,
puede no ser posible asignar un identificador o dirección global, porque su
mantenimiento genera un costo indirecto elevado. Sucede también que la
información generada por sensores instalados en una misma región, puede
contener redundancias que producen tráfico innecesario[11]. Ası́, este paradigma propone dos técnicas clave para mejorar las cuestiones expuestas:
un esquema de direccionamiento basado en propiedades o atributos de la
información y la posibilidad de agregar o fusionar datos eliminando redundancias.
En esta clase de protocolos el encaminamiento se inicia con una consulta
realizada por alguno de los nodos. Lo que se direcciona no es un nodo de la
red, sino la información misma, a través de algún atributo que posea (por
ejemplo, la ubicación geográfica en donde se generó), utilizando consultas
[36]. Se han dado diferentes definiciones y nombres al encaminamiento centrado en datos [5][10][25], y en todas se lo caracteriza , de alguna manera,
como basado en el contenido que se transmite. Un paquete se envı́a a un
determinado nodo o es descartado, dependiendo de la información que contiene.
Este tipo de protocolos es adecuado para aplicaciones de detección de
eventos, como por ejemplo, detección de incendios forestales, contaminación.
La técnica de direccionamiento por atributos no es apropiada para aplicaciones de monitoreo (reporte periódico), ya que en este tipo de aplicación
se requiere un tráfico continuo de datos. Ello implica tener que consultar la
misma información periódicamente, y la búsqueda de coincidencias entre la
consulta y los datos disponibles acarrea un costo indirecto [11] que puede
evitarse por diseño.
El paradigma también se ha propuesto como adecuado para aplicaciones que
requieren consultas orientadas a eventos, ya que las mismas sólo involucran
una parte de la red a la vez, el tráfico es eventual por lo que conviene reducir al mı́nimo el costo de direccionamiento y mantenimiento de rutas. La
utilización de agregación de datos permitirı́a en cierta manera minimizar la
probabilidad de obtener falsas alarmas en la detección de eventos.
69
3.4. ENCAMINAMIENTO CENTRADO EN LOS DATOS
EAD (Enery-Aware Data-Centric Routing) [39] es un algoritmo que pertenece a este grupo, ya que implementa la técnica de agregación de datos.
3.4.2.
Energy-Aware Data-Centric Routing
Introducción
El protocolo se basa en que el mayor consumo de baterı́a es realizado por
el tranceptor, que consume casi lo mismo al enviar, recibir o en estado ocioso.
Para ahorrar energı́a, el mismo debe simplemente apagarse. Sin embargo,
un nodo dormido no puede retransmitir mensajes, por lo que no se pueden
apagar todos los tranceptores al mismo tiempo. EAD propone construir una
columna vertebral de nodos activos que permita realizar un encaminamiento
consciente de la energı́a.
Modelo de red
El modelo de red para el que se plantea EAD está compuesto por cientos
o miles de nodos sensores instalados al azar en el área de sensado, y una
estación base o gateway que conecta la red con el exterior y se encuentra en
los lı́mites del área de instalación, de manera de ser alcanzada por algunos
sensores [39].
Heurı́stica de construcción de la columna
El objetivo de la columna vertebral de nodos es que exista un camino
activo que permita hacer llegar el dato desde el nodo sensor en donde se
origina hasta el sumidero. Mientras un nodo forme parte de la columna,
estará activo, con su radio encendida. Un nodo que no forme parte de la
columna, puede apagarse periódicamente, y ahorrar energı́a. Entonces, es
conveniente construir la columna vertebral con la menor cantidad de nodos
activos posibles, o dicho de otro modo, construir con los nodos un árbol
recubridor con el máximo número de nodos hoja y cuya raı́z sea el nodo
sumidero. Este problema es equivalente a construir un conjunto dominanteconexo que es NP-Completo, para lo que en [39] se propone una heurı́stica
distribuida que permite construir un árbol recubridor de nodos, teniendo en
cuenta los niveles residuales de energı́a.
En la figura 3.6 se esquematiza el algoritmo de cambio de estado del nodo EAD. La columna se construye mediante el envı́o de mensajes de control
que contienen 4 valores:
Estado
Puede ser 0 (indefinido), 1 (nodo hoja) ó 2 (nodo de columna)
70
CAPÍTULO 3. PROTOCOLOS DE RED
Figura 3.6: Máquina de estados del nodo EAD
Nivel
El nivel dentro del árbol cuya raı́z es el nodo sumidero
Padre
El siguiente nodo, en el camino al sumidero
Energı́a
Energı́a residual que posee el nodo
Al comenzar, todos los nodos se encuentran en estado 0 y el sumidero
(la raı́z) hace broadcast de la tupla (2, 0, N U LL, ∞), donde ∞ indica que el
emisor es el sumidero.
Como se esquematiza en la figura 3.7, cuando un nodo v en estado indefinido
recibe el mensaje (2, nivelu , padreu , Eu ) de un nodo de columna u:
1. v se vuelve nodo hoja
2. sensa el canal hasta que esté ocioso
71
3.4. ENCAMINAMIENTO CENTRADO EN LOS DATOS
3. espera por T2v
4. si el canal sigue ocioso, v hace broadcast del mensaje (1, nivelv +
1, u, Ev )
Figura 3.7: De estado indefinido a estado hoja
Cuando un nodo v en estado indefinido recibe el mensaje (1, nivelu , padreu , Eu )
de un nodo hoja u:
1. v se vuelve nodo columna
2. sensa el canal hasta que esté ocioso
3. espera por T1v
4. si el canal está todavı́a ocioso, v hace broadcast del mensaje (2, nivelu +
1, u, Ev )
5. todos los nodos vecinos de v en estado indefinido se vuelven nodos
hoja
72
CAPÍTULO 3. PROTOCOLOS DE RED
Mientras el nodo v espera T1 o T2 , si el canal es ocupado, el nodo vuelve
a sensar hasta que el canal esté ocioso.
Cuando un nodo v hoja recibe un mensaje (2, nivelu , v, Ew ) de un nodo
w columna, lo que indica que v es padre de w:
1. v hace broadcast del mensaje (2, nivelv , padrev , Ev ) apenas el canal
está ocioso (sin esperar)
El proceso continua hasta que todos los nodos definen su estado. Si un
nodo no descubre ningún hijo, automáticamente se vuelve nodo columna.
Los tiempos de espera, T1v y T2v , se calculan localmente y de modo que los
nodos con la mayor cantidad de energı́a residual hagan broadcast primero,
por lo que se definen inversamente proporcional a Ev .
Encaminamiento centrado en datos
EAD intenta reducir y descartar información redundante, utilizando
agregación de datos en cada nodo que no es hoja a lo largo de la ruta.
Cada nodo no-hoja combina los datos producidos en todos los nodos en el
sub-árbol del cual es raı́z, empleando alguna función de agregación (suma,
promedio, media, máximo, etc.). De este modo, un paquete de información
puede cambiar su contenido durante su recorrido desde un nodo hoja, pasando por nodos intermedios hasta alcanzar la raı́z del árbol.
Figura 3.8: Ejemplo de agregación de datos camino al sumidero
Incluso dos o más paquetes pueden ser fusionados o agregados en un
único paquete que sigue la ruta al sumidero, como puede observarse en el
ejemplo de la figura 3.8 (obtenida de [39]), donde la función de agregación
obtiene el máximo valor.
73
3.5. DISEMINACIÓN DE INTERÉS
Fases de operación
EAD opera en rondas. La ronda consta de las siguientes dos fases:
1. Inicialización
Durante esta fase se ejecuta el algoritmo EAD y se construye la columna vertebral de la red.
2. Transmisión
En esta fase se transmiten los datos al sumidero.
En cada ronda, al ejecutarse la inicialización, los nodos que no estén
activos ya no serán agregados, y los nodos que han quedado huérfanos son
reincorporados al árbol.
Problemas que resuelve
EAD permite ahorrar energı́a apagando el tranceptor de los nodos que
no pertenecen a la columna de transmisión, extendiendo la vida de la red.
Asimismo, los nodos en columna agregan los datos recibidos de sus hojas,
descartando información redundante para reducir tráfico innecesario.
Desventajas
Para redes de sensores de gran escala, la ejecución de EAD puede necesitar mucho tiempo para propagarse a toda la red. En [39] se proponen dos
enfoques para limitar la ejecución del algoritmo a un subconjunto de nodos
de la red. Sucede también que sólo los nodos más cercanos al sumidero serán
elegidos como gateways, lo que eventualmente conduce al particionamiento
de la red [40].
3.5.
3.5.1.
Diseminación de interés
Caracterı́sticas
Como ya se ha dicho, dentro del paradigma de protocolos centrados en
datos, se clasifican aquellos que direccionan la información por atributos de
la misma, en lugar de direccionar el dispositivo fı́sico en donde fue generada.
En esencia, la identidad del nodo que genera la información, o la del nodo
que recolectará los datos es irrelevante [22]. El flujo de la información queda
determinado por el interés especı́fico del receptor en lugar de la dirección
del emisor [41].
El paradigma que naturalmente se ajusta a ese patrón de interacción
es el de publisher/subscriber, donde todos los nodos están conectados a un
software bus, en el cual se publican datos notificados a aquellos nodos que
74
CAPÍTULO 3. PROTOCOLOS DE RED
previamente se han suscripto como interesados en esos datos [22].
El flooding o inundación es una técnica utilizada a menudo para diseminar información, que se basa en un enfoque reactivo donde cada nodo
que recibe un paquete lo reenvı́a a todos sus vecinos. Es económico en un
sentido, no hay descubrimiento y mantenimiento de rutas, ya que se asume
una topologı́a de red plana [4].
La diseminación de interés es una técnica que surge a partir del análisis
de las falencias del flooding. El desempeño de los algoritmos basados en
inundación empeora rápidamente a medida que crece el tamaño de la red
[4]. En la literatura se mencionan tres efectos no deseados [42]:
Implosión de tráfico
Como un nodo siempre envı́a el paquete recibido a sus vecinos, sin
importar si alguno ya lo recibió, cuando un nodo recibe más de una
copia de un paquete, ello significa que se han desperdiciado recursos
en transmisiones redundantes. El problema se ilustra en la figura 3.9
(obtenida de [42]). En (1) el nodo a envı́a el paquete DATA1 a sus
vecinos, b y c. En (2) el nodo b envı́a el paquete recibido DATA1 a su
vecino, d. En (3) el nodo c también envı́a DATA1 al nodo d. El nodo
d recibe dos veces el mismo paquete.
Superposición
Los nodos a menudo sensan áreas geográficas que se superponen. Cuando inundan a sus vecinos con los datos sensados, si dos nodos cercanos
poseen un vecino común, éste puede recibir la información por duplicado. Como puede verse en la figura 3.10 (obtenida de [42]), tanto el
nodo a como el nodo b sensan la zona 3, y por lo tanto, al inundar a
su vecino común, el nodo c, éste recibe la información de la zona 3 por
duplicado. Este problema es más difı́cil de resolver que la implosión,
porque no solo depende de la topologı́a de la red, sino también del
mapeo del dato sensado a los nodos.
Ceguera de recursos
Los nodos no modifican su actividad según la cantidad de energı́a disponible que poseen, produciendo un uso poco eficiente de los recursos
de la red.
Ası́, para optimizar el tráfico, en varios protocolos propuestos tempranamente para redes de sensores [18][42], la diseminación se apoya en un
direccionamiento basado en atributos. El tráfico se negocia por medio del
intercambio de meta-datos, o descriptores de alto nivel de la información
disponible [42]. La diseminación de interés es un caso especial de la diseminación. Permite implementar consultas a la red, donde por ejemplo, un
sumidero inicia una petición que especifica la información de interés por
75
3.5. DISEMINACIÓN DE INTERÉS
Figura 3.9: Implosión
Figura 3.10: Superposición
medio de atributos de la misma. La petición se propaga por la red y posteriormente cuando un nodo dispone de información que cumple con los
atributos, los datos se encaminan hacia el sumidero que originó la consulta.
En la literatura a menudo se ilustra el paradigma centrado en datos
con dos enfoques populares para la diseminación de información, Directed
Diffussion y SPIN[43]. Directed Diffussion disemina consultas de datos a
demanda y está orientado a aplicaciones de consulta de datos frecuente.
SPIN es un protocolo conducido por eventos, orientado a aplicaciones de
consulta única (one-shot query) [22], y se describe en la siguiente sección
[25]. En [44][45] también se menciona a Fireworks, un protocolo que disemina
interés o consultas en forma probabilı́stica.
76
CAPÍTULO 3. PROTOCOLOS DE RED
3.5.2.
SPIN
Introducción
Para poder superar las deficiencias del flooding clásico (implosión, superposición y ceguera de recursos) , SPIN (Sensor Protocols for Information
via Negotiation) incorpora dos técnicas innovadoras en su momento [42]:
Negociación
Para evitar la implosión y la superposición, los nodos negocian entre
sı́ la transmisión de los datos, utilizando meta-datos para describir la
información disponible.
Adaptación a los recursos
Cada nodo dispone de un administrador de recursos que mantiene
registro del consumo de recursos. Cuando la energı́a es baja, el nodo
se abstiene de participar de ciertas actividades, por ejemplo, el reenvı́o
de información de terceros.
SPIN es diseñado sobre la base de dos ideas clave. Primeramente, si bien
intercambiar la información sensada puede ser una actividad costosa, intercambiar información sobre la información sensada no necesariamente lo es.
En segundo lugar, los nodos deben adaptarse a cambios en su disponibilidad
de recursos para extender su vida útil y la de la red. Sus autores establecen
que se toman mejores decisiones de encaminamiento si se utilizan conocimientos sobre los datos de la aplicación y el estado de los recursos en cada
nodo, además de la topologı́a de red [42].
Modelo de red
SPIN asume una topologı́a de red plana, donde cualquier nodo sensor
puede cumplir el rol de sumidero. Asimismo, cualquier nodo puede ser fuente
de datos, es decir, genera información sensando el medio ambiente, y esta
información debe ser diseminada a toda la red. El tamaño del dato que
genera el nodo sensor es relativamente grande [22].
Operación
Meta-datos sobre la información sensada
SPIN no establece el formato que debe tener el meta-dato de la información generada. Sin embargo, se asume lo siguiente [42]:
Si x es el meta-dato descriptor del dato X, entonces el tamaño de x
en bytes es mucho menor que el tamaño de X
Si dos datos son distinguibles, entonces sus meta-datos también lo son
77
3.5. DISEMINACIÓN DE INTERÉS
De la misma manera, si dos datos son indistinguibles, entonces tienen
la misma meta-representación (el mismo meta-dato)
La ventaja de contar con una representación sucinta de los datos supera ampliamente el costo de almacenar, recuperar y mantener metadatos
Son interesantes los dos ejemplos de meta-datos que se mencionan en
[42]:
Si los sensores cubren regiones geográficas que no se superponen, el
meta-dato puede ser su identificador único
Un sensor cámara podrı́a llegar a usar como meta-dato una coordenada
de tipo (x, y, P hi) donde (x, y) es una coordenada geográfica, y P hi
es la orientación
Negociación
Los nodos SPIN se comunican utilizando 3 tipos de mensajes [46]:
ADV
Aviso o anuncio de nuevos datos. Cuando un nodo dispone de nueva información, puede notificarlo transmitiendo un mensaje ADV que
contiene meta-datos.
REQ
Petición de datos. Se utiliza para indicar que se desea recibir la nueva
información.
DATA
Mensaje de datos. Un mensaje DATA contiene la información propiamente dicha, encabezada por el meta-dato.
En [46] se presentan 4 protocolos SPIN, el más básico de ellos SPIN-PP
(SPIN point-to-point) permite ilustrar el modelo de negociación. SPIN-PP
se diseña optimizado para una red teórica que utiliza un medio de transmisión punto a punto, asumiendo que es posible que dos nodos A y B se
comuniquen exclusivamente uno con el otro, sin interferir la comunicación
con otros nodos. Bajo esta hipótesis, el costo de comunicación es lineal (comunicarse con n vecinos, es n veces el costo de comunicarse con un vecino).
SPIN-PP trabaja en tres etapas, cada una de las cuales corresponde a
uno de los mensajes descriptos anteriormente:
78
CAPÍTULO 3. PROTOCOLOS DE RED
Anuncio
El protocolo comienza cuando un nodo anuncia que dispone de nuevos
datos para diseminar, enviando un mensaje ADV que contiene el metadato de la información generada.
Petición
Cuando un nodo vecino recibe un mensaje ADV, determina si ya ha
recibido el mensaje o si ha requerido la información que describe el
meta-dato. En caso negativo, responde enviando un mensaje REQ pidiendo la información.
Datos
El protocolo se completa cuando el nodo que lo inició responde el
mensaje REQ con un mensaje DATA que contiene la información propiamente dicha.
La ronda de negociación se ilustra en las figuras 3.11, 3.12, 3.13, obtenidas del trabajo original [42]. Observando la figura 3.11, la negociación
comienza en 1), donde el nodo a anuncia que dispone de nuevos datos. En
2) el nodo b solicita la transmisión de la información nueva. Luego, en la
figura 3.12, en 3) el nodo a transmite la información propiamente dicha al
nodo b, encabezada por el meta-dato. En 4) el nodo b anuncia a sus vecinos
que dispone de nuevos datos. Por último, en la figura 3.13, en 5) los nodos
c y e solicitan la transmisión de los nuevos datos de b. Finalmente en 6) El
nodo b transmite los datos a los nodos que lo han solicitado.
Figura 3.11: Negociación SPIN pasos 1 y 2
79
3.5. DISEMINACIÓN DE INTERÉS
Figura 3.12: Negociación SPIN pasos 3 y 4
Figura 3.13: Negociación SPIN pasos 5 y 6
Es importante aclarar que el protocolo no requiere que todos los nodos
respondan a todos los mensajes. Por ejemplo, un nodo no enviará un mensaje
REQ si ya dispone de la información que se anuncia en el mensaje ADV
recibido.
80
CAPÍTULO 3. PROTOCOLOS DE RED
SPIN-EC
SPIN-EC[46] agrega lógica de conservación de energı́a bastante simple a
SPIN-PP. Cuando un nodo observa que su energı́a residual se aproxima a un
umbral inferior de carga de baterı́a, reduce su participación en el protocolo.
Si el nodo recibe un dato nuevo, sólo iniciará la ronda de negociación si puede
completar las tres etapas (anunciar y responder la petición). De la misma
manera, si recibe un anuncio, sólo enviará la petición si tiene suficiente
energı́a para recibir el dato.
SPIN-BC
SPIN-BC[46] es una versión de SPIN que agrega optimizaciones para
cuando se utiliza un canal de transmisión compartido. Cuando un nodo
envı́a un mensaje, éste es recibido por todos los nodos dentro del rango de
alcance de la radio, sin importar el destino original de mensaje.
Supresión de peticiones
En SPIN-BC todos los nodos envı́an a la dirección de broadcast. Si algún
nodo A dentro del rango del nodo B requiere el dato, bastarı́a con la petición
de A para que todos los nodos en el rango reciban el dato. Si A direcciona la
petición a B, todos los nodos en el rango sobreescuchan la petición. Entonces, un nodo C que también requiere el dato, se abstiene de enviar también
su petición, es decir, suprime la petición. Ası́, cuando un nodo recibe un
mensaje ADV, revisa si ya recibió o solicitó el dato. Si no lo hizo, establece
un temporizador que expira en un tiempo al azar, elegido de manera uniforme en un intervalo predeterminado. Al expirar el temporizador el nodo envı́a
un mensaje REQ a la dirección de broadcast especificando en la cabecera la
dirección del nodo que originalmente anunció el dato. Cuando otros nodos
reciben el mensaje REQ, cancelan sus propios temporizadores y suprimen
su petición redundante.
Otra diferencia importante es que el nodo que recibe peticiones de datos
responderá la información a la dirección de broadcast una única vez.
SPIN-RL
SPIN-RL [46] es una versión confiable de SPIN-BC.
Repetición de pedidos
En SPIN-RL cada nodo mantiene registro de todos los anuncios recibidos.
Si no recibe el dato transcurrido un cierto periodo de tiempo posterior al
pedido enviado o suprimido, el nodo vuelve a pedir el dato. En la cabecera
81
3.6. CONSCIENCIA DE LA ENERGÍA
del pedido indica como nodo origen cualquier vecino que haya anunciado el
dato.
Limite de reenvı́o de datos
Si un nodo envı́a un dato, luego espera una cantidad de tiempo predefinida
antes de volver a enviar el mismo dato.
Si no hay confiabilidad en el enlace, y un anuncio se pierde, el protocolo
no garantiza la completa difusión de los datos.
Problemas que resuelve
Una de las ventajas de SPIN es que los cambios en la topologı́a de la red
son localizados ya que un nodo sólo necesita conocer a sus vecinos [11].
Desventajas
No todos los protocolos o heurı́sticas de diseminación son confiables. Por
ejemplo, SPIN no garantiza la entrega de datos, ya que si un nodo interesado
en determinados datos se encuentra muy lejos de la fuente, y los nodos
intermedios no tienen el mismo interés, la información no será entregada
[11].
3.6.
3.6.1.
Consciencia de la energı́a
Introducción
Una de las limitaciones fundamentales de las redes de sensores es la
capacidad de baterı́a. En [14] se plantea que en las redes móviles y ad hoc
los protocolos se diseñan con el objetivo de minimizar la cantidad de saltos
que atraviesa un paquete. A diferencia de estas redes, en WSN es crucial
minimizar el consumo de energı́a empleado para la tarea de encaminamiento,
o resolver el problema del encaminamiento de menor energı́a [12] a partir de
diferentes enfoques de diseño, que se manifiestan en las métricas de energı́a
utilizadas.
En los trabajos analizados, especialmente los que presentan una taxonomı́a de algoritmos, la técnica de dar consciencia de la energı́a al encaminamiento no aparece como un paradigma en sı́ misma, sino que, la eficiencia
en términos de energı́a se busca utilizando técnicas adicionales. El empleo
de métricas de energı́a en el encaminamiento no siempre aparece en el diseño
de protocolos que buscan eficientizar el uso de energı́a.
Por ejemplo, en el caso de LEACH, el rol de cabecera dentro de un cluster de nodos es el que mayor consumo de transmisión tiene, por reenviar a
82
CAPÍTULO 3. PROTOCOLOS DE RED
la estación base, la cual no pertenece al cluster y está a mayor distancia que
los nodos locales. Este rol es rotado sobre la base de la energı́a residual que
el nodo posee. Aquéllos nodos que tengan mayor energı́a disponible, tendrán
más oportunidades de ser cabecera y entonces, el tráfico fluirá a la estación
base siempre a través de los nodos con mayor energı́a residual.
En el caso de EAD, que como LEACH es un protocolo jerárquico, el nivel de
energı́a residual se utiliza de manera que los nodos con más energı́a tengan
mayor probabilidad de ser los nodos de la columna vertebral de transmisión
que el protocolo construye. Nuevamente, la información fluye a través de los
nodos que poseen mayor energı́a
En cambio, con los protocolos de encaminamiento geográfico, al encaminar
de manera ávida, la eficiencia se intenta lograr de manera más indirecta. Al
buscar rutas que utilicen la menor cantidad de saltos, se disminuye la cantidad de reenvı́os de un paquete, y con ello, la energı́a de transmisión utilizada.
3.6.2.
Métricas de energı́a
En [47] se presentan varias métricas de diseño que permiten construir
rutas eficientes en términos de energı́a, y que aparecen muy frecuentemente
en los protocolos para redes de sensores:
1. Minimizar la energı́a total de la ruta
Con el enfoque de energı́a total mı́nima o MTE (Minimum Total
Energy), se busca minimizar la energı́a de transmisión y recepción
total consumida por un paquete para alcanzar el destino. Sucede que
si todo el tráfico se encamina a través de las rutas más económicas, los
nodos en esa ruta se agotan rápidamente, particionando la red [12],
por lo que no se recomienda utilizar esta métrica en forma aislada.
2. Maximizar el tiempo hasta que la red se particiona
Se determinan los nodos que al ser removidos causan particiones, y se
trata de balancear la carga sobre los mismos.
3. Uniformizar el consumo de energı́a
Se parte de la hipótesis de que todos los nodos son igualmente importantes, y se intenta asegurar que todos los nodos funcionen juntos
la mayor cantidad de tiempo, que la carga sea balanceada entre todos. Por ejemplo, utilizando rutas compuestas por los nodos de mayor
energı́a residual, evitando los nodos de menor capacidad restante, posponiendo al máximo posible la muerte del primer nodo. En [14] se
aclara que aunque todos los nodos de la red funcionen en conjunto la
mayor cantidad de tiempo posible, ello no implica que la utilización
de la energı́a disponible será óptima. Una red densa podrı́a operar
83
3.6. CONSCIENCIA DE LA ENERGÍA
efectivamente durante más tiempo sin el total de los nodos desplegados inicialmente, recuperando información con los nodos que queden
activos.
4. Minimizar el costo por paquete
Se seleccionan las rutas de menor costo total, que equivale a la suma
de los costos de cada enlace que se utiliza. Si se define adecuadamente
el costo del enlace, puede utilizarse la métrica con diferentes objetivos.
Por ejemplo, si el costo depende de la energı́a residual, puede lograrse
aumentar el tiempo hasta el particionamiento de la red.
Ahora bien, en el material de investigación analizado se hallaron varios
algoritmos que utilizan alguna de las métricas mencionadas en la decisión
de encaminamiento. Algunos de ellos [48][49] no fueron desarrollados para
WSN, sino para redes ad hoc. Otros fueron diseñados especı́ficamente para
redes de sensores:
SPIN (Sensor Protocols for Information via Negotiation)
SPIN es una familia de protocolos [4] basados en la negociación para
la diseminación de información. SPIN-EC es una variante que limita
la participación del nodo en la secuencia de negociación según el nivel
de energı́a que posee. Podrı́a decirse que utiliza una métrica de tipo
4, ya que un nodo es reluctante a participar del encaminamiento si su
energı́a está por debajo de un nivel umbral [42].
FA (Flow Augmentation)
Modifica periódicamente el tráfico dirigido a un nodo según el costo del
enlace. Un enlace menos costoso es aquel que requiere menos energı́a
de transmisión y aquel en donde el nodo destino posee una mayor cantidad de energı́a residual [12]. Este costo es una métrica de tipos 1 y
4.
MIR (Maximum Information Routing )
Define el costo del enlace a partir de una métrica de cantidad de información que el nodo contribuye, penalizando el costo de aquellos nodos
que más información generan, para evitar que sean incluidos frecuentemente en la ruta [14]. Este algoritmo utiliza una métrica de tipo 4.
Keep Connected
Define el costo del enlace a partir de la cantidad de componentes conexas que resultarı́an si el nodo agota su energı́a y muere. Aquel nodo
84
CAPÍTULO 3. PROTOCOLOS DE RED
que al morir, produce una mayor cantidad de particiones es más importante y debe evitarse incluirlo en la ruta [13]. Este algoritmo utiliza
una métrica de tipo 2.
EBTA-WSN (Energy-Balanced Transmission Algorithm)
Selecciona la ruta de menor costo total de transmisión, utilizando nodos cuya energı́a residual está por encima del promedio de la red [9],
es decir, utiliza una métrica de tipos 1 y 4.
Flow Augmentation, propuesto en [12] incluye en su diseño el objetivo
de maximizar la vida útil de la red.
3.6.3.
Flow Augmentation
Introducción
El algoritmo de aumentación de flujo propuesto en [12] es un encaminamiento de camino más corto, donde el costo del enlace es una combinación
del consumo de energı́a de transmisión y recepción, y los niveles de energı́a
residual en los dos nodos extremos. En el trabajo se calcula la solución óptima teórica al problema de maximizar la vida de la red, planteado como un
problema de programación lineal, y atacando el problema equivalente de
maximizar la cantidad de información transferida para una tasa de generación de datos constante. La solución óptima se compara con la heurı́stica
diseñada. La heurı́stica consiste en calcular la ruta de menor costo. En lugar de utilizar como costo eij la energı́a consumida cuando se transmite el
eij
paquete por el enlace ij, se utiliza REi1−eij y RE
, donde REi es la energı́a rei
sidual del nodo i. Mediante el algoritmo de camino más corto Bellman-Ford
distribuido, se halla la ruta de menor costo [11].
Modelo de red y tipo de aplicación
El modelo de red asume un conjunto de nodos estáticos, desplegados al
azar, y cuya energı́a es empleada mayormente en la transmisión y recepción de datos. Los nodos generan información que debe ser entregada a un
conjunto de nodos gateway, siendo posiblemente encaminada a través de
múltiples saltos. En [50] se analizan dos escenarios o tipos de aplicación.
En un escenario se asume una tasa de generación de información constante,
como sucede con el tipo de aplicación de reporte periódico de datos. En un
segundo escenario, un objetivo atraviesa la región de despliegue haciendo
que los sensores que lo detectan generen cierta cantidad de información por
segundo, lo que corresponde al tipo de aplicación de seguimiento.
85
3.6. CONSCIENCIA DE LA ENERGÍA
Costo del enlace
Se elige el nombre Aumentación de Flujo porque el algoritmo aumenta
o disminuye el tráfico dirigido a un nodo, según el costo actualizado del enlace a utilizar. Como el costo del enlace se define en función de la energı́a
de transmisión, pero también en función de la energı́a residual del nodo a
utilizar, el efecto es que al comienzo, cuando todos los nodos disponen de
energı́a, se encamina minimizando la energı́a total consumida por la ruta.
A medida que la energı́a residual disminuye, el algoritmo trata de evitar los
nodos que dispongan de la menor cantidad de energı́a.
El costo del enlace se define como:
x
costoij = (eij t ) 1 · REi −x2 · IEi x3 + (eij r )x1 · REj −x2 · IEj x3
etij es la energı́a de transmisión consumida al utilizar el enlace (i,j)
erij es la energı́a de recepción consumida al utilizar el enlace (i,j)
IEi y IEj son las energı́as iniciales en los nodos i, j respectivamente
REi y REj son las energı́as residuales
x1 , x2 y x3 son factores de peso que permiten variar la manera en que
se considera el nivel de energı́a residual
Ası́,
IEi
REi
IEj
REj
IEi
REi
+
IEj
REj
se logra utilizando x1 = 0 y x2 = x3 = 1.
es el inverso de energı́a residual en i, relativa al total.
es el inverso de energı́a residual en j, relativa al total.
De esta manera, a menor energı́a residual, mayor es el costo del enlace.
Fases de operación
En [12] no se menciona una fase de arranque, sino únicamente un régimen
que comprende varios pasos ejecutados en forma iterativa. En cada iteración:
commodity: un conjunto de nodos fuente y nodos destino
1. Cada nodo origen calcula la ruta más económica para cada nodo destino que pertenece al commodity c
2. Si algún commodity no puede hallar una ruta a su destino, entonces
parar.
86
CAPÍTULO 3. PROTOCOLOS DE RED
3. Aumentar el flujo en cada ruta de menor costo
Las rutas de menor costo serán utilizadas hasta la próxima iteración.
Como se asume una tasa constante de generación de información, puede conocerse la cantidad de información enviada en cada iteración
4. Actualizar los valores de energı́a residual
Dado que se conoce la cantidad de información transmitida en cada
iteración, puede conocerse también la cantidad de energı́a consumida
y valor de energı́a residual resultante
Aunque los resultados de simulaciones muestran que el algoritmo tiene
un desempeño cercano al óptimo, la mayorı́a de las veces, tanto para tasas
de generación de información fijas como para un escenario de detección de
un objetivo en movimiento, el desempeño del algoritmo depende las rutas
de generación de información.
Figura 3.14: Desempeño no óptimo de FA
Por ejemplo, consideremos la red de la figura 3.14 (obtenida de [12]),
donde cada nodo posee cuatro unidades de energı́a, y se requiere una unidad
de energı́a para transmitir un paquete, utilizando cualquier enlace. Si el
nodo b genera cuatro paquetes de información (Qb = 4), el algoritmo los
divide entre los nodos d y e, empleando dos unidades de energı́a en cada
nodo. Luego, el nodo a genera ocho paquetes de información (Qa = 8), y
el algoritmo los divide entre los nodos c y d, pero la energı́a en esos nodos
ahora no es suficiente y quedan dos paquetes de información sin entregar.
Fácilmente puede verse que si los paquetes de b sólo se encaminaran a través
de e, podrı́a entregarse toda la información generada.
Desventajas
En [12] se aclara que el protocolo no es escalable ni aplicable a grandes
redes debido a las limitaciones inherentes al encaminamiento dirigido por tablas. Cabe señalar que esta restricción surge de la topologı́a planteada, cada
87
3.6. CONSCIENCIA DE LA ENERGÍA
nodo debe mantener las rutas más económicas actualizadas hacia múltiples
destinos (gateways). De igual manera, si se requiere soportar la comunicación de peticiones de la estación base a un conjunto de nodos, cada nodo
deberá mantener el costo de las rutas en tablas que crecerán en proporción
a la densidad de la red.
88
Capı́tulo 4
Diseño de la simulación con
Omnet++
4.1.
4.1.1.
¿Qué es Omnet++?
Introducción
Omnet++ es una herramienta de simulación de redes, de eventos discretos, modular y orientada a objetos. Su arquitectura genérica ha permitido que sea utilizada para estudiar problemas de diversos dominios, entre
ellos, el modelado de redes de comunicación inalámbrica y protocolos. La
herramienta no es un simulador de algo en particular, sino que provee la
infraestructura para escribir simulaciones. Los modelos son ensamblados a
partir de componentes reutilizables llamados módulos. Los módulos se comunican entre sı́ por medio del pasaje de mensajes a través de compuertas
y conexiones, o directamente. Los módulos pueden tener parámetros para
personalizar su comportamiento o parametrizar la topologı́a del modelo de
red.
Al nivel más bajo de la jerarquı́a de módulos se tienen los módulos simples
que encapsulan el comportamiento, se programan en C++ utilizando la librerı́a de simulación.
Las simulaciones pueden correrse en varios tipos de ambiente. El ambiente
gráfico animado es útil para demostraciones y depuración. El ambiente de
lı́nea de comandos es mejor para ejecución por lotes.
La herramienta completa es probada en los sistemas operativos más comunes (Linux, MAC OS/X y Windows), y también soporta simulaciones en
paralelo distribuidas. Para este trabajo no se utilizó esta funcionalidad, y
las simulaciones corrieron en una única computadora con Windows 7. Omnet++ es gratis para uso académico y sin fines de lucro [51], y OMNEST es
su versión comercial.
89
4.1. ¿QUÉ ES OMNET++?
4.1.2.
Conceptos de modelado
Un modelo de Omnet++ consiste de módulos que se comunican a través
del pasaje de mensajes.
Los módulos que actúan se llaman módulos simples y se escriben en C++
utilizando la librerı́a de simulación. A su vez, los módulos simples pueden
agruparse en módulos compuestos, creando una jerarquı́a. El modelo completo se llama red y es un modelo compuesto.
Los mensajes son enviados por conexiones que comunican los módulos,
y pueden contener cualquier información. Tı́picamente, son enviados por
módulos simples a través de compuertas. Las compuertas son las interfaces
de entrada y salida de los módulos: los mensajes se envı́an a través de compuertas de salida y llegan por compuertas de entrada. Una compuerta de
entrada y una compuerta de salida se enlazan por una conexión. Se pueden
definir tipos de conexión con propiedades especı́ficas (retardo de propagación, tasa de transferencia, tasa de errores de bit), modelando un canal.
4.1.3.
Descripción de red
La estructura del modelo de simulación se describe con el lenguaje NED
(Network Description). Con este lenguaje se declaran módulos simples y
módulos compuestos. Un módulo compuesto puede ser etiquetado como red,
es decir, como modelo de simulación auto-contenido. Por ejemplo, se puede
definir una red compuesta por nodos encaminadores, donde en cada nodo
hay una aplicación corriendo, que genera paquetes de datos transmitidos a
través de un canal (ver figura 4.1, obtenida del manual de la herramienta
[51]).
90
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
Figura 4.1: Vista de diseño de una red Omnet++
El nodo es un módulo compuesto por los submódulos que modelan la
aplicación y el encaminamiento (capa fı́sica, acceso al medio y capa de red).
La figura 4.2 es la vista de diseño de un nodo MiXiM (ver sección 4.2.1).
Figura 4.2: Diseño del nodo como módulo compuesto
91
4.1. ¿QUÉ ES OMNET++?
4.1.4.
Conceptos de simulación
Como ya se ha dicho, los módulos que actúan se llaman módulos simples
y se escriben en C++ utilizando la librerı́a de simulación. Los siguientes
conceptos de simulación de eventos discretos permiten entender como se
diseñan los módulos simples.
Simulación de eventos discretos
Un sistema de eventos discretos es aquel en el que los cambios de estados
suceden en tiempo discreto, y el evento emplea cero cantidad de tiempo en
suceder. Se asume que nada interesante sucede entre dos eventos consecutivos, es decir, no se produce ningún cambio de estado. Este tipo de sistema
puede ser modelado usando simulación de eventos discretos.
El tiempo en el que el evento ocurre se llama marca de tiempo y en
Omnet++ se llama tiempo de llegada (ya que en la biblioteca de clases la
palabra marca de tiempo esta reservada para un atributo asignable en la
clase evento).
El tiempo en el modelo se llama tiempo de simulación, tiempo de modelo
o tiempo virtual en oposición al tiempo real, que se refiere al tiempo durante
el cual el programa ha estado corriendo, o el tiempo de CPU que se refiere
a cuánto tiempo de CPU ha consumido.
Eventos
En Omnet++ los eventos son representados por mensajes, es decir, por
una instancia de la clase cMessage o una subclase de ésta. Los mensajes
son enviados desde un módulo a otro, lo que significa que el lugar donde
“el evento ocurre” es en el módulo destino, y el tiempo de modelo en el que
ocurre es el tiempo de llegada del mensaje. Los eventos se consumen en el
orden que da el tiempo de llegada. Si el tiempo de llegada es el mismo, el
orden lo da la prioridad del mensaje. Si la prioridad es la misma, el orden
es aleatorio.
El ciclo de eventos
La simulación de eventos discretos mantiene una lista de eventos futuros
en una estructura comúnmente llamada FES (Future Event Set). En Omnet++ se implementa como un montı́culo binario, la estructura de datos
más utilizada para este propósito.
El simulador trabaja de acuerdo al pseudocódigo del algoritmo 1.
El paso de inicialización construye las estructuras de datos que representan el modelo a simular, ejecuta el código de inicialización que se ha
redefinido, e inserta eventos iniciales en la lista de eventos futuros. El bucle subsiguiente consume eventos de la lista y los procesa. Los eventos se
92
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
Algoritmo 1: Ciclo de evento
1
2
3
4
5
6
7
inicializar (construye el modelo e inserta eventos iniciales)
while FES no vacı́a Y simulación no completa do
obtener primer evento de FES
t := marca de tiempo de este evento
procesar evento (inserta nuevos eventos o borra eventos de FES)
end
terminar simulación (escribir resultados estadı́sticos, etc.)
procesan en orden estricto dado por la marca de tiempo, para mantener la
causalidad. Procesar eventos involucra la invocación de código provisto por
el módulo creado. La simulación se detiene cuando no hay más eventos o
cuando se alcanza el lı́mite de tiempo de modelo o CPU. En ese momento, antes de terminar la ejecución, generalmente se graban estadı́sticas en
archivos de salida.
93
4.1. ¿QUÉ ES OMNET++?
4.1.5.
Ambiente de desarrollo
El IDE (ambiente integrado de desarrollo) de Omnet++ está basado en
la plataforma Eclipse [52], y la extiende con editores, vistas y asistentes. Este
IDE provee una Perspectiva de Simulación (figura 4.3) para trabajar con los
tipos de archivo de Omnet++, que deben ser incluidos en un proyecto de
simulación.
Figura 4.3: Perspectiva de Simulación de Omnet++ en Eclipse
4.1.6.
Definición de un módulo simple
Como se ha dicho, la simulación ejecuta módulos simples. Un módulo
simple es una clase C++ que debe extender de una clase módulo simple
de base, y redefinir su comportamiento. La clase debe registrarse con Omnet++.
Los módulos simples son instanciados por el kernel de simulación, por
ello la firma del constructor debe tener una forma predefinida. Debe seguirse
la siguiente convención de inicialización y finalización:
constructor
El constructor es invocado para crear el módulo, como parte de la
94
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
inicialización del módulo propiamente dicho. En ese momento, todo el
modelo esta siendo construido por lo que no pueden hacerse muchas
cosas desde el constructor. Por convención, en el constructor se asignan
todas las variables puntero de la clase del módulo a NULL.
inicializador
El método initialize() es invocado justo antes de comenzar la ejecución
de la simulación, cuando todo el modelo está listo. Por convención, en
el método initialize() se realizan todas las tareas de inicialización: leer
parámetros, inizalizar variables, reservar memoria, crear e inicializar
timers.
destructor
El destructor siempre se llama al final, sin importar cómo terminó la
simulación. Se puede asumir que, en ese momento, el modelo de simulación está casi destruido por completo. Por convención en el destructor
se libera la memoria reservada, se eliminan los temporizadores creados
(con la función cancelAndDelete(msg)).
finalizador
El método finalize() sirve para grabar estadı́sticas. Solamente se invoca
cuando la simulación ha terminado normalmente. Si la simulación se
detiene por error, no será invocado. Por convención, en este método se
graban estadı́sticas, y no se deben liberar objectos ni ejecutar
tareas de limpieza.
Para definir el comportamiento dinámico del módulo simple, se debe redefinir el método handleMessage, invocado con un mensaje como parámetro cada vez que el módulo recibe un mensaje. Se espera que el método
procese el mensaje, y retorne. Durante la ejecución de este método no
transcurre tiempo de simulación, sólo entre llamadas. La idea es que con
cada evento (llegada de mensaje) se invoca una función definida en el módulo. Dentro de la función pueden utilizarse otras funciones predefinidas para
enviar mensajes a otros módulos, programar un evento (enviar un mensaje
a sı́ mismo), y borrar un evento programado. Los modelos de capas de protocolos tienden a compartir una estructura similar, porque reaccionan a tres
tipos de eventos fundamentales: mensajes que llegan de capas superiores (la
aplicación), mensajes que llegan de capas inferiores (la red) y varios temporizadores (auto-mensajes).
Generalmente, surge el patrón de modelado que se ilustra en el fragmento de código 4.1:
95
4.1. ¿QUÉ ES OMNET++?
Fragmento de código 4.1: Modelo de protocolo de capa
1
2
3
4
5
6
7
8
9
10
11
class FooProtocol: public cSimpleModule
{
protected:
//state variables
//...
virtual void processMsgFromHigherLayer(cMessage *packet);
virtual void processMsgFromLowerLayer(FooPacket *packet);
virtual void processTimer(cMessage *timer);
virtual void initialize();
virtual void handleMessage(cMessage *msg);
};
96
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
4.1.7.
Simulación
Una vez que se han escrito los fuentes se compila el proyecto obteniendo
un ejecutable. La simulación se realiza corriendo el ejecutable generado, y
puede ser lanzada desde el IDE. Para ello, se define una configuración de
ejecución, especificando algunos detalles como (ver figura 4.4):
directorio de trabajo
es el directorio base del cual dependen otras configuraciones
ejecutable
la ruta del ejecutable de la simulación, relativa al directorio del espacio de trabajo
archivos de inicialización
archivos que contienen conguraciones de parámetros modificables de
la red y los módulos
Figura 4.4: Configuración de ejecución en Omnet++
4.1.8.
Herramientas de análisis
Gráficos de secuencia
Un archivo de log de eventos contiene la bitácora de mensajes enviados
durante la simulación, y el detalle de eventos disparados por su envı́o o recepción, incluyendo mensajes enviados entre módulos y temporizadores. Se
puede controlar qué módulos graban en el log, la cantidad de datos que se
97
4.1. ¿QUÉ ES OMNET++?
graban, el comienzo y fin de la grabación. Los gráficos de secuencia despliegan el archivo de log en forma gráfica, permitiendo visualizar la causalidad
de los eventos. El log de eventos también se puede visualizar en forma tabular. Los eventos pueden ser filtrados por diferentes criterios, incluyendo por
módulo, tipo de mensaje y por relación de causalidad. La figura 4.5 es un
fragmento de secuencia de las simulaciones del protocolo SPIN.
Figura 4.5: Gráfico de secuencia en Omnet++
Análisis de resultados
Los resultados de la simulación son grabados como escalares, vectores e
histogramas. Luego, pueden aplicarse métodos estadı́sticos para extraer información relevante y obtener una conclusión. En el proceso generalmente se
filtran y transforman datos. Desde la versión 4 de Omnet++, la herramienta
de análisis estadı́stico se ha integrado a Eclipse. Los filtros y transformaciones de datos se graban en archivos de análisis que permiten reproducir
instantáneamente el post-proceso sobre resultados de nuevas corridas. Con
el editor de análisis de Eclipse se navegan los vectores y escalares, se definen
datasets a partir de expresiones de filtro, y estos se despliegan en gráficos
98
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
de barras, curvas, histogramas y de dispersión. En la figura 4.6 se muestra
la solapa de navegación de resultados, donde se han filtrado los escalares
para visualizar solamente la tasa de éxito de cada simulación. Luego, en la
figura 4.7 se presenta la tasa de buen éxito en un gráfico de barras.
Figura 4.6: Navegador de vectores y escalares en Omnet++
Figura 4.7: Gráfico de barras en Omnet++
99
4.2. DISEÑO DE LA RED
Desempeño
Omnet++ ha sido comparado con NS2 y se han recogido métricas que
indican que emplea menos memoria y un menor tiempo de ejecución [53][54].
También se ha evaluado la exactitud de los resultados obtenidos con Omnet++ en simulaciones de WSN[55], observándose que cuanto mayor es la
frecuencia de muestreo, la cantidad de eventos que debe manejar el nodo
aumenta fuertemente. A una frecuencia de muestreo de 5 ms, los resultados de las simulaciones muestran una distancia significativa respecto de los
resultados obtenidos en un campo de pruebas real. A partir de una frecuencia de 50 ms, esta distancia es menos evidente, y a partir de los 500 ms es
despreciable.
4.2.
Diseño de la red
4.2.1.
MiXiM 2.1
MiXiM [56] es un framework de modelado para Omnet++, creado para redes inalámbricas fijas y móviles (redes inalámbricas de sensores, redes
de área corporal, redes vehiculares, etc). Ofrece modelos detallados de propagación de ondas, estimación de interferencias, consumo del tranceptor, y
protocolos de acceso al medio.
Una red MiXiM básica se compone de los siguientes elementos:
módulo de definición de la red
módulo de definición del host
módulo de interfaz de red, que define la placa de red del host
la configuración de la capa fı́sica, modelo analógico (cálculo de atenuación) y decider (clasificación de ruido y cálculo de errores de bit).
la configuración de la simulación
La figura 4.2 en la sección 4.1.3 es la vista de diseño de un nodo MiXiM.
Fragmento de código 4.2: Definición de red
1
2
3
4
5
6
7
8
network WSNRouting {
parameters:
// x size of the area the nodes are in (in meters)
double playgroundSizeX @unit(m);
// y size of the area the nodes are in (in meters)
double playgroundSizeY @unit(m);
// z size of the area the nodes are in (in meters)
double playgroundSizeZ @unit(m);
100
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
double numHosts; // total number of hosts in the network
9
10
submodules:
world: BaseWorldUtility {
parameters:
playgroundSizeX = playgroundSizeX;
playgroundSizeY = playgroundSizeY;
playgroundSizeZ = playgroundSizeZ;
@display("p=0,0;i=misc/globe");
11
12
13
14
15
16
17
18
}
connectionManager: ConnectionManager {
}
19
20
21
22
node[numHosts]: Host802154_2400MHz {
parameters:
numHosts = numHosts;
}
23
24
25
26
27
connections allowunconnected:
28
29
}
En la definición de red 4.2 se incluyen parámetros de definición de las
dimensiones del terreno, los submódulos de utilidad global y de administración de conexiones, y el tipo de host que compone la red.
El administrador de conexiones verifica si dos hosts pueden oı́rse uno al
otro y actualiza sus conexiones de acuerdo a eso. Si dos hosts están conectados significa que pueden recibir algo de cada uno, pero no significa que
pueden entenderse. Si dos hosts no están conectados, están fuera del rango
de interferencia y no recibirán ninguna señal uno del otro.
Es muy importante diferenciar el rango de interferencia del modelo de
comportamiento de la radio. El rango de interferencia define la distancia a
partir de la cual un nodo alejado deja de existir para el tranceptor. El modelo
analógico y el decider, junto con los parámetros del módulo de interfaz de
red, determinan la intensidad de señal combinada y si un frame es recibido
o no.
El decider y los modelos analógicos se definen con un archivo xml que
configura parámetros propios. En el módulo de interfaz se debe especificar
qué archivo contiene esta configuración.
Fragmento de código 4.3: Configuración del decider
1
2
3
4
5
<?xml version="1.0" encoding="UTF-8"?>
<root>
<AnalogueModels>
<AnalogueModel type="BreakpointPathlossModel">
<!-- IEEE 802.15.4 path loss channel model -->
101
4.2. DISEÑO DE LA RED
6
7
8
9
10
11
12
13
14
15
16
17
18
<parameter name="alpha1" type="double" value="2"/>
<parameter name="L01" type="double" value="40.2"/>
<parameter name="breakpointDistance" type="double" value="8.0"/>
<parameter name="alpha2" type="double" value="3.3"/>
<parameter name="L02" type="double" value="58.8"/>
<parameter name="carrierFrequency" type="double" value="2.4E+9"/>
</AnalogueModel>
</AnalogueModels>
<Decider type="Decider802154Narrow">
<!--Length of Start Frame Delimiter
(used to compute probability of successful
synchronization)-->
<parameter name="sfdLength" type="long" value="8"/>
19
<!--minimum possible bit error rate (BER floor)-->
<parameter name="berLowerBound" type="double" value="1e-8"/>
20
21
22
<!--modulation type-->
<parameter name="modulation" type="string" value="oqpsk16"/>
23
24
25
26
27
</Decider>
</root>
En el fragmento de código 4.3 es un ejemplo del contenido del archivo xml. En este ejemplo, se declara un modelo analógico de tipo BreakpointPathlossModel, que representa el modelo de atenuación definido en el
estándar IEEE 802.15.4. Como puede observarse, pueden declararse más de
un modelo analógico. Luego se declara el tipo de decider, Decider802154Narrow,
que clasifica la señal en bits o ruido, según el modelo BER definido también
en el estándar IEEE 802.15.4.
En la tabla 4.1 se enumeran la mayorı́a de los módulos de MiXiM utilizados para modelar la red.
4.2.2.
Modelo de dispositivo
Los nodos de la red están representados por un módulo compuesto por
varios submódulos:
battery
Permite definir una capacidad inicial de baterı́a, y que la radio pueda consumir energı́a descontando de esa capacidad.
nic
Define el comportamiento de la interfaz de red. Es a su vez un módulo
compuesto por el módulo de capa de enlace y el módulo de capa fı́sica. El
modelo de interfaz utilizado es IEEE 802.15.4-2006 y está implementado por
el módulo ic802154 TI CC2420, descripto más adelante.
102
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
Módulo
WSNRouting
Host802154 2400MHz
BatteryStats
SimpleBattery
BaseMobility
Nic802154 TI CC2420
CSMA802154
PhyLayerBattery
Decider802154Narrow
BreakPointPathlossModel
Propósito
Definición de red para simulación de redes
inalámbricas de sensores.
Definición de host que utiliza un tranceptor
802.15.4 a 2.4 GHz.
Módulo de recolección de estadı́sticas sobre baterı́a.
Modelo simple de baterı́a.
Administrador de información básica de movilidad y posición. Éste módulo define un patrón de
movilidad estático (sólo posición).
Modelo de interfaz de red Texas Instruments CC
2420 IEEE 892.15.4 CSMA.
Enlace IEEE 802.15.4-2006 CSMA no ranurado.
Capa fı́sica que consume baterı́a.
Decider para clasificación de señales 802.15.4 de
banda estrecha
Implementación del modelo de atenuación IEEE
802.15.4
Cuadro 4.1: Módulos MiXiM utilizados
net
Define el protocolo de red que utiliza el dispositivo. En este trabajo se desarrollaron nuevos módulos de red para tres protocolos.
app
Define el comportamiento de la aplicación que utiliza los servicios de red. Se
desarrollaron dos nuevos módulos para simular una aplicación de consulta.
Interfaz de red IEEE 802.15.4
El módulo Nic802154 TI CC2420 implementa una interfaz de red Texas
Instruments CC 2420 802.15.4 usando el protocolo de enlace CSMA especificado en el estándar IEEE 802.15.4-2006. El modelo CSMA802154 fue
validado independientemente en una red inalámbrica de sensores de prueba [57], aunque la validación fue realizada con una cantidad de nodos muy
pequeña.
Capa fı́sica
El módulo de capa fı́sica permite configurar la sensibilidad y potencia de
transmisión. El tranceptor del chip CC 2420 soporta los siguientes niveles
103
4.2. DISEÑO DE LA RED
de potencia de transmisión según las especificaciones[58]:
Figura 4.8: Potencia de transmisión del tranceptor TI CC2420
La máxima potencia de transmisión es 1 mW, y es la que se utilizó para
la simulaciones.
No se ha podido hallar el alcance de la radio en la hoja de datos del
tranceptor [58]. En la documentación del nodo sensor MICAz de la compañı́a
MEMSIC [24] se especifica que el alcance del tranceptor es de 75 a 100 m en
exteriores, y de 20 a 30 m en interiores. Se configuró un valor de sensibilidad
de -95 dBm [58].
El módulo de capa fı́sica utilizado calcula la atenuación utilizando el modelo establecido en la sección E.5.3 del estándar IEEE 802.15.4-2006 [31].
Esta capa utiliza el módulo decider Decider802154Narrow para filtrar las
señales recibidas según su intensidad, calcular los errores de bits y clasificar las señales en ruido o frames. En la versión 2.1 de MiXiM este módulo
ignora la sensibilidad del tranceptor, por lo que dos nodos que están a una
distancia bastante mayor que la de la especificación (recibiendo una señal
con una potencia mucho menor a la que el tranceptor es sensible), pueden
conectarse en la simulación. Este comportamiento fue modificado para que
la sensibilidad sea tenida en cuenta.
Se aclara que para las simulaciones realizadas se deshabilitó el ruido
térmico.
Modelo de baterı́a
La baterı́a es un módulo independiente, y define cuál es la capacidad
inicial y el voltaje.
La capa fı́sica de la interfaz Nic802154 TI CC2420, PhyLayerBattery,
descuenta energı́a de la baterı́a según tipos de actividades definidas: dormir,
recepción, transmisión, cambio de modo, y actividad del decider. El fragmento de código 4.4 muestra la definición de las posibles actividades en el
104
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
módulo.
Fragmento de código 4.4: Actividades de capa fı́sica
1
class PhyLayerBattery : public PhyLayer{
2
3
4
5
6
7
8
9
10
enum Activities {
SLEEP_ACCT=0,
RX_ACCT,
TX_ACCT,
SWITCHING_ACCT,
DECIDER_ACCT,
};
...
4.2.3.
Topologı́a
Si bien en [59] se utilizan tres tipos de nodo, sensor, encaminador y sumidero; en el trabajo [60] sólo se observan dos tipos, sensor y sumidero.
El modelo de red seleccionado para este trabajo está formado por un
sumidero único y un conjunto de nodos sensores, todos estáticos. Se implementa con un único tipo de nodo sensor-encaminador, y uno de los nodos
se configura como sumidero. Para ese nodo sumidero no se contabilizan
paquetes ni consumo de energı́a. La selección del nodo sumidero se hace especificando su dirección de red, en el archivo de configuración de simulación,
con la lı́nea del fragmento de código 4.5:
Fragmento de código 4.5: Configuración del nodo sumidero
1
**.node[*].net.sinkAddress = 0
4.2.4.
Tamaño del terreno y densidad de nodos
En las simulaciones de [59] se modela el algoritmo encaminador de manera aislada, excluyendo el canal, por lo cual no se especifica un tamaño de
terreno. En [60] tampoco se especifica el tamaño de la región cubierta.
En omnet++ se pueden especificar las dimensiones en metros de un espacio tridimensional con forma de cubo, en la configuración de la simulación,
con las lı́neas del fragmento de código 4.6:
Fragmento de código 4.6: Dimensiones del terreno
105
4.2. DISEÑO DE LA RED
1
2
3
**.playgroundSizeX = 500 m
**.playgroundSizeY = 500 m
**.playgroundSizeZ = 10 m
Para las simulaciones se utilizó un terreno de 500 m de lado.
En [60], para probar M-SPIN se utilizó un tamaño de red de 10 a 60
nodos, y en [59] se probó SAFM en despliegues de 80 a 1280 nodos.
El modelo de radio asume un alcance de 75-100 m en terreno abierto.
Con un alcance de 75 m de nodo a nodo, y un despliegue predefinido estilo
grilla, con un nodo en cada vértice de cuadrados de 75 m de lado, la cantidad
mı́nima de nodos sensores para cubrir un terreno de 500 metros de lado es de:
500×500
75×75
= 44 nodos
Pero este cálculo se aplica cuando se puede hacer un despliegue preciso.
Cuando el despliegue es al azar, para cubrir un área cuadrada con alta probabilidad, la cantidad de nodos es la siguiente [61]:
r = rango de transmisión de los nodos
a = longitud de lado de un área cuadrada de a × a
n = ( ar )2
m = Θ(n ln n)
cantidad de nodos para cubrir el área cuadrada
Dimensiones del terreno (m2 )
500
Cantidad de nodos
80
Cuadro 4.2: Densidad mı́nima de nodos
Para cubrir las dimensiones del terreno de prueba se necesitan 80 nodos.
4.2.5.
Modelo de despliegue
En ninguno de los trabajos [60][59] se especifica una posición fı́sica para
el sumidero. En lugar de ello, se define con qué nodos sensores tiene conectividad.
Para las simulaciones de este trabajo, los nodos sensores son desplegados
al azar, excepto por el sumidero, cuya posición es cercana a algún punto en el
perı́metro del terreno definido. Las posiciones son generadas aleatoriamente
por el simulador, y por ello, puede que algún nodo quede desconectado de
la red y no participe de la consulta.
106
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
4.2.6.
Modelo de aplicación
El tipo de aplicación modelado es el de consulta iniciada por el sumidero,
el patrón de tráfico es episódico y los requerimientos de latencia no son
estrictos.
Se definen dos módulos de aplicación, uno para el sumidero y otro para el
resto de los nodos. La aplicación del sumidero envı́a un mensaje que contiene
una tarea de sensado a diseminar entre los nodos. La aplicación de los nodos
recibe una tarea de sensado proveniente del sumidero, y responde con los
datos generados.
La tarea de sensado contiene un número de mediciones a tomar y un
perı́odo de tiempo entre cada una. Para las estadı́sticas, solo se contabilizarán los paquetes de datos generados enviados por los nodos, y se omiten
los paquetes que envı́a el sumidero con la tarea.
Los nodos que han quedado sin conexión a sumidero, no generan datos,
porque nunca reciben la tarea.
107
4.3. MÉTRICAS DE EVALUACIÓN
4.2.7.
Resumen del diseño
Caracterı́stica
Interfaz de red
Topologı́a
Terreno
Despliegue
Modelo de aplicación
Descripción
TI CC 2420 802.15.4 banda estrecha CSMA no ranurado
1 sumidero y 79 sensores
500 m2
al azar
Consulta
Cuadro 4.3: Resumen de la red a simular
4.3.
Métricas de evaluación
Puede decirse que las métricas para evaluar protocolos estarán relacionadas con los requerimientos de la aplicación para la cual se diseñan. En [26] se
sugiere que no todas las métricas son útiles para todos los tipos de aplicación.
En algunos artı́culos se da una definición general de la métrica, sin detallar
cómo se mide. Del análisis de los trabajos de generalización [26][27][4] y de
las evaluaciones de protocolos [62][39][63][14], surge el conjunto de métricas
enumerado en las siguientes secciones.
4.3.1.
Vida útil del sistema
Tiempo de vida
Dadas las limitaciones de energı́a de los nodos de de las WSNs, se busca
optimizar los protocolos para extender el tiempo que dura la red en operación, es decir, que puede proveer información del fenómeno sensado.
Puede tomarse alguna de las siguientes medidas genéricas:
a) Tiempo hasta que un nodo agota su energı́a
T1
[segundos]
b) Tiempo hasta que la mitad de los nodos agotan su energı́a
T n2
[segundos]
108
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
c) Tiempo hasta que algún nodo queda aislado
d) Tiempo hasta que algún nodo no posee ruta al sumidero
e) Tiempo hasta que la red queda particionada
Tpartition
[segundos]
O alguna medida especı́fica de la aplicación:
f) Tiempo hasta que algún requerimiento de calidad de servicio ya no puede
garantizarse
Esta métrica se define sobre la base de otra; es el tiempo hasta que una
métrica de calidad de servicio supera o cae debajo de un umbral. En [64]
se menciona que la cobertura puede utilizarse un parámetro para medir la
calidad de servicio en aplicaciones de detección de eventos. Entonces, la vida útil podrı́a también definirse, por ejemplo, como el tiempo hasta que la
cobertura cae al 80 %.
TCov80
[segundos]
Capacidad
Podrı́a definirse como el total de paquetes recibidos durante el tiempo
de vida.
AppT
4.3.2.
Eficiencia
Longitud de ruta promedio
Es la cantidad de nodos que forman el camino entre el nodo origen y el
nodo destinatario del dato. Puede relacionarse con la cantidad de transmisiones y energı́a necesaria para encaminar un paquete.
Una manera de calcularlo es contar la cantidad de saltos totales y la cantidad total de paquetes recibidos.
Havg =
H
Rec
H = Cantidad de saltos totales
Rec = Total de paquetes recibidos
Total de paquetes
Total de paquetes de encaminamiento que genera el protocolo.
Sent = Total de paquetes enviados
109
4.3. MÉTRICAS DE EVALUACIÓN
Transmisiones por consulta
Da una medida del costo promedio en paquetes de una consulta inyectada en la red. Este tipo de métrica se utiliza en aplicaciones basadas en
consulta.
QTavg =
Q
Sent
Q = Cantidad total de consultas
Sent = Total de paquetes enviados
Overhead de control
Es la medida del costo indirecto asociado al encaminamiento. Existen
varias métricas que muestran este costo.
Controlt = Total de paquetes de control enviados
Datat = Total de paquetes de datos enviados
Sent = Total de paquetes enviados
Rec = Total de paquetes recibidos
Appr = Total de paquetes de aplicación entregados
a) Cantidad promedio de paquetes de control por paquete de datos.
Controlt
Datat
b) Cantidad promedio de paquetes necesarios para encaminar un paquete.
Sent
Rec
c) Cantidad promedio de paquetes del protocolo por paquete de aplicación
entregado.
Sent
Appr
4.3.3.
Uso de la energı́a
Costo por paquete
La cantidad promedio de paquetes que pueden ser exitosamente entregados por unidad de energı́a.
110
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
eAppavg =
Appr
E
1
[ mW
s]
E = Consumo total de energı́a
[mWs]
Appr = Total de paquetes de aplicación entregados
Energı́a disipada
La cantidad promedio de energı́a que se utiliza al detectar un evento. Es
una medida más general, que incluirı́a otras actividades además del encaminamiento.
eEvavg =
E
Ev
[mWs]
E = Consumo total de energı́a
[mWs]
Ev = Total de eventos detectados
Energı́a total
Energı́a disipada total, suma del consumo total de cada nodo.
E = Consumo total de energı́a
[mWs]
Distribución de la energı́a
Uniformidad de los niveles de energı́a de los nodos.
Eσ = Desviación de la energı́a residual
4.3.4.
Calidad de servicio
Confiabilidad
Una medida de la tasa de éxito en la transmisión de paquetes.
Conf =
Datar
Datat
(0..1)
Datat = Total de paquetes de datos enviados
Datar = Total de paquetes de datos recibidos
111
4.3. MÉTRICAS DE EVALUACIÓN
Pérdidas
Tasa de pérdidas, indica el porcentaje de paquetes de datos no recibidos
por ningún nodo.
Loss = 1 − Conf
(0..1)
Latencia
Tiempo promedio de recepción de paquetes (latency, end-to-end delay).
Latavg = Retardo promedio de fuente a sumidero
[s,ms]
Tiempo de reacción
Retardo luego de algún cambio en la red.
Cobertura
Expresa qué fracción de la región a monitorear es alcanzada por los nodos que quedan activos.
Cov =
SubR
R
(0..1)
R = Espacio total monitoreado inicialmente
SubR = Espacio monitoreado con los nodos activos
Escalabilidad
Variación del comportamiento del protocolo al variar la densidad y cantidad de nodos. Podrı́a pensarse como la variación de las métricas de interés
en función de la cantidad de nodos.
4.3.5.
Métricas no consideradas
Conectividad
Fracción de enlaces activos una vez que la red se particiona. En realidad,
la métrica sugiere una medida de cobertura.
112
CAPÍTULO 4. DISEÑO DE LA SIMULACIÓN CON OMNET++
Particionamiento
Cuántos nodos quedaron aislados. Esta métrica también sugiere una medida de cobertura.
4.3.6.
Métricas seleccionadas
Las siguientes métricas serán extraı́das de los resultados de la simulación,
basadas en la clasificación presentada al comienzo de la sección.
Longitud de ruta
Se extraerán estadı́sticas sobre la longitud de ruta en cantidad de saltos
de los paquetes entregados al sumidero.
Hσ = Desviación de la longitud de ruta
Hmax = Longitud máxima registrada
Hmin = Longitud mı́nima registrada
Hmean = Longitud media registrada
Total de paquetes
Se contabilizará el total de paquetes de red enviados durante la simulación, excluyendo los que envı́a el sumidero.
Sent = Total de paquetes de red enviados
Overhead de control
Se extraerá una métrica de gasto de control calculada de la siguiente
manera:
Overhead =
Sent
Appr
Total de paquetes de red enviados por cada paquete de aplicación recibido
Costo por paquete
La cantidad de paquetes de aplicación entregados por unidad de energı́a.
eAppavg =
113
Appr
Et
4.3. MÉTRICAS DE EVALUACIÓN
Distribución de la energı́a
Para analizar la uniformidad de energı́a, puede analizarse en su lugar,
la uniformidad del consumo de energı́a para la transmisión, excluyendo al
sumidero.
Eσt = Desviación del consumo total de energı́a en transmisiones
t
Emax
= Máximo consumo total de energı́a en transmisiones
t
Emin = Mı́nimo consumo total de energı́a en transmisiones
t
Emean
= Media del consumo total de energı́a en transmisiones
Energı́a total de transmisión
Puede analizarse el consumo de energı́a desglosándolo por actividad.
En particular, se extraerá el consumo total en transmisiones, excluyendo
el sumidero.
E t = Energı́a total utilizada en transmisiones
Confiabilidad
Se calculará la confiabilidad a nivel aplicación, es decir, contabilizando
paquetes de aplicación.
Conf =
Appr
Appt
Latencia
Se extraerán estadı́sticas de latencia a nivel aplicación, registrando el
retardo de todos los paquetes entregados en el sumidero:
Latσ = Desviación de latencia
Latmin = Latencia mı́nima
Latmax = Latencia máxima
Latmean = Latencia media
114
Capı́tulo 5
Implementación de módulos
de red
5.1.
Definiciones
Como se presenta en [65], la relación de vecindad de los nodos define un
grafo no dirigido (por ser los enlaces bidireccionales) G = (V, E), donde V
es el conjunto de vértices y E ⊆ V × V es el conjunto de aristas. Los vértices
corresponden a las entidades (o nodos) y una arista (o enlace) (x, y) existe sı́ y solo sı́ el nodo x puede transmitir al nodo y, y viceversa. Se denomina:
n(G) al número de vértices o nodos
m(G) al número de aristas y
d(G) al diámetro de G, la máxima distancia entre dos nodos (para hallarlo,
se determina el camino más corto entre cada par de vértices, y la mayor
logitud de todos ellos es el diámetro
N (x) el conjunto de vecinos de x, tal que si y N (x), entonces x puede
transmitir a y, y viceversa
Para el análisis de costo de los algoritmos se medirá la actividad de comunicación, contando la cantidad de transmisiones de mensajes realizadas,
es decir, el costo en mensajes M.
En las especificaciones se utilizaran los términos nodo y enlace únicamente, y se hará referencia al costo en mensajes como complejidad M.
115
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
5.2.
5.2.1.
Diseminación de interés con M-SPIN
Caracterı́sticas
M-SPIN [60] es una versión modificada de SPIN (ver 3.5.2) para transmitir información únicamente al nodo sumidero (en lugar de propagarla a
la totalidad de la red), disminuyendo ası́ la cantidad de paquetes necesarios
y el consumo de energı́a. Como SPIN, M-SPIN es un protocolo orientado a
aplicaciones de reporte de eventos. La modificación contribuye a que la información sea notificada y propagada en dirección al sumidero rápidamente.
Para ello, se agrega una etapa previa a las rondas de negociación de información de SPIN, donde se asigna la distancia al sumidero, quedando la red
dividida en niveles, como puede observarse en la figura 5.1.
Descubrimiento de distancia
En esta etapa, se mide la distancia en saltos al sumidero. Inicialmente
el sumidero hace broadcast de un paquete STARTUP, que contiene la tupla
(tipo, id, distancia):
tipo
es el tipo de mensaje
id
es el identificador del nodo emisor
distancia
es la distancia en saltos al nodo sumidero, el valor inicial es 1
Cuando un nodo recibe el paquete STARTUP, se asigna la distancia que
trae el paquete, incrementa la distancia del paquete en 1 y vuelve a hacer
broadcast del paquete. Si un nodo recibe múltiples paquetes STARTUP, se
asigna la menor distancia recibida, y cada vez que actualiza su distancia,
retransmite el paquete con la distancia incrementada en 1.
En la figura 5.1 (obtenida de [60]), los enlaces que unen los nodos que
han quedado a una misma distancia del sumidero, no serán utilizados para
peticiones y transmisiones de datos, porque siempre se encamina hacia un
nodo de menor distancia. Observar que si el nodo que está a distancia 4
genera datos, ambos nodos a distancia 3 solicitarán la información. El dato
del nodo a distancia 4 será posiblemente encaminado a través de ambos
nodos a distancia 3.
116
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Figura 5.1: Etapa de descubrimiento de distancia al sumidero
Negociación, petición y transmisión de datos
La negociación es similar a la que realiza SPIN-BC, descripto en la sección 3.5.2. El nodo que genera el dato lo notifica haciendo broadcast de un
paquete ADV. Al recibirlo, cada nodo verifica si ya ha recibido o requerido
el dato, y también si está a menor distancia del sumidero que el nodo que
envió el ADV. Sólo si está a menor distancia, el nodo hará la petición del
dato, enviando un paquete REQ.
La transmisión de datos ocurre de la misma manera que en SPIN-BC. Cuando el nodo que generó el dato recibe el paquete REQ, envı́a el paquete DATA
inmediatamente con la información solicitada. Al recibir el dato, el nodo que
lo pidió recomienza la negociación, notificando a sus vecinos con un paquete
ADV con la distancia modificada. El proceso continúa hasta que el sumidero
recibe los datos.
Evaluación
En la evaluación original del protocolo se utilizaron las siguientes métricas:
Métrica
ADV
E
Descripción
Cantidad total de paquetes ADV transferidos para que
un evento alcance el nodo sumidero.
Consumo total de energı́a al variar la cantidad de nodos.
Cuadro 5.1: Métricas de M-SPIN
Se utilizó una tamaño de red mı́nimo de 10 nodos y un máximo de 60.
En el trabajo [60] se presenta como problema principal de M-SPIN el
agotamiento de la energı́a en los nodos más cercanos al sumidero.
117
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
5.2.2.
Especificaciones
SPIN-PP
Valores de estado
S = {INITIATOR, IDLE, DIFFUSE, GATHER, DONE}
SIN IT = {INITIATOR, IDLE}
ST ERM = {DONE}
Restricciones
{BL, TR, CN, UI }
Tipos de mensaje
ADV, REQ, DATA
Variables
countADV
BL = Bidirectional Links
El grafo que definen los enlaces es no dirigido.
TR = Total Reliability
No han habido fallas ni las habrá.
CN = Connectivity
El grafo es fuertemente conexo. De cada nodo es posible alcanzar a
cualquier otro nodo.
UI = Unique Initiator
Sólo una entidad comienza el algoritmo.
El nodo en estado INITIATOR posee un nuevo dato para encaminar y
comienza la negociación anunciando el dato a todos sus vecinos, enviando
un paquete ADV a cada uno. Entonces pasa al estado DIFFUSE.
INITIATOR
Spontaneously
begin
send(ADV) to N(x);
countADV := |N (x)|;
118
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
become DIFFUSE;
end
Al comenzar, el resto de los nodos se encuentra en estado IDLE. En este
estado, cuando el nodo recibe un paquete ADV que anuncia un nuevo dato,
envı́a un paquete REQ para solicitar el dato al nodo que lo anunció. Luego
pasa al estado GATHER.
IDLE
Receiving(ADV)
begin
send REQ to sender;
countADV := |N (x)| − 1;
become GATHER;
end
En estado DIFFUSE, el nodo se encuentra a la espera de peticiones por
el dato que ha anunciado. Cuando recibe un paquete REQ de petición, responde con los datos solicitados al nodo que lo emitió. Si recibe un paquete
ADV, decrementa un contador que permite determinar cuando todos los
nodos vecinos ya poseen el dato, momento en el cual pasa al estado de terminación local DONE.
DIFFUSE
Receiving(REQ)
begin
send DATA to sender;
end
Receiving(ADV)
begin
counter−−;
if counter = 0 then
become DONE;
endif
end
119
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
En estado GATHER el nodo se encuentra negociando el dato que ha solicitado. Si recibe un paquete DATA, envı́a un paquete ADV a cada vecino
menos el nodo del cual recibió información, anunciando el nuevo dato que
posee y pasa al estado DIFFUSE. Si recibe un paquete ADV, decrementa
un contador que permitirá determinar cuando todos los nodos vecinos ya
poseen el dato.
GATHER
Receiving(DATA)
begin
Cache(DATA)
send ADV to N(x) - {sender};
become DIFFUSE;
end
Receiving(ADV)
begin
counter−−;
end
SPIN-BC
Valores de estado
S = {INITIATOR, IDLE, WAIT, DIFFUSE, GATHER, DONE}
SIN IT = {INITIATOR, IDLE}
ST ERM = {DONE}
Restricciones
{BL, TR, CN, UI }
Tipos de mensaje
ADV, REQ, DATA
Variables
{countADV}
El nodo en estado INITIATOR posee un nuevo dato para encaminar y
comienza la negociación anunciando el dato a todos sus vecinos, enviando
un paquete ADV por broadcast. Entonces pasa al estado DIFFUSE.
120
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
INITIATOR
Spontaneously
begin
send(ADV) to N(x);
countADV := |N (x)|;
become DIFFUSE;
end
Al comenzar, el resto de los nodos se encuentra en estado IDLE. En este
estado, cuando el nodo escucha un paquete ADV, inicia la alarma de supresión de petición, que expira en un tiempo al azar, y pasa al estado WAIT.
IDLE
Receiving(ADV)
begin
set alarm := c(x) + u(I)
source := sender;
countADV := |N (x)| − 1;
become WAIT;
end
En el estado WAIT, el nodo se encuentra esperando oir una petición por
el mismo dato en negociación, para suprimir la suya. En este estado, si la
alarma de supresión expira, el nodo envı́a una petición por broadcast, especificando de qué nodo recibió el anuncio. Luego pasa al estado GATHER.
Si antes de expirar la alarma, recibe un paquete REQ, el nodo cancela la
alarma suprimiendo su petición y pasa al estado GATHER. Asimismo, si
antes de expirar la alarma recibe el paquete DATA, cancela la alarma suprimiendo su petición, anuncia el nuevo dato por broadcast y pasa al estado
DIFFUSE.
Si en el estado WAIT recibe un paquete ADV, decrementa un contador que
permite detectar que todos los vecinos ya poseen el dato.
WAIT
When c(x) = alarm
begin
REQ.source = source;
send REQ to N(x);
121
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
become GATHER;
end
Receiving(REQ)
begin
//Si escucha un pedido por el mismo dato
if source = REQ.source then
unset alarm; //Suprime la petición
become GATHER;
endif
end
Receiving(DATA)
begin
Cache(DATA);
unset alarm; //Suprime la petición
send ADV to N(x);
become DIFFUSE;
end
Receiving(ADV)
begin
counter−−;
end
En el estado DIFFUSE, el nodo se encuentra a la espera de peticiones
por el dato que anunció. Si escucha una petición que especifica que el origen
del anuncio fue él mismo, responde por broadcast un paquete DATA con los
datos y pasa al estado DONE, ya que SPIN-BC sólo envı́a el dato una vez.
Si recibe un paquete ADV, decrementa un contador que permite detectar
cuando todos los vecinos ya poseen el dato anunciado.
DIFFUSE
Receiving(REQ)
begin
//El pedido debe ser para este nodo
if REQ.source = x then
send DATA to N(x);
become DONE;
endif
end
122
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Receiving(ADV)
begin
counter−−;
if counter = 0 then
become DONE;
endif
end
En estado GATHER, el nodo se encuentra negociando el dato que no
posee. Si escucha el paquete DATA, anuncia por broadcast el nuevo dato a
sus vecinos y pasa al estado DIFFUSE. Si escucha un paquete ADV, decrementa un contador que permite detectar cuando todos sus vecinos ya poseen
el dato.
GATHER
Receiving(DATA)
begin
Cache(DATA)
send ADV to N(x);
become DIFFUSE;
end
Receiving(ADV)
begin
counter−−;
end
M-SPIN Distancia
Según descripto en [60].
Valores de estado
S = {INITIATOR, IDLE, ITERATE, DONE}
SIN IT = {INITIATOR, IDLE}
ST ERM = {DONE}
Restricciones
{BL, TR, CN, UI }
123
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
Tipos de mensaje
{STARTUP, ACK}
Variables
{countAck, parent}
El nodo sumidero o iniciador comienza el algoritmo enviando por broadcast un paquete STARTUP con valor de distancia 0 a todos sus vecinos.
Luego, contabiliza paquetes ACK. Cuando ha recibido un ACK de cada
vecino, pasa al estado DONE de terminación local. En ese momento se alcanzó la convergencia.
INITIATOR
Spontaneously
begin
STARTUP.hop := 0;
send STARTUP to N(x);
countAck := |N (x)|;
end
Receiving(ACK)
begin
countAck−−;
if countAck = 0 then
become DONE;
endif
end
Receiving(STARTUP)
begin
send ACK to sender;
end
Al comenzar, el resto de los nodos se encuentra en estado IDLE. Cuando
el nodo escucha el primer paquete STARTUP, se asigna la distancia del paquete, toma al emisor como nodo padre y transmite por broadcast un nuevo
paquete STARUP a sus vecinos, que contiene su distancia incrementada en
1. Luego pasa al estado ITERATE.
IDLE
124
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Receiving(STARTUP)
//Recibe el primer STARTUP
begin
distance := STARTUP.hop;
parent := sender;
countAck := |N (x)|;
STARTUP.hop++;
send STARTUP to N(x);
become ITERATE;
end
En el estado ITERATE, si el nodo recibe un paquete STARTUP que
contiene una distancia menor al sumidero, actualiza su distancia a ese valor, y envı́a por broadcast un nuevo paquete STARTUP con su distancia
incrementada en 1. Si el nodo recibe un ACK, decrementa un contador que
permite detectar cuando todos sus vecinos menos el padre han alcanzado la
convergencia. En ese momento, envı́a su propio ACK al nodo que marcó como padre.
ITERATE
Receiving(STARTUP)
begin
send ACK to sender;
if distance > STARTUP.hop then
distance := STARTUP.hop;
countAck += |N (x)|;
STARTUP.hop++;
send STARTUP to N(x);
endif
end
Receiving(ACK)
begin
countAck−−;
if countAck = 0 then
send ACK to parent;
become DONE;
endif
end
125
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
Como se explica en la sección 8.1 de [66], para detectar la terminación
local se debe introducir el acuse de recibo. El sumidero, con el rol de iniciador, envı́a un paquete STARTUP a todos sus vecinos. Cuando un nodo x
en estado IDLE recibe el primer STARTUP, actualiza su distancia al sumidero, y define como padre al nodo emisor. Luego envı́a su nueva distancia
a todos sus vecinos. Para todos los siguiente paquetes STARTUP que recibe, responde con un ACK. Si la distancia que contiene el paquete es menor
que la que el nodo x tiene asignada actualmente, x actualiza su distancia,
y vuelve a notificar a sus vecinos por broadcast con un paquete STARTUP.
Por cada paquete STARTUP que x ha enviado, deberá recibir un ACK de
cada vecino. Cuando x recibe todos los acuse de recibo pendientes, pasa al
estado de terminación local en x.
M-SPIN Negociación
Según descripto en [60]. La negociación es muy similar a la de SPIN-BC,
excepto por el comportamiento del nodo al recibir el paquete ADV. Si el
anuncio proviene de un nodo más cercano al sumidero, no participa de la
negociación.
Valores de estado
S = {INITIATOR, IDLE, DIFFUSE, GATHER, DONE}
SIN IT = {INITIATOR, IDLE}
ST ERM = {DONE}
Restricciones
{BL, TR, CN, UI }
Tipos de mensaje
{ADV, REQ, DATA}
Al comenzar, el nodo que posee un nuevo dato lo anuncia por broadcast
a sus vecinos. Luego pasa al estado DIFFUSE.
INITIATOR
Spontaneously
begin
send(ADV) to N(x);
become DIFFUSE;
end
126
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
El resto de los nodos se encuentra en estado IDLE. Al escuchar un paquete de anuncio, el nodo inspecciona la distancia del emisor, y si es mayor
que la propia, inicia la alarma de supresión de petición, pasando al estado
WAIT. Si el emisor del ADV está a menor distancia del sumidero, el nodo
pasa al estado DONE de terminación local, sin participar de la negociación.
IDLE
Receiving(ADV)
begin
if distance < ADV.hop then
set alarm := c(x) + u(I)
source := sender;
become WAIT;
else
//Si no esta a menor distancia,
//no participa
become DONE;
endif
end
En el estado WAIT, el nodo se encuentra negociando el dato. Si la alarma
de supresión expira, el nodo envı́a la petición por broadcast, especificando el
nodo origen del anuncio, y pasa al estado GATHER. Si antes de expirar la
alarma escucha un paquete REQ, cancela la alarma suprimiendo su propia
petición, y pasa al estado GATHER. Asimismo, si antes de expirar la alarma escucha el paquete DATA, cancela la alarma suprimiendo la petición,
anuncia por broadcast el nuevo dato y pasa al estado DIFFUSE.
WAIT
When c(x) = alarm
begin
REQ.source = source;
send REQ to N(x);
become GATHER;
end
Receiving(REQ)
begin
//Si escucha un pedido por el mismo dato
127
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
if source = REQ.source then
unset alarm; //Suprime la petición
become GATHER;
endif
end
Receiving(DATA)
begin
Cache(DATA);
unset alarm; //Suprime la petición
send ADV to N(x);
become DIFFUSE;
end
En el estado DIFFUSE, el nodo se encuentra a la espera de peticiones
por el dato que anunció. Si escucha un paquete REQ para sı́ mismo, responde enviando por broadcast el paquete DATA y pasa al estado DONE de
terminación local. Si escucha un paquete ADV que proviene de un nodo más
cercano al sumidero, pasa al estado DONE, asumiendo que no es necesario
continuar con la negociación.
DIFFUSE
Receiving(REQ)
begin
//El pedido debe ser para este nodo
if REQ.source = x then
send DATA to N(x);
become DONE;
endif
end
Receiving(ADV)
begin
//Si un nodo más cerca del sumidero
//anuncia el dato, ya no es necesario
//continuar activo
if ADV.hop < distance then
become DONE;
endif
end
128
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
En el estado GATHER, el nodo se encuentra negociando el dato. Cuando
escucha el paquete DATA esperado, anuncia por broadcast el nuevo dato y
pasa al estado DIFFUSE.
GATHER
Receiving(DATA)
begin
Cache(DATA)
send ADV to N(x);
become DIFFUSE;
end
5.2.3.
Complejidad M
Como se define en la sección 5, la complejidad M es el costo en mensajes
del algoritmo, es decir, la cantidad de transmisiones de mensajes necesarias
para completar la ejecución del protocolo.
Complejidad M de M-SPIN Distancia
Se omite del análisis de M-SPIN Distancia, los mensajes ACK, por ser
una construcción teórica que facilita el análisis. Los ACK no son mencionados en el trabajo original de M-SPIN [60].
Sean n el número de vértices o nodos de la red, y d el diámetro de la red
(la mayor distancia entre dos nodos). Un nodo puede actualizar su distancia una cantidad máxima de veces equivalente a d, dado que hay d posibles
valores de distancia al sumidero. Como cada vez que actualiza su distancia,
transmite un mensaje STARTUP:
M [M-SPIN D] ≤ n· d
n = número de vértices o nodos de la red
d = diámetro de la red
Dado que la máxima distancia que puede haber entre dos nodos de un
grafo de n nodos es n − 1, entonces d ≤ n − 1 y la fórmula anterior puede
expresarse como:
M [M-SPIN D] ≤ n· (n − 1) = n2 − n ≤ n2
Un análisis diferente puede hacerse, observando que M-SPIN Distancia
tiene la misma forma que Iterated Construction (Bellman-Ford distribuido),
donde todos los enlaces tienen el mismo costo (que es 1 salto). Asumiendo
129
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
un canal compartido, en cada iteración, el nodo x envı́a su nueva distancia
por broadcast a sus vecinos, transmitiendo un mensaje STARTUP. Como se
sabe que el protocolo converge a lo sumo en n − 1 iteraciones [65]:
M [M-SPIN D] ≤ n· (n − 1) = n2 − n ≤ n2
n = número de vértices o nodos de la red
d = diámetro de la red
M [M-SPIN D] ∼ O(n2 )
Complejidad M de M-SPIN Negociación
En [42] se analiza el tiempo de convergencia, estableciendo que la longitud máxima de ruta que atraviesa un dato es d, que equivale al diámetro de
la red.
Escenario 1 Para negociar la información, cuando un nodo x genera
un dato, transmite por broadcast un mensaje ADV anunciándolo. Si todos
los nodos, menos el generador y el sumidero, están a la misma distancia,
el nodo generador está a distancia 2, el sumidero a distancia 0, y el resto
de los nodos a distancia 1. Entonces, d = 2. El generador anuncia el dato
con un mensaje ADV, n − 2 nodos peticionarán el dato con mensajes REQ,
y el generador deberá responder las peticiones con mensajes DATA. Luego
los n − 2 nodos anunciarán el dato con mensajes ADV. El primer anuncio
que reciba el sumidero iniciará su propia negociación, agregando un mensaje
REQ y un DATA.
ADV = 1 + n − 2
REQ = n − 2 + 1
DAT A = n − 2 + 1
M [M-SPIN N] ≤ 3· (n − 1)
n = número de vértices o nodos de la red
M [M-SPIN N] ∼ O(n)
Escenario 2 Puede pensarse que se transmiten como mı́nimo 3 mensajes por cada salto que debe atravesarse. Suponiendo que el diámetro de G
es el máximo posible, n − 1, y el nodo más alejado del sumidero anuncia un
dato, entonces se ejecutarán n − 1 negociaciones de 3 mensajes cada una.
M [M-SPIN N] ≤ 3· (n − 1)
n = número de vértices o nodos de la red
130
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
M [M-SPIN N] ∼ O(n)
En ambos escenarios, todos los nodos participan de la negociación. En
cualquier otro escenario, la cantidad de nodos que participan puede ser menor que n, por lo que la cantidad de negociaciones serı́a menor, y la cantidad
de mensajes también. Entonces puede decirse que O(n) es el orden M de la
cantidad de mensajes de negociación, y 3· (n − 1) una cota superior.
5.2.4.
Detalles de implementación
Se implementó la familia de protocolos SPIN, SPIN-BC y SPIN-RL.
El módulo SPIN implementa la secuencia de negociación básica. El módulo SPIN-BC tiene una secuencia de negociación diferente, aprovechando el
canal compartido y suprimiendo peticiones, y SPIN-RL lo mejora con la
repetición de peticiones y el lı́mite de reenvı́os. Por simplicidad, todos los
protocolos de la familia almacenan los datos en una cache sin lı́mite. M-SPIN
se implementa extendiendo SPIN-RL, con la fase de asignación de distancia
al sumidero, y la restricción de participar en la negociación sólo si la distancia al sumidero es menor que la del nodo anunciante.
La jerarquı́a de clases para los protocolos SPIN desarrollados puede verse
en la figura 5.2.
131
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
Figura 5.2: Jerarquı́a de módulos de diseminación
132
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Registro de anuncios
En SPIN-PP se procesan todos los anuncios recibidos, enviando peticiones y datos a una dirección especı́fica. En SPIN-BC es necesario registrar
cada anuncio recibido para poder enviar peticiones no suprimidas. Se utilizará un temporizador de petición por cada anuncio recibido, al expirar, se
envı́a la petición. Si se escucha una petición de otro nodo por un dato cuyo
anuncio se registró, se cancela el temporizador, suprimiendo la petición.
Repetición de pedidos
En SPIN-BC un nodo puede suprimir sus peticiones si escucha que otro
nodo ha pedido el mismo dato. Dado que en un canal no ideal puede darse
que al transmitir el dato anunciado, algún nodo que lo espera no lo reciba,
en SPIN-RL cada nodo mantiene registro de todos los anuncios recibidos.
Si no recibe el dato transcurrido un cierto periodo de tiempo posterior al
pedido enviado o suprimido, el nodo vuelve a enviar la petición, indicando
en la cabecera el nodo que originalmente anunció el dato. Se utilizará un
temporizador de recepción del dato, que se programa a partir del momento
en que se envı́a o suprime la petición. Cuando se suprime la petición, ello
implica que se ha escuchado un pedido de otro nodo por el mismo dato, o se
ha recibido el dato directamente. Al expirar el temporizador de recepción,
se repite la petición sólo si el dato no está ya en la cache, y se vuelve a
programar el temporizador de recepción para ese dato.
Lı́mite de reenvios
En SPIN-RL, si un nodo envı́a un dato, luego se debe esperar una cantidad de tiempo predefinida antes de volver a enviar el mismo dato. Se utilizó un registro de envı́os con marcas de tiempo, para controlar los reenvı́os.
Si se recibe un pedido por un dato, y todavı́a no ha transcurrido el tiempo
de espera de reenvı́o, simplemente se ignora el pedido. De lo contrario, se
responde el pedido actualizando la marca de tiempo a ese momento.
Paquete M-SPIN
En el fragmento de código 5.1 puede observarse la definición del paquete
M-SPIN:
Fragmento de código 5.1: Paquete M-SPIN
1
packet SPINPkt extends NetwPkt {
2
3
4
5
int hops;
int advSource;
int meta;
133
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
int finalDestAddr;
int initialSrcAddr;
6
7
8
}
Donde:
hops
es cantidad de saltos al sumidero
advSource
es la dirección del nodo que originalmente anunció el dato
meta
es el metadato del dato anunciado o solicitado
finalDestAddr
es la dirección del nodo destino final del paquete
initialDestAddr
es la dirección del nodo origen del paquete
Se ha definido como longitud de cabecera un valor de 24 bits. El mismo
valor se utilizará en todos los módulos de red.
Ajuste de tiempos de espera
Como M-SPIN extiende a SPIN-RL, existen varios tiempos de espera
que pueden ser ajustados para mejorar el desempeño del protocolo:
sendAgainWait
es el tiempo para enviar un dato nuevamente si ya se envió
requestAgainWait
es el tiempo para volver a pedir un dato
requestSuppressWait
es el tiempo para esperar suprimir un pedido, es decir, el tiempo durante el
cual se espera que otro nodo solicite el mismo dato, en cuyo caso la propia
petición no se envı́a
requestTimes
cantidad de veces que se repite el pedido por un dato como máximo
134
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Se ha observado que si la espera es muy pequeña o muy grande, la tasa de
éxito se empeora. Se realizó un lote de simulaciones de ajuste que resultó en
los siguientes valores de mejor desempeño:
sendAgainWait 100 ms
requestAgainWait 100 ms
requestSuppressWait 150 ms
requestTimes 4
5.2.5.
Pseudocódigo
Algoritmo 2: M-SPIN Procesar paquete de aplicación
1
2
3
agregar datos a cache
crear paquete ADV
entregar al enlace para transmisión broadcast
Algoritmo 3: M-SPIN Procesar paquete STARTUP
1
2
3
4
5
6
7
if saltos del paquete < mi distancia then
asignar la distancia del paquete a mi distancia
incrementar la distancia del paquete
entregar al enlace para retransmisión por broadcast
else
descartar
end
135
5.2. DISEMINACIÓN DE INTERÉS CON M-SPIN
Algoritmo 4: M-SPIN Procesar paquete ADV de anuncio
1
2
3
4
5
6
7
8
9
if el dato anunciado no está en cache Y no está siendo negociado
then
if dirección final = broadcast Ó distancia del emisor > mi
distancia then
programar temporizador de supresión de petición
else
descartar
end
else
descartar
end
Algoritmo 5: M-SPIN Procesar paquete REQ de pedido
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
if origen de anuncio = mi dirección then
if pasó el tiempo mı́nimo entre reenvı́os then
crear paquete de datos
entregar al enlace para transmisión por broadcast
else
descartar
end
else
if hay temporizador de supresión de pedido programado then
cancelar el temporizador
programar temporizador de repetición de pedido
else
descartar
end
end
136
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Algoritmo 6: M-SPIN Procesar paquete DATA de datos
1
2
3
4
5
6
7
8
9
10
11
if el dato está siendo negociado then
cancelar temporizador de repetición de pedido
agregar el dato a la cache
if dirección final = mi dirección Ó dirección final = broadcast
then
entregar el dato a la aplicación
end
crear paquete anuncio
entregar al enlace para transmisión broadcast
else
descartar
end
Algoritmo 7: M-SPIN Expira temporizador de repetición o supresión
de pedido
1
2
3
4
5
if el dato no está ya en cache Y no se superó la cantidad de pedidos
repetidos then
crear paquete de pedido
entregar al enlace para transmisión por broadcast
programar temporizador de repetición de pedido
end
137
5.3. CONSCIENCIA DE RECURSOS CON SAMF
5.3.
Consciencia de recursos con SAMF
5.3.1.
Caracterı́sticas
En el trabajo que desarrolla Flow Augmentation, se mencionan como
futuras direcciones de investigación [12]:
Efectos de la densidad de nodos y variaciones de energı́a residual sobre
el algoritmo
Aplicación de la métrica de enlace a encaminamiento por demanda
Consideración de cuestiones de la MAC
Utilización de niveles discretos de energı́a residual
Es importante tener en mente que este es un protocolo que requiere mantenimiento de tablas de encaminamiento. El costo del camino es la suma de
costos de cada enlace y los caminos se calculan con cualquier algoritmo de
camino más corto, como Bellman-Ford. En el trabajo de [12] no se tiene en
cuenta la energı́a para calcular las rutas de menor costo ni de intercambio
de mensajes de control.
SAMF (Self-adapting Maximum Flow Routing) [59] es un protocolo más
recientemente investigado que, de manera similar a Flow Augmentation, asigna costos de enlace relacionados a la energı́a residual, y estos costos son
actualizados cada cierta cantidad de tiempo.
En [59] se dice que en general hay dos fases de operación en una WSN.
Una fase de diseminación, donde se difunde información de control para
cambiar la tarea de sensado, y la recolección, donde se transmiten los datos
a un sumidero o punto de recolección. SAMF encamina la máxima carga de
trabajo sostenible dadas las restricciones de ancho de banda, energı́a y recursos, y se adapta dinámicamente cambios en estas restricciones. Se modela
la red como un grafo dirigido, donde cada nodo es un vértice y los enlaces
entre nodos son las aristas. Sean:
e = Un enlace
v = El nodo origen de e
B(e) = El ancho de banda del enlace
CP U (v) = El poder de cómputo en el nodo origen (velocidad de proceso,
número de paquetes que puede procesar por unidad de tiempo)
E(v, e) = La energı́a requerida para recibir o generar un paquete de datos
y enviarlo a través del enlace
P (v) = La energı́a en el nodo origen
F (e) = Flujo en paquetes que atraviesa el enlace
138
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
C(e) = Capacidad del enlace (la máxima cantidad de paquetes que pueden
enviarse por e en una unidad de tiempo)
El modelo plantea una capacidad de enlace, limitada por el mı́nimo entre
tres capacidades:
P (v)
F (e) <= C(e) = min{B(e), CP U (v), E(v,e)
}
La red entera entonces puede modelarse como una red de flujo [59].
Encaminamiento
El encaminamiento implementa una estrategia ávida, siempre encamina
paquetes por el camino al sumidero que tiene la máxima capacidad residual.
Entonces, se dice que la capacidad residual es usada como métrica de encaminamiento. Más precisamente, el nodo elige el enlace que pertenece al
camino de mayor capacidad residual entre todos los caminos que llevan al
sumidero. El mejor enlace es el que pertenece al camino más corto, entre
aquellos caminos de máxima capacidad residual.
Cálculo de capacidad por época
Para reducir el costo de calcular una y otra vez la capacidad residual de
los caminos al sumidero, las métricas de encaminamiento se mantienen sin
variación por un perı́odo de tiempo, la época, y se recalculan al comienzo
de cada época.
En este sentido, todos los paquetes procesados por un nodo en
una determinada época, son encaminados por el mismo camino.
Las capacidades residuales se calculan al final de la época, substrayendo de
la capacidad nominal el costo de todos los paquetes encaminados en esa
época.
Luego, para el cálculo de la capacidad residual de cada camino (constraint), de cada enlace se mantienen los atributos enumerados en la tabla 5.2.
Cada nodo, a su vez, tiene los atributos enumerados en la tabla 5.3
139
5.3. CONSCIENCIA DE RECURSOS CON SAMF
Atributo
residual capacity
link use
link capacity
constraint
path capacity
path hop
packet energy
Descripción
La cantidad de paquetes por unidad de tiempo que se
pueden enviar por el enlace en la nueva época.
Cantidad de paquetes enviados por el enlace.
La cantidad de paquetes por unidad de tiempo que se
pueden enviar por el enlace (ancho de banda).
Capacidad en cantidad de paquetes en la época.
Cuando se recibe un mensaje por el enlace, se asigna el
mı́nimo entre constraint y la capacidad que asignó el
nodo emisor al mensaje.
Cuando se recibe un mensaje por el enlace, se asigna la
cantidad de saltos que trae el mensaje, incrementada
en uno.
La cantidad de energı́a necesaria para transmitir un
paquete.
Cuadro 5.2: Atributos de cada enlace SAMF
Atributo
residual energy
node power
delta T
energy use
residual cpu
packet cpu
cpu capacity
cpu use
Descripción
Se actualiza en cada época, sumando node power, y
restando energy use.
Es lo que el nodo pudo recargar en la época anterior.
Tiempo que transcurre entre cada época.
Acumula la energı́a utilizada en transmisiones durante
una época. Incrementa cada vez la energı́a necesaria
para transmitir un paquete. Se pone en 0 cada vez que
comienza una nueva época.
Cantidad de paquetes que se pueden procesar por unidad de tiempo para la nueva época.
La cantidad de energı́a necesaria para procesar un paquete.
Cantidad de paquetes que se pueden procesar por unidad de tiempo.
Acumula la energı́a utilizada en procesamiento. Incrementa cada vez la energı́a necesaria para procesar un
paquete. Se pone en 0 cada vez que comienza una nueva época.
Cuadro 5.3: Atributos de cada nodo SAMF
140
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Cuando cambia la época, cada nodo vuelve a calcular la capacidad de
cada enlace (constraint) para la nueva época. La energı́a residual del nodo
suma la energı́a que el nodo haya podido cargar y resta el uso en la época
anterior. La capacidad de un enlace (ancho de banda) para la época nueva
se calcula como el mı́nimo entre:
1) transmisiones residuales del nodo:
Er r
eP
Er = Residual energy
eP = Packet energy
Esto es, cuantos paquetes pueden transmitirse con la energı́a residual
2) proceso residual del nodo:
CP Ur
cpup
CP Ur = Residual CPU
cpup = Packet CPU
Esto es, cuantos paquetes pueden procesarse con la CPU residual
3) transmisiones residuales del enlace:
Cr · ∆T
Cr = Residual capacity
Cuantos paquetes pueden enviarse con el ancho de banda residual
La intención es que si en la época anterior se excedió el uso de la capacidad asignada, la capacidad para la época que sigue será menor, intentando
compensar y balancear el flujo.
El sumidero dispara el intercambio de paquetes INTEREST al comienzo
de cada época, que permiten ejecutar en la red el algoritmo Bellmand-Ford
distribuido con iniciador único, para calcular los caminos de costo mı́nimo
al sumidero (con las capacidades actualizadas) con complejidad de mensajes
polinomial. El algoritmo pertenece a una clase de estrategias denominada
distance vector. En cada iteración, la entidad envı́a su vector de distancia
que contiene información de la ruta y el costo al sumidero. En [65] se dice
que este es un enfoque costoso en complejidad M (cantidad de mensajes).
141
5.3. CONSCIENCIA DE RECURSOS CON SAMF
Evaluación
Para la evaluación se hizo foco en la escalabilidad del protocolo, evaluando la respuesta de las siguientes métricas en función de la cantidad de nodos:
Métrica
flujo máximo
longitud de ruta
deuda máxima
interés
Descripción
Consumo total de energı́a al variar la cantidad de nodos.
La cantidad promedio de saltos en el camino al sumidero.
Es la máxima deuda de capacidad observada durante
la simulación. Representa un uso de capacidad superior al asignado para alguna época, compensado en la
siguiente.
Cantidad total de paquetes INTEREST intercambiados por época. No se aclara si es el promedio de todas
las épocas.
Cuadro 5.4: Métricas de SAMF
La evaluación se realizó con Omnet++, asumiendo un canal ideal (sin
utilizar una pila completa de protocolos). Este trabajo es muy similar al de
Flow Augmentation [12], en donde en cada época, el flujo hacia un nodo
se aumenta o disminuye sobre la base de su energı́a residual, y la energı́a
de transmisión y recepción necesarias para utilizar el enlace a ese nodo.
SAMF innova asumiendo nodos que pueden cosechar energı́a, por lo que
en cada época, la capacidad residual puede aumentar o disminuir. Además,
incorpora la capacidad de procesamiento y el ancho de banda a la métrica
de encaminamiento.
5.3.2.
Especificaciones
SAMF Capacidad
A continuación se ha elaborado la especificación del algoritmo de cálculo
de capacidad, según descripto en [59]. Se asume un canal ideal no compartido para este análisis.
Valores de estado
S = {INITIATOR, IDLE, ITERATE, DONE}
SIN IT = {INITIATOR, IDLE}
ST ERM = {DONE}
Restricciones
{BL, TR, CN, UI }
142
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Tipos de mensaje
{INTEREST, ACK}
Variables
{countAck, parent}
Al comenzar, el sumidero o nodo iniciador envı́a el primer paquete INTEREST a todos su vecinos, con un valor inicial de capacidad muy alto, ya
que en el sumidero los recursos no son acotados, y el identificador de época
actual. Cuando el sumidero recibe un paquete ACK, decrementa un contador que permite detectar la terminación local, cuando llega a cero. Cuando
recibe un paquete INTEREST, simplemente acusa su recibo respondiendo
con un ACK al emisor.
INITIATOR
Spontaneously
begin
send(INTEREST) to N(x);
countAck := |N (x)|;
end
Receiving(ACK)
begin
countAck−−;
if countAck = 0 then
become DONE;
endif
end
Receiving(INTEREST)
begin
send(ACK) to sender;
end
El resto de los nodos comienza en estado IDLE. En este estado, al recibir
el primer paquete INTEREST, el nodo inspecciona el identificador de época,
y si difiere de la conocida, actualiza su valor y recalcula las capacidades de
enlace para la nueva época. Luego, actualiza la tabla de encaminamiento y
establece al nodo emisor como su nodo padre. Entonces, determina la capacidad de la mejor ruta conocida (mayor capacidad, y menor cantidad de
143
5.3. CONSCIENCIA DE RECURSOS CON SAMF
saltos a igual capacidad), y transmite un paquete INTEREST con la capacidad calculada a todos sus vecinos menos el padre. Finalmente pasa al estado
ITERATE.
IDLE
Receiving(INTEREST)
//Recibe el primer paquete
begin
// Nueva época
if INTEREST.epoch != epoch then
Recompute contraints;
epoch := INTEREST.epoch;
endif
Update routing table(INTEREST);
parent := sender;
INTEREST.bestGate := Get best gate();
send(INTEREST) to N(x);
countAck := |N (x)|;
become ITERATE;
end
En el estado ITERATE, si el nodo recibe un nuevo paquete INTEREST, actualiza la tabla de encaminamiento con la capacidad que contiene el
paquete, y determina si ha cambiado la mejor ruta conocida. En caso afirmativo, envı́a la nueva mayor capacidad a todos sus vecinos, incrementando
la cantidad de ACK esperados. Si recibe un paquete ACK, decrementa el
contador. Cuando el contador de ACK llega a cero, el nodo envı́a su propio
ACK al padre y pasa al estado DONE de terminación local.
ITERATE
Receiving(INTEREST)
begin
send(ACK) to sender;
bestGateUpdated := Update routing table(INTEREST);
if bestGateUpdated = true then
INTEREST.bestGate := Get best gate();
send(INTEREST) to N(x);
countAck += |N (x)|;
endif
end
144
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Receiving(ACK)
begin
countAck−−;
if countAck = 0 then
send(ACK) to parent;
become DONE;
endif
end
En SAMF, el establecimiento de las rutas de mayor capacidad se hace
utilizando un algoritmo con la estructura de Bellman-Ford distribuido de
origen único[59], también sugerido en Flow Augmentation[12].
Como se describe en la sección 8.1 de [66], para detectar la terminación
del algoritmo se debe introducir el acuse de recibo de los mensajes que
se envı́an con la mejor capacidad conocida. El sumidero, nodo iniciador,
comienza el algoritmo enviando el paquete INTEREST conteniendo un valor
de capacidad muy grande a los nodos vecinos. Cuando un nodo x recibe
el paquete INTEREST por primera vez, define al emisor como su padre,
y reenvı́a el paquete INTEREST con la mejor capacidad que conoce a sus
propios vecino. Cuando el nodo x recibe nuevos paquetes INTEREST de sus
vecinos, responde con ACK. Si algún paquete INTEREST de los recibidos
proviene de una mejor ruta (contiene una capacidad mayor o igual pero con
menor cantidad de saltos) que la que el nodo x conoce, éste actualiza su
capacidad, y vuelve a emitir un paquete INTEREST con este nuevo valor, a
todos sus vecinos. Una vez que el nodo x recibe los paquetes ACK de cada
paquete INTEREST que envió, transmite su propio ACK al nodo padre, y
pasa al estado terminal, alcanzándose la terminación local.
SAMF Encaminar
Especificación del algoritmo de encaminamiento de SAMF, según descripto en [59].
Valores de estado
S = {INITIATOR, IDLE, DONE}
SIN IT = {INITIATOR, IDLE}
ST ERM = {DONE}
Restricciones
{BL, TR, CN, UI }
145
5.3. CONSCIENCIA DE RECURSOS CON SAMF
Tipos de mensaje
{DATA}
El nodo iniciador es el que tiene un nuevo dato para encaminar. Comienza la ejecución del protocolo inspeccionando su tabla de encaminamiento y
seleccionando la mejor ruta (mayor capacidad) al destino. Luego, envı́a el
paquete de datos al siguiente nodo en la ruta y pasa al estado DONE de
terminación local, dado que no se requiere alguna otra intervención.
INITIATOR
Spontaneously
begin
y := Next hop(DATA);
send(DATA)to y;
become DONE;
end
El resto de los nodos, comienzan en estado IDLE. Al recibir un paquete
DATA, el nodo revisa su tabla de encaminamiento y selecciona la mejor ruta
al destino (siempre el sumidero), y reenvı́a el paquete al siguiente nodo en
la ruta. Luego pasa al estado DONE, ya que no se requiere otra intervención.
IDLE
Receiving(DATA)
begin
y := Next hop(DATA);
send(DATA) to y;
become DONE;
end
Cabe señalar que sólo los nodos a lo largo de la ruta participan en el
encaminamiento.
5.3.3.
Complejidad M
Como se definió en la sección 5, la complejidad M es el costo en mensajes
del algoritmo, es decir, la cantidad de transmisiones de mensajes necesarias
para completar la ejecución del protocolo.
146
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Complejidad M de SAMF Capacidad
SAMF Capacidad tiene el mismo comportamiento que el protocolo Iterated Construction (Bellman-Ford distribuido) presentado en [65], la tabla
de encaminamiento se construye de forma iterativa. En cada iteración, cada
nodo comunica su mejor capacidad al sumidero a todos sus vecinos y luego
de recibir la mayor capacidad de sus vecinos, recalcula ese valor. Asumiendo
un canal compartido, en cada iteración, el nodo x envı́a un mensaje por
broadcast, y dado que el proceso converge en n - 1 iteraciones como máximo
[65]:
M [SAMF Capacidad] ≤ n· (n − 1) = n2 − n ≤ n2
n = número de vértices o nodos de la red
M [SAMF Capacidad] ∼ O(n2 )
Complejidad M de SAMF Encaminar
SAMF Encaminar se basa en las tablas construidas para la época corriente. La cantidad de saltos que pueden requerirse para que el paquete
de datos llegue a destino está acotada por el diámetro máximo que puede
poseer la red.
M [SAMF Encaminar] ∼ d ≤ n − 1
d = diámetro de la red
M [SAMF Encaminar] ∼ O(n)
5.3.4.
Detalles de implementación
Paquete SAMF
En el fragmento de código 5.2 puede observarse la definición del paquete
SAMF:
Fragmento de código 5.2: Paquete SAMF
1
2
3
4
5
6
7
packet SAMFPkt extends NetwPkt {
int pathHops;
double pathCapacity;
long epochId;
int finalDestAddr;
int initialSrcAddr;
}
147
5.3. CONSCIENCIA DE RECURSOS CON SAMF
A continuación se describe cada campo del paquete SAMF:
pathHops
es la cantidad de saltos de la mejor ruta conocida
pathCapacity
es la capacidad de la mejor ruta conocida
epochId
es la época actual
finalDestAddr
es la dirección del nodo destino final del paquete
initialDestAddr
es la dirección del nodo origen del paquete
Se utilizará el mismo paquete para representar el mensaje INTEREST y
DATA. Se le define como longitud de cabecera un valor de 24 bits. El mismo
valor se utiliza para todos los paquetes utilizados en la simulación.
Mantenimiento de rutas
En SAMF[59] se utiliza una forma del algoritmo Bellman-Ford distribuido para el mantenimiento de los costos de las rutas, el mismo sugerido en
el algoritmo FA (Flow Augmentation)[12], que también modela flujo de red.
Con cada paquete INTEREST se recibe información que permite actualizar
el costo del enlace. El paquete trae la capacidad de la ruta conocida por el
nodo remoto, y la cantidad de saltos al sumidero. En SAMF, la capacidad
de la ruta, es la menor de las capacidades de los enlaces que la componen.
El costo de la ruta es inverso a la capacidad, cuanto más capacidad, menor
costo.
La librerı́a de simulación provee una clase cTopology que permite extraer
la topologı́a de la red y calcular el camino más corto de un nodo a cualquier
otro, pero la misma no puede utilizarse, porque utiliza como costo de ruta
la suma de los costos de los enlaces. En el protocolo Flow Augmentation el
costo de la ruta es la suma de los costos de los enlaces que la componen.
Pero en SAMF, como se ha dicho, la capacidad de la ruta no es la suma
de las capacidades de cada enlace, sino que se restringe a la menor de las
capacidades de los enlaces que la componen. Entonces, en SAMF la tabla de
encaminamiento se construye a medida que se reciben paquetes INTEREST
148
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
con estructuras de datos, sin utilizar cTopology.
Diseño del módulo
Para modelar el protocolo, se ha excluido del modelo la posibilidad de cosechar energı́a. La métrica de encaminamiento sólo tiene en cuenta la energı́a
residual, y ésta siempre va en disminución. Se han excluido del cálculo de la
métrica de capacidad, el ancho de banda del enlace y el poder de cómputo
en el nodo, modelando una red de dispositivos homogéneos.
En el SAMF original, al comienzo de cada época se define el crédito
disponible de cpu, energı́a y ancho de banda de cada enlace. Durante la
época, se registra el consumo de cpu, ancho de banda utilizado por el enlace
y la energı́a utilizada. Al final de la época, si alguno ha excedido el crédito
asignado, en la siguiente época el crédito será la capacidad nominal menos
el exceso anterior, intentando balancear la carga en los enlaces y nodos.
Para la implementación, la métrica se ha simplificado utilizando solamente
la energı́a residual, con la hipótesis de que los nodos que más paquetes han
encaminado durante una época, tendrán un nivel de energı́a residual menor
al final de la época. Si su crédito se basa sólo en la energı́a residual, los
nodos más cargados en una época dispondrán de menos capacidad para la
época siguiente, encaminando una menor cantidad de paquetes.
Asimismo, en el trabajo original se define la capacidad en cantidad de
paquetes. Para este trabajo, a la capacidad dada por la energı́a residual se
le da valores discretos múltiplos de 5, a partir de la carga de baterı́a relativa
que va de 0 a 100 %, siguiendo la sugerencia de [12].
Encaminamiento
El encaminamiento de SAMF simplemente selecciona de la tabla, el enlace con la mejor capacidad al sumidero y reenvı́a el paquete.
5.3.5.
Pseudocódigo
A continuación, se detallan los algoritmos 8, 9, 10, 11, 12, 13 implementados en la clase C++ del protocolo.
149
5.3. CONSCIENCIA DE RECURSOS CON SAMF
Algoritmo 8: SAMF Procesar paquete de aplicación
1
2
3
4
5
6
7
8
crear paquete de red
if la dirección destino = broadcast then
guardar paquete en cache de inundación
entregar al enlace para transmisión broadcast
else
buscar en la tabla la ruta de mejor capacidad al destino
entregar al enlace para transmisión al siguiente nodo
end
Algoritmo 9: SAMF Procesar paquete INTEREST
1
2
3
4
5
6
7
8
9
10
11
if época del paquete 6= época actual then
actualizar la época actual a la época del paquete
recalcular las restricciones en la tabla de enlace
end
obtener la ruta A, la mejor de la tabla
actualizar el enlace en la tabla con los datos del paquete
obtener la ruta B, la nueva mejor de la tabla
if ruta A 6= ruta B then
crear paquete INTEREST con los datos de la nueva mejor ruta
entregar paquete INTEREST al enlace para transmisión por
broadcast
end
150
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Algoritmo 10: SAMF Procesar paquete DATA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
if cantidad de saltos del paquete > máxima cantidad de saltos then
descartar
else if el paquete es inundación then
if el paquete no está en la cache de inundación then
agregar a la cache de inundación
entregar al enlace para retransmisión broadcast
entregar a la capa de aplicación
else
descartar
end
else
if destino final = mi dirección then
entregar a la aplicación
else
buscar la ruta de mejor capacidad en tabla
entregar al enlace para retransmisión al siguiente nodo
end
end
Algoritmo 11: SAMF Recalcular restricciones de enlace
1
2
3
for cada ruta en la tabla do
actualizar la restricción al valor de energı́a residual
end
151
5.3. CONSCIENCIA DE RECURSOS CON SAMF
Algoritmo 12: SAMF Actualizar enlace en la tabla
1
2
asignar la capacidad del enlace al mı́nimo entre la restricción y la
capacidad que informa el paquete
asignar los saltos del enlace a la cantidad que informa el paquete + 1
Algoritmo 13: SAMF Obtener la mejor ruta a destino
1
2
iterar la tabla y seleccionar la ruta de mayor capacidad
si hay rutas de igual capacidad, seleccionar la de menor cantidad de
saltos
152
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
5.4.
5.4.1.
Módulo de técnica mixta: EA-SPIN
Diseño
Una manera de combinar las técnicas de diseminación de interés y consciencia de energı́a es utilizar la negociación por metadatos de SPIN y el
control de flujo por épocas de SAMF en un mismo algoritmo de encaminamiento. En este trabajo se estudia esa posibilidad definiendo EA-SPIN
(Energy Aware SPIN), una versión de SPIN basada en M-SPIN y SAMF.
SAMF y M-SPIN tienen en común la difusión de información de control
con el sumidero iniciando el proceso periódicamente. Entonces, en EA-SPIN,
además de registrarse la distancia al sumidero como lo hace M-SPIN, en la
fase periódica de descubrimiento puede registrarse también la capacidad de
la mejor ruta, como hace SAMF.
Saltear negociación
Cuando un nodo sensor genera un dato, este se anuncia a todos sus vecinos. En M-SPIN, sólo aquellos vecinos más cercanos al sumidero requerirán
el dato. Si el nodo está más lejos del sumidero que el nodo que anunció, no
participa de la negociación.
Con la modificación que se introduce en EA-SPIN, el nodo que anuncia
el dato incluye en el anuncio la capacidad de la mejor ruta conocida. Los
nodos vecinos que tienen una capacidad mejor o igual a la anunciada son
los que peticionarán el dato de manera adelantada, utilizando un tiempo
máximo de espera de supresión de pedido menor al normal. Los nodos vecinos que están más cerca del sumidero esperarán escuchar que algún otro
nodo ha peticionado el dato. Si el nodo más cercano al sumidero no escucha
ningún otro pedido, entonces deberá negociar el dato. Si escucha un pedido
de un nodo de mejor capacidad, se abstiene de continuar con la negociación,
asumiendo que otro nodo se ha propuesto a sı́ mismo para encaminar el
dato.
Con este enfoque, se espera mejorar el problema de M-SPIN mencionado
en [60], donde unos pocos nodos son utilizados una mayor cantidad de veces,
por lo que disipan su energı́a más rápidamente que el resto, intentando
mejorar consumo de energı́a en los nodos cercanos al sumidero.
Repetición de anuncios
EA-SPIN además agrega la repetición de anuncios. Si un dato anunciado
no es pedido por un nodo vecino durante un intervalo de tiempo, el anuncio se
repite hasta un número máximo de veces. Cuando un nodo envı́a un paquete
de datos, este puede estar siendo esperado por más de un vecino. Al recibir
un dato, EA-SPIN no lo anunciará inmediatamente, sino que esperará un
153
5.4. MÓDULO DE TÉCNICA MIXTA: EA-SPIN
intervalo de tiempo al azar, para evitar colisiones que puedan producirse por
la recepción simultánea del dato enviado por broadcast.
Consciencia de energı́a
El protocolo SAMF siempre va a consumir menos energı́a por que no
tiene etapas de negociación, y por lo tanto se utiliza una menor cantidad
de mensajes. Existe una diferencia conceptual entre los dos protocolos de
base, que radica en qué extremo del enlace entre dos nodos decide el encaminamiento. En SAMF, el que encamina es el nodo origen, enviando el
dato generado al vecino en la mejor ruta al sumidero que el nodo tiene registrado en sus tablas. En cambio en EA-SPIN el que encamina es el nodo
destino, que escucha un dato anunciado y solicita su recepción, es decir, un
nodo intermedio con mejor capacidad se postula a través de la petición para
encaminar el dato. El hecho de que toda la comunicación en los protocolos
EA-SPIN y M-SPIN se realice con broadcast permitirı́a una mejor respuesta
a cambios en la topologı́a, por la naturaleza dinámica de negociación de los
protocolos SPIN. En SAFM, el encaminamiento es por tablas, pero en EASPIN es por negociación, y las tablas se mantienen para que la negociación
sea consciente de la energı́a.
5.4.2.
Especificaciones
Para el análisis, las siguientes especificaciones se construyen bajo la restricción de confiabilidad total, por lo que no se modelan las repeticiones de
anuncios ni de peticiones.
EA-SPIN Capacidad
Valores de estado
S = {INITIATOR, IDLE, ITERATE, DONE}
SIN IT = {INITIATOR, IDLE}
ST ERM = {DONE}
Restricciones
{BL, TR, CN, UI }
Tipos de mensaje
{START, ACK}
Variables
{epoch, distance, countAck}
154
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Al comenzar, el sumidero o nodo iniciador envı́a por broadcast un paquete START a todos sus vecinos, que contiene un valor de capacidad muy
alto, cantidad saltos al sumidero inicializada en cero, y el identificador de
época actual. Por cada ACK que recibe, decrementa un contador iniciado
en un valor igual a la cantidad de vecinos. Cuando el contador llega a cero,
todos los vecinos han determinado las capacidades de ruta y pasa al estado
DONE de terminación local. Si recibe un paquete START, envı́a un acuse
de recibo al nodo que lo emitió.
INITIATOR
Spontaneously
begin
send(START) to N(x);
countAck := |N (x)|;
end
Receiving(ACK)
begin
countAck−−;
if countAck = 0 then
become DONE;
endif
end
Receiving(START)
begin
send(ACK) to sender;
end
El resto de los nodos comienza en estado IDLE. En este esstado, al recibir el primer paquete START, determina si ha cambiado la época. En
caso afirmativo, actualiza su identificador de época actual y recalcula las
capacidades de enlace para la nueva época. Luego actualiza la tabla de encaminamiento y establece al nodo emisor como su nodo padre. Para seguir,
envı́a por broadcast un nuevo paquete INTEREST con la capacidad de la
mejor ruta conocida. Finalmente pasa al estado ITERATE.
IDLE
Receiving(START)
begin
// Nueva época
if START.epoch != epoch then
155
5.4. MÓDULO DE TÉCNICA MIXTA: EA-SPIN
Recompute contraints;
endif
Update routing table(START);
distance := START.hop;
parent := sender;
countAck := |N (x)|;
send(START) to N(x);
become ITERATE;
end
En el estado ITERATE, el nodo itera hasta recibir un ACK de cada
vecino, para cada una de sus actualizaciones de mejor ruta, transmitidas
con paquetes START. Al recibir un paquete START, responde con ACK al
emisor y actualiza la tabla de encaminamiento con la información que trae
el paquete. Si la mejor ruta a cambiado (hay una nueva ruta de mayor capacidad, o igual capacidad que la anterior pero con menor cantidad de saltos)
o la distancia del nodo es mayor que la cantidad de saltos del paquete, el
nodo notifica este cambio transmitiendo por broadcast un nuevo paquete
START con el nuevo valor de mayor capacidad y, como cantidad de saltos al
sumidero, su distancia incrementada en 1. Cuando recibe un paquete ACK,
decrementa el contador de acuses y cuando este llega a cero, envı́a su propio
ACK al nodo definido como padre, pasando al estado DONE de terminación
local.
ITERATE
Receiving(START)
begin
send(ACK) to sender;
bestPathChanged := Update routing table(START);
if bestPathChanged = true || distance > START.hop then
if distance > START.hop then
distance := START.hop;
endif
START.bestGate := Get best gate();
START.hop = distance + 1;
countAck += |N (x)|;
send(START) to N(x);
endif
end
Receiving(ACK)
begin
156
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
countAck−−;
if countAck = 0 then
send(ACK) to parent;
become DONE;
endif
end
EA-SPIN Negociar
La negociación es similar a la que realiza M-SPIN, excepto por el pedido adelantado que realizan los nodos en la mejor ruta al sumidero, y por
cancelar la negociación si un nodo con mejor capacidad la ha iniciado.
Valores de estado
S = {INITIATOR, IDLE, DIFUSE, GATHER, DONE}
SIN IT = {INITIATOR, IDLE}
ST ERM = {DONE}
Restricciones
{BL, TR, CN, UI }
Tipos de mensaje
{ADV, REQ, DATA}
Parámetros
RA = Máximo intervalo de espera para peticionar en forma adelantada
RS = Máximo intervalo de espera para escuchar otro pedido y suprimir el propio
Al comenzar, el nodo que tiene un nuevo dato para encaminar lo anuncia
por broadcast con un paquete ADV, que incluye la capacidad de la mejor
ruta. Luego pasa al estado DIFFUSE.
INITIATOR
Spontaneously
begin
send(ADV) to N(x);
become DIFFUSE;
end
157
5.4. MÓDULO DE TÉCNICA MIXTA: EA-SPIN
El resto de los nodos comienza en estado IDLE. Al recibir un paquete
ADV, inspecciona la capacidad del emisor que viene en el paquete, y si el
nodo conoce una ruta de mejor capacidad, inicia la alarma de supresión de
petición, que expirará en un tiempo al azar seleccionado en un intervalo menor que el que se utiliza para la espera normal de supresión de peticiones.
Luego pasa al estado WAIT. Si al recibir el ADV, el nodo no posee mejor
capacidad, pero está a menor distancia, inicia la alarma normal de supersión
de pedido y pasa al estado WAIT. Si al recibir el paquete ADV el nodo no
posee una ruta mejor ni está a menor distancia, se abstiene de participar
pasando al estado DONE de terminación local.
IDLE
Receiving(ADV)
begin
//Revisa si tiene mejor capacidad que el que anunció
if Better capacity(ADV) then
set alarm := c(x) + u(RA)
source := sender;
become WAIT;
else if distance < ADV.hop then
set alarm := c(x) + u(RS)
source := sender;
become WAIT;
else
//Si no esta a menor distancia,
//ni tiene mejor capacidad,
//no participa
become DONE;
endif
end
En el estado WAIT, al expirar la alarma de supresión, el nodo envı́a por
broadcast el paquete REQ especificando el nodo origen del anuncio y pasa
al estado GATHER. Si en estado WAIT escucha un paquete REQ por el
mismo dato, cancela la alarma suprimiendo su propia petición. Si el pedido
escuchado proviene de un nodo con una mejor ruta al sumidero, se detiene la
negociación pasando al estado DONE de terminación local. De lo contrario,
el nodo pasa al estado GATHER. Si en estado WAIT el nodo escucha el dato
esperado, cancela la alarma de supresión y anuncia por broadcast el nuevo
dato, pasando al estado DIFFUSE.
158
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
WAIT
When c(x) = alarm
begin
REQ.source = source;
send REQ to N(x);
become GATHER;
end
Receiving(REQ)
begin
//Si escucha un pedido por el mismo dato
if source = REQ.source then
unset alarm; //Suprime la petición
if Better capacity(REQ) = false then
// Saltea negociación
become DONE;
else
// Continúa la negociación
become GATHER;
endif
endif
end
Receiving(DATA)
begin
Cache(DATA);
unset alarm; //Suprime la petición
send ADV to N(x);
become DIFFUSE;
end
En estado DIFFUSE, el nodo espera peticiones por el dato en negociación. Si recibe una petición par sı́ mismo, responde haciendo broadcast de un
paquete DATA, y luego pasa al estado DONE de terminación local. Recordar que para el análisis se toma la base de SPIN-BC, que sólo envı́a el dato
una vez por broadcast. Si en el estado DFFUSE recibe un paquete ADV de
un nodo más cercano al sumidero, pasa al estado DONE asumiendo que no
se requiere más su intervención.
DIFFUSE
159
5.4. MÓDULO DE TÉCNICA MIXTA: EA-SPIN
Receiving(REQ)
begin
//El pedido debe ser para este nodo
if REQ.source = x then
send DATA to N(x);
become DONE;
endif
end
Receiving(ADV)
begin
//Si un nodo más cerca del sumidero
//anuncia el dato, ya no es necesario
//continuar activo
if ADV.hop < distance then
become DONE;
endif
end
En el estado GATHER, el nodo espera recibir el dato en negociación. Si
recibe un paquete DATA, anuncia el nuevo dato enviando por broadcast un
paquete ADV a todos sus vecinos y pasando al estado DIFFUSE.
GATHER
Receiving(DATA)
begin
Cache(DATA)
send ADV to N(x);
become DIFFUSE;
end
5.4.3.
Complejidad M
Recordando las definiciones de la sección 5, la complejidad M es el costo
en mensajes del algoritmo, es decir, la cantidad de transmisiones de mensajes
necesarias para completar la ejecución del protocolo.
Al igual que M-SPIN Distancia, y SAMF Capacidad, EA-SPIN Capacidad tiene la estructura de Bellman-Ford y ejecuta a lo sumo n−1 iteraciones
(ver secciones 5.2.2 y 5.3.2), por lo que:
M [EA-SPIN Capacidad] ∼ O(n2 )
160
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
EA-SPIN Negociar suprime más rondas de negociación que M-SPIN,
porque si un nodo escucha que otro a la misma distancia o mayor ha peticionado el dato anunciado, se abstiene de participar. En M-SPIN, si dos
nodos a la misma distancia reciben un anuncio de un dato a mayor distancia del sumidero, ambos participan de la negociación. Por lo tanto, puede
decirse que la complejidad M de EA-SPIN es también:
M [EA-SPIN Negociar] ∼ O(n)
5.4.4.
Detalles de implementación
Paquete EA-SPIN
El paquete EA-SPIN extiende el paquete de M-SPIN con la información
del paquete SAMF, con la definición del fragmento de código 5.3:
Fragmento de código 5.3: Paquete EA-SPIN
1
packet EASPINPkt extends SPINPkt {
2
int pathHops;
double pathCapacity;
long epochId;
bool routeType;
3
4
5
6
7
}
En el módulo de red se define como longitud de cabecera un valor de 24
bits, el mismo valor que se utiliza para todos los módulos de red.
Ajuste paramétrico de EA-SPIN
Se realizó un lote de simulaciones para ajustar los siguientes tiempos de
espera:
sendAgainWait
es el tiempo para enviar un dato nuevamente si ya se envió
requestAgainWait
es el tiempo para volver a pedir un dato
requestSuppressWait
es el tiempo para esperar suprimir un pedido
requestFirstWait
es el tiempo de espera para pedir un dato de manera adelantada
161
5.4. MÓDULO DE TÉCNICA MIXTA: EA-SPIN
repeatAdvWait
es el tiempo de espera para repetir un anuncio
requestAgainTimes
cantidad de veces que se repite un pedido como máximo
repeatAdvTimes
cantidad de veces que se repite un anuncio como máximo
El ajuste de EA-SPIN se realizó independientemente del ajuste realizado para M-SPIN. Se observó nuevamente que si la espera es muy corta o
demasiado larga, el desempeño empeora. El ajuste se orienta a la asignación
de esperas lo más cortas posibles que no degraden el desempeño (éxito, latencia, uniformidad de consumo) por la competencia por el medio. Se tuvo
en cuenta el trabajo de [54], que describe los efectos de utilizar una frecuencia de muestreo demasiado alta (del orden de los 5ms) en la exactitud
de la simulación: una distancia significativa de los resultados respecto de la
realidad.
Para la red definida, se encontró que con la siguiente configuración se
logra un mejor desempeño:
sendAgainWait 50 ms
requestAgainWait 200 ms
requestSuppressWait 300 ms
requestFirstWait 150 ms
repeatAdvWait 500 ms
requestAgainTimes 7
repeatAdvTimes 5
Totalizadores
Para analizar el comportamiento de los protocolos SPIN, se incluyeron
en los módulos los siguientes contabilizadores de paquetes:
Algunas relaciones entre ellos:
nbAdvNew = nbAdvReceived - nbAdvNotProcessed
nbReqReceived = nbReqNotProcessed + nbReqProcessed
nbCacheSize = nbAdvSent - nbAdvRepeat
nbCacheSize = nbDataForMe + ¡cantidad de muestras a sensar¿
nbDataForMe = nbDataReceived - nbDataNotProcessed
162
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Contabilizador
nbAdv2Data
nbAdvDuplicated
nbAdvFar
nbAdvNew
nbAdvNotProcessed
nbAdvReceived
nbAdvRepeat
nbAdvSent
nbDataDuplicated
nbDataForMe
nbDataMaxHops
nbDataNotProcessed
nbDataPending
nbDataReceived
nbDataSent
nbReqDuplicated
nbReqForMe
nbReqImmediate
nbReqNotProcessed
nbReqProcessed
nbReqReceived
nbReqRepeat
nbReqSent
nbReqSuppressed
nbSkipNegotiation
nbTotalSent
nbCacheSize
Descripción
Relación entre la cantidad de paquetes de datos
destinados al nodo y la cantidad de anuncios de
datos que el nodo no posee
Anuncios recibidos duplicados
Anuncios recibidos e ignorados por provenir de un
nodo más cercano al sumidero o con mejor capacidad
Anuncios recibidos de datos que el nodo no posee
Anuncios recibidos y descartados por alguna razón
Total de anuncios recibidos
Anuncios enviados por duplicado
Total de anuncios enviados
Datos recibidos por duplicado
Datos recibidos y destinados a este nodo
Datos recibidos y descartados por superar el máximo de saltos permitidos
Datos recibidos y descartados por alguna razón
Datos esperados y no recibidos
Total de paquetes de datos recibidos
Total de paquetes de datos enviados
Peticiones recibidas por un dato que ya ha sido
enviado y no ha transcurrido el tiempo de espera
entre reenviı́os, por lo tanto se ignoran
Peticiones recibidas destinadas a este nodo
Peticiones enviadas en adelanto
Peticiones recibidas no procesadas por alguna
razón
Peticiones recibidas procesadas
Total de peticiones recibidas
Peticiones enviadas por duplicado
Total de peticiones enviadas
Peticiones suprimidas
Negociaciones salteadas
Total de paquetes de negociación enviados: anuncios, peticiones y datos
Tamaño de la cache
Cuadro 5.5: Contadores para el análisis de SPIN
nbReqProcessed = nbDataSent
nbReqRepeat = nbReqRepeat
163
5.4. MÓDULO DE TÉCNICA MIXTA: EA-SPIN
5.4.5.
Pseudocódigo
Algoritmo 14: EA-SPIN Procesar paquete de aplicación
1
2
3
4
agregar datos a cache
crear paquete ADV especificando la mejor capacidad conocida
entregar al enlace para transmisión broadcast
programar temporizador de repetición de anuncio
Algoritmo 15: EA-SPIN Procesar paquete STARTUP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
if época del paquete 6= época actual then
actualizar la época actual a la época del paquete
recalcular las restricciones en la tabla de enlace
end
obtener la ruta A, la mejor de la tabla
actualizar el enlace en la tabla con los datos del paquete
obtener la ruta B, la nueva mejor de la tabla
if ruta A 6= ruta B Ó cantidad de saltos del paquete < mi distancia
then
if cantidad de saltos del paquete < mi distancia then
asignar a mi distancia la cantidad de saltos del paquete
end
crear paquete STARTUP con los datos de la nueva mejor ruta y
mi distancia + 1
entregar al enlace para transmisión por broadcast
else
descartar
end
164
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Algoritmo 16: EA-SPIN Procesar paquete ADV de anuncio
1
2
3
4
5
6
7
8
9
10
11
12
13
if el dato anunciado no está en cache Y no está siendo negociado
then
if dirección final = broadcast then
programar temporizador de supresión de pedido normal
else if tengo mejor capacidad que la especificada en el paquete
then
programar temporizador supresión de pedido adelantado
else if distancia del emisor > mi distancia then
programar temporizador de supresión de pedido normal
else
descartar
end
else
descartar
end
Algoritmo 17: EA-SPIN Procesar paquete REQ de pedido
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
if dirección final 6= broadcast Y estoy negociando el dato Y no tengo
mejor capacidad then
cancelar temporizador de supresión de pedido
else if origen de anuncio = mi dirección then
if pasó el tiempo mı́nimo entre reenvı́os then
crear paquete de datos
entregar al enlace para transmisión por broadcast
else
descartar
end
else if hay temporizador de supresión de petición programado then
cancelar el temporizador
programar temporizador de repetición de pedido
else
descartar
end
165
5.4. MÓDULO DE TÉCNICA MIXTA: EA-SPIN
Algoritmo 18: EA-SPIN Procesar paquete DATA de datos
1
2
3
4
5
6
7
8
9
10
11
if el dato esta siendo negociado then
cancelar temporizador de repetición de pedido
agregar el dato a la cache
if dirección final = mi dirección O dirección final = broadcast
then
entregar el dato a la aplicación
end
crear paquete de anuncio
entregar al enlace para transmisión broadcast
else
descartar
end
Algoritmo 19: EA-SPIN Expira temporizador pedido
1
2
3
4
5
if el dato no está ya en cache Y no se superó la cantidad de pedidos
repetidos then
crear paquete de pedido
entregar al enlace para transmisión por broadcast
programar temporizador de repetición de pedido
end
166
CAPÍTULO 5. IMPLEMENTACIÓN DE MÓDULOS DE RED
Algoritmo 20: EA-SPIN Expira temporizador de repetición de anuncio
1 if el dato nunca fue enviado Y no se superó la cantidad de anuncios
repetidos then
2
crear paquete de anuncio
3
entregar al enlace para transmisión por broadcast
4
programar temporizador de repetición de anuncio
5 end
5.5.
Resumen de módulos desarrollados
En la siguiente tabla se enumeran los módulos C++ desarrollados para
poder llevar a cabo la simulación con Omnet++.
Módulo
SAMF
SPIN
SPIN-BC
SPIN-RL
M-SPIN
EA-SPIN
NetworkStudy
NetworkTracer
NodeApplLayer
SinkApplLayer
Propósito
Módulo que implementa el protocolo de red con
consciencia de energı́a SAMF
Implementa el protocolo de red de diseminación
SPIN
Protocolo de red SPIN-BC
Protocolo de red SPIN-RL
Protocolo de red M-SPIN
Versión de diseminación M-SPIN con consciencia
de energı́a estilo SAFM
Módulo de red base, con utilidades para contabilizar paquetes y totalizar consumo y niveles de
energı́a
Módulo de recolección de estadı́sticas
Módulo de aplicación de nodo sensor
Aplicación del sumidero
Cuadro 5.6: Módulos desarrollados
167
5.5. RESUMEN DE MÓDULOS DESARROLLADOS
168
Capı́tulo 6
Simulación y conclusiones
Para las simulaciones se utilizó la interfaz de red Nic802154 TI CC2420
(802.15.4-2006) como es sugerido por el ejemplo de encaminamiento en
redes de sensores que trae la herramienta, implementando CSMA no ranurado (nonbeacon-enabled unslotted CSMA-CA). La interfaz alternativa
Nic802154A (802.15.4a-2007) es apropiada para redes de muy baja carga
según el estándar [28], por lo que se decidió no utilizar para los experimentos, ya que el patrón de tráfico seleccionado produce ráfagas de transmisiones
no soportadas por ALOHA.
Es importante mencionar que el módulo CSMA 802.15.4 que viene con
el framework MiXiM 2.1 no implementa el modo ranurado, y sólo funciona
en el modo competitivo.
El uso de CSMA no ranurado implica una importante limitación al modelo: los nodos sensores no se sincronizan y deben mantener el tranceptor
encendido todo el tiempo para poder recibir los frames. Debido a esta limitación, los efectos del encaminamiento en la vida útil de la red no serán
evidenciados analizando la cantidad de tiempo que transcurre hasta el agotamiento de nodos. En lugar de ello, se utilizaron métricas de consumo en
transmisiones.
Con respecto a la capa fı́sica se debe aclarar que se deshabilitó el ruido
térmico.
Las caracterı́sticas completas del modelo son descriptas en detalle en la
sección 4.2.
169
6.1. ESCENARIOS
6.1.
Escenarios
Se hicieron simulaciones de red para los siguientes escenarios, con cada
uno de los tres protocolos estudiados:
Escenario
1
2
3
4
Descripción
Sensar 1 muestra en cada uno de los 79 nodos
Sensar 100 muestras en cada uno de los 79 nodos
3 nodos sensan 100 muestras cada uno
Sensar 1 muestra cada 1 m, en cada uno de los
79 nodos, durante 24 h
Paquetes de datos
79
7900
300
113760
Cuadro 6.1: Escenarios simulados
6.2.
Resultados
Se debe tener en cuenta que, en todos los estudios, las estadı́sticas incluyen los paquetes enviados para diseminar la tarea, y todos los paquetes de
control, STARTUP e INTEREST.
6.2.1.
Complejidad M
Para la comparación con las cotas teóricas, se asume que se ejecutó el
algoritmo de asignación de capacidad/distancia una vez, y las negociaciones
necesarias para encaminar la cantidad total de paquetes de datos, dada por
el escenario. La cota de complejidad M es un lı́mite superior muy alto de
cantidad de paquetes necesarios para completar la consulta y se espera que
la métrica de las simulaciones esté lejos de ese valor. Recordando, las cotas
superiores de cantidad de mensajes para la asignación de distancia y la negociación son:
M [M-SPIN D] ≤ n· (n − 1) en una iteración de asignación de distancia
n = 80
n· (n − 1) = 6,320
M [M-SPIN N] ≤ 3· (n − 1) por cada paquete a encaminar
Escenario
Escenario
Escenario
Escenario
1:
2:
3:
4:
6,320 + 79· 3· 79 = 25,043
6,320 + 79· 100· 3· 79 ∼ 1, 9 millones
6,320 + 79· 3· 3· 79 = 77,420
6,320 + 79· 1440· 3· 79 ∼ 27 millones
170
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
Escenario
1
1
2
2
3
3
4
4
Protocolo
M-SPIN
EA-SPIN
M-SPIN
EA-SPIN
M-SPIN
EA-SPIN
M-SPIN
EA-SPIN
M cota
25.043
25.043
1,9 millones
1,9 millones
77.420
77.420
27 millones
27 millones
M simulación
1.688
2.088
150.953
153.564
4.940
6.174
2,17 millones
2,21 millones
Cuadro 6.2: Cantidad total de paquetes enviados en cada escenario
En la tabla 6.2 se compara la cota M, con la cantidad total de paquetes
de red enviados en la simulación.
171
6.2. RESULTADOS
6.2.2.
Métricas obtenidas
Escenario 1
En el escenario 1 todos los nodos responden la consulta con un dato.
Figura 6.1: Escenario 1 - Latencia media en el sumidero
Figura 6.2: Escenario 1 - Tasa de éxito
172
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
Figura 6.3: Escenario 1 - Overhead
Figura 6.4: Escenario 1 - Total de energı́a de transmisión
173
6.2. RESULTADOS
Figura 6.5: Escenario 1 - Media y máxima de saltos
Figura 6.6: Escenario 1 - Media y desviación de energı́a de transmisión
174
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
Escenario 2
En el escenario 2, todos los nodos responden con 100 paquetes de datos.
Figura 6.7: Escenario 2 - Latencia media en el sumidero
Figura 6.8: Escenario 2 - Tasa de éxito
175
6.2. RESULTADOS
Figura 6.9: Escenario 2 - Overhead
Figura 6.10: Escenario 2 - Total de energı́a de transmisión
176
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
Figura 6.11: Escenario 2 - Media y máxima de saltos
Figura 6.12: Escenario 2 - Media y desviación de energı́a de transmisión
177
6.2. RESULTADOS
Escenario 3
En este escenario, sólo 3 nodos responden con 100 paquetes de datos.
Figura 6.13: Escenario 3 - Latencia media en el sumidero
Figura 6.14: Escenario 3 - Tasa de éxito
178
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
Figura 6.15: Escenario 3 - Overhead
Figura 6.16: Escenario 3 - Total de energı́a de transmisión
179
6.2. RESULTADOS
Figura 6.17: Escenario 3 - Media y máxima de saltos
Figura 6.18: Escenario 3 - Media y desviación de energı́a de transmisión
180
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
Escenario 4
En el escenario 4, todos los nodos responden con 1440 paquetes, a razón
de uno por minuto.
Figura 6.19: Escenario 4 - Latencia media en el sumidero
Figura 6.20: Escenario 4 - Tasa de éxito
181
6.2. RESULTADOS
Figura 6.21: Escenario 4 - Overhead
Figura 6.22: Escenario 4 - Total de energı́a de transmisión
182
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
Figura 6.23: Escenario 4 - Media y máxima de saltos
Figura 6.24: Escenario 4 - Media y desviación de energı́a de transmisión
183
6.2. RESULTADOS
Consumo de energı́a en transmisiones
Figura 6.25: Escenario 1 - Total de energı́a vs. distancia al sumidero
Figura 6.26: Escenario 2 - Total de energı́a vs. distancia al sumidero
184
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
Figura 6.27: Escenario 3 - Total de energı́a vs. distancia al sumidero
Figura 6.28: Escenario 4 - Total de energı́a vs. distancia al sumidero
185
6.2. RESULTADOS
Resumen de métricas
Escenario 1
Tasa de éxito
Overhead
Energı́a total de
transmisión (mWs)
Consumo de transmisión medio (mWs)
Desviación estándar
del
consumo
de
transmisión (mWs)
Latencia media (s) en
el sumidero
Media de saltos en el
sumidero
Máxima de saltos en
el sumidero
SAMF
1
7
26
M-SPIN
0,87
24
51,9
EA-SPIN
0,98
26
52,2
0,33
0,66
0,66
0,63
0,90
1,05
0,02
0,22
1,91
4
5
5
8
9
9
Cuadro 6.3: Métricas de escenario 1
Escenario 2
Tasa de éxito
Overhead
Energı́a total de
transmisión (mWs)
Consumo de transmisión medio (mWs)
Desviación estándar
del
consumo
de
transmisión (mWs)
Latencia media (s) en
el sumidero
Media de saltos en el
sumidero
Máxima de saltos en
el sumidero
SAMF
1
5
2037,88
M-SPIN
0,92
20
4675,36
EA-SPIN
0,95
20
3793,43
25,80
59,18
48,02
65,5
94,06
102,53
0,02
0,22
1,86
4
5
5
8
10
9
Cuadro 6.4: Métricas de escenario 2
186
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
Escenario 3
Tasa de éxito
Overhead
Energı́a total de
transmisión (mWs)
Consumo de transmisión medio (mWs)
Desviación estándar
del
consumo
de
transmisión (mWs)
Latencia media (s) en
el sumidero
Media de saltos en el
sumidero
Máxima de saltos en
el sumidero
SAMF
1
5
86,05
M-SPIN
0,84
19
153,38
EA-SPIN
0,97
21
153,35
1,09
1,94
1,94
3,03
4,33
5,15
0,02
0,25
2,02
5
5
5
6
8
7
Cuadro 6.5: Métricas de escenario 3
Escenario 4
Tasa de éxito
Overhead
Energı́a total de
transmisión (mWs)
Consumo de transmisión medio (mWs)
Desviación estándar
del
consumo
de
transmisión (mWs)
Latencia media (s) en
el sumidero
Media de saltos en el
sumidero
Máxima de saltos en
el sumidero
SAMF
1
5
29.292
M-SPIN
0,92
20
67.303
EA-SPIN
0,95
20
54.526
370,79
851,95
690,20
887,83
1.354,43
1.475,29
0,02
0,22
1,86
4
5
5
8
10
9
Cuadro 6.6: Métricas de escenario 4
187
6.2. RESULTADOS
6.2.3.
Análisis de confiabilidad
SPIN es un protocolo diseñado originalmente para diseminar información a la totalidad de la red, y M-SPIN y EA-SPIN intentan transformar
la diseminación en encaminamiento convergente al sumidero. El diseño de
EA-SPIN modifica la negociación en tres etapas ADV-REQ-DATA para que
los nodos con mejor capacidad se ofrezcan primero para encaminar los datos,
utilizando el modelo de capacidad de encaminamiento de SAMF.
La confiabilidad en M-SPIN y EA-SPIN nunca alcanza el 100 % en las
simulaciones realizadas. Esto puede deberse a que toda la comunicación
en estos protocolos, tanto en la fase de asignación de distancia/capacidad,
como en las negociaciones se realiza por broadcast. El módulo de enlace CSMA802154 no envı́a ACKs de frames broadcast, porque ası́ se se encuentra
establecido en el estándar IEEE 802.15.4-2006 [31], y por ello todas las transmisiones de M-SPIN y EA-SPIN no tienen acuse de recibo en el enlace. La
confiabilidad entonces depende en mayor medida de los protocolos de red y
transporte.
En la especificación de SPIN no se aclara qué sucede cuando un anuncio no es respondido por ningún vecino. Para mejorar la tasa de éxito se
incluyó en el diseño de EA-SPN la repetición de anuncios por una cantidad
configurable. También se evaluó la posibilidad de emitir paquetes ADV unicast directamente al siguiente nodo en la mejor ruta conocida, produciendo
frames CSMA-ACK en el enlace, y de esta manera reducir la cantidad de
anuncios perdidos, pero esto no mejoró el desempeño del protocolo. Según el
estándar, los ACK se envı́an directamente, sin utilizar el mecanismo CSMACA [31], por lo que aumentaba la cantidad de descartes por interferencia.
Se observa que la cantidad de colisiones se ve afectada por la carga del
protocolo de red, e incide significativamente en el nivel de confiabilidad, dependiendo del diseño. El módulo de capa de enlace notifica a la capa de
red cuando no puede transmitir un mensaje porque la cola está llena, o se
ha superado el número máximo de backoffs, pero en las simulaciones no se
produjeron descartes por esas causas.
Los efectos de repetir anuncios pueden observarse en el resumen de métricas de la sección 6.2.2. En todos los escenarios simulados la tasa de éxito
de EA-SPIN fue un poco mejor que la de M-SPIN. Intuitivamente puede
pensarse que al agregar la repetición de anuncios, se agregan más mensajes
al ciclo de negociación y se esperará que el efecto sea un mayor número de
colisiones. Pero no resultó de esa manera en las simulaciones. Por ejemplo,
en el escenario 4, se produjeron los siguientes totales de descartes de frames
por interferencia:
188
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
Escenario 4
Descartes por interferencia
SAMF
9.647
M-SPIN
410.614
EA-SPIN
10.476
Cuadro 6.7: Total de frames descartados por interferencia
La menor cantidad de descartes en EA-SPIN puede deberse también a
las modificaciones a la negociación: cuando un nodo oye que otro nodo de
mejor capacidad está negociando el dato, se abstiene de negociar, reduciendo
la cantidad de mensaje transmitidos. Probablemente, los tiempos de espera
de EA-SPIN bastante largos disminuyen la competencia por el medio, con
el efecto no deseado de un gran incremento en la latencia de recepción del
sumidero.
6.2.4.
Consciencia de energı́a
En los cuatro escenarios simulados, el consumo total de energı́a en transmisiones de EA-SPIN es similar o menor al de M-SPIN. En particular, sin
tener en cuenta la menor tasa de éxito de M-SPIN:
Escenario
1
2
3
4
M-SPIN
0,66
59,18
1,94
851,95
EA-SPIN
0,66
48,02
1,94
690,20
Ahorro
0%
18 %
0%
19 %
Cuadro 6.8: Consumo total de energı́a en transmisiones
Lo mismo sucede con el consumo medio de energı́a para transmisiones,
que siempre es menor en EA-SPIN.
Sin embargo, la desviación estándar del consumo en transmisiones es más
alta en EA-SPIN y esto significa que el consumo es más desparejo entre los
nodos, aún habiendo incorporado la capacidad de ruta basada en la energı́a
residual en el encaminamiento. Cuanto más cerca se encuentra un nodo
del sumidero, encamina una mayor cantidad de paquetes y el consumo de
energı́a de transmisión difiere significativamente del consumo de los nodos
más alejados.
Ahora bien, las figuras 6.26 y 6.28 sugieren que las negociaciones evitadas y el uso de la capacidad de SAMF para decidir la participación en el
encaminamiento contribuyen a ahorrar energı́a en los nodos más cercanos al
sumidero.
189
6.2. RESULTADOS
En particular, para los escenarios de respuestas transmitidas al sumidero
desde la totalidad de los nodos, se observan los consumos de transmisión
promedio según la distancia de las figuras 6.29 y 6.30.
Figura 6.29: Escenario 2: Promedio de energı́a de transmisión por distancia
Figura 6.30: Escenario 4: Promedio de energı́a de transmisión por distancia
Es particularmente llamativo que la forma de la curva sea tan similar
entre los dos escenarios. Observados los promedios, se debe aclarar que el
consumo total por nodo difiere bastante entre nodos a la misma distancia.
Haciendo referencia a las figuras 6.25, 6.26, 6.27 y 6.28, las curvas sugieren
que los cambios introducidos al protocolo suavizan el consumo total en trasmisión en los nodos a distancias más cercanas al sumidero y disminuyen el
190
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
consumo promedio de nodos a la misma distancia. Un análisis más extenso
permitirı́a comprobar si el efecto contribuye a prolongar la conectividad que
los sensores más cercanos al sumidero proveen, para poder encaminar una
mayor cantidad de información antes de que la red se particione.
6.2.5.
Experiencia con MiXiM 2.1 y Omnet++ 4.1
La herramienta de simulación seleccionada es gratis y de código abierto,
tiene una comunidad de usuarios bastante pequeña, pero activa. En general
las preguntas a foros de discusión son respondidas. Las utilidades estándares que provee (lı́nea de comandos, ambiente gráfico, ambiente de depuración) permiten trabajar de manera fluida. En especial, la visualización de
la transmisión de mensajes de un nodo a otro en diagramas de secuencia, y
los archivos de eventos fueron de enorme utilidad para depurar los módulos
desarrollados. La ejecución por lotes también es muy fácil de parametrizar,
lo que permitió ajustar los protocolos sin mayores dificultades.
La gran fortaleza de Omnet++ podrı́a decirse que es el desarrollo modular,
y la reutilización de módulos. También lo es la librerı́a de simulación, que da
soporte a la recolección de estadı́sticas de manera sencilla, si bien requiere
bastante programación. Para utilizar variables globales se provee un módulo
pizarra al cual se accede con un mecanismo publisher/subscriber.
Como gran debilidad puede decirse que en MiXiM los módulos agregados se
liberan muy tempranamente, y pueden contener errores de diseño o configuración. Algunos módulos provistos por MiXiM 2.1 y utilizados para este
trabajo, se encontraban en su primera versión o migración de frameworks
anteriores y, por ejemplo, la plantilla para redes de sensores definı́a una frecuencia de transmisión de 2.4 GHz, y una modulación BPSK, cuando en
el estándar IEEE 802.15.4-2006 se establece que a esa frecuencia se utiliza
modulación O-QPSK. Más aún, se descubrió que la sensibilidad configurada
en el módulo de capa fı́sica estaba siendo ignorada, y nodos distantes tenı́an
alcance de radio para comunicarse. En los foros se hallaron comentarios reportando errores en otros módulos de capa de enlace y fı́sica ya liberados.
El aprendizaje llevó un tiempo moderado, algunos problemas al comienzo,
especialmente con la depuración, fueron por trabajar en Windows. La documentación de Omnet++ es bastante completa, y la de MiXiM está incluida
en el código fuente y es buena.
191
6.3. CONCLUSIONES
6.3.
Conclusiones
Para extender la vida útil de las redes inalámbricas de sensores se debe
optimizar el consumo de energı́a en todas las actividades que realizan los
nodos sensores, y la comunicación es una de las tareas de mayor consumo
energético. La optimización en las comunicaciones depende en gran parte
del diseño de los algoritmos de encaminamiento, por lo que han recibido
especial atención en la comunidad cientı́fica interesada en este tipo de redes
durante los últimos años.
En este trabajo se han estudiado los paradigmas de vanguardia en encaminamiento WSN, poniendo especial atención en las técnicas de diseminación
de interés y en algoritmos que tienen consciencia de la energı́a. También se
han estudiado los requerimientos de tráfico de distintos tipos de aplicaciones.
Utilizando el software de simulación Omnet++ se ha configurado una red
de sensores desplegados al azar con una aplicación de consulta iniciada por
el sumidero, para probar el protocolo de diseminación, M-SPIN, el protocolo consciente de la energı́a, SAMF, y un protocolo diseñado mezclando
las técnicas de ambos, EA-SPIN. Se desarrollaron módulos C++ para los
tres algoritmos, y se agregaron y modificaron módulos de recolección de estadı́sticas.
Para el modelo de nodo se utilizó una pila de protocolos IEEE 802.15.4 provista por el framework MiXiM 2.1 con algunas limitaciones en el modelo de
enlace que condicionaron el análisis. Aún ası́, se consideró una mejor opción
utilizar este esquema de trabajo, que simular los algoritmos en forma aislada,
sin un modelo de canal inalámbrico compartido, ya que no se evidenciarı́an
algunos importantes efectos como la interferencia.
Se realizaron simulaciones de ajuste de los parámetros de los protocolos
M-SPIN y EA-SPIN para la red de ejemplo y luego se simularon varios escenarios de consulta iniciada por el sumidero para comparar su desempeño.
La métricas recolectadas indican que las modificaciones realizadas a M-SPIN
producen una mayor tasa de éxito, pero una latencia mucho más larga.
El análisis de consumo de energı́a de transmisión mostró que el consumo
en general es similar o menor en EA-SPIN y que el ahorro se manifiesta
en nodos más cercanos al sumidero, lo cual es esperable porque son los que
encaminan una mayor cantidad de paquetes en favor de nodos más alejados.
Un posterior análisis permitirı́a determinar si esta modificación al patrón
de consumo es mejor y prolonga la conectividad provista por nodos más
cercanos al sumidero.
El resultado de tener en cuenta la capacidad de ruta en M-SPIN, además
de la repetición de anuncios y la suspensión de la negociación si otro nodo con mejor capacidad la inicia primero, fue un consumo de transmisión
moderadamente menor en algunos escenarios para la red de ejemplo.
192
CAPÍTULO 6. SIMULACIÓN Y CONCLUSIONES
6.4.
Resumen de aportes del trabajo
evaluación M-SPIN (Modified Sensor Protocols for Information via
Negotiation) y SAMF (Self-adapting Maximum Flow Routing) en simulaciones de una red con una pila de protocolos IEEE 802.15.4
evaluación de SAFM [59] en simulaciones de un escenario de consulta
por demanda, adoptando las sugerencias de trabajo de Flow Aumentation [12]
evaluación de una variación de M-SPIN, agregando un control de flujo
similar al que utiliza SAFM, continuando el trabajo presentado en [60],
e incluyendo repetición de anuncios para aumentar la confiabilidad
comparación del desempeño en simulaciones de los tres protocolos con
métricas de eficiencia y uso de energı́a
6.5.
Trabajo futuro
Algunas cuestiones interesantes que han quedado fuera del alcance de
este trabajo son:
analizar la sensibilidad de los protocolos a un mayor tamaño de red,
escalabilidad
analizar la sensibilidad a los tiempos de espera en SPIN
estudiar el comportamiento de los protocolos utilizando BMAC para el
acceso al medio y enlace(actualmente MiXiM 2.1 contiene un módulo
BMAC no utilizado en este trabajo)
estudiar el comportamiento utilizando CSMA IEEE 802.15.4-2006 en
modo ranurado (beacon-enabled slotted CSMA-CA)
probar otros patrones de tráfico por consulta, consultas a diferentes
subconjuntos de nodos, tareas diferentes para cada nodo, etc.
implementar una red experimental real para ajustar el modelo y verificar el comportamiento en cuanto a la utilización de la energı́a
analizar los patrones de consumo de energı́a que sugieren los protocolos
y su incidencia en la vida útil de la red
193
6.5. TRABAJO FUTURO
194
Apéndices
195
Apéndice A
Glosario
ASK Amplitude Shift Keying, esquema de modulación que representa información digital por medio de variaciones en la amplitud de la onda portadora.
AES Advanced Encryption Standard, estándar de cifrado por bloques.
Beacon Nodo baliza o trama de señalización.
BER Bit Error Rate, tasa de errores en los bits en un intervalo de tiempo.
BPSK Binary Phase Shift Keying, esquema de modulación digital que representa los datos mediante variaciones en la fase de la onda portadora,
BPSK utiliza dos fases separadas en 180 grados.
Broadcast En un medio compartido, transmisión cuyo destino es la totalidad de los dispositivos en alcance.
C4ISRT Command, control, communications, computing, intelligence, surveillance, reconnaissance and targeting.
CAP Contention Access Period, en enlace CSMA, perı́odo de acceso por
competencia.
197
CCA Clear Channel Assesment, en enlace CSMA, sensado del canal para
determinar si está libre.
CDMA Code Divission Multiple Access, técnica de acceso al medio que permite compartir una banda de frecuencias, que dispersa el ancho de banda de
la señal combinandola con un código pseudo-random de mucha mayor frecuencia, utilizando códigos ortogonales transmisiones de diferentes usuarios
no interfieren entre sı́.
Conjunto dominante conexo Subconjunto de vértices de un grafo tal
que se puede formar un árbol de expansión en el que todos los nodos del
subconjunto no son hojas.
CSMA Carrier Sense Multiple Access, protocolo de acceso al medio.
CSS Chirp Spread Spectrum, técnica de modulación digital de espectro
disperso, que utiliza el total del ancho de banda asignado, y codifica la información mediante pulsos con frecuencia creciente o decreciente.
RTS/CTS Request To Send / Clear To Send, en enlace CSMA, solicitud de
envı́o, y respuesta que permite a otros nodos abstenerse de utilizar el medio
reduciendo colisiones.
DCF Distributed Coordination Function, técnica de acceso al medio utilizada por tecnologı́as basadas en el estándar IEEE 802.11.
Desviación estándar Medida de la distancia de las muestras a la media
aritmética (promedio).
DSSS Direct Sequence Spread Spectrum, técnica de modulación de espectro disperso, que utiliza el total del ancho de banda asignado, y que modula
la señal de información multiplicándola por una cadena continua de pseudoruido, una secuencia de valores 1 y -1 a una frecuencia mucho mayor que la
de la señal original.
EAD Energy-Aware Data Centric Routing, protocolo de encaminamiento
jerárquico centrado en datos.
198
APÉNDICE A. GLOSARIO
ED Energy Detection, Detección de Energı́a, mecanismo de detección de
intensidad de señal de tranceptores.
ERS Expanding Ring Search, búsqueda por expansión en anillo, técnica de
multicasting por rondas, donde en cada ronda el paquete transmitido alcanza nodos a una distancia cada vez mayor del iniciador [67].
Estación Base Nodo recolector o sumidero de datos.
Flow Augmentation Aumentación de flujo, protocolo de encaminamiento
consciente de la energı́a.
Fuente Nodo que genera datos que deben ser encaminados.
Grafo embebido Un grafo puede ser embebido en una superficie si admite
ser dibujado en ella sin intersección de aristas [68]
Graph Routing Encaminamiento por grafo, propuesto por WirelessHART,
donde las rutas se identifican por el grafo al que pertenecen, y el dispositivo
administrador de la red configura múltiples grafos de red que pueden solaparse.
GTS Guaranteed Time Slot, en enlace CSMA, perı́odo de acceso al medio
exclusivo garantizado.
Hopping Secuencia de saltos de frecuencia.
ISM Industrial Scientific and Medical, banda de frecuencias de uso no licenciado.
LEACH Low Energy Adaptive Clustering Hierarchy, protocolo de encaminamiento jerárquico por clústeres.
199
LQI Link Quality Indicator, indicador de la calidad de la señal recibida.
MAC Medium Access Layer, Capa de acceso al medio, según el modelo de
referencia OSI.
MIC Message Integrity Code, código de integridad del mensaje.
Mote Nodo sensor.
Multicast En un medio compartido, transmisión con destino de grupo.
NAV Network Allocation Vector, en enlace CSMA, mecanismo de sensado
y espera por acceso al medio.
NP Nondeterministic polynomial time, clase de complejidad computacional
que pueden ser resueltos en tiempo polinómico (que puede acotarse por un
polinomio de las variables implicadas) por una máquina de Turing no determinista;.
NP-Completo Subconjunto de problemas NP para los que el mejor algoritmo conocido para encontrar una solución es una busqueda exahustiva.
OQPSK Offset Quadrature Phase Shift Keying, esquema de modulación
digital que codifica la información por medio de cambios de fase en la onda
portadora, utilizando 4 valores diferentes de fase.
PAN Personal Areal Network, red de área personal.
Picored Red en Bluetooth.
PHY Physical Layer, Capa Fı́sica, según el modelo de referencia OSI.
200
APÉNDICE A. GLOSARIO
PSSS Parallel Sequence Spread Spectrum, técnica de modulación basada
en el principio CDMA, que codifica una secuencia de datos en paralelo.
Relay Nodo que reenvı́a paquetes en favor de otros nodos.
RSSI Received Signal Strength Indicator, medida de la intensidad de la
señal recibida.
schedule Temporizador o programación de tarea.
SIFS Short Inter Frame Spacing, en redes 802.11, intervalo de tiempo entre
una trama de datos y su acuse de recibo.
SNR Signal to Noise Ratio, relación señal-ruido.
Software Bus Sistema de comunicación de datos que permite intercambiar
información por broadcast, donde los receptores definen los mensajes que
desean recibir según su contenido (servicio publish/subscribe) [69].
Source Routing Encaminamiento en origen, el nodo que emite por primera
vez el paquete especifica la ruta por la que debe encaminarse.
Spanning tree Árbol recubridor o de expansión.
SPIN Sensor Protocols for Information via Negotiation, protocolo de diseminación centrado en datos.
Sumidero Nodo recolector de información.
Superframe Especificación de actividades de comunicación y acceso al medio periódicas.
201
TDMA Time Division Multiplexed Access, tecnologı́a de acceso al medio
para canales compartidos por división del tiempo en ranuras.
Trama Frame.
Tranceptor Radio transmisor y receptor.
Unicast En un medio compartido, transmisión con destino único.
UWB Ultra-wideband, tecnologı́a inalámbrica de comunicación a baja energı́a
y ancho de banda amplio.
WPAN Wireless Personal Area Network, red inalámbrica de área personal.
WSN Wireless Sensor Network, red inalámbrica de sensores.
ZigBee Estándar de comunicación para redes inalámbricas de sensores basado en el estándar IEEE 802.15.4-2003.
202
Apéndice B
Métricas
B.1.
Recopilación de métricas
En [27] se realiza una taxonomı́a de modelos de redes inalámbricas de
sensores. Allı́ se proponen las siguientes métricas para evaluar protocolos
para WSNs:
Métrica
Vida útil del sistema /
Eficiencia
Latencia
Exactitud
Tolerancia a fallas
Escalabilidad
Descripción
Como los nodos utilizan una baterı́a de duración limitada, los
protocolos deben ser eficientes en términos de energı́a. La vida
útil del sistema se puede definir en forma genérica o especı́fica
de la aplicación. De manera genérica por ejemplo, puede definirse como el tiempo hasta que la mitad de los nodos de la red
agota su baterı́a. De manera especı́fica, el tiempo hasta que
la aplicación ya no puede proveer información del fenómeno
sensado, por ejemplo, una región queda sin cobertura.
Se requiere obtener datos del fenómeno con un determinado
retardo, especı́fico de cada aplicación.
La exactitud requerida de la información nuevamente depende
del tipo de aplicación, e impactará en la latencia y eficiencia
con la que se obtendrán los datos. Por ejemplo, pueden requerirse mediciones más frecuentes si se utiliza un único nodo que
si se utiliza un conjunto de nodos.
La red debe ser tolerante a fallas en el sentido en que las
fallas no catastróficas (por ejemplo, de algunos nodos) deben
ocultarse a la aplicación.
Cuán bueno es el comportamiento de la red al aumentar la
densidad o cantidad de nodos.
Cuadro B.1: Métricas de evaluación de protocolos
203
B.1. RECOPILACIÓN DE MÉTRICAS
En [4] se presentan las siguientes métricas de análisis de desempeño:
Métrica
Vida útil del sistema
Eficiencia energética
Confiabilidad
Cobertura
Conectividad
Calidad de Servicio
Descripción
Definida de varias maneras: a) tiempo hasta que un nodo agota
su energı́a; b) tiempo hasta que los requisitos de calidad de
servicio de la aplicación ya no pueden garantizarse; c) tiempo
hasta que la red se particiona.
Cantidad de paquetes que pueden ser exitosamente transmitidos por unidad de energı́a. Las colisiones de frames en la capa
de enlace, el costo indirecto del encaminamiento, la pérdida de
paquetes, y las retransmisiones reducen la eficiencia energética.
La razón de la cantidad de paquetes recibidos con éxito vs. el
total de paquetes transmitidos.
Cobertura total significa que el espacio entero es monitoreado
por los sensores. Si algún sensor deja de ser funcional, debido
al agotamiento de su energı́a, ya no se puede monitorear una
cierta región. La cobertura es la razón del espacio monitoreado
vs. el espacio total.
Para redes multi-salto, la red puede particionarse. La conectividad es una medida de cuan bien conectada está la red, o
cuantos nodos han quedado aislados.
Algunas aplicaciones tienen caracterı́sticas de tiempo real, por
lo que pueden requerirse tasas especı́ficas de retardo, pérdidas
y ancho de banda.
Cuadro B.2: Otras métricas de desempeño
En [26] se repasan múltiples criterios de evaluación. Casi todas las estrategias de evaluación incluyen alguna forma de métrica de energı́a. El autor
se sorprende de que no se vinculen las métricas de energı́a a la calidad de
servicio requerida por la aplicación.
204
APÉNDICE B. MÉTRICAS
Cuadro B.3: Métricas de una revisión de criterios de evaluación
Tipo de métrica
Nombre
la métrica
Uso de energı́a y vida
útil efectiva
Paquetes antes de la
partición
Cantidad de paquetes de datos enviados y recibidos exitosamente antes de
que la red se particione (debido al agotamiento de energı́a de algunos nodos)
Uso de energı́a y vida
útil efectiva
Conectividad después
de la partición
Fracción de enlaces aún activos luego
de la partición. Indica de qué manera
un patrón de tráfico afecta una red.
Uso de energı́a y vida
útil efectiva
Recursos gastados por
paquete entregado
En términos de enlaces (aristas) rotos
por agotamiento de nodos: enlaces rotos / total de paquetes entregados.
Uso de energı́a y vida
útil efectiva
Energı́a disipada promedio
Energı́a total utilizada por nodo / cantidad de eventos detectados
Uso de energı́a y vida
útil efectiva
Energı́a disipada total
Suma del total de energı́a disipada en
todos los nodos
Uso de energı́a y vida
útil efectiva
Distribución de energı́a
Uniformidad de los niveles de energı́a
de los nodos
Overhead y eficiencia
Pérdida de mensajes
Porcentaje de mensajes no recibidos
por ningún nodo de la red
Overhead de control
La razón entre los mensajes de control
vs. los de datos. Algunos autores usan
la razón entre el total de mensajes enviados vs. los recibidos. Otros comparan la tasa de paquetes de aplicación
con la de paquetes de encaminamiento.
Overhead y eficiencia
Tasa de entrega de
eventos
La razón de la cantidad de mensajes de
eventos diferentes recibidos por el sumidero vs. la cantidad de mensajes originalmente enviados por el nodo fuente. Algunos autores utilizan la razón
pérdidas vs. colisiones.
Overhead y eficiencia
Transmisiones por consulta
La razón del total de paquetes enviados
por la cantidad de consultas inyectadas
en la red
Overhead y eficiencia
Longitud promedio de
la ruta
Número de saltos, relacionados al uso
de la energı́a, pero cada autor puede
dar resultados muy diferentes debido a
la relación no lineal entre la potencia
de transmisión y el alcance.
Overhead y eficiencia
Costo en mensajes de
protocolo
La cantidad de paquetes de encaminamiento generados por un algoritmo.
Evaluación temporal
Latencia
El retardo promedio entre la transmisión de un evento y la recepción en el
sumidero.
Evaluación temporal
Tiempo de reacción
Varia según el autor, esencialmente es
el tiempo que tarda el sumidero en recibir un mensaje de datos luego de que
algún cambio ocurre en la red.
Otras
Facilidad de despliegue
Mencionadas en algunos artı́culos.
Overhead y eficiencia
de
Continúa en la página siguiente. . .
205
Descripción
B.2. MÉTRICAS DE SIMULACIONES ESPECÍFICAS
Tipo de métrica
Otras
Otras
Otras
B.2.
Cuadro B.3 – Continuación
Nombre
de
Descripción
la métrica
A pesar de que algunas técnicas requieren de la configuración de un gran
Sensibilidad
a
los
número de parámetros, esta métrica no
parámetros
es muy utilizada.
Requerimientos de almacenamiento
La cantidad de memoria requerida por
cada nodo
Escalabilidad
Como varı́a el comportamiento del protocolo al variar la densidad de nodos,
la cantidad de nodos, y la cantidad de
fuentes y sumideros.
Métricas de simulaciones especı́ficas
En [62] se evalúa a SPIN utilizando las siguientes métricas:
Métrica
Tasa de éxito
Eficiencia energética
Cantidad de saltos de
la ruta
Descripción
La probabilidad de entregar exitosamente los paquetes
de datos a los nodos interesados.
La cantidad de nodos que reenvı́an cuando la tasa de
éxito es 1 (no es lo mismo que hop count?).
La cantidad de saltos entre el nodo origen y el nodo
que solicita el dato.
Cuadro B.4: Métricas de evaluación del protocolo SPIN
Ası́ mismo, en [63], se evalúa un protocolo orientado a mantener la conectividad de una red de nodos estacionarios desplegados al azar, maximizando
la vida útil de la red. Cada nodo sensa el medio ambiente en forma periódica y produce datos que deben ser comunicados a un único sumidero, a una
tasa constante. En este trabajo se compara el desempeño con los protocolos
descriptos en [12].
Métrica
Vida útil de los nodos
Descripción
Se dice que un nodo sensor muere cuando agota su
energı́a o no existe una ruta al sumidero.
Tiempo hasta que la
red se particiona
Proceso de cobertura
Fracción de el espacio cubierta por los nodos, que decrece a medida que los nodos mueren.
Cuadro B.5: Métricas de evaluación del protoclo PBR
206
APÉNDICE B. MÉTRICAS
También, en [39], se muestran resultados de simulaciones de evaluación
de EAD. El protocolo construye un árbol de encaminamiento para enviar
datos a un único sumidero.
Métrica
Cantidad de nodos activos
Rendimiento
Consumo de energı́a
Descripción
Indica la cantidad de fallas de nodo debido a la baja de
energı́a con el paso del tiempo. La falla se caracteriza
por la incapacidad de generar paquetes, definida por
un umbral de energı́a disponible.
Volumen de datos transmitido al sumidero a medida
que pasa el tiempo.
Total de energı́a empleada por la red a medida que pasa el tiempo. Muestra la capacidad de ahorrar energı́a
del algoritmo.
Cuadro B.6: Métricas de evaluación del protocolo EAD
207
B.2. MÉTRICAS DE SIMULACIONES ESPECÍFICAS
208
Apéndice C
Modificaciones a MiXiM 2.1
C.1.
Energı́a de transmisión
Para poder totalizar la energı́a de transmisión, y habilitar el cálculo de
estadı́sticas, se modificó el módulo de baterı́a, para permitir el acceso público
a los totales de consumo por actividad, agregando el método getActivityTotal() que se muestra en el fragmento de código C.1:
Fragmento de código C.1: Método getActivityTotal()
1
2
3
4
5
6
7
8
9
10
11
double SimpleBattery::getActivityTotal(int act) {
double total = 0;
for (int i = 0; i < numDevices; i++) {
for (int j = 0; j < devices[i].numAccts; j++) {
if (j == act) {
total += devices[i].accts[j];
}
}
}
return total;
}
La modificación permitió también a los módulos de protocolo consultar
el consumo acumulado por actividad, por ejemplo, en transmisiones.
C.2.
Total de mensajes
Para que se graben estadı́sticas sobre el total de paquetes enviados, se
necesita utilizar la utilidad Blackboard. El Blackboard es un módulo que
permite encapsular variables globales, permitiendo un intercambio de información de estilo pizarra entre los módulos.
La red WSNRouting utiliza un módulo de seguimiento, que se suscribe a la
pizarra, para ser notificado cuando la aplicación envı́a o recibe un paquete.
Para utilizar un módulo de seguimiento más completo y personalizado, el
209
C.2. TOTAL DE MENSAJES
mismo se hace configurable, modificando la definición de la red WSNRouting.ned, como se muestra en el fragmento de código C.2:
Fragmento de código C.2: Redefinición del módulo de rastreo
1
2
3
4
5
network WSNRouting {
parameters:
string tracerType = default("SimTracer"); //type of the network layer
submodules:
simTracer: <tracerType> {}
Para poder extender y mejorar la clase SimTracer se debió hacer que la
herencia de ImNotifiable sea pública, como se muestra en el fragmento de
código C.3:
Fragmento de código C.3: Herencia pública de ImNotifiable para SimTracer
1
2
class SimTracer:public cSimpleModule, public ImNotifiable
{
Se creó la clase NetworkTracer que es notificada sobre la publicación de
un ı́tem global de tipo cPacket en la pizarra, que comunica cada paquete
enviado y recibido, de red o aplicación, y cada paquete de red superfluo. El
proceso de las notificaciones se muestra en el fragmento de código C.4:
Fragmento de código C.4: Total de paquetes a partir de notificaciones
1
2
3
4
5
6
class NetworkTracer : public SimTracer
{
public:
virtual void receiveBBItem(int category, const BBItem * details,
int scopeModuleId);
}
7
8
9
10
11
void NetworkTracer::receiveBBItem(int category, const BBItem * details,
int scopeModuleId)
{
cModule * module = simulation.getModule(scopeModuleId);
12
13
14
15
16
17
18
19
20
21
22
23
24
if (category == catPacket) {
if (strcmp(module->getName(), "net") == 0) {
packet = *(static_cast<const Packet*>(details));
if(packet.isSent()) {
nbNetwPacketsSent++;
} else {
nbNetwPacketsOverhear++;
}
} else {
SimTracer::receiveBBItem(category, details, scopeModuleId);
}
} else if (category == catHostState){
210
APÉNDICE C. MODIFICACIONES A MIXIM 2.1
25
26
...
}
Las notificaciones son publicadas en la pizarra por el módulo de red,
como se ilustra en el fragmento de código C.5:
Fragmento de código C.5: SPIN publica paquetes envı́ados y de sobreescucha
1
2
3
4
5
6
7
void SPIN::publishPacketOverhear(){
packet.setPacketSent(false);
packet.setNbPacketsSent(0);
packet.setNbPacketsReceived(1);
packet.setHost(myNetwAddr);
world->publishBBItem(catPacket, &packet, getId());
}
8
9
10
11
12
13
14
15
void SPIN::publishPacketSent(){
packet.setPacketSent(true);
packet.setNbPacketsSent(1);
packet.setNbPacketsReceived(0);
packet.setHost(myNetwAddr);
world->publishBBItem(catPacket, &packet, getId());
}
C.3.
Energı́a residual
En MiXiM, el módulo que graba totales de baterı́a se llama BatteryStats, pero algunos valores necesarios para el análisis en este trabajo no son
grabados. Para poder grabar la energı́a residual al terminar la simulación,
se modificó BatteryStats.cc como se muestra en el fragmento de código C.6:
Fragmento de código C.6: Grabación de la energı́a residual al finalizar
1
2
3
4
void BatteryStats::summary(double init, double final, simtime_t lifetime)
{
recordScalar("final", final, "mW-s");
...
Para poder identificar a qué actividad corresponde el consumo registrado
se modificó la descripción del valor, según el fragmento de código C.7:
Fragmento de código C.7: Grabación del consumo por actividad
1
2
3
4
5
6
void BatteryStats::detail(DeviceEntry *devices, int numDevices)
{
for (int j = 0; j < devices[i].numAccts; j++) {
// Record activity energy
stringstream activitySummary;
211
C.4. SENSIBILIDAD
activitySummary << "activity-" << j;
recordScalar(activitySummary.str().c_str(), devices[i].accts[j]);
7
8
9
...
C.4.
Sensibilidad
Se modificó el módulo Decider802154Narrow para que se descarten frames que se reciben con una potencia de transmisión menor que la sensibilidad del tranceptor. La modificación se muestra en el fragmento de código C.8
Fragmento de código C.8: Descarte por baja intensidad en Decider802154Narrow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
simtime_t Decider802154Narrow::processNewSignal(AirFrame* frame) {
Signal& s = frame->getSignal();
simtime_t time = MappingUtils::post(s.getSignalStart());
double rcvPower = s.getReceivingPower()->getValue(Argument(time));
...
// check whether signal is strong enough to receive
if ( rcvPower < sensitivity )
{
// Discard frame
return notAgain;
}
...
}
Con la modificación mostrada, los frames que no llegan con la intensidad
de señal mayor que la sensibilidad son descartados. De esta manera con una
potencia de transmisión de 1 mW se logra un alcance aproximado de 85 m.
212
Referencias
[1] Neha Jain. Energy Aware Adaptive Routing Protocols in Wireless Sensor Networks. PhD thesis, University of Cincinnati, 2004.
[2] Suyoung Yoon. Power Management in Wireless Sensor Networks. PhD
thesis, North Carolina State University, 2007.
[3] Libelium. Libelium Environment - http://www.libelium.com/ applications/Environment, 2010.
[4] Kazem Sohraby, Daniel Minoli, and Taieb Znati. Wireless Sensor Networks. Wiley, 2007 edition, 2007.
[5] Levente Butty and Gergely Ács. A Taxonomy of Routing Protocols for
Wireless Sensor Networks, 2007.
[6] ZigBee Alliance. ZigBee Specification, 2008.
[7] Najet Boughanmi and YeQiong Song. Improvement of Zigbee routing
protocol including energy and delay constraints, 2007.
[8] Charles E Perkins and Elizabeth M Royer. Ad-hoc On-Demand Distance Vector Routing. In Proceedings Of The 2nd IEEE Workshop On
Mobile Computing Systems And Applications, pages 90–100, 1997.
[9] Ouadoudi Zytoune, Youssef Fakhri, and Driss Aboutajdine. Lifetime
Optimization for Wireless Sensor Networks. IEEE/ACS International Conference on Computer Systems and Applications, pages 816–820,
2009.
[10] Jamal N Al-Karaki and Ahmed E Kamal. Routing Techniques in Wireless Sensor Networks : A Survey. Wireless Communications, IEEE,
11(6):6–28, 2004.
[11] K Akkaya and M Younis. A Survey on Routing Protocols for Wireless
Sensor Networks. Ad Hoc Networks, 3:325–349, 2005.
[12] Jae-hwan Chang and Leandros Tassiulas. Maximum Lifetime Routing
in Wireless Sensor Networks. IEEE/ACM Transactions On Networking,
12:609–619, 2004.
213
REFERENCIAS
[13] Charles Pandana and K J Ray Liu. Maximum Connectivity and Maximum Lifetime Energy-aware Routing for Wireless Sensor Networks.
Global Telecommunications Conference, 2:1034–1038, 2005.
[14] Yeling Zhang, Ramkumar Mahalingam, and Nasir Memon. Information
Flow Based Routing Algorithms for Wireless Sensor Networks. Global
Telecommunications Conference, 2:742–747, 2004.
[15] Vahid Shah-mansouri and Vincent W S Wong. Distributed Maximum
Lifetime Routing in Wireless Sensor Networks Based on Regularization.
Global Telecommunications Conference, pages 598–603, 2007.
[16] Shinya Ito and Kenji Yoshigoe. Consumed-Energy-Type-Aware Routing for Wireless Sensor Networks. Wireless Telecommunications Symposium, pages 1–6, 2007.
[17] Rahul C Shah and Jan M Rabaey. Energy Aware Routing for Low
Energy Ad Hoc Sensor Networks. Wireless Communications and Networking Conference, 1:350–355, 2002.
[18] Chalermek Intanagonwiwat, Ramesh Govindan, and Deborah Estrin.
Directed Diffusion : A Scalable and Robust Communication Paradigm
for Sensor Networks. In MOBICOM, pages 56–67. ACM, 2000.
[19] I F Akyildiz, W Su, Y Sankarasubramaniam, and E Cayirci. Wireless
sensor networks : a survey. Computer Networks, 38:393–422, 2002.
[20] Tampere University of
http://www.tkt.cs.tut.fi/
2011.
Technology.
WIREPAS Project research/daci/cp wirepas overview.html,
[21] Jennifer Yick, Biswanath Mukherjee, and Dipak Ghosal. Wireless sensor network survey. Computer Networks, 52:2292–2330, 2008.
[22] Holger Karl and Andreas Willig. Protocols and Architectures for Wireless Sensor Networks. Wiley, 2005.
[23] TinyOS. http://www.tinyos.net/, 2011.
[24] MEMSIC. MICAz Datasheet - http://www.memsic.com/support/
documentation/wireless-sensor-networks/
category/7datasheets.html?download=148 %253Amicaz, 2011.
[25] Yingshu Li, My T. Thai, and Weili Wu, editors. Wireless Sensor Networks and Applications. Spinger, 2008.
[26] Ronan Mac Ruairı́, Mark T Keane, and Gerry Coleman. A Wireless
Sensor Network Application Requirements Taxonomy. Sensor Technologies and Applications, pages 209–216, 2008.
214
REFERENCIAS
[27] Sameer Tilak, Nael B Abu-ghazaleh, and Wendi Heinzelman. A Taxonomy of Wireless Micro-Sensor Network Models. ACM Mobile Computing And Communications Review, 6:28–36, 2002.
[28] IEEE. IEEE 802.15.4a-2007 Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs) Amendment 1: Add Alternate PHYs.
2007(August), 2007.
[29] Shahin Farahani. Zigbee Wireless Networks and Transceivers. Elsevier,
2008.
[30] ZigBee Alliance. ZigBee Standards - http://www.zigbee.org/ Standards/Overview.aspx, 2011.
[31] IEEE. IEEE 802.15.4-2006 Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs). Control, 2006(September), 2006.
[32] Jianping Song, Song Han, Aloysius K Mok, Deji Chen, Mike Lucas,
Mark Nixon, and Wally Pratt. WirelessHART : Applying Wireless Technology in Real-Time Industrial Process Control. Real-Time and Embedded Technology and Applications Symposium, pages 377–386, 2008.
[33] IEC. IEC 62591 Ed. 1.0 Industrial communication networks - Wireless
communication network and communication profiles - WirelessHART,
2010.
[34] HARTCOMM. WirelessHART - http://www.hartcomm.org/ protocol/wihart/wireless how it works.html, 2011.
[35] Tomas Lennvall and Stefan Svensson. A Comparison of WirelessHART
and ZigBee for Industrial Applications. Factory Communication Systems, pages 85–88, 2008.
[36] Azzedine Boukerche, Mohammad Z Ahmad, Begumhan Turgut, and
Damla Turgut. A Taxonomy of Routing Protocols in Sensor Networks,
pages 129 –160. Wiley-IEEE Press, 1 edition, 2008.
[37] W Heinzelman, A Chandrakasan, and H Balakrishnan. Energy-Efficient
Communication Protocol for Wireless Microsensor Networks. Proceedings of the 33rd Hawaii International Conference on System Sciences,
2, 2000.
[38] Ananth Rao, Sylvia Ratnasamy, Christos Papadimitriou, Scott Shenker,
and Ion Stoica. Geographic Routing without Location Information. In
Mobile computing and networking, pages 03–218. ACM, 2003.
215
REFERENCIAS
[39] Azzedine Boukerche, George Washington, and Joseph Linus. EnergyAware Data-Centric Routing in Microsensor Networks. In Modeling
analysis and simulation of wireless and mobile systems, pages 42–49.
ACM, 2003.
[40] Tayseer Al-khdour and Uthman Baroudi. A Generalized Energy-Aware
Data Centric Routing for Wireless Sensor Network. In Signal Processing
and Communications, number November, pages 24–27. IEEE, 2007.
[41] Antonio Carzaniga and Alexander L Wolf. Content-Based Networking
: A New Communication Infrastructure, 2002.
[42] Wendi Rabiner Heinzelman, Joanna Kulik, and Hari Balakrishnan.
Adaptive Protocols for Information Dissemination in Wireless Sensor
Networks. pages 174–185, 1999.
[43] F Zabin, S Misra, I Woungang, HF Rashvand, N-W A, and M Ahsan
Ali. REEP: data-centric, energy-efficient, reliable routing protocol for
wireless sensor networks. Communications, IET, 2(8):995– 1008, 2008.
[44] Michele Mastrogiovanni, Chiara Petrioli, Michele Rossi, Andrea Vitaletti, and Michele Zorzi. Integrated Data Delivery and Interest Dissemination Techniques for Wireless Sensor Networks. Global Telecommunications Conference, pages 1–6, 2006.
[45] Lorenzo Orecchia, Ro Panconesi, Chiara Petrioli, and Andre Vitaleti.
Localized Techniques for Broadcasting in Wireless Sensor. In DIALMPOMC. ACM Press, 2004.
[46] Joanna Kulik and Wendi Heinzelman. Negotiation-Based Protocols
for Disseminating Information in Wireless Sensor Networks. Wireless
Networks, 8:169–185, 2002.
[47] Mike Woo and Suresh Singh. Power-Aware Routing in Mobile Ad Hoc
Networks, 1998.
[48] Leandros Tassiulas and Jae-hwan Chang. Routing for Maximum System Lifetime in Wireless Ad-hoc Networks. In 37-th Annual Allerton
Conference on Communication, Control, and Computing, 1999.
[49] C.-K. Toh. Maximum Battery Life Routing to Support Ubiquitous Mobile Computing in Wireless Ad Hoc Networks. IEEE Communications
Magazine, 39(6):138–147, 2001.
[50] Jae-hwan Chang and Leandros Tassiulas. Energy Conserving Routing
in Wireless Ad-hoc Networks. In INFOCOM 2000. Nineteenth Annual
Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, pages 22–31. ATIRP, 2000.
216
REFERENCIAS
[51] OpenSim. Omnet++ User Manual, 2010.
[52] The Eclipse Foundation. Eclipse - http://www.eclipse.org/, 2011.
[53] Xiaodong Xian, Weiren Shi, and He Huang. Comparison of OMNET
++ and Other Simulator for WSN Simulation. In Industrial Electronics
and Applications, pages 1439–1443. IEEE, 2008.
[54] C Mallanda, A Suri, V Kunchakarra, S S Iyengar, R Kannan, and A Durresi. Simulating Wireless Sensor Networks with OMNeT ++, 2005.
[55] Ugo Maria Colesanti, Carlo Crociani, and Andrea Vitaletti. On the
Accuracy of OMNeT ++ in the Wireless Sensor Networks Domain :
Simulation vs . Testbed. In Proceedings of the 4th ACM workshop
on Performance evaluation of wireless ad hoc, sensor,and ubiquitous
networks. ACM, 2007.
[56] MiXiM. MiXiM - http://mixim.sourceforge.net/, 2011.
[57] Jérôme Rousselot, Jean-Dominique Decotignie, Marc Aoun, Peter van
Der Stok, Ramon Serna Oliver, and Gerhard Fohler. Accurate Timeliness Simulations for Real-Time Wireless Sensor Networks. In EMS ’09
Proceedings of the 2009 Third UKSim European Symposium on Computer Modeling and Simulation. IEEE, 2009.
[58] Texas Intruments. 2.4 GHz IEEE 802.15.4 / ZigBee-ready RF Transceiver Datasheet, 2010.
[59] Alessandro Bogliolo, Saverio Delpriori, Emanuele Lattanzi, and Andrea
Seraghiti. Self-adapting maximum flow routing for autonomous wireless
sensor networks. Cluster Computing, 14(1), 2011.
[60] Zeenat Rehena and Sarbani Roy. A Modified SPIN for Wireless Sensor
Networks. In Communication Systems and Networks, pages 1–4, 2011.
[61] Xiangyang Li and Yajun Wang. Random Deployment of Wireless Sensor Networks : Power of Second Chance. In The 15th International
Computing and Combinatorics Conference, 2009.
[62] Dandan Liu, Xiaodong Hu, and Xiaohua Jia. Energy efficient information dissemination protocols by negotiation for wireless sensor networks.
Computer Communications, 29(11):2136–2149, 2006.
[63] Praveen Kumar, Joy Kuri, Pavan Nuggehalli, Mario Strasser, Martin
May, and Bernhard Plattner. Connectivity-aware Routing in Sensor
Networks. Sensor Technologies and Applications, pages 387–392, 2007.
217
REFERENCIAS
[64] Dazhi Chen and Pramod K Varshney. QoS Support in Wireless Sensor
Networks: A Survey. In International Conference on Wireless Networks,
2004.
[65] Nicola Santoro. Design and Analysis of Distributed Algorithms. Wiley,
2007.
[66] Dimitri P. Bertsekas Tsitsiklis and John N. Parallel and Distributed
Computation: Numerical Methods. Athena Scientific, 1997.
[67] Damien Magoni and Jean-jacques Pansiot. Oriented Multicast Routing
Algorithm Applied to Network-level Agent Search. Discrete Mathematics And Theoretical Computer Science, pages 255–272, 2001.
[68] Petra Mutzel and René Weiskircher. Computing Optimal Embeddings
for Planar Graphs. In Proceedings COCOON ’00 volume 1858 of LNCS,
pages 94–104. Springer Verlag, 2000.
[69] Ivy. Ivy Software Bus - http://www2.tls.cena.fr/ products/ivy/about.shtml, 2011.
218