Etapa de Ajuste de la Agrupación

Cada uno de los mensajes en esta etapa utiliza mecanismos de confirmación de envío dado que son mensajes de control muy importantes y en caso de pérdida es necesario retransmitirlo. La primera etapa de ajuste después de que los nodos han sido encendidos (de ser necesaria), es inducida de manera asíncrona, de manera que si dos compuertas tratan de ajustarse al mismo tiempo y una está una posición más hacia la dirección descendente que la otra, obliga a la primera a que se ajuste y luego envíe un mensaje de AUTHORIZED en el que le indica a la otra compuerta que ya puede alterar su agrupación. De esta forma evitamos que la compuerta ubicada más hacia la dirección descendente durante su proceso de adaptación vaya a desajustar alguna agrupación ya ajustado en la dirección ascendente. Este proceso sólo es utilizado durante la primera etapa de ajuste de la agrupación, con el objetivo de garantizar una convergencia ordenada. Los campos del mensaje AUTHORIZED se presentan en la Figura 21.

Figura 21. Campos del mensaje AUTHORIZED. Mensaje utilizado durante la primera etapa de ajuste de agrupación. Encargado de promover una convergencia ordenada. Hace que el orden de ajuste sea desde la dirección descendente a la dirección ascendente.

En dónde senderID incluye la dirección de la compuerta que ya se ajustó y le da la autorización a la compuerta que recibe el AUTHORIZED para que modifique su agrupación (si goahead=1). Este proceso de ajuste inicial es disparado por las compuertas que tengan conectividad directa con el sumidero, y se propaga hasta alcanzar los nodos más lejanos. Una compuerta generará un AUTHORIZED una vez se haya ajustado (lo cual sólo puede pasar si antes ha recibido un AUTHORIZED con goahead=1).

Los mensajes asociados propiamente con el ajuste de una agrupación se muestran en la Figura 22.

Figura 22. Campos de los mensajes usados en la etapa de adaptación de la agrupación. Mensajes con los que se extrae información de las next gates, se determina el tipo de movimiento a realizar y se transmite a la compuerta a mover.

Cada vez que una compuerta necesite modificar su agrupación asociada activa una bandera que representa su estado actual, busy=1. Esta bandera será liberado una vez alguna de las compuertas en la dirección ascendente haya sido movida, bien sea mediante una operación de PULL o PUSH, esto se realiza con el mensaje RELEASE.

Con la utilización de los mensajes NGIREQ (Next Gate Information REQuest) y NGIREPLY (Next Gate Information REPLY) se recoge información de las next gates. El NGIREQ se genera si goahead=1, se acaba de completar un super-paquete y si el tiempo de llenado del mismo fue menor a Tmin o mayor a Tmax.

Cuando la compuerta ha transmitido el NGIREQ al último de sus hijos (contenidos en OHCList), espera cierto tiempo TimerOPERATION (tiempo durante el cual espera recibir

la información de sus siguientes compuertas) antes de determinar y enviar la operación a ejecutar, PULL o PUSH. El diagrama de flujo se muestra en la Figura 23.

Nodo: Compuertas

Evento: violación de las restricciones del tiempo de llenado

Figura 23. Diagrama de flujo para el arranque de la adaptación de la agrupación. Proceso de envío del mensaje NGIREQ para recoger información de las next gates.

Una vez una compuerta recibe un NGIREQ, este responde con un NGIREPLY al trigger_node (es decir el nodo que transmitió el NGIREQ). En la respuesta, cada compuerta transmite información de su estado (busy), si es un branch node (BN), si su padre es un branch node (BNP) y su tiempo de llenado del último super-paquete (Ti). Si el nodo que

El algoritmo se presenta en la Figura 24. Nodo: Compuertas

Evento: Recibir NQIREQ

Figura 24. Diagrama de flujo para la recepción de un NGIREQ. Se responde al nodo que está tratando de ajustar la agrupación con los valores del tiempo de llenado y banderas que permitirán calcular la operación a realizar y la compuerta objetivo.

Cuando una compuerta recibe un NGIREPLY, almacena los datos en una tabla que contiene la información de las next compuertas (mynextG), para que al final del TimerOPERATION, se pueda calcular la operación a realizar sobre una de las compuertas de la tabla.

La primera columna de la tabla especifica la compuerta de la que se recibe información, la segunda es el último valor del tiempo de llenado para dicha compuerta, la tercera indica si el nodo padre de la compuerta en cuestión es un branch node, la cuarta columna muestra si

la compuerta de la que se recibió la información es un branch node y la última columna indica si la compuerta está en estado busy o no.

Se lleva un contador de next gates de las que se recibe un NGIREPLY, ngiReplyCount. Si al final del proceso, ngiReplyCount es igual a cero, quiere decir que se trata de una Leaf Lock Gate (tal como se definió con anterioridad). Es en esta clase de compuertas que se presenta el aumento o disminución del número de compuertas de todo el sistema, ya que son ellas capaces de crear o destruir una compuerta existente. El diagrama se presenta en la Figura 25.

Nodos: Todos

Evento: Recibir un NGIREPLY desde la compuerta i

Figura 25. Diagrama de flujo la recepción de un NGIREPLY. Se ha recogido información de las compuertas ubicadas en la dirección ascendente y se ha almacenado en la tabla mynextG.

Una vez se ha cumplido el TimerOPERATION, la compuerta analiza los datos almacenados en la tabla mynextG para determinar la operación a realizar y la compuerta sobre la que se va a dar el movimiento. Si todas las compuertas están en estado busy, debe esperar durante delta segundos [10] y transmitir nuevamente el NGIREQ.

La selección de la operación a realizar y la compuerta sobre la que se va a dar el movimiento se establece de acuerdo a las reglas definidas en la sección anterior.

Como se puede apreciar en la definición del mensaje OPERATION (ver Figura 22), existe un campo homónimo que indica el tipo de movimiento a realizar por la dirección indicada en el campo destgate del mismo paquete. Así, un 0 en ese campo implica un PULL, mientras que un 1 equivale a una operación de PUSH. La secuencia se muestra en la Figura 26.

Nodo: Compuerta tratando de ajustar su agrupación Evento: TimerOPERATION

Figura 26. Diagrama de flujo para el envío de la operación a realizar. Se determina la operación a realizar con la información almacenada en mynextG y las reglas planteadas en la sección anterior.

Una vez un nodo recibe un mensaje OPERATION, si no es una compuerta, retransmite el mensaje a sus hijos. Si es la compuerta a la que está dirigida el mensaje, deja de ser compuerta y emite un mensaje C_ADAPTION dependiendo la clase de operación incluida

en el mensaje. Si se trata de un proceso de PUSH, el destinatario del mensaje C_ADAPTION será uno de los hijos del nodo que recibe OPERATION. Si es un proceso de PULL, el nodo al que debe dirigirse el mensaje C_ADAPTION es el nodo padre. Básicamente C_ADAPTION se encarga de que su receptor se convierta en compuerta. El proceso se aprecia en la Figura 27.

Nodo: Todos

Evento: Recibir OPERATION

Figura 27. Diagrama de flujo para la recepción de un mensaje OPERATION. Proceso con lo que una compuerta se mueve desapareciendo la agrupación inicial y creándose una nueva.

El nodo que recibe un mensaje de C_ADAPTION tiene dos responsabilidades, la primera es convertirse en la nueva compuerta empezando un proceso de asociación a la agrupación (mediante el envío a sus hijos de un mensaje C_ASSOCIATION), como ya se mencionó antes en el documento, y la otra función que debe realizar es enviar el mensaje RELEASE al nodo trigger_node que fue el nodo que empezó todo el proceso de ajuste.

Cuando la compuerta almacenada en trigger_node recibe el mensaje de RELEASE, este cambia el estado de busy a 0, es decir ya se modificó el agrupación que la compuerta tiene asociado. Ahora debe esperar hasta el próximo proceso de llenado del super-paquete para determinar si ya no existe violación de los umbrales Tmin y Tmax o si por el contrario es

necesario volver a ajustar la agrupación con el envío de un NGIREQ (como ya se expuso en un apartado anterior). El diagrama lógico se presenta enseguida:

Nodo: Todos

Evento: recibir C_ADAPTION

Figura 28. Diagrama de flujo para la recepción de un C_ADAPTION. El nodo que recibe un C_ADAPTION, se convierte en compuerta, envía un mensaje de C_ASSOCIATION a sus hijos y luego envía el mensaje de RELEASE al nodo que empezó el ajuste de la agrupación.

Aportes Realizados

En esta sección se resumen los aportes realizados (algunos ya expuestos) y las variaciones con respecto a la versión original de ALT propuesta en [10]-[11].

1. Se propuso que el proceso de ajuste de agrupaciones tenga dos variables de sintonización: LMAX (el tamaño en bytes del super-paquete) y K (la cantidad de

referencia [10]-[11], en los que sólo se varía el valor de K, mientras LMAX queda fijo

al valor máximo establecido por el estándar IEEE802.15.4. Con esa sintonización se logra que las Leaf Lock Gates que no tengan suficientes nodos en sus agrupaciones, no les agregue un retardo considerable a los mismos, y a su vez pueda cumplir con las restricciones del tiempo de llenado.

2. Se planteó el uso de dos tipos de mensajes en la red. El primero de ellos corresponde a mediciones periódicas de cierta variable, que no son muy sensibles a retardos, pero sí a la pérdida de paquetes. El otro corresponde a mensajes que representan un evento de interés inmediato en la periferia de un nodo (o incluso en el nodo mismo), y que deben ser transmitidos a la mayor brevedad posible hacia el sumidero (TRAPs). Ambos mensajes se distinguen gracias al campo SF del paquete de aplicación descrito con anterioridad.

3. Se plantea una ejecución inicial de ALT de manera asíncrona (empezando por las compuertas cercanas al sumidero), de manera que el primer ajuste de una compuerta no vaya afectar el de otra ya ajustada en la dirección ascendente (esto se logra mediante el mensaje AUTHORIZED).

4. Se implementa el envío de confirmación de recibido para los mensajes propios del protocolo y para los TRAPs, mientras que se espera una transmisión de mensajes de aplicación basados en la política del “mejor esfuerzo”.

5. Se propone un esquema algorítmico para la implementación de nuestra versión de ALT en tres etapas simples que minimiza el número de mensajes de broadcast (sólo lo utiliza el sumidero para anunciarse en la Etapa de Descubrimiento de Red). De esa manera se evitan tormentas de broadcast que consuman los recursos de la red.

6. Se plantea la implementación en un sistema operativo de nodos comerciales que exhibe el menor consumo de energía tal como se explica en la Sección 5.