webpersonal.uma.eswebpersonal.uma.es/~ECASILARI/Docencia/Memorias_Presentaciones_… · SAP Service...

��

��

� ��

� ��

��

��

��

��

��

�� !∀#�∃%��%&∋%�∋()∀�∗∋��∋!∋#+, %�#∀#�∃%

∋ %�∗+�∋!��(�− %∀!�∋.∀,�%∀∗+(�∋%�∋!�∗)∀�∗∋�!∀�/∋#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

Í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


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


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.


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.


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.

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


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


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


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.


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.


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]


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


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:


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.


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]


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


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.


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


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.


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


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


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


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


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


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.


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


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.

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.


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


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.


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


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.


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


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


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


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:


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]


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


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


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:


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


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


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


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.


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


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


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:


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.


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");


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.


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.


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


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


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


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


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


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.


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


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


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


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.


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'


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


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


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#


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


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,


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.


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


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


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.


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.

webpersonal.uma.eswebpersonal.uma.es/~ECASILARI/Docencia/Memorias_Presentaciones_… · SAP Service...

Documents

Transcript of webpersonal.uma.eswebpersonal.uma.es/~ECASILARI/Docencia/Memorias_Presentaciones_… · SAP Service...