Zig Bee

Gerardo Andrs Lopez Orozco
Juan David Valenzuela Ramos

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.

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].


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.

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].

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].
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).
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
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.

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).

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
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
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
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
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
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:


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.

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,
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

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]

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.
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]

P
a
q
u
e
t
e

A
P
I

Trama de datos
LSB 2 0x05
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
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
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]

P
a
q
u
e
t
e

A
P
I

Trama de datos
LSB 2 0x16
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
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
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)
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]

P
a
q
u
e
t
e

A
P
I

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
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
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.
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]

P
a
q
u
e
t
e

A
P
I

Trama de datos
LSB 2 0x11
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
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)
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]

P
a
q
u
e
t
e

A
P
I

Trama de datos
LSB 2 0x10
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
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

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
(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]

P
a
q
u
e
t
e

A
P
I

Trama de datos
LSB 2 0x13
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
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.

Zig Bee

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Zig Bee

Transféré par

Droits d'auteur :

Formats disponibles

Gerardo Andrs Lopez Orozco

Juan David Valenzuela Ramos

Vous aimerez peut-être aussi