������������������ �� �������� ��������������������
���� ���������������
� ��������������� � ���������������������������
� �������������� ��������
������������ ��
����� �����������������
������������� �������� ���������
������������������ �� �������� ��������������������
���� ���������������
��� !∀#�∃%���%&∋%�∋()∀�∗∋��∋!∋#+, %�#∀#�∃%
∋ %�∗+�∋!��(�− %∀!�∋.∀,�%∀∗+(�∋%�∋!�∗)∀�∗∋�!∀�/∋#0∀��#+%1��� �∗+�2+(�
�3�44444444444444444444444444444444444444444444444444444444444444
�3�44444444444444444444444444444444444444444444444444444444444444
�3�44444444444444444444444444444444444444444444444444444444444444
2∀(∀�5 6&∀(�∋!��(+7∋#�+���%�∗∋��∀((∋(∀���� !∀∗+�
�������������������������
� �������������� ��������
������������ ��
∗∋!�∀! ,%+��3��∀8�∗��∋(%9%∗∋6��)∋6
∗�(�&�∗+�2+(��3��∗ ∀(∗+��∀1�!∀(���:(∋6
��� ����� ��4444444444444444���� �� ������������������
44444444444444444444444444444444444444444444444444444444444444
7��2∀(∀�; ∋�#+%1�∋��1∋�∋.��∋%∗∋�/�(,∀∗∀�2+(�!+1�#+,2+%∋%�∋1�∗∋!��(�− %∀!��!∀�2(∋1∋%�∋∗�!�&∋%#�∀3
�9!∀&∀��∀�4444∗∋44444444444444∗∋�����
������!<�∀��(∋1�∗∋%�∋<∀� ����!<�∀��∋#(∋�∀(�+<∀� �!<�∀��+#∀!�
�∗+3�444444444444444 �∗+3�444444444444444 �∗+3�444444444444444
������������������ �� �������� ��������������������
���� ���������������
�������������������������
� �������������� ��������
������������ ��
����������� �
�∀8�∗��∋(%9%∗∋6��)∋6
�� �������� �
�∗ ∀(∗+��∀1�!∀(���:(∋6
���� ������������∋#%+!+&)∀��!∋#�(∃%�#∀3
������������%&∋%�∋()∀�∗∋��∋!∋#+, %�#∀#�∃%
����= ����������2∀1∀(∋!∀����&=∋∋��>����?�≅�����������������≅>������≅Α�
��������%�∋1�∋�2(+7∋#�+�1∋�(∋∀!�6∀� %�∋1� ∗�+�∗∋�!∀1�#∀(∀#�∋()1��#∀1�∗∋!�#+%5 %�+�∗∋�1+! #�+%∋1�∋1�∀%∗∀(�6∀∗∀1���&=∋∋<>��3�?3≅�7�1∋�∗∋1∀((+!!∀� %∀�2∀1∀(∋!∀�; ∋�2+1�−�!��∀�!∀��(∀%1/∋(∋%#�∀�∗∋�∗∀�+1�∗∋1∗∋�!∀�(∋∗�#+,2 ∋1�∀�2+(�!+1�1∋%1+(∋1���&=∋∋<>��3�?3≅�0∀1�∀� %∀�1∋(�∋�∗∋�∗�(∋##�+%∋1����∋12∋#�/�#∀∗∀1�2+(�∋!� 1 ∀(�+3
�9!∀&∀���%∋(+�∗∋�����
����� !∀#∀ ∃%&∋
Acrónimos
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 für 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, Scienti�c and Medical
ISO International Organization for Standardization
JTAG Joint Test Action Group
LQI Link Quality Indication
LR-WPAN Low Rate Wireless Personal Area Network
MAC Medium Access Control
MIPS Microprocessor without Interlocked Pipeline Stages
MCU MicroController Unit
OSI Open Systems Interconnection
SAP Service Access Point
SCP Secure Copy Protocol
SFTP SSH File Transfer Protocol
SOF Start Of Frame
SPI Serial Peripheral Interface
SSH Secure SHell
SSP Secure Services Provider
PAN Personal Area Network
PPDU Physical layer conversion Protocol Data Unit
RISC Reduced Instruction Set Computer
UART Universal Asynchronous Receiver-Transmitter
UDP 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 ZigBee Accelerator Sample Application
ZDO ZigBee Device Object
iv
Índice general
1. Introducción 1
1.1. Ubicación tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Tecnologías inalámbricas de corto alcance: ZigBee o Bluetooth . . . . . . . 2
1.3. El papel de ZigBee/802.15.4 en el futuro de las comunicaciones . . . . . . . 5
1.4. Motivación y objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. ZigBee/802.15.4 9
2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Evolución de las redes inalámbricas de área personal . . . . . . . . 9
2.1.2. IEEE 802.15.4 y ZigBee . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3. Certi�cación de un dispositivo ZigBee . . . . . . . . . . . . . . . . . 12
2.1.4. Arquitectura de ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.5. Versiones de ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.6. Empaquetamiento, direccionamiento y acceso al canal . . . . . . . . 15
2.2. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1. Tipos de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2. Topología de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3. Capa física IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3.1. Detección de energía recibida (ED) . . . . . . . . . . . . . 25
2.2.3.2. Indicador de calidad de enlace (LQI) . . . . . . . . . . . . 25
2.2.3.3. Evaluación de canal libre (CCA) . . . . . . . . . . . . . . 26
2.2.3.4. Formato de PPDU . . . . . . . . . . . . . . . . . . . . . . 26
2.2.3.5. Características que reducen el consumo energético en la
capa física . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
v
vi ÍNDICE GENERAL
2.2.4. Capa MAC IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.4.1. Estructura de supertrama (Modo balizado) . . . . . . . . 28
2.2.4.2. Modelo de transferencia de datos . . . . . . . . . . . . . . 29
2.2.4.3. Inicialización y mantenimiento de una PAN . . . . . . . . 30
2.2.4.4. Unión a una red ZigBee . . . . . . . . . . . . . . . . . . . 31
2.2.4.5. Sincronización . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.4.6. Formato de la trama MAC . . . . . . . . . . . . . . . . . 32
2.2.4.7. Características que reducen el consumo energético en la
capa MAC . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3. ZigBee Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1. Capa de Red ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1.1. Reincorporación a la red . . . . . . . . . . . . . . . . . . . 33
2.3.1.2. Enrutamiento ZigBee . . . . . . . . . . . . . . . . . . . . . 34
2.3.1.3. Características que reducen el consumo energético en la
capa de red . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.2. Capa de Aplicación ZigBee . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.2.1. Per�les de aplicación, grupos y endpoints . . . . . . . . . 37
2.4. Seguridad en ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3. Componentes y tecnologías utilizadas 41
3.1. Elementos hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.1. Equipo de desarrollo eZ430-RF2480 de Texas Instruments . . . . . 41
3.1.2. Conversor TTL-232R-3V3 de FTDI . . . . . . . . . . . . . . . . . . 46
3.1.3. Router ASUS WL-500G Premium . . . . . . . . . . . . . . . . . . . 48
3.2. Elementos software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1.1. DD-WRT . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1.2. Entorno de desarrollo Eclipse . . . . . . . . . . . . . . . . 55
3.2.1.3. MSP430 IAR Embedded Workbench . . . . . . . . . . . . 56
3.2.1.4. WinSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.1.5. Putty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2.1.6. XVI32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.2. Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
ÍNDICE GENERAL vii
3.2.2.1. C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.2.2. CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.2.3. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4. Desarrollo del sistema 69
4.1. Descripción de objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.1. Requisitos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2. Conectividad entre dispositivos . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3. Desarrollo de la aplicación pasarela . . . . . . . . . . . . . . . . . . . . . . 74
4.3.1. Funciones que componen la aplicación pasarela . . . . . . . . . . . . 74
4.3.2. Diagramas de �ujo . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.4. Desarrollo de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.1. Interacción a traves de la interfaz web . . . . . . . . . . . . . . . . 83
4.4.2. Interacción a través de comandos . . . . . . . . . . . . . . . . . . . 84
4.5. Con�guración inicial automatizada . . . . . . . . . . . . . . . . . . . . . . 85
4.6. Integración en el sistema operativo DD-WRT . . . . . . . . . . . . . . . . 86
4.6.1. Extracción del �rmware DD-WRT . . . . . . . . . . . . . . . . . . . 87
4.6.2. Modi�cación del �rmware DD-WRT . . . . . . . . . . . . . . . . . 88
4.6.3. Reconstrucción del �rmware DD-WRT . . . . . . . . . . . . . . . . 89
4.7. Aplicación cargada en los sensores ZigBee/802.15.4 . . . . . . . . . . . . . 90
5. Fase de pruebas 93
5.1. Descripción del entorno de pruebas . . . . . . . . . . . . . . . . . . . . . . 93
5.2. Procesos de veri�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.2. Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.3. Pruebas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6. Conclusiones y líneas futuras de trabajo 103
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2. Líneas futuras de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
A. Manual de usuario 107
A.1. Instalación del sistema operativo en el router . . . . . . . . . . . . . . . . . 107
viii ÍNDICE GENERAL
A.1.1. Actualización desde otra versión de DD-WRT . . . . . . . . . . . . 107
A.1.2. Instalación en otros casos . . . . . . . . . . . . . . . . . . . . . . . 107
A.2. Con�guración inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
A.3. Manejo de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Bibliografía 109
Índice de �guras
1.1. Ámbitos de aplicación de distintas tecnologías [30] . . . . . . . . . . . . . . 3
2.1. Logotipo ZigBee [21] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Arquitectura de la pila ZigBee/802.15.4 [20] . . . . . . . . . . . . . . . . . 13
2.3. Tramas y empaquetamiento ZigBee [30] . . . . . . . . . . . . . . . . . . . . 15
2.4. Topología en estrella [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5. Topología en árbol o jerárquica [8] . . . . . . . . . . . . . . . . . . . . . . . 22
2.6. Topología en árbol agrupado [8] . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7. Topología Mallada [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8. Canales IEEE 802.15.4 [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9. Estructura supertrama [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.10. Descubrimiento de ruta [20] . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.11. Encaminamiento jeráquico [20] . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1. Contenido eZ430-RF2480 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2. Conexión CC2480-MSP430 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3. Distribución 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
3.10. DD-WRT: Interfaz Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.11. Eclipse: Pantalla Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
ix
x ÍNDICE DE FIGURAS
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 Programación: Distribución de uso [29] . . . . . . . . . . . . 63
4.1. FTDI TTL-232R-3V3: Pin out [18] . . . . . . . . . . . . . . . . . . . . . . 72
4.2. Esquemático de conexión entre MSP430 y CC2480 . . . . . . . . . . . . . . 73
4.3. Pasarela: Diagrama de Flujo . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.4. Lectura y envío: Diagrama de Flujo . . . . . . . . . . . . . . . . . . . . . . 81
Índice de tablas
1.1. Comparativa de tecnologías inalámbricas [17] . . . . . . . . . . . . . . . . . 4
2.1. ZigBee 2006 y PRO: Características destacadas [20] . . . . . . . . . . . . . 16
3.1. Características Asus WL-500G Premium [2] . . . . . . . . . . . . . . . . . 48
3.2. DD-WRT: Utilidades principales [1] . . . . . . . . . . . . . . . . . . . . . . 53
4.1. Interconexión entre conversor y sensor . . . . . . . . . . . . . . . . . . . . 72
xi
xii ÍNDICE DE TABLAS
Capítulo 1
Introducción
1.1. Ubicación tecnológica
Los consumidores descubren día a día que la interconexión de sistemas empotrados
permite un mayor y más �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 cámaras, teléfonos móviles y un largo etcétera son ya una realidad. Por todo ello,
el próximo requisito en estos dispositivos será la posibilidad de comunicarse con objetos
que hasta ahora no poseían esas capacidades de comunicación, como electrodomésticos o
automóviles. Tanto ZigBee, basado en el estándar 802.15.4 del IEEE (Institute of Electrical
and Electronics Engineers), como Bluetooth, basado en el estándar 802.15.1 del IEEE,
dan respuesta a ésto. Cada estándar IEEE de�ne una capa física y una pila de protocolos
distinta, operando ambos dentro de la banda ISM (Industrial, Scienti�c and Medical).
A pesar de sus similitudes, ZigBee y Bluetooth no son intercambiables como soluciones
tecnológicas 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 CAPÍTULO 1. INTRODUCCIÓN
1.2. Tecnologías inalámbricas de corto alcance: ZigBee
o Bluetooth
Bluetooth sobrepasa a ZigBee en velocidad de transferencia, posibilidades de interco-
nexión, capacidad para evitar las interferencias en frecuencia y estandarización de per�les
de aplicación. Bluetooth es ideal para transferencia de archivos e intercambio de datos, y
más adecuado para la comunicación de ordenadores con periféricos.
En resumen, se puede determinar que si la aplicación necesita de forma predominante
alguna de las siguientes características, se debe elegir un dispositivo Bluetooth:
Imprescindible si se necesita:
• Intercambio de datos en tiempo real (audio o vídeo streaming)
• Calidad de servicio garantizada
Opción más adecuada si se necesita:
• Identi�cación 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 duración de la batería de los
dispositivos y es más robusto en caso de fallos de sensores en la red. ZigBee es la mejor
alternativa para aplicaciones que necesiten la trasferencia de pequeños paquetes sin una
periodicidad de�nida a través de redes malladas.
En resumen, se puede determinar que si la aplicación necesita de forma predominante
alguna de las siguientes características, se debe elegir un dispositivo ZigBee:
Imprescindible si se necesita:
1.2. TECNOLOGÍAS INALÁMBRICAS DE CORTOALCANCE: ZIGBEE O BLUETOOTH3
• Capacidad para la interconexión simultánea de cientos de dispositivos.
• Enrutamiento multisalto de mensajes hacia un dispositivo localizado más allá
del rango de trasmisión directa del dispositivo transmisor.
Opción más adecuada si se necesita:
• Monitorización de múltiples dispositivos.
El mercado de ambos estándares está creciendo de forma signi�cativa en los últimos
años, presentando ambas opciones diferentes, pero en parte solapados, dominios de apli-
cación. A pesar de haberse descritos solo estas dos opciones, se deben mencionar otras
tecnologías que también pueden coincidir parcialmente en cuanto a su dominio de apli-
cación, tales como Ultra Wide Band, Wi-Fi1 o la red de telefonía móvil. En la �gura 1.1
podemos ver reprentado dicho solape entre las tecnologías anteriormente mencionadas.
Figura 1.1: Ámbitos de aplicación de distintas tecnologías [30]
1Aunque se pensaba que el término viene de Wireless Fidelity como equivalente a Hi-Fi, High Fidelity,que se usa en la grabación de sonido, realmente la Wireless Ethernet Compatibility Alliance contrató auna empresa de publicidad para que le diera un nombre a su estándar, de tal manera que fuera fácil deidenti�car y recordar.
4 CAPÍTULO 1. INTRODUCCIÓN
Se muestra a continuación en la tabla 1.1 una comparación entre las tecnologías ante-
riomente mencionadas:
Estándar ZigBee Bluetooth
3.0
Ultra Wide
Band
Wi-Fi
Especificación
IEEE
802.15.4 802.15.1 802.15.3a 802.11a/b/g
Banda de
Frecuencias
868/915 MHz;
2.4 GHz
2.4 GHz 3.1-10.6 GHz 2.4 GHz;5 GHz
Tasa de
Transferencia
Máxima
250 Kb/s 1 - 24 Mb/s 110 Mb/s 54 Mb/s
Alcance 70m 100m 10m 100m
Número de
canales
1/10; 16 79 (1-15) 14
Ancho de Banda
de Canal
0.3/0.6 MHz; 2
MHz
1 MHz 500MHz-7.5 GHz 22MHz
Tipo de
Modulación
BPSK
(+ASK),
O-QPSK
GFSK BPSK, QPSK BPSK, QPSK,COFDM,
CCK, M-QAM
Ensanchamiento DSSS FHSS DS-UWB,
MB-OFDM
DSS, CCK, OFDM
Mecanismo de
Coexistencia
Selección
Dinámica de
Frecuencia
Salto de
Frecuencia
Adaptativo
Salto de
Frecuencia
Adaptativo
Selección Dinámica deFrecuencia
Control de Potencia
Transmitida (802.11h)
Número Máximo
de sensores
> 65000 8
(para unapiconet)
8
Tabla 1.1: Comparativa de tecnologías inalámbricas [17]
1.3. EL PAPEL DE ZIGBEE/802.15.4 EN EL FUTURO DE LAS COMUNICACIONES5
1.3. El papel de ZigBee/802.15.4 en el futuro de las
comunicaciones
En los próximos años es muy probable que ZigBee vea incrementado su uso ya que
sus características se adaptan a los requerimientos necesarios para un amplio rango de
soluciones, destacándose las siguientes:
Automatización de tareas en el hogar
Aplicaciones para el ahorro de energía
Aplicaciones destinadas a las telecomunicaciones
Si se toma como referencia el tamaño de la pila de protocolos, el de ZigBee, en torno
a 32KB, es aproximadamente una tercera parte del tamaño de la pila de otros protocolos
de comunicaciones inalámbricos.
Además, para dispositivos �nales, este tamaño 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 rápido desarrollo de aplicacio-
nes y, por lo tanto, una mayor capacidad de adaptación al rápido cambio al que se ven
sometidos los productos tecnológicos.
Por todo lo anterior, junto a otras razones que se detallarán en sucesivos capítulos,
ZigBee/802.15.4 ha sido adoptado ya por multitud de empresas y se prevé que en los
próximos años pueda aprovecharse todo su potencial.
6 CAPÍTULO 1. INTRODUCCIÓN
1.4. Motivación y objetivos del proyecto
En el contexto de una sociedad en continuo movimiento y con capacidad de conexión
a internet allá donde se encuentre, la posibilidad de poder acceder a información o no-
ti�cación de eventos concretos en ambientes personales (como puede ser el residencial)
se hace cada vez más útil, necesario e incluso demandado por los consumidores. Por ello,
considerando el tipo de información a noti�car como de periodicidad no determinada y con
amplios intervalos de tiempo entre comunicaciones sucesivas, la elección de ZigBee para la
red de control se convierte en una elección acertada. Una vez decidido esto, y teniendo en
cuenta la �exibilidad, expansión y cobertura de las redes basadas en IP (Internet Protocol)
en todo el mundo, la combinación de redes de sensores ZigBee con la red IP se vislumbra
como una solución de un gran atractivo con unas posibilidades interesantes.
Por ello, el objetivo de este proyecto es la creación de una pasarela entre una red
ZigBee/802.15.4 e IP, usando un router comercial a modo de ejemplo de aplicación. Se
elige como información a transmitir la temperatura en el lugar de colocación del sensor
ZigBee. La �nalidad será conseguir que dicha información pueda llegar hasta una o varias
direcciones IP, con�gurables mediante una interfaz web.
1.5. Estructura del documento
El documento que a continuación se presenta está dividido en siete capítulos, quedando
organizado como a continuación se detalla:
Capítulo 1: Introducción
Breve presentación de ZigBee/802.15.4 y comparativa con otras posibilidades para
las comunicaciones inalámbricas. Justi�cación de la utilidad de este Proyecto Fin de
Carrera
Capítulo 2: ZigBee/802.15.4
1.5. ESTRUCTURA DEL DOCUMENTO 7
Descripción detallada de ZigBee/802.15.4 por ser considerado el estándar más nove-
doso y quizás desconocido de los que se usan para este Proyecto Fin de Carrera.
Capítulo 3: Componentes y tecnologías utilizadas
Recopilación de las herramientas hardware y software que se hicieron imprescindibles
para llevar a cabo este desarrollo.
Capítulo 4: Desarrollo del sistema
Detalle de las decisiones adoptadas y desarrolladas así como descripción de todos los
elementos que la integran.
Capítulo 5: Fase de pruebas
Descripción del proceso a través del cual se ha conseguido asegurar el correcto fun-
cionamiento de la solución desarrollada.
Capítulo 6: Conclusiones y líneas futuras de trabajo
Presentación de las conclusiones obtenidas tras la elaboración de este Proyecto Fin
de Carrera, así de como posibles mejoras o líneas distintas de trabajo que pueden
seguirse tomando este desarrollo como punto de partida.
Capítulo 7: Manual de usuario
Breve guía que detalla los pasos a seguir para lograr el correcto funcionamiento de
la pasarela, partiendo de la instalación en el router y terminando en la puesta en
marcha y posterior recepción de paquetes de datos en un dispositivo remoto con
acceso a internet.
8 CAPÍTULO 1. INTRODUCCIÓN
Capítulo 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 través del conjunto de soluciones
estandarizadas ZigBee/802.15.4 para poder entender tanto sus fundamentos básicos, como
las causas que lo han hecho tan prometedor en los últimos años con la llegada de la
domótica.
2.1. Introducción
2.1.1. Evolución de las redes inalámbricas de área personal
Las redes celulares pueden ser consideradas la extensión lógica y natural de las redes
telefónicas por cable. Conforme fueron aumentando tanto las necesidades de movilidad
como el coste de instalación de las redes cableadas, la idea de lograr conexiones personales
independientemente de la localización del usuario también progresó.
Durante la década de los 80, se pasó de la búsqueda de células capaces de proporcionar
áreas de cobertura de hasta decenas de kilómetros, al interés por células con menor área de
cobertura a cambio de una mayor capacidad para grandes densidades de usuarios. Es en
9
10 CAPÍTULO 2. ZIGBEE/802.15.4
este último punto donde se enmarca el grupo de trabajo IEEE 802.11, en la investigación
y estandarización de redes WLAN (Wireless Local Area Network).
Sin embargo, mientras IEEE 802.11 se centra en proporcionar altas tasas de datos a
distancias típicas de decenas de metros, las WPAN (Wireless Personal Area Network)
tienen como principal objetivo dar servicio en el entorno próximo a una persona u objeto,
buscando ante todo lograr dispositivos de bajo coste, bajo consumo y pequeño tamaño.
El grupo de trabajo IEEE 802.15 surge como respuesta a estos requisitos. Este grupo
ha de�nido tres clases de WPAN diferenciadas por sus tasas de transferencias de datos,
consumo energético 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,
están destinadas al manejo de un amplio rango de aplicaciones, como las destinadas a
teléfonos móviles, 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, médico o residencial de bajo consumo
de energía y bajo coste.
2.1.2. IEEE 802.15.4 y ZigBee
ZigBee es un protocolo de interconexión inalámbrico de baja tasa de transferencia
de datos, bajo coste y reducido consumo energético orientado hacia la automatización y
control remoto de aplicaciones. No se trata de una tecnología, sino de un conjunto es-
tandarizado de soluciones que pueden ser implementadas por cualquier fabricante. ZigBee
está promovido por la ZigBee Alliance, asociación creada en 1998 y que, según un informe
reciente de ON World [12], ha sido adoptada por más de 350 fabricantes globales, que
trabajan de forma conjunta para lograr un estándar global y abierto, contando ingresos
anuales que sobrepasan el billon de dólares estadounidenses.
La especi�cación 1.0 de ZigBee se aprobó el 14 de Diciembre de 2004, estando disponible
para miembros de ZigBee Alliance. Dicha especi�cación se divide en distintos niveles,
2.1. INTRODUCCIÓN 11
accesibles según la categoria adoptada por el suscriptor.
Mientras, y en paralelo, el grupo IEEE 802.15.4 había continuado con su trabajo cen-
trado en las WPAN de baja tasa de transferencia de datos el cual comenzó poco tiempo
después de la formación de ZigBee Alliance. Más tarde, ZigBee Alliance e IEEE decidie-
ron uni�car esfuerzos y criterios, optándose por ZigBee como nombre comercial para la
solución tecnológica.
Como ya se apuntó anteriormente, ZigBee está indicado como solución de bajo coste y
bajo consumo de energía para la interconexión inalámbrica de dispositivos que necesiten
un largo ciclo de duración de la batería, pudiendo ir de varios meses a varios años. Además,
ZigBee puede ser implementado en redes malladas de un tamaño 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
aplicación, 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 unión, IEEE y ZigBee Alliance han trabajado en colaboración para especi�car
la pila de protocolos. IEEE 802.15.4 se centró en la especi�cación de las dos capas inferiores
del protocolo, las capas física y MAC (Medium Access Control), mientras que ZigBee
Alliance tuvo como objetivo la de�nición de las capas superiores, desde la capa de red
hasta la capa de aplicación, ambas inclusive. Esta arquitectura puede verse en la �gura
2.2. Además, ZigBee Alliance se ocupó de de�nir una serie de aplicaciones de control
destinadas al ámbito residencial y de la construcción, 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 evolución de ZigBee.
12.4 Ghz en todo el mundo, 915 MHz en América y 868 MHz en Europa
12 CAPÍTULO 2. ZIGBEE/802.15.4
2.1.3. Certi�cación de un dispositivo ZigBee
Para que un producto pueda llevar el logotipo de ZigBee Alliance (�gura 2.1) debe
pasar exitosamente el Programa de Certi�cación ZigBee. Esto asegura que dicho producto
cumple con el estándar descrito en la especi�cación ZigBee. Se distinguen dos tipos de
certi�caciones:
ZigBee Compliant Platform: se aplica a módulos destinados a ser usados como blo-
ques para la construcción de productos �nales.
ZigBee Certi�ed Products: aplicado a productos �nales construidos en base a bloques
con certi�cación ZigBee Compliant Platform.
Figura 2.1: Logotipo ZigBee [21]
Aquellos productos que usan per�les de aplicación públicos son probados para asegurar
la interoperabilidad con otros productos �nales ZigBee.
Los productos que usan per�les de aplicación especí�cos de un fabricante, y que funcio-
naran como 'sistemas cerrados', son probados para asegurar que pueden coexistir con otros
sistemas ZigBee, esto es, que no inter�eren en el buen funcionamiento de otros productos
ZigBee certi�cados.
2.1.4. Arquitectura de ZigBee
Se presentan a continuación 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. INTRODUCCIÓN 13
trabajo. Cada capa añade 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 física, MAC y de red. Las funciones de las capas 4-72 están incluidas en
las capas APS (Application Support Sub-layer) y ZDO (ZigBee Device Object) del modelo
ZigBee. Entre cada capa se de�nen 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 gestión.
Las dos capas inferiores, física y MAC, están de�nidas por la especi�cación IEEE
802.15.4. La capa física simplemente traduce los bits al interfaz aire o viceversa. La capa
MAC provee el concepto de red, incluyendo el identi�cador de PAN (Personal Area Net-
work), el descubrimiento y unión a otras redes, y comandos para unirse o formar una red.
2Transporte, Sesión Presentación y Aplicación
14 CAPÍTULO 2. ZIGBEE/802.15.4
La capa MAC no soporta encaminamiento multi salto ni mallado.
Las capas de red y aplicación quedarón de�nidas por la ZigBee Alliance. La capa de red
es responsable de la administración de redes malladas, lo cual incluye el envío de paquetes
a través de la red, la determinación de rutas para envíos unicast y, de manera general,
el control del envío correcto de los paquetes entre sensores. Esta capa incluye también
una serie de comandos para la administración 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 aplicación actúa como �ltro para las aplicaciones ejecutadas sobre ella,
simpli�cando sus interacciones con otros módulos como Applicastion Pro�le. Se ocupa
también de �ltrar mensajes duplicados. Dentro de esta capa se incluye el módulo ZDO,
responsable de la gestión 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 descripción de
interacciones entre dispositivos que no se lleven a cabo a través del interfaz aire. ZigBee
solo de�ne el protocolo de red y el comportamiento a través de dicho interfaz. Este hecho
permite que todos los mensajes transmitidos a través del interfaz aire por un sensor ZigBee
puedan ser interpretados correctamente por cualquier otro sensor ZigBee, consiguiéndose
así que los fabricantes innoven a la vez que se mantiene la compatibilidad entre ellos.
Todas estas capas serán descritas de manera más detallada en siguientes secciones.
2.1.5. Versiones de ZigBee
Hasta el día 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 versión 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. INTRODUCCIÓN 15
Se muestra en la tabla 2.1 un resumen con las características más 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 través cuatro tipos de tramas
básicas: 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 transmisión.
La estructura de las tramas ACK permite la realimentación desde el receptor al
emisor, con�rmándose que fue recibida sin errores.
La trama MAC se utiliza para el control remoto y la con�guración de los distintos
dispositivos.
16 CAPÍTULO 2. ZIGBEE/802.15.4
2006 PRO
El coordinador selecciona el mejor canal disponible paraevitar interferencias al inicio
SI SI
Permite el cambio de canal durante la operación para evitarinterferencias
NO SI
Asignación distribuida de direcciones SI NOAsignación estocástica de direcciones NO SI
Los dispositivos pueden ser asignados a grupos paradireccionarlos de forma común
SI SI
Soporte para dispositivos con función de agregador NO SIEncriptado AES de 128 bits con código de integridad de
mensaje de 32 bitsSI SI
Contador de tramas para asegurar la no duplicidad SI SISeguridad en la capa de red por defecto y soportada en capas
superioresSI SI
Rotación de la clave de red SI SICentro de seguridad soportado en el coordinador SI SI
Modo de alta seguridad NO SICentro de seguridad soportado en cualquier dispositivo de la
redNO SI
Tamaño del mensaje de hasta 100 bytes dependiendo delservicio empleado
SI SI
Soporte para mensajes mayores de 100 bytes, teniendo comolímite los bu�ers de envío y recepción
NO SI
Algoritmo de enrutamiento tolerante a fallos con capacidad derespuesta a cambios en la red y en el interfaz radio
SI NO
Cada dispositivo mantiene información de sus vecinos,mejorando la �abilidad y robustez
NO SI
Tabla 2.1: ZigBee 2006 y PRO: Características destacadas [20]
2.1. INTRODUCCIÓN 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 más. Estas tramas son
importantes para permitir el ahorro de energía de los dispositivos, que esperan el
momento adecuado para mantener a los dispositivos sincronizados sin necesidad de
estar permanentemente en funcionamiento, permitiendo ahorrar energía.
En cuanto al mecanismo de direccionamiento, tanto la capa MAC como la capa de
aplicación forman parte de él. Un dispositivo ZigBee está formado por un transceptor
radio compatible con el estándar 802.15.4, en el que se implementan dos mecanismos de
acceso al canal y una o más descripciones de dispositivos. El transceptor es la base del
direccionamiento mientras que las aplicaciones asociadas a un dispositivo se identi�can 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 generación de subgrupos de direcciones. El
coordinador asigna un subgrupo de direcciones a cada uno de sus hijos con capacidad
de enrutador. Este proceso de asignación de subgrupos se repite de nuevo en los
dispositivos enrutadores de manera iterativa hasta que se llega a los dispositivos
�nales. Para calcular el tamaño de estos subgrupos de direcciones se tienen en cuenta
ciertos parámetros de la red de�nidos por el coordinador: máximo número de hijos
que un padre puede tener, máxima profundidad de la red (es decir, número máximo
de saltos hacía arriba o abajo) y máximo número de dispositivos enrutadores que un
padre puede tener como hijo.
Mecanismo estocástico (solo disponible para ZigBee PRO): basado en la asignación
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 fun-
cionamiento balizado, el mecanismo CSMA-CA (Carrier Sense Multiple Access-Collision
Avoidance) ranurado envía, de manera opcional, tramas ACK para los paquetes recibidos
correctamente. En este mecanismo, cada dispositivo es autónomo, pudiendo iniciar una
18 CAPÍTULO 2. ZIGBEE/802.15.4
conversación, en la que otros pueden interferir. Así, el canal puede estar ocupado o el dis-
positivo destino puede no recibir la petición. Este sistema se usa en sistemas en los que los
dispositivos pasan la mayor parte del tiempo inactivos. Para que los demás elementos de
la red sigan teniéndolos 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 ningún momento, debiendo permanecer en modo escucha en
todo momento.
Por otro lado, en una red con funcionamiento balizado se usa una estructura de super-
trama que se estudiará con detalle en 2.2.4.1.
2.2. IEEE 802.15.4
A continuación 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 estándar WPAN optimizado para aplicaciones con una baja tasa de trans-
ferencia de datos (entre 0.01 y 250 kbit/s) y requisitos mínimos o inexistentes
de calidad de servicio.
• El tipo de WPAN de menor coste y menor consumo.
• Un estándar 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 física y MAC.
En cuanto a los requisitos hardware de la MCU (MicroController Unit), se de�nen
los siguientes:
8 bits
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 según el papel que desem-
peñen en la red:
Coordinador ZigBee: es el dispositivo más completo, solo puede haber uno en cada
red y se encarga de la inicialización y control de la misma. Puede actuar también
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 dinámica-
mente alrededor de obstáculos y proporciona rutas alternativas en caso de congestión
o de fallos de dispositivos. Pueden conectarse tanto al coordinador como a otros en-
rutadores y soporta también dispositivos hijos. Cabe destacar que ofrece un nivel de
aplicación para la ejecución de código de usuario.
Dispositivo �nal ZigBee: debe estar conectado a un coordinador ZigBee o a un enru-
tador ZigBee y no admite hijos. Posee la funcionalidad necesaria para comunicarse
con su sensor padre pero no puede transmitir información destinada a otros dispo-
sitivos ni llevar a cabo ninguna operación de enrutamiento. De esta forma, puede
permanecer inactivo la mayor parte del tiempo, aumentando la vida de sus bate-
rías. Además, y no menos importante, el hecho de no tener que almacenar tablas de
encaminamiento hace que su necesidad de memoria disminuya considerablemente,
haciéndolo signi�cativamente más barato.
Por otro lado, atendiendo a la capacidad para actuar según qué tipo de los dispositivos
vistos anteriormente, podemos realizar una segunda clasi�cación:
20 CAPÍTULO 2. ZIGBEE/802.15.4
Dispositivo de funcionalidad completa (FFD: Full Functionality Device): es capaz de
recibir mensajes en formato del estándar 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): presen-
ta capacidad y funcionalidad limitadas (especi�cadas en el estándar) con el propósito
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. Topología de red
En las redes ZigBee pueden encontrarse tres tipos de topologías que se describen a
continuación:
Estrella: se compone de un dispositivo coordinador y varios dispositivos �nales, tal
y como se muestra en �gura 2.4. En esta topología, 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 fácil la formación de cuellos
de botella. Además 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 bene�ciarias de esta topología son la automatización resi-
dencial, periféricos de ordenadores y juguetes.
2.2. IEEE 802.15.4 21
Figura 2.4: Topología en estrella [8]
Árbol o jerárquica: en esta topología la red esta compuesta por un sensor central que
actúa como coordinador y varios enrutadores y/o dispositivos �nales, tal y como se
muestra en la �gura 2.5. La misión de los enrutadores es extender la cobertura de la
red (aunque también 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, además, 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 CAPÍTULO 2. ZIGBEE/802.15.4
Figura 2.5: Topología en árbol o jerárquica [8]
Árbol agrupado: este es un caso especial de topología 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 identi�cación única en la red. Esta topología forma parte de la
especi�cación del IEEE 802.15.4 pero no se incluye dentro de ZigBee por lo que no
se entrará en más detalles.
Figura 2.6: Topología en árbol agrupado [8]
2.2. IEEE 802.15.4 23
Mallada: consiste en una malla de enrutadores y dispositivos �nales interconectados.
Cada enrutador está tipicamente conectado a través 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 múltiples
enrutadores y dispositivos �nales.
En este escenario, añadir o eliminar dispositivos es sencillo, pudiénsose evitar
zonas 'muertas', o con señal recibida débil sin más que añadir enrutadores a la red.
Como inconvenientes presenta la necesidad de una cabecera de mayor tamaño y que
el protocolo de enrutamiento es más complejo que en los otros casos, haciendo los
requisitos de memoria y proceso más elevados.
Este concepto de red, conocido también como red nodal, es la aportación de
ZigBee que mayor interés está despertando entre las empresas desarrolladoras de
productos ya que su aplicación hará viable muchas soluciones de domótica vía radio
en viviendas construidas, allí donde las tecnologías radio de anteriores generaciones
estaban limitadas en cuanto a la cobertura o alcance entre dispositivos.
Figura 2.7: Topología Mallada [8]
24 CAPÍTULO 2. ZIGBEE/802.15.4
Sea cual sea la topología elegida, después 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 identi�cador 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 física IEEE 802.15.4
La capa física realiza las funciones de activación/desactivación del transceptor radio,
detección de energía, indicador de calidad del enlace, selección de canal y evaluación de
canal libre, además de ocuparse de la recepción y transmisión de paquetes a través del
interfaz aire.
El estándar proporciona dos opciones determinadas por la banda de frecuencia elegida.
Ambas están basadas en la técnica 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 modulación. Por otro lado, frecuencias menores proporcionan un mayor alcance en la
cobertura ya que las pérdidas por propagación 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 estándar
permite también la selección dinámica de canal.
En cuanto a la parte hardware, la sensibilidad mínima del receptor ha de ser de -85
dBm para 2.4 GHz3 y de -95 dBm para 868/915 MHz. Por otro lado, la máxima potencia
de transmisión ha de estar regulada según la regulación local. Un dispositivo certi�cado
como ZigBee debe indicar su potencia nominal de transmisión indicada en el parámetro
de la capa física phyTransmitPower.
3Aunque los dispositivos comerciales alcanzan a menudo sensibilidades muy inferiores, siendo -100 dBmun valor habitual.
2.2. IEEE 802.15.4 25
Figura 2.8: Canales IEEE 802.15.4 [20]
2.2.3.1. Detección de energía recibida (ED)
La medida de la energía recibida es usada por la capa de red en el algoritmo de selección
de canal. Se trata de una estimación de la potencia recibida en el ancho de banda de un
canal IEEE 802.15.4 y no decodi�ca la señal recibida. El tiempo requerido para llevar a
cabo la estimación debe ser igual al de 8 periodos de símbolo (128 ms en la banda de 2.4
GHz).
El resultado de la función ED (Energy Detection) es noti�cado como un entero de
8 bits. El valor mínimo indica potencia recibida menor de 10 dB sobre la sensibilidad
especi�cada 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 esti-
mación de la relación señal a ruido o una combinación de ambos métodos. El resultado de
LQI será usado por la capa de red o por la de aplicación.
LQI se indica mediante un entero de 8 bits, asociándose el mayor y el menor valor
26 CAPÍTULO 2. ZIGBEE/802.15.4
posible con la mayor o menor calidad detectable por el receptor, distribuyéndose los valores
de manera uniforme entre estos límites.
2.2.3.3. Evaluación de canal libre (CCA)
La operación de CCA (Clear Channel Assessment) se lleva a cabo de acuerdo a uno
de los siguientes métodos:
Energía por encima del umbral: CCA informará de canal ocupado si detecta cualquier
energía sobre el umbral de ED.
Detección de portadora: CCA informará de canal ocupado solo cuando detecte una
señal con la modulación y ensanchamiento de las características de IEEE 802.15.4.
No tiene en cuenta si la señal esta por encima o por debajo del umbral ED.
Detección de portadora con energía por encima del umbral: se trata de una combi-
nación de los dos métodos anteriores.
2.2.3.4. Formato de PPDU
La estructura de la PPDU (Physical layer conversion Protocol Data Unit) se muestra
en la �gura 2.3. Esta fomada por los siguientes componentes:
Cabecera de sincronización: permite al dispositivo receptor sincronizarse.
PHY CAB: contiene información acerca de la longitud de la trama.
Zona de carga variable (SDU física) que incluirá la trama MAC.
2.2.3.5. Características que reducen el consumo energético en la capa física
Se presentan a continuación las características que posibilitan el bajo consumo energé-
tico en la capa física:
2.2. IEEE 802.15.4 27
Señalización ortogonal multinivel
La baja potencia media usada es lograda gracias a tiempos de funcionamiento
reducidos, acompañados de bajos picos de corriente. En la capa física esto fomenta el
uso de una tasa de transferencia de datos elevada pero con una baja tasa de símbolos
ya que los picos de corriente suelen ir en consonancia con la tasa de símbolos usada
más que con la tasa de datos. Esto implica el uso de señalización multinivel.
Sin embargo, la señalización multinivel produce una pérdida de sensibilidad que
lleva aparejada un aumento del consumo. La solución es el uso de la señalización
ortogonal, intercambiando ancho de banda para mejorar la sensibilidad por medio
de la ganancia de código.
Reducción de la energía usada al activarse
Al ser los periodos activos de los sensores IEEE 802.15.4 muy cortos, una parte
signi�cativa de la potencia puede perderse si el transceptor tarda mucho en �ponerse
a funcionar�. El uso de técnicas como DSSS aporta la ventaja de que sus �ltros de
canal de gran anchura llevan de forma implícita aparejados una baja latencia.
No se contempla funcionamiento en modo dúplex para así reducir los picos de co-
rriente.
Elección 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 administración de la baliza, acceso al canal,
administración de las ranuras temporales garantizadas, validación de la trama, acuse de
recibo de trama, asociación y disasociación.
28 CAPÍTULO 2. ZIGBEE/802.15.4
2.2.4.1. Estructura de supertrama (Modo balizado)
IEEE 802.15.4 permite el uso de la estructura de supertrama. El formato de esta
supertrama es de�nido por el coordinador, quedando localizada entre las balizas y dividida
en 16 slots de igual duración. La baliza es enviada en el primer slot de cada supertrama. Si
el coordinador no quiere usar la estructura de supertrama puede desactivar la transmisión
de balizas, que son usadas para sincronizar los dispositivos adheridos a él, identi�car 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 contención (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. Además, una ranura temporal garantizada puede ocupar más 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 espe-
cialmente adecuado para aquellos casos en los que el coordinador está alimentado median-
te baterías. Los dispositivos que componen la red, escuchan dicho coordinador durante el
2.2. IEEE 802.15.4 29
envío de la baliza4. Un dispositivo que quiera intervenir, deberá registrarse para el coor-
dinador 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 coor-
dinador a un dispositivo de otro tipo y viceversa. El mecanismo de transferencia varía
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 trans-
misión 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 envío 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 trasmisión de
un comando MAC hacia el coordinador. Este comando MAC de sondeo será enviado
usando CSMA-CA no ranurado y especi�cando una tasa de datos requerida. Si no
4El envío se produce en modo broadcast de forma periódica. Este periodo puede variar, dependiendode la con�guración, entre 0.015 y 252 segundos
30 CAPÍTULO 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 con�rmará
el recibo de esta trama.
En el caso de la transmisión de datos entre dispositivos del mismo tipo, se presentan
dos opciones. En el primer caso, el sensor escuchará de manera constante y trans-
mitirá sus datos usando CSMA-CA no ranurado. En el segundo caso, los sensores se
sincronizan para poder ahorrar energía.
2.2.4.3. Inicialización 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 identi�cador PAN adecuado.
El escaneo activo de canal permite al dispositivo FFD localizar coordinadores que estén
transmitiendo tramas baliza dentro de su espacio de operación personal.
El escaneo activo de canal se lleva a cabo sobre un conjunto de canales lógicos. Para
cada canal, el dispositivo debe conmutar la trasmisión a dicho canal y y enviar un comando
de solicitud de baliza. Después de esto, el dispositivo activa su receptor durante un tiempo
con�gurable y almacena la información 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 periódicas le acabarán
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 especi-
�cado o cuando se hayan almacenado el número máximo de identi�cadores PAN indicados
en la implementación. El escaneo completo �nalizará cuando todos los canales del conjun-
to de canales lógicos disponibles hayan sido escaneados (o cuando se hayan almacenado
2.2. IEEE 802.15.4 31
el número máximo de identi�cadores PAN indicados en la implementación si esto ocurre
antes). La elección del identi�cador de PAN se hará teniendo en cuenta el resultado de las
PAN detectadas durante el escaneo y será responsabilidad exclusiva de la aplicación.
En conjunto con lo visto hasta ahora, para la selección del identi�cador también se
tendrá en cuenta el resultado de ED en la capa física, pudiéndo ser descartadas ciertas
tramas por parte de la capa MAC. Además de todo lo anterior, cabe destacar que Zig-
Bee dispone de una serie de procedimientos para solucionar con�ictos relacionados con la
duplicidad de identi�cadores PAN dentro de su espacio de operación personal.
2.2.4.4. Unión a una red ZigBee
Hay dos procedimientos para unirse a una red ZigBee: asociación MAC y reasociación
de red (que se describirá más adelante).
La asociación 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 trasmisión del comando correspondiente. Posterior-
mente, el dispositivo que desee unirse a la red deberá indicarlo mediante otro comando.
Esta última petición causará el inicio de un protocolo de la capa MAC en el que se in-
tercambiarán mensajes entre el dispositivo que desea unirse a la red y el coordinador o el
enrutador, indicándose entre otros detalles la dirección asignada al dispositivo dentro de
la red. Debe destacarse que la asociación MAC es un protocolo inseguro ya que todas las
tramas que se intercambian son enviadas sin tomar medidas de seguridad.
2.2.4.5. Sincronización
En aquellas redes con funcionamietnto balizado, la sincronización se consigue a través
de la recepción y decodi�cación de las tramas baliza. En redes sin funcionamiento bali-
zado, la sincronización es llevada a cabo mediante el sondeo del coordinador solicitando
transmitir datos.
32 CAPÍTULO 2. ZIGBEE/802.15.4
Existen también procedimientos para la recuperación de dispositivos que han perdido
la comunicación con la red, denominados dispositivos huérfanos.
2.2.4.6. Formato de la trama MAC
El formato general de la trama MAC varía según el tipo de trama que se envíe, las di-
ferentes opciones se muestra en la �gura 2.3 e incluyen los siguientes componentes básicos:
MHR: comprende control de trama, número de secuencia e información de direccio-
namiento.
Zona de carga MAC: de longitud variable, contiene información especí�ca del tipo
de trama. Las tramas ACK no contienen zona de carga.
MFR: contiene FCS (Frame Check Sequence).
2.2.4.7. Características que reducen el consumo energético en la capa MAC
Se presentan a continuación las características que posibilitan el bajo consumo energé-
tico 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 signi�cativamente el consumo.
Efecto de recuperación de las baterías: todos los tipos de baterías presentan un efecto
de recuperación por el cual su duración se extiende si la corriente es extraída de ellas
en ráfagas en lugar de hacerse con el equivalente en corriente constante.
2.3. ZIGBEE ALLIANCE 33
2.3. ZigBee Alliance
A continuación 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 asociación de empresas que buscan promover IEEE 802.15.4.
• Una asociación de empresas que llevan a cabo la comercialización y certi�cación
de ZigBee.
• Una asociación de empresas que se ocupan de la de�nición 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 invocación de acciones en
la capa MAC. Sus tareas incluyen iniciar la red5, asignar direcciones de red, añadir o elimi-
nar dispositivos en la red, enrutar mensajes, aplicar medidas de seguridad e implementar
el descubrimiento de rutas.
2.3.1.1. Reincorporación a la red
El procedimiento de reincorporación 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 unión
de dispositivos a la red y que, si se hace a nivel de red, la unión de un dispositivo a la red
puede hacerse de forma segura. Esto último es cierto si el dispositivo está reincorporándose
a a red o si el dispositivo esta uniéndose por primera vez pero ha obtenido la clave de red
por medio de algún mecanismo externo.
5Si se trata de un dispositivo actuando como coordinador
34 CAPÍTULO 2. ZIGBEE/802.15.4
2.3.1.2. 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 transmisión de tramas desde
una fuente a un destino mantiene un registro en su tabla de enrutamiento asociada a esta
comunicación. Este registro, como mínimo, debe almacenar tanto la distancia lógica hasta
el destino como la dirección del siguiente enrutador en el camino hacia dicho destino.
Las rutas son determinadas según van siendo solicitadas usando un proceso de descubri-
miento de rutas en el que el dispositivo que desea trasmitir envía 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 petición ahora como
destino. Conforme dicha contestación vaya pasando a través de los distintos enrutadores
que actuarán como intermediadores en la trasmisión, 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 número de optimizaciones al algoritmo básico
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 distribución de direcciones, en el que las direcciones son asignadas siguiendo una cierta
jerarquía, comenzando por el coordinador. Así, los dispositivos con poca o ninguna capa-
cidad de enrutamiento, o dispositivos cuya capacidad haya sido agotada, tienen la opción
de usar el encaminamiento jerárquico para proporcionar un enrutamiento posiblemente
menos e�ciente pero más sencillo (ya que el paquete es siempre enrutado hacia un padre
2.3. ZIGBEE ALLIANCE 35
o un hijo, según el rango de la dirección de destino). Este procedimiento se muestra en la
�gura 2.11.
Figura 2.11: Encaminamiento jeráquico [20]
Por otro lado, en la mayoría de las aplicaciones empotradas para redes inalámbricas
suele existir un dispositivo denominado sumidero, al que todos los demás dispositivos per-
tenecientes 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 petición 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 ejempli�ca este problema. Las tablas de enrutamiento de estos pocos
vecinos se verán sobrecargadas simplemente por su proximidad al sumidero.
La especi�cación 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 información de enrutamiento es almacenada en las
tablas de los dispositivos que participan en la retransmisión de una trama, el enrutamiento
fuente añade la información de enrutado en la propia trama que se transmite. Ahora solo
el origen de la trama necesita almacenar la información para la ruta, pero a costa de que
36 CAPÍTULO 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. Características que reducen el consumo energético en la capa de red
Se presentan a continuación las características que posibilitan el bajo consumo energé-
tico en la Capa de Red:
El algoritmo de enrutamiento usado en ZigBee 1.0 emplea como parámetros tanto la
calidad del enlace como el número de saltos, de esta manera disminuye el consumo
de energía al minimizar las retransmisiones de mensajes y evitar la repetición de las
rutinas para el descubrimiento de rutas.
Las implementaciones futuras de ZigBee probablemente incluirán dentro de su fun-
ción de costes para la eleccion de la ruta adecuada parámetros relacionados con el
consumo energético, tales como energía restante del sensor o fuente de energía usada
por el sensor.
2.3.2. Capa de Aplicación ZigBee
La capa superior de la pila de protocolos ZigBee esta compuesta por los siguientes
elementos:
Marco de aplicación: proporciona una descripción acerca de cómo de�nir un per�l
en la pila ZigBee. También especi�ca un conjunto de tipos de datos para per�les,
descriptores para la asistencia en el servicio de descubrimiento, formatos de trama
para el transporte de datos y un constructor para desarrollar per�les básicos.
Dentro del marco de aplicación quedan de�nidos los objetos de aplicación, 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 aplicación, estando el 0
reservado para ZDO.
2.3. ZIGBEE ALLIANCE 37
ZDO: de�ne el papel a desempeñar por un dispositivo dentro de la red (coordina-
dor, enrutador o dispositivo �nal), inicia y/o responde a peticiones de conexión y
de descubrimiento, y establece una relación segura entre los dispositivos de la red.
También provee un amplio conjunto de comandos para la administración de la red
y el dispositivo. ZDO es siempre el endpoint 0.
En colaboración con ZDO se encuentra el Plano de Administración ZDO, cuya
labor es facilitar la comunicación 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 aplicación. Se ocupa también
de almacenar la tabla de conexiones.
SSP (Secure Services Provider): actúa entre APS y la capa de red para proveer los
mecanismos necesarios para el uso de encriptación a ambas. Queda con�gurado a
través de ZDO.
2.3.2.1. Per�les de aplicación, grupos y endpoints
Un per�l de aplicación describe una colección de dispositivos empleados para una
aplicación especí�ca e, implicitamente, el esquema de intercambio de mensajes entre estos
dispositivos. Un identi�cador de per�l es asignado para cada aplicación de manera que
quede identi�cado de forma unívoca.
Existen dos tipos de per�les de aplicación:
Per�l de aplicación público: aplicación desarrollada por ZigBee Alliance que realiza
una tarea determinada y puede ser usada en cualquier dispositivo ZigBee.
Per�l de aplicación especí�co de un fabricante: aplicación privada desarrollada por
una compañía para funcionar en un derteminado dispositivo ZigBee.
Los dispostivos con un per�l de aplicación común se comunican entre ellos usando el
concepto de grupos, en el que se describen las posibles entradas o salidas de datos que se
38 CAPÍTULO 2. ZIGBEE/802.15.4
pueden registrar desde o hasta otros dispositivos. Un identi�cador de grupo diferencia de
forma unívoca los grupos dentro del rango de un per�l determinado.
Un endpoint de�ne una entidad dentro de un dispositivo a través de la que se realiza
la comunicación con una aplicación especí�ca, como ya se indicó, pueden existir hasta
240 endpoints, estando el 0 reservado para ZDO, que proporciona comandos de control y
administración.
2.4. Seguridad en ZigBee
La seguridad en ZigBee esta basada en el algoritmo 128-bit AES (Advanced Encryption
Standard) y se añade al modelo de seguridad que provee IEEE 802.15.4. Incluye métodos
para el establecimiento y el transporte de manera cifrada, administración de dispositivos y
protección de la trama. La especi�cación de ZigBee de�ne la seguridad para las capas MAC,
de red y de aplicación. La seguridad para las aplicaciones es proporcionada típicamente a
través de los per�les de aplicación.
Veamos los elementos más importantes en lo referente a la seguridad:
Centro de Con�anza: decide si se permiten o no nuevos dispositivos en la red y puede
actualizar y cambiar de forma periódica 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 Con�anza es normalmente el coordinador, pero tambien puede ser un
dispositivo dedicado a esta labor. Es responsable de las siguientes tareas de seguridad:
• Autenticación de dispositivos que soliciten unirse a la red.
• Mantenimiento y distribución 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 encriptación 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 Con�anza se denominan Claves
Maestras del Centro de Con�anza mientras que las demás se denominan Claves
Maestras de la Capa de Aplicación.
• 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 estándar pueden ser enviadas con o sin encriptación. La
opción 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 aplicación. Las claves
de red proporcionadas por el Centro de Con�anza son denominadas Claves de
Enlace del Centro de Con�anza, las demás son denominadas Claves de Enlace
de la Capa de Aplicación.
40 CAPÍTULO 2. ZIGBEE/802.15.4
Capítulo 3
Componentes y tecnologías utilizadas
En este capítulo se hará una descripción de las herramientas tanto software como
hardware que han sido necesarias para la realización y prueba de este Proyecto Fin de
Carrera.
3.1. Elementos hardware
3.1.1. 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 veri�car el correcto funcionamiento de la pasarela
a desarrollar en este proyecto. A continuación se hará una descripción de sus elemen-
tos centrándonos principalmente en la pastilla contenedora de la pila de protocolos Zig-
Bee/802.15.4 pero sin entrar en grandes detalles ya que no es el objetivo de este proyecto
su estudio. Para conocer más acerca de su funcionamiento se recomienda consultar la guía
para desarrolladores del CC24801.
1Disponible en http://focus.ti.com/lit/an/swra176/swra176.pdf
41
42 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
El equipo de desarrollo que nos ocupa está compuesto de tres motas/sensores Zig-
Bee, un conector USB (Universal Serial Bus) y dos suministradores de energía mediante
baterías. Todos ellos pueden verse en la �gura 3.1.
Figura 3.1: Contenido eZ430-RF2480
El conector USB permite la comunicación 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 también proporciona
la energía necesaría para el correcto funcionamiento de la mota conectada al conversor. En
cuanto a los suministradores de energía mediante baterías, se ha de destacar que permiten
mantener en funcionamiento a las motas conectadas a ellos sin necesidad de depender de
la red eléctrica, funcionando con baterías de tipo AAA.
2Descrito en el apartado 3.2.1.3
3.1. ELEMENTOS HARDWARE 43
Descripción 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 física, MAC y de red y
un microcontrolador que se encarga únicamente de la capa de aplicación. En concreto,
el procesador es un CC2480 y el microcontrolador es un MSP430F2274, comunicándose
ambos mediante interfaz SPI (Serial Peripheral Interface) o UART (Universal Asynch-
ronous Receiver-Transmitter) según puede verse en la �gura 3.2. La antena se encuentra
integrada en el mismo CC2480.
Figura 3.2: Conexión CC2480-MSP430
La solución incluida en estas motas por Texas Instruments de cara a la implementación
de la pila de protocolos es denominada Z-Accel. Dicha solución consiste en la ejecución de
la versión de la pila de protocolos ZigBee desarrollada por Texas Instruments, denominada
Z-Stack, en el procesador CC2480 y la ejecución de la aplicación en el microcontrolador
MSP430F2274. El CC2480 se ocupa de manejar todas las tareas críticas en tiempo así como
todo aquello relacionado con el protocolo ZigBee/802.15.4 mientras que el microcontrola-
dor está liberado para ocuparse tan solo de la ejecución de la aplicación almacenada. Esta
distribución 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 estándar ZigBee-2006. Se debe reseñar que el procesador CC2480 trabaja sólo en modo
no balizado.
44 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
Figura 3.3: Distribución 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 cúal 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 envíe a través 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 continuación se encuentran los bytes de datos. Como último
campo encontramos el FCS, que es una función 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:
Petición Asíncrona: enviada desde el microcontrolador al procesador. No se espera
respuesta.
Petición Síncrona: enviada desde el microcontrolador al procesador. Se espera res-
puesta.
Respuesta Síncrona: respuesta por parte de procesador a la petición síncrona hecha
por el microcontrolador.
Sondeo: al estar toda comunicación iniciada por el microcontrolador, el sondeo sirve
para preguntar al procesador si tiene alguna petición que realizarle al microcontro-
lador.
Por otra parte, como ya se mostró anteriormente, la capa de aplicación se compone
de distintas subcapas, indicándose esto mediante el campo subsistema.
Finalmente, los 8 bits �nales del campo comando identi�can a cada uno de los comandos
disponibles.
46 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
Interfaz de aplicación
En cuanto a la interfaz con la capa de aplicación, aparte de la interfaz API propia
de la solución 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 versión
simpli�cada 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 con�guración 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 Speci�cation'3.
Microprocesador MSP 430
Como se ha descrito a lo largo de esta sección, el procesador CC2480 se combina
con un microcontrolador MSP430F2274 que gestiona la parte de aplicación. Este micro-
controlador tiene como principal característica el bajo consumo energético, lo cual lo hace
ideal para lograr uno de los principales propósitos de ZigBee, la duración de las baterías.
Esto se logra gracias a su arquitectura y a cinco modos de funcionamiento optimizados
para lograr un bajo consumo energético. 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 gestión de toda la señalización y protocolos asociados al estándar
USB. Cada uno de estos conversores contiene un pequeño circuito impreso interno encap-
sulado en el propio conector USB incluido al �nal del cable. El modelo concreto usado en
3Disponible 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. Además, cada
cable incorpora la identi�cación única desarrollada por FTDI y denominada FTDIChip-ID
que permite proporcionar seguridad a la hora del acceso para la transferencia de archivos
a través 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 comunicación con este dispositivo mediante los puertos de emulación 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 elección frente a otras
alternativas, como podría haber sido el conversor proporcionado en el equipo de desarrollo
eZ430-RF2480 de Texas Instruments.
48 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
3.1.3. Router ASUS WL-500G Premium
La programación de nuestra pasarela Zigbee/802.15.4-IP se llevará a cabo sobre un
router ASUS WL-500G Premium. Esta elección 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
través de las cuales llegará la información procedente de nuestra red de sensores ZigBee.
Se muestra una breve descripción de sus principales características en la tabla 3.1.
Parámetro Descripción
Estándar Inalámbrico IEEE 802.11 b/gCifrado WEP, WAP, WPA2Antena Antena IF interna y antena externa de
dipoloModulación OFDM, CCK, DQPSK, DBPSK
Frecuencia de operación 2.4 - 2.5 GHzTasa de transferencia de
datos nominal802.11g: 6, 9, 12, 18, 24, 36, 48, 54 Mbps;
802.11b: 1, 2, 5.5, 11MbpsPotencia de salida 802.11g: 14~16dBm; 802.11b: 16~18dBm
Sensibilidad -74~-75dBm a 54Mbps; -87~-88dBm a11Mbps; -95~-97dBm a 1Mbps
Canales 13 para Europa (ETSI), 11 para NorteAmerica y 14 para Japón
WAN 1 puerto RJ-45 (10/100 BaseT) FastEthernet (10/100 Mb/s)
LAN 4 puertos RJ-45 (10/100 BaseT) FastEthernet (10/100 Mb/s)
Otras conexiones 2 puertos USB2.0
Tabla 3.1: Características Asus WL-500G Premium [2]
El enrutador presenta una serie de indicadores de tipo LED en el frontal que indican
su estado según 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 capa-
cidad de conectividad que presenta gracias a sus dos puertos USB 2.0. Además de esto,
presenta 4 puertos para conexiones LAN y otro puerto para conexión 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 alimentación (a la izquierda) tal y como
puede apreciarse en la �gura 3.8. Debe destacarse el interruptor restore, imprescindible
para la instalación del sistema operativo deseado como veremos más 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 módulo Wi-Fi. Esta última es una pequeña placa conectada a la principal
a través 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 denomina-
do BCM4318E y otro denominado SiGe 2521A60. El chip BCM4318E es un controlador
inalámbrico altamente integrado que, entre otras tareas, es capaz de dar soporte a la tec-
nología propietaria de Broadcom denominada AfterBurner que permite un incremento de
50 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
Figura 3.9: ASUS WL-500G Premium Interior
la tasa de transferencia de datos para 802.11g de hasta un 35% mediante la compresión
de tramas. Por su parte, el chip SiGe 2521A60 es un módulo de radiofrecuencia para la
gestion de los estándares 802.11b y 802.11g.
Los principales componentes del enrutador, procesador y memoria, se encuentran en
la placa impresa principal bajo la carcasa metálica. 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. Además, cuenta con 32 Mbytes de memoria RAM5 para la ejecución de software.
Otros dos controladores a los que se debe hacer mención son el chip VT6212L fabricado
por VIA y el chip BCM5325E fabricado por Broadcom. El primero es un controlador para
4Familia de microprocesadores de arquitectura RISC desarrollados por MIPS Technologies.5Concretamente DDR SDRAM
3.2. ELEMENTOS SOFTWARE 51
los puertos USB 2.0 y el segundo es un conmutador Fast Ethernet con un bu�er para
tramas de 128 Mbytes y la capacidad de detectar el tipo de cable conectado al puerto
(ordinario o cruzado).
Para la resolución de problemas, se puede conectar al enrutador ASUS WL-500G Pre-
mium a través de un bus de tipo UART. El conector correspondiente se encuentra locali-
zado en el borde derecho de la placa principal.
3.2. Elementos software
3.2.1. Herramientas
3.2.1.1. DD-WRT
El software DD-WRT es un �rmware libre con licencia GPL (General Public Licen-
se) versión 2. Está destinado a una gran variedad de enrutadores inalámbricos IEEE
802.11a/b/g/h/n con arquitectura basada en chips Atheros o Broadcom.
Las versiones hasta la número 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
versión 23 en adelante está basado en OpenWrt, que empezó siendo un �rmware basado en
el de Linksys pero más tarde cambió a su propio entorno. La idea inicial de crear DD-WRT
surgió debido a la decisión de Sveasoft de comenzar a cobrar por su producto, cerrando
de esta manera la puerta al código 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é versión es adecuada instalar en nuestro enrutador, basta con ac-
ceder a la página o�cial del �rmware DD-WRT6, una vez ahí acudir a la sección Support y
entrar a Router Database. Especi�cando nuestro modelo de router en el espacio correspon-
diente se mostrarán las versiones recomendadas para ser instaladas en nuestro dispositivo,
6http://www.dd-wrt.com
52 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
en este caso la elección es la versión 24 (build 12188). Es importante asegurarse de que la
versión es la adecuada ya que existen versiones con núcleo 2.6 y otras con núcleo 2.4 de
Linux, la instalación en el dispositivo inadecuado de cualquiera de ellas puede dar como
resultado la inutilización permanente del enrutador.
Además de existir distintas versiones disponibles, también es posible elegir entre varias
tipos de �rmware dentro de cada versión, diferenciandose entre ellos por las utilidades
que incluyen instaladas por defecto. Esto último es importante ya que de esta elección
dependerán los requisitos, principalmente de memoria, de los que necesitaremos disponer
en nuestro enrutador.
En la tabla 3.2 se describen algunas características que pueden ser incluidas en DD-
WRT:
3.2. ELEMENTOS SOFTWARE 53
Utilidad Descripción
Asterisk Aplicación que emula una PBX mediantesoftware. Permite el manejo de telefoníasobre IP sin necesidad de añadir hardwareadicional, facilitando la interoperabilidadcon la mayoría de dispositivos estándares
de telefonía.Monitorización del ancho de banda Monitorización de ancho de banda
consumido por cada usuario, mediatemporal...
Chillispot Aplicación para la autenticación deusuarios. Permite el ingreso via web que esel estándar actual para HotSpots públicos.
Afterburner Incrementa el throughput WiFi a travésde procesos software.
IPv6 Versión de IP de�nida en el RFC 2460 ydiseñada para reemplazar a la versión 4
de�nida en el RFC 79JFFS2 Área dentro de un dispositivo equipado
con DD-WRT para la re-escritura habitualde datos.
Soporte de expansión de memoriaMMC/SD
Permite añadir memoria externa alenrutador para el almacenamieto de datos
y/o aplicaciones.Samba Implementación libre del protocolo de
archivos compartidos de MicrosoftWindows (antiguamente llamado SMB,renombrado recientemente a CIFS) para
sistemas de tipo UNIX.Wake On LAN Permite encender remotamente
ordenadores en estado de hibernación oapagados.
RFlow Collector Permite el envío y almacenamiento deinformación relacionada con el trá�co de
la red para su posterior estudio.
Tabla 3.2: DD-WRT: Utilidades principales [1]
54 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
La elección de DD-WRT para la realización de este Proyecto Fin de Carrera se basó en
la existencia de controladores para el conversor TTL-232R-3V3 de FTDI, la facilidad de
con�guración a través 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 programación bajo el que está desarrollado el núcleo de DD-WRT es
C++, existiendo además compiladores cruzados para la creación de aplicaciones dirigidas
a routers con arquitectura MIPS tal y como es el caso del ASUS WL-500G Premium.
En sucesivos capítulos se describirá de una manera detallada el proceso de compilación,
instalación y con�guración del �rmware para lograr la completa adaptación de éste a los
requerimientos deseados.
3.2. ELEMENTOS SOFTWARE 55
3.2.1.2. Entorno de desarrollo Eclipse
Eclipse es una comunidad cuyos objetivos están centrados en la realización de una pla-
taforma de código abierto para el desarrollo de aplicaciones. Se puede mantener el mismo
entorno de desarrollo pero variar el lenguage de programación usado para la aplicación a
desarrollar sin más que añadir distintos módulos. La Fundación Eclipse7 es una asociación
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 código abierto surgida entorno a este proyecto.
El Proyecto Eclipse fue creado por IBM en Noviembre de 2001 y apoyado por una
agrupación de desarrolladores de software. La Fundación 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 extensión dedicada al
7http://www.eclipse.org/org/foundation/
56 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
desarrollo de software Java, pero nada más lejos de la realidad ya que Eclipse permite
la adición de módulos para el desarrollo de aplicaciones en lenguages de programación
tan diversos como pueden ser C/C++, PHP, Perl, Ruby y JavaScript. Cada una de estos
módulos se denominan Kits de Desarrollo Software (SDK) y permiten desde la corrección
de la sintaxis utilizada, hasta la depuración y compilación del código, pasando por la
información acerca de las API que pueden utilizarse y como deben ser utilizadas. Otra
interesante característica de Eclipse es su capacidad para ocultar bloques de código que
hacen más fácil la comprensión y manejo del mismo cuando éste crece.
En cuanto a su rendimiento, Eclipse se muestra muy estable, presentando como úni-
co inconveniente su consumo de memoría, que lo hace especialmente lento en aquellas
máquinas con pocos recursos de memoria RAM.
En el caso de este Proyecto Fin de Carrera se hace uso de Eclipse en combinación con
el SDK de C++, todo ello ejecutado bajo un sistema operativo Ubuntu 10.04.
3.2.1.3. MSP430 IAR Embedded Workbench
La aplicación MSP430 IAR Embedded Workbench es un entorno de desarrollo de
C/C++ que integra las funciones necesarias para la realización de aplicaciones empotradas
destinadas a la familia de microcontroladores MSP430. Se muestran a continuación los
elementos más destacados de los que está compuesto:
Editor de textos
Permite la edición de varios archivos en paralelo, además de todas las característi-
cas básicas exigidas en un editor de textos moderno, como la posibilidad de hacer/rehacer
de forma ilimitada acciones. Provee también características destinadas a facilitar el desa-
rrollo 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 características básicas de un compilador C/C++ además 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 código de alto nivel destinado a aplicaciones empo-
tradas. Está especialmente diseñado para su uso junto a ensambladores y compiladores
de IAR System. Entre sus características incluye la posibilidad de editar el código fuente
mientras se está depurando éste.
El depurador está compuesto de dos módulos, uno que aporta un conjunto de acciones
para la depuración y otro que actúa como un controlador, permitiendo la comunicación y
control del dispositivo destino de la aplicación desarrollada.
Simulador IAR C-SPY
Este módulo permite simular las funciones del procesador destino mediante softwa-
re. Así, mediante IAR C-SPY, la aplicación 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 través de conexión JTAG (Joint Test Action Group),
incluida en todas las placas de desarrollo de Texas Instruments. Este módulo permite la
descarga de la memoria �ash y aprovecha las facilidades de la depuración sobre el chip.
Podemos ver la estructura de MSP430 IAR Embedded Workbench en la �gura 3.12:
58 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
Figura 3.12: MSP430 IAR Embedded Workbench: Estructura [24]
Para la ejecución de este Proyecto Fin de Carrera, MSP430 IAR Embedded Workbench
fue utilizado para la modi�cación del software residente en las motas proporcionadas por
el equipo de desarrollo eZ430-RF2480 de Texas Instruments, usándose la versión de prueba
disponible en su web8.
3.2.1.4. WinSCP
WinSCP es una aplicación libre y descargable desde su web9 que se ejecuta bajo siste-
mas 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 Proto-
col). WinSCP permite efectuar las operaciones básicas con archivos, tales como descargas
y subidas. Tambien es posible renombrar archivos y directorios, crear nuevos directorios,
modi�car las propiedades de archivos y carpetas, y crear enlaces simbólicos y accesos
directos.
WinSCP permite la elección entre dos tipos de interfaces, uno denominado 'comman-
der' que consta de dos paneles (el izquierdo dedicado al directorio local y el derecho al
8http://www.iar.com/website1/1.0.1.0/220/1/9http://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 información referida al directorio remoto). En la �gura puede observarse el interfaz
'commander ' de WinSCP.
Esta aplicación 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 sólo para Windows, ahora también está disponible para varias plataformas
Unix en su web10. Su característica más 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 comprobación 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 visualización del formato de trama enviado por
éstas.
La con�guración adecuada para una correcta recepción de los datos es: 9600 baudios, 8
bits de datos, 1 bit de parada y ningún 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.
10http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
60 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
Figura 3.13: Putty: Pantalla Principal
3.2.1.6. XVI32
XVI32 es un editor hexadecimal freeware11. Su utilidad viene del hecho de que los
valores recibidos mediante Putty se encuentran en formato ASCII y a través de esta
utilidad podremos pasar del formato ASCII proporcionado a un formato hexadecimal al
que se está más habituado y suele ser más cómodo 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, mostrándose en pantalla el equivalente en hexadecimal. Se puede ver un
ejemplo de conversión 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.
11Puede 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. Programación
3.2.2.1. C++
C++ fue una evolución de C, el cual surgió a partir de dos lenguajes de programación
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 características de su lenguaje B según sus equivalentes en BCPL, valiéndose
de B para crear las primeras versiones del sistema operativo UNIX. BCPL y B tenían
también en común que eran lenguages sin tipos de�nidos.
El lenguaje C fue una evolución de B llevada a cabo por Dennis Ritchie en los Labora-
torios Bell. C se basa en muchos conceptos básicos de BCPL y de B, añadiendo 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 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
La gran difusión vivida por C tuvo también aspectos negativos, el más destacado fue
que, al estar disponible para muchos tipos de ordenadores, surgieron demasiadas varian-
tes, 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é técnico
X3J11 bajo el ANSI (American National Standards Institute), con el objetivo de de�nir el
lenguaje de manera independiente del equipo. Finalmente, en 1989 se aprobó el estándar
y el ANSI trabajó junto a ISO (International Organization for Standardization) en su es-
tandarización a nivel mundial, publicándose el documento conjunto del estándar en 1990
bajo el nombre 'ANSI/ISO 9899: 1990'.
Por otro lado, a principios de los 80, Bjarne Stroustrup creó C++, una extensión de C.
C++ añade una serie de características que mejoran el lenguaje C, pero sobre todas ellas,
la más importante fue la inclusión de la capacidad de programación orientada a objetos. El
concepto de objeto surgía novedoso pero traería con él la puerta de acceso de�nitiva para
la construcción de software de forma rápida y económica. 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 modi�car su software que con la
anterior visión de programación estructurada. C++ era y es un lenguage híbrido 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 implementación comer-
cial de C++, cfront 1.0, fue lanzada en 1985, se trataba de un traductor de C++ a C.
C++ está de�nido y mantenido por el comité ISO, compuesto por delegados de asociacio-
nes nacionales de estandarización como ANSI, DIN (Deutsches Institut für Normung) y
muchas otras. El primer estándar de C++ fue aprobado en 1998 bajo el nombre ISO/IEC
14882, habiendose publicado hasta hoy dos revisiones de éste. El estándar ISO de C++
de�ne el lenguaje del núcleo, las librerías incluídas de manera estándar y los requisitos
de implementación. Se espera para próximas fechas el lanzamiento del nuevo estándar de
C++, siendo el nombre no o�cial de éste C++0x.
La implantación del uso de C y C++ es mayoritaría entre la comunidad desarrolladora
de software pero su in�uencia es aún mayor al ser la base de otros lenguajes de progra-
mación ampliamente usados en la actualidad como es Java, de Sun Microsystems. En la
3.2. ELEMENTOS SOFTWARE 63
�gura 3.15 se muestra la distribución de uso de los principales lenguaes de programación
en los últimos díez años.
Figura 3.15: Lenguages de Programación: Distribución de uso [29]
La �gura 3.15 muestra como los tres lenguages de programación más usados en la
actualidad y en los últimos años 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 híbrido
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 estándar que permite la comunicación de
aplicaciones externas con servidores. Un programa CGI se ejecuta en tiempo real, por lo
que permite la generación de información de manera dinámica.
64 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
Un ejemplo clásico de uso de CGI es la comunicación de una base de datos con Internet
para permitir su consulta a través de un servidor. Para llevar esto a cabo se necesitará
un programa CGI, al que la página web del servidor llamará cuando el usuario así lo
decida, que permitirá extraer resultados de la base de datos y mostrárselos posteriormente
al usuario.
A la hora de usar CGI no hay límites respecto a lo que se puede realizar pero deberá
tenerse siempre presente que el tiempo de cómputo 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, decisión que no es la más segura. Por ello existen una
serie de precauciones de seguridad que deben implementarse cuando se usan programas
CGI de las cuales la más 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 páginas web alojadas en el servidor, normalmente /www. El servidor conoce que el
directorio /cgi-bin contiene ejecutables que deberán ser ejecutados y su salida deberá ser
enviada al navegador del cliente.
Un programa CGI puede ser escrito en cualquier lenguage de programación 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 mención al hecho de que CGI permite
la ejecución de programas tanto de tipo interpretado como compilado, lo que permite
también el uso de scripts.
Para el paso de datos del servidor al programa CGI, el servidor puede usar tanto líneas
de comando como variables de entorno que se activan cuando se ejecuta el programa CGI.
Se describen a continuación de forma breve estas variables de entorno:
3.2. ELEMENTOS SOFTWARE 65
SERVER_SOFTWARE Devuelve el nombre y la versión del software del servi-
dor de información que contesta la petición de usuario.
SERVER_NAME Devuelve nombre de host del servidor, el alias DNS, o la di-
rección IP como aparecería en las URL autoreferenciadas.
GATEWAY_INTERFACE Devuelve la revisión de la especi�cación CGI con
que el servidor puede trabajar.
Las variables anteriormente mencionadas son activadas en todos los casos por el ser-
vidor, con independencia de la información enviada, por otro lado, las que se muestran a
continuación son especí�cas de la petición hecha por el usuario.
SERVER_PROTOCOL Devuelve el nombre y revisión del protocolo de infor-
mación bajo el que se realizó la petición.
SERVER_PORT Devuelve el número de puerto por el cual fue enviada la peti-
ción.
REQUEST_METHOD Devuelve el método por el cual la petición fue enviada.
QUERY_STRING Hace referencia a la parte de la URL con la que se llama
al programa CGI que viene inmediatamente después del símbolo '?'. Esta variable de
entorno es usada para pasar una lista de pares variable-valor usando el símbolo '&' como
delimitador de cada uno de los pares y el símbolo '=' como separador entre la variable y su
valor. Para evitar confusiones, algunos caracteres son codi�cados. Esta variable es usada
principalmente para pasar a los programas CGI información asociada a formularios.
66 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
REMOTE_HOST y REMOTE_ADDR Devuelven el nombre del host que
realiza la petición y la dirección IP del host remoto que realiza la petición respectivamente.
AUTH_TYPE Si el servidor soporta autenti�cación de usuario , y el programa
CGI está protegido, este es el método de autenti�cación especí�co del protocolo para
validar el usuario.
REMOTE_USER Si el servidor soporta autenti�cación de usuario , y el script
está protegido, este será el nombre de usuario con el que se ha autenti�cado.
REMOTE_IDENT Si el servidor HTTP soporta autenti�cación RFC 931 , en-
tonces 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 información añadida, 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 página web, bastará con imprimir ésta en pantalla
usando una función destinada a ello dentro del lenguaje de programación elegido para la
creación del programa CGI, respetando el estándar usado por el servidor para la presen-
tación de webs. En los programas CGI usados en este Proyecto Fin de Carrera se hace uso
de la función printf en combinación con HTML. Un ejemplo de esta combinación podría
ser:
printf("<HTML>\n");
printf("<HEAD>\n");
printf("<TITLE>Ejemplo de página impresa mediante CGI usando HTML\n");
3.2. ELEMENTOS SOFTWARE 67
printf("</TITLE>\n");
printf("</HEAD>\n");
printf("</HTML>\n");
Lo anterior, al ejecutarse dentro de un programa CGI escrito en C++, daría como
resultado la impresión por pantalla de una página web en blanco con la cabecera �Ejemplo
de página impresa mediante CGI usando HTML�.
Por último, se debe mencionar también que el código CGI, una vez compilado, deberá
ser guardado en la carpeta cgi-bin anteriormente indicada, con permisos de ejecución y
extensión 'cgi'.
3.2.2.3. HTML
HTML (HyperText Markup Language) es el lenguage de programación básico usado
en la web. El código de HTML hace uso del concepto de etiquetas para permitir a los
navegadores la correcta representación de las páginas web. Para comprender la forma en
la que se estructura un código HTML se puede hacer una similitud con el cuerpo humano,
ya que las etiquetas aparecen según un orden lógico, limitándose qué puede aparecer o no
antes o después 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 estándar, compuesto por recomendaciones publicadas por
un consorcio internacional: el W3C (World Wide Web Consortium). Las especi�caciones
o�ciales de HTML describen las "instrucciones" del lenguaje, pero no cómo seguirlas, es
decir, cómo las interpretan los programas informáticos. Esto permite visualizar páginas
Web independientemente del sistema operativo o la arquitectura del equipo del usuario.
Sin embargo, pese a lo detallado de las especi�caciones, existe margen para la inter-
pretación por parte del navegador y esta es la razón por la que la misma página puede
aparecer de modo diferente en un navegador u otro. Es más, algunos editores de software
agregan instrucciones HTML exclusivas que no se hallan en las especi�caciones de W3C.
68 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS
Por este motivo, las páginas 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 páginas Web deben seguir las recomendaciones de W3C, de forma que lleguen
al público más amplio posible.
Para un aprendizaje detallado acerca de HTML se recomienda consultar la especi�ca-
ción o�cial de HTML 4.0112.
12Disponible en http://www.w3.org/TR/html401/
Capítulo 4
Desarrollo del sistema
4.1. Descripción de objetivos
El sistema a desarrollar debe permitir, de manera general, transferir información 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 término lo
anteriormente descrito, comenzando por las necesidades puramente hardware necesarias
para la comunicación entre las motas/sensores y el enrutador, pasando por los distintos
elementos software desarrollados y acabando por la integración 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 instalación sin más que disponer de los elementos hardware necesarios.
4.1.1. Requisitos del sistema
Para mostrar una visión más clara del sistema desarrollado se enumeran a continuación
los requisitos, tanto funcionales como operacionales, que ejercieron de guía a la hora de
69
70 CAPÍTULO 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 información transportada en dichos datos, hacia una serie
de direcciones IP especi�cadas por el usuario.
• Conseguir la integración del desarrollo en el sistema operativo alojado en el
enrutador, de manera que se facilite la instalación 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 aplicación destinada a ejecutarse en el enrutador para ejercer las tareas de
recogida de datos de la red ZigBee/802.15.4 y, posteriormente, el envío a las
direcciones IP indicadas, deberá funcionar en segundo plano.
• Las direcciones IP que podrán ser introducidas como destinatarias deberán
cumplir con el protocolo IPv4.
• El usuario podrá añadir 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 deberán pasar a través de una
aplicación que las valide, evitándose de esta manera errores en el funcionamiento
derivados de la introducción de direcciones IP incorrectas según el protocolo
IPv4.
• El usuario podrá elegir el puerto a través del cual se enviarán los datos proce-
dentes de la red de sensores y visualizarlo desde la interfaz web.
4.2. CONECTIVIDAD ENTRE DISPOSITIVOS 71
• Los �cheros, carpetas y módulos necesarios para el correcto funcionamiento del
sistema deberán crearse o cargarse al encenderse el enrutador, de manera que
la aplicación pueda ser ejecutada en cualquier momento desde su puesta en
marcha.
• El usuario deberá tener a su disposición una interfaz que le permita conocer el
estado actual de la aplicación 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 con-
seguir la comunicación entre la red formada por las motas ZigBee/802.15.4 y el router
especi�cados1. Para lograr esta comunicación se hace uso, por un lado, de la capacidad
de conexiones vía USB del router y, por otro, de la posibilidad de replicación de los datos
intercambiados entre el microcontrolador MSP430 y el procesador CC2480 a través de la
conexión UART. Gracias a ésto, todos aquellos datos procedentes de los distintos senso-
res ZigBee/802.15.4 que llegan hasta el dispositivo coordinador pueden ser leídos usando
esta interfaz UART. Usando un conversor que permita la comunicación entre la conexión
UART y la entrada USB del router se conseguirá la transmisión de los datos procedentes
de la red de sensores hacia el mismo.
La característica necesaria para la elección del conversor fué la existencia de contro-
ladores adecuados al sistema operativo basado en un kernel 2.4 elegido para funcionar
en el router. La primera opción fué la utilización 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 disponi-
bles, pensados para su funcionamiento en un kernel 2.6 o superior. Consultando distintas
alternativas con módulos controladores para un kernel 2.4, �nalmente se eligió el coversor
TTL-232R-3V3 de FTDI descrito en la subsección 3.1.2. En la �gura 4.1 se muestra el
detalle referente a los distintos pines existentes en el conversor.
1Tal y como se indicó en la sección 3.1, se usarán las motas incluidas en el equipo de desarrollo eZ430-RF2480 de Texas Instruments para la formación de la red ZigBee/802.15.4 y el router ASUS WL-500GPremium como elemento intermedio entre ésta y la red IP.
72 CAPÍTULO 4. DESARROLLO DEL SISTEMA
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 esquemático de conexión entre MSP430 y CC2480 mostrado en la �gura 4.2
en el que se especi�ca el signi�cado de cada uno de los pines de salida del sensor.
Una vez estudiado el esquemático, se determina que los terminales del conversor y del
sensor han de ser interconectados según 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 6Orange 1Black 5Red 2
Tabla 4.1: Interconexión entre conversor y sensor
4.2. CONECTIVIDAD ENTRE DISPOSITIVOS 73
Figura 4.2: Esquemático de conexión entre MSP430 y CC2480
74 CAPÍTULO 4. DESARROLLO DEL SISTEMA
4.3. Desarrollo de la aplicación pasarela
En esta sección se presentan los detalles más importantes referidos a la aplicación
principal de este Proyecto Fin de Carrera. Se trata del programa que toma los datos
que llegan al puerto USB y los reenvía a las direcciones IP especi�cadas en el archivo
correspondiente. Dicho reenvío 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
condición se cumple, los datos serán leídos y pasarán a formar parte de un paquete UDP
(User Datagram Protocol) que será encaminado a través de la interfaz o de las interfaces
correspondiente del router para así poder alcanzar todos los destinos indicados por el
usuario de la aplicación.
El usuario deberá especi�car el puerto a través del cual desea que sean enviados los
datos procedentes de la red de sensores, así como las direcciones IP que actuarán como
destinatarias.
Se debe tener en cuenta que, a la hora de compilar la aplicación pasarela se usaron dos
compiladores distintos, según se desease ejecutarla en un ordenador o en el router. Así,
para su ejecución sobre un ordenador, cualquiera de los compiladores de C++ existentes
para Linux es válido, mientras que para su ejecución en el router se hizo uso del compilador
cruzado 'mipsel-linux-uclibc-c++'.
4.3.1. Funciones que componen la aplicación pasarela
A continuación se muestran las distintas funciones que componen la aplicación pasarela,
además de una breve descripción de su funcionamiento y sus aspectos más destacados
referentes a la composición del código fuente.
4.3. DESARROLLO DE LA APLICACIÓN PASARELA 75
void AdecuacionRouter()
Se encarga de la carga de los módulos necesarios para el correcto funcionamien-
to del conversor, de la creación de la estructura de carpetas en el sistema operativo y
de la creación e inicialización de los archivos que indican el estado, las direcciones IP
destinatarias y la página web que permite la visualización de estas direcciones.
int AbrirPuertoSerie (char *dispositivo)
Establece el vínculo con el puerto USB al que se conectará el conversor TTL-232R-
3V3 de FTDI, determinándose además su modo de apertura, en este caso de entrada y en
modo binario. Todo lo anterior se establece a través 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 con�g)
Finaliza el vínculo con el puerto USB previamente establecido a través de la fun-
ción 'AbrirPuertoSerie'. Para ello se le debe pasar como parámetro el descriptor de �chero
devuelto por ésta última función. Como actuación complementaria, con�gura el puerto
USB con los mismos parámetros existentes antes de la ejecución de la aplicación 'pasarela'
mediante el paso del parámetro 'con�g'. Este parámetro será obtenido al comienzo de la
ejecución de la pasarela, previamente al cambio de con�guración del puerto USB para
lograr el funcionamiento necesario para el correcto desempeño de la aplicación 'pasarela'.
Lo anteriormente explicado se ejecuta mediante el siguiente código:
tcsetattr(fd, TCSANOW, &config);
close(fd);
76 CAPÍTULO 4. DESARROLLO DEL SISTEMA
La función 'tcsetattr' con�gura el puerto USB asociado al indicador de �chero 'fd' se-
gún lo indicado a través del parámetro 'con�g'. Por último, 'TCSANOW' es una constante
simbólica de�nida en la librería <termios.h> que indica que el cambio de con�guración se
lleve a cabo de manera inmediata.
struct termios Con�gurarPuertoSerie (int fd, int baudios, int datos, int parada,
int paridad, int tipo_paridad, int modo, int tamano, int temporizador)
Haciendo uso de esta función se establece la con�guración del puerto USB desde el
que se leerán los datos procedentes del conversor. Tal y como se desprende de los nombres
de los parámetros, la con�guración queda determinada mediante el número de símbolos
transmitidos por segundo, los bits de parada, la existencia o no de paridad así como su
tipo, el modo de operación (canónico o no canónico), el número 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 con�guración del puerto USB
han de ser introducidos en una estructura especí�ca para tal �n, esta estructura es del
tipo struct termios. Este tipo de estructura aporta una interfaz para la con�guración de
los parámetros de comunicación con dispositivos asíncronos. 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 ejecución del cambio de con�guración del puerto USB de obtendrá la
con�guración actual del puerto para después ser devuelto a su estado original una vez ter-
minada la ejecución de la aplicación pasarela. Esta con�guración actual es proporcionada
por la función 'Con�gurarPuertoSerie' para luego ser usada por la 'CerrarPuertoSerie'.
4.3. DESARROLLO DE LA APLICACIÓN PASARELA 77
La obtención y el cambio de con�guración son llevados a cabo por las funciones 'tcge-
tattr' y 'tcsetattr' respectivamente.
static void Demonizar (void)
Mediante esta función se consigue que la aplicación pasarela sea ejecutada en
background, es decir, como un demonio o servicio. Para ello debe ser invocada al comienzo
de la función main. Su funcionamiento consiste en crear un proceso hijo que tiene su propia
copia de datos y código del padre. Además, redirigirá la salida y entrada estándar hacia
'/dev/null'.
Gracias a esto, la ejecución de la pasarela continuará sigamos o no conectados al router,
sin perjuicio para la ejecución de otras aplicaciones residentes en él.
void Lectura_y_Envio (int puerto_serie)
En esta función se realiza la lectura de la trama recibida en el puerto USB y
posterior reenvío.
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 además
de los bytes pertenecientes al campo de datos, existen otros tres bytes más enviados por
los sensores, correspondientes a los campos de comando y FCS, se podrá indicar cuantos
bytes deberán leerse a continuación hasta esperar de nuevo a la recepción 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 función 'RecibirPorPuertoSerie', que
será explicada a continuación.
Una vez que se tiene almacenada la trama completa, se procede al envío de la misma a
todos los destinatarios especi�cados 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 CAPÍTULO 4. DESARROLLO DEL SISTEMA
del mismo. Cada vez que se lea una dirección IP se creará un socket UDP en el que se
incluirá la trama procedente del conversor anteriromente leída y que llevará como destino
la dirección IP recien leída.
El proceso anteriormente descrito de recepción de trama y posterior envío de la misma
a todas las direcciones IP almacenadas como destino será repetido de manera continuada
mientras no se indique la detención de la pasarela u ocurra algún error en su ejecución.
En cuanto al proceso de creación y envío del socket, se aprecian distintas acciones
necesarias para su correcta ejecución. En primer lugar deben reservarse recursos para el
socket mediante:
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
Esta función devuelve un indicador de socket que será utilizado para hacer referencia
a él una vez creado. Como parámetros se le pasan tres constantes simbólicas. La primera
de ellas, AF_INET, indica que el socket está destinado a su envío a través de Internet. La
segunda, SOCK_DGRAM, especi�ca el uso de datagramas en lugar del establecimiento
de un circuito virtual para su envío. La tercera y última constante simbólica pasada como
parámetro, IPPROTO_UDP, indica que se debe usar el protocolo de nivel de transporte
UDP. UDP es el protocolo estándar para el nivel de transporte cuando enviamos datagra-
mas a través de redes IP por lo que también podría haberse pasado como parámetro cero,
de manera que sería el propio sistema operativo el que elegiría el protocolo para el envío
de datagramas más 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', especi�cando en ella la familia
de direcciones a las que podrá ser enviado, en este caso direcciones IP, y el puerto a través
del cual se enviará. Para este propósito se rellena la estructura como sigue:
descr_socket.sin_family = AF_INET;
descr_socket.sin_port = htons(PORT);
4.3. DESARROLLO DE LA APLICACIÓN PASARELA 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 dirección IP a la que se envía y la descripción 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 dirección IP, 'buf' la variable donde se almacena el dato
recibido procedente del conversor y 'BUFLEN' su tamaño.
int RecibirPorPuertoSerie (int fd, char *bu�er, int bu�er_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 función 'Lectura_y_Envio'. Lee tantos caracteres como se le indique
a través del parámetro, en este caso uno. Devuelve el número de bytes leídos de forma
correcta.
80 CAPÍTULO 4. DESARROLLO DEL SISTEMA
4.3.2. Diagramas de �ujo
El diagrama de �ujo asociado a la ejecución completa de la aplicación pasarela se
muestra en la �gura 4.3.
Figura 4.3: Pasarela: Diagrama de Flujo
4.3. DESARROLLO DE LA APLICACIÓN PASARELA 81
En cuanto a la función más importante incluída en la aplicación pasarela, la que realiza
la tarea de lectura y envío 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 envío: Diagrama de Flujo
82 CAPÍTULO 4. DESARROLLO DEL SISTEMA
4.4. Desarrollo de la interfaz
Para la con�guración, puesta en marcha y detención de la aplicación 'pasarela' se
dispone de varios elementos. Por un lado pueden distinguirse aquellos destinados a la ve-
ri�cación del estado y con�guración actual de la aplicación y por otro aquellos orientados
a la modi�cación de lo anterior. Para ello, las opciones disponibles a través de la interfaz
desarrollada permiten el inicio y detención de la aplicación, la adición y eliminación de
direcciones IP destinatarias de los datos procedentes de la red de sensores, la veri�cación
del estado de funcionamiento de la pasarela, la visualización de las direcciones IP actual-
mente almacenadas y la introducción y visualización del puerto a través del cual se realiza
la comunicación.
En un principio se desarrolló toda la estructura de interacción con la aplicación 'pa-
sarela' a través 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 través de dicha interfaz web. Estos proble-
mas están originados por la limitación, 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 permitía la introducción de direcciones IP destina-
tarias desde la propia interfaz web, se hacía uso del metodo POST de CGI para el paso
de parámetros. De esta manera, mediante la lectura de STDIN, así como de la lectura de
la variable de entorno CONTENT_LENGTH, que informa del número exacto de bytes
a leer, y el procesado de los datos con la función de descifrado adecuada que también se
desarrolló, se conseguía la adición de la dirección IP al sistema de reenvío de los datos.
Todo lo anteriormente descrito debió ser sustituido por otra solución debido a que la
variable de entorno mencionada se encuentra deshabilitada, como muchas otras de CGI,
por motivos de seguridad. Tan solo están disponibles para la interfaz web incluída en
el sistema operativo. Por este motivo, la interacción se realiza a través de dos sistemas
distintos. Por un lado se encuentran una serie de acciones accesibles a través de la interfaz
web y por otro aquellas acciones llevadas a cabo mediante la ejecución a modo de comando
de distintos programas de tipo shell script.
4.4. DESARROLLO DE LA INTERFAZ 83
4.4.1. Interacción a traves de la interfaz web
La interfaz web puede ser accedida a través de internet mediante la introducción de
la URL (Uniform Resource Locator) correspondiente asociada al router seguida de 'pa-
sarelazb.html'. A modo de ejemplo, y suponiendo que la URL asignada al router sea la
dirección IP 192.168.2.1, el acceso a la página principal se consigue introduciendo en el
navegador:
http://192.168.2.1/pasarelazb.html
Una vez se muestre, la primera página que aparece da la posibilidad de comprobar si
la pasarela se encuentra en funcionamiento o no, esta primera página puede verse en la
FIGURA.
Tras pulsar sobre el enlace que determina el estado de la pasarela, se pasa a la siguiente
página asociada a la interfaz. En ella se presentan las siguientes opciones:
Si la pasarela se encuentra en funcionamiento permite detener su ejecución. Si por el
contrario se encuentra detenida, se nos presenta el enlace y las instrucciones a seguir
para iniciar su ejecución.
Visualización de las direcciones IP que actualmente estan almacenadas como desti-
natarias de los paquetes procedentes de la red de sensores ZigBee.
Visualización del puerto a través del cual se envían los datos.
En la FIGURA puede apreciarse el aspecto de esta última página para el caso en el
que la aplicación se encuentre en funcionamiento.
Para la realización de esta interfaz se hizo uso de HTML y CGI,de manera que gracias
a las características de CGI se leen y modi�can los �cheros correspondientes para después,
dependiendo de los valores que hayan sido leídos en dichos �cheros, mostrar la página web
correspondiente. Por ejemplo, en el caso de la primera pantalla que se muestra, al pinchar
84 CAPÍTULO 4. DESARROLLO DEL SISTEMA
sobre el enlace que veri�ca el estado de la pasarela, la aplicación CGI se encargará de leer
el archivo 'estado' y, una vez leído su contenido, si almacenaba un uno mostrará la página
que permite detener la pasarela o, en el caso de que al archivo leído almacenara un cero,
mostrará la página con las indicaciones que permiten iniciar la pasarela.
Conviene recordar que, a la hora de compilar los archivos cgi se usaron dos compiladores
distintos, según se desease ejecutarlos en un ordenador o en el router. Así, para su ejecución
sobre un ordenador con un sistema operativo Linux, cualquiera de los compiladores de
C++ existentes para Linux es válido, mientras que para su ejecución en el router se hizo
uso del compilador cruzado 'mipsel-linux-uclibc-c++'.
4.4.2. Interacción a través de comandos
Como ya fué comentado en anteriores secciones, la limitación en el uso de las variables
de estado asociadas a CGI obligó a buscar alternativas que permitieran la interacción
deseada con la aplicación 'pasarela'. Para ello fue muy útil la utilidad integrada en la
interfaz web proporcionada por el sistema operativo DD-WRT que permite la ejecución de
comandos y que se muestra en la FIGURA. Estas mismas acciones podrían llevarse a cabo
accediendo al router a través de Telnet, sin embargo, la posibilidad de realizarlo todo sin
necesidad de usar más que un navegador web resulta más adecuada para permitir un uso
sencillo a todo tipo de usuarios, independientemente de sus conocimientos informáticos.
Para ello se ponen a disposición del usuario una serie de pequeñas soluciones que com-
plementan aquello mostrado o ejecutado a través del interfaz web asociado a la aplicación
'pasarela'. Se describen estas soluciones a continuación:
Pasarelazb: permite el inicio de la ejecución del programa principal. Está desarrollado
en lenguaje C++.
AnadirIPzb: permite la introducción de una IP destinataria de paquetes de la red
de sensores. Previamente a su almacenamiento se chequeará que la IP introducida
cumple con el estándar IP versión 4. Se trata de un script ejecutado haciendo uso del
intérprete de comandos ASH (A Shell) contenido en DD-WRT. 'AnadirIPzb' hace
4.5. CONFIGURACIÓN INICIAL AUTOMATIZADA 85
uso del script 'creacion_web_destinatarios', que actualiza la página a mostrar en
caso de querer visualizar, a través de la interfaz web, las direcciones IP almacenadas.
EliminarIPzb: permite la eliminación de la IP situada en la posición pasada como
parámetro. Dichas posiciones quedan determinadas al visualizar, a través de la in-
terfaz web, las IP destinatarias. Se tratá de un script ejecutado haciendo uso del
intérprete de comandos ASH contenido en DD-WRT. 'EliminarIPzb' hace uso del
ejecutable 'creacion_web_destinatarios', que actualiza la página a mostrar en caso
de querer visualizar, a través de la interfaz web, las direcciones IP almacenadas.
SeleccionPuerto: permite la modi�cación del puerto a través del cual se envían 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 página a mostrar en caso de querer visualizar, a través de la interfaz
web, el puerto que está siendo usado.
4.5. Con�guración inicial automatizada
Para lograr que en cada inicialización del router todo se encuentre con�gurado de
manera adecuada para usar la aplicación pasarela, es imprescindible la creación 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 creación de un shell script.
El otro método que podía haberse elegido consiste en almacenar los comandos que se
desean ejecutar en la memoria nvram, sin embargo, dicha opcion no es la más adecuada
por el uso de memoria �ash que requiere. Además de esta razón, que en este caso no era
crítica pues el script es de pequeño tamaño, se debe tener en cuenta la facilidad para
futuras modi�caciones, mucho más accesibles a través de la opción �nalmente elegida.
Para que el shell script sea ejecutado en cada inicialización 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 subsección 4.6.2.
86 CAPÍTULO 4. DESARROLLO DEL SISTEMA
El shell script desarrollado presenta la estructura que se muestra a continuación:
#! /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 crearán e inicializarán todos los directorios y archivos necesarios
para poder ejecutar la aplicación 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 intérprete de comando utilizado fué bash.
4.6. Integración 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 DD-
WRT, de esta manera, bastará instalar en el router el paquete proporcionado y, a falta
de la conexión 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:
Aplicación principal
Interfaz web
Ejecutables para la interacción con la aplicación pasarela a través de comandos
Módulos necesarios para la correcta detección del conversor
4.6. INTEGRACIÓN EN EL SISTEMA OPERATIVO DD-WRT 87
Para compilar todos estos componentes junto al sistema operativo y obtener así una
solución global y agrupada fueron necesarios tres pasos. En el primero de ellos se llevó a
cabo la extracción del �rmware DD-WRT, en el segundo se realizaron las modi�caciones
deseadas y en el tercero y último se compiló todo de nuevo obteniéndose una única solución.
Veamos estos pasos con más detalle.
4.6.1. Extracción del �rmware DD-WRT
Antes de proceder a la extracción del �rmware se debe disponer de una serie de requi-
sitos mínimos para que sea realizada con exito. Estos requisitos son:
Llevarla a cabo sobre uno de los sistemas operativos soportados por la herramienta
de extracción, a saber: Linux o OS-X. En el caso concreto de este Proyecto Fin
de Carrera, se utilizó como sistema operativo Ubuntu 10.04 ejecutándose sobre un
ordenador portatil DELL Inspiron 1545.
GNU C
GNU C++
Librerías de desarrollo estándar para C y C++
GNU make
Disponiendo de todo lo anterior, se puede pasar a utilizar la herramienta para la ex-
tracción del �rmware. Dicha herramienta puede conseguirse desde los repositorios o�ciales
proporcionados por DD-WRT2. En el paquete que se obtendrá también se encontrarán las
herramientas necesarias para la instalación de paquetes y la posterior reconstrucción del
sistema operativo.
Una vez obtenida la herramienta, se lleva a cabo la extracción mediante el uso del
comando:2Mediante el comando 'svn checkout http://�rmware-mod-kit.googlecode.com/svn/trunk/ �rmware-
mod-kit-read-only'
88 CAPÍTULO 4. DESARROLLO DEL SISTEMA
./extract_firmware.sh firmware.bin directorio_de_extracción
Debe indicarse que '�rmware.bin' es el sistema operativo DD-WRT que se preten-
de extraer3 y 'directorio_de_extracción' hace referencia al lugar donde se almacenarán
los archivos resultantes de la extracción. Por útimo, indicar que para ejecución del co-
mando 'extract_�rmware.sh' se debe estar dentro del directorio en el que se encuentre la
herramienta.
4.6.2. Modi�cación del �rmware DD-WRT
Una vez extraido el �rmware, el sistema de archivos resultante se encontrará almace-
nado 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 recons-
trucciones.
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 modi�caciones que se introducirán serán llevadas a cabo todas en este
directorio.
installed_packages: destinado a los paquetes que el usuario desea instalar en el siste-
ma operativo DD-WRT para su uso desde el mismo momento de su instalación en el
router y que no se encuentran a su disposición en la versión disponible por defecto.
Para llevar a cabo esto se hace uso de la herramienta 'ipkg_install.sh', obtenida
junto a la herramienta de extracción en el paquete obtenido desde los repositorios
de DD-WRT.
A continuación se detallan las modi�caciones llevadas a cabo dentro del sistema de
archivos contenido en la carpeta 'rootfs', indicando aquellos directorios en los que se han
añadido elementos y de qué elementos se tratan para cada caso:3En este caso DD-WRT versión 24 (build 12188)
4.6. INTEGRACIÓN EN EL SISTEMA OPERATIVO DD-WRT 89
bin: se añade el ejecutable destinado a la creación de la página web, los ejecutables
para la interacción con la aplicqación mediante el uso de comandos y la aplicación
principal de la pasarela.
etc/con�g: se añade el archivo que se ejecutará en cada encendido del router para
su lograr la adecuada con�guración permitiendo así el correcto funcionamiento de la
aplicación pasarela una vez que el router se encuentra inicializado.
lib: añadidos los módulos 'usbserial.o' y 'ftdi_sio.o' para permitir la detección y
posterior manejo del conversor conectado al puerto USB usado en este Proyecto Fin
de Carrera.
www: añadida la pagina html que servirá como inicio del interfaz web de la aplicación
pasarela. Además, se crea dentro la carpeta 'cgi-bin' en la que se almacenarán los
archivos cgi necesarios para la interacción con los archivos que indican el estado
actual de la pasarela en cuanto a funcionamiento y con�guración.
4.6.3. Reconstrucción 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 accción 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_extracción/
Siendo 'directorio_de_salida' el lugar donde se almacenarán las reconstrucciones del
�rmware y 'directorio_de_extracción' el lugar donde está el sistema de archivos extraído
y posteriormente modi�cado.
90 CAPÍTULO 4. DESARROLLO DEL SISTEMA
Por último, indicar que la herramienta reconstruirá el �rmware y presentará diversas
versiones, diferenciadas entre ellas por el hecho de estar optimizadas para su instalación en
routers de distintos fabricantes. También se incluye una versión reconstruida del �rmware
genérica.
4.7. Aplicación cargada en los sensores ZigBee/802.15.4
Para poder determinar el correcto funcionamiento de la aplicación 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 aplicación que haga uso de la
capacidad de monitorización y posterior envío de los datos monitorizados a través 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 aplicación ZASA (ZigBee
Accelerator Sample Application), aportada por Texas Instruments a modo de ejemplo de
uso, es ideal para el propósito deseado.
La aplicación ZASA puede hacer que los sensores actúen de dos maneras distintas,
como sumideros o como fuentes de infomación. 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 especi�cación ZigBee/802.15.4: coordinador, enrutador o dispositivo �nal.
De esta manera, los datos recolectados y enviados por aquellos sensores que actúen como
fuente de información serán el voltaje del bus y la temperatura ambiente. La con�guración
del papel dentro de la red será determinada en base a la actuación sobre el botón incluido
en el CC2480 e informada a través de un código de colores mediante dos indicadores
luminosos. Los sensores se con�guran con dos posibles acciones, pulsando el botón incluido
en CC2480 una o dos veces. Se muestran a continuación las distintas posibilidades:
Si se pulsa el botón una vez en dos segundos intentará con�gurarse como enrutador
dentro de una red ya existente, actuando además 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. APLICACIÓN CARGADA EN LOS SENSORES ZIGBEE/802.15.4 91
LED verde encendido en caso de actuar como enrutador.
Si se pulsa el botón dos veces en dos segundos, el sensor quedará con�gurado como
un dispositivo �nal y, por lo tanto, actuará como fuente de datos. Esto quedará
indicado a través del parpadeo del LED de color verde a una frecuencia de 1Hz.
Para completar el código usado a traves de los LED incluidos, caben destacarse los
siguientes casos:
Ambos LED parpadeando indican que el sensor aún no ha sido con�gurado.
En el caso de que los sensores actúen como enrutador o dispositivo �nal, una vez
que envían 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 recepción de un paquete de datos.
Para adecuar la aplicación ZASA a ciertas características propias del desarrollo llevado
a cabo en este Proyecto Fin de Carrera, se han incluido modi�caciones en su código que
a continuación 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 actuación dentro de la
red la de dispositivo coordinador. Esto es así porque dicha función va directamente
ligada a su conexión con el router y por lo tanto no tiene ningún sentido que se
deba determinar, a través de la pulsación del botón, su papel en la red. Además, de
esta manera se prevén posibles fallos derivados de cortes de luz y reinicios del router
puesto que al estar pensado para su funcionamiento autónomo, el hecho de tener
que estar �sicamente presente para la con�guración de este sensor podría hacerle
perder al conjunto la facilidad y comodidad de uso que se pretende. Para conseguir
esta con�guración automática como coordinador anteriormente descrita se modi�có
el código incluido en 'sample_app.c', suprimiéndose el funcionamiento de la función
'appBtnPress' para de esta manera deshabilitar la interacción a través del botón e
92 CAPÍTULO 4. DESARROLLO DEL SISTEMA
incluyéndose la variable 'timerboton' en combinación con otras llamadas a funciones
para conseguir la con�guración como coordinador que se desea.
Para los sensores que actúan como fuentes de datos (ya sean enrutadores o disposi-
tivos �nales), se añade un campo en la trama enviada que los identi�ca de manera
física, no a través de la dirección de red que asigna el protocolo basada en la asig-
nación distribuida de direcciones. De esta manera, se puede identi�car a que sensor
corresponde cada paquete recibido sin necesidad de saber cual se conectó a la red
en primer lugar, proporcionando un método de identi�cación más claro. Para lograr
este propósito 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
función 'appSrceData', se determina el número que identi�cará a cada sen-
sor. Por ejemplo, para establecer el número identi�cativo del sensor a uno, se
debería intoducir en el código:
srceReport[SRCE_REPORT_ZBID] = 1;
Capítulo 5
Fase de pruebas
5.1. Descripción 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 debían ir veri�cando para de esta manera construir
cada nuevo paso sobre una base sólida en lo referente a su funcionamiento. Como entorno
de prueba se usarón dos elementos para la veri�cación, variando este entorno según la fase
del proyecto en la que se ejecutaron las pruebas, como se mostrará más adelante.
Se pueden diferenciar dos entornos de pruebas:
Ordenador DELL Inspiron 1545, equipado con 4 Gb de memoria RAM y un pro-
cesador 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 realizarán una serie de
veri�caciones que determinarán si el desarrollo cumple con los requisitos operacionales y
93
94 CAPÍTULO 5. FASE DE PRUEBAS
funcionales que fueron de�nidos para el proyecto.
5.2. Procesos de veri�cación
El objetivo de los procesos de veri�cación es la búsqueda de defectos en el sistema
debidos a errores en el proceso de desarrollo para así evitar la posterior aparicición de
fallos. Estas actividades de veri�cación se llevan a cabo mediantte un conjunto de pruebas,
pudiéndose utilizar distintos métodos, para este caso concreto el método usado para la
veri�cación ha sido el método a través de experimentos, esto es, la prueba del sistema
desarrollado mediante la simulación de las condiciones reales en las que debe desempeñar
su función, observando y analizando su funcionamiento.
Para llevar a cabo el proceso de veri�cación se determina una secuanciación bottom-
top, partiendo del correcto funcionamiento de los elementos unitarios y acabando en la
veri�cación de la combinación 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 funcio-
namiento de los distintos elementos en este entorno, éstos quedaban validados para su
posterior integración 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 progresión: la primera prueba que se realiza al elemento.
Pruebas de corrección: repetición de una prueba tras haber sido detectado un error
y haberse realizado un cambio.
5.2. PROCESOS DE VERIFICACIÓN 95
Pruebas de regresión: volver a ejecutar una prueba que ya se había pasado satisfac-
toriamente tras realizar un cambio.
Siguiendo la secuenciación temporal llevada a cabo en el desarrollo se exponen a
continuación las pruebas unitarias de cada elemento:
Pasarelazb
Para la veri�cación de este elemento se hizo uso del ordenador DELL Inspiron
1545 en combinación con el conversor TTL-232R-3V3 de FTDI y los sensores incluidos
en el equipo de desarrollo eZ430-RF2480 de Texas Instruments. La veri�cación se llevó
a cabo de forma progresiva, añadiendo las distintas funciones de las que se compone de
manera escalonada según el siguiente orden:
1. Funciones para el manejo, con�guración y lectura del puerto USB.
2. Función destinada al envío de los datos leídos del puerto USB a una dirección IP y
un puerto �jos.
3. Adición de lectura de archivo para indicar la interrupción de la aplicación.
4. Adición de lectura de �cheros para permitir la modi�cación de las direcciones IP de
destino y del puerto a usar.
5. Función que permite la ejecución 'pasarelazb' en background.
Para llevar a cabo la prueba se conectó el conversor al sensor que actua como coor-
dinador 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 asigna-
ba1 y hecha la correspondiente modi�cación del mismo en el código fuente se procedía a
la ejecución del programa habiendo previamente con�gurado los demás sensores para su
funcionamiento como enrutadores o dispositivos �nales.
1De tipo ttyUSB#
96 CAPÍTULO 5. FASE DE PRUEBAS
Una vez se encontraba el programa en funcionamiento y los dispositivos correctamente
con�gurados se procedía a la comparación de los datos obtenidos a través de la aplicación
'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 más clara se hacía uso de un postprocesado
mediante XVI32 (descrito en 3.2.1.6). De esta manera, se fueron ajustando los parámetros
de con�guración asociados al puerto USB hasta conseguir la lectura de los datos tal y
como eran obtenidos a través de Putty.
Así, para poder visualizar los datos leídos a través del conversor se introdujo en el código
fuente del programa 'pasarelazb' las líneas necesarias para la impresión por pantalla de
todos los caracteres que iban siendo leídos del conversor, de manera que pudiera realizarse
la comparación anteriormente mencionada. Estas líneas permitían la lectura y correcta
impresión de los datos en formato hexadecimal. Se muestra a continuación como ejemplo
el código que posibilita la impresión por pantalla del preámbulo 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 recepción de los datos, se pasó al envío de éstos a
una dirección �ja. Para facilitar la veri�cación de los envíos se decidió que esta dirección
de destino fuese el localhost. Además se desarrollaró una sencilla aplicación que actuara
recepcionando estos datos. Así, haciendo uso de la visualización introducida en 'pasarelazb'
y de esta aplicación de recepción se pudo constatar el correcto envío a la dirección IP
indicada. Se muestra a continuación la parte del código de la aplicación de recepción que
permite visualizar lo enviado por la aplicación '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 añadió la lectura de un archivo a través del cual se especi�ca si la
aplicación debe seguir ejecutándose o no, su chequeo consistió en la modi�cación manual
5.2. PROCESOS DE VERIFICACIÓN 97
de dicho �chero para determinar la interrupción de 'pasarelazb' en el momento debido.
Tras lograr la correcta recepción y posterior envío de los paquetes se añadió la posibi-
lidad de lectura de puerto y dirección IP desde un archivo que podía ser modi�cado. Con
el objetivo de probar esta adición se creó el �chero de destinatarios con la dirección IP
127.0.0.1 (localhost) y se usó la aplicación de recepción anteriormente mencionada de ma-
nera que quedara comprobaa la correcta interpretación de la dirección IP introducida en
el �chero. De igual manera y siguiendo el mismo proceso se comprobó la correcta lectura
e interpretación del archivo destinado a indicar el puerto a usar para el envío de los datos.
Por último, se añadió la función que permitía la ejecución de todo lo anterior en
background. Comprobando que a pesar de ejecutarse como un demonio seguía cumpliendo
todo lo anteriormente veri�cado.
Shell scripts
Para la veri�cación de los shell scripts en el entorno de pruebas indicado se usó
bash, incluido por defecto en la instalación de Ubuntu 10.04, como intérprete de comandos.
Una vez indicado esto, su prueba se basó en comprobar que modi�caban, borraban y crea-
ban los directorios y archivos de la manera en la que debian según los distintos requisitos.
Se detallan a continuación las distintas veri�caciones realizadas en cada shell script :
AnadirIPzb: la veri�cación de este script se llevo a cabo comprobando por separado
cada una de las tareas de las que se compone y veri�cando después su funcionamiento
conjunto, de esta manera, el orden seguido a la hora de veri�car e integrar funciones
dentro del script fué el siguiente:
1. Veri�cación de que la dirección 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, comprobándose que todas
ellas eran detectadas como no válidas. Una vez hecho esto, y tras comprobar que
las direcciones IP formadas por cuatro partes eran clasi�cadas como válidas,
98 CAPÍTULO 5. FASE DE PRUEBAS
se procedió a comrpobar que también eran descartadas todas aquellas direccio-
nes formadas por cuatro partes pero no separadas por un punto, veri�cándose
también este extremo.
2. Veri�cación de que todas y cada una de las cuatro partes de las que se compone
la dirección IP introducida están compuestas tan solo de valores numéricos.
Para la veri�cación 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 dirección IP contenían un valor no numérico. En todos los
casos fué detectado dicho valor y, por lo tanto, clasi�cadas como direcciones IP
no válidas.
3. Veri�cación de que todas y cada una de los cuatro valores numéricos de los
que se compone la dirección IP introducida se encuentran dentro del rango
permitido.
Para la veri�cación 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 dirección IP contenían un valor numérico por encima de
255. En todos los casos fué detectado dicho valor y, por lo tanto, clasi�cadas
como direcciones IP no válidas.
4. Si todo lo anterior se cumple, almacenamiento en el �chero correspondiente de
la dirección IP introducida.
La veri�cación de este punto consistió en introducir una dirección IP válida
y comprobar su correcto almacenamiento en el �chero indicado.
5. Por último, eliminación de posibles direcciones IP repetidas dentro del �chero.
La veri�cación de este punto consistió en introducir de manera consecutiva
dos direcciones IP válidas iguales y la posterior comprobación de que solo se
almacenaba una vez en el �chero.
Siguiendo este orden, a medida que un objetivo cumplía con los requisitos de
uno de los puntos anteriores se añadía el siguiente, partiendo de la base de lo que ya
se había desarrollado y veri�cado.
5.2. PROCESOS DE VERIFICACIÓN 99
EliminarIPzb: para veri�car este script se hizo uso de 'AnadirIPzb', mediante el
cual se almacenaron varias direcciones IP para, posteriormente y tras seleccionar el
número de línea correspondiente a la dirección IP que se deseaba eliminar, hacer uso
de 'EliminarIPzb' y comprobar que se había eliminado la dirección IP que ocupaba
el número de línea seleccionado y que, además, aquellas que ocupaban posiciones
inferiores habían sido desplazadas convenientemente.
SeleccionPuerto: la veri�cación de este script se llevó a cabo en dos fases que a
continuación se detallan
1. Veri�cación de detección de valores no permitidos.
Para la comprobación de este requisito se desarrolló el código necesario
para detectar,y en tal caso desechar, toda aquella introducción de puerto que
no se trate de un número dentro de un rango determinado. Con el objetivo
de probar su funcionamiento se introdujeron valores no nu �mericos además de
valores fuera del rango permitido, habiéndose dettectado en todos los casos y
posibles combinaciones la no validez del valor introducido.
2. Eliminación del anterior valor almacenado y almacenamiento del valor introdu-
cido en caso de ser detectado como válido.
En este caso se introducía un valor válido y se comprobaba su correcto al-
macenamiento. Posteriormente se introducía otro valor también válido, compro-
bándose que éste último había sustituído de manera adecuada al anteriormente
almacenado.
Ejecutables destinados a la creación de un HTML
Aquí se incluye tanto 'creacion_web_destinatarios' como 'creacion_web_puerto'.
El funcionamiento de los dos es completamente análogo por lo que el proceso de veri�-
cación seguido con los dos fué el mismo, consistiendo en la veri�cación de la correcta
generación de un archivo con extensión 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 veri�cación consistió en introducir en
los �cheros una serie de datos haciendo uso de 'AnadirIPzb' o 'SeleccionPuerto' y abrir
100 CAPÍTULO 5. FASE DE PRUEBAS
con el explorador Firefox incluido en Ubuntu 10.04 la página 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 página 'pasarelazb.html' de inicio de la
interfaz como los ejecutables 'Estado.cgi' y 'Detener.cgi'. Veamos el proceso de veri�cación
de cada uno de ellos:
Pasarelazb.html: la veri�cación consistió en su visualización haciendo uso del explo-
rador Firefox.
Estado.cgi: dado que este ejecutable debe leer un archivo y según su cobtenido mos-
trar una página u otra, su prueba consistió en la modi�cación manual de dicho archivo
y en la veri�cación de que semostraba por pantalla la página HTML adecuada.
Detener.cgi: este ejecutable debe modi�car un archivo y posteriormente mostrar
una página HTML. Para su veri�cación se comprobó la modi�cación adecuada del
correspondiente archivo y la visualización correcta de la página HTML.
5.2.2. Pruebas de integración
A la hora de llevar a cabo la integración de distintos elementos unitarios ya veri�cados,
se siguió una secuenciación que permitía la detección de posibles fallos en dicha integración
de manera rápida. Las pruebas de integración y su correcta secuenciación están enfocadas
a encontrar problemas de interacción entre los distintos elementos que van integrándose.
Se detalla a continuación el plan seguido para la integración:
1. Lectura por parte de la aplicación 'pasarelazb' de los archivos modi�cados por
'AnadirIPzb' y 'SeleccionPuerto'.
2. Posterior adición de 'EliminarIPzb', siendo el archivo modi�cado por este script
aquel modi�cado por 'AnadirIPzb'.
5.2. PROCESOS DE VERIFICACIÓN 101
3. Creación de los enlaces entre distintas páginas HTML de la interfaz web.
4. Enlace de los ejecutables 'Estado.cgi' y 'Detener.cgi' con los archivos modi�cados
y/o leídos por 'pasarelazb'.
5.2.3. Pruebas de sistema
Una vez integrado el sistema, es decir, construido el último nivel de integración 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 veri�cado al router
gracias a la compilación cruzada y a la construcción del �rmware DD-WRT con las adi-
ciones desarrolladas en este Proyecto Fin de Carrera, se pasó a la veri�cación global del
sistema en el entorno bajo el que debe cumplir con los requisitos. Se detallan a continuación
los requisitos funcionales que implicaron pruebas de sistema:
Se usará el protocolo UDP.
Una vez ejecutada la aplicación 'pasarelazb' se hacía uso de la aplicación de
recepción también desarrollada para comprbar el correcto uso del protocolo de trans-
porte UDP.
La aplicación destinada a ejecutarse en el enrutador para ejercer las tareas de reco-
gida de datos de la red ZigBee/802.15.4 y, posteriormente, el envío a las direcciones
IP indicadas, deberá funcionar en segundo plano.
Su veri�cación consistió en la ejecución del ejecutable 'pasarelazb' y, posterior-
mente, accediendo a través Telnet comprobación de que se encontraba en ejecución
mediante el comando 'ps'.
El usuario podrá añadir o eliminar direcciones IP destino en cualquier momento,
independientemente de si el sistema se encuentra en funcionamiento o no.
102 CAPÍTULO 5. FASE DE PRUEBAS
Una vez encontrándose el ejecutable 'pasarelazb' en funcionamiento se añadían
y eliminaban direcciones IP, funcionando en todo momento de manera correcta y
variando adecuadamente su funcionamiento en función de lo introducido.
El usuario deberá ser capaz de visualizar las direcciones IP que se encuentran ac-
tualmente almacenadas como destinatarias de los datos procedentes de la red Zig-
Bee/802.15.4.
Su veri�cación consistió en la visualización de la página correspondiente a través
del acceso remoto al router.
El usuario podrá elegir el puerto a través del cual se enviarán los datos procedentes
de la red de sensores y visualizar el puerto usado desde la interfaz web.
La modi�cación del puerto quedó veri�cada haciendo uso de 'SeleccionPuerto'
en combinación con la aplicación de recepción desarrollada, que era programada
para usar el puerto que se introducía y, de esta manera, constatar el correcto uso del
mismo. Posteriormente se procedió a la visualización a través de la interfaz web del
puerto previamente introducido.
Los �cheros, carpetas y módulos necesarios para el correcto funcionamiento del siste-
ma deberán crearse o cargarse al encenderse el enrutador, de manera que la aplicación
pueda ser ejecutada en cualquier momento desde su puesta en marcha.
La aplicación WinSCP (descrita en 3.2.1.4) permitió veri�car 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 disposición una interfaz que le permita conocer el estado
actual de la aplicación en cuanto a su funcionamiento o no.
Esto fue veri�cado iniciando y deteniendo el ejecutable 'pasarelazb' y con�rman-
do que era mostrado el mensaje correcto según se encontrará o no en funcionamiento.
Capítulo 6
Conclusiones y líneas futuras de trabajo
En el presente capítulo se expondrán las conclusiones deducidas del desarrollo de este
Proyecto Fin de Carrera. Además se mencionarán posibles líneas de investigación y estudio
que permitirían la continuación 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 continuación se detallan:
Realización de una pasarela Zigbee/802.15.4-IP sobre un router comercial.
Posibilidad de seleccionar distintas IP destinatarias así como el puerto a través del
cual se desean enviar los datos procedentes de la red de sensores ZigBee.
Utilización, en el router sobre el cual funcionará el desarrollo, de un sistema operativo
de código abierto.
103
104 CAPÍTULO 6. CONCLUSIONES Y LÍNEAS FUTURAS DE TRABAJO
Permitir al usuario la interacción con la pasarela a través de una interfaz web, de
manera que no se necesiten conocimientos añadidos a la ya habitual y comunmente
utilizada navegación en Internet.
Integración del desarrollo completo en el sistema operativo elegido, quedando todo
con�gurado e instalado de la manera más cómoda posible para el usuario.
Además de los objetivos anteriormente expuestos y exigidos, a título 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 realización de este Proyecto Fin de Carrera,
estos son:
Estudio del conjunto de soluciones estandarizadas ZigBee/802.15.4.
Manejo y con�guración, a través del lenguaje C++, de los puertos disponibles en un
dispositivo equipado con un sistema operativo basado en Linux.
Conocimientos básicos de HTML y scripting.
Aprendizaje de la estructura y de las posibilidades de con�guración y modi�cación
del sistema operativo de código abierto DD-WRT.
Conocimientos acerca de los distintos pasos a seguir a la hora de realizar un proyecto
desde cero, desde la fase de documentación y estudio hasta la realización del plan
de pruebas, pasando por el estudio de distintas alternativas y acabando con este
documento.
6.2. Líneas futuras de trabajo
Como consecuencia del continuo aumento de necesidades relacionadas con la moni-
torización tato en el ámbito de la industria, como en el ámbito médico o residencial,
ZigBee/802.15.4, en combinación con el desarrollo llevado a cabo en este Proyecto Fin
6.2. LÍNEAS FUTURAS DE TRABAJO 105
de Carrera, puede cubrir una amplia variedad de estas necesidades. Se detallan a conti-
nuación algunas variantes que, partiendo de este desarrollo, podrían aportar soluciones
interesantes:
Añadir comunicación desde el usuario hacia la red de sensores ZigBee para permitir
cambios en su con�guración. Esta posibilidad implicaría casi con total seguridad un
cambio en la elección de los sensores, ya que los usados en este desarrollo admiten
una limitada capacidad de con�guración.
Adición de soporte para direcciones IPv6 ya que el agotamiento de las direcciones
IPv4 hará imprescindible su uso en pocos años.
Integración total del interfaz web en la misma estructura añadiendo módulos y uti-
lizando otras opciones de comunicación entre HTML y los ejecutables como podría
ser PHP.
106 CAPÍTULO 6. CONCLUSIONES Y LÍNEAS FUTURAS DE TRABAJO
Apéndice A
Manual de usuario
A.1. Instalación del sistema operativo en el router
A.1.1. Actualización desde otra versión de DD-WRT
A.1.2. Instalación en otros casos
A.2. Con�guración inicial
A.3. Manejo de la interfaz
107
108 APÉNDICE A. MANUAL DE USUARIO
Bibliografía
[1] DD-WRT O�cial Web Page. Disponible en http://www.dd-wrt.com/site/index.
[2] ASUS. WL-500g Premium Features. Disponible en
http://www.asus.es/product.aspx?P _ID=8el2DcrRjLoHNdQ8&templete=2.
[3] BlackCode Magazine. A brief programming tutorial in C for raw sockets. Disponible
en http://mixter.void.ru/rawip.html.
[4] Per Bothner. Sockets Tutorial. Disponible en
http://www.linuxhowtos.org/C_C++/socket.htm.
[5] Dora Castañeda, Diana Bacca, and Gustavo Higuera. Estudio de la tecnología Zig-
bee y la implementación en la aplicación de sensores remotos, 2010. Disponible en
http://www.iiis.org/cds2010/cd2010csc/cisci_2010/PapersPdf/ca371me.pdf.
[6] Cristian Castiblanco. Programación Shell en Linux. Disponible en
http://casidiablohost.googlepages.com/ProgramacinenshellLinux.pdf.
[7] H.M. Deitel and P.J. Deitel. C++ Cómo Programar. Prentice Hall, 1999.
[8] Ata Elahi and Adam Gschwender. Introduction to the Zig-
Bee Wireless Sensor and Control Network, 2009. Disponible en
http://www.informit.com/articles/article.aspx?p=1409785&seqNum=4.
[9] José Tomás Entrambasaguas Muñoz. Ingeniería de desarrollo de Sistemas de Teleco-
municación. Servicio de Publicaciones e Intercambio Cientí�co de la Universidad de
Málaga, 2008.
109
110 BIBLIOGRAFÍA
[10] Shahin Farahani. ZigBee Wireless Networks and Transceivers. Elsevier, 2008.
[11] Drew Gislason. ZigBee Wireless Networking. Elsevier, 2008.
[12] Mareca Hatler, Darryl Gurganious, Charley Chi, and Mike Ritter. A Market Dyna-
mics report on IEEE802.15.4 and ZigBee. ON World, 2010.
[13] Janell Armstron. C. Richard Helps. Comparative Evaluation of ZigBee and Blue-
tooth: Embedded Wireless Network Technologies for Students and Designers., 2007.
Disponible en http://icee.usm.edu/icee/conferences/asee2007/papers/ 1242_compa-
rative_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. Getting Started with CGI Programming in C, 2010. Disponible en
http://www.cs.tut.�/�jkorpela/forms/cgic.html.
[16] Ed Callaway. Florida Communication Research Lab & Motorola Labs. Low Power
Consumption Features of the IEEE 802.15.4/ZigBee LR-WPAN Standard., November
2003. Disponible en http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf.
[17] Jin-Shyan Lee, Yu-Wei Su, and Chung-Chou Shen. A Comparative Study of
Wireless Protocols: Bluetooth, UWB, ZigBee, and Wi-Fi, 2007. 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
Converter Cable, 2006. Disponible en http://eris.liralab.it/viki/images/c/c1/FTDI_-
_serial_converter_cable_TTL232R.pdf.
[19] Jordi Mayné. Estado actual de las Comunicaciones por Radio Frecuencia, 2009. Dis-
ponible en http://www.bairesrobotics.com.ar/data/estado_actual_de_las _comuni-
caciones_por_radiofrecuencia.pdf.
[20] Daintree Networks. Getting Started with ZigBee and IEEE 802.15.4, 2008. Disponible
en http://www.daintree.net/downloads/whitepapers/zigbee_primer.pdf.
[21] Patrice Oehen. ZigBee: An Overview of the Upcoming Standard., October 2005. Dispo-
nible en http://www.dcg.ethz.ch/lectures/ws0506/seminar/materials/zb_slides.pdf.
BIBLIOGRAFÍA 111
[22] Juan R. Pozo. Tutorial de HTML, 2003. Disponible en
http://html.conclase.net/tutorial/html/.
[23] Michael R. Sweet. Serial Programming Guide for POSIX Operating Systems, 2005.
Disponible en http://www.easysw.com/�mike/serial/serial.html.
[24] IAR Systems. MSP430 IAR Embedded Workbench ID, 2006.
[25] Iñigo Tejedor and Pello Altadill. Taller Shell, comandos y programación. Disponible
en http://4party.cuatrovientos.org/�les/2007/shell_linux.pdf.
[26] Texas Instruments. Z-Accel 2.4 GHz ZigBee Processor. Disponible en
http://focus.ti.com/lit/er/swra175a/swra175a.pdf.
[27] Texas Instruments. eZ430-RF2480 Demonstration Kit: User's Guide, 2008. Disponi-
ble en http://focus.ti.com/lit/ug/swru151a/swru151a.pdf.
[28] Texas Instruments. CC2480 Target Board Reference Design 1.4, 2009. Disponible en
http://www.ti.com/litv/zip/swru156a.
[29] TIOBE Software. TIOBE Programming Community Index for December 2010. Dis-
ponible en http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html.
[30] Jorge Carlos Valverde Rebaza. El Estándar inalámbrico ZigBee, 2007. Disponible en
http://www.seccperu.org/�les/ZigBee.pdf.
Top Related