capÍtulo 6. diseÑo del nivel de red y ... -...
TRANSCRIPT
120
CAPÍTULO 6.
DISEÑO DEL NIVEL DE RED Y PROGRAMACIÓN DE LOS
WASPMOTES.
Una vez realizado el estudio de planificación radioeléctrica de la red (parte física), el
siguiente paso es el diseño de un nivel de red para la misma y la programación de los
Waspmotes para permitir la comunicación desde cualquiera de los nodos con la oficina central.
Como zona de estudio se han elegido 4 nodos en torno al nodo de la oficina central, con el fin
de facilitar la realización de las pruebas.
Figura 6.1: Zona de pruebas del canal y estructura lógica de la red en la misma.
Puesto que este proyecto se ha centrado en la parte de comunicaciones de la red ya que no se
extraen datos reales de las almenaras ni caudalímetros y nuestro objetivo es simplemente
mostrar una alternativa al sistema de comunicaciones existente, los Waspmotes se han
programado de tal forma que se pueda:
Comprobar el correcto funcionamiento del protocolo de red: Demostrando que el
encaminamiento funciona y los nodos buscan la ruta óptima, alterando la topología de
manera dinámica, ante situaciones de caída o reactivación de nodos.
Realizar medidas de la calidad de los enlaces: Para poder ver el nivel de señal real
recibido en los extremos de los radioenlaces y comprobar el ratio nº de paquetes
recibidos correctos / nº total de reenvíos realizados para entregar dichos paquetes.
121
Simular una red de sensores que realizan medidas desde diferentes puntos y las
envían a un centro donde se monitorizan y procesan: Para ello, además de la
información útil para el protocolo de red que permite la comunicación entre los nodos,
se envían medidas tomadas de los Waspmotes (Temperatura del RTC, Nivel de Batería,
Duty Cycle y la fecha y hora en que se toman). Evidentemente, en la realidad las
medidas se tomarían desde sensores situados en las almenaras y los caudalímetros.
6.1. Diseño del nivel de red.
Como se explicó en el apartado 4.2.3., el protocolo RF de Digi que utilizan los xBee 868
encargados de las comunicaciones de los Waspmotes, no implementan un Nivel de Red.
El protocolo sí dispone de una capa MAC o Nivel de Enlace, que garantiza:
Entrega fiable punto a punto mediante la realización de retransmisiones y
asentimientos.
Comprobación de la integridad de las tramas recibidas mediante un código de
redundancia cíclica (CRC).
Según el modelo OSI, el objetivo de un nivel de red es hacer que los paquetes lleguen desde un
origen a un determinado destino mediante un adecuado encaminamiento, ya sea dentro de
una misma red, o entre diferentes redes. Para poder identificar el nodo de origen y destino,
dentro de la red, es necesario un direccionamiento, es decir, que los nodos tengan una
dirección que los identifique de manera unívoca en la red. Otras funciones definidas son el
control de congestión (aunque en el modelo TCP/IP, de esto se encarga la capa de transporte y
no la de red), el control de errores (en el modelo TCP/IP, el nivel IP añade un pequeño control
de errores con un CRC) y la interconexión de diferentes tecnologías de nivel de enlace.
En resumen, para diseñar un nivel de red los dos elementos básicos son:
Direccionamiento: Para identificar de manera unívoca a los nodos ya sea dentro de la
misma red o entre redes.
Encaminamiento: Conexión entre dos nodos cualesquiera de la red o entre redes (si
hay más de una) calculando la mejor ruta entre las posibles.
Los nodos de un nivel de red se suelen clasificar en nodos finales (los que generan y reciben
paquetes) y nodos intermedios (los que conducen los paquetes a su destino). Poniendo como
ejemplo Internet, un nodo final sería un PC y un nodo intermedio, un router. En el caso de la
red del canal, todos los nodos actuarán como nodos intermedios y finales ya que producen
paquetes con información de monitorización y a la vez, actúan como routers encaminando
paquetes hacia el nodo de la oficina donde se monitorizan los datos.
El direccionamiento puede ser jerárquico, como es el caso de las direcciones IP, o plano, como
es el caso de las direcciones MAC.
El encaminamiento se puede clasificar, de manera simplificada:
122
En función de dónde se decide encaminar.
o Fijado en el origen. Los sistemas finales fijan la ruta.
o Salto a salto. Los sistemas intermedios van calculando la ruta.
En función de la adaptabilidad.
o Estático. Las tablas de encaminamiento de los nodos se fijan de forma manual
y no cambian.
o Dinámico. Las tablas de encaminamiento cambian de forma automática. A su
vez, puede clasificarse en:
Centralizado: La información de encaminamiento se envía desde un
nodo central y se rellenan todas las tablas de encaminamiento de los
nodos.
Aislado: No se tiene en cuenta la información de los otros nodos a la
hora de encaminar
Distribuido: Rellenan sus tablas de encaminamiento a partir de
cualquiera de los demás nodos adyacentes.
6.1.1. Elección del tipo de direccionamiento y encaminamiento.
La elección de un tipo de direccionamiento y encaminamiento, depende de las
necesidades de la red.
En el caso del proyecto, la estructura de la red presenta las siguientes características:
1. Número de nodos limitado y sin expectativas de gran crecimiento.
2. Emplazamiento de los nodos fijo.
3. Número de rutas alternativas posibles limitada por el nivel físico (radioenlaces).
4. Homogeneidad de la tecnología.
6.1.1.1. Direccionamiento.
Debido a que se cuenta con un número limitado de nodos, en emplazamientos fijos,
con expectativas limitadas de crecimiento y puesto que no existe más que una red, se ha
optado por la elección de un direccionamiento plano.
Al contrario que el existente en la red actual, que se basa en direcciones IP locales, las
opciones que ofrece el protocolo de RF de Digi para el direccionamiento eran básicamente
tres, como se vio en el apartado 4.2.1.:
Dirección MAC.
Identificador de nodo (NI).
Identificador de red (NA).
En un principio se pensó en utilizar las direcciones NA o NI para el nivel de red, pero el
problema es que para transmisiones unicast, la única posibilidad es utilizar direcciones MAC.
Usar sólo las direcciones MAC era una opción válida ya que sólo se cuenta con una red, de la
123
misma tecnología y con un número limitado de unidades, pero se ha optado por usar unas
direcciones de red para facilitar el direccionamiento de los nodos y la creación de los mensajes
de monitorización y que los nodos sean más fácilmente identificables por la persona que
observa la monitorización del canal.
Por tanto, lo que se ha hecho es:
Usar las direcciones MAC para el nivel de enlace.
Crear una nuevas direcciones de red llamadas NA (haciendo abuso de notación), con
la siguiente nomenclatura:
Nodo 00XY: Donde, X es el número de tramo del canal e Y es el número de nodo. Con
la excepción del nodo Oficina, que se denota con ‘0000’, por ser un nodo “especial”
donde se recogen los datos de todo el canal.
Figura 6.2: Direccionamiento de los nodos de la red.
124
Si bien el direccionamiento no es jerárquico y no existen subredes, como en el caso de las
direcciones IP, el hecho de introducir direcciones NA frente a las MAC, permite agrupar en
tramos los nodos del canal (tramos 1, 2, 3 4 y 5), facilitando una especie de “sumarización” o
agrupamiento de direcciones en las tablas de encaminamiento y limitando el número de
cálculos necesarios en caso de que se desee hacer un enrutamiento desde la oficina a
cualquier nodo. En el proyecto sólo se ha contemplado el caso de que los nodos transmitan
información de monitorización a la Oficina y por tanto, la dirección de destino siempre es la
‘0000’ pero podría hacerse también que la Oficina enviara información a cualquier nodo.
El Waspmote Gateway no tiene dirección de red, ya que no forma parte de la misma, todos los
mensajes que llegan al nodo de Oficina se reenvían al Gateway.
No existe un protocolo de “resolución de direcciones de red” tipo ARP ya que, al ser tan
limitado el número de nodos es más eficiente directamente incluir en las tablas de
encaminamiento las correspondencias MAC – dirección NA.
6.1.1.2. Encaminamiento.
En lo que respecta al encaminamiento, por los mismos motivos ya expuestos y porque
las posibles rutas alternativas están limitadas por los radioenlaces, se ha elegido un modelo
estático.
Las tablas de encaminamiento se consideran estáticas ya que están fijadas de antemano de
manera manual por el programador, no obstante, el cálculo de la ruta óptima sí es dinámico y
se realizará a partir de la información encaminamiento que obtengan los nodos a través de dos
tipos de mensaje: Keepalives de tipo Node y Keepalives de tipo Link. Los primeros son
mensajes que envían los propios nodos hacia la Oficina y los segundos, mensajes recibidos de
manera periódica desde los nodos adyacentes.
En general, en los algoritmos de encaminamiento, los nodos intermedios o encaminadores a la
hora de elegir una ruta necesitan una métrica para decidir cuál es la ruta mejor. Un ejemplo
puede ser, el número de saltos, el retardo, etc.
Figura 6.3: Cálculo de ruta en el nodo Ctra. Utrera.
125
En el caso de la red bajo estudio, debido a su topología y a las limitaciones que impone el
medio físico radioeléctrico (radioenlaces de muy largo alcance y nodos fijos), no hay
alternativas. La ruta óptima siempre será la que vaya por un radioenlace primario, puesto que
es la que garantiza que habrá menor pérdida de paquetes, menos retransmisiones, etc. La 2ª
opción será el mejor radioenlace secundario en lo que respecta a calidad de enlace (RSSI), y así
sucesivamente.
En la figura 6.3. se puede ver esto con un ejemplo del nodo de Ctra. Utrera. El nodo enviará
por orden de prioridad Keepalives de tipo Node primero a la primera opción (en este caso, el
nodo 0042) y lo reintentará varias veces (se ha elegido un máximo de 4 reintentos de nivel de
red, cada uno con sus correspondientes 10 retransmisiones de capa MAC). Una vez superado
ese número de reintentos, se pasará al siguiente salto posible (nodo 0043) y volverá a realizar
el proceso, y así hasta llegar a la última posibilidad de la tabla de encaminamiento. De esto se
hablará más en el siguiente apartado.
Si el medio físico hubiera sido otro, por ejemplo cableado o incluso radio, pero con distancias
cortas, y la prioridad fuera por ejemplo conseguir un retardo bajo en las comunicaciones o una
gran tasa de transmisión, se podría haber elegido otra métrica para elegir la ruta, como por
ejemplo el número de saltos o el retardo de transmisión. Sin embargo, puesto que los
radioenlaces son de larga distancia, el volumen de datos es pequeño, los mensajes son
repetitivos (son mensajes de monitorización) y la tasa de transmisión es baja, se ha elegido
como métrica la RSSI (nivel de señal recibido) en el siguiente salto. Es decir, que el enlace que
una al siguiente salto con el nodo emisor sea el de mayor calidad.
6.1.2. Algoritmo de encaminamiento.
Como ya se anticipó en el apartado anterior, el algoritmo de encaminamiento hace uso
de dos tipos de mensaje para decidir cuál debe ser el siguiente salto o “Next Hop” y garantizar
así que se está tomando la ruta óptima (aquella que hace uso de los radioenlaces con mejor
RSSI). Estos mensajes son:
Keepalive de tipo Node.
Keepalive de tipo Link.
Los mensajes de Keepalive de tipo Node, como se verá en el apartado 6.2.1.1., tienen tres
objetivos:
1. Informar al nodo receptor que los nodos no están caídos.
2. Servir al algoritmo de encaminamiento para seleccionar un camino u otro.
3. Monitorizar.
Estos mensajes se envían cada 30 segundos al siguiente salto, sirviendo para el
encaminamiento y para la monitorización. En este apartado nos centraremos en el punto 2, ya
126
que estos mensajes se emplean para elegir la ruta adecuada, actualizando la tabla de
encaminamiento en caso de que sea necesario.
Por otra parte, los mensajes de Keepalive de tipo Link, se envían cada 5 minutos desde cada
nodo a todos los nodos adyacentes, y tienen como objetivo informar por parte de dicho nodo
a sus adyacentes de que el mismo sigue vivo y por tanto el radioenlace que los une, también.
De ahí el nombre “Link”.
Figura 6.4: Algoritmo de encaminamiento.
El diagrama de flujo del algoritmo de encaminamiento se muestra en la figura 6.4. En dicha
figura se observa que se ejecutan dos bucles infinitos en paralelo, uno que se repite cada 30
segundos, y otro cada 5 minutos.
En el primer bucle, cada nodo envía un mensaje de Keepalive a su “Next Hop” (siguiente salto)
y si no hay problema, no realiza nada. El Keepalive llegará al siguiente nodo y se reenviará
hasta llegar al nodo 0000 que lo entregará al Waspmote Gateway.
En caso de que no se reciba ACK en la trama MAC enviada, se reintentará (se enviará el
paquete de nuevo), comprobando que el número de reintentos no es mayor que 4. Si se
supera ese límite, se supone que el enlace con ese “Next Hop” está caído, y se actualiza la
127
tabla de encaminamiento, eligiendo como “Next Hop” a la siguiente posición de la tabla de
encaminamiento.
Un ejemplo de esto se puede ver en la figura 6.5. Por simplicidad se han escrito en las
tablas de encaminamiento las direcciones NA sólo, pero las MACs estarían también, como ya
se explicó en el apartado anterior.
Figura 6.5: Ejemplo de retransmisiones y actualización de la tabla de encaminamiento.
En caso de que se llegara a la última posibilidad de “Next Hop” de la tabla de encaminamiento,
pues no habría solución, todos los enlaces estarían caídos y el nodo no tendría comunicación
con el resto de la red hacia el nodo central. Esto es una limitación, pero es inevitable dado a los
radioenlaces de largo alcance y a la limitación geográfica a la que están dispuestos los nodos
(deben situarse dentro de la zona del canal y preferiblemente en sitios donde haya una
almenara o caudalímetro). A pesar de ello, se vuelve a seleccionar la primera posición de la
tabla de encaminamiento y se espera hasta que se vuelva a intentar transmitir el siguiente
Keepalive, con la esperanza de que esta vez el proceso funcione.
En el segundo bucle (figura 6.4), los nodos informan de manera periódica (cada 5 minutos) a
sus nodos adyacentes de que siguen vivos mediante los mensajes de Keepalive de tipo Link. Si
el nodo recibe un Keepalive de tipo Link de un nodo adyacente, y el RSSI de dicho nodo es
mejor que el Next Hop actual seleccionado, se actualiza la tabla de encaminamiento eligiendo
como Next Hop el origen del Keepalive Link recibido. De esta forma, se garantiza que si un
nodo cae, avise a los adyacentes para que actualicen sus tablas y la ruta elegida siempre sea la
óptima (aquella que pase por los radioenlaces con mejor RSSI en su destino).
128
Según lo que hemos visto, hay dos tipos de mensaje utilizados para calcular la ruta por el
algoritmo de encaminamiento (en la figura 6.6 se ven como KA-Node y KA-Link):
Keepalive tipo Node: Se envían al siguiente salto con destino oficina cada 30 segundos
y además se aprovechan para transportar información de monitorización.
Keepalive tipo Link: Se envían a los nodos adyacentes cada 5 minutos.
Figura 6.6: Ejemplo de reactivación de nodo, actualización de tabla de encaminamiento y cálculo de ruta
óptima de nuevo.
Se podría pensar en usar tan sólo los Keepalives de tipo Link, haciendo algo parecido a
lo que hacen algunos protocolos usados en Internet: enviar en períodos cortos mensajes a los
nodos adyacentes e ir actualizando las tablas de encaminamiento. Esto tendría mucha utilidad
en nuestro proyecto si la métrica tomada fuera otra distinta a la RSSI, ya que la métrica podría
ir cambiando constantemente (por ejemplo el retardo) pero en nuestro caso, un radioenlace
de 8 Km NLOS nunca va a tener una RSSI mejor que uno LOS de 1 Km. Las métricas están
calculadas previamente mediante planificación radioeléctrica.
Por otra parte, puesto que la red es una red de monitorización y los mensajes llegan de
manera periódica, se aprovechan los Keepalives de tipo Node para, además de servir para el
algoritmo de encaminamiento, llevar información de monitorización, evitando gastar duty
cycle, que como se ha explicado a lo largo del proyecto es una de las limitaciones de los xBee
868 MHz que usan los Waspmotes.
Por ello, los Keepalive de tipo Link se emiten también periódicamente, pero sin carga alguna
de datos (para no gastar duty cycle) y con períodos de tiempo grandes, con el único objetivo
de garantizar, que si un nodo caído se reactiva, los nodos adyacentes sean capaces de darse
cuenta y actualizar sus tablas de encaminamiento en caso de que proceda, garantizándose la
ruta óptima.
En el ejemplo de la figura 6.6. se observa la siguiente situación: Inicialmente (fig.
izquierda) el nodo 0042 está caído por lo que el nodo de 0041 elige como siguiente salto al
nodo 0043, ya que la RSSI en destino es mejor que la obtenida si conecta directamente con el
nodo 0000. Pasado un tiempo (fig. centro), se activa el nodo 0042 y éste envía un Keepalive de
tipo Link a los nodos adyacentes. Una vez que el nodo 0041 ha recibido el Keepalive de tipo
129
Link procedente del 0042 (fig. derecha), entiende que el nodo está vivo, y puesto que el RSSI
de dicho nodo es mejor que el Next Hop actual (nodo 0043), actualiza su tabla de
encaminamiento y cambiando, por tanto, la ruta a la mejor posible.
6.1.3. Tablas de encaminamiento.
Las tablas de encaminamiento se han programado teniendo en cuenta que la
comunicación siempre es en un sentido. Es decir, los mensajes siempre se emiten desde nodos
situados a lo largo del canal hacia el nodo de la Oficina. No obstante, siguiendo el modelo de
encaminamiento estático, se podrían programar los nodos para que encaminaran mensajes
desde la Oficina a cualquier nodo (por ejemplo, para mandar órdenes de control),
simplemente añadiendo líneas en las tablas de encaminamiento y, aprovechando que las
direcciones NA de los nodos permiten agruparlos pro tramos, sumarizar los destinos en una
misma línea de la tabla. El proceso sería el mismo y las limitaciones, también las mismas, ya
que los “Next Hops” están fijos y las posibilidades son muy limitadas, debido a la longitud de
los radioenlaces.
Figura 6.7: Tablas de encaminamiento.
En la figura 6.7. se puede ver un ejemplo de la tabla de encaminamiento actual del nodo 0041
de Ctra. Utrera en la configuración utilizada en el proyecto (arriba) y en otra opción, fuera del
alcance del proyecto, en la que se incluiría encaminamiento desde la oficina hasta los nodos
(abajo). Como ya se explicó anteriormente, no existe ningún protocolo de resolución de
direcciones del estilo de ARP, sino que en la misma tabla se incluye la equivalencia dirección
NA – MAC.
Para un determinado destino, los posibles Next Hop van ordenados por RSSI de mayor a menor
y existe un índice o puntero “ind” que va cambiando por decisión del algoritmo de
130
encaminamiento. En el caso de que hubiera encaminamiento en los dos sentidos (desde y
hacia la oficina), una posible solución sería usar dos punteros, uno para cada dirección y los
destinos, se podrían agrupar o “sumarizar” en una misma línea común (001x, 002x, 003x, etc.)
para ahorrar cálculos a la hora de encaminar. No obstante, como se ha dicho, esto no se ha
realizado en el proyecto.
6.2. Programación de los Waspmotes.
6.2.1. Mensajes enviados por los nodos.
Para realizar las pruebas de campo, y simular un posible escenario real en el que se
estuvieran tomando medidas desde las almenaras y caudalímetros, se han diseñado una serie
de mensajes que enviarán los nodos periódicamente o tras ocurrir algún evento.
Los nodos enviarán 3 tipos de mensaje:
Keepalive. (De tipo Node o tipo Link)
Estado de Enlace.
Alarma.
6.2.1.1. Mensajes de Keepalive.
Como ya se anticipó en apartados anteriores existen dos tipos de mensajes de
Keepalive:
Keepalive de tipo Node.
Keepalive de tipo Link.
Los mensajes de Keepalive de tipo Node cumplen varios objetivos:
Informar al nodo receptor que los nodos no están caídos.
Son enviados periódicamente (cada 30 segundos) por los Waspmotes hacia el nodo
0000, que los entrega al Gateway y cumplen la función de “Keepalive Node”, es decir,
informan de que el nodo se mantiene vivo, como indica su nombre en inglés. Se ha
elegido este nombre ya que recuerda a otros mensajes usados en otros protocolos
para informar de que una conexión o nodo está vivo.
Servir al algoritmo de encaminamiento para seleccionar un camino u otro.
Como se vio al explicar el algoritmo de encaminamiento, estos mensajes se
aprovechan para saber si el siguiente salto está vivo o no (contando los reintentos de
en envío hace éste y suponiendo que está caído si se supera un máximo de 4). En caso
de que el siguiente nodo estuviese caído, se actualiza la tabla de encaminamiento y se
elige otra ruta.
Monitorizar.
Si bien se podría haber creado un mensaje aparte para monitorización de datos,
puesto que el Duty Cycle está limitado, y los mensajes de Keepalive son repetitivos
131
como las medidas tomadas del canal, se han aprovechado estos mensajes para tomar
supuestas medidas del canal. En la realidad, sería por ejemplo el nivel de agua o el
caudal, pero puesto que no contamos con sensores, las medidas tomadas son del
propio Waspmote. En concreto, la temperatura medida por el sensor del RTC, el Nivel
de Batería del Waspmote y el Duty Cycle consumido por el xBee.
Esto simplemente se hace para mostrar el potencial que ofrece la tecnología.
Figura 6.8: Mensaje de Keepalive de tipo Node (Formato y ejemplo).
El mensaje de Keepalive de tipo Node está compuesto por los siguientes campos:
Delimitador de inicio de trama ‘##’: Se usa en el programa de monitorización
Waspmonitor para extraer el mensaje.
Fecha – Hora: Muestran la fecha y la hora en que se envía el mensaje.
Tipo de mensaje: En este caso, será KEEPALIVE.
Dirección de red de origen.
Dirección de red de destino: En este proyecto siempre es 0000, puesto que todos los
mensajes van a la oficina.
Temperatura: Muestra la temperatura en grados centígrados que tiene la placa del
Waspmote (medida por el sensor de temperatura del RTC).
Batería: Nivel de batería restante (en %) que le queda al Waspmote.
Duty Cycle: Porcentaje del Duty Cycle total, medido sobre una hora que ha utilizado el
xBee 868 transmitiendo datos.
Número de saltos: Número de saltos que da el paquete desde el Origen hasta el Nodo
Oficina (0000).
Delimitador de fin de trama ‘####’: Al igual que el de inicio, se usa por Waspmonitor
para extraer el mensaje.
En la figura 6.8 se pueden ver cómo van dispuestos los campos del mensaje y un ejemplo del
mismo. Cabe destacar, que como se explicó en el apartado anterior, las “direcciones de red”,
sólo se usan con carácter informativo para generar los distintos mensajes, pero las direcciones
efectivas que se emplean a la hora que encaminar, son las direcciones MAC.
Por otra parte, los mensajes de Keepalive tipo Link:
Informan a los nodos adyacentes mediante mensajes broadcast emitidos cada 5
minutos de que el nodo sigue vivo y por tanto, el enlace (link) que los une también.
Se emiten en intervalos muy grandes para evitar gasto inútil de duty cycle.
132
Tienen como objetivo garantizar que siempre se elija la ruta óptima.
No transportan ninguna información de monitorización y por tanto no se pasan al
Gateway por parte del nodo de la Oficina. Esto se hace para minimizar el gasto de duty
cycle.
Figura 6.9: Mensaje de Keepalive de tipo Link (Formato y ejemplo).
6.2.1.2. Mensajes de Estado de Enlace.
Los mensajes de Estado de Enlace no tienen realizan ninguna función relacionada con
el protocolo de encaminamiento y se han diseñado ex profeso para las pruebas de campo de
este proyecto con el fin de comprobar la calidad real de los radioenlaces.
Los xBee 868 no tienen tanta precisión como fuera deseable a la hora de medir la RSSI de los
paquetes recibidos, ya que el rango que miden va desde los -112 dBm a los -60 dBm, con una
precisión, valga la redundancia, de 1 dBm. Aun así, como es la única forma de la que se
dispone para hacer las mediciones de la calidad de los radioenlaces, se utilizará este método.
Figura 6.10: Mensaje de Estado de Enlace (Formato y ejemplo).
El mensaje de Estado de Enlace se compone de los siguientes campos:
Delimitador de inicio de trama ‘##’: Se usa en el programa de monitorización
Waspmonitor para extraer el mensaje.
Fecha – Hora: Muestran la fecha y la hora en que se envía el mensaje.
Tipo de mensaje: En este caso, será ESTADO_ENLACE.
Dirección de red de origen.
Dirección de red de destino. En este proyecto siempre es 0000, puesto que todos los
mensajes van a la oficina.
RSSI: Muestra la RSSI (Nivel de Señal Recibido) y se usa para comprobar la calidad del
enlace.
MAC_Retries: Reintentos de envío de la trama MAC.
133
Es utilizado por el interfaz Waspmonitor para calcular el throughput o rendimiento del
enlace a partir del campo ‘MAC_Retries’:
( )
En telecomunicaciones existen muchas formas de definir el throughput: basado en el
ratio payload/cabeceras + payload, pérdida de paquetes, reenvío de tramas, etc. Se ha
elegido esta medida por ser fácilmente medible por el xBee 868.
Radioenlace: Radioenlace bajo estudio.
Delimitador de fin de trama ‘####’: Al igual que el de inicio, se usa por Waspmonitor
para extraer el mensaje.
En la figura 6.10 se puede ver la disposición de los campos del mensaje y un ejemplo del
mismo.
6.2.1.3. Mensajes de Alarma.
Al igual que los mensajes de Estado de Enlace, estos se han creado expresamente para
las pruebas de campo, con el fin de simular un escenario de monitorización lo más real posible.
Se han creado 4 tipos de mensaje de alarma:
CAIDA_ENLACE: Alarma por caída de un radioenlace.
BATERIA_BAJA: Alarma por batería baja de un Waspmote (< 10%).
DUTY_CYCLE: Alarma por Duty Cycle consumido alto (> 90 %).
TEMP_ALTA: Alarma por temperatura de la placa alta (> 55°C).
Figura 6.11: Mensaje de Alarma (Formato y ejemplo).
El mensaje de Estado de Enlace se compone de los siguientes campos:
134
Delimitador de inicio de trama ‘##’: Se usa en el programa de monitorización
Waspmonitor para extraer el mensaje.
Fecha – Hora: Muestran la fecha y la hora en que se envía el mensaje.
Tipo de mensaje: En este caso, será ALARMA.
Dirección de red de origen.
Dirección de red de destino. En este proyecto siempre es 0000, puesto que todos los
mensajes van a la oficina.
Tipo Alarma: Muestra qué tipo de alarma se ha producido.
Radioenlace: Este campo es opcional, y sólo aparece en el caso de mensajes de Caída
de Enlace. Muestra el radioenlace caído.
Delimitador de fin de trama ‘####’: Al igual que el de inicio, se usa por Waspmonitor
para extraer el mensaje.
En la figura 6.11 se puede ver la disposición de los campos del mensaje y dos ejemplos, uno en
el que se ve un mensaje de ALARMA por BATERÍA BAJA y otro por CAÍDA_ENLACE.
6.2.2. Programación de los nodos.
En este apartado se muestra el pseudocódigo simplificado de un nodo intermedio en el
caso más general posible. No se ha detallado en exceso puesto que el código se puede
consultar en el anexo correspondiente.
loop()
{
if(t2 = t2 + 5 min)
{
Enviar_KEEPALIVE_LINK(Broadcast);
}
if(t = t + 30 seg)
{
Enviar_KEEPALIVE_NODE(Next_Hop);
Reintentos = 0;
if (Error_TX == 1)
{
Reintentos++;
Esperar(Reintentos*t_ms);
if(Reintentos == 4) // Se actualiza la tabla de encaminamiento
{
if(Next_Hop < Ultima_pos)
Next_Hop++;
else
Next_Hop = Primera_pos;
Enviar_ALARMA_CAIDA_ENLACE(Next_Hop);
}
}
if (temp > 55)
Enviar_ALARMA_TEMP_ALTA(Next_Hop);
135
if (batt < 20)
Enviar_ALARMA_BATERIA_BAJA(Next_Hop);
if (dc > 90)
Enviar_ALARMA_DUTY_CYCLE(Next_Hop);
if(Hay_mensajes_en_buffer_RX == 1)
{
Extraer_mensaje_del_buffer_de_RX();
Extraer_campos_del_mensaje();
if(NA_Destino ¡= Broadcast) // Los KEEPALIVE LINK no se reenvían
Reenviar_mensaje();
else // Se actualiza la tabla de encaminamiento
{
if (Next_Hop_Nuevo < Next_Hop) // Si el nuevo Next Hop tiene mejor RSSI
Next_Hop = Next_Hop_Nuevo;
}
if (tipo_mensaje_recibido == KEEPALIVE && Proviene_de_nodo_adyacente == 1)
Enviar_ESTADO_ENLACE(Next_Hop);
}
}
}
Figura 6.12: Pseudocódigo de un nodo intermedio.
En el pseudocódigo se han omitido muchas cosas por simplicidad. Por ejemplo, antes de enviar
cada paquete, se espera 1 s. Esto se ha hecho así, para evitar que se pierdan paquetes en el
buffers de los xBee.
Como se puede observar, los mensajes que provocan los cambios en la tabla de
encaminamiento son sólo los de Keepalive de tipo Node y los de tipo Link y no los reenviados
ni los de Alarma o Estado de Enlace. Esto se ha hecho así para evitar consumir en exceso el
Duty Cycle y aprovechar que todos los mensajes se emiten periódicamente (incluidos los de
alarma, que como se ve en el código, en caso de existir, se emitirán cada 30 segundos).
Por tanto, que se pierdan algunos mensajes no es tan relevante, tras pasar 30 segundos, el
Keepalive Node se encargará de actualizar la tabla o cada 5 min, el Keepalive Link. Sin embargo,
si se consume el duty cycle con muchos reintentos, sí es algo grave, ya que el nodo quedará
inoperativo.