Esta parte del documento surge como resultado de un trabajo paralelo al desarrollo en TOS, y que consistió en la búsqueda de plataformas comerciales de bajo costo y que permitan la modificación de los protocolos a lo largo de la pila. Esta sección se puede considerar un punto de partida hacia la selección de la mejor herramienta para la libre implementación de protocolos de recolección y enrutamiento de datos en una WSN. La plataforma descrita a continuación fue utilizada en la referencia [11] para la implementación de la versión original de ALT.
Hardware
JENNIC suministra una familia de módulos de montaje superficial de ultra bajo consumo de potencia y bajo costo [38] para la implementación de redes inalámbricas de sensores: JN5139 y JN5148. Son módulos que consisten de un procesador y componentes de RF (compatibles con 802.15.4). Algunos módulos tienen una antena de cerámica integrada, mientras que otros suministran un conector SMA para una antena externa (mediciones indican que es posible obtener rangos de alcance entre 1 Km y 4 Km cuando se utilizan antenas externas dependiendo del módulo y la antena por supuesto [38]).
Sin embargo estos módulos no incluyen un circuito de alimentación, ni sensores (aunque si se tiene conexión al conversor A/D del procesador), ni un circuito de conexión a un PC para la programación del dispositivo y para la integración del sumidero con un computador. Es por eso que se requiere el diseño en una tarjeta aparte de esas partes. Un punto de partida para este diseño puede ser el diagrama de componentes y conexiones para la tarjeta DR1048 [39], que es la que acompaña a los módulos JN5139 en los kits de desarrollo suministrados por la misma empresa, y que es mostrada en la sección de ANEXOS.
Software
En la actualidad los procesadores de JENNIC no soportan TinyOS. Sin embargo, JENNIC presenta tres versiones de API (Application Programming Interface): IEE802.15.4, ZigBEE Pro y JenNet. Las dos últimas representan una programación a alto nivel que es sencilla con el SDK (Software Development Kit) suministrado por JENNIC. Sin embargo se imponen
los protocolos de enrutamiento, por lo que no se tiene ninguna libertad de modificación. Por su parte el API IEEE802.15.4, es más tedioso pero permite la modificación de los protocolos y la definición arbitraria de tipos de datos y mensajes (como TinyOS).
El lenguaje de programación para estos dispositivos es similar a C y es necesario siempre realizar un código para el sumidero (master) y otro para los demás nodos (slaves). La cadena de desarrollo necesita la instalación de un emulador de Linux (por ejemplo Cygwin), el Code::Blocks (que es la interfaz de desarrollo), Flash Programmer (que descarga las aplicaciones sobre los nodos al conectarse al PC) y Jennic Compiler Tools (herramienta de compilación y debug del código). Para más detalles de la instalación se recomienda la referencia [38].
El API 802.15.4 le permite a la aplicación interactuar con la pila IEEE802.15.4. Esta interacción es implementada en función de dos servicios de la subcapa mac2: MCPS (MAC Data Service) que brinda los mecanismos para pasar datos a la capa superior y MLME (MAC Management Services) que le brinda las interfaces a la capa superior para controlar características de la transmisión [40]. En la Figura 59 podemos observar las interfaces de relación entre las capas.
Figura 59. Interface entre Capa de Red y Capas inferiores en JENNIC. Tomada de [40]
2 Recordemos que en el stack de protocolos clásico la capa de enlace o capa dos se divide en dos sub capas: LLC (Logical Link Control, que interactúa con la capa de enrutamiento) y la sub capa mac (que interactúa con la capa física)
Las anteriores interfaces incluyen varias rutinas e indicaciones (concepto similar al de evento en TOS) que se desplazan entre capas facilitando de esa manera el diseño cross- layer.
La capa MAC suministra servicios para la transmisión y recepción de datos. Los datos son transmitidos usando MCPS-DATA.request; el estado de una transmisión es reportado mediante MCPS-DATA.confirm; la recepción de datos es indicada a la capa de red o aplicación mediante un MCPS-DATA.indication.
La primitiva MCPS-DATA.request es usada por la capa de red para transmitir un paquete de datos a un nodo destino. El request es enviado a la capa MAC mediante la rutina vAppApiMcpsRequest() con el siguiente formato:
struct tagMAC_McpsReqData_s {
uint8 u8Handle; /* Handle of frame in queue */ MAC_TxFrameData_s sFrame; /* Frame to send */ } MAC_McpsReqData_s;
Donde u8Handle es un identificador de la transmisión y sFrame contiene la trama de datos a enviar con el siguiente formato:
typedef struct {
MAC_Addr_s sSrcAddr; /* Source address */ MAC_Addr_s sDstAddr; /* Destination address */ uint8 u8TxOptions; /* Transmit options */
uint8 u8SduLength; /* Length of payload (MSDU) */
uint8 au8Sdu[MAC_MAX_DATA_PAYLOAD_LEN];/* Payload (MSDU) */ } MAC_TxFrameData_s;
Donde el campo au8Sdu contiene el payload (así como en TOS el campo data[TOSH_DATA_LENGTH]). Para mayor detalle de esta rutina se recomienda acudir a la referencia [40]. Es en el campo de payload precisamente dónde deberían definirse las estructuras de mensajes (estilo estructuras en C) que se definieron en la Sección 4.
La primitiva MCPS-DATA.confirm es generada por la capa MAC para informar a la capa de red o aplicación el estado de un MCPS-DATA.request. El mensaje de confirmación es enviado a la capa de red usando la siguiente estructura de mensaje [40]:
typedef struct {
uint8 u8Handle; /* Handle matching associated request */ uint8 u8Status; /* Status of request */
} MAC_McpsCfmData_s;
Dónde nuevamente u8Handle identifica el paquete transmitido y u8Status presenta el uno de varios valores para el estado de la transmisión (por ejemplo si la transmisión fue confirmada en el destino). De esta manera tendríamos el equivalente al campo ack de la sección de metadata en un paquete de TinyOS, que se revisó en la Sección 5.
Por otro lado, una MCPS-DATA.indication es generada por la capa MAC para informarle a la capa de red o aplicación acerca de la recepción de un paquete. La indicación será trasladada a la capa de red con el siguiente formato [40]:
typedef struct {
MAC_RxFrameData_s sFrame; /* Frame received */ } MAC_McpsIndData_s;
Con sFrame cumpliendo la siguiente estructura: struct tagMAC_RxFrameData_s
{
MAC_Addr_s sSrcAddr; /* Source address */ MAC_Addr_s sDstAddr; /* Destination address */ uint8 u8LinkQuality; /* Link quality of received frame */ uint8 u8SecurityUse; /* True if security was used */ uint8 u8AclEntry; /* Security suite used */
uint8 u8SduLength; /* Length of payload (MSDU) */
uint8 au8Sdu[MAC_MAX_DATA_PAYLOAD_LEN];/* Payload (MSDU) */ } MAC_RxFrameData_s;
De donde entre muchos parámetros podemos extraer la calidad del enlace (al momento de la recepción de la trama) y el mensaje enviado en la estructura au8Sdu. Para mayor detalle en cuanto a esta estructura se recomienda leer la referencia [40].
De esta manera se ha hecho una equivalencia entre TinyOS y las primitivas de JENNIC, que permitiría la implementación de ALT en su familia de microprocesadores para WSN.
Para obtener mayor información acerca del funcionamiento, configuración y esquemas de programación para el API 802.15.4 de JENNIC se recomiendan acudir a: [40], [41] y [42].
CONCLUSIONES
La escogencia de protocolos para redes inalámbricas de sensores queda supeditada a las características propias de los nodos, los patrones de las topologías físicas y por supuesto de la aplicación que será soportada sobre la red. En los trabajos recientes sobre esta área se han modificado los conceptos de la pila de protocolos convencional, para abrirle paso a la creación de nuevas capas lógicas que facilitan la interacción entre capas. Se han perdido las divisiones fuertemente marcadas entre niveles y la independencia entre ellos se ha hecho vaga, haciendo posible un diseño entre capas (cross-layer).
La topología sobre la que se centró el trabajo es la Long-Thin. Término reciente y no estándar utilizado para referirse a redes muy extensas cuyas conexiones muestran fuertes componentes longitudinales, y que se dividen en ramas que cubren el área de interés. Estas redes se caracterizan porque cada nodo puede tener varios descendientes, pero sólo un nodo padre a cada instante de tiempo. Es decir que puede pensarse en esquemas de rotación de padres en caso de fallo. Sin embargo esta última situación no es abordada en este trabajo. ALT es precisamente un ejemplo de diseño transversal entre capas de la pila. Propone básicamente un compromiso entre congestión de la red en ciertos puntos y un aumento en el retardo de los paquetes en su camino para alcanzar el sumidero, lo que lo hace un protocolo útil para aplicaciones con sensibilidad de paquetes perdidos, pero que toleren ciertos retardos adicionales. Se propuso una implementación del mismo, con una descripción algorítmica simple y que produce un protocolo que no exige grandes cantidades de procesamiento y modifica la topología de conexiones lógicas entre nodos de acuerdo a ciertas restricciones de retardo.
Se encontró que el retardo adicional agregado a los paquetes es dependiente del número de nodos que hacen parte de una agrupación y la cantidad de lecturas que la compuerta recoge en un super-paquete. El primero de estos factores no es modificable debido a que queda determinado por la inercia misma del protocolo. Por ende, es posible disminuir la latencia elevada de ciertos nodos mediante la modificación de la cantidad de lecturas recogidas en un super-paquete. Esta idea básica se utilizó para resolver un problema que presentaban las
agrupaciones más alejadas del sumidero y que no alcanzaban a cumplir las restricciones del tiempo de llenado.
La implementación de ALT se realizó sobre TinyOS gracias a que se encontró que para un mismo nodo (que soporta varios sistemas operativos) ejecutando diversas tareas, el uso de TinyOS representaba el menor consumo de energía, lo que es un indicio del uso adecuado de los recursos por parte de ese OS. Se planteó un marco de simulación donde el modelo de propagación se implementó en Matlab y se tenía una interfaz con TOSSIM, que es un simulador basado en eventos. Dichos eventos fueron registrados en archivos de registro que fueron luego procesados por una aplicación en Perl. Esta cadena de herramientas nos permitió llevar a cabo estudios de latencias, paquetes perdidos y consumo energético de una red Long-Thin en la que se ejecutaba ALT como protocolo de recolección y enrutamiento. Se planteó una equivalencia entre el desarrollo en TinyOS y el modelo planteado por JENNIC, una empresa que suministra módulos WSN, abriendo la puerta a una posible implementación del protocolo propuesto en este documento.
TRABAJO FUTURO Y RECOMENDACIONES
Las simulaciones en este trabajo se realizaron sobre topologías que permitieran ver comportamientos básicos de ALT. Por ende sería interesante alterar varios parámetros de la simulación para complementar la visual de las características de ALT: por ejemplo introducir asimetrías en los enlaces entre nodos, simular para varios escenarios con diferentes características de propagación de la señal, simular topologías más complejas (sin violar la restricción que impone TOSSIM al número máximo de nodos: 1000).
Aunque se planteó un modelo del retardo extra que implica el uso de ALT, sería interesante realizar un proceso de modelado también para el comportamiento de los paquetes perdidos en la red así como para el ahorro de energía que adquieren los nodos cercanos al sumidero. De igual manera sería útil plantear un proceso de búsqueda óptima de los valores Tmin y
Tmax dada una aplicación dada.
Dado que los cambios de topología de la red dependen de la tasa de creación de datos de aplicación y en las simulaciones realizadas en este trabajo dichos tiempos son elevados (se generaba una lectura cada 5 minutos), junto con la imposición de convergencia asíncrona (con el mensaje AUTHORIZED), los tiempos de convergencia del protocola la primera vez que se ejecuta pueden ser altos. Es preciso desarrollar un proceso de escalamiento de factores (basado en las fórmulas extraídas en este trabajo) de manera que se pueda acelerar la convergencia inicial del protocolo.
Resulta interesante complementar el protocolo con un esquema de recuperación ante posibles fallas de nodos. Un esquema en el que un nodo que pierda conectividad con el sumidero (por ejemplo porque su nodo padre quedó sin energía), puede emitir un mensaje de rescate y si algún otro nodo (diferente a sus hijos) recibe dicho mensaje, le envíe una invitación para formar parte de su agrupación.
Por último, es evidente la necesidad de implementación en una plataforma comercial para la corroboración de los datos obtenidos durante la simulación y el modelado del protocolo.
BIBLIOGRAFÍA
[1] R. Gamboa, Simulación y Análisis de protocolos de capa MAC para redes inalámbricas de sensores, Tesis de Maestría, Universidad de los Andes, 2008.
[2] J. Cárdenas, Control de Topologías y Enrutamiento en redes Inalámbricas de Sensores, Tesis de Maestría, Universidad de los Andes, 2008.
[3] M. Labrador, P. Wightman, Topology Control in Wireless Sensor Networks with a Companion Simulating Tool for Teaching and Research. Florida: Springer, 2009, 210 p.
[4] J. Zhen, A. Jamalipour, Wireless Sensor Networks: A Networking Perspective. New Jersey: J. Wiley & Sons, 2009, 522 p.
[5] B. Krishnamachari, Networking Wireless Sensors. Cambrige: Cambriedge University Press, 2005, 215 p.
[6] C. Silva, Simulación de Protocolos de Red Eficientes en Energía para Redes Inalámbricas de Sensores, Tesis de Maestría, Universidad de los Andes, 2007.
[7] H. Haridas, BriMon: Design and Implementation of Railway Bridge Monitoring Application, Master’s Thesis, Indian Institute of Technology, 2006.
[8] Z. Zi-Nan, G. Wei-Feng, Research on Monitoring Power Systems Faults by Wireless Sensor Networks, en Proc. IEEE Third International Symposium on Electronic Commerce and Security Workshops, 2010.
[9] M. Pan, H. Fang, Y. Liu, Y. Tseng, Address Assignment and Routing Schemes for ZigBee-Based Long-Thin Wireless Sensor Networks, Vehicular Technology Conference, Mayo 2008.
[10] Y. Wang, A Lightweight, Self-Adaptive Lock Gate Designation Scheme for Data Collection in Long-Thin Wireless Sensor Networks, Wireless Communications ans Mobile Computing. (SCIE) (to appear).
[11] Y. Wang, C. Chuang, Y. Tseng, Dynamic Water Gate Assignment Scheme for Data Aggregation in Long-Thin Sensor Networks, IEEE Computer Symposium (ICS), 2010 International, pp.429-434, 16-18 Dec. 2010.
[12] CC2420 Radio Stack. [Online]. Disponible en: http://www.tinyos.net/tinyos-
[13] O. Bermejo, T. García, Evaluación de métricas de encaminamiento basadas en LQI para un protocolo de encaminamiento en redes IEEE802.15.4, Tesis de Ingeniería, Universitat Politecnica de Catalunya, 2009.
[14] TinyOS. [Online]. Disponible en: http://www.tinyos.net
[15] A. Dunkels, B. Grönvall, and T. Voigt, Contiki—a lightweight and flexible operating system for tiny networked sensors, in Proc. EmNets, 2004.
[16] C.-C. Han, R. Kumar, R. Shea, E. Kohler, and M. Srivastava, A dynamic operating system for sensor nodes, in Proc. ACM MobiSys, 2005.
[17] S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald, A. Torgerson, and R. Han, MANTIS OS: An embedded multithreaded operating system for wireless micro sensor platforms, ACM/Kluwer Mobile Netw. Appl. J. (MONET), Special Issue Wireless Sensor Netw., vol. 10, pp. 563–579, 2005. [18] A. Eswaran, A. Rowe, and R. Rajkumar, Nano-RK: An energy-aware resource-
centric RTOS for sensor networks, in Proc. IEEE RTSS, 2005.
[19] H. Cha, S. Choi, I. Jung, H. Kim, and H. Shin, RETOS: Resilient, expandable, and threaded operating system for wireless sensor networks, in Proc. ACM/IEEE IPSN, 2007.
[20] Q. Cao, T. F. Adbelzaher, and J. A. Stankovic, The LiteOS operating system: towards Unix-like abstractions for wireless sensor networks, in Proc. ACM/IEEE IPSN, 2008.
[21] D. Méndez, Desarrollo de una plataforma para Prototipaje Flexible de Aplicaciones WSN, Tesis de Maestría, Universidad de los Andes, 2007.
[22] SOS Embedded Operating System. [Online]. Disponible en:
https://projects.nesl.ucla.edu/public/sos-2x/doc/ .
[23] M. Healy, T. Newe, and E. Lewis, Power Management in Operating Systems for Wireless Sensor Nodes, Sensors Applications Symposium, 2007. SAS '07. IEEE, vol., no., pp.1-6, 6-8 Feb. 2007.
[24] S. Bock, Implementación del Sistema Operativo TinyOS sobre un nodo de una red Inalámbrica de Sensores, Tesis de Ingeniería Electrónica, Universidad de los Andes, 2007.
[25] Simulating TinyOS Applications in TOSSIM. [Online]. Disponible en:
]http://www.tinyos.net/tinyos-1.x/doc/tutorial/lesson5.html .
[26] L. Cano, Implementación del Protocolo S-MAC sobre la Plataforma CHIPCON CC2431, Tesis de Maestría, Universidad de los Andes, 2007.
[27] TEP 111 - message_t. [Online]. Disponible en: http://www.tinyos.net/dist- 2.0.0/tinyos-2.0.0beta1/doc/html/tep111.html
[28] TEP 111 – message_t - Revision: 1.1.2.12. [Online]. Disponible en:
http://www.tinyos.net/dist-2.0.0/tinyos-2.0.0beta2/doc/txt/tep111.txt
[29] P. Levis, D. Gay, TinyOS Programming. Cambriadge: Cambriadge University Press, 2009, 282 p.
[30] S. Seidel, T. Rappaport, 914 MHz Path Loss Prediction Models for Indoor Wireless Communications in Multifloored Buildings, Antennas and Propagation, IEEE Transactions on , vol.40, no.2, pp.207-217, Feb 1992.
[31] V. Erceg, J. Greenstein, S. Tjandra, S. Parkoff, A. Gupta, B. Kulic, A. Julius, R. Jastrzab, An Empirically-Based Path Loss Model for Wireless Channels in Suburban Environments, Selected Areas in Communications, IEEE Journal on , vol.17, no.7, pp.1205-1211, Jul 1999.
[32]K. Sohrabi, B. Manriquez, G. Pottie, Near Ground Wideband Channel Measurement in 800-1000MHz, Vehicular Technology Conference, 1999 IEEE 49th , vol.1, no., pp.571-574 vol.1, Jul 1999
[33] Building a Network Topology for TOSSIM. [Online]. Disponible en
http://www.tinyos.net/dist-2.0.0/tinyos-2.x/doc/html/tutorial/usc-topologies.html
[34] H.Lee, A.Cerpa, P. Levis, Improving wireless Simulation through Noise Modeling, Information Processing in Sensor Networks, 2007. IPSN 2007. 6th International Symposium on , vol., no., pp.21-30, 25-27 April 2007
[35] TOSSIM. [Online]. Disponible en: http://docs.tinyos.net/index.php/TOSSIM
[36]PowerTOSSIM-Z: Realistic Energy Model in TOSSIM for the MicaZ Mote. [Online]. Disponible en http://www.scss.tcd.ie/~carbajor/powertossimz/index.html
[37] W. Heinzelman, A. Chandrakasan, H. Balakrishnan, Energy-Efficient Communication Protocol forWireless Microsensor Networks, System Sciences, 2000. Proceedings of the 33rd Annual Hawaii International Conference on , vol., no., pp. 10 pp. vol.2, 4-7 Jan. 2000.
[38] Choosing a Network Protocol Stack. [Online]. Disponible en:
http://www.jennic.com/products/protocol_stacks/
[39] DR1048 Sensor Board Reference Manual. [Online]. Disponible en:
[40] IEEE 802.15.4 Application Development Reference Manual. [Online]. Disponible en: http://www.jennic.com/files/support_files/
[41] 802.15.4 Stack API Reference Manual. [Online]. Disponible en:
http://www.jennic.com/support/reference_manuals/jn-rm-2002_802154_stack_api
[42] IEEE 802.15.4 Wireless Networks User Guide. [Online]. Disponible en:
http://www.jennic.com/support/user_guides/jn-ug- 3024_ieee_802154_wireless_networks