Zigbbe

!#%%&%()!#+, %##%
%+!( %!.,%+(%!)!/#0#+%1 +2+(
344444444444444444444444444444444444444444444444444444444444444
344444444444444444444444444444444444444444444444444444444444444
344444444444444444444444444444444444444444444444444444444444444
2(5 6&(!(+7#+%((( !+

!! ,%+38(%9%6)6
(&+2+(3 (+1!(:(6
4444444444444444

44444444444444444444444444444444444444444444444444444444444444
72(; #+%11.%/(,2+(!+1#+,2+%%1!( %!!2(1%

!&%#3
9!&444444444444444444
!<(1%<
!<#((+<
+3444444444444444
+3444444444444444
!<+#!
+3444444444444444

8(%9%6)6

(+1!(:(6

#%+!+&)!#(%#3

%&%()!#+, %##%
= 21(!&=>?>

%12(+7#+1(!6 %1 +!1#(#()1#1!
#+%5 %+1+! #+%11%(61&=<>3?3711((+!! %
21(!; 2+1!!(%1/(%#+11!(#+,2 12+(!+1
1%1+(1&=<>3?301 %1((##+%112#/#12+(!
1 (+3
9!&%(+
!# %&
Acrnimos
AES Advanced Encryption Standard
ANSI American National Standards Institute
ASCII American Standard Code for Information Interchange
ASH A Shell
API Application Programming Interface
APS Application Support Sub-layer
CCA Clear Channel Assessment
CGI Common Gateway Interface
CSMA-CA Carrier Sense Multiple Access-Collision Avoidance
DIN Deutsches Institut fr Normung
DSSS Direct Sequence Spread Spectrum
ED Energy Detection
FCS Frame Check Sequence
GPL General Public License
HTML HyperText Markup Language
IEEE Institute of Electrical and Electronics Engineers
i
ii
IP
Internet Protocol
ISM
Industrial, Scientic and Medical
ISO
International Organization for Standardization

Joint Test Action Group
JTAG
Link Quality Indication
LQI
LR-WPAN
Low Rate Wireless Personal Area Network
MAC
Medium Access Control
MIPS
Microprocessor without Interlocked Pipeline Stages
MCU
MicroController Unit
Open Systems Interconnection
OSI
SAP
Service Access Point
SCP
Secure Copy Protocol

SSH File Transfer Protocol
SFTP
Start Of Frame
SOF
SPI
Serial Peripheral Interface
SSH
Secure SHell
SSP
Secure Services Provider
PAN
Personal Area Network
PPDU
RISC
Reduced Instruction Set Computer
UART
UDP
Physical layer conversion Protocol Data Unit
Universal Asynchronous Receiver-Transmitter
User Datagram Protocol
iii
URL
Uniform Resource Locator
USB
Universal Serial Bus
W3C
World Wide Web Consortium
WAN
Wide Area Network
WHATWG
Web Hypertext Application Technology Working Group
WLAN
Wireless Local Area Network
WPAN
Wireless Personal Area Network
ZASA
ZDO
ZigBee Accelerator Sample Application

ZigBee Device Object
iv
ndice general
1. Introduccin
1.1.
1.2.
1.3.
1.4.
1.5.
Ubicacin tecnolgica . . . . . . . . . . . . . . . . . . . . . . .
Tecnologas inalmbricas de corto alcance: ZigBee o Bluetooth
El papel de ZigBee/802.15.4 en el futuro de las comunicaciones
Motivacin y objetivos del proyecto . . . . . . . . . . . . . . .
Estructura del documento . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2. ZigBee/802.15.4
1
2
5
6
6
9
2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Evolucin de las redes inalmbricas de rea personal . . . .
2.1.2. IEEE 802.15.4 y ZigBee . . . . . . . . . . . . . . . . . . . .
2.1.3. Certicacin de un dispositivo ZigBee . . . . . . . . . . . . .
2.1.4. Arquitectura de ZigBee . . . . . . . . . . . . . . . . . . . . .
2.1.5. Versiones de ZigBee . . . . . . . . . . . . . . . . . . . . . . .
2.1.6. Empaquetamiento, direccionamiento y acceso al canal . . . .
2.2. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Tipos de dispositivos . . . . . . . . . . . . . . . . . . . . . .
2.2.2. Topologa de red . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3. Capa fsica IEEE 802.15.4 . . . . . . . . . . . . . . . . . . .
2.2.3.1. Deteccin de energa recibida (ED) . . . . . . . . .
2.2.3.2. Indicador de calidad de enlace (LQI) . . . . . . . .
2.2.3.3. Evaluacin de canal libre (CCA) . . . . . . . . . .
2.2.3.4. Formato de PPDU . . . . . . . . . . . . . . . . . .
2.2.3.5. Caractersticas que reducen el consumo energtico
capa fsica . . . . . . . . . . . . . . . . . . . . . . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
en
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
la
. .
9
9
10
12
12
14
15
18
19
20
24
25
25
26
26
26
NDICE GENERAL
vi
2.2.4. Capa MAC IEEE 802.15.4 . . . . . . . . . . . . . . . . . . .

2.2.4.1. Estructura de supertrama (Modo balizado) . . . .
2.2.4.2. Modelo de transferencia de datos . . . . . . . . . .
2.2.4.3. Inicializacin y mantenimiento de una PAN . . . .
2.2.4.4. Unin a una red ZigBee . . . . . . . . . . . . . . .
2.2.4.5. Sincronizacin . . . . . . . . . . . . . . . . . . . .
2.2.4.6. Formato de la trama MAC . . . . . . . . . . . . .
capa MAC . . . . . . . . . . . . . . . . . . . . . .
2.3. ZigBee Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1. Capa de Red ZigBee . . . . . . . . . . . . . . . . . . . . . .
2.3.1.1. Reincorporacin a la red . . . . . . . . . . . . . . .
2.3.1.2. Enrutamiento ZigBee . . . . . . . . . . . . . . . . .
capa de red . . . . . . . . . . . . . . . . . . . . . .
2.3.2. Capa de Aplicacin ZigBee . . . . . . . . . . . . . . . . . . .
2.3.2.1. Perles de aplicacin, grupos y endpoints . . . . .
2.4. Seguridad en ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
. .
. .
. .
. .
. .
. .
en
. .
. .
. .
. .
. .
en
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
la
. .
. .
. .
. .
. .
la
. .
. .
. .
. .
3. Componentes y tecnologas utilizadas
3.1. Elementos hardware . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1. Equipo de desarrollo eZ430-RF2480 de Texas Instruments
3.1.2. Conversor TTL-232R-3V3 de FTDI . . . . . . . . . . . . .
3.1.3. Router ASUS WL-500G Premium . . . . . . . . . . . . . .
3.2. Elementos software . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.1. DD-WRT . . . . . . . . . . . . . . . . . . . . . .
3.2.1.2. Entorno de desarrollo Eclipse . . . . . . . . . . .
3.2.1.3. MSP430 IAR Embedded Workbench . . . . . . .
3.2.1.4. WinSCP . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.5. Putty . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.6. XVI32 . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2. Programacin . . . . . . . . . . . . . . . . . . . . . . . . .
27
28
29
30
31
31
32
32
33
33
33
34
36
36
37
38
41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
46
48
51
51
51
55
56
58
59
60
61
NDICE GENERAL
vii
3.2.2.1. C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2.2. CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2.3. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Desarrollo del sistema
69
4.1. Descripcin de objetivos . . . . . . . . . . . . . . . . .

4.1.1. Requisitos del sistema . . . . . . . . . . . . . .
4.2. Conectividad entre dispositivos . . . . . . . . . . . . .
4.3. Desarrollo de la aplicacin pasarela . . . . . . . . . . .
4.3.1. Funciones que componen la aplicacin pasarela .
4.3.2. Diagramas de ujo . . . . . . . . . . . . . . . .
4.4. Desarrollo de la interfaz . . . . . . . . . . . . . . . . .
4.4.1. Interaccin a traves de la interfaz web . . . . .
4.4.2. Interaccin a travs de comandos . . . . . . . .
4.5. Conguracin inicial automatizada . . . . . . . . . . .
4.6. Integracin en el sistema operativo DD-WRT . . . . .
4.6.1. Extraccin del rmware DD-WRT . . . . . . . .
4.6.2. Modicacin del rmware DD-WRT . . . . . .
4.6.3. Reconstruccin del rmware DD-WRT . . . . .
4.7. Aplicacin cargada en los sensores ZigBee/802.15.4 . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5. Fase de pruebas
5.1. Descripcin del entorno de pruebas

5.2. Procesos de vericacin . . . . . . .
5.2.1. Pruebas unitarias . . . . . .
5.2.2. Pruebas de integracin . . .
5.2.3. Pruebas de sistema . . . . .
61
63
67
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
69
69
71
74
74
80
82
83
84
85
86
87
88
89
90
93
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6. Conclusiones y lneas futuras de trabajo
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 93
. 94
. 94
. 100
. 101
103
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.2. Lneas futuras de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
A. Manual de usuario
107
A.1. Instalacin del sistema operativo en el router . . . . . . . . . . . . . . . . . 107
NDICE GENERAL
viii
A.1.1. Actualizacin desde otra versin de DD-WRT

A.1.2. Instalacin en otros casos . . . . . . . . . . .
A.2. Conguracin inicial . . . . . . . . . . . . . . . . . .
A.3. Manejo de la interfaz . . . . . . . . . . . . . . . . . .
Bibliografa
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
107
107
107
107
109
ndice de guras
1.1.
mbitos de aplicacin de distintas tecnologas [30] . . . . . . . . . . . . . .
2.1.
Logotipo ZigBee [21]
2.2.
Arquitectura de la pila ZigBee/802.15.4 [20]
. . . . . . . . . . . . . . . . .
13
2.3.
Tramas y empaquetamiento ZigBee [30] . . . . . . . . . . . . . . . . . . . .
15
2.4.
Topologa en estrella [8]
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.5.
Topologa en rbol o jerrquica [8] . . . . . . . . . . . . . . . . . . . . . . .
22
2.6.
Topologa en rbol agrupado [8] . . . . . . . . . . . . . . . . . . . . . . . .
22
2.7.
Topologa Mallada [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.8.
Canales IEEE 802.15.4 [20] . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.9.
Estructura supertrama [11] . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10. Descubrimiento de ruta [20]
3
12
. . . . . . . . . . . . . . . . . . . . . . . . . .
34
2.11. Encaminamiento jerquico [20] . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.1.
Contenido eZ430-RF2480 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.2.
Conexin CC2480-MSP430 . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.3.
Distribucin de protocolos CC2480-MSP430 [26] . . . . . . . . . . . . . . .
44
3.4.
Formato de trama intercambiada entre CC2480 y MSP430
. . . . . . . . .
44
3.5.
Campo de Comando
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.6.
FTDI TTL-232R-3V3 [18]
. . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.7.
Asus WL 500G Frontal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.8.
Asus WL 500G Trasera . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.9.
ASUS WL-500G Premium Interior
. . . . . . . . . . . . . . . . . . . . . .
50
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.11. Eclipse: Pantalla Principal . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.10. DD-WRT: Interfaz Web
ix
NDICE DE FIGURAS
x
3.12. MSP430 IAR Embedded Workbench: Estructura [24]
. . . . . . . . . . . .
58
3.13. Putty: Pantalla Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
3.14. XVI32: Ejemplo de cambio de formato
61
. . . . . . . . . . . . . . . . . . . .
3.15. Lenguages de Programacin: Distribucin de uso [29]
. . . . . . . . . . . .
63
4.1.
FTDI TTL-232R-3V3: Pin out [18]
. . . . . . . . . . . . . . . . . . . . . .
72
4.2.
Esquemtico de conexin entre MSP430 y CC2480 . . . . . . . . . . . . . .
73
4.3.
Pasarela: Diagrama de Flujo . . . . . . . . . . . . . . . . . . . . . . . . . .
80
4.4.
Lectura y envo: Diagrama de Flujo . . . . . . . . . . . . . . . . . . . . . .
81
ndice de tablas
1.1.
Comparativa de tecnologas inalmbricas [17] . . . . . . . . . . . . . . . . .
2.1.
ZigBee 2006 y PRO: Caractersticas destacadas [20] . . . . . . . . . . . . .
16
3.1.
Caractersticas Asus WL-500G Premium [2]
. . . . . . . . . . . . . . . . .
48
3.2.
DD-WRT: Utilidades principales [1] . . . . . . . . . . . . . . . . . . . . . .
53
4.1.
Interconexin entre conversor y sensor
72
xi
. . . . . . . . . . . . . . . . . . . .
xii
NDICE DE TABLAS
Captulo 1
Introduccin
1.1.
Ubicacin tecnolgica
Los consumidores descubren da a da que la interconexin de sistemas empotrados

permite un mayor y ms exible control sobre su entorno personal y profesional. Esto
tiene como resultado que se est produciendo una mayor demanda de estos dispositivos.
Las comunicaciones entre distintos tipos de dispositivos comunes en la vida diaria
como cmaras, telfonos mviles y un largo etctera son ya una realidad. Por todo ello,
el prximo requisito en estos dispositivos ser la posibilidad de comunicarse con objetos
que hasta ahora no posean esas capacidades de comunicacin, como electrodomsticos o
automviles. Tanto ZigBee, basado en el estndar 802.15.4 del IEEE (Institute of Electrical
and Electronics Engineers ), como Bluetooth, basado en el estndar 802.15.1 del IEEE,
dan respuesta a sto. Cada estndar IEEE dene una capa fsica y una pila de protocolos
distinta, operando ambos dentro de la banda ISM (Industrial, Scientic and Medical ).
A pesar de sus similitudes, ZigBee y Bluetooth no son intercambiables como soluciones
tecnolgicas y para decidir cual de los dos se ha de elegir, deben tenerse claras las ventajes
y desventajas de cada uno de ellos.
1
2
1.2.
CAPTULO 1.
INTRODUCCIN
Tecnologas inalmbricas de corto alcance: ZigBee

o Bluetooth
Bluetooth sobrepasa a ZigBee en velocidad de transferencia, posibilidades de interconexin, capacidad para evitar las interferencias en frecuencia y estandarizacin de perles
de aplicacin. Bluetooth es ideal para transferencia de archivos e intercambio de datos, y
ms adecuado para la comunicacin de ordenadores con perifricos.
En resumen, se puede determinar que si la aplicacin necesita de forma predominante
alguna de las siguientes caractersticas, se debe elegir un dispositivo Bluetooth:
Imprescindible si se necesita:
Intercambio de datos en tiempo real (audio o vdeo streaming )
Calidad de servicio garantizada
Opcin ms adecuada si se necesita:

Identicacin de compatibilidad entre dispositivos o disponibilidad de servicios
por parte de los sensores.

Interoperabilidad garantizada entre dispositivos similares de distintos fabrican-
tes.
Por otro lado, ZigBee aventaja a Bluetooth en cuanto a duracin de la batera de los
dispositivos y es ms robusto en caso de fallos de sensores en la red. ZigBee es la mejor
alternativa para aplicaciones que necesiten la trasferencia de pequeos paquetes sin una
periodicidad denida a travs de redes malladas.
En resumen, se puede determinar que si la aplicacin necesita de forma predominante
alguna de las siguientes caractersticas, se debe elegir un dispositivo ZigBee:
Imprescindible si se necesita:
1.2. TECNOLOGAS INALMBRICAS DE CORTO ALCANCE: ZIGBEE O BLUETOOTH
Capacidad para la interconexin simultnea de cientos de dispositivos.

Enrutamiento multisalto de mensajes hacia un dispositivo localizado ms all
del rango de trasmisin directa del dispositivo transmisor.

Opcin ms adecuada si se necesita:
Monitorizacin de mltiples dispositivos.
El mercado de ambos estndares est creciendo de forma signicativa en los ltimos

aos, presentando ambas opciones diferentes, pero en parte solapados, dominios de aplicacin. A pesar de haberse descritos solo estas dos opciones, se deben mencionar otras
tecnologas que tambin pueden coincidir parcialmente en cuanto a su dominio de aplicacin, tales como Ultra Wide Band, Wi-Fi1 o la red de telefona mvil. En la gura 1.1
podemos ver reprentado dicho solape entre las tecnologas anteriormente mencionadas.
Figura 1.1: mbitos de aplicacin de distintas tecnologas [30]

1 Aunque
se pensaba que el trmino viene de Wireless Fidelity como equivalente a Hi-Fi, High Fidelity,
que se usa en la grabacin de sonido, realmente la Wireless Ethernet Compatibility Alliance contrat a
una empresa de publicidad para que le diera un nombre a su estndar, de tal manera que fuera fcil de
identicar y recordar.
CAPTULO 1.
INTRODUCCIN
Se muestra a continuacin en la tabla 1.1 una comparacin entre las tecnologas anteriomente mencionadas:
Estndar
ZigBee
Bluetooth
Ultra Wide
3.0
Band
802.15.4
802.15.1
802.15.3a
802.11a/b/g
Banda de
868/915 MHz;
2.4 GHz
3.1-10.6 GHz
2.4 GHz;5 GHz
Frecuencias
2.4 GHz
Tasa de
250 Kb/s
1 - 24 Mb/s
110 Mb/s
54 Mb/s
Alcance
70m
100m
10m
100m
Nmero de
1/10; 16
79
(1-15)
14
Ancho de Banda
0.3/0.6 MHz; 2
1 MHz
500MHz-7.5 GHz
22MHz
de Canal
MHz
Tipo de
BPSK
GFSK
BPSK, QPSK
BPSK, QPSK,
Modulacin
(+ASK),
COFDM,
O-QPSK
CCK, M-QAM
Especificacin
Wi-Fi
IEEE
Transferencia
Mxima
canales
Ensanchamiento
DSSS
FHSS
DS-UWB,
DSS, CCK, OFDM
MB-OFDM
Mecanismo de
Seleccin
Salto de
Salto de
Seleccin Dinmica de
Coexistencia
Dinmica de
Frecuencia
Frecuencia
Frecuencia
Frecuencia
Adaptativo
Adaptativo
Control de Potencia
Transmitida (802.11h)
Nmero Mximo
de sensores
> 65000
(para una
piconet )
Tabla 1.1: Comparativa de tecnologas inalmbricas [17]
1.3. EL PAPEL DE ZIGBEE/802.15.4 EN EL FUTURO DE LAS COMUNICACIONES
1.3.
El papel de ZigBee/802.15.4 en el futuro de las

comunicaciones
En los prximos aos es muy probable que ZigBee vea incrementado su uso ya que
sus caractersticas se adaptan a los requerimientos necesarios para un amplio rango de
soluciones, destacndose las siguientes:
Automatizacin de tareas en el hogar

Aplicaciones para el ahorro de energa
Aplicaciones destinadas a las telecomunicaciones
Si se toma como referencia el tamao de la pila de protocolos, el de ZigBee, en torno

a 32KB, es aproximadamente una tercera parte del tamao de la pila de otros protocolos
de comunicaciones inalmbricos.
Adems, para dispositivos nales, este tamao puede verse reducido hasta los 4KB.
Esto redunda en un menor coste, tanto por la memoria necesaria para su almacenamiento
como por su mayor simplicidad de funcionamiento y, por lo tanto, el ahorro en otros
componentes hardware.
Igualmente, la sencillez antes mencionada posibilita un rpido desarrollo de aplicaciones y, por lo tanto, una mayor capacidad de adaptacin al rpido cambio al que se ven
sometidos los productos tecnolgicos.
Por todo lo anterior, junto a otras razones que se detallarn en sucesivos captulos,
ZigBee/802.15.4 ha sido adoptado ya por multitud de empresas y se prev que en los
prximos aos pueda aprovecharse todo su potencial.
6
1.4.
CAPTULO 1.
INTRODUCCIN
Motivacin y ob jetivos del proyecto
En el contexto de una sociedad en continuo movimiento y con capacidad de conexin

a internet all donde se encuentre, la posibilidad de poder acceder a informacin o noticacin de eventos concretos en ambientes personales (como puede ser el residencial)
se hace cada vez ms til, necesario e incluso demandado por los consumidores. Por ello,
considerando el tipo de informacin a noticar como de periodicidad no determinada y con
amplios intervalos de tiempo entre comunicaciones sucesivas, la eleccin de ZigBee para la
red de control se convierte en una eleccin acertada. Una vez decidido esto, y teniendo en
cuenta la exibilidad, expansin y cobertura de las redes basadas en IP (Internet Protocol )
en todo el mundo, la combinacin de redes de sensores ZigBee con la red IP se vislumbra
como una solucin de un gran atractivo con unas posibilidades interesantes.
Por ello, el objetivo de este proyecto es la creacin de una pasarela entre una red
ZigBee/802.15.4 e IP, usando un router comercial a modo de ejemplo de aplicacin. Se
elige como informacin a transmitir la temperatura en el lugar de colocacin del sensor
ZigBee. La nalidad ser conseguir que dicha informacin pueda llegar hasta una o varias
direcciones IP, congurables mediante una interfaz web.
1.5.
Estructura del documento
El documento que a continuacin se presenta est dividido en siete captulos, quedando

organizado como a continuacin se detalla:
Captulo 1: Introduccin
Breve presentacin de ZigBee/802.15.4 y comparativa con otras posibilidades para
las comunicaciones inalmbricas. Justicacin de la utilidad de este Proyecto Fin de
Carrera
Captulo 2: ZigBee/802.15.4
1.5.
ESTRUCTURA DEL DOCUMENTO
Descripcin detallada de ZigBee/802.15.4 por ser considerado el estndar ms novedoso y quizs desconocido de los que se usan para este Proyecto Fin de Carrera.
Captulo 3: Componentes y tecnologas utilizadas

Recopilacin de las herramientas hardware y software que se hicieron imprescindibles
para llevar a cabo este desarrollo.
Captulo 4: Desarrollo del sistema

Detalle de las decisiones adoptadas y desarrolladas as como descripcin de todos los
elementos que la integran.
Captulo 5: Fase de pruebas

Descripcin del proceso a travs del cual se ha conseguido asegurar el correcto funcionamiento de la solucin desarrollada.
Captulo 6: Conclusiones y lneas futuras de traba jo

Presentacin de las conclusiones obtenidas tras la elaboracin de este Proyecto Fin
de Carrera, as de como posibles mejoras o lneas distintas de trabajo que pueden
seguirse tomando este desarrollo como punto de partida.
Captulo 7: Manual de usuario

Breve gua que detalla los pasos a seguir para lograr el correcto funcionamiento de
la pasarela, partiendo de la instalacin en el
router
y terminando en la puesta en
marcha y posterior recepcin de paquetes de datos en un dispositivo remoto con

acceso a internet.
CAPTULO 1.
INTRODUCCIN
Captulo 2
ZigBee/802.15.4
Como primer paso, y antes de entrar en la materia principal sobre la que versa este
Proyecto Fin de Carrera, se har un breve recorrido a travs del conjunto de soluciones
estandarizadas ZigBee/802.15.4 para poder entender tanto sus fundamentos bsicos, como
las causas que lo han hecho tan prometedor en los ltimos aos con la llegada de la
domtica.
2.1.
2.1.1.
Introduccin
Evolucin de las redes inalmbricas de rea personal
Las redes celulares pueden ser consideradas la extensin lgica y natural de las redes
telefnicas por cable. Conforme fueron aumentando tanto las necesidades de movilidad
como el coste de instalacin de las redes cableadas, la idea de lograr conexiones personales
independientemente de la localizacin del usuario tambin progres.
Durante la dcada de los 80, se pas de la bsqueda de clulas capaces de proporcionar

reas de cobertura de hasta decenas de kilmetros, al inters por clulas con menor rea de
cobertura a cambio de una mayor capacidad para grandes densidades de usuarios. Es en
9
10
CAPTULO 2.
ZIGBEE/802.15.4
este ltimo punto donde se enmarca el grupo de trabajo IEEE 802.11, en la investigacin
y estandarizacin de redes WLAN (Wireless Local Area Network ).
Sin embargo, mientras IEEE 802.11 se centra en proporcionar altas tasas de datos a
distancias tpicas de decenas de metros, las WPAN (Wireless Personal Area Network )
tienen como principal objetivo dar servicio en el entorno prximo a una persona u objeto,
buscando ante todo lograr dispositivos de bajo coste, bajo consumo y pequeo tamao.
El grupo de trabajo IEEE 802.15 surge como respuesta a estos requisitos. Este grupo
ha denido tres clases de WPAN diferenciadas por sus tasas de transferencias de datos,
consumo energtico y calidad de servicio. Las WPAN de alta tasa de transferencia de datos,
IEEE 802.15.3, son adecuadas para aplicaciones multimedia que requieren de una calidad
de servicio alta. Las WPAN de tasa de transferencia media, IEEE 802.15.1/Bluetooth,
estn destinadas al manejo de un amplio rango de aplicaciones, como las destinadas a
telfonos mviles, y permiten una calidad de servicio adecuada para comunicaciones por
voz. Por ltimo, se encuentran las WPAN de baja tasa de transferencia de datos, IEEE
802.15.4/LR-WPAN (Low Rate WPAN), indicadas para satisfacer las necesidades de un
amplio rango de aplicaciones en el mbito industrial, mdico o residencial de bajo consumo
de energa y bajo coste.
2.1.2.
IEEE 802.15.4 y ZigBee
ZigBee es un protocolo de interconexin inalmbrico de baja tasa de transferencia

de datos, bajo coste y reducido consumo energtico orientado hacia la automatizacin y
control remoto de aplicaciones. No se trata de una tecnologa, sino de un conjunto estandarizado de soluciones que pueden ser implementadas por cualquier fabricante. ZigBee
est promovido por la ZigBee Alliance, asociacin creada en 1998 y que, segn un informe
reciente de ON World [12], ha sido adoptada por ms de 350 fabricantes globales, que
trabajan de forma conjunta para lograr un estndar global y abierto, contando ingresos
anuales que sobrepasan el billon de dlares estadounidenses.
La especicacin 1.0 de ZigBee se aprob el 14 de Diciembre de 2004, estando disponible
para miembros de ZigBee Alliance. Dicha especicacin se divide en distintos niveles,
2.1.
INTRODUCCIN
11
accesibles segn la categoria adoptada por el suscriptor.

Mientras, y en paralelo, el grupo IEEE 802.15.4 haba continuado con su trabajo centrado en las WPAN de baja tasa de transferencia de datos el cual comenz poco tiempo
despus de la formacin de ZigBee Alliance. Ms tarde, ZigBee Alliance e IEEE decidieron unicar esfuerzos y criterios, optndose por ZigBee como nombre comercial para la
solucin tecnolgica.
Como ya se apunt anteriormente, ZigBee est indicado como solucin de bajo coste y
bajo consumo de energa para la interconexin inalmbrica de dispositivos que necesiten
un largo ciclo de duracin de la batera, pudiendo ir de varios meses a varios aos. Adems,
ZigBee puede ser implementado en redes malladas de un tamao mayor que las permitidas
por Bluetooth. Los dispositivos ZigBee pueden transmitir en rangos de entre 10 y 70
metros, dependiendo de las condiciones radio y del consumo deseado para una determinada
aplicacin, y opera en las bandas ISM1 , que son bandas reservadas internacionalmente para
su uso en campos relacionados con la industria, la ciencia y la medicina, y cuyo acceso es
libre sin necesidad de solicitar licencia. El rango de transferencia de datos va de los 250
kbps a los 20 kbps, dependiendo de la banda ISM usada.
Desde su unin, IEEE y ZigBee Alliance han trabajado en colaboracin para especicar
la pila de protocolos. IEEE 802.15.4 se centr en la especicacin de las dos capas inferiores
del protocolo, las capas fsica y MAC (Medium Access Contro l), mientras que ZigBee
Alliance tuvo como objetivo la denicin de las capas superiores, desde la capa de red
hasta la capa de aplicacin, ambas inclusive. Esta arquitectura puede verse en la gura
2.2. Adems, ZigBee Alliance se ocup de denir una serie de aplicaciones de control
destinadas al mbito residencial y de la construccin, as como de establecer los requisitos
para determinar la interoperabilidad de los dispositivos, ocuparse de la parte comercial y
determinar las directrices principales en la evolucin de ZigBee.
1 2.4
Ghz en todo el mundo, 915 MHz en Amrica y 868 MHz en Europa
12
CAPTULO 2.
ZIGBEE/802.15.4
2.1.3. Certicacin de un dispositivo ZigBee

Para que un producto pueda llevar el logotipo de ZigBee Alliance (gura 2.1) debe
pasar exitosamente el Programa de Certicacin ZigBee. Esto asegura que dicho producto
cumple con el estndar descrito en la especicacin ZigBee. Se distinguen dos tipos de
certicaciones:
ZigBee Compliant Platform : se aplica a mdulos destinados a ser usados como bloques para la construccin de productos nales.
ZigBee Certied Products : aplicado a productos nales construidos en base a bloques
con certicacin ZigBee Compliant Platform.
Figura 2.1: Logotipo ZigBee [21]

Aquellos productos que usan perles de aplicacin pblicos son probados para asegurar
la interoperabilidad con otros productos nales ZigBee.
Los productos que usan perles de aplicacin especcos de un fabricante, y que funcionaran como 'sistemas cerrados', son probados para asegurar que pueden coexistir con otros
sistemas ZigBee, esto es, que no intereren en el buen funcionamiento de otros productos
ZigBee certicados.
2.1.4. Arquitectura de ZigBee

Se presentan a continuacin los conceptos esenciales acerca de la arquitectura de la
pila ZigBee, la cual se muestra en la gura 2.2.
Ninguna de las capas de la pila conoce nada de la capa superior. La capa superior
puede ser considerada la 'maestra' que ordena a la capa inferior 'esclava' que realice el
2.1.
INTRODUCCIN
13
trabajo. Cada capa aade una mayor complejidad basada en el soporte que prestan las
capas inferiores.
Figura 2.2: Arquitectura de la pila ZigBee/802.15.4 [20]
La arquitectura ZigBee/802.15.4 no cumple de manera exacta con el modelo OSI (Open

Systems Interconnection ) de siete capas, pero coincide en algunos de sus elementos tales
como las capas fsica, MAC y de red. Las funciones de las capas 4-72 estn incluidas en
las capas APS (Application Support Sub-layer ) y ZDO (ZigBee Device Object ) del modelo
ZigBee. Entre cada capa se denen SAP (Service Access Point ). Los SAP proveen los API
(Application Programming Interface ), que permite aislar el trabajo que lleva a cabo una
capa respecto a las capas superior e inferior de sta. ZigBee incluye dos accesos SAP por
capa, uno de ellos para datos y otro para gestin.
Las dos capas inferiores, fsica y MAC, estn denidas por la especicacin IEEE
802.15.4. La capa fsica simplemente traduce los bits al interfaz aire o viceversa. La capa
MAC provee el concepto de red, incluyendo el identicador de PAN (Personal Area Network ), el descubrimiento y unin a otras redes, y comandos para unirse o formar una red.
2 Transporte,
Sesin Presentacin y Aplicacin
14
CAPTULO 2.
ZIGBEE/802.15.4
La capa MAC no soporta encaminamiento multi salto ni mallado.

Las capas de red y aplicacin quedarn denidas por la ZigBee Alliance. La capa de red
es responsable de la administracin de redes malladas, lo cual incluye el envo de paquetes
a travs de la red, la determinacin de rutas para envos unicast y, de manera general,
el control del envo correcto de los paquetes entre sensores. Esta capa incluye tambin
una serie de comandos para la administracin de la seguridad en la red. Las redes ZigBee
proveen seguridad en la capa de red, tal y como se explicar mas adelante.
La capa de aplicacin acta como ltro para las aplicaciones ejecutadas sobre ella,
simplicando sus interacciones con otros mdulos como Applicastion Prole. Se ocupa
tambin de ltrar mensajes duplicados. Dentro de esta capa se incluye el mdulo ZDO,
responsable de la gestin de medio radio, del descubrimiento de otros sensores y servicios
al alcance y del estado del sensor en la red.
Es importante resaltar que no se contempla en la arquitectura ninguna descripcin de
interacciones entre dispositivos que no se lleven a cabo a travs del interfaz aire. ZigBee
solo dene el protocolo de red y el comportamiento a travs de dicho interfaz. Este hecho
permite que todos los mensajes transmitidos a travs del interfaz aire por un sensor ZigBee
puedan ser interpretados correctamente por cualquier otro sensor ZigBee, consiguindose
as que los fabricantes innoven a la vez que se mantiene la compatibilidad entre ellos.
Todas estas capas sern descritas de manera ms detallada en siguientes secciones.
2.1.5.
Versiones de ZigBee
Hasta el da de hoy existen tres versiones de la pila ZigBee/802.15.4: la primera se

denomina ZigBee 2004, la siguiente apareci en Junio de 2006 y se denomin ZigBee
2006 y la ltima es la versin ZigBee PRO o 2007. El nivel de red de ZigBee 2007 no es
compatible con el de ZigBee 2004-2006, aunque un sensor de funcionalidad reducida puede
unirse a una red 2007 y viceversa. No pueden combinarse dispositivos enrutadores de las
versiones antiguas con un dispositivo coordinador 2007.
2.1.
INTRODUCCIN
15
Se muestra en la tabla 2.1 un resumen con las caractersticas ms destacadas incluidas

en las versiones 2006 y PRO.
2.1.6.
Empaquetamiento, direccionamiento y acceso al canal
El empaquetamiento en ZigBee/802.15.4 se realiza a travs cuatro tipos de tramas

bsicas: trama de datos, trama ACK o de acuse de recibo, trama MAC y trama baliza.
Podemos ver los campos de estas tramas en la gura 2.3.
Figura 2.3: Tramas y empaquetamiento ZigBee [30]

La trama de datos presenta una zona de carga de hasta 104 bytes y est numerada
para asegurar que todos llegan a su destino. Un campo nos asegura que la trama se
ha recibido sin errores. Con esta estructura se aumenta la abilidad en condiciones
complicadas de transmisin.
La estructura de las tramas ACK permite la realimentacin desde el receptor al
emisor, conrmndose que fue recibida sin errores.
La trama MAC se utiliza para el control remoto y la conguracin de los distintos
dispositivos.
16
CAPTULO 2.
El coordinador selecciona el mejor canal disponible para

evitar interferencias al inicio
Permite el cambio de canal durante la operacin para evitar
interferencias
Asignacin distribuida de direcciones
Asignacin estocstica de direcciones
Los dispositivos pueden ser asignados a grupos para
direccionarlos de forma comn
Soporte para dispositivos con funcin de agregador
Encriptado AES de 128 bits con cdigo de integridad de
mensaje de 32 bits
Contador de tramas para asegurar la no duplicidad
Seguridad en la capa de red por defecto y soportada en capas
superiores
Rotacin de la clave de red
Centro de seguridad soportado en el coordinador
Modo de alta seguridad
Centro de seguridad soportado en cualquier dispositivo de la
red
Tamao del mensaje de hasta 100 bytes dependiendo del
servicio empleado
Soporte para mensajes mayores de 100 bytes, teniendo como
lmite los buers de envo y recepcin
Algoritmo de enrutamiento tolerante a fallos con capacidad de
respuesta a cambios en la red y en el interfaz radio
Cada dispositivo mantiene informacin de sus vecinos,
mejorando la abilidad y robustez
ZIGBEE/802.15.4
2006
PRO
NO
SI
SI
NO
SI
NO
SI
SI
NO
SI
SI
SI
SI
SI
SI
SI
SI
SI
NO
NO
SI
SI
SI
SI
SI
SI
NO
SI
SI
NO
NO
SI
SI
Tabla 2.1: ZigBee 2006 y PRO: Caractersticas destacadas [20]
SI
2.1.
INTRODUCCIN
17
La trama baliza se ocupa de activar a los dispositivos, que escanean el canal y

luego vuelven a pasar a estado inactivo si no reciben nada ms. Estas tramas son
importantes para permitir el ahorro de energa de los dispositivos, que esperan el
momento adecuado para mantener a los dispositivos sincronizados sin necesidad de
estar permanentemente en funcionamiento, permitiendo ahorrar energa.
En cuanto al mecanismo de direccionamiento, tanto la capa MAC como la capa de
aplicacin forman parte de l. Un dispositivo ZigBee est formado por un transceptor
radio compatible con el estndar 802.15.4, en el que se implementan dos mecanismos de
acceso al canal y una o ms descripciones de dispositivos. El transceptor es la base del
direccionamiento mientras que las aplicaciones asociadas a un dispositivo se identican por
medio de un endpoint numerado entre 1 y 240. Los dispositivos se direccionan empleando
64 bits o un direccionamiento corto de 16 bits que puede asignarse usando dos posibles
mecanismos:
Mecanismo distribuido: se basa en la generacin de subgrupos de direcciones. El
coordinador asigna un subgrupo de direcciones a cada uno de sus hijos con capacidad
de enrutador. Este proceso de asignacin de subgrupos se repite de nuevo en los
dispositivos enrutadores de manera iterativa hasta que se llega a los dispositivos
nales. Para calcular el tamao de estos subgrupos de direcciones se tienen en cuenta
ciertos parmetros de la red denidos por el coordinador: mximo nmero de hijos
que un padre puede tener, mxima profundidad de la red (es decir, nmero mximo
de saltos haca arriba o abajo) y mximo nmero de dispositivos enrutadores que un
padre puede tener como hijo.
Mecanismo estocstico (solo disponible para ZigBee PRO): basado en la asignacin
aleatoria.
Los dos mecanismos de acceso al canal que se implementan en ZigBee corresponden
a redes con funcionamiento balizado y sin funcionamiento balizado. Para una red sin funcionamiento balizado, el mecanismo CSMA-CA (Carrier Sense Multiple Access-Collision
Avoidance ) ranurado enva, de manera opcional, tramas ACK para los paquetes recibidos
correctamente. En este mecanismo, cada dispositivo es autnomo, pudiendo iniciar una
18
CAPTULO 2.
ZIGBEE/802.15.4
conversacin, en la que otros pueden interferir. As, el canal puede estar ocupado o el dispositivo destino puede no recibir la peticin. Este sistema se usa en sistemas en los que los
dispositivos pasan la mayor parte del tiempo inactivos. Para que los dems elementos de
la red sigan tenindolos en cuenta, cada cierto tiempo se activan para anunciar que siguen
en la red. Se debe destacar que los dispositivos que actuan como coordinadores no pueden
pasar a estado inactivo en ningn momento, debiendo permanecer en modo escucha en
todo momento.
Por otro lado, en una red con funcionamiento balizado se usa una estructura de supertrama que se estudiar con detalle en 2.2.4.1.
2.2.
IEEE 802.15.4
A continuacin se describir de forma detallada la parte de ZigBee responsabilidad del

IEEE, sin embargo, se deben tener claras una serie de ideas:
IEEE 802.15.4 es:
Un estndar WPAN optimizado para aplicaciones con una baja tasa de trans-
ferencia de datos (entre 0.01 y 250 kbit/s) y requisitos mnimos o inexistentes

de calidad de servicio.
El tipo de WPAN de menor coste y menor consumo.
Un estndar desarrollado por el IEEE que delega en ZigBee
Alliance
la parte
referente a la mercadotecnia y la conformidad de los dispositivos.

La parte de ZigBee perteneciente a las capas fsica y MAC.
En cuanto a los requisitos hardware de la MCU (MicroController

los siguientes:
8 bits
Unit ), se denen
2.2.
IEEE 802.15.4
19
4 MHz
32 kB ROM
8 kB RAM
2.2.1.
Tipos de dispositivos
Las redes ZigBee incluyen los siguientes tipos de dispositivos segn el papel que desempeen en la red:
Coordinador ZigBee: es el dispositivo ms completo, solo puede haber uno en cada
red y se encarga de la inicializacin y control de la misma. Puede actuar tambin
como centro de seguridad, siendo el encargado de guardar y distribuir las claves de
cifrado.
Enrutador ZigBee: este dispositivo extiende el rea de cobertura, encamina dinmicamente alrededor de obstculos y proporciona rutas alternativas en caso de congestin
o de fallos de dispositivos. Pueden conectarse tanto al coordinador como a otros enrutadores y soporta tambin dispositivos hijos. Cabe destacar que ofrece un nivel de
aplicacin para la ejecucin de cdigo de usuario.
Dispositivo nal ZigBee: debe estar conectado a un coordinador ZigBee o a un enrutador ZigBee y no admite hijos. Posee la funcionalidad necesaria para comunicarse
con su sensor padre pero no puede transmitir informacin destinada a otros dispositivos ni llevar a cabo ninguna operacin de enrutamiento. De esta forma, puede
permanecer inactivo la mayor parte del tiempo, aumentando la vida de sus bateras. Adems, y no menos importante, el hecho de no tener que almacenar tablas de
encaminamiento hace que su necesidad de memoria disminuya considerablemente,
hacindolo signicativamente ms barato.
Por otro lado, atendiendo a la capacidad para actuar segn qu tipo de los dispositivos
vistos anteriormente, podemos realizar una segunda clasicacin:
20
CAPTULO 2.
ZIGBEE/802.15.4
Dispositivo de funcionalidad completa (FFD: Full Functionality Device ): es capaz de

recibir mensajes en formato del estndar 802.15.4 y gracias a su memoria adicional
puede actuar como coordinador, enrutador o dispositivo nal ZigBee. Cualquier red
ZigBee debe incluir, al menos, un dispositivo ZigBee FFD.
Dispositivo de funcionalidad reducida (RFD: Reduced Functionality Device ): presenta capacidad y funcionalidad limitadas (especicadas en el estndar) con el propsito
de conseguir bajo coste y simplicidad. Son los sensores/actuadores de la red y, por
lo tanto, solo pueden actuar como dispositivos nales ZigBee.
2.2.2.
Topologa de red
En las redes ZigBee pueden encontrarse tres tipos de topologas que se describen a
continuacin:
Estrella: se compone de un dispositivo coordinador y varios dispositivos nales, tal

y como se muestra en gura 2.4. En esta topologa, el dispositivo nal se comunica
solo con el coordinador. Cualquier intercambio de paquetes entre dispositivos nales
ha de pasar por el coordinador, siendo sta su principal desventaja ya que la red
depende del buen funcionamiento del coordinador y es fcil la formacin de cuellos
de botella. Adems no presenta rutas alternativas desde la fuente al destino. Como
ventajas aporta su simplicidad y el hecho de alcanzar cualquier destino con solo dos
saltos.
Posibles aplicaciones beneciarias de esta topologa son la automatizacin residencial, perifricos de ordenadores y juguetes.
2.2.
21
IEEE 802.15.4
Figura 2.4: Topologa en estrella [8]
rbol o jerrquica: en esta topologa la red esta compuesta por un sensor central que
acta como coordinador y varios enrutadores y/o dispositivos nales, tal y como se
muestra en la gura 2.5. La misin de los enrutadores es extender la cobertura de la
red (aunque tambin tienen capacidad para ejecutar aplicaciones). Los dispositivos
nales conectados a los enrutadores o al coordinador son llamados sensores hijos.
Solo los enrutadores y los coordinadores admiten sensores hijo. Cada dispositivo nal
solo puede comunicarse con su padre (enrutador o coordinador). El coordinador y
los enrutadores pueden tener hijos y, adems, son los nicos dispositivos que pueden
ser padres. Un dispositivo nal no puede tener hijos por lo que, consecuentemente,
no puede actuar como padre.
22
CAPTULO 2.
ZIGBEE/802.15.4
Figura 2.5: Topologa en rbol o jerrquica [8]

rbol agrupado: este es un caso especial de topologa en rbol en la que un padre
con sus hijos es denominado grupo, tal y como se muestra en la gura 2.6. Cada
grupo presenta una identicacin nica en la red. Esta topologa forma parte de la
especicacin del IEEE 802.15.4 pero no se incluye dentro de ZigBee por lo que no
se entrar en ms detalles.
Figura 2.6: Topologa en rbol agrupado [8]
2.2.
23
IEEE 802.15.4
Mallada: consiste en una malla de enrutadores y dispositivos nales interconectados.

Cada enrutador est tipicamente conectado a travs de, al menos, dos caminos de
salida y puede transmitir mensajes a sus vecinos. Tal y como se muestra en la
gura 2.7, una red mallada esta compuesta por un nico coordinador y mltiples
enrutadores y dispositivos nales.
En este escenario, aadir o eliminar dispositivos es sencillo, pudinsose evitar
zonas 'muertas', o con seal recibida dbil sin ms que aadir enrutadores a la red.
Como inconvenientes presenta la necesidad de una cabecera de mayor tamao y que
el protocolo de enrutamiento es ms complejo que en los otros casos, haciendo los
requisitos de memoria y proceso ms elevados.
Este concepto de red, conocido tambin como red nodal, es la aportacin de
ZigBee que mayor inters est despertando entre las empresas desarrolladoras de
productos ya que su aplicacin har viable muchas soluciones de domtica va radio
en viviendas construidas, all donde las tecnologas radio de anteriores generaciones
estaban limitadas en cuanto a la cobertura o alcance entre dispositivos.
Figura 2.7: Topologa Mallada [8]
24
CAPTULO 2.
ZIGBEE/802.15.4
Sea cual sea la topologa elegida, despus de que un dispositivo FFD se activa por
primera vez, puede establecer su propia red y convertirse en el coordinador. Cada vez que
un dispositivo FFD establece una nueva red, elige un identicador PAN que no est siendo
actualmente utilizado por ninguna otra red ZigBee dentro del alcance de cobertura del
coordinador. Esto permite a cada red trabajar de forma independiente.
2.2.3.
Capa fsica IEEE 802.15.4
La capa fsica realiza las funciones de activacin/desactivacin del transceptor radio,

deteccin de energa, indicador de calidad del enlace, seleccin de canal y evaluacin de
canal libre, adems de ocuparse de la recepcin y transmisin de paquetes a travs del
interfaz aire.
El estndar proporciona dos opciones determinadas por la banda de frecuencia elegida.
Ambas estn basadas en la tcnica DSSS (Direct Sequence Spread Spectrum ). La tasa de
transferencia de datos es de 250 kbps en la banda de 2.4 GHz, 40 kbps en la de 915 MHz
y 20 kbps en la de 868 MHz. La tasa de 250 kbps se consigue usando un orden mayor
de modulacin. Por otro lado, frecuencias menores proporcionan un mayor alcance en la
cobertura ya que las prdidas por propagacin son menores.
Entre 868 y 868.6 MHz hay un nico canal, 10 canales entre 902 y 928 MHz y 16
canales entre 2.4 y 2.4835 GHz, tal y como se muestra en la gura 2.8. El hecho de tener
canales en diferentes bandas permite el realojo dentro del espectro disponible. El estndar
permite tambin la seleccin dinmica de canal.
En cuanto a la parte hardware, la sensibilidad mnima del receptor ha de ser de -85
dBm para 2.4 GHz3 y de -95 dBm para 868/915 MHz. Por otro lado, la mxima potencia
de transmisin ha de estar regulada segn la regulacin local. Un dispositivo certicado
como ZigBee debe indicar su potencia nominal de transmisin indicada en el parmetro
de la capa fsica phyTransmitPower.
3 Aunque
los dispositivos comerciales alcanzan a menudo sensibilidades muy inferiores, siendo -100 dBm
un valor habitual.
2.2.
25
IEEE 802.15.4
Figura 2.8: Canales IEEE 802.15.4 [20]

2.2.3.1.
Deteccin de energa recibida (ED)
La medida de la energa recibida es usada por la capa de red en el algoritmo de seleccin

de canal. Se trata de una estimacin de la potencia recibida en el ancho de banda de un
canal IEEE 802.15.4 y no decodica la seal recibida. El tiempo requerido para llevar a
cabo la estimacin debe ser igual al de 8 periodos de smbolo (128 ms en la banda de 2.4
GHz).
El resultado de la funcin ED (Energy Detection ) es noticado como un entero de
8 bits. El valor mnimo indica potencia recibida menor de 10 dB sobre la sensibilidad
especicada para el receptor. La amplitud de los posibles valores indicados debe ser de, al
menos, 40 dB.
2.2.3.2.
Indicador de calidad de enlace (LQI)
LQI (Link Quality Indication ) es una medida de la calidad y/o fuerza de la trama
recibida. Puede ser implementado por medio de un receptor con capacidad ED, una estimacin de la relacin seal a ruido o una combinacin de ambos mtodos. El resultado de
LQI ser usado por la capa de red o por la de aplicacin.
LQI se indica mediante un entero de 8 bits, asocindose el mayor y el menor valor
26
CAPTULO 2.
ZIGBEE/802.15.4
posible con la mayor o menor calidad detectable por el receptor, distribuyndose los valores
de manera uniforme entre estos lmites.
2.2.3.3.
Evaluacin de canal libre (CCA)
La operacin de CCA (Clear

de los siguientes mtodos:
Channel Assessment ) se lleva a cabo de acuerdo a uno
Energa por encima del umbral: CCA informar de canal ocupado si detecta cualquier
energa sobre el umbral de ED.
Deteccin de portadora: CCA informar de canal ocupado solo cuando detecte una
seal con la modulacin y ensanchamiento de las caractersticas de IEEE 802.15.4.
No tiene en cuenta si la seal esta por encima o por debajo del umbral ED.
Deteccin de portadora con energa por encima del umbral: se trata de una combinacin de los dos mtodos anteriores.
2.2.3.4.
Formato de PPDU
La estructura de la PPDU (Physical layer conversion Protocol

en la gura 2.3. Esta fomada por los siguientes componentes:
Data Unit ) se muestra
Cabecera de sincronizacin: permite al dispositivo receptor sincronizarse.

PHY CAB: contiene informacin acerca de la longitud de la trama.
Zona de carga variable (SDU fsica) que incluir la trama MAC.
2.2.3.5.
Caractersticas que reducen el consumo energtico en la capa fsica
Se presentan a continuacin las caractersticas que posibilitan el bajo consumo energtico en la capa fsica:
2.2.
IEEE 802.15.4
27
Sealizacin ortogonal multinivel
La baja potencia media usada es lograda gracias a tiempos de funcionamiento

reducidos, acompaados de bajos picos de corriente. En la capa fsica esto fomenta el
uso de una tasa de transferencia de datos elevada pero con una baja tasa de smbolos
ya que los picos de corriente suelen ir en consonancia con la tasa de smbolos usada
ms que con la tasa de datos. Esto implica el uso de sealizacin multinivel.
Sin embargo, la sealizacin multinivel produce una prdida de sensibilidad que

lleva aparejada un aumento del consumo. La solucin es el uso de la sealizacin
ortogonal, intercambiando ancho de banda para mejorar la sensibilidad por medio
de la ganancia de cdigo.
Reduccin de la energa usada al activarse
Al ser los periodos activos de los sensores IEEE 802.15.4 muy cortos, una parte
signicativa de la potencia puede perderse si el transceptor tarda mucho en ponerse
a funcionar. El uso de tcnicas como DSSS aporta la ventaja de que sus ltros de
canal de gran anchura llevan de forma implcita aparejados una baja latencia.
No se contempla funcionamiento en modo dplex para as reducir los picos de corriente.
Eleccin adecuada de la frecuencia de la portadora: por ahora no se contempla el

uso de la banda ISM de 60 GHz.
2.2.4.
Capa MAC IEEE 802.15.4
La Capa MAC realiza las funciones de administracin de la baliza, acceso al canal,

administracin de las ranuras temporales garantizadas, validacin de la trama, acuse de
recibo de trama, asociacin y disasociacin.
28
2.2.4.1.
CAPTULO 2.
ZIGBEE/802.15.4
Estructura de supertrama (Modo balizado)
IEEE 802.15.4 permite el uso de la estructura de supertrama. El formato de esta

supertrama es denido por el coordinador, quedando localizada entre las balizas y dividida
en 16 slots de igual duracin. La baliza es enviada en el primer slot de cada supertrama. Si
el coordinador no quiere usar la estructura de supertrama puede desactivar la transmisin
de balizas, que son usadas para sincronizar los dispositivos adheridos a l, identicar la
PAN y describir la estructura de las supertramas.
La supertrama esta compuesta de una parte activa y otra inactiva. Durante la parte
inactiva, el coordinador no tiene que interactuar con su PAN y entra en modo de bajo
consumo. La parte activa consiste en un periodo de acceso contenido (CAP) y otro periodo
libre de contencin (CFP). Cualquier dispositivo que desee comunicarse durante CAP
competir con otros dispositivos haciendo uso del mecanismo CSMA-CA ranurado. Por
otro lado, CFP contiene ranuras temporales reservadas y queda localizado al nal de la
parte activa de la supertrama. El coordinador puede asignar hasta siete de estos time slots
reservados. Adems, una ranura temporal garantizada puede ocupar ms de un periodo
de ranura. Esta estructura puede verse en la gura 2.9.
Figura 2.9: Estructura supertrama [11]

Esta estructura garantiza el ancho de banda dedicado y el bajo consumo, siendo especialmente adecuado para aquellos casos en los que el coordinador est alimentado mediante bateras. Los dispositivos que componen la red, escuchan dicho coordinador durante el
2.2.
IEEE 802.15.4
29
envo de la baliza4 . Un dispositivo que quiera intervenir, deber registrarse para el coordinador y luego comprobar si hay paquetes para l. Posteriormente, si no hay paquetes
con l como destinatario, pasar a estado inactivo y se activar de nuevo de acuerdo a un
horario que habr establecido previamente el coordinador.
2.2.4.2.
Modelo de transferencia de datos
Existen tres tipos de transacciones de datos: entre dos dispositivos iguales, de un coordinador a un dispositivo de otro tipo y viceversa. El mecanismo de transferencia vara
dependiendo de si la red soporta o no funcionamiento en modo balizado.
Cuando un dispositivo desea transmitir al coordinador datos en modo no balizado,
simplemente transmite su trama, usando CSMA-CA no ranurado. Cuando la transmisin hacia el coordinador se realiza mediante modo balizado, primero espera a
detectar la baliza y, cuando lo hace, se sincroniza con la estructura de supertrama y
transmite su trama de datos en el momento adecuado, usando CSMA-CA ranurado.
Puede activarse de manera opcional el acuse de recibo tanto en modo balizado como
en modo no balizado.
Si es el coordinador el que desea transferir datos a un dispositivo dentro de una
red con funcionamiento balizado activado, indica en la baliza que tiene un mensaje
esperando a ser enviado. El dispositivo escuchar periodicamente la baliza y, si hay
un mensaje con l como destinatario, lo solicitar mediante el envo de un comando
MAC haciendo uso de CSMA-CA ranurado. El mensaje ser enviado entonces usando
tambien CSMA-CA ranurado y, una vez que lo reciba, el dispostivo enviar un acuse
de recibo y el mensaje ser eliminado de la lista de mensajes pendientes en la baliza.
Por otro lado, cuando el mensaje a transmitir por el coordinador se hace en una red
sin funcionamiento balizado activado, el coordinador almacena el mensaje hasta que
el dispositivo entre en contacto con l y solicite el mensaje, mediante la trasmisin de
un comando MAC hacia el coordinador. Este comando MAC de sondeo ser enviado
usando CSMA-CA no ranurado y especicando una tasa de datos requerida. Si no
4 El
envo se produce en modo broadcast de forma peridica. Este periodo puede variar, dependiendo
de la conguracin, entre 0.015 y 252 segundos
30
CAPTULO 2.
ZIGBEE/802.15.4
hay datos pendientes de ser enviados en el coordinador, el coordinador transmitir

una trama de datos con una zona de carga de longitud cero y el dispositivo conrmar
el recibo de esta trama.
En el caso de la transmisin de datos entre dispositivos del mismo tipo, se presentan
dos opciones. En el primer caso, el sensor escuchar de manera constante y transmitir sus datos usando CSMA-CA no ranurado. En el segundo caso, los sensores se
sincronizan para poder ahorrar energa.
2.2.4.3.
Inicializacin y mantenimiento de una PAN
Una PAN solo puede ser iniciada por dispositivos FFD y una vez que ha llevado a
cabo un escaneo de canal activo y que se ha seleccionado un identicador PAN adecuado.
El escaneo activo de canal permite al dispositivo FFD localizar coordinadores que estn
transmitiendo tramas baliza dentro de su espacio de operacin personal.
El escaneo activo de canal se lleva a cabo sobre un conjunto de canales lgicos. Para
cada canal, el dispositivo debe conmutar la trasmisin a dicho canal y y enviar un comando
de solicitud de baliza. Despus de esto, el dispositivo activa su receptor durante un tiempo
congurable y almacena la informacin de todas las balizas PAN distintas que se han
recibido (rechazando en este periodo de tiempo aquellas tramas que no correspondan a
balizas).
Si el comando de solicitud de baliza es recibido por un dispositivo coordinador de
una red con funcionamiento balizado activado, debe ignorar dicho comando y continuar
transmitiendo sus balizas normalmente ya que asume que sus balizas peridicas le acabarn
llegando. Si el comando de solicitud de baliza es recibido por un dispositivo coordinador de
una red no balizada, trasmitir una nica trama de baliza usando CSMA-CA no ranurado.
El escaneo activo de un determinado canal acabar una vez expirado el tiempo especicado o cuando se hayan almacenado el nmero mximo de identicadores PAN indicados
en la implementacin. El escaneo completo nalizar cuando todos los canales del conjunto de canales lgicos disponibles hayan sido escaneados (o cuando se hayan almacenado
2.2.
IEEE 802.15.4
31
el nmero mximo de identicadores PAN indicados en la implementacin si esto ocurre

antes). La eleccin del identicador de PAN se har teniendo en cuenta el resultado de las
PAN detectadas durante el escaneo y ser responsabilidad exclusiva de la aplicacin.
En conjunto con lo visto hasta ahora, para la seleccin del identicador tambin se
tendr en cuenta el resultado de ED en la capa fsica, pudindo ser descartadas ciertas
tramas por parte de la capa MAC. Adems de todo lo anterior, cabe destacar que ZigBee dispone de una serie de procedimientos para solucionar conictos relacionados con la
duplicidad de identicadores PAN dentro de su espacio de operacin personal.
2.2.4.4.
Unin a una red ZigBee
Hay dos procedimientos para unirse a una red ZigBee: asociacin MAC y reasociacin
de red (que se describir ms adelante).
La asociacin MAC es el procedimiento que todo dispositivo ZigBee debe soportar. En
este caso, un coordinador o un ennrutador que desee permitir a otro dispositivo asociarse
a la red deber indicarlo mediante la trasmisin del comando correspondiente. Posteriormente, el dispositivo que desee unirse a la red deber indicarlo mediante otro comando.
Esta ltima peticin causar el inicio de un protocolo de la capa MAC en el que se intercambiarn mensajes entre el dispositivo que desea unirse a la red y el coordinador o el
enrutador, indicndose entre otros detalles la direccin asignada al dispositivo dentro de
la red. Debe destacarse que la asociacin MAC es un protocolo inseguro ya que todas las
tramas que se intercambian son enviadas sin tomar medidas de seguridad.
2.2.4.5.
Sincronizacin
En aquellas redes con funcionamietnto balizado, la sincronizacin se consigue a travs

de la recepcin y decodicacin de las tramas baliza. En redes sin funcionamiento balizado, la sincronizacin es llevada a cabo mediante el sondeo del coordinador solicitando
transmitir datos.
32
CAPTULO 2.
ZIGBEE/802.15.4
Existen tambin procedimientos para la recuperacin de dispositivos que han perdido

la comunicacin con la red, denominados dispositivos hurfanos.
2.2.4.6.
Formato de la trama MAC
El formato general de la trama MAC vara segn el tipo de trama que se enve, las diferentes opciones se muestra en la gura 2.3 e incluyen los siguientes componentes bsicos:
MHR: comprende control de trama, nmero de secuencia e informacin de direccionamiento.
Zona de carga MAC: de longitud variable, contiene informacin especca del tipo
de trama. Las tramas ACK no contienen zona de carga.
MFR: contiene FCS (Frame
2.2.4.7.
Check Sequence ).
Caractersticas que reducen el consumo energtico en la capa MAC
Se presentan a continuacin las caractersticas que posibilitan el bajo consumo energtico en la capa MAC:
Supertrama MAC: permite el funcionamiento en modo balizado que a su vez deriva
en un menor tiempo de actividad (duty cycle ) de los dispositivos.
CSMA-CA: su uso en lugar del sondeo disminuye signicativamente el consumo.
Efecto de recuperacin de las bateras: todos los tipos de bateras presentan un efecto
de recuperacin por el cual su duracin se extiende si la corriente es extrada de ellas
en rfagas en lugar de hacerse con el equivalente en corriente constante.
2.3.
ZIGBEE ALLIANCE
2.3.
33
ZigBee Alliance
A continuacin se describir de forma detallada la parte de ZigBee responsabilidad de

ZigBee Alliance, sin embargo, se deben tener claras una serie de ideas:
ZigBee Alliance es:
Una asociacin de empresas que buscan promover IEEE 802.15.4.
Una asociacin de empresas que llevan a cabo la comercializacin y certicacin
de ZigBee.
Una asociacin de empresas que se ocupan de la denicin de las capas supe-
riores de ZigBee.
2.3.1.
Capa de Red ZigBee
La capa de red ZigBee se ocupa del enrutamiento mediante la invocacin de acciones en

la capa MAC. Sus tareas incluyen iniciar la red5 , asignar direcciones de red, aadir o eliminar dispositivos en la red, enrutar mensajes, aplicar medidas de seguridad e implementar
el descubrimiento de rutas.
2.3.1.1.
Reincorporacin a la red
El procedimiento de reincorporacin a la red puede ser, a pesar de su nombre, usado

para unirse a la red por primera vez. Se trata de un protocolo de la capa de red, lo que quiere
decir, por un lado, que no es responsabilidad obligada de la capa MAC permitir la unin
de dispositivos a la red y que, si se hace a nivel de red, la unin de un dispositivo a la red
puede hacerse de forma segura. Esto ltimo es cierto si el dispositivo est reincorporndose
a a red o si el dispositivo esta unindose por primera vez pero ha obtenido la clave de red
por medio de algn mecanismo externo.
5 Si
se trata de un dispositivo actuando como coordinador
34
2.3.1.2.
CAPTULO 2.
ZIGBEE/802.15.4
Enrutamiento ZigBee
El algoritmo de enrutamiento ZigBee est basado en el concepto de enrutamiento por

vector distancia, en el cual cada enrutador que participa en la transmisin de tramas desde
una fuente a un destino mantiene un registro en su tabla de enrutamiento asociada a esta
comunicacin. Este registro, como mnimo, debe almacenar tanto la distancia lgica hasta
el destino como la direccin del siguiente enrutador en el camino hacia dicho destino.
Las rutas son determinadas segn van siendo solicitadas usando un proceso de descubrimiento de rutas en el que el dispositivo que desea trasmitir enva un comando de solicitud
de ruta a todos los dispositivos a su alcance, posteriormente, cuando dicho mensaje llegue
al destinatario, tras sucesivas retransmisiones por parte de los enrutadores intermedios,
ste contestar enviando un comando con el dispositivo origen de la peticin ahora como
destino. Conforme dicha contestacin vaya pasando a travs de los distintos enrutadores
que actuarn como intermediadores en la trasmisin, se ir creando en cada uno de ellos el
registro dentro de la tabla de enrutamiento indicado anteriormente. Este procedimiento se
muestra en la gura 2.10. Existen un gran nmero de optimizaciones al algoritmo bsico
descrito que sirven para reducir la memoria RAM dedicada a las tablas de enrutamiento.
Figura 2.10: Descubrimiento de ruta [20]
Una de estas alternativas para reducir las necesidades de memoria es usar el mecanismo
de distribucin de direcciones, en el que las direcciones son asignadas siguiendo una cierta
jerarqua, comenzando por el coordinador. As, los dispositivos con poca o ninguna capacidad de enrutamiento, o dispositivos cuya capacidad haya sido agotada, tienen la opcin
de usar el encaminamiento jerrquico para proporcionar un enrutamiento posiblemente
menos eciente pero ms sencillo (ya que el paquete es siempre enrutado hacia un padre
2.3.
ZIGBEE ALLIANCE
35
o un hijo, segn el rango de la direccin de destino). Este procedimiento se muestra en la

gura 2.11.
Figura 2.11: Encaminamiento jerquico [20]

Por otro lado, en la mayora de las aplicaciones empotradas para redes inalmbricas
suele existir un dispositivo denominado sumidero, al que todos los dems dispositivos pertenecientes a la red deben enviar datos de forma regular. Para evitar que cada dispositivo
de la red deba descubrir al sumidero de forma individual, se establece un caso especial
de descubrimiento de ruta en el que una nica peticin en modo broadcast realizada por
el sumidero establece un registro con l como destino en las tablas de encaminamiento
de cada enrutador de la red. En grandes redes, los problemas pueden darse cuando el
sumidero necesita alcanzar a cada dispositvo de la red de forma separada. El caso de una
red en la que el sumidero tiene pocos vecinos pero mediante los cuales pueden alcanzarse
muchos dispositvos ejemplica este problema. Las tablas de enrutamiento de estos pocos
vecinos se vern sobrecargadas simplemente por su proximidad al sumidero.
La especicacin ZigBee PRO introduce otro estilo de enrutamiento, conocido como
enrutamiento fuente, que solventa este problema. Mientras que en el enrutamiento basado
en el algoritmo de vector distancia la informacin de enrutamiento es almacenada en las
tablas de los dispositivos que participan en la retransmisin de una trama, el enrutamiento
fuente aade la informacin de enrutado en la propia trama que se transmite. Ahora solo
el origen de la trama necesita almacenar la informacin para la ruta, pero a costa de que
36
CAPTULO 2.
ZIGBEE/802.15.4
el registro sea mayor ya que debe almacenar la ruta completa y no solo el siguiente salto.
2.3.1.3.
Caractersticas que reducen el consumo energtico en la capa de red
Se presentan a continuacin las caractersticas que posibilitan el bajo consumo energtico en la Capa de Red:
El algoritmo de enrutamiento usado en ZigBee 1.0 emplea como parmetros tanto la
calidad del enlace como el nmero de saltos, de esta manera disminuye el consumo
de energa al minimizar las retransmisiones de mensajes y evitar la repeticin de las
rutinas para el descubrimiento de rutas.
Las implementaciones futuras de ZigBee probablemente incluirn dentro de su funcin de costes para la eleccion de la ruta adecuada parmetros relacionados con el
consumo energtico, tales como energa restante del sensor o fuente de energa usada
por el sensor.
2.3.2.
Capa de Aplicacin ZigBee
La capa superior de la pila de protocolos ZigBee esta compuesta por los siguientes
elementos:
Marco de aplicacin: proporciona una descripcin acerca de cmo denir un perl
en la pila ZigBee. Tambin especica un conjunto de tipos de datos para perles,
descriptores para la asistencia en el servicio de descubrimiento, formatos de trama
para el transporte de datos y un constructor para desarrollar perles bsicos.
Dentro del marco de aplicacin quedan denidos los objetos de aplicacin, que
es un software que actua como endpoint y que sirve para el control del dispositivo
ZigBee. Un dispositivo ZigBee soporta hasta 240 objetos de aplicacin, estando el 0
reservado para ZDO.
2.3.
ZIGBEE ALLIANCE
37
ZDO: dene el papel a desempear por un dispositivo dentro de la red (coordinador, enrutador o dispositivo nal), inicia y/o responde a peticiones de conexin y
de descubrimiento, y establece una relacin segura entre los dispositivos de la red.
Tambin provee un amplio conjunto de comandos para la administracin de la red
y el dispositivo. ZDO es siempre el endpoint 0.
En colaboracin con ZDO se encuentra el Plano de Administracin ZDO, cuya
labor es facilitar la comunicacin entre el APS y la capa de red con ZDO. Permite
al ZDO negociar peticiones relacionadas con el acceso a la red o la seguridad.
APS: responsable de proveer el servicio de datos a la aplicacin. Se ocupa tambin
de almacenar la tabla de conexiones.
SSP (Secure Services Provider ): acta entre APS y la capa de red para proveer los
mecanismos necesarios para el uso de encriptacin a ambas. Queda congurado a
travs de ZDO.
2.3.2.1. Perles de aplicacin, grupos y endpoints

Un perl de aplicacin describe una coleccin de dispositivos empleados para una
aplicacin especca e, implicitamente, el esquema de intercambio de mensajes entre estos
dispositivos. Un identicador de perl es asignado para cada aplicacin de manera que
quede identicado de forma unvoca.
Existen dos tipos de perles de aplicacin:
Perl de aplicacin pblico: aplicacin desarrollada por ZigBee Alliance que realiza
una tarea determinada y puede ser usada en cualquier dispositivo ZigBee.
Perl de aplicacin especco de un fabricante: aplicacin privada desarrollada por
una compaa para funcionar en un derteminado dispositivo ZigBee.
Los dispostivos con un perl de aplicacin comn se comunican entre ellos usando el
concepto de grupos, en el que se describen las posibles entradas o salidas de datos que se
38
CAPTULO 2.
ZIGBEE/802.15.4
pueden registrar desde o hasta otros dispositivos. Un identicador de grupo diferencia de

forma unvoca los grupos dentro del rango de un perl determinado.
Un endpoint dene una entidad dentro de un dispositivo a travs de la que se realiza
la comunicacin con una aplicacin especca, como ya se indic, pueden existir hasta
240 endpoint s, estando el 0 reservado para ZDO, que proporciona comandos de control y
administracin.
2.4.
Seguridad en ZigBee
La seguridad en ZigBee esta basada en el algoritmo 128-bit AES (Advanced Encryption

Standard ) y se aade al modelo de seguridad que provee IEEE 802.15.4. Incluye mtodos
para el establecimiento y el transporte de manera cifrada, administracin de dispositivos y
proteccin de la trama. La especicacin de ZigBee dene la seguridad para las capas MAC,
de red y de aplicacin. La seguridad para las aplicaciones es proporcionada tpicamente a
travs de los perles de aplicacin.
Veamos los elementos ms importantes en lo referente a la seguridad:
Centro de Conanza: decide si se permiten o no nuevos dispositivos en la red y puede
actualizar y cambiar de forma peridica la clave de red. Para ello, transmite la nueva
clave encriptada con la anterior. Posteriormente comunicar a los dispositivos que
pasen a utilizar la nueva clave.
El Centro de Conanza es normalmente el coordinador, pero tambien puede ser un
dispositivo dedicado a esta labor. Es responsable de las siguientes tareas de seguridad:
Autenticacin de dispositivos que soliciten unirse a la red.
Mantenimiento y distribucin de las claves de red.
Habilitar seguridad
end-to-end
entre dispositivos.
Claves de seguridad: ZigBee usa tres tipos de claves, la Clave Maestra, la Clave de
Red y la Clave de Enlace.
2.4.
SEGURIDAD EN ZIGBEE
39
Clave Maestra: esta clave no es usada para la encriptacin de tramas sino como
un secreto inicial compartido entre dos dispositivos cuando se lleva a cabo el

Procedimiento de Establecimiento de Clave para determinar la clave de enlace.
Las claves que se originan en el Centro de Conanza se denominan Claves
Maestras del Centro de Conanza mientras que las dems se denominan Claves
Maestras de la Capa de Aplicacin.
Clave de Red: proporciona la seguridad para la Capa de Red. Todos los dispo-
sitivos en la red ZigBee comparten la misma clave. Las claves de red de alta
seguridad siempre deben ser transmitidas encriptadas mientras que las claves
de red de seguridad estndar pueden ser enviadas con o sin encriptacin. La
opcin de alta seguridad es solo soportada por ZigBee PRO.
Clave de Enlace: se trata de una clave opcional, usada para el envio unicast
de mensajes entre dos sipositivos a nivel de la capa de aplicacin. Las claves

de red proporcionadas por el Centro de Conanza son denominadas Claves de
Enlace del Centro de Conanza, las dems son denominadas Claves de Enlace
de la Capa de Aplicacin.
40
CAPTULO 2.
ZIGBEE/802.15.4
Captulo 3
Componentes y tecnologas utilizadas
En este captulo se har una descripcin de las herramientas tanto software como
hardware que han sido necesarias para la realizacin y prueba de este Proyecto Fin de
Carrera.
3.1.
3.1.1.
Elementos hardware
Equipo de desarrollo eZ430-RF2480 de Texas Instruments
El equipo de desarrollo eZ430-RF2480 de Texas Instruments proporciona la red de

sensores ZigBee/802.15.4 que permiten vericar el correcto funcionamiento de la pasarela
a desarrollar en este proyecto. A continuacin se har una descripcin de sus elementos centrndonos principalmente en la pastilla contenedora de la pila de protocolos ZigBee/802.15.4 pero sin entrar en grandes detalles ya que no es el objetivo de este proyecto
su estudio. Para conocer ms acerca de su funcionamiento se recomienda consultar la gua
para desarrolladores del CC24801 .
1 Disponible
en http://focus.ti.com/lit/an/swra176/swra176.pdf
41
42
CAPTULO 3.
COMPONENTES Y TECNOLOGAS UTILIZADAS
El equipo de desarrollo que nos ocupa est compuesto de tres motas/sensores ZigBee, un conector USB (Universal Serial Bus ) y dos suministradores de energa mediante
bateras. Todos ellos pueden verse en la gura 3.1.
Figura 3.1: Contenido eZ430-RF2480
El conector USB permite la comunicacin de las motas con un ordenador, de esta

manera se pueden recibir datos procedentes de la red y programar las motas haciendo uso
del software IAR Embedded Workbench2 . Por otro lado, el conector tambin proporciona
la energa necesara para el correcto funcionamiento de la mota conectada al conversor. En
cuanto a los suministradores de energa mediante bateras, se ha de destacar que permiten
mantener en funcionamiento a las motas conectadas a ellos sin necesidad de depender de
la red elctrica, funcionando con bateras de tipo AAA.
2 Descrito
en el apartado 3.2.1.3
3.1.
ELEMENTOS HARDWARE
43
Descripcin de las motas

Las motas ZigBee contenidas en el equipo de desarrollo eZ430-RF2480 presentan una
arquitectura basada en un procesador que se ocupa de las capas fsica, MAC y de red y
un microcontrolador que se encarga nicamente de la capa de aplicacin. En concreto,
el procesador es un CC2480 y el microcontrolador es un MSP430F2274, comunicndose
ambos mediante interfaz SPI (Serial Peripheral Interface ) o UART (Universal Asynchronous Receiver-Transmitter ) segn puede verse en la gura 3.2. La antena se encuentra
integrada en el mismo CC2480.
Figura 3.2: Conexin CC2480-MSP430
La solucin incluida en estas motas por Texas Instruments de cara a la implementacin

de la pila de protocolos es denominada Z-Accel. Dicha solucin consiste en la ejecucin de
la versin de la pila de protocolos ZigBee desarrollada por Texas Instruments, denominada
Z-Stack, en el procesador CC2480 y la ejecucin de la aplicacin en el microcontrolador
MSP430F2274. El CC2480 se ocupa de manejar todas las tareas crticas en tiempo as como
todo aquello relacionado con el protocolo ZigBee/802.15.4 mientras que el microcontrolador est liberado para ocuparse tan solo de la ejecucin de la aplicacin almacenada. Esta
distribucin de capas, y por lo tanto de tareas, entre el procesador y el microcontrolador
queda representada en la gura 3.3. Todo lo anteriormente descrito funciona cumpliendo
el estndar ZigBee-2006. Se debe resear que el procesador CC2480 trabaja slo en modo
no balizado.
44
CAPTULO 3.
Figura 3.3: Distribucin de protocolos CC2480-MSP430 [26]
Trama intercambiada entre procesador y microcontrolador

Un punto importante a la hora de llevar a cabo este proyecto es determinar cal es el
formato de trama intercambiado entre el microcontrolador MSP430F2274 y el procesador
CC2480 ya que ser esta trama la que se tome y posteriormente enve a travs de la red
IP. Dicho formato se muestra en la gura 3.4.
Figura 3.4: Formato de trama intercambiada entre CC2480 y MSP430

El primer campo que nos encontramos en el formato descrito es el byte SOF (Start
Of Frame ) que avisa del comienzo de la trama. El siguiente campo indica la longitud en
bytes del campo de datos. A continuacin se encuentran los bytes de datos. Como ltimo
campo encontramos el FCS, que es una funcin XOR de todos los campos anteriormente
3.1.
ELEMENTOS HARDWARE
45
descritos exceptuando el SOF.

El byte de comando presenta el formato que se muestra en la gura 3.5.
Figura 3.5: Campo de Comando
Los comandos que se intercambian el microcontrolador y el procesador pueden ser de

los siguientes tipos:
Peticin Asncrona: enviada desde el microcontrolador al procesador. No se espera
respuesta.
Peticin Sncrona: enviada desde el microcontrolador al procesador. Se espera respuesta.
Respuesta Sncrona: respuesta por parte de procesador a la peticin sncrona hecha
por el microcontrolador.
Sondeo: al estar toda comunicacin iniciada por el microcontrolador, el sondeo sirve
para preguntar al procesador si tiene alguna peticin que realizarle al microcontrolador.
Por otra parte, como ya se mostr anteriormente, la capa de aplicacin se compone
de distintas subcapas, indicndose esto mediante el campo subsistema.
Finalmente, los 8 bits nales del campo comando identican a cada uno de los comandos
disponibles.
46
CAPTULO 3.
Interfaz de aplicacin
En cuanto a la interfaz con la capa de aplicacin, aparte de la interfaz API propia
de la solucin Z-Stack, y las interfaces de sistema y con ZDO, el procesador CC2480
aporta la interfaz Simple API o SAPI. La interfaz SAPI ofrece nicamente diez llamadas a
funciones API, esto facilita enormemente el desarrollo de aplicaciones ZigBee. Esta versin
simplicada est pensada para aquellos dispositivos el los que la pila de protocolos est
cargada en el procesador y, por lo tanto, no se permite un nivel de conguracin tan
alto como el que API Z-Stack proporciona por lo que no son necesarias gran parte de las
llamadas que contiene. SAPI contiene lo necesario para formar una red ZigBee, vincular
dispositivos y enviar/recibir datos. Para conocer con mayor profundidad estos aspectos se
recomienda la consulta del documento 'CC2480 Interface Specication'3 .
Microprocesador MSP 430

Como se ha descrito a lo largo de esta seccin, el procesador CC2480 se combina
con un microcontrolador MSP430F2274 que gestiona la parte de aplicacin. Este microcontrolador tiene como principal caracterstica el bajo consumo energtico, lo cual lo hace
ideal para lograr uno de los principales propsitos de ZigBee, la duracin de las bateras.
Esto se logra gracias a su arquitectura y a cinco modos de funcionamiento optimizados
para lograr un bajo consumo energtico. Presenta una unidad de proceso RISC (Reduced
Instruction Set Computer ) de 16 bits con 16 registros, una memoria ash de 32 Kbytes y
una memoria RAM de 1 Kbyte.
3.1.2.
Conversor TTL-232R-3V3 de FTDI
Los conectores TTL-232R de FTDI son una familia de conversores de UART-TTL a

USB que permiten la gestin de toda la sealizacin y protocolos asociados al estndar
USB. Cada uno de estos conversores contiene un pequeo circuito impreso interno encapsulado en el propio conector USB incluido al nal del cable. El modelo concreto usado en
3 Disponible
en http://focus.ti.com/lit/er/swra175a/swra175a.pdf
3.1.
ELEMENTOS HARDWARE
47
este proyecto es el TTL-232R-3V3 y puede verse en la gura 3.6.
Figura 3.6: FTDI TTL-232R-3V3 [18]
La parte USB del conversor presenta funcionalidad USB de tipo 2.0. El cable mide 1.8m
de longitud y permite hasta 3 Mbaud de tasa de transferencia de datos. Adems, cada
cable incorpora la identicacin nica desarrollada por FTDI y denominada FTDIChip-ID
que permite proporcionar seguridad a la hora del acceso para la transferencia de archivos
a travs del conversor.
El conversor TTL-232R requiere una serie de controladores que le permiten aparecer en
el sistema operativo correspondiente como un puerto virtual, permitiendo de esta manera
la comunicacin con este dispositivo mediante los puertos de emulacin serie disponibles
en el sistema operativo (como por ejemplo TTY en el caso de Linux). Para el desarrollo
de este proyecto, la existencia de controladores para este conversor destinados a sistemas
operativos basados en el kernel 2.4 de Linux fue esencial para su eleccin frente a otras
alternativas, como podra haber sido el conversor proporcionado en el equipo de desarrollo
eZ430-RF2480 de Texas Instruments.
48
3.1.3.
CAPTULO 3.
Router ASUS WL-500G Premium
La programacin de nuestra pasarela Zigbee/802.15.4-IP se llevar a cabo sobre un

router ASUS WL-500G Premium. Esta eleccin se debe a la facilidad para poder instalar
en l un sistema operativo basado en Linux y al hecho de disponer de conexiones USB a
travs de las cuales llegar la informacin procedente de nuestra red de sensores ZigBee.
Se muestra una breve descripcin de sus principales caractersticas en la tabla 3.1.
Parmetro
Estndar Inalmbrico
Cifrado
Antena
Modulacin
Frecuencia de operacin
Tasa de transferencia de
datos nominal
Potencia de salida
Sensibilidad
Canales
WAN
LAN
Otras conexiones
Descripcin
IEEE 802.11 b/g

WEP, WAP, WPA2
Antena IF interna y antena externa de
dipolo
OFDM, CCK, DQPSK, DBPSK
2.4 - 2.5 GHz
802.11g: 6, 9, 12, 18, 24, 36, 48, 54 Mbps;
802.11b: 1, 2, 5.5, 11Mbps
802.11g: 14~16dBm; 802.11b: 16~18dBm
-74~-75dBm a 54Mbps; -87~-88dBm a
11Mbps; -95~-97dBm a 1Mbps
13 para Europa (ETSI), 11 para Norte
America y 14 para Japn
1 puerto RJ-45 (10/100 BaseT) Fast
Ethernet (10/100 Mb/s)
4 puertos RJ-45 (10/100 BaseT) Fast
Ethernet (10/100 Mb/s)
2 puertos USB2.0
Tabla 3.1: Caractersticas Asus WL-500G Premium [2]

El enrutador presenta una serie de indicadores de tipo LED en el frontal que indican
su estado segn actuen de una u otra manera. En la gura 3.7 podemos apreciar dichos
indicadores.
Como ya se indic, una de las grandes ventajas del enrutador elegido es la gran capacidad de conectividad que presenta gracias a sus dos puertos USB 2.0. Adems de esto,
presenta 4 puertos para conexiones LAN y otro puerto para conexin WAN, sin olvidar
3.1.
ELEMENTOS HARDWARE
49
Figura 3.7: Asus WL 500G Frontal

las conexiones para la antena (a la derecha) y la alimentacin (a la izquierda) tal y como
puede apreciarse en la gura 3.8. Debe destacarse el interruptor restore, imprescindible
para la instalacin del sistema operativo deseado como veremos ms adelante.
Figura 3.8: Asus WL 500G Trasera

En lo referente a la arquitectura interna, el enrutador est compuesto de dos placas, la
principal y un mdulo Wi-Fi. Esta ltima es una pequea placa conectada a la principal
a travs de una ranura miniPCI. Esta estructura puede apreciarse en la gura 3.9.
En la placa principal destacan dos chips, uno fabricado por Broadcom y denominado BCM4318E y otro denominado SiGe 2521A60. El chip BCM4318E es un controlador
inalmbrico altamente integrado que, entre otras tareas, es capaz de dar soporte a la tecnologa propietaria de Broadcom denominada AfterBurner que permite un incremento de
50
CAPTULO 3.
Figura 3.9: ASUS WL-500G Premium Interior

la tasa de transferencia de datos para 802.11g de hasta un 35 % mediante la compresin
de tramas. Por su parte, el chip SiGe 2521A60 es un mdulo de radiofrecuencia para la
gestion de los estndares 802.11b y 802.11g.
Los principales componentes del enrutador, procesador y memoria, se encuentran en
la placa impresa principal bajo la carcasa metlica. El ASUS WL 500g Premium est
equipado con un procesador BCM4704 fabricado por Broadcom. Se trata de un procesador
MIPS4 (Microprocessor without Interlocked Pipeline Stages ) de 32 bits que puede funcionar
a una frecuencia de 300 MHz a pesar de que en este enrutador la frecuencia quede limitada
a 264 MHz.
El sistema operativo se almacena en una memoria ash de 8Mbytes fabricada por
Spansion. Adems, cuenta con 32 Mbytes de memoria RAM5 para la ejecucin de software.
Otros dos controladores a los que se debe hacer mencin son el chip VT6212L fabricado
por VIA y el chip BCM5325E fabricado por Broadcom. El primero es un controlador para
4 Familia
de microprocesadores de arquitectura RISC desarrollados por MIPS Technologies.
5 Concretamente
DDR SDRAM
3.2.
ELEMENTOS SOFTWARE
51
los puertos USB 2.0 y el segundo es un conmutador Fast Ethernet con un buer para
tramas de 128 Mbytes y la capacidad de detectar el tipo de cable conectado al puerto
(ordinario o cruzado).
Para la resolucin de problemas, se puede conectar al enrutador ASUS WL-500G Premium a travs de un bus de tipo UART. El conector correspondiente se encuentra localizado en el borde derecho de la placa principal.
3.2.
3.2.1.
3.2.1.1.
Elementos software
Herramientas
DD-WRT
El software DD-WRT es un rmware libre con licencia GPL (General Public License) versin 2. Est destinado a una gran variedad de enrutadores inalmbricos IEEE
802.11a/b/g/h/n con arquitectura basada en chips Atheros o Broadcom.
Las versiones hasta la nmero 22 estaban basadas en el rmware Alchemy de Sveasoft,
que a su vez estaba basado en el rmware original de Linksys con licencia GPL. Desde la
versin 23 en adelante est basado en OpenWrt, que empez siendo un rmware basado en
el de Linksys pero ms tarde cambi a su propio entorno. La idea inicial de crear DD-WRT
surgi debido a la decisin de Sveasoft de comenzar a cobrar por su producto, cerrando
de esta manera la puerta al cdigo abierto. Actualmente DD-WRT puede conseguirse de
manera gratuita en su web pero existen una serie de versiones solo accesibles previo pago.
Para determinar qu versin es adecuada instalar en nuestro enrutador, basta con acceder a la pgina ocial del rmware DD-WRT6 , una vez ah acudir a la seccin Support y
entrar a Router Database. Especicando nuestro modelo de router en el espacio correspondiente se mostrarn las versiones recomendadas para ser instaladas en nuestro dispositivo,
6 http://www.dd-wrt.com
52
CAPTULO 3.
en este caso la eleccin es la versin 24 (build 12188). Es importante asegurarse de que la

versin es la adecuada ya que existen versiones con ncleo 2.6 y otras con ncleo 2.4 de
Linux, la instalacin en el dispositivo inadecuado de cualquiera de ellas puede dar como
resultado la inutilizacin permanente del enrutador.
Adems de existir distintas versiones disponibles, tambin es posible elegir entre varias
tipos de
rmware
dentro de cada versin, diferenciandose entre ellos por las utilidades
que incluyen instaladas por defecto. Esto ltimo es importante ya que de esta eleccin
dependern los requisitos, principalmente de memoria, de los que necesitaremos disponer
en nuestro enrutador.
En la tabla 3.2 se describen algunas caractersticas que pueden ser incluidas en DDWRT:
3.2.
53
ELEMENTOS SOFTWARE
Utilidad
Asterisk
Monitorizacin del ancho de banda

Chillispot
Afterburner
IPv6
JFFS2
Soporte de expansin de memoria
MMC/SD
Samba
Wake On LAN
RFlow Collector
Descripcin
Aplicacin que emula una PBX mediante

software. Permite el manejo de telefona
sobre IP sin necesidad de aadir hardware
adicional, facilitando la interoperabilidad
con la mayora de dispositivos estndares
de telefona.
Monitorizacin de ancho de banda
consumido por cada usuario, media
temporal...
Aplicacin para la autenticacin de
usuarios. Permite el ingreso via web que es
el estndar actual para HotSpots pblicos.
Incrementa el throughput WiFi a travs
de procesos software.
Versin de IP denida en el RFC 2460 y
diseada para reemplazar a la versin 4
denida en el RFC 79
rea dentro de un dispositivo equipado
con DD-WRT para la re-escritura habitual
de datos.
Permite aadir memoria externa al
enrutador para el almacenamieto de datos
y/o aplicaciones.
Implementacin libre del protocolo de
archivos compartidos de Microsoft
Windows (antiguamente llamado SMB,
renombrado recientemente a CIFS) para
sistemas de tipo UNIX.
Permite encender remotamente
ordenadores en estado de hibernacin o
apagados.
Permite el envo y almacenamiento de
informacin relacionada con el trco de
la red para su posterior estudio.
Tabla 3.2: DD-WRT: Utilidades principales [1]
54
CAPTULO 3.
La eleccin de DD-WRT para la realizacin de este Proyecto Fin de Carrera se bas en

la existencia de controladores para el conversor TTL-232R-3V3 de FTDI, la facilidad de
conguracin a travs de su interfaz web, cuya pantalla principal puede verse en la gura
3.10, y la posibilidad de incluir el desarrollo software realizado para el funcionamiento de
la pasarela dentro de la estructura del rmware a instalar en el router.
Figura 3.10: DD-WRT: Interfaz Web
El lenguage de programacin bajo el que est desarrollado el ncleo de DD-WRT es

C++, existiendo adems compiladores cruzados para la creacin de aplicaciones dirigidas
a routers con arquitectura MIPS tal y como es el caso del ASUS WL-500G Premium.
En sucesivos captulos se describir de una manera detallada el proceso de compilacin,
instalacin y conguracin del rmware para lograr la completa adaptacin de ste a los
requerimientos deseados.
3.2.
ELEMENTOS SOFTWARE
3.2.1.2.
55
Entorno de desarrollo Eclipse
Eclipse es una comunidad cuyos objetivos estn centrados en la realizacin de una plataforma de cdigo abierto para el desarrollo de aplicaciones. Se puede mantener el mismo
entorno de desarrollo pero variar el lenguage de programacin usado para la aplicacin a
desarrollar sin ms que aadir distintos mdulos. La Fundacin Eclipse7 es una asociacin
sin nimo de lucro que busca tanto el mantenimiento del entorno de desarrollo Eclipse
como el crecimiento de una serie de productos y servicios complementarios a ste a la vez
que promueve la comunidad de cdigo abierto surgida entorno a este proyecto.
El Proyecto Eclipse fue creado por IBM en Noviembre de 2001 y apoyado por una
agrupacin de desarrolladores de software. La Fundacin Eclipse fue creada en Enero de
2004 como medio que permitiese a cualquier empresa neutral y abierta establecerse en
alrededor de todo lo relacionado con Eclipse. Puede apreciarse la estructura de la pantalla
principal de Eclipse en la gura 3.11.
Figura 3.11: Eclipse: Pantalla Principal

Existe la extendida idea de que Eclipse es simplemente una extensin dedicada al
7 http://www.eclipse.org/org/foundation/
56
CAPTULO 3.
desarrollo de software Java, pero nada ms lejos de la realidad ya que Eclipse permite
la adicin de mdulos para el desarrollo de aplicaciones en lenguages de programacin
tan diversos como pueden ser C/C++, PHP, Perl, Ruby y JavaScript. Cada una de estos
mdulos se denominan Kits de Desarrollo Software (SDK) y permiten desde la correccin
de la sintaxis utilizada, hasta la depuracin y compilacin del cdigo, pasando por la
informacin acerca de las API que pueden utilizarse y como deben ser utilizadas. Otra
interesante caracterstica de Eclipse es su capacidad para ocultar bloques de cdigo que
hacen ms fcil la comprensin y manejo del mismo cuando ste crece.
En cuanto a su rendimiento, Eclipse se muestra muy estable, presentando como nico inconveniente su consumo de memora, que lo hace especialmente lento en aquellas
mquinas con pocos recursos de memoria RAM.
En el caso de este Proyecto Fin de Carrera se hace uso de Eclipse en combinacin con
el SDK de C++, todo ello ejecutado bajo un sistema operativo Ubuntu 10.04.
3.2.1.3.
MSP430 IAR Embedded Workbench
La aplicacin MSP430 IAR Embedded Workbench es un entorno de desarrollo de

C/C++ que integra las funciones necesarias para la realizacin de aplicaciones empotradas
destinadas a la familia de microcontroladores MSP430. Se muestran a continuacin los
elementos ms destacados de los que est compuesto:
Editor de textos
Permite la edicin de varios archivos en paralelo, adems de todas las caractersticas bsicas exigidas en un editor de textos moderno, como la posibilidad de hacer/rehacer
de forma ilimitada acciones. Provee tambin caractersticas destinadas a facilitar el desarrollo de software como puede ser el resaltado de palabras clave del lenguage C/C++.
3.2.
ELEMENTOS SOFTWARE
57
Compilador IAR C/C++

Incluye las caractersticas bsicas de un compilador C/C++ adems de extensiones
que permiten aprovechar las facilidades que los microcontroladores de la familia MSP430
ofrecen.
Depurador IAR C-SPY

Se trata de un depurador de cdigo de alto nivel destinado a aplicaciones empotradas. Est especialmente diseado para su uso junto a ensambladores y compiladores
de IAR System. Entre sus caractersticas incluye la posibilidad de editar el cdigo fuente
mientras se est depurando ste.
El depurador est compuesto de dos mdulos, uno que aporta un conjunto de acciones
para la depuracin y otro que acta como un controlador, permitiendo la comunicacin y
control del dispositivo destino de la aplicacin desarrollada.
Simulador IAR C-SPY

Este mdulo permite simular las funciones del procesador destino mediante software. As, mediante IAR C-SPY, la aplicacin puede ser depurada antes de que sea portado
al dispositivo destino, facilitando la tarea y ahorrando tiempo de forma considerable.
Depurador C-SPY FET

Se trata de una emulador a travs de conexin JTAG (Joint Test Action Group ),
incluida en todas las placas de desarrollo de Texas Instruments. Este mdulo permite la
descarga de la memoria ash y aprovecha las facilidades de la depuracin sobre el chip.
Podemos ver la estructura de MSP430 IAR Embedded Workbench en la gura 3.12:
58
CAPTULO 3.
Figura 3.12: MSP430 IAR Embedded Workbench: Estructura [24]

Para la ejecucin de este Proyecto Fin de Carrera, MSP430 IAR Embedded Workbench
fue utilizado para la modicacin del software residente en las motas proporcionadas por
el equipo de desarrollo eZ430-RF2480 de Texas Instruments, usndose la versin de prueba
disponible en su web8 .
3.2.1.4.
WinSCP
WinSCP es una aplicacin libre y descargable desde su web9 que se ejecuta bajo sistemas operativos Windows y permite conectarse a un servidor SSH (Secure Shell ) empleando
el protocolo SFTP (SSH File Transfer Protocol ) o el servicio SCP (Secure Copy Protocol ). WinSCP permite efectuar las operaciones bsicas con archivos, tales como descargas
y subidas. Tambien es posible renombrar archivos y directorios, crear nuevos directorios,
modicar las propiedades de archivos y carpetas, y crear enlaces simblicos y accesos
directos.
WinSCP permite la eleccin entre dos tipos de interfaces, uno denominado 'commander' que consta de dos paneles (el izquierdo dedicado al directorio local y el derecho al
8 http://www.iar.com/website1/1.0.1.0/220/1/
9 http://winscp.net/eng/docs/lang:es
3.2.
ELEMENTOS SOFTWARE
59
directorio remoto) y otro denominado 'explorer' en el que solo se muestra un panel (con
la informacin referida al directorio remoto). En la gura puede observarse el interfaz
'commander ' de WinSCP.
Esta aplicacin fue usada para la transferencia de archivos al router equipado con
DD-WRT para facilitar y agilizar el proceso de prueba de los mismos.
3.2.1.5.
Putty
PuTTY es un cliente SSH, Telnet, rlogin, y TCP raw con licencia MIT. Disponible
originalmente slo para Windows, ahora tambin est disponible para varias plataformas
Unix en su web10 . Su caracterstica ms importante de cara a su uso en este Proyecto
Fin de Carrera es su soporte para conexiones de puerto serie local, que fue imprescindible
para la comprobacin del buen funcionamiento del conversor TTL-232R-3V3 de FTDI
conectado a las motas ZigBee proporcionadas por el equipo de desarrollo eZ430-RF2480
de Texas Instruments, as como para la visualizacin del formato de trama enviado por
stas.
La conguracin adecuada para una correcta recepcin de los datos es: 9600 baudios, 8
bits de datos, 1 bit de parada y ningn control de ujo ni de paridad. Los datos se reciben
en formato ASCII (American Standard Code for Information Interchange ). Se puede ver
la pantalla principal de putty en la gura 3.13.
10 http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
60
CAPTULO 3.
Figura 3.13: Putty: Pantalla Principal
3.2.1.6.
XVI32
XVI32 es un editor hexadecimal freeware 11 . Su utilidad viene del hecho de que los
valores recibidos mediante Putty se encuentran en formato ASCII y a travs de esta
utilidad podremos pasar del formato ASCII proporcionado a un formato hexadecimal al
que se est ms habituado y suele ser ms cmodo leer. Para ello, los datos recibidos por
Putty deben ser almacenados en un archivo de texto. Posteriormente bastar ejecutar la
utilidad XVI32 y arrastrar sobre su ventana principal el archivo de texto con los datos en
formato ASCII, mostrndose en pantalla el equivalente en hexadecimal. Se puede ver un
ejemplo de conversin a hexadecimal hecho por XVI32 en la gura 3.14, en ella pueden
apreciarse a la derecha los valores en formato ASCII y a la izquierda su equivalente en
formato hexadecimal.
11 Puede
obternerse en http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
3.2.
ELEMENTOS SOFTWARE
61
Figura 3.14: XVI32: Ejemplo de cambio de formato
3.2.2.
Programacin
3.2.2.1. C++
C++ fue una evolucin de C, el cual surgi a partir de dos lenguajes de programacin
previos, BCPL y B. BCPL fue desarrollado en 1967 por Martin Richards como medio para
escribir software de sistemas operativos y compiladores. Posteriormente, Ken Thompson
cre muchas caractersticas de su lenguaje B segn sus equivalentes en BCPL, valindose
de B para crear las primeras versiones del sistema operativo UNIX. BCPL y B tenan
tambin en comn que eran lenguages sin tipos denidos.
El lenguaje C fue una evolucin de B llevada a cabo por Dennis Ritchie en los Laboratorios Bell. C se basa en muchos conceptos bsicos de BCPL y de B, aadiendo como gran
novedad los tipos de datos. C se hizo muy popular en sus comienzos por el ser el lenguaje
de desarrollo del sistema operativo UNIX.
62
CAPTULO 3.
La gran difusin vivida por C tuvo tambin aspectos negativos, el ms destacado fue
que, al estar disponible para muchos tipos de ordenadores, surgieron demasiadas variantes, siendo parecidas entre ellas pero a menudo incompatibles. Surgia de esta manera un
gran roblema para aquellos desarrolladores con necesidades de crear software portable a
distintas plataformas. Como respuesta a este problema, en 1983 se cre el comit tcnico
X3J11 bajo el ANSI (American National Standards Institute ), con el objetivo de denir el
lenguaje de manera independiente del equipo. Finalmente, en 1989 se aprob el estndar
y el ANSI trabaj junto a ISO (International Organization for Standardization ) en su estandarizacin a nivel mundial, publicndose el documento conjunto del estndar en 1990
bajo el nombre 'ANSI/ISO 9899: 1990'.
Por otro lado, a principios de los 80, Bjarne Stroustrup cre C++, una extensin de C.
C++ aade una serie de caractersticas que mejoran el lenguaje C, pero sobre todas ellas,
la ms importante fue la inclusin de la capacidad de programacin orientada a objetos. El
concepto de objeto surga novedoso pero traera con l la puerta de acceso denitiva para
la construccin de software de forma rpida y econmica. Los objetos son componentes de
software reutilizables capaces de simular elementos reales, permitiendo a los programadores
una mayor facilidad a la hora de entender, corregir y modicar su software que con la
anterior visin de programacin estructurada. C++ era y es un lenguage hbrido ya que
es posible programar tanto en estilo C como en estilo orientado a objetos o en ambos.
En 1983 el nombre C++ fue propuesto y aceptado. La primera implementacin comercial de C++, cfront 1.0, fue lanzada en 1985, se trataba de un traductor de C++ a C.
C++ est denido y mantenido por el comit ISO, compuesto por delegados de asociaciones nacionales de estandarizacin como ANSI, DIN (Deutsches Institut fr Normung ) y
muchas otras. El primer estndar de C++ fue aprobado en 1998 bajo el nombre ISO/IEC
14882, habiendose publicado hasta hoy dos revisiones de ste. El estndar ISO de C++
dene el lenguaje del ncleo, las libreras includas de manera estndar y los requisitos
de implementacin. Se espera para prximas fechas el lanzamiento del nuevo estndar de
C++, siendo el nombre no ocial de ste C++0x.
La implantacin del uso de C y C++ es mayoritara entre la comunidad desarrolladora
de software pero su inuencia es an mayor al ser la base de otros lenguajes de programacin ampliamente usados en la actualidad como es Java, de Sun Microsystems. En la
3.2.
ELEMENTOS SOFTWARE
63
gura 3.15 se muestra la distribucin de uso de los principales lenguaes de programacin

en los ltimos dez aos.
Figura 3.15: Lenguages de Programacin: Distribucin de uso [29]
La gura 3.15 muestra como los tres lenguages de programacin ms usados en la

actualidad y en los ltimos aos son C, C++ y Java, estando ste ltimo basado en C++.
Podemos de esta manera calibrar la importancia de C++ al tratarse de un lenguage hbrido
y permitir programar tanto en estilo C como en estilo orientado a objetos o en ambos.
En el caso de este Proyecto Fin de Carrera, el uso de C++ viene determinado por ser
el lenguaje bajo el que est desarrollado el sistema operativo DD-WRT.
3.2.2.2.
CGI
CGI (Common Gateway Interface ) es un estndar que permite la comunicacin de

aplicaciones externas con servidores. Un programa CGI se ejecuta en tiempo real, por lo
que permite la generacin de informacin de manera dinmica.
64
CAPTULO 3.
Un ejemplo clsico de uso de CGI es la comunicacin de una base de datos con Internet
para permitir su consulta a travs de un servidor. Para llevar esto a cabo se necesitar
un programa CGI, al que la pgina web del servidor llamar cuando el usuario as lo
decida, que permitir extraer resultados de la base de datos y mostrrselos posteriormente
al usuario.
A la hora de usar CGI no hay lmites respecto a lo que se puede realizar pero deber
tenerse siempre presente que el tiempo de cmputo deber presentar una baja latencia
para no sobrecargar el servidor en caso de recibir varias peticiones.
Como un programa CGI es un ejecutable, es equivalente a dejar a cualquier usuario
ejecutar un programa en el sistema, decisin que no es la ms segura. Por ello existen una
serie de precauciones de seguridad que deben implementarse cuando se usan programas
CGI de las cuales la ms importante es que los programas CGI necesitan residir en un
directorio especial. As el servidor sabe que tiene que ejecutarlo, en vez de simplemente
mostrarlo por pantalla. Este directorio est bajo el control del administrador del servidor,
prohibiendo de esta manera al usuario crear programas CGI. El directorio anteriormente
mencionado suele denominarse /cgi-bin y estar dentro del directorio destinado a almacenar
las pginas web alojadas en el servidor, normalmente /www. El servidor conoce que el
directorio /cgi-bin contiene ejecutables que debern ser ejecutados y su salida deber ser
enviada al navegador del cliente.
Un programa CGI puede ser escrito en cualquier lenguage de programacin que pueda
ser ejecutado en el sistema, en el caso de este Proyecto Fin de Carrera os programas se han
desarrollado haciendo uso de C++. Se debe hacer mencin al hecho de que CGI permite
la ejecucin de programas tanto de tipo interpretado como compilado, lo que permite
tambin el uso de scripts.
Para el paso de datos del servidor al programa CGI, el servidor puede usar tanto lneas
de comando como variables de entorno que se activan cuando se ejecuta el programa CGI.
Se describen a continuacin de forma breve estas variables de entorno:
3.2.
ELEMENTOS SOFTWARE
65
SERVER_SOFTWARE
Devuelve el nombre y la versin del software del servidor de informacin que contesta la peticin de usuario.
SERVER_NAME
Devuelve nombre de host del servidor, el alias DNS, o la direccin IP como aparecera en las URL autoreferenciadas.
GATEWAY_INTERFACE
Devuelve la revisin de la especicacin CGI con
que el servidor puede trabajar.
Las variables anteriormente mencionadas son activadas en todos los casos por el servidor, con independencia de la informacin enviada, por otro lado, las que se muestran a
continuacin son especcas de la peticin hecha por el usuario.
SERVER_PROTOCOL
Devuelve el nombre y revisin del protocolo de informacin bajo el que se realiz la peticin.
SERVER_PORT
Devuelve el nmero de puerto por el cual fue enviada la peti-
cin.
REQUEST_METHOD
QUERY_STRING
Devuelve el mtodo por el cual la peticin fue enviada.
Hace referencia a la parte de la URL con la que se llama

al programa CGI que viene inmediatamente despus del smbolo ' ?'. Esta variable de
entorno es usada para pasar una lista de pares variable-valor usando el smbolo '&' como
delimitador de cada uno de los pares y el smbolo '=' como separador entre la variable y su
valor. Para evitar confusiones, algunos caracteres son codicados. Esta variable es usada
principalmente para pasar a los programas CGI informacin asociada a formularios.
66
CAPTULO 3.
REMOTE_HOST y REMOTE_ADDR
Devuelven el nombre del host que

realiza la peticin y la direccin IP del host remoto que realiza la peticin respectivamente.
AUTH_TYPE
Si el servidor soporta autenticacin de usuario , y el programa

CGI est protegido, este es el mtodo de autenticacin especco del protocolo para
validar el usuario.
REMOTE_USER
Si el servidor soporta autenticacin de usuario , y el script

est protegido, este ser el nombre de usuario con el que se ha autenticado.
REMOTE_IDENT
Si el servidor HTTP soporta autenticacin RFC 931 , entonces est variable se activar con el nombre del usuario remoto obtenido por el servidor.
Esta varible solo se utilizar durante el login.
CONTENT_TYPE
Para peticiones que tienen informacin aadida, como HTTP

POST y PUT, este ser el tipo de datos contenido.
CONTENT_LENGTH
Devuelve la longitud del contenido tal como es dado por
el cliente.
Para devolver como respuesta una pgina web, bastar con imprimir sta en pantalla
usando una funcin destinada a ello dentro del lenguaje de programacin elegido para la
creacin del programa CGI, respetando el estndar usado por el servidor para la presentacin de webs. En los programas CGI usados en este Proyecto Fin de Carrera se hace uso
de la funcin printf en combinacin con HTML. Un ejemplo de esta combinacin podra
ser:
printf("<HTML>\n");
printf("<HEAD>\n");
printf("<TITLE>Ejemplo de pgina impresa mediante CGI usando HTML\n");
3.2.
67
ELEMENTOS SOFTWARE
printf("</TITLE>\n");
printf("</HEAD>\n");
printf("</HTML>\n");
Lo anterior, al ejecutarse dentro de un programa CGI escrito en C++, dara como
resultado la impresin por pantalla de una pgina web en blanco con la cabecera Ejemplo
de pgina impresa mediante CGI usando HTML.
Por ltimo, se debe mencionar tambin que el cdigo CGI, una vez compilado, deber
ser guardado en la carpeta cgi-bin anteriormente indicada, con permisos de ejecucin y
extensin 'cgi'.
3.2.2.3.
HTML
HTML (
HyperText Markup Language ) es el lenguage de programacin bsico usado
en la web. El cdigo de HTML hace uso del concepto de etiquetas para permitir a los
navegadores la correcta representacin de las pginas web. Para comprender la forma en
la que se estructura un cdigo HTML se puede hacer una similitud con el cuerpo humano,
ya que las etiquetas aparecen segn un orden lgico, limitndose qu puede aparecer o no
antes o despus de cada una de ellas, si hacemos la similitud con el cuerpo humano, si se
observa ste de arriba abajo y consideramos sus distintas partes como etiquetas, nunca
aparecer antes la etiqueta 'piernas' que la etiqueta 'cabeza'.
El lenguaje HTML es un estndar, compuesto por recomendaciones publicadas por
World Wide Web Consortium ). Las especicaciones
un consorcio internacional: el W3C (
ociales de HTML describen las "instrucciones" del lenguaje, pero no cmo seguirlas, es
decir, cmo las interpretan los programas informticos. Esto permite visualizar pginas
Web independientemente del sistema operativo o la arquitectura del equipo del usuario.
Sin embargo, pese a lo detallado de las especicaciones, existe margen para la interpretacin por parte del navegador y esta es la razn por la que la misma pgina puede
aparecer de modo diferente en un navegador u otro. Es ms, algunos editores de software
agregan instrucciones HTML exclusivas que no se hallan en las especicaciones de W3C.
68
CAPTULO 3.
Por este motivo, las pginas Web que contienen dichas instrucciones pueden ser vistas en
un navegador, y ser completa o parcialmente ilegibles en otros. Debido a lo anteriormente
expuesto, las pginas Web deben seguir las recomendaciones de W3C, de forma que lleguen
al pblico ms amplio posible.
Para un aprendizaje detallado acerca de HTML se recomienda consultar la especicacin ocial de HTML 4.0112 .
12 Disponible
en http://www.w3.org/TR/html401/
Captulo 4
Desarrollo del sistema
4.1.
Descripcin de ob jetivos
El sistema a desarrollar debe permitir, de manera general, transferir informacin desde

una red de motas ZigBee/802.15.4 hasta una o varias direcciones IP, usando como elemento
intermedio un dispositivo con capacidad de enrutamiento. En las siguientes secciones se
describir con detalle las distintas tareas llevadas a cabo para llevar a buen trmino lo
anteriormente descrito, comenzando por las necesidades puramente hardware necesarias
para la comunicacin entre las motas/sensores y el enrutador, pasando por los distintos
elementos software desarrollados y acabando por la integracin del software con el sistema
operativo elegido para el enrutador, proporcionandose de esta manera un paquete software
completo con todo lo necesario para su funcionamiento en el enrutador desde el mismo
momento de su instalacin sin ms que disponer de los elementos hardware necesarios.
4.1.1.
Requisitos del sistema
Para mostrar una visin ms clara del sistema desarrollado se enumeran a continuacin
los requisitos, tanto funcionales como operacionales, que ejercieron de gua a la hora de
69
70
CAPTULO 4.
DESARROLLO DEL SISTEMA
tomar las distintas decisiones que se fueron llevando a cabo en cada una de las fases del
proyecto.
Requisitos operacionales
Permitir la transferencia de datos procedentes de una red de motas ZigBee/802.15.4,
siendo transparente la informacin transportada en dichos datos, hacia una serie

de direcciones IP especicadas por el usuario.
Conseguir la integracin del desarrollo en el sistema operativo alojado en el
enrutador, de manera que se facilite la instalacin y uso por parte del usuario.
Requisitos funcionales
La base sobre la que se desarrollar el sistema deber ser un sistema operativo
Linux.
Se usar el protocolo UDP.
La aplicacin destinada a ejecutarse en el enrutador para ejercer las tareas de
recogida de datos de la red ZigBee/802.15.4 y, posteriormente, el envo a las

direcciones IP indicadas, deber funcionar en segundo plano.
Las direcciones IP que podrn ser introducidas como destinatarias debern
cumplir con el protocolo IPv4.

El usuario podr aadir o eliminar direcciones IP destino en cualquier momento,
independientemente de si el sistema se encuentra en funcionamiento o no.

El usuario deber ser capaz de visualizar las direcciones IP que se encuentren
actualmente almacenadas como destinatarias de los datos procedentes de la red

ZigBee/802.15.4.
Las direcciones IP introducidas por el usuario debern pasar a travs de una
aplicacin que las valide, evitndose de esta manera errores en el funcionamiento

derivados de la introduccin de direcciones IP incorrectas segn el protocolo
IPv4.
El usuario podr elegir el puerto a travs del cual se enviarn los datos proce-
dentes de la red de sensores y visualizarlo desde la interfaz web.
4.2.
71
CONECTIVIDAD ENTRE DISPOSITIVOS
Los cheros, carpetas y mdulos necesarios para el correcto funcionamiento del
sistema debern crearse o cargarse al encenderse el enrutador, de manera que

la aplicacin pueda ser ejecutada en cualquier momento desde su puesta en
marcha.
El usuario deber tener a su disposicin una interfaz que le permita conocer el
estado actual de la aplicacin en cuanto a su funcionamiento o no.
4.2.
Conectividad entre dispositivos
Como primer paso en el desarrollo de la pasarela ZigBee/802.15.4 - IP se debe conseguir la comunicacin entre la red formada por las motas ZigBee/802.15.4 y el router
especicados1 . Para lograr esta comunicacin se hace uso, por un lado, de la capacidad
de conexiones va USB del router y, por otro, de la posibilidad de replicacin de los datos
intercambiados entre el microcontrolador MSP430 y el procesador CC2480 a travs de la
conexin UART. Gracias a sto, todos aquellos datos procedentes de los distintos sensores ZigBee/802.15.4 que llegan hasta el dispositivo coordinador pueden ser ledos usando
esta interfaz UART. Usando un conversor que permita la comunicacin entre la conexin
UART y la entrada USB del router se conseguir la transmisin de los datos procedentes
de la red de sensores hacia el mismo.
La caracterstica necesaria para la eleccin del conversor fu la existencia de controladores adecuados al sistema operativo basado en un kernel 2.4 elegido para funcionar
en el router. La primera opcin fu la utilizacin del conector USB proporcionado por el
equipo de desarrollo eZ420-RF2480 de Texas Instruments, sin embargo, su uso debi ser
rechazado debido a la imposibilidad de compilar adecuadamente los controladores disponibles, pensados para su funcionamiento en un kernel 2.6 o superior. Consultando distintas
alternativas con mdulos controladores para un kernel 2.4, nalmente se eligi el coversor
TTL-232R-3V3 de FTDI descrito en la subseccin 3.1.2. En la gura 4.1 se muestra el
detalle referente a los distintos pines existentes en el conversor.
1 Tal
y como se indic en la seccin 3.1, se usarn las motas incluidas en el equipo de desarrollo eZ430-
RF2480 de Texas Instruments para la formacin de la red ZigBee/802.15.4 y el

Premium como elemento intermedio entre sta y la red IP.
router
ASUS WL-500G
72
CAPTULO 4.
Figura 4.1: FTDI TTL-232R-3V3: Pin out [18]
Una vez elegido el conversor se ha de determinar la manera en la que ste ha de ser

interconectado al sensor que actuar como dispositivo coordinador de la red. Para ello se
hace uso del esquemtico de conexin entre MSP430 y CC2480 mostrado en la gura 4.2
en el que se especica el signicado de cada uno de los pines de salida del sensor.
Una vez estudiado el esquemtico, se determina que los terminales del conversor y del
sensor han de ser interconectados segn se indica en la tabla 4.1. Se debe tener en cuenta
que todo aquel terminal o pin no usado debe ser convenientemente conectado para evitar
posibles malos funcionamientos.
Terminal del conversor Pin del sensor

Amarillo
Orange
Black
Red
6
1
5
2
Tabla 4.1: Interconexin entre conversor y sensor
4.2.
CONECTIVIDAD ENTRE DISPOSITIVOS
Figura 4.2: Esquemtico de conexin entre MSP430 y CC2480
73
74
4.3.
CAPTULO 4.
Desarrollo de la aplicacin pasarela
En esta seccin se presentan los detalles ms importantes referidos a la aplicacin

principal de este Proyecto Fin de Carrera. Se trata del programa que toma los datos
que llegan al puerto USB y los reenva a las direcciones IP especicadas en el archivo
correspondiente. Dicho reenvo estar siempre supeditado a que la trama de datos recibida
por el puerto USB cumpla con el formato de trama asociado a nuestra pasarela. Si esta
condicin se cumple, los datos sern ledos y pasarn a formar parte de un paquete UDP
(User Datagram Protocol ) que ser encaminado a travs de la interfaz o de las interfaces
correspondiente del router para as poder alcanzar todos los destinos indicados por el
usuario de la aplicacin.
El usuario deber especicar el puerto a travs del cual desea que sean enviados los
datos procedentes de la red de sensores, as como las direcciones IP que actuarn como
destinatarias.
Se debe tener en cuenta que, a la hora de compilar la aplicacin pasarela se usaron dos
compiladores distintos, segn se desease ejecutarla en un ordenador o en el router. As,
para su ejecucin sobre un ordenador, cualquiera de los compiladores de C++ existentes
para Linux es vlido, mientras que para su ejecucin en el router se hizo uso del compilador
cruzado 'mipsel-linux-uclibc-c++'.
4.3.1.
Funciones que componen la aplicacin pasarela
A continuacin se muestran las distintas funciones que componen la aplicacin pasarela,

adems de una breve descripcin de su funcionamiento y sus aspectos ms destacados
referentes a la composicin del cdigo fuente.
4.3.
DESARROLLO DE LA APLICACIN PASARELA
75
void AdecuacionRouter()
Se encarga de la carga de los mdulos necesarios para el correcto funcionamiento del conversor, de la creacin de la estructura de carpetas en el sistema operativo y
de la creacin e inicializacin de los archivos que indican el estado, las direcciones IP
destinatarias y la pgina web que permite la visualizacin de estas direcciones.
int AbrirPuertoSerie (char *dispositivo)

Establece el vnculo con el puerto USB al que se conectar el conversor TTL-232R3V3 de FTDI, determinndose adems su modo de apertura, en este caso de entrada y en
modo binario. Todo lo anterior se establece a travs de:
open(dispositivo,std::ios::in | std::ios::binary)
Por ltimo indicar que devuelve un entero con el descriptor de chero asociado a la
apertura previamente realizada.
void CerrarPuertoSerie (int fd, struct termios cong)

Finaliza el vnculo con el puerto USB previamente establecido a travs de la funcin 'AbrirPuertoSerie'. Para ello se le debe pasar como parmetro el descriptor de chero
devuelto por sta ltima funcin. Como actuacin complementaria, congura el puerto
USB con los mismos parmetros existentes antes de la ejecucin de la aplicacin 'pasarela'
mediante el paso del parmetro 'cong'. Este parmetro ser obtenido al comienzo de la
ejecucin de la pasarela, previamente al cambio de conguracin del puerto USB para
lograr el funcionamiento necesario para el correcto desempeo de la aplicacin 'pasarela'.
Lo anteriormente explicado se ejecuta mediante el siguiente cdigo:
tcsetattr(fd, TCSANOW, &config);
close(fd);
76
CAPTULO 4.
La funcin 'tcsetattr' congura el puerto USB asociado al indicador de chero 'fd' segn lo indicado a travs del parmetro 'cong'. Por ltimo, 'TCSANOW' es una constante
simblica denida en la librera <termios.h> que indica que el cambio de conguracin se
lleve a cabo de manera inmediata.
struct termios CongurarPuertoSerie (int fd, int baudios, int datos, int parada,
int paridad, int tipo_paridad, int modo, int tamano, int temporizador)
Haciendo uso de esta funcin se establece la conguracin del puerto USB desde el
que se leern los datos procedentes del conversor. Tal y como se desprende de los nombres
de los parmetros, la conguracin queda determinada mediante el nmero de smbolos
transmitidos por segundo, los bits de parada, la existencia o no de paridad as como su
tipo, el modo de operacin (cannico o no cannico), el nmero de caracteres adquiridos en
cada lectura y un temporizador entre lecturas sucesivas que para este caso ser establecido
a cero y por lo tanto quedar desactivado.
Todos los datos anteriormente descritos para lograr la conguracin del puerto USB
han de ser introducidos en una estructura especca para tal n, esta estructura es del
tipo struct termios. Este tipo de estructura aporta una interfaz para la conguracin de
los parmetros de comunicacin con dispositivos asncronos. La forma de completar dicha
estructura es la siguiente:
nuevaconfig.c_cflag = baudios|datos|parada|paridad|tipo_paridad|CLOCAL|CREAD;
nuevaconfig.c_lflag = modo;
nuevaconfig.c_cc[VMIN] = tamano;
nuevaconfig.c_cc[VTIME] = temporizador;
Previamente a la ejecucin del cambio de conguracin del puerto USB de obtendr la

conguracin actual del puerto para despus ser devuelto a su estado original una vez terminada la ejecucin de la aplicacin pasarela. Esta conguracin actual es proporcionada
por la funcin 'CongurarPuertoSerie' para luego ser usada por la 'CerrarPuertoSerie'.
4.3.
77
La obtencin y el cambio de conguracin son llevados a cabo por las funciones 'tcgetattr' y 'tcsetattr' respectivamente.
static void Demonizar (void)
Mediante esta funcin se consigue que la aplicacin pasarela sea ejecutada en

background, es decir, como un demonio o servicio. Para ello debe ser invocada al comienzo
de la funcin main. Su funcionamiento consiste en crear un proceso hijo que tiene su propia
copia de datos y cdigo del padre. Adems, redirigir la salida y entrada estndar hacia
'/dev/null'.
Gracias a esto, la ejecucin de la pasarela continuar sigamos o no conectados al router,
sin perjuicio para la ejecucin de otras aplicaciones residentes en l.
void Lectura_y_Envio (int puerto_serie)
En esta funcin se realiza la lectura de la trama recibida en el puerto USB y

posterior reenvo.
Cuando se reciben datos en el puerto USB, se leen los bytes uno a uno. Si el byte
recibido contiene 'FE' se habr detectado el SOF, de esta manera se puede determinar
que el byte que vendr tras SOF ser la longitud del campo de datos. Sabiendo que adems
de los bytes pertenecientes al campo de datos, existen otros tres bytes ms enviados por
los sensores, correspondientes a los campos de comando y FCS, se podr indicar cuantos
bytes debern leerse a continuacin hasta esperar de nuevo a la recepcin de un byte con
el contenido del SOF. El formato de la trama se mostr en la gura 3.4. Para la lectura
de los datos llegados al puerto USB se har uso de la funcin 'RecibirPorPuertoSerie', que
ser explicada a continuacin.
Una vez que se tiene almacenada la trama completa, se procede al envo de la misma a
todos los destinatarios especicados por el usuario. Para ello se sigue un proceso iterativo
en el que se lee el chero en el que se almacenan las direcciones IP, hasta llegar al nal
78
CAPTULO 4.
del mismo. Cada vez que se lea una direccin IP se crear un socket UDP en el que se
incluir la trama procedente del conversor anteriromente leda y que llevar como destino
la direccin IP recien leda.
El proceso anteriormente descrito de recepcin de trama y posterior envo de la misma
a todas las direcciones IP almacenadas como destino ser repetido de manera continuada
mientras no se indique la detencin de la pasarela u ocurra algn error en su ejecucin.
En cuanto al proceso de creacin y envo del socket, se aprecian distintas acciones
necesarias para su correcta ejecucin. En primer lugar deben reservarse recursos para el
socket mediante:
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
Esta funcin devuelve un indicador de socket que ser utilizado para hacer referencia
a l una vez creado. Como parmetros se le pasan tres constantes simblicas. La primera
de ellas, AF_INET, indica que el socket est destinado a su envo a travs de Internet. La
segunda, SOCK_DGRAM, especica el uso de datagramas en lugar del establecimiento
de un circuito virtual para su envo. La tercera y ltima constante simblica pasada como
parmetro, IPPROTO_UDP, indica que se debe usar el protocolo de nivel de transporte
UDP. UDP es el protocolo estndar para el nivel de transporte cuando enviamos datagramas a travs de redes IP por lo que tambin podra haberse pasado como parmetro cero,
de manera que sera el propio sistema operativo el que elegira el protocolo para el envo
de datagramas ms apropiado, que hubiera sido UDP de igual manera.
Una vez que se est seguro de disponer de recursos necesarios para procesar el socket,
se procede a completar la estructura de tipo 'sockaddr_in', especicando en ella la familia
de direcciones a las que podr ser enviado, en este caso direcciones IP, y el puerto a travs
del cual se enviar. Para este propsito se rellena la estructura como sigue:
descr_socket.sin_family = AF_INET;
descr_socket.sin_port = htons(PORT);
4.3.
79
Como ltimo paso, y si todo lo anterior ha sido realizado de manera correcta y sin
errores, se procede al envio del socket descrito, indicando el descriptor de socket para el
que se reservaron recursos, la direccin IP a la que se enva y la descripcin del socket.
Todo se lleva a cabo gracias a:
inet_aton(linea, &descr_socket.sin_addr);
sendto(s, buf, BUFLEN, 0, (struct sockaddr *)&descr_socket, slen);
Siendo la variable 'linea' la direccin IP, 'buf ' la variable donde se almacena el dato
recibido procedente del conversor y 'BUFLEN' su tamao.
int RecibirPorPuertoSerie (int fd, char *buer, int buer_tamano, int num_car,
int reintentos)
Se ocupa de la lectura y almacenamiento de los datos que llegan al puerto USB.

Es llamada desde la funcin 'Lectura_y_Envio'. Lee tantos caracteres como se le indique
a travs del parmetro, en este caso uno. Devuelve el nmero de bytes ledos de forma
correcta.
80
CAPTULO 4.
4.3.2. Diagramas de ujo

El diagrama de ujo asociado a la ejecucin completa de la aplicacin pasarela se
muestra en la gura 4.3.
Figura 4.3: Pasarela: Diagrama de Flujo
4.3.
81
En cuanto a la funcin ms importante includa en la aplicacin pasarela, la que realiza

la tarea de lectura y envo de los datos procedentes de la red de sensores, su diagrama de
ujo se muestra en la gura 4.4.
Figura 4.4: Lectura y envo: Diagrama de Flujo
82
4.4.
CAPTULO 4.
Desarrollo de la interfaz
Para la conguracin, puesta en marcha y detencin de la aplicacin 'pasarela' se

dispone de varios elementos. Por un lado pueden distinguirse aquellos destinados a la vericacin del estado y conguracin actual de la aplicacin y por otro aquellos orientados
a la modicacin de lo anterior. Para ello, las opciones disponibles a travs de la interfaz
desarrollada permiten el inicio y detencin de la aplicacin, la adicin y eliminacin de
direcciones IP destinatarias de los datos procedentes de la red de sensores, la vericacin
del estado de funcionamiento de la pasarela, la visualizacin de las direcciones IP actualmente almacenadas y la introduccin y visualizacin del puerto a travs del cual se realiza
la comunicacin.
En un principio se desarroll toda la estructura de interaccin con la aplicacin 'pasarela' a travs de una interfaz web haciendo uso de CGI, sin embargo, una vez se pas
a la fase de portabilidad para su funcionamiento en el router, surgieron problemas que
imposibilitaron su funcionamiento completo a travs de dicha interfaz web. Estos problemas estn originados por la limitacin, en las versiones actuales disponibles del sistema
operativo DD-WRT, a la hora de usar las variables de entorno asociadas a CGI.
En concreto, para la utilidad que permita la introduccin de direcciones IP destinatarias desde la propia interfaz web, se haca uso del metodo POST de CGI para el paso
de parmetros. De esta manera, mediante la lectura de STDIN, as como de la lectura de
la variable de entorno CONTENT_LENGTH, que informa del nmero exacto de bytes
a leer, y el procesado de los datos con la funcin de descifrado adecuada que tambin se
desarroll, se consegua la adicin de la direccin IP al sistema de reenvo de los datos.
Todo lo anteriormente descrito debi ser sustituido por otra solucin debido a que la
variable de entorno mencionada se encuentra deshabilitada, como muchas otras de CGI,
por motivos de seguridad. Tan solo estn disponibles para la interfaz web includa en
el sistema operativo. Por este motivo, la interaccin se realiza a travs de dos sistemas
distintos. Por un lado se encuentran una serie de acciones accesibles a travs de la interfaz
web y por otro aquellas acciones llevadas a cabo mediante la ejecucin a modo de comando
de distintos programas de tipo shell script.
4.4.
DESARROLLO DE LA INTERFAZ
4.4.1.
83
Interaccin a traves de la interfaz web
La interfaz web puede ser accedida a travs de internet mediante la introduccin de

la URL (Uniform Resource Locator ) correspondiente asociada al router seguida de 'pasarelazb.html'. A modo de ejemplo, y suponiendo que la URL asignada al router sea la
direccin IP 192.168.2.1, el acceso a la pgina principal se consigue introduciendo en el
navegador:
http://192.168.2.1/pasarelazb.html
Una vez se muestre, la primera pgina que aparece da la posibilidad de comprobar si
la pasarela se encuentra en funcionamiento o no, esta primera pgina puede verse en la
FIGURA.
Tras pulsar sobre el enlace que determina el estado de la pasarela, se pasa a la siguiente
pgina asociada a la interfaz. En ella se presentan las siguientes opciones:
Si la pasarela se encuentra en funcionamiento permite detener su ejecucin. Si por el
contrario se encuentra detenida, se nos presenta el enlace y las instrucciones a seguir
para iniciar su ejecucin.
Visualizacin de las direcciones IP que actualmente estan almacenadas como destinatarias de los paquetes procedentes de la red de sensores ZigBee.
Visualizacin del puerto a travs del cual se envan los datos.
En la FIGURA puede apreciarse el aspecto de esta ltima pgina para el caso en el
que la aplicacin se encuentre en funcionamiento.
Para la realizacin de esta interfaz se hizo uso de HTML y CGI,de manera que gracias
a las caractersticas de CGI se leen y modican los cheros correspondientes para despus,
dependiendo de los valores que hayan sido ledos en dichos cheros, mostrar la pgina web
correspondiente. Por ejemplo, en el caso de la primera pantalla que se muestra, al pinchar
84
CAPTULO 4.
sobre el enlace que verica el estado de la pasarela, la aplicacin CGI se encargar de leer
el archivo 'estado' y, una vez ledo su contenido, si almacenaba un uno mostrar la pgina
que permite detener la pasarela o, en el caso de que al archivo ledo almacenara un cero,
mostrar la pgina con las indicaciones que permiten iniciar la pasarela.
Conviene recordar que, a la hora de compilar los archivos cgi se usaron dos compiladores
distintos, segn se desease ejecutarlos en un ordenador o en el router. As, para su ejecucin
sobre un ordenador con un sistema operativo Linux, cualquiera de los compiladores de
C++ existentes para Linux es vlido, mientras que para su ejecucin en el router se hizo
uso del compilador cruzado 'mipsel-linux-uclibc-c++'.
4.4.2.
Interaccin a travs de comandos
Como ya fu comentado en anteriores secciones, la limitacin en el uso de las variables

de estado asociadas a CGI oblig a buscar alternativas que permitieran la interaccin
deseada con la aplicacin 'pasarela'. Para ello fue muy til la utilidad integrada en la
interfaz web proporcionada por el sistema operativo DD-WRT que permite la ejecucin de
comandos y que se muestra en la FIGURA. Estas mismas acciones podran llevarse a cabo
accediendo al router a travs de Telnet, sin embargo, la posibilidad de realizarlo todo sin
necesidad de usar ms que un navegador web resulta ms adecuada para permitir un uso
sencillo a todo tipo de usuarios, independientemente de sus conocimientos informticos.
Para ello se ponen a disposicin del usuario una serie de pequeas soluciones que complementan aquello mostrado o ejecutado a travs del interfaz web asociado a la aplicacin
'pasarela'. Se describen estas soluciones a continuacin:
Pasarelazb: permite el inicio de la ejecucin del programa principal. Est desarrollado
en lenguaje C++.
AnadirIPzb: permite la introduccin de una IP destinataria de paquetes de la red
de sensores. Previamente a su almacenamiento se chequear que la IP introducida
cumple con el estndar IP versin 4. Se trata de un script ejecutado haciendo uso del
intrprete de comandos ASH (A Shell ) contenido en DD-WRT. 'AnadirIPzb' hace
4.5.
CONFIGURACIN INICIAL AUTOMATIZADA
85
uso del script 'creacion_web_destinatarios', que actualiza la pgina a mostrar en

caso de querer visualizar, a travs de la interfaz web, las direcciones IP almacenadas.
EliminarIPzb: permite la eliminacin de la IP situada en la posicin pasada como
parmetro. Dichas posiciones quedan determinadas al visualizar, a travs de la interfaz web, las IP destinatarias. Se trat de un script ejecutado haciendo uso del
intrprete de comandos ASH contenido en DD-WRT. 'EliminarIPzb' hace uso del
ejecutable 'creacion_web_destinatarios', que actualiza la pgina a mostrar en caso
de querer visualizar, a travs de la interfaz web, las direcciones IP almacenadas.
SeleccionPuerto: permite la modicacin del puerto a travs del cual se envan los
datos procedentes de la red de sensores y con destino a las distintas direcciones IP
almacenadas. 'SeleccionPuerto' hace uso del ejecutable 'creacion_web_puerto', que
actualiza la pgina a mostrar en caso de querer visualizar, a travs de la interfaz
web, el puerto que est siendo usado.
4.5. Conguracin inicial automatizada

Para lograr que en cada inicializacin del router todo se encuentre congurado de
manera adecuada para usar la aplicacin pasarela, es imprescindible la creacin de un
script que se ejecute tras cada encendido del router. Hay varias opciones para llevarlo a
cabo, pero en este caso concreto se opt por la creacin de un shell script.
El otro mtodo que poda haberse elegido consiste en almacenar los comandos que se
desean ejecutar en la memoria nvram, sin embargo, dicha opcion no es la ms adecuada
por el uso de memoria ash que requiere. Adems de esta razn, que en este caso no era
crtica pues el script es de pequeo tamao, se debe tener en cuenta la facilidad para
futuras modicaciones, mucho ms accesibles a travs de la opcin nalmente elegida.
Para que el shell script sea ejecutado en cada inicializacin del router, debe elegirse
un nombre seguido de '.startup', en este caso 'pasarelazb.startup', y ser almacenado en el
directorio adecuado, tal y como se detallar en la subseccin 4.6.2.
86
CAPTULO 4.
El shell script desarrollado presenta la estructura que se muestra a continuacin:
#! /bin/ash
touch /tmp/destinatarios.txt
touch /tmp/estado.txt
echo 0 >> /tmp/estado.txt
mkdir /tmp/www
/bin/creacion_web_destinatarios
De esta manera se crearn e inicializarn todos los directorios y archivos necesarios

para poder ejecutar la aplicacin pasarela una vez se ponga en funcionamiento el router. Se
debe aclarar que para su prueba en el entorno compuesto por un ordenador funcionando
bajo un sistema operativo Ubuntu 10.04 el intrprete de comando utilizado fu bash.
4.6.
Integracin en el sistema operativo DD-WRT
Los distintos componentes destinados para funcionar en el router, y que posibilitan

el funcionamiento de la pasarela, han sido compilados junto al sistema operativo DDWRT, de esta manera, bastar instalar en el router el paquete proporcionado y, a falta
de la conexin del conversor al puerto USB, se dispondr del software necesario para el
funcionamiento de la pasarela. Este paquete compilado, como ya se ha mencionado, est
formado por DD-WRT y todos los componentes necesarios para el correcto funcionamiento
de la pasarela, lo que incluye:
Aplicacin principal
Interfaz web
Ejecutables para la interaccin con la aplicacin pasarela a travs de comandos
Mdulos necesarios para la correcta deteccin del conversor
4.6.
INTEGRACIN EN EL SISTEMA OPERATIVO DD-WRT
87
Para compilar todos estos componentes junto al sistema operativo y obtener as una
solucin global y agrupada fueron necesarios tres pasos. En el primero de ellos se llev a
cabo la extraccin del rmware DD-WRT, en el segundo se realizaron las modicaciones
deseadas y en el tercero y ltimo se compil todo de nuevo obtenindose una nica solucin.
Veamos estos pasos con ms detalle.
4.6.1. Extraccin del rmware DD-WRT

Antes de proceder a la extraccin del rmware se debe disponer de una serie de requisitos mnimos para que sea realizada con exito. Estos requisitos son:
Llevarla a cabo sobre uno de los sistemas operativos soportados por la herramienta
de extraccin, a saber: Linux o OS-X. En el caso concreto de este Proyecto Fin
de Carrera, se utiliz como sistema operativo Ubuntu 10.04 ejecutndose sobre un
ordenador portatil DELL Inspiron 1545.
GNU C
GNU C++
Libreras de desarrollo estndar para C y C++
GNU make
Disponiendo de todo lo anterior, se puede pasar a utilizar la herramienta para la extraccin del rmware. Dicha herramienta puede conseguirse desde los repositorios ociales
proporcionados por DD-WRT2 . En el paquete que se obtendr tambin se encontrarn las
herramientas necesarias para la instalacin de paquetes y la posterior reconstruccin del
sistema operativo.
Una vez obtenida la herramienta, se lleva a cabo la extraccin mediante el uso del
comando:
2 Mediante
el comando 'svn checkout http://rmware-mod-kit.googlecode.com/svn/trunk/ rmwaremod-kit-read-only'
88
CAPTULO 4.
./extract_firmware.sh firmware.bin directorio_de_extraccin
Debe indicarse que 'rmware.bin' es el sistema operativo DD-WRT que se pretende extraer3 y 'directorio_de_extraccin' hace referencia al lugar donde se almacenarn
los archivos resultantes de la extraccin. Por timo, indicar que para ejecucin del comando 'extract_rmware.sh' se debe estar dentro del directorio en el que se encuentre la
herramienta.
4.6.2. Modicacin del rmware DD-WRT

Una vez extraido el rmware, el sistema de archivos resultante se encontrar almacenado en el directorio indicado anteriormente. Dicho sistema de archivos se compone de los
siguientes directorios principales:
image_parts: aqu se almacenan archivos intermedios necesarios para futuras reconstrucciones.
rootfs: aqu se encuentra el sistema de archivos que compone DD-WRT, con los
directorios habituales que se encuentran en los sistemas operativos Linux (bin, dev,
etc...). Las modicaciones que se introducirn sern llevadas a cabo todas en este
directorio.
installed_packages: destinado a los paquetes que el usuario desea instalar en el sistema operativo DD-WRT para su uso desde el mismo momento de su instalacin en el
router y que no se encuentran a su disposicin en la versin disponible por defecto.
Para llevar a cabo esto se hace uso de la herramienta 'ipkg_install.sh', obtenida
junto a la herramienta de extraccin en el paquete obtenido desde los repositorios
de DD-WRT.
A continuacin se detallan las modicaciones llevadas a cabo dentro del sistema de
archivos contenido en la carpeta 'rootfs', indicando aquellos directorios en los que se han
aadido elementos y de qu elementos se tratan para cada caso:
3 En este caso DD-WRT versin 24 (build 12188)
4.6.
INTEGRACIN EN EL SISTEMA OPERATIVO DD-WRT
89
bin: se aade el ejecutable destinado a la creacin de la pgina web, los ejecutables

para la interaccin con la aplicqacin mediante el uso de comandos y la aplicacin
principal de la pasarela.
etc/cong: se aade el archivo que se ejecutar en cada encendido del router para
su lograr la adecuada conguracin permitiendo as el correcto funcionamiento de la
aplicacin pasarela una vez que el router se encuentra inicializado.
lib: aadidos los mdulos 'usbserial.o' y 'ftdi_sio.o' para permitir la deteccin y
posterior manejo del conversor conectado al puerto USB usado en este Proyecto Fin
de Carrera.
www: aadida la pagina html que servir como inicio del interfaz web de la aplicacin
pasarela. Adems, se crea dentro la carpeta 'cgi-bin' en la que se almacenarn los
archivos cgi necesarios para la interaccin con los archivos que indican el estado
actual de la pasarela en cuanto a funcionamiento y conguracin.
4.6.3. Reconstruccin del rmware DD-WRT

Por ltimo, una vez extraido el rmware y realizados los cambios que se desean, se
debe volver a crear un paquete nico de manera que pueda ser instalado como un nico
elemento en el router. Para esta acccin se har uso de otra de las herramientas obtenidas
desde los repositorios de DD-WRT, en este caso 'build_rmware.sh'. Para su correcto uso
deber ejecutarse el siguiente comando desde el directorio en el que est almacenada la
herramienta:
./build_firmware.sh directorio_de_salida/ directorio_de_extraccin/
Siendo 'directorio_de_salida' el lugar donde se almacenarn las reconstrucciones del

rmware y 'directorio_de_extraccin' el lugar donde est el sistema de archivos extrado
y posteriormente modicado.
90
CAPTULO 4.
Por ltimo, indicar que la herramienta reconstruir el rmware y presentar diversas

versiones, diferenciadas entre ellas por el hecho de estar optimizadas para su instalacin en
routers de distintos fabricantes. Tambin se incluye una versin reconstruida del rmware
genrica.
4.7.
Aplicacin cargada en los sensores ZigBee/802.15.4
Para poder determinar el correcto funcionamiento de la aplicacin pasarela desarrollada

para el router, se hace imprescindible la carga en los sensores contenidos en el equipo de
desarrollo eZ430-RF2480 de Texas Instruments de una aplicacin que haga uso de la
capacidad de monitorizacin y posterior envo de los datos monitorizados a travs de la
red ZigBee. Dado que la capacidad de los sensores incluidos se basa en la medida de
la temperatura del lugar en el que se encuentren colocados, la aplicacin ZASA (ZigBee
Accelerator Sample Application ), aportada por Texas Instruments a modo de ejemplo de
uso, es ideal para el propsito deseado.
La aplicacin ZASA puede hacer que los sensores acten de dos maneras distintas,
como sumideros o como fuentes de infomacin. Si indicamos esto desde el punto de vista
de su papel en la red, los sensores pueden actuar como los tipos de dispositivos habituales
descritos por la especicacin ZigBee/802.15.4: coordinador, enrutador o dispositivo nal.
De esta manera, los datos recolectados y enviados por aquellos sensores que acten como
fuente de informacin sern el voltaje del bus y la temperatura ambiente. La conguracin
del papel dentro de la red ser determinada en base a la actuacin sobre el botn incluido
en el CC2480 e informada a travs de un cdigo de colores mediante dos indicadores
luminosos. Los sensores se conguran con dos posibles acciones, pulsando el botn incluido
en CC2480 una o dos veces. Se muestran a continuacin las distintas posibilidades:
Si se pulsa el botn una vez en dos segundos intentar congurarse como enrutador
dentro de una red ya existente, actuando adems como fuente de datos, si no existe
tal red, pasar a crear una nueva y se establecer como coordinador, actuando como
sumidero de datos. Lo anteriormente descrito se indicar mostrando el LED rojo
encendido de forma continua en caso de actuar como coordinador o mostrando el
4.7.
APLICACIN CARGADA EN LOS SENSORES ZIGBEE/802.15.4
91
LED verde encendido en caso de actuar como enrutador.

Si se pulsa el botn dos veces en dos segundos, el sensor quedar congurado como
un dispositivo nal y, por lo tanto, actuar como fuente de datos. Esto quedar
indicado a travs del parpadeo del LED de color verde a una frecuencia de 1Hz.
Para completar el cdigo usado a traves de los LED incluidos, caben destacarse los
siguientes casos:
Ambos LED parpadeando indican que el sensor an no ha sido congurado.
En el caso de que los sensores acten como enrutador o dispositivo nal, una vez
que envan un paquete de datos el LED rojo parpadear.
En el caso de actuar el sensor como coordinador, un parpadeo del LED verde indicar
la correcta recepcin de un paquete de datos.
Para adecuar la aplicacin ZASA a ciertas caractersticas propias del desarrollo llevado
a cabo en este Proyecto Fin de Carrera, se han incluido modicaciones en su cdigo que
a continuacin se describen:
El sensor que se conecta al conversor TTL-232R-3V3 de FTDI, y que por lo tanto se
comunica con el router, presenta como nica posibilidad de actuacin dentro de la
red la de dispositivo coordinador. Esto es as porque dicha funcin va directamente
ligada a su conexin con el router y por lo tanto no tiene ningn sentido que se
deba determinar, a travs de la pulsacin del botn, su papel en la red. Adems, de
esta manera se prevn posibles fallos derivados de cortes de luz y reinicios del router
puesto que al estar pensado para su funcionamiento autnomo, el hecho de tener
que estar sicamente presente para la conguracin de este sensor podra hacerle
perder al conjunto la facilidad y comodidad de uso que se pretende. Para conseguir
esta conguracin automtica como coordinador anteriormente descrita se modic
el cdigo incluido en 'sample_app.c', suprimindose el funcionamiento de la funcin
'appBtnPress' para de esta manera deshabilitar la interaccin a travs del botn e
92
CAPTULO 4.
incluyndose la variable 'timerboton' en combinacin con otras llamadas a funciones

para conseguir la conguracin como coordinador que se desea.
Para los sensores que actan como fuentes de datos (ya sean enrutadores o dispositivos nales), se aade un campo en la trama enviada que los identica de manera
fsica, no a travs de la direccin de red que asigna el protocolo basada en la asignacin distribuida de direcciones. De esta manera, se puede identicar a que sensor
corresponde cada paquete recibido sin necesidad de saber cual se conect a la red
en primer lugar, proporcionando un mtodo de identicacin ms claro. Para lograr
este propsito se realizaron los siguientes cambios en 'sample_app.c':
La constante SRCE_REPORT_SZ fue establecida a un valor de tres
Se crea la constante SRCE_REPORT_ZBID con un valor de dos
Por ltimo, estableciendo srceReport[SRCE_REPORT_ZBID] dentro de la
funcin 'appSrceData', se determina el nmero que identicar a cada sensor. Por ejemplo, para establecer el nmero identicativo del sensor a uno, se
debera intoducir en el cdigo:
srceReport[SRCE_REPORT_ZBID] = 1;
Captulo 5
Fase de pruebas
5.1.
Descripcin del entorno de pruebas
Con el objetivo de detectar defectos que causen un funcionamiento no deseado del

desarrollo llevado a cabo en este Proyecto Fin de Carrera se determinaron una serie de
pruebas que los distintos componentes deban ir vericando para de esta manera construir
cada nuevo paso sobre una base slida en lo referente a su funcionamiento. Como entorno
de prueba se usarn dos elementos para la vericacin, variando este entorno segn la fase
del proyecto en la que se ejecutaron las pruebas, como se mostrar ms adelante.
Se pueden diferenciar dos entornos de pruebas:
Ordenador DELL Inspiron 1545, equipado con 4 Gb de memoria RAM y un procesador Intel Core 2 Duo T6400 y funcionando con un sistema operativo Ubuntu
10.04.
Router ASUS WL-500G Premium, funcionando con un sistema operativo DD-WRT.

Haciendo uso de los dos entornos anteriormente descritos se realizarn una serie de
vericaciones que determinarn si el desarrollo cumple con los requisitos operacionales y
93
94
CAPTULO 5.
FASE DE PRUEBAS
funcionales que fueron denidos para el proyecto.
5.2. Procesos de vericacin

El objetivo de los procesos de vericacin es la bsqueda de defectos en el sistema
debidos a errores en el proceso de desarrollo para as evitar la posterior aparicicin de
fallos. Estas actividades de vericacin se llevan a cabo mediantte un conjunto de pruebas,
pudindose utilizar distintos mtodos, para este caso concreto el mtodo usado para la
vericacin ha sido el mtodo a travs de experimentos, esto es, la prueba del sistema
desarrollado mediante la simulacin de las condiciones reales en las que debe desempear
su funcin, observando y analizando su funcionamiento.
Para llevar a cabo el proceso de vericacin se determina una secuanciacin bottomtop, partiendo del correcto funcionamiento de los elementos unitarios y acabando en la
vericacin de la combinacin de todos estos elementos unitarios para dar lugar al sistema
global que se desea.
5.2.1.
Pruebas unitarias
Para el caso de las pruebas unitarias se us el entorno de pruebas constituido por el

ordenador DELL Inspiron 1545, de esta manera, una vez conseguido el correcto funcionamiento de los distintos elementos en este entorno, stos quedaban validados para su
posterior integracin en el sistema mediante la portabiliddad al router ASUS WL-500G
Premium. Igualmente cabe destacar que en este proceso se llevaron a cabo tres tipos de
pruebas:
Pruebas de progresin: la primera prueba que se realiza al elemento.
Pruebas de correccin: repeticin de una prueba tras haber sido detectado un error
y haberse realizado un cambio.
5.2.
PROCESOS DE VERIFICACIN
95
Pruebas de regresin: volver a ejecutar una prueba que ya se haba pasado satisfactoriamente tras realizar un cambio.
Siguiendo la secuenciacin temporal llevada a cabo en el desarrollo se exponen a
continuacin las pruebas unitarias de cada elemento:
Pasarelazb
Para la vericacin de este elemento se hizo uso del ordenador DELL Inspiron
1545 en combinacin con el conversor TTL-232R-3V3 de FTDI y los sensores incluidos
en el equipo de desarrollo eZ430-RF2480 de Texas Instruments. La vericacin se llev
a cabo de forma progresiva, aadiendo las distintas funciones de las que se compone de
manera escalonada segn el siguiente orden:
1. Funciones para el manejo, conguracin y lectura del puerto USB.
2. Funcin destinada al envo de los datos ledos del puerto USB a una direccin IP y
un puerto jos.
3. Adicin de lectura de archivo para indicar la interrupcin de la aplicacin.
4. Adicin de lectura de cheros para permitir la modicacin de las direcciones IP de
destino y del puerto a usar.
5. Funcin que permite la ejecucin 'pasarelazb' en background.
Para llevar a cabo la prueba se conect el conversor al sensor que actua como coordinador por un lado y por el otro se conect a un puerto USB de los disponibles en el
ordenador. Una vez comprobado el puerto que el sistema operativo Ubuntu le asignaba1 y hecha la correspondiente modicacin del mismo en el cdigo fuente se proceda a
la ejecucin del programa habiendo previamente congurado los dems sensores para su
funcionamiento como enrutadores o dispositivos nales.
1
De tipo ttyUSB#
96
CAPTULO 5.
FASE DE PRUEBAS
Una vez se encontraba el programa en funcionamiento y los dispositivos correctamente

congurados se proceda a la comparacin de los datos obtenidos a travs de la aplicacin
'pasarelazb' con los obtenidos gracias a la herramienta Putty (descrita en 3.2.1.5). Para ver
los datos obtenidos por Putty de una manera ms clara se haca uso de un postprocesado
mediante XVI32 (descrito en 3.2.1.6). De esta manera, se fueron ajustando los parmetros
de conguracin asociados al puerto USB hasta conseguir la lectura de los datos tal y
como eran obtenidos a travs de Putty.
As, para poder visualizar los datos ledos a travs del conversor se introdujo en el cdigo
fuente del programa 'pasarelazb' las lneas necesarias para la impresin por pantalla de
todos los caracteres que iban siendo ledos del conversor, de manera que pudiera realizarse
la comparacin anteriormente mencionada. Estas lneas permitan la lectura y correcta
impresin de los datos en formato hexadecimal. Se muestra a continuacin como ejemplo
el cdigo que posibilita la impresin por pantalla del prembulo del paquete enviado desde
el conversor procedente del sensor que actua como coordinador:
cout<<"PREAMBULO: "<<hex<<int(buf[0])<<endl;
Una vez asegurada la correcta recepcin de los datos, se pas al envo de stos a
una direccin ja. Para facilitar la vericacin de los envos se decidi que esta direccin
de destino fuese el localhost. Adems se desarrollar una sencilla aplicacin que actuara
recepcionando estos datos. As, haciendo uso de la visualizacin introducida en 'pasarelazb'
y de esta aplicacin de recepcin se pudo constatar el correcto envo a la direccin IP
indicada. Se muestra a continuacin la parte del cdigo de la aplicacin de recepcin que
permite visualizar lo enviado por la aplicacin 'pasarelazb':
cout<<"Datos procedente de la mota "<<dec<<int(buf[12])<<endl;
cout<<"Temperatura: "<<dec<<int(buf[10])<<" Grados"<<endl;
cout<<"Voltaje: "<<dec<<int(buf[11])<<" V"<<endl;
cout<<"Network address: "<<hex<<int(buf[5])<<hex<<int(buf[4])<<endl;
En este punto se aadi la lectura de un archivo a travs del cual se especica si la

aplicacin debe seguir ejecutndose o no, su chequeo consisti en la modicacin manual
5.2.
97
de dicho chero para determinar la interrupcin de 'pasarelazb' en el momento debido.

Tras lograr la correcta recepcin y posterior envo de los paquetes se aadi la posibilidad de lectura de puerto y direccin IP desde un archivo que poda ser modicado. Con
el objetivo de probar esta adicin se cre el chero de destinatarios con la direccin IP
127.0.0.1 (localhost ) y se us la aplicacin de recepcin anteriormente mencionada de manera que quedara comprobaa la correcta interpretacin de la direccin IP introducida en
el chero. De igual manera y siguiendo el mismo proceso se comprob la correcta lectura
e interpretacin del archivo destinado a indicar el puerto a usar para el envo de los datos.
Por ltimo, se aadi la funcin que permita la ejecucin de todo lo anterior en
background. Comprobando que a pesar de ejecutarse como un demonio segua cumpliendo
todo lo anteriormente vericado.
Shell scripts
Para la vericacin de los shell scripts en el entorno de pruebas indicado se us
bash, incluido por defecto en la instalacin de Ubuntu 10.04, como intrprete de comandos.
Una vez indicado esto, su prueba se bas en comprobar que modicaban, borraban y creaban los directorios y archivos de la manera en la que debian segn los distintos requisitos.
Se detallan a continuacin las distintas vericaciones realizadas en cada shell script :
AnadirIPzb: la vericacin de este script se llevo a cabo comprobando por separado
cada una de las tareas de las que se compone y vericando despus su funcionamiento
conjunto, de esta manera, el orden seguido a la hora de vericar e integrar funciones
dentro del script fu el siguiente:
1. Vericacin de que la direccin IP introducida se compone de cuatro partes.
Para llevar esto a cabo se introducjeron direcciones IP formadas por una,
dos, tres y cinco partes, separadas todas por puntos, comprobndose que todas
ellas eran detectadas como no vlidas. Una vez hecho esto, y tras comprobar que
las direcciones IP formadas por cuatro partes eran clasicadas como vlidas,
98
CAPTULO 5.
FASE DE PRUEBAS
se procedi a comrpobar que tambin eran descartadas todas aquellas direcciones formadas por cuatro partes pero no separadas por un punto, vericndose
tambin este extremo.
2. Vericacin de que todas y cada una de las cuatro partes de las que se compone
la direccin IP introducida estn compuestas tan solo de valores numricos.
Para la vericacin completa de este punto se introdujeron direcciones
IP formadas por cuatro partes y separadas por puntos. De esta manera se
comprobaron las distintas combinaciones en las que alguna o varias de las partes
constituyentes de la direccin IP contenan un valor no numrico. En todos los
casos fu detectado dicho valor y, por lo tanto, clasicadas como direcciones IP
no vlidas.
3. Vericacin de que todas y cada una de los cuatro valores numricos de los
que se compone la direccin IP introducida se encuentran dentro del rango
permitido.
Para la vericacin completa de este punto se introdujeron direcciones
IP formadas por cuatro partes y separadas por puntos. De esta manera se
comprobaron las distintas combinaciones en las que alguna o varias de las partes
constituyentes de la direccin IP contenan un valor numrico por encima de
255. En todos los casos fu detectado dicho valor y, por lo tanto, clasicadas
como direcciones IP no vlidas.
4. Si todo lo anterior se cumple, almacenamiento en el chero correspondiente de
la direccin IP introducida.
La vericacin de este punto consisti en introducir una direccin IP vlida
y comprobar su correcto almacenamiento en el chero indicado.
5. Por ltimo, eliminacin de posibles direcciones IP repetidas dentro del chero.
La vericacin de este punto consisti en introducir de manera consecutiva
dos direcciones IP vlidas iguales y la posterior comprobacin de que solo se
almacenaba una vez en el chero.
Siguiendo este orden, a medida que un objetivo cumpla con los requisitos de
uno de los puntos anteriores se aada el siguiente, partiendo de la base de lo que ya
se haba desarrollado y vericado.
5.2.
99
EliminarIPzb: para vericar este script se hizo uso de 'AnadirIPzb', mediante el

cual se almacenaron varias direcciones IP para, posteriormente y tras seleccionar el
nmero de lnea correspondiente a la direccin IP que se deseaba eliminar, hacer uso
de 'EliminarIPzb' y comprobar que se haba eliminado la direccin IP que ocupaba
el nmero de lnea seleccionado y que, adems, aquellas que ocupaban posiciones
inferiores haban sido desplazadas convenientemente.
SeleccionPuerto: la vericacin de este script se llev a cabo en dos fases que a
continuacin se detallan
1. Vericacin de deteccin de valores no permitidos.
Para la comprobacin de este requisito se desarroll el cdigo necesario
para detectar,y en tal caso desechar, toda aquella introduccin de puerto que
no se trate de un nmero dentro de un rango determinado. Con el objetivo
de probar su funcionamiento se introdujeron valores no numericos

adems de
valores fuera del rango permitido, habindose dettectado en todos los casos y
posibles combinaciones la no validez del valor introducido.
2. Eliminacin del anterior valor almacenado y almacenamiento del valor introducido en caso de ser detectado como vlido.
En este caso se introduca un valor vlido y se comprobaba su correcto almacenamiento. Posteriormente se introduca otro valor tambin vlido, comprobndose que ste ltimo haba sustitudo de manera adecuada al anteriormente
almacenado.
Ejecutables destinados a la creacin de un HTML

Aqu se incluye tanto 'creacion_web_destinatarios' como 'creacion_web_puerto'.
El funcionamiento de los dos es completamente anlogo por lo que el proceso de vericacin seguido con los dos fu el mismo, consistiendo en la vericacin de la correcta
generacin de un archivo con extensin HTML partiendo de los datos almacenados en el
chero correspondiente (aquel que almacena las direcciones IP destinatarias o aquel que
almacena el puerto actualmente seleccionado). La vericacin consisti en introducir en
los cheros una serie de datos haciendo uso de 'AnadirIPzb' o 'SeleccionPuerto' y abrir
100
CAPTULO 5.
FASE DE PRUEBAS
con el explorador Firefox incluido en Ubuntu 10.04 la pgina creada, determinando si lo

visualizado se corresponde con lo almacenado en cada uno de estos archivos.
Interfaz web
Bajo este punto quedan englobadas tanto la pgina 'pasarelazb.html' de inicio de la

interfaz como los ejecutables 'Estado.cgi' y 'Detener.cgi'. Veamos el proceso de vericacin
de cada uno de ellos:
Pasarelazb.html: la vericacin consisti en su visualizacin haciendo uso del explorador Firefox.
Estado.cgi: dado que este ejecutable debe leer un archivo y segn su cobtenido mostrar una pgina u otra, su prueba consisti en la modicacin manual de dicho archivo
y en la vericacin de que semostraba por pantalla la pgina HTML adecuada.
Detener.cgi: este ejecutable debe modicar un archivo y posteriormente mostrar
una pgina HTML. Para su vericacin se comprob la modicacin adecuada del
correspondiente archivo y la visualizacin correcta de la pgina HTML.
5.2.2.
Pruebas de integracin
A la hora de llevar a cabo la integracin de distintos elementos unitarios ya vericados,

se sigui una secuenciacin que permita la deteccin de posibles fallos en dicha integracin
de manera rpida. Las pruebas de integracin y su correcta secuenciacin estn enfocadas
a encontrar problemas de interaccin entre los distintos elementos que van integrndose.
Se detalla a continuacin el plan seguido para la integracin:
1. Lectura por parte de la aplicacin 'pasarelazb' de los archivos modicados por
'AnadirIPzb' y 'SeleccionPuerto'.
2. Posterior adicin de 'EliminarIPzb', siendo el archivo modicado por este script
aquel modicado por 'AnadirIPzb'.
5.2.
101
3. Creacin de los enlaces entre distintas pginas HTML de la interfaz web.

4. Enlace de los ejecutables 'Estado.cgi' y 'Detener.cgi' con los archivos modicados
y/o ledos por 'pasarelazb'.
5.2.3.
Pruebas de sistema
Una vez integrado el sistema, es decir, construido el ltimo nivel de integracin y

realizadas las pruebas de funcionalidad capaces de detectar problemas en los interfaces
entre los distintos elementos unitarios, se pasa a la fase de pruebas del sistema, para
asegurar el cumplimiento de todos los requisitos en el entorno bajo el que debe funcionar.
Una vez hecha la portabilidad de todo lo anteriormente descrito y vericado al router
gracias a la compilacin cruzada y a la construccin del rmware DD-WRT con las adiciones desarrolladas en este Proyecto Fin de Carrera, se pas a la vericacin global del
sistema en el entorno bajo el que debe cumplir con los requisitos. Se detallan a continuacin
los requisitos funcionales que implicaron pruebas de sistema:
Se usar el protocolo UDP.
Una vez ejecutada la aplicacin 'pasarelazb' se haca uso de la aplicacin de
recepcin tambin desarrollada para comprbar el correcto uso del protocolo de transporte UDP.
La aplicacin destinada a ejecutarse en el enrutador para ejercer las tareas de recogida de datos de la red ZigBee/802.15.4 y, posteriormente, el envo a las direcciones
IP indicadas, deber funcionar en segundo plano.
Su vericacin consisti en la ejecucin del ejecutable 'pasarelazb' y, posteriormente, accediendo a travs Telnet comprobacin de que se encontraba en ejecucin
mediante el comando 'ps'.
El usuario podr aadir o eliminar direcciones IP destino en cualquier momento,
independientemente de si el sistema se encuentra en funcionamiento o no.
102
CAPTULO 5.
FASE DE PRUEBAS
Una vez encontrndose el ejecutable 'pasarelazb' en funcionamiento se aadan

y eliminaban direcciones IP, funcionando en todo momento de manera correcta y
variando adecuadamente su funcionamiento en funcin de lo introducido.
El usuario deber ser capaz de visualizar las direcciones IP que se encuentran actualmente almacenadas como destinatarias de los datos procedentes de la red ZigBee/802.15.4.
Su vericacin consisti en la visualizacin de la pgina correspondiente a travs
del acceso remoto al router.
El usuario podr elegir el puerto a travs del cual se enviarn los datos procedentes
de la red de sensores y visualizar el puerto usado desde la interfaz web.
La modicacin del puerto qued vericada haciendo uso de 'SeleccionPuerto'
en combinacin con la aplicacin de recepcin desarrollada, que era programada
para usar el puerto que se introduca y, de esta manera, constatar el correcto uso del
mismo. Posteriormente se procedi a la visualizacin a travs de la interfaz web del
puerto previamente introducido.
Los cheros, carpetas y mdulos necesarios para el correcto funcionamiento del sistema debern crearse o cargarse al encenderse el enrutador, de manera que la aplicacin
pueda ser ejecutada en cualquier momento desde su puesta en marcha.
La aplicacin WinSCP (descrita en 3.2.1.4) permiti vericar que los archivos
y carpetas eran creados en el router tal y como el shell script 'pasarelazb.startup'
indicaba.
El usuario deber tener a su disposicin una interfaz que le permita conocer el estado
actual de la aplicacin en cuanto a su funcionamiento o no.
Esto fue vericado iniciando y deteniendo el ejecutable 'pasarelazb' y conrmando que era mostrado el mensaje correcto segn se encontrar o no en funcionamiento.
Captulo 6
Conclusiones y lneas futuras de trabajo
En el presente captulo se expondrn las conclusiones deducidas del desarrollo de este
Proyecto Fin de Carrera. Adems se mencionarn posibles lneas de investigacin y estudio
que permitiran la continuacin del mismo, permitiendo a otros proyectandos su uso como
base para futuros desarrollos.
6.1.
Conclusiones
Una vez alcanzado el nal en el desarrollo del presente Proyecto Fin de Carrera, pueden
considerarse como superados los objetivos que en el principio del mismo se marcaron y
que a continuacin se detallan:
Realizacin de una pasarela Zigbee/802.15.4-IP sobre un router comercial.
Posibilidad de seleccionar distintas IP destinatarias as como el puerto a travs del
cual se desean enviar los datos procedentes de la red de sensores ZigBee.
Utilizacin, en el router sobre el cual funcionar el desarrollo, de un sistema operativo
de cdigo abierto.
103
104
CAPTULO 6.
CONCLUSIONES Y LNEAS FUTURAS DE TRABAJO
Permitir al usuario la interaccin con la pasarela a travs de una interfaz web, de

manera que no se necesiten conocimientos aadidos a la ya habitual y comunmente
utilizada navegacin en Internet.
Integracin del desarrollo completo en el sistema operativo elegido, quedando todo
congurado e instalado de la manera ms cmoda posible para el usuario.
Adems de los objetivos anteriormente expuestos y exigidos, a ttulo personal se deben
mencionar distintos campos en los que se ha adquirido un conocimiento mayor al haber
sido directamente tratados a lo largo de la realizacin de este Proyecto Fin de Carrera,
estos son:
Estudio del conjunto de soluciones estandarizadas ZigBee/802.15.4.
Manejo y conguracin, a travs del lenguaje C++, de los puertos disponibles en un
dispositivo equipado con un sistema operativo basado en Linux.
Conocimientos bsicos de HTML y scripting.
Aprendizaje de la estructura y de las posibilidades de conguracin y modicacin
del sistema operativo de cdigo abierto DD-WRT.
Conocimientos acerca de los distintos pasos a seguir a la hora de realizar un proyecto
desde cero, desde la fase de documentacin y estudio hasta la realizacin del plan
de pruebas, pasando por el estudio de distintas alternativas y acabando con este
documento.
6.2.
Lneas futuras de traba jo
Como consecuencia del continuo aumento de necesidades relacionadas con la monitorizacin tato en el mbito de la industria, como en el mbito mdico o residencial,
ZigBee/802.15.4, en combinacin con el desarrollo llevado a cabo en este Proyecto Fin
6.2.
LNEAS FUTURAS DE TRABAJO
105
de Carrera, puede cubrir una amplia variedad de estas necesidades. Se detallan a continuacin algunas variantes que, partiendo de este desarrollo, podran aportar soluciones
interesantes:
Aadir comunicacin desde el usuario hacia la red de sensores ZigBee para permitir
cambios en su conguracin. Esta posibilidad implicara casi con total seguridad un
cambio en la eleccin de los sensores, ya que los usados en este desarrollo admiten
una limitada capacidad de conguracin.
Adicin de soporte para direcciones IPv6 ya que el agotamiento de las direcciones
IPv4 har imprescindible su uso en pocos aos.
Integracin total del interfaz web en la misma estructura aadiendo mdulos y utilizando otras opciones de comunicacin entre HTML y los ejecutables como podra
ser PHP.
106
CAPTULO 6.
CONCLUSIONES Y LNEAS FUTURAS DE TRABAJO
Apndice A
Manual de usuario
A.1. Instalacin del sistema operativo en el router
A.1.1.
Actualizacin desde otra versin de DD-WRT
A.1.2.
Instalacin en otros casos
A.2. Conguracin inicial

A.3. Manejo de la interfaz
107
108
APNDICE A.
MANUAL DE USUARIO
Bibliografa
[1] DD-WRT Ocial Web Page. Disponible en http://www.dd-wrt.com/site/index.
[2] ASUS.
WL-500g
Premium
Features.
Disponible
http://www.asus.es/product.aspx?P _ID=8el2DcrRjLoHNdQ8&templete=2.
[3] BlackCode Magazine. A brief programming
en http://mixter.void.ru/rawip.html.
en
tutorial in C for raw sockets. Disponible
[4] Per
Bothner.
Sockets Tutorial.
http://www.linuxhowtos.org/C_C++/socket.htm.
Disponible
en
Estudio de la tecnologa Zigbee y la implementacin en la aplicacin de sensores remotos, 2010. Disponible en
[5] Dora Castaeda, Diana Bacca, and Gustavo Higuera.
http://www.iiis.org/cds2010/cd2010csc/cisci_2010/PapersPdf/ca371me.pdf.
[6] Cristian Castiblanco.

Programacin Shell en Linux.
Disponible en
http://casidiablohost.googlepages.com/ProgramacinenshellLinux.pdf.
[7] H.M. Deitel and P.J. Deitel.
[8] Ata
Elahi
and
Adam
C++ Cmo Programar. Prentice Hall, 1999.

Gschwender.
Bee Wireless Sensor and Control Network,
Introduction to the Zig-
2009.
Disponible
http://www.informit.com/articles/article.aspx?p=1409785&seqNum=4.
en
[9] Jos Toms Entrambasaguas Muoz. Ingeniera de desarrollo de Sistemas de Telecomunicacin. Servicio de Publicaciones e Intercambio Cientco de la Universidad de
Mlaga, 2008.
109
BIBLIOGRAFA
110
[10] Shahin Farahani.
[11] Drew Gislason.
. Elsevier, 2008.
ZigBee Wireless Networks and Transceivers
. Elsevier, 2008.
ZigBee Wireless Networking
[12] Mareca Hatler, Darryl Gurganious, Charley Chi, and Mike Ritter.
A Market Dyna-
. ON World, 2010.
mics report on IEEE802.15.4 and ZigBee
[13] Janell Armstron. C. Richard Helps.
Comparative Evaluation of ZigBee and Blue-
, 2007.
tooth: Embedded Wireless Network Technologies for Students and Designers.
Disponible en http://icee.usm.edu/icee/conferences/asee2007/papers/ 1242_comparative_evaluation_of_zigbee_and_blu.pdf.

[14] Texas
Instruments.
CC2480
Developer
Guide
2008.
Disponible
en
http://focus.ti.com/lit/an/swra176/swra176.pdf.
[15] Jukka Korpela.
, 2010. Disponible en
Getting Started with CGI Programming in C
http://www.cs.tut./jkorpela/forms/cgic.html.
[16] Ed Callaway. Florida Communication Research Lab & Motorola Labs.
Low Power
, November
Consumption Features of the IEEE 802.15.4/ZigBee LR-WPAN Standard.
2003. Disponible en http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf.

[17] Jin-Shyan Lee, Yu-Wei Su, and Chung-Chou Shen.
Wireless
Protocols:
Bluetooth,
UWB,
ZigBee,
and
Comparative
, 2007.
Wi-Fi
Study
of
Disponible en
http://eee.guc.edu.eg/Announcements/Comparaitive_Wireless_Standards.pdf.
[18] Future Technology Devices International Ltd.
TTL-232R-3V3 USB to TTL Serial
, 2006. Disponible en http://eris.liralab.it/viki/images/c/c1/FTDI_-
Converter Cable
_serial_converter_cable_TTL232R.pdf.
[19] Jordi Mayn.
, 2009. Dis-
Estado actual de las Comunicaciones por Radio Frecuencia
ponible en http://www.bairesrobotics.com.ar/data/estado_actual_de_las _comunicaciones_por_radiofrecuencia.pdf.

[20] Daintree Networks.
, 2008. Disponible
Getting Started with ZigBee and IEEE 802.15.4
en http://www.daintree.net/downloads/whitepapers/zigbee_primer.pdf.
[21] Patrice Oehen. ZigBee: An Overview of the Upcoming Standard., October 2005. Disponible en http://www.dcg.ethz.ch/lectures/ws0506/seminar/materials/zb_slides.pdf.
BIBLIOGRAFA
[22] Juan
R.
111
Pozo.
Tutorial
de
2003.
HTML
Disponible
en
http://html.conclase.net/tutorial/html/.
[23] Michael R. Sweet.
, 2005.
Serial Programming Guide for POSIX Operating Systems
Disponible en http://www.easysw.com/mike/serial/serial.html.
[24] IAR Systems.
, 2006.
MSP430 IAR Embedded Workbench ID
[25] Iigo Tejedor and Pello Altadill.
. Disponible
Taller Shell, comandos y programacin
en http://4party.cuatrovientos.org/les/2007/shell_linux.pdf.
[26] Texas Instruments.
Z-Accel
2.4
GHz
ZigBee
Disponible en
Processor
http://focus.ti.com/lit/er/swra175a/swra175a.pdf.
, 2008. Disponi-
eZ430-RF2480 Demonstration Kit: User's Guide
ble en http://focus.ti.com/lit/ug/swru151a/swru151a.pdf.
CC2480 Target Board Reference Design 1.4
http://www.ti.com/litv/zip/swru156a.
[29] TIOBE Software.
. Dis-
TIOBE Programming Community Index for December 2010
ponible en http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html.
[30] Jorge Carlos Valverde Rebaza.
El Estndar inalmbrico ZigBee
http://www.seccperu.org/les/ZigBee.pdf.

Zigbbe

Transféré par

Informations du document

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

Zigbbe

Transféré par

Droits d'auteur :

Formats disponibles



72(; #+%11.%/(,2+(!+1#+,2+%%1!( %!!2(1%

Industrial, Scientic and Medical

International Organization for Standardization

Link Quality Indication

Low Rate Wireless Personal Area Network

Medium Access Control

Microprocessor without Interlocked Pipeline Stages

Open Systems Interconnection

Service Access Point

Secure Copy Protocol

Serial Peripheral Interface

Secure Services Provider

Personal Area Network

Reduced Instruction Set Computer

Physical layer conversion Protocol Data Unit

Universal Asynchronous Receiver-Transmitter

User Datagram Protocol

Uniform Resource Locator

Universal Serial Bus

World Wide Web Consortium

Wide Area Network

Web Hypertext Application Technology Working Group

Wireless Local Area Network

Wireless Personal Area Network

ZigBee Accelerator Sample Application

2.2.4. Capa MAC IEEE 802.15.4 . . . . . . . . . . . . . . . . . . .

3. Componentes y tecnologas utilizadas

3.1. Elementos hardware . . . . . . . . . . . . . . . . . . . . . . . . .

4.1. Descripcin de objetivos . . . . . . . . . . . . . . . . .

5.1. Descripcin del entorno de pruebas

6. Conclusiones y lneas futuras de trabajo

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

A.1. Instalacin del sistema operativo en el router . . . . . . . . . . . . . . . . . 107

A.1.1. Actualizacin desde otra versin de DD-WRT

mbitos de aplicacin de distintas tecnologas [30] . . . . . . . . . . . . . .

Logotipo ZigBee [21]

Arquitectura de la pila ZigBee/802.15.4 [20]

Tramas y empaquetamiento ZigBee [30] . . . . . . . . . . . . . . . . . . . .

Topologa en estrella [8]

Topologa en rbol o jerrquica [8] . . . . . . . . . . . . . . . . . . . . . . .

Topologa en rbol agrupado [8] . . . . . . . . . . . . . . . . . . . . . . . .

Topologa Mallada [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Canales IEEE 802.15.4 [20] . . . . . . . . . . . . . . . . . . . . . . . . . . .

Estructura supertrama [11] . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.10. Descubrimiento de ruta [20]

2.11. Encaminamiento jerquico [20] . . . . . . . . . . . . . . . . . . . . . . . . .

Distribucin de protocolos CC2480-MSP430 [26] . . . . . . . . . . . . . . .

Formato de trama intercambiada entre CC2480 y MSP430

FTDI TTL-232R-3V3 [18]

Asus WL 500G Frontal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Asus WL 500G Trasera . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ASUS WL-500G Premium Interior

3.11. Eclipse: Pantalla Principal . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.10. DD-WRT: Interfaz Web

3.13. Putty: Pantalla Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.14. XVI32: Ejemplo de cambio de formato

3.15. Lenguages de Programacin: Distribucin de uso [29]

FTDI TTL-232R-3V3: Pin out [18]

Esquemtico de conexin entre MSP430 y CC2480 . . . . . . . . . . . . . .

Pasarela: Diagrama de Flujo . . . . . . . . . . . . . . . . . . . . . . . . . .

Lectura y envo: Diagrama de Flujo . . . . . . . . . . . . . . . . . . . . . .

Comparativa de tecnologas inalmbricas [17] . . . . . . . . . . . . . . . . .

ZigBee 2006 y PRO: Caractersticas destacadas [20] . . . . . . . . . . . . .

72(; #+%11.%/(,2+(!+1#+,2+%%1!( %!!2(1%

Industrial, Scientic and Medical

El mercado de ambos estndares est creciendo de forma signicativa en los ltimos

2.1.3. Certicacin de un dispositivo ZigBee

Estrella: se compone de un dispositivo coordinador y varios dispositivos nales, tal

Mallada: consiste en una malla de enrutadores y dispositivos nales interconectados.