Grupo GDSPROC Universidad del Quindo ZIGBEE 1. ESPECIFICACIN INALMBRICA ZIGBEE ZigBee es un protocolo de comunicaciones inalmbricas diseado por la ZigBee Alliance. No es una tecnologa, sino un conjunto estandarizado de soluciones que pueden ser implementadas por cualquier fabricante. ZigBee est basado en el estndar IEEE 802.15.4 de redes inalmbricas de rea personal (WPAN, Wireless Personal Area Network) donde define los niveles de red, seguridad y aplicacin basndose en el nivel fsico y de acceso al medio (MAC). Tiene como objetivo las aplicaciones que requieren comunicaciones seguras con baja tasa de envo de datos y maximizacin de la vida til de sus bateras como es el caso de los nodos que conforman una red sensorial inalmbrica. ZigBee es promovida por la ZigBee Alliance, la cual, es una comunidad internacional de ms de 100 compaas como Motorola, Mitsubishi, Philips, Samsung, Honeywell, Siemens, entre otras; cuyo objetivo es habilitar redes inalmbricas con capacidades de control y monitoreo que sean confiables, de bajo consumo energtico y de bajo costo, que funcione va radio y de modo bidireccional; todo basado en un estndar pblico global que permita a cualquier fabricante crear productos que sean compatibles entre ellos [1]. Cuando se concibi este protocolo, los primeros nombres que sonaron fueron: PURLnet, RF- Lite, Firefly y HomeRF Lite, finalmente se escogi el trmino ZigBee, sin embargo, el origen de este nombre es an incierto, pero la idea surgi de una colmena de abejas pululando alrededor de su panal y comunicndose entre ellas.
1.1. CARACTERSTICAS A continuacin se enlistan algunas las caractersticas del protocolo ZigBee: Tiene una velocidad de transmisin de 250 Kbps y un rango de cobertura de 10 a 75 metros. A pesar de coexistir en la misma frecuencia con otro tipo de redes como WiFi o Bluetooth su desempeo no se ve afectado, esto debido a su baja tasa de transmisin y a caractersticas propias del estndar IEEE 802.15.4. Capacidad de operar en redes de gran densidad, esta caracterstica ayuda a aumentar la confiabilidad de la comunicacin, ya que entre ms nodos existan dentro de una red, entonces, mayor nmero de rutas alternas existirn para garantizar que un paquete llegue a su destino. Cada red ZigBee tiene un identificador de red nico, lo que permita que coexistan varias redes en un mismo canal de comunicacin sin ningn problema. Tericamente pueden existir hasta 16000 redes diferentes en un mismo canal y cada red puede estar constituida por hasta 65000 nodos, obviamente estos lmites se ven truncados por algunas restricciones fsicas (memoria disponible, ancho de banda, etc.). Es un protocolo de comunicacin multi-salto, es decir, que se puede establecer comunicacin entre dos nodos aun cuando estos se encuentren fuera del rango de transmisin, siempre y cuando existan otros nodos intermedios que los interconecten, de esta manera, se incrementa el rea de cobertura de la red. Es posible establecer la topologa de red tipo MESH, que permite a la red auto recuperarse de problemas en la comunicacin aumentando su confiabilidad.
Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo Una red ZigBee la forman bsicamente 3 tipos de elementos, un nico dispositivo coordinador, dispositivos routers y dispositivos finales. Coordinador ZigBee (ZC, ZigBee Coordinator). Es el nodo de la red que tiene la nica funcin de formar la red, bien sea en topologa de estrella o rbol, y es el responsable de establecer el canal de comunicaciones y del PAN ID (identificador de red) para toda la red. Una vez establecidos estos parmetros, el Coordinador puede formar la red, permitiendo unirse a l a dispositivos Routers y End Points. Una vez formada la red, el Coordinador hace las funciones de Router, es decir, participa en el enrutado de paquetes y puede ser origen y/o destinatario de informacin, as como tambin puede ser puente de enlace con otras redes de rea personal. Router ZigBee (ZR). Adems de ofrecer un nivel de aplicacin para la ejecucin de cdigo de usuario, puede actuar como router interconectando dispositivos separados en la topologa de la red, es decir, interconectar End Points con el Coordinador. Dispositivo final (ZED, ZigBee End Device). Posee la funcionalidad necesaria para comunicarse con un Coordinador o un Router, pero no puede transmitir informacin destinada a otros End Points. De esta forma, este tipo de nodo puede estar dormido la mayor parte del tiempo, aumentando la vida media de las bateras que lo alimentan, adems de que tiene requerimientos mnimos de memoria y es por tanto significativamente ms barato [1, p. 2].
1.2. ARQUITECTURA La arquitectura ZigBee se basa en el modelo de siete capas OSI, dejando las dos capas inferiores, la fsica y la de acceso al medio (MAC) al estndar IEEE 802.15.4. De este modo, ZigBee especifica nicamente la capa de red, los mecanismos de seguridad a emplear y la interfaz con la capa de aplicacin para completar lo que se conoce como la pila o stack de ZigBee. Esta ltima estar formada por la subcapa de soporte de la aplicacin (APS), el objeto de dispositivo ZigBee (ZDO, ZigBee Device Object) y los objetos de aplicacin definidos por el fabricante, que se comunicarn con el resto de la arquitectura desde la plataforma de aplicacin (AF) a travs de sus puntos de acceso de servicio [2].
El hecho que ZigBee maneje la parte alta del estndar IEEE 802.15.4 significa que puede tomar muchas ventajas de las cualidades del estndar, pero tambin sufre sus limitaciones, como por ejemplo, la baja tasa de transmisin de datos. Comparado con otros estndares inalmbricos el stack de ZigBee es pequeo. Para dispositivos de puente de red con capacidad limitada, el stack requiere cerca de 4Kb de memoria. La implementacin completa de la pila ZigBee requiere menos de 32Kb de memoria. El coordinador de red requiere memoria RAM extra para una base de datos de dispositivos nodo, tablas de transaccin y tablas de emparejamiento [1, p. 29].
Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo
Figura 1. Esquema de la arquitectura ZigBee [2, p. 51] 1.2.1. NIVEL DE RED (NWK) La funcin principal de este nivel debe ser asegurar un correcto uso del nivel MAC especificado en el estndar IEEE 802.15.4 y ofrecer una interfaz adecuada al nivel de aplicacin para que ste pueda hacer uso de sus servicios fcilmente. Esta capa tiene tres objetivos principales: asociacin o disociacin de los dispositivos usando el coordinador de red, implementacin de seguridad y encaminamiento de tramas a su destino. Adems es responsable de iniciar una nueva red cuando sea necesario y asignar las nuevas direcciones a los dispositivos asociados a esta. Este nivel est formado por dos entidades: la entidad de datos NLDE (Network Layer Data Entity) y la entidad de gestin NLME (Network Layer Management Entity) [2, p. 52].
A. Entidad de Datos del Nivel de Red (NLDE) Proporciona los siguientes servicios: Generacin de tramas de nivel de red. Encaminamiento de mensajes segn sea la topologa especfica que se est usando. Autenticacin y confidencialidad de las comunicaciones.
Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo B. Entidad de Gestin del Nivel de Red (NLME) Proporciona los siguientes servicios: Configuracin de la pila de protocolos para un funcionamiento correcto. Establecimiento de una nueva red ZigBee. Asociacin, re-asociacin y abandono de una red. Asignacin de direcciones a los dispositivos que se incorporen a la red. Descubrimiento, seguimiento y notificacin de dispositivos ZigBee adyacentes. Descubrimiento de rutas para el encaminamiento de paquetes en la red. Control del estado activo/inactivo del receptor. Encaminamiento de paquetes mediante diferentes mecanismos: Unicast, Broadcast, Multicast, o many-to-one para el intercambio eficiente de datos en la red.
C. Topologas de red En ZigBee existen tres tipos de topologas: estrella, rbol y en red malla (Mesh Network), que pueden observarse en la Figura 2. Siempre hay un nodo de red que asume el papel de coordinador central encargado de centralizar la adquisicin y las rutas de comunicacin entre los dispositivos que conforman la red. Adems, si se aplica el concepto de Mesh Network, pueden existir coordinadores o routers, alimentados permanentemente en espera de recibir o repetir las tramas de los dispositivos.
Figura 2. Topologas de red disponibles en ZigBee El concepto de red nodal o Mesh Network es un concepto novedoso y quizs corresponde a la funcionalidad ms potente que ofrece ZigBee, donde cualquier dispositivo dentro de la red puede conectarse con otro utilizando a varios de sus compaeros como repetidores. A esto se le conoce como enrutado multi-salto (multi-hop), donde, primero hace llegar la informacin al nodo ZigBee vecino, el cual puede adems ser coordinador de la red, para as llegar al nodo destino, pasando por todos los nodos que sean necesarios. De esta manera cualquier nodo ZigBee puede hacer llegar los datos a cualquier parte de la red inalmbrica siempre y cuando todos los dispositivos tengan un vecino dentro de su rango de cobertura.
1.2.2. NIVEL DE APLICACIN (APL) Este nivel est situado en la parte ms alta del modelo de capas definido por la especificacin ZigBee y se compone de los siguientes subniveles: el subnivel de soporte de aplicacin (APS), la plataforma de aplicacin (AF) y el objeto de dispositivo ZigBee (ZDO) [2, p. 55]. Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo
A. Subnivel de Soporte de Aplicacin (APS) La subcapa de soporte de la aplicacin (APS) provee de una interfaz entre la capa de red (NWK) y la capa de aplicacin (APL), a travs de un conjunto de servicios que las aplicaciones definidas por los fabricantes comparten con el ZDO [2, p. 55]. Esta subcapa otorga una comunicacin segura y fiable mediante el envo de reintentos y tramas de asentimiento de aplicacin (ACK opcionales), adems de responsabilizarse de la fragmentacin y re-ensamblado de paquetes cuando sea necesario. En este subnivel, se distingue entre una entidad de datos (APSDE) y una entidad de gestin (APSME), ambos con sus respectivos puntos de acceso (SAP). La APSDE provee del servicio de transmisin de datos entre dos objetos de aplicacin de dos dispositivos pertenecientes a la misma red, otorgando filtrado de direcciones de grupo, rechazo de mensajes duplicados y comunicacin a travs de ligaduras (bindings) La APSME provee de diversos servicios a los objetos de aplicacin, entre los cuales se incluye la seguridad, la gestin de grupos (para mensajes Multicast) y los bindings entre dispositivos. Adicionalmente se encarga de mantener una base de datos de los objetos gestionados [2, p. 55].
i. Ligaduras (Bindings) Las ligaduras son enlaces virtuales que se establecen entre clusters de dos objetos de aplicacin complementarios. Esto quiere decir que se hace una asociacin lgica entre una funcionalidad de una aplicacin actuando como servidor y otra funcionalidad compatible de otra aplicacin actuando como cliente, un ejemplo habitual podra ser el establecimiento de una ligadura entre las actuaciones de encendido/apagado de un interruptor de pared y el encendido/apagado de una bombilla. Habitualmente los bindings se establecen de forma que sea muy sencillo para el usuario/instalador: mediante la pulsacin de un switch de los dispositivos implicados, mediante comandos emitidos desde una aplicacin controladora, etctera. Esto permite efectuar la asociacin lgica entre dispositivos de funcionalidades similares de forma casi plug&play, lo cual otorga a la red ZigBee de un gran potencial, escalabilidad e interoperabilidad sin necesidad de instalaciones complicadas y costosas [2, p. 57].
B. Plataforma de aplicacin (AF) La plataforma de aplicacin es el entorno sobre el cual se alojan los objetos de aplicacin ZigBee y que otorga la interfaz imprescindible para que stos puedan comunicarse con el resto de las capas que conforman la pila y con los objetos de aplicacin de otros dispositivos de la red. Aunque cada nodo de una red ZigBee est dotado de una direccin larga de 64 bits y recibe adicionalmente una direccin corta de 16 bits (identificador de nodo) al asociarse a sta, se requiere un mecanismo para direccionar cada uno de los distintos objetos de aplicacin que pueden residir dentro de un mismo nodo. De este modo, cada objeto de aplicacin se identificar mediante un endpoint (punto final) numerado con un valor entre 1 y 240. Los valores 0 y 255 identificarn el ZDO y la interfaz de transmisiones Broadcast respectivamente, mientras que el resto de valores entre 241 y 254 se reservarn para usos futuros [2, p. 57]. Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo Adicionalmente, cada objeto de aplicacin asociado a un endpoint podr describirse a travs de un identificador de tipo de dispositivo que ser nico dentro de cada perfil de aplicacin y mediante el conjunto de clusters y atributos que contiene.
i. Objetos de aplicacin Son objetos definidos por cada fabricante, que se emplean para definir diferentes perfiles de aplicacin ZigBee. Estos perfiles son acuerdos de comandos, formatos de mensaje y acciones de procesado que permiten a los desarrolladores, la creacin de una aplicacin interoperable distribuida entre las entidades de aplicacin residentes dentro de dispositivos de diferentes fabricantes. Un ejemplo de perfil de aplicacin ZigBee es el Home Automation Profile, que permite a distintos tipos de dispositivos el intercambio de mensajes de control para el establecimiento de una aplicacin inalmbrica de automatizacin del hogar. De este modo, los dispositivos pertenecientes a la red pueden, por ejemplo, enviar tramas conocidas para apagar/encender luminarias, emitir medidas de temperatura a termostatos, o el envo de alarmas por deteccin de movimiento. Otro ejemplo vlido podra ser el perfil de dispositivo ZigBee (ZDP), soportado por todos los dispositivos ZigBee, y que define las acciones comunes entre dispositivos ZigBee como son las asociaciones a la red y el descubrimiento de dispositivos y servicios. Otro perfil corresponde al Smart Energy, que ofrece a empresas y a proveedores de energa un sistema sencillo y seguro para la gestin inalmbrica del consumo energtico en redes de rea del hogar (HAN). De este modo se pueden programar, de forma sencilla, aplicaciones de gestin y eficiencia energtica para adecuarse a los requisitos impuestos por el gobierno [2, p. 58].
ii. Clusters Son conjuntos de atributos y comandos relacionados que definen una interfaz de comunicacin entre dos dispositivos, uno de los cuales emplea las funcionalidades que ofrece como cliente el clster mientras que el otro har uso de las herramientas que ofrece como servidor. Los clusters se identifican de forma unvoca mediante un identificador de 16 bits que ser nico dentro de un determinado perfil de aplicacin.
C. Objeto de dispositivo ZigBee (ZDO) Define la funcin del dispositivo en la red ZigBee (Coordinador, router o dispositivo final) y se comporta como la interfaz existente entre los objetos de aplicacin, el perfil del dispositivo y la plataforma de soporte de la aplicacin (APS). El ZDO se localiza siempre en el endpoint 0, desde donde se comunica con las capas inferiores de la pila del protocolo a travs de sus puntos de acceso (APSDE-SAP para transmisin de datos y APSME-SAP para mensajes de control). El ZDO satisface los requisitos comunes de todas las aplicaciones que operan empleando la pila de protocolos ZigBee. De este modo, es responsable de: Inicializar la capa de soporte de aplicacin (APS), la capa de red (NWK) y el proveedor de servicios de seguridad (SSP). Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo Recopilar informacin de configuracin de los objetos de aplicacin para desempear adecuadamente las funciones de descubrimiento de dispositivos y servicios, gestin de seguridad, gestin de red y gestin de bindings [2, p. 59].
2. MDULOS DE COMUNICACIN XBEE Son dispositivos que integran un transmisor y un receptor de radiofrecuencia, integran un procesador en el mismo mdulo, lo que le permite a los usuarios desarrollar aplicaciones de manera rpida y sencilla. Estos dispositivos operan bajo el protocolo de comunicaciones inalmbricas ZigBee y utilizan el estndar de red IEEE 802.15.4 para crear redes FAST POINT-TO-MULTIPOINT (punto a multipunto), o para redes PEER-TO-PEER (punto a punto). Fueron diseados para aplicaciones que requieren de un alto trfico de datos, baja latencia y una sincronizacin de comunicacin predecible.
Figura 3. Mdulo Xbee MaxStream En la actualidad la empresa Digi International, empresa lder mundial en el desarrollo de mdems de conexin a redes inalmbricas para dispositivos electrnicos, suministra ciertas referencias de mdulos de radiofrecuencia, denominados Xbee y XBee-PRO, que ofrecen una solucin excepcionalmente potente para los numerosos mercados que adoptan la conexin a redes inalmbricas para sus aplicaciones de comunicaciones de datos. La lnea de productos XBee se puede encontrar en diversas aplicaciones industriales y comerciales, como sensores remotos, control y manipulacin de robots, control de equipos y automatizacin. Si bien existen bastantes mdulos inalmbricos, estos son los que mantienen la relacin exacta entre precio y calidad, y debido a su pequeo tamao y fcil programacin (slo requiere una conexin serial) son ideales para cualquier proyecto.
2.1. FUNCIONAMIENTO Los mdulos tienen 6 conversores anlogo-digital y 8 entradas digitales, adems de las lneas de recepcin y transmisin serial (RX y TX). Por ser mdulos con microcontrolador integrado se tienen solucionados los problemas de fallo de trama, ruidos, etc. Estos se comunican con dispositivos RS232 a niveles TTL con lo cual la comunicacin necesita un adaptador intermedio en el caso de un PC, pero pueden conectarse directamente a una placa de desarrollo como es Arduino, o cualquier otro sistema basado en microcontrolador que cuente con interfaz serial UART. Los mdulos ofrecen una velocidad de comunicacin desde 1200 hasta 115200 baudios, pasando por todos los valores convencionales, tambin disponen de varias puertos I/O Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo que pueden ser configurados para diferentes funciones; conversor analgico digital, generacin de PWM, entrada digital y salida digital. Para poder configurar todos los parmetros de los mdulos es necesario emplear el software X-CTU suministrado por la empresa que los comercializa (DIGI International), donde la interfaz permite una rpida programacin de cada uno de estos o hacer uso de programas de comunicacin que empleen interfaz serial, en cuyo caso se har uso de comandos AT para programarlos. Dichos parmetros permitirn establecer la comunicacin de cada uno de los mdulos de radiofrecuencia que conforman la red, segn corresponda la topologa, teniendo en cuenta que siempre debe existir un dispositivo configurado como coordinador.
Figura 4. Interfaz Grfica del X-CTU 2.2. CONEXIN BSICA Para ser utilizado cada mdulo, se requiere cierta conexin fsica que permita programarle los parmetros de configuracin, esto es conectar las lneas de transmisin de datos por medio de la UART (lneas TXD y RXD, Figura 5) para comunicarlo con un microcontrolador o dispositivo que soporte la misma interfaz de comunicacin (Figura 6), o comunicarlo directamente a un puerto serial utilizando un conversor adecuado para los niveles de voltaje. Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo
Figura 5. Pines y conexiones mnimas requeridas para el Xbee Cada mdulo requiere una alimentacin que va desde 2.7 a 3.6 voltios (dependiendo de la referencia utilizada), y en su configuracin bsica no se permite el uso de control de flujo de datos por hardware que hace participar activamente las lneas RTS y CTS del estndar. Por lo que esta opcin debe ser deshabilitada en el terminal y en el mdulo XBee, en el caso de que se enve gran cantidad de informacin, donde el buffer del mdulo se puede sobrepasar, se puede hacer uso de esta alternativa [3, p. 12].
Figura 6. Diagrama del sistema de flujo de datos en entornos que utilicen interfaz UART [4, p. 26] 2.3. DATOS SERIALES Los datos entran al mdulo por el pin DIN (pin 3 del mdulo) como una seal serial asncrona. Cada dato consiste de un bit de inicio, 8 bits de datos y un bit de parada como ensea la Figura 7. Esto significa que tanto la UART del microcontrolador como la del mdulo RF debe ser configurada con los mismos parmetros (igual baudio, igual bit de paridad, igual bits de parada, igual bits de inicio e igual bits de datos) [4, p. 26].
Figura 7. Diagrama de transmisin serial a travs del mdulo Xbee [4, p. 26] 2.4. BUFFERS SERIALES Los mdulos XBee tienen pequeos buffers para almacenar los datos recibidos serialmente e inalmbricamente, como se ilustra en la Figura 8. El buffer de recepcin serial almacena los caracteres recibidos (a travs del pin DIN del mdulo) y los mantiene hasta que puedan ser procesados. El buffer de transmisin serial almacena los datos que son recibidos va radiofrecuencia para luego ser trasmitidos a travs de la UART (pin DOUT del mdulo XBee). Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo
Figura 8. Diagrama de flujo de datos interno del mdulo XBee [4, p. 27] 2.5. PROTOCOLOS DE LA INTERFAZ SERIAL Los mdulos Xbee soportan dos protocolos de comunicacin; la interfaz serial transparente y la interfaz API (Application Programming Interface).
2.5.1. OPERACIN TRANSPARENTE Cuando se opera en modo transparente, los mdulos actan como reemplazo de las lneas seriales de la interfaz UART. Todos los datos UART recibidos a travs del pin DIN se ponen en cola para la transmisin RF. Cuando se reciben los datos de RF, los datos se envan a travs del pin DOUT. Los parmetros de configuracin del mdulo se configuran a travs de la interfaz de modo de comandos AT. Los datos se almacenan temporalmente en el buffer de recepcin serial hasta que una de las siguientes causas provoca que los datos sean empaquetados y transmitidos: No se reciben caracteres seriales en el tiempo determinado por el parmetro RO (Packetization Timeout). Si a este parmetro se le asigna el valor cero, el empaquetamiento empieza cuando un caracter es recibido. Se sobrepasa el nmero mximo de caracteres que caben en un paquete de RF recibido.
2.5.2. OPERACIN API Esta operacin es alternativa a la operacin en modo transparente, donde este modo est basado en la utilizacin de tramas que extienden el nivel al que una aplicacin host puede interactuar con las capacidades de red del mdulo. Cuando est en modo API, todos los datos que entran y salen del mdulo estn contenidos en las tramas que definen las operaciones o eventos dentro del mdulo. La transmisin de tramas de datos (recibidas a travs del pin DIN) incluye: Transmisin RF de tramas de datos. Tramas de comandos (equivalente a los comandos AT) La recepcin de tramas de datos (enviadas por el pin DOUT) incluye: Recepcin RF de tramas de datos. Respuesta a comandos. Notificacin de eventos como reinicio, asociar, desasociar, etc. El modo API proporciona medios alternativos de configuracin de los mdulos y los datos de enrutamiento en la capa de aplicacin host. Una aplicacin host puede enviar Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo tramas de datos al mdulo conteniendo informacin sobre la direccin y la carga til en lugar de utilizar el modo de comandos para modificar la direccin de envo. Este modo tiene la capacidad de enviar tramas de datos a la aplicacin conteniendo paquetes de estado relacionados con la fuente, informacin de la carga til de los paquetes de datos recibidos y cuenta con la capacidad de transmitir datos a mltiples mdulos remotos solo cambiando el campo de direccin en las tramas API. Este proceso es mucho ms rpido que el realizado en la operacin transparente donde la aplicacin debe hacer entrar en modo de comandos al mdulo, cambiar la direccin, salir del modo de comandos y transmitir los datos [4, p. 28].
2.6. MODOS DE OPERACIN Los mdulos XBee pueden operar en 5 modos.
Figura 9. Modos de operacin 2.6.1. MODO INACTIVO (IDLE MODE) Cuando no se est recibiendo ni transmitiendo datos, el modulo RF se encuentra en estado inactivo. Este se desplaza en los otros modos de operacin bajo las siguientes condiciones: Modo de transmisin (datos seriales en el buffer de recepcin que estn listos para ser empaquetados) Modo de recepcin (datos RF vlidos que se reciben a travs de la antena) Modo de espera (dispositivos finales solamente) Modo de comando (secuencia de comandos enviada)
2.6.2. MODO DE TRANSMISIN (TRANSMIT MODE) Cuando se reciben datos serialmente y estn listos para el empaquetamiento, el mdulo RF saldr del modo inactivo y tratar de enviar los datos, donde la direccin de destino determina qu nodos recibirn los datos. Antes de la transmisin de los datos, el mdulo se asegura de que la direccin de red de 16-bits y la ruta del nodo destino han sido establecidas. Si no se conoce la direccin de 16-bits, se har el descubrimiento de dicha direccin de red. Si no se conoce la ruta de destino, se har el descubrimiento con el Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo propsito de establecer una ruta al nodo destino y si no se descubre un mdulo con una direccin de red, el paquete se descarta, finalmente una vez establecida la ruta, los paquetes sern enviados. Cuando se transmiten datos de un nodo a otro, un reconocimiento (Acknowledge, ACK) a nivel de red se transmite de vuelta por la ruta establecida al nodo de origen. Este paquete de reconocimiento indica al nodo origen que el paquete de datos fue recibido por el nodo destino, sino se recibe el reconocimiento, el nodo origen retransmitir los datos. Es posible en circunstancias poco comunes para el nodo destino recibir un paquete de datos, pero no recibir el reconocimiento de red el nodo origen, en este caso el nodo fuente retransmitir los datos, lo que podra causar que el nodo destino reciba el mismo paquete de datos mltiples veces [4, p. 30].
Figura 10. Secuencia para el modo de transmisin 2.6.3. MODO DE RECEPCIN (RECEIVE MODE) Si un paquete RF vlido es recibido, el dato es transferido al buffer de transmisin serial.
2.6.4. MODO DE COMANDOS (COMMAND MODE) Para modificar o leer los parmetros del mdulo RF, este debe entrar primero en el modo de comandos (un estado en el que los caracteres seriales de entrada se interpretan como comandos). Este modo permite ajustar parmetros como la direccin propia o la de destino, establecer el identificador de la red, as como su modo de operacin entre otras cosas. Para poder ingresar los comandos es necesario utilizar el Hyperterminal de Windows o el programa pertinente de acuerdo al sistema operativo, el programa X-CTU Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo o algn microcontrolador que maneje UART y tenga los comandos almacenados en memoria o los adquiera de alguna otra forma [4, p. 31].
A. Entrar al modo de comandos AT Para ingresar a este modo se debe esperar un tiempo dado por el parmetro GT (Guard Times, por defecto tiene un valor de 1000ms (0x3E8)), luego se enva tres caracteres que representan la secuencia de comandos +++ para luego esperar un tiempo determinado por el comando GT. Lo que significa que no se pueden enviar caracteres mientras pasa este tiempo estimado. Una vez la secuencia del modo de comandos AT es aceptada el mdulo enva como respuesta la cadena de caracteres OK\r a travs del pin DOUT. Esta respuesta se puede retrasar si el modulo no ha terminado la transmisin de datos recibidos. El mdulo XBee viene por defecto con una velocidad de 9600bps, en caso de no poder ingresar al modo de comandos, es posible que sea debido a la diferencia de velocidades entre el mdulo y la interfaz que se comunica va serial.
B. Envo de comandos AT Para realizar el envo de comandos se debe emplear la siguiente sintaxis:
Figura 11. Sintaxis para el envo de comandos AT Para leer algn parmetro almacenado en el registro del mdulo se debe omitir el campo de parmetro. Para que los valores de los parmetros modificados se mantengan en el registro del mdulo despus de ejecutar un reinicio, se deben almacenar en la memoria no voltil utilizando el comando WR (Write). De lo contrario, los valores se reestablecen a los valores guardados anteriormente despus de reiniciar el mdulo [4, p. 31].
C. Respuesta al comando Cuando un comando es enviado al mdulo, este lo analiza y luego lo ejecuta. Luego de ejecutarlo exitosamente, este retorna el mensaje OK, si la ejecucin del comando resulta en error, el mdulo enviar un mensaje de ERROR.
D. Salida del modo de comandos AT Para salir del modo de comandos se ingresa el comando ATCN (Exit Command Mode). En caso de que no se ingrese ningn comando AT vlido durante el tiempo determinado por el parametro CT (Command Mode Timeout), el mdulo se saldr automticamente y entrar en modo inactivo.
2.6.5. MODO DE SUEO (SLEEP MODE) Este modo permite al mdulo entrar en estados de bajo consumo de energa cuando no est en uso. Los mdulos XBee soportan tanto el modo de sueo a travs de un pin Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo especfico y el sueo cclico (que es la capacidad del mdulo de dormir durante un periodo determinado). La configuracin de los ciclos de sueo se realiza principalmente con el comando SM (Sleep Mode). Por defecto, los modos de sueos estn deshabilitados (SM=0), permaneciendo el mdulo en estado inactivo, lo que significa que el mdulo XBee est siempre preparado para responder a un comando, ya sea, por la interfaz serial o la interfaz RF [4, p. 32].
3. COMUNICACIN INALMBRICA ZIGBEE Teniendo en cuenta que los mdulos ofrecen dos modos de operacin, no se utiliza el modo transparente porque no ofrece la suficiente robustez en la comunicacin; de tal forma que no permite verificar la validez de los datos transmitidos, no permite la recepcin de tramas de reconocimiento (ACK frames), adems de que establecer transmisiones a distintos dispositivos se puede hacer un poco tedioso por el procedimiento que se debe seguir. Contrariamente a estas desventajas, se presenta el modo API que si permite verificar que los paquetes transmitidos por el nodo fuente y recibidos por el nodo destino no contengan errores (a travs de sumas de verificacin de errores), permite enviar informacin a otros dispositivos de manera sencilla (solo cambiando el campo de direccin de las tramas API), recibir tramas ACK para verificar y determinar los errores (en caso de que se produzcan) en la recepcin de los paquetes, entre otras funcionalidades que se explican a profundidad en las siguientes secciones.
3.1 OPERACIN API Para comprender este modo de operacin y la estructura de las tramas de comunicacin que ofrece, es necesario entender ciertos conceptos. El primero es comprender la interfaz de programacin de aplicaciones (API, Application Programming Interface), esta simplemente es un conjunto de interfaces estndar creadas para permitir a un programa interactuar con otros, para este propsito lo ms importante a destacar de la API es que est diseada especficamente para habilitar la comunicacin eficiente entre equipos. Lo segundo es comprender que es un protocolo, teniendo presente que cada transferencia de informacin requiere de un protocolo se puede definir ste simplemente como reglas para establecer una comunicacin. Existen protocolos establecidos para las comunicaciones inalmbricas de computadores, al igual que existen protocolos para establecer una comunicacin casual entre dos seres humanos, eso quiere decir que tanto las personas como los computadores se enfrentan a los mismos problemas de comunicacin que deben ser resueltos de manera similar. En ese sentido se puede hablar de una comunicacin bsica cuando, por ejemplo, un computador o un dispositivo habla sin parar y el otro escucha tolerando ciertos errores. Si se establece un protocolo ms complicado se puede definir si hay algn tipo de establecimiento de comunicacin (handshaking) involucrado para constituir el intercambio de informacin, problemas de tiempo, qu respuestas son enviadas cuando se transmiten mensajes, estrategias de enrutamiento, y as sucesivamente. Desde este contexto la operacin API requiere que la comunicacin con el mdulo se haga a travs de una interfaz estructurada, eso quiere decir que los datos se comunican a partir de tramas en un orden definido, donde se establece los comandos a operar, respuesta a los comandos y los mensajes de estado que son enviados y recibidos del mdulo utilizando la interfaz serial UART (Universal Asynchronous Receiver-Transmitter). Por lo tanto, el Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo objetivo de las comunicaciones en modo API es transmitir datos rpidamente, altamente estructurados, predecibles y fiables. Para trabajar en modo API, lo mdulos XBee deben ser configurados para tal fin usando el software X-CTU como se muestra en la Figura 12. En las siguientes seccionas se mostrarn pantallazos de cmo configurar otros parmetro del modo API usando dicho software.
Figura 12. Seleccin del firmware adecuado con la terminacin API 3.1.1 MODOS API Los mdulos soportan dos modos API de funcionamiento, donde ambos pueden ser habilitados utilizando el comando AP (API Enable). Los parmetros a utilizar para que el mdulo opere en un modo particular corresponden:
AP = 1: Operacin API
Figura 13. Modo API 1 AP = 2: Operacin API con carcter de escape
Figura 14. Modo API con caracter de escape a) Operacin API, Comando AP en 1 Cuando este modo est habilitado, la estructura de la trama API es definida de la siguiente manera:
Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo
Figura 15. Estructura de la trama API [2, p. 98] Cualquier dato recibido antes del delimitador de inicio es descartado, si la trama no se recibe correctamente o si la suma de comprobacin falla, el mdulo responder con una trama de estado indicando la naturaleza de la falla.
b) Operacin API con Carcter de Escape, Comando AP en 2 Cuando este modo est habilitado, la estructura de la trama API es definida de la siguiente manera:
Figura 16. Estructura de la trama API con carcter de escape [2, p. 98] Cuando se envan o reciben tramas de datos a travs de la interfaz serial UART, los valores especficos de esa trama deben escaparse (marcarse) de modo que no interfieran con la secuencia de trama de datos. Para escapar un byte que interfiere con la secuencia de datos de la trama es necesario insertar el valor 0x7D, para luego con el byte a ser escapado aplicar la operacin lgica XOR con el valor 0x20. En definitiva, con este modo se garantiza que el caracter 0x7E slo aparece en la trama de datos para indicar el inicio de una trama, si alguno de los datos a transmitir contiene el valor 0x7E, ste resulta reemplazado por una secuencia de escape. Lo mismo se aplica a los caracteres de control de flujo XON/XOFF (0x11 y 0x13) y al carcter de escape 0x7D.
3.1.2 ESTRUCTURA DE LA TRAMA API Como la trama API consiste de una serie de bytes, a continuacin se explica el significado de cada uno:
a) Delimitador de inicio (Start Delimiter) Cada trama API comienza con un byte de inicio, este es un nmero nico que indica cual es el inicio de la trama de datos, en este caso la API de XBee utiliza el valor 0x7E (126 en decimal). Esto significa que si se estn leyendo bytes a travs de la interfaz serial no se sabe lo que representan hasta que se conozca su orden, por lo tanto lo primero que se debe hacer es buscar dentro de esa serie de bytes el carcter que identifica el inicio de trama (0x7E). Una vez se tiene dicho carcter, ya se puede proceder a identificar la dems informacin que conforma la trama API, recibida despus del identificador de inicio.
Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo b) Longitud de la Trama (Length) Los siguientes dos bytes recibidos despus del byte de inicio indican la longitud total de la trama de datos. Esto permite al momento de implementar la librera que interpreta la trama, conocer cunto se debe mantener la lectura de los bytes antes de parar, en efecto deja saber cunta memoria se debe reservar, en el microcontrolador, para almacenar la trama en su totalidad. Aunque se especifican dos bytes (65,535 como mximo) para establecer el tamao de la trama se debe tener en cuenta, que el estndar IEEE 802.15.4 sobre el que se basa ZigBee establece un tamao mximo de trama de 127 bytes incluyendo la carga til o payload. En este caso el manual de usuario de los mdulos utilizados indica que es posible enviar como mximo 84 bytes de payload, que se debe tener en cuenta para evitar la prdida de informacin.
c) Trama de Datos (Frame Data) La trama de datos especifica cada tipo de mensaje que se recibe del mdulo XBee, donde se explicar en detalle, en los siguientes acpites, cada uno de los bytes que conforma las tramas principales de los dispositivos utilizados. Se debe tener en cuenta que en este punto ya se ha ledo los dos bytes de tamao, por lo que ya se sabe exactamente cul es el tamao de cada trama de datos a procesar.
d) Checksum Finalmente el ltimo byte de la trama es una suma de comprobacin (Checksum), que se calcula sobre la base de todos los bytes que se reciben antes de este byte final. Simplemente es una suma de todos los bytes que conforman las tramas API, utilizada para comprobar en el extremo receptor, errores de transmisin. Se debe tener en cuenta que para verificar la integridad de los datos, la suma de comprobacin se calcula y se verifica sobre los datos que no se les ha aplicado la secuencia de escape. Para calcular el Checksum no se debe incluir el delimitador de trama y los bytes de longitud, luego se debe sumar todos los bytes que conforman la trama de datos, manteniendo solo los 8 bits ms bajos del resultado para en seguida restarle el valor 0xFF. Para verificar el Checksum se debe sumar todos los bytes, incluyendo el byte de Checksum pero no el byte delimitador de inicio y los dos bytes de longitud. Si la suma de comprobacin es correcta el resultado debe ser igual al valor 0xFF. Esta frmula es muy sencilla de programar, puesto que solo implica sumas y sustracciones que calcular, para mantener los bits ms bajos del resultado solo basta que en el cdigo se aplique la operacin de mascara de bits (&0xFF).
3.1.3 ESPECIFICACIONES DE LAS TRAMAS API Dentro de la estructura de la trama general, existen subestructuras que cubren todos los diferentes tipos de datos que se pueden enviar y recibir de los mdulos de radiofrecuencia, donde diferentes tipos de tramas contienen diferentes tipos de estructuras de datos que siguen diferentes patrones estandarizados para ayudar a transmitir los diferentes tipos de informacin. Existen 18 tipos de tramas API definidas por la empresa DIGI International en sus mdulos XBee, en los siguientes apartados se mirarn solo las ms importantes. Es relevante saber que el byte que indica el tipo de trama nos indica qu tipo de trama API se est empleando, Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo esto con la finalidad de conocer qu significa la informacin que se lee a partir de este indicador. As por ejemplo, si el tipo de trama indica que es una trama de comando AT, leyendo los primeros cuatro bytes se conocer dnde la trama inicia (a partir del byte de inicio), cual es la longitud total de la trama de datos (con los dos bytes de longitud), y que tipo de trama se est empleando (con el byte de tipo de trama)
a) Estructura de la Trama de Datos Cada trama de datos API se forma a partir de la siguiente estructura (Figura 17)
Figura 17. Estructura de la trama de datos API [4, p. 99] El campo cmdID indica el tipo de trama API, donde a cada una se le asigna un valor numrico nico. Y el campo cmdData contiene todos los bytes que estructuran el tipo de trama. Los mdulos XBee trabajados soportan los siguientes tipos de tramas API:
Tabla 1. Tramas API Nombre trama API Identificador API AT Command 0x08 AT Command Queue Parameter Value 0x09 ZigBee Transmit Request 0x10 Explicit Addressing ZigBee Command Frame 0x11 Remote Command Request 0x17 Create Source Route 0x21 AT Command Response 0x88 Modem Status 0x8A ZigBee Transmit Status 0x8B ZigBee Receive Packet (AO = 0) 0x90 ZigBee Explicit Rx Indicator (AO = 1) 0x91 ZigBee IO Data Sample Rx Indicator 0x92 XBee Sensor Read Indicator (AO = 0) 0x94 Node Identification Indicator (AO = 0) 0x95 Remote Command Response 0x97 Over-the-Air Firmware Update Status 0xA0 Route Record Indicator 0xA1 Many-to-One Route Request Indicator 0xA3
Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo b) Intercambio de Trama API 1. Comandos AT La Figura 18 muestra el intercambio de tramas API que se lleva a cabo al enviar una solicitud de comando AT para leer o establecer algn parmetro del mdulo. La respuesta puede deshabilitarse estableciendo el identificador de la trama (Frame ID) en 0 al hacer la solicitud.
Figura 18. Peticin y Respuesta al tipo de trama AT Commands [4, p. 101] 2. Transmisin y recepcin de datos RF La Figura 19 ensea los intercambios API que se llevan a cabo cuando se envan datos a otro dispositivo. La transmisin de la trama de estado siempre se enva al final de la transmisin de datos, a menos que se establezca el identificador de trama (Frame ID) en 0 al hacer la peticin de transmisin. Si el paquete no puede ser entregado al nodo destino, la transmisin de la trama de estado indicar la causa de la falla. La trama de datos recibida (0x90 o 0x91) se establece mediante el comando AP.
Figura 19. Transmisin y recepcin de datos, tipos de tramas API utilizadas [4, p. 101] 3. Comandos AT remotos La figura 20 muestra el intercambio de tramas API que tienen los mdulos cuando se enva un comando AT a distancia. Si la trama de respuesta al comando remoto no es enviada significa que el nodo destino no recibi dicho comando.
Figura 20. Intercambio de tramas API Remote AT Commands [4, p. 101]
Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo c) Tipos de Trama API Las siguientes secciones ilustran los tipos de tramas en el modo API de los mdulos.
1. AT Command Este tipo de trama permite enviar comandos AT para configurar a s mismo el mdulo XBee. A travs de este tipo se puede consultar la configuracin local del dispositivo o establecer parmetros de configuracin, donde dichos parmetros se establecen de manera equivalente a la que se hace directamente en el modo transparente/comando. Como todos los tipos de tramas, esta empieza con el byte delimitador de inicio (0x7E), seguido de los dos bytes de longitud de la trama de datos, luego de estos dos bytes se encuentra la informacin que hace nica a este tipo de trama para finalmente establecer el Checksum (Tabla 2).
Tabla 2. Trama API - AT Command [4, p. 103]
Campos de trama Offset Ejemplo Descripcin P a q u e t e
A P I
Delimitador de inicio 0 0x7E Longitud MSB 1 0x00 Nmero de bytes entre la longitud de la trama de datos y el Checksum. Trama de datos LSB 2 0x04 Tipo de trama 3 0x08 ID de la trama 4 0x52 Identifica la trama de datos para el host que se correlaciona con un ACK posterior. Si se establece en 0, no se enva ninguna respuesta. Comando AT 5 0x4E (N) Nombre del comando, dos caracteres ASCII identifican el comando AT. 6 0x4A (J) Valor del parmetro (opcional)
Si est presente, indica el valor del parmetro solicitado para establecer el registro dado. Si no hay caracteres presentes, significa consulta del parmetro. Checksum 7 0x0D
Tipo de trama (Frame Type) La trama AT Comand es identificada con el valor 0x08, esto permite al radio receptor saber que los bytes que siguen corresponden al comando AT a programar o consultar. Identificador de trama (Frame ID) Una vez se ha identificado el tipo de trama, el prximo byte serial contiene el identificador de trama. Este es simplemente un nmero de serie que se le asigna al comando, para identificar en el envo de una serie de comandos cuales regresaron bien y cuales podran haberse perdido o tener algn error. Si el identificador de trama se establece en 0x00, se elimina la posibilidad de recibir respuesta alguna del mdulo XBee, aun as se enviar el comando correspondiente. En general se define el ID de trama con el valor 0x01 para el primer comando AT que se enve, luego 0x02 para el siguiente, y as sucesivamente para cada uno de los comandos que se transmitan hasta llegar al valor 0xFF (mximo valor para un nmero de 8 bits), en este punto se debe reiniciar la asignacin en 1. Comando AT (AT Command) Los dos bytes siguientes al ID de trama corresponden al comando AT en s, donde las letras AT se omiten dado que ya se conoce que esta es una trama AT Command. Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo Solo se utiliza los dos caracteres que identifican al comando AT, en este ejemplo (Tabla 2) se enva el comando NJ (Node Join Time), el primer byte corresponde a la equivalencia ASCII del carcter N y el segundo es la equivalencia ASCII del carcter J. Valor del parmetro (Parameter Value) Si el comando que se enva requiere de parmetro, los siguientes bytes contendrn el valor de configuracin. Si no se suministra el valor del parmetro, el comando enviado se tratar como una consulta, donde los resultados se enviarn devuelta en una trama de respuesta que se detalla ms adelante. Los parmetros que implican un tamao mayor a un byte se deben dividir en varios bytes estableciendo primero la parte ms significativa hasta llegar a la menos significativa. Checksum Finalmente se establece el byte de Checksum que para este ejemplo, los valores que conforman la trama producen el valor 0x0D.
Este tipo de trama ofrece la posibilidad de modificar el mdulo XBee sin utilizar software especializado que maneje el formato de tramas API, como lo es el X-CTU. Solo es necesario establecer el formato de tramas API en un programa que permita comunicacin serial y de esa manera se podr modificar, segn las necesidades, los parmetros de cada dispositivo RF.
2. AT Command Response En el modo API todos los comandos AT enviados al mdulo RF, hacen que el dispositivo XBee genere una respuesta que puede ser leda a travs de la interfaz serial, esta indica el estado del comando y opcionalmente el valor del registro si se ha solicitado la consulta de algn parmetro. Procesar esta respuesta depende del contexto particular en el que se utilice estos dispositivos, en algunos casos simplemente envan los comandos y esperan a que no se produzca errores haciendo caso omiso de las respuestas. Pero si se quiere establecer un sistema a prueba de errores donde se requiera utilizar este tipo de trama API, ya se debe considerar leer esta trama de respuesta para determinar las causas del error y hacer ms robusto el sistema. Un ejemplo claro, son las redes de sensores implementadas en un sitio de difcil acceso, donde cada detalle debe ser abordado de la manera ms estricta, procesando cada respuesta que se genera y dando el tratamiento adecuado a los errores que se conciban en la utilizacin de los mdulos XBee.
Tabla 3. Trama API - AT Command Response [4, p. 110]
Campos de trama Offset Ejemplo Descripcin P a q u e t e
A P I
Delimitador de inicio 0 0x7E Longitud MSB 1 0x00 Nmero de bytes entre la longitud de la trama de datos y el Checksum. Trama de datos LSB 2 0x05 Tipo de trama 3 0x88 ID de la trama 4 0x01 Identifica la trama de datos que se informa, si este campo est en 0 en el modo AT Command, no se obtendr la trama de respuesta AT Command Response. Comando AT 5 B=0x42 Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo 6 D=0x44 Nombre del comando, dos caracteres ASCII identifican el comando AT. Estado del comando 7 0x00 0 = OK 1 = ERROR 2 = Invalid Command 3 = Invalid Parameter 4 = Tx Failure Valor del comando
Registro de datos en formato binario, si este registro fue configurado este campo no se retorna, como en este ejemplo. Checksum
8 0xF0 0xFF menos los 8 bits de la suma desde el Offset 3 hasta este byte.
De igual manera a la trama anterior, esta contiene un byte de inicio, dos bytes de longitud, un byte que identifica el tipo de trama API, un byte identificador de trama, seguido por el tipo de comando AT enviado. Luego de esto se encuentra el estado y los datos del comando, para finalmente obtener el byte de Checksum, calculado de forma habitual (Tabla 3). Tipo de trama (Frame Type) El valor del tipo de trama AT Command Response siempre es 0x88. Identificador de trama (Frame ID) El identificar que se obtiene en la respuesta es el mismo que se enva en la peticin original de la trama AT Command. Comando AT (AT Command) Estos dos bytes son los equivalentes ASCII de los dos caracteres que se enviaron en la peticin AT Command, B y D respectivamente. Estado del comando (Command Status) Este byte ensea el estado del comando AT enviado; 0 indica que todo ocurri de manera satisfactoria es como recibir la cadena OK en el modo de operacin transparente/comando, un valor 1 indica que el comando no fue aplicado correctamente generndose error. Esto significa que fue reconocido pero no puede llevarse a cabo por alguna razn. Cuando se recibe el valor 2 significa que el comando no es vlido (posiblemente porque estableci uno de los caracteres de manera errnea). El valor 3 indica que el comando se ha reconocido, pero que los parmetros que se han enviado estn fuera del alcance. Y finalmente el valor 4 indica falla en la transmisin de la trama. Valor del comando (Command Data) Si la peticin AT Command se hace mediante el envo del comando sin establecer el parmetro, estos bytes contendrn la informacin de respuesta. Esta respuesta se divide en bytes y puede representar un nmero o una cadena ASCII.
3. ZigBee Transmit Request Este tipo de trama es la que permite enviar informacin de un nodo local a otro remoto, establece de qu manera se debe empaquetar la informacin para que esta llegue a su destino. La trama ZigBee Transmit Request encapsula la informacin que conforma el payload (carga til, los datos en s) con un campo que especifica el direccionamiento y con campos que indican ciertas opciones de transmisin que describen cmo el payload se debe enviar hacia su destino. Este tipo de trama es un claro ejemplo de por qu es mejor utilizar Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo el modo API de los mdulos y no el modo Transparente. El potencial radica en que este modo facilita de manera eficiente la configuracin de la direccin de destino sobre la marcha, es decir, sobre tiempo de ejecucin de los mdulos, proceso que favorece la comunicacin en redes sensoriales conformadas por cientos de nodos diferentes que pueden utilizarse como destinos. Algo que no es posible cuando se utiliza el modo transparente, donde para poder realizar la configuracin de la direccin de destino es necesario seguir un procedimiento poco eficiente. La siguiente tabla muestra la estructura de bytes que conforma esta trama API.
Tabla 4. Trama API - ZigBee Transmit Request [4, p. 104]
Campos de trama Offset Ejemplo Descripcin P a q u e t e
A P I
Delimitador de inicio 0 0x7E Longitud MSB 1 0x00 Nmero de bytes entre la longitud de la trama de datos y el Checksum. Trama de datos LSB 2 0x16 Tipo de trama 3 0x10 ID de la trama 4 0x01 Identifica la trama de datos que se informa, si este campo est en 0 en el modo AT Command, no se obtendr la trama de respuesta AT Command Response. Direccin de destino 64-bit MSB 5 0x00 Configura la direccin de 64-bit de destino. Las siguientes direcciones son soportadas:
0x0000000000000000, direccin reservada para el coordinador.
0x000000000000FFFF, direccin Broadcast.
6 0x13 7 0xA2 8 0x00 9 0x40 10 0x0A 11 0x01 LSB 12 0x27 Direccin de destino 16-bit MSB 13 0xFF Configura la direccin de 16-bit de destino si se conoce. Si no se conoce por defecto se configura con el valor 0xFFFE o si es un envo tipo Broadcast. LSB 14 0xFE Radio Broadcast 15 0x00 Configura el nmero mximo de saltos soportados en una transmisin Broadcast. Si se establece en 0, el radio Broadcast estar configurado con el valor mximo de saltos. Opciones 16 0x00 Campo para las opciones de transmisin soportadas. Los valores admitidos son los siguientes:
0x01 Desactiva los reintentos y la reparacin de ruta 0x20 Habilita el cifrado APS (si el parmetro EE = 1) 0x40 Utiliza tiempo de espera de trasmisin extendido
Habilitar el cifrado APS supone que el origen y el destino han sido autenticados. Adems este disminuye el nmero mximo de bytes de Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo payload por un factor de 4 al reportado por el comando NP. El establecimiento del bit de tiempo de espera prolongado hace que el stack configure el tiempo de espera de trasmisin extendido para la direccin de destino. Todos los bits no utilizados y no admitidos deben establecerse en 0. Datos RF 17 0x54 Datos que conforman el payload enviado al dispositivo destino. 18 0x78 19 0x44 20 0x61 21 0x74 22 0x61 23 0x30 24 0x41 Checksum
25 0x13 0xFF menos los 8 bits de la suma desde el Offset 3 hasta este byte.
Nuevamente esta trama la conforma el byte de inicio, dos bytes de longitud, un byte que indica el tipo de trama (en este caso el valor corresponde a 0x10 indicando el tipo de trama ZigBee Transmit Request) y el identificador de trama. Luego de esto sigue la informacin de direccionamiento y la carga til. Para finalmente concluir con la suma de comprobacin de errores. Direccin de destino de 64 bits (64-bit destination address) Este campo lo componen 8 bytes que indican la direccin de destino (nica en el mundo) para la transmisin de informacin. Existen dos direcciones especiales que pueden ser utilizadas; si se quiere contactar al coordinador de red se debe establecer este campo con el valor 0x0000000000000000 y de esta manera se establece comunicacin automticamente. Para enviar un mensaje Broadcast a todos los nodos de la red, se debe configurar esta direccin con el valor 0x000000000000FFFF. Si se quiere descubrir las direcciones de 64 bits presentes en la red se debe hacer uso del comando ATND (Node Discovery) Direccin de red de destino de 16 bits (16-bit destination network address) Estos dos bytes pueden ser utilizados para configurar la direccin de 16 bits de destino, en caso de que se conozca, si no se conoce por defecto se asigna el valor 0xFFFE. Esto har que una bsqueda de direccin se produzca de modo que la transmisin puede ser entregada correctamente, si fue exitosa la bsqueda, la trama Transmit Status indicar la direccin de 16 bits descubierta. El valor 0xFFFE es tambin la configuracin de direccin de 16 bits adecuada para las transmisiones tipo Broadcast que se entregarn a todos los dispositivos de la red. Radio Broadcast (Broadcast Radius) Cada mensaje Broadcast puede ser limitado a un cierto radio, usualmente por el valor de tiempo de espera Broadcast establecido por defecto en ATNH (Maximum Unicast Hops). Esta es una opcin avanzada para ser utilizada en aplicaciones muy especficas, por lo que en este proyecto, este parmetro se establece en 0. Opciones (Options) Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo Este parmetro se configura con el valor 0, esto indica que no hay opciones definidas para este tipo de trama. Datos RF (RF Data) Esta seccin corresponde a la carga til o payload, que es la informacin que se quiere enviar a un nodo especfico. El tamao del payload lo limita la referencia del mdulo XBee utilizado, en este caso las especificaciones para la referencia PRO S2B (empleada en el proyecto propuesto) de Digi International define un tamao mximo de 84 bytes. En caso de que se utilice cifrado o el enrutamiento de origen, ese tamao mximo vara, por lo que es necesario emplear el comando ATNP (Maximum RF Payload Bytes) para determinar los lmites del payload.
4. ZigBee Transmit Status Otra ventaja que ofrece el modo API en las transmisiones es que por cada una, donde se establece un valor distinto de 0 en el identificador de trama (Frame ID), se recibe de vuelta un completo reporte de estado sobre cualquier descubrimiento de nodo, transmisin o problema de entrega. Algunas veces esa trama de estado que se recibe es irrelevante si se est desarrollando un prototipo rpido o se ejecuta una aplicacin que tolera fallos ocasionales en la comunicacin, en definitiva aplicaciones donde no se requieren informes de estado detallados. Pero si la aplicacin es, por ejemplo, las transmisiones que vigilan la seguridad de una casa o que monitorean el estado de un edificio, lo ms seguro es que se requiera hacer la comunicacin lo ms robusta posible, por lo tanto, se debe procesar el mensaje que informa el estado de dicha comunicacin.
Tabla 5. Trama API - ZigBee Transmit Status [4, p. 111]
Campos de trama Offset Ejemplo Descripcin P a q u e t e
A P I
Delimitador de inicio 0 0x7E Longitud MSB 1 0x00 Nmero de bytes entre la longitud de la trama de datos y el Checksum. Trama de datos LSB 2 0x07 Tipo de trama 3 0x8B ID de la trama 4 0x01 Identifica la trama de datos que se informa, si este campo est en 0 en el modo AT Command, no se obtendr la trama de respuesta AT Command Response. Direccin de destino 16-bit MSB 5 0x7D Direccin de 16 bits del paquete que fue entregado (si tuvo xito). Si no fue satisfactoria la entrega, esta direccin ser 0xFFFD: Direccin de Destino Desconocido. LSB 6 0x84 Conteo de reintentos de trasmisin 7 0x00 Numero de reintentos de trasmisin que tuvieron lugar. Estado del envo 8 0x00 0x00 = Success 0x01 = MAC ACK Failure 0x02 = CCA Failure 0x15 = Invalid destination endpoint 0x21 = Network ACK Failure 0x22 = Not Joined to Network 0x23 = Self-addressed 0x24 = Address Not Found Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo 0x25 = Route Not Found 0x26 = Broadcast source failed to hear a neighbor relay the message 0x2B = Invalid binding table index 0x2C = Resource error lack of free buffers, timers, etc. 0x2D = Attempted broadcast with APS transmission 0x2E = Attempted unicast with APS transmission, but EE=0 0x32 = Resource error lack of free buffers, timers, etc. 0x74 = Data payload too large Estado de descubrimiento 9 0x01 0x00 = No Discovery Overhead 0x01 = Address Discovery 0x02 = Route Discovery 0x03 = Address and Route 0x40 = Extended Timeout Discovery Checksum
10 0x71 0xFF menos los 8 bits de la suma desde el Offset 3 hasta este byte.
El formato de esta trama se indica en la Tabla 5. Este tipo de trama se establece con el valor 0x8B, con lo cual se identifica la trama ZigBee Transmit Status. El identificador de trama ser el mismo que se configure en la trama de envo ZigBee Transmit Request y se incluyen nuevos campos para indicar el nmero de reintentos de trasmisin, el estado de entrega de los mensajes, y el estado de descubrimiento de la ruta de trasmisin. Conteo de reintentos de trasmisin (Transmit Retry Count) Cada trasmisin ser intentada hasta tres veces (de forma invisible a lo largo de la ruta) por cada envo RF. El conteo de estos reintentos se enlista en este byte y son parte normal de las redes inalmbricas, por lo que individualmente no son de preocupacin. A pesar de esto, este conteo considerado en su conjunto podra indicar problemas de interferencia. Estado del envo (Delivery Status) Si este byte se encuentra en 0 la trasmisin fue entregada con xito a la direccin de destino, de lo contrario, el numero recibido en este byte indica el tipo de problema que impide la entrega. Esta informacin es til para depurar y posiblemente para decidir si se debe enviar la informacin de nuevo. Aunque muchas aplicaciones no se preocupan del porqu del error, en este caso, desde lo que se quiere plantear con el proyecto, es necesario revisar la causa del error, puesto que un valor distinto de 0 podra indicar que se requiere intentar la trasmisin de nuevo o reportar al usuario que se produjo un error en la comunicacin con los mdulos RF. Estado de descubrimiento (Discovery Status) Este byte proporciona informacin acerca del estado de descubrimiento de la ruta para una transmisin. Para redes muy grandes es posible que se deba darle importancia a este parmetro y considerar el uso de enrutamiento de origen avanzado que ofrece los mdulos XBee. Pero para redes pequeas el estado de deteccin o de descubrimiento se puede ignorar sin acarrear ningn inconveniente en el desarrollo del proyecto. Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo 5. ZigBee Receive Packet Esta es otra trama que proporciona mucho ms de lo que se podra obtener con las simples iteraciones en modo trasparente/comando. Cuando se recibe una trasmisin en modo transparente, se recibe sin ninguna indicacin de quien es el remitente. En una red simple eso es aceptable porque solo hay un remitente, pero en una red ms grande, generalmente es necesario conocer no solo lo que se recibi sino tambin de donde proviene. Adems de los bytes habituales; incluyendo el tipo de trama que corresponde al valor 0x90 para indicar la trama ZigBee Receive Packet y el identificador de trama enviado por el trasmisor, estn los bytes que indican las direcciones de 64 bits y 16 bits junto con los bytes que permiten conocer las opciones de recepcin y por supuesto la carga til de datos en s, seguido finalmente por la suma de comprobacin de errores (Tabla 6).
Tabla 6. Trama API - ZigBee Receive Packet [4, p. 112]
Campos de trama Offset Ejemplo Descripcin P a q u e t e
A P I
Delimitador de inicio 0 0x7E Longitud MSB 1 0x00 Nmero de bytes entre la longitud de la trama de datos y el Checksum. Trama de datos LSB 2 0x11 Tipo de trama 3 0x90 Direccin de origen 64-bit MSB 4 0x00 Direccin de 64 bits del remitente. Se establece en 0xFFFFFFFFFFFFFFFF si la direccin de 64 bits del remitente es desconocida.
5 0x13 6 0xA2 7 0x00 8 0x40 9 0x52 10 0x2B LSB 11 0xAA Direccin de origen 16-bit MSB 12 0x7D Direccin de 16 bits del remitente. LSB 13 0x84 Opciones de recepcin 14 0x01 0x01 - Packet Acknowledged 0x02 - Packet was a broadcast packet 0x20 - Packet encrypted with APS encryption 0x40 - Packet was sent from an end device (if known) Datos recibidos 15 0x52 Datos RF recibidos. 16 0x78 17 0x44 18 0x61 19 0x74 20 0x61 Checksum
21 0x0D 0xFF menos los 8 bits de la suma desde el Offset 3 hasta este byte.
Direccin de origen de 64 bits (64-bit Source Address) Estos 8 bytes reportan la direccin del nodo desde donde fue realizada la trasmisin. Es la forma de decir que el mdulo RF est asociado a los datos que se acaban de recibir. Direccin de origen de 16 bits (16-bit Source Network Address) Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo Estos dos bytes indican la direccin de red corta del remitente. Conocer esta direccin e incluirla en una trama de trasmisin puede ahorrar tiempo y cierta sobrecarga puesto que no obliga a la red a buscar un nodo nuevamente. Opciones de recepcin (Receive Options) Este byte indica cierta informacin sobre cmo se recibe las trasmisiones; un valor de 0x01 indica si la trasmisin recibida se reconoci, 0x02 indica si la informacin recibida fue enviada como una trasmisin Broadcast, en cuyo caso ningn reconocimiento (ACK) se enviar. Un valor igual a 0x20 indica que la recepcin est cifrada y el valor 0x40 ensea que el paquete recibido proviene de un dispositivo final. Datos recibidos (Receive Data) Se trata de los datos en s recibidos, donde cada uno de los bytes que los conforman estn organizados en el mismo orden en que estaban cuando fueron empaquetados en la trasmisin del remitente.
6. Remote AT Command Request Otra trama que expone el verdadero potencial del modo API de los mdulos XBee corresponde a la trama Remote AT Command Request. Esta permite enviar comandos a travs de la red inalmbrica para configurar los parmetros de cada dispositivo RF remoto, algo que solo se puede lograr con este modo de operacin. Esto significa que cualquier comando AT que se puede enviar localmente tambin se puede enviar de forma inalmbrica para su ejecucin a un nodo remoto. Esto resulta especialmente til, por ejemplo, para el accionamiento a distancia, donde es posible que se desee cambiar el estado de alguna salida digital (de bajo a alto o viceversa) de los mdulos RF utilizados y desencadenar as una accin que contribuya al desarrollo de algn proceso.
Tabla 7. Trama API - Remote AT Command Request [4, p. 108]
Campos de trama Offset Ejemplo Descripcin P a q u e t e
A P I
Delimitador de inicio 0 0x7E Longitud MSB 1 0x00 Nmero de bytes entre la longitud de la trama de datos y el Checksum. Trama de datos LSB 2 0x10 Tipo de trama 3 0x17 ID de la trama 4 0x01 Identifica la trama de datos para el host que se correlaciona con un ACK posterior, si este campo est en 0 no se recibe respuesta. Direccin de destino 64-bit MSB 5 0x00 Configura la direccin de 64-bit de destino. Las siguientes direcciones son soportadas:
0x0000000000000000, direccin reservada para el coordinador.
0x000000000000FFFF, direccin Broadcast.
6 0x13 7 0xA2 8 0x00 9 0x40 10 0x40 11 0x11 LSB 12 0x22 Direccin de destino 16-bit MSB 13 0xFF Configura la direccin de 16-bit de destino si se conoce. Si no se conoce por defecto se configura con el valor 0xFFFE o si es un envo tipo Broadcast. LSB 14 0xFE Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo Opciones de comando remoto 15 0x02 Campo para las opciones de transmisin soportadas. Los valores admitidos son los siguientes: 0x01 Desactiva los reintentos y la reparacin de ruta 0x02 Aplica cambios 0x20 Habilita el cifrado APS (si el parmetro EE = 1) 0x40 Utiliza tiempo de espera de trasmisin extendido
Si aplicar cambios (0x02) no est habilitado, se debe enviar el comando AC para que los cambios tengan efecto.
Habilitar el cifrado APS supone que el origen y el destino han sido autenticados. Adems este disminuye el nmero mximo de bytes de payload por un factor de 4 al reportado por el comando NP. El establecimiento del bit de tiempo de espera prolongado hace que el stack configure el tiempo de espera de trasmisin extendido para la direccin de destino. Todos los bits no utilizados y no admitidos deben establecerse en 0. Comando AT 16 0x42 (B) Nombre del comando. 17 0x48 (H) Parmetro del comando 18 0x01 Si est presente, indica el valor del parmetro solicitado para establecer el registro dado. Si no hay caracteres presentes, el registro es consultado. Checksum
19 0xF5 0xFF menos los 8 bits de la suma desde el Offset 3 hasta este byte.
El formato de esta trama se indica en la Tabla 7. La trama Remote AT Command Request se identifica con el valor 0x17, seguido del byte que indica, como ya se sabe, el identificador de trama, luego los bytes que identifican la direccin de 64 bits y de 16 bits de destino. El siguiente byte es para establecer las opciones de los comandos remotos que se quieran aplicar, seguido por los dos bytes que establecen los dos caracteres que identifican al comando, uno o ms bytes para contener cualquier parmetro a enviar, y finalmente se tiene la suma de comprobacin de errores. Opciones de comando remoto (Remote Command Options) Este byte generalmente se establece en dos estados, el primero corresponde a establecer este byte en 0x02 para indicar que todos los cambios realizados de forma remota, a travs de los comandos AT, deben aplicarse de inmediato. El segundo estado corresponde en establecer este byte en 0, donde puede ocurrir que no se desea aplicar un comando hasta un momento determinado, es decir, retrasar la ejecucin de los comandos porque la aplicacin as lo requiere y luego emitir el comando AC Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo (Apply Changes) en el momento que se requiera para que todos los cambios realizados surtan efecto, conocindose a este procedimiento como una operacin atmica.
7. Remote Command Response Cada trama Remote AT Command Request que se enve a un nodo remoto, con un identificador de trama diferente de 0 recibir una respuesta para informar sobre si fue o no satisfactorio el envo y la aplicacin del comando remoto. Esa respuesta corresponde a la trama Remote Command Response identificada con el valor 0x97, seguido a este byte de solicitud se identifica los bytes que ensean las direcciones de 64 bits y 16 bits del nodo origen, luego se encuentra el comando AT que se envi, un byte que indica el estado de los comandos AT enviados, en seguida se encuentran los bytes que informan sobre los datos de los comandos (en caso de que la peticin haya sido consultar algn registro especifico) y finalmente se tiene la suma de comprobacin (Tabla 8).
Tabla 8. Trama API - Remote Command Response [4, p. 118]
Campos de trama Offset Ejemplo Descripcin P a q u e t e
A P I
Delimitador de inicio 0 0x7E Longitud MSB 1 0x00 Nmero de bytes entre la longitud de la trama de datos y el Checksum. Trama de datos LSB 2 0x13 Tipo de trama 3 0x97 ID de la trama 4 0x55 Este valor es el mismo que se pasa en la solicitud. Direccin de origen 64-bit MSB 5 0x00 Direccin del nodo origen.
6 0x13 7 0xA2 8 0x00 9 0x40 10 0x52 11 0x2B LSB 12 0xAA Direccin de origen 16-bit MSB 13 0x7D Direccin de red de 16 bits del nodo origen. Se establece en 0xFFFE si no se conoce. LSB 14 0x84 Comando AT 15 0x53 Nombre del comando. 16 0x4C Estado del comando 17 0x00 0 = OK 1 = ERROR 2 = Invalid Command 3 = Invalid Parameter 4 = Remote Command Transmission Failed Datos del comando 18 0x40 Datos del registro en formato binario. Si se ha programado el registro este campo no es retornado. 19 0x52 20 0x2B 21 0xAA Checksum
22 0xF0 0xFF menos los 8 bits de la suma desde el Offset 3 hasta este byte. Gerardo Andrs Lopez Orozco Juan David Valenzuela Ramos Grupo GDSPROC Universidad del Quindo Referencias
[1] J. C. Valverde Rebaza, El Estndar Inalmbrico ZigBee, Trujillo: Universidad Nacional de Trujillo, 2007. [2] J. J. Wrzburger, DESARROLLO Y VALIDACIN DE UN BOOTLOADER PARA APLICACIONES DE CARGA REMOTA EN ENTORNOS INALMBRICOS 802.15.4 Y ZIGBEE, Universidad Carlos III de Madrid. [3] A. Oyarce, Gua del Usuario XBee Series 1, Ingeniera MCI LTDA. [4] XBee ZB User Guide, XBee / XBee PRO - ZB RF Modules, Digi International Inc.