INGENIERÍA DE TELECOMUNICACIÓN - Servicio …webpersonal.uma.es/~ECASILARI/Docencia/Memorias_Presentaciones_… · IEEE Institute of Electrical and Electronics Engineers IR Infra

ESCUELA TÉCNICA SUPERIOR DE

INGENIER ÍA DE TELECOMUNICAC IÓN

UNIVERS IDAD DE MÁLAGA

P RO YE C TO F I N D E C ARR E R A

CARACTERIZACIÓN DEL CONSUMO EN REDES

ZIGBEE/802.15.4

I NGEN I ER Í A D E T E LECOMUN I CAC IÓN

MÁLAGA , 2009 GONZALO CAMPOS GARR IDO




Titulación: Ingeniería de Telecomunicación

Reunido el tribunal examinador en el día de la fecha, constituido por:

D./Dª.__________________________________________________________

D./Dª.__________________________________________________________

D./Dª.__________________________________________________________

para juzgar el Proyecto Fin de Carrera titulado:

CARACTERIZACIÓN DEL CONSUMO EN REDES

ZIGBEE/802.15.4

del alumno/a D. Gonzalo Campos Garrido

dirigido por D. Eduardo Casilari Pérez

ACORDÓ POR ______________________________________ OTORGAR LA

CALIFICACIÓN DE _______________________________________________

Y, para que conste, se extiende firmada por los componentes del tribunal, lapresente diligencia

Málaga, a ______ de __________________ de _________

El/La Presidente/a El/La Vocal El/La Secretario/a

Fdo.: _________________ Fdo.: _________________ Fdo.: _________________




CARACTERIZACIÓN DEL CONSUMO EN REDES ZIGBEE/802.15.4

REALIZADO POR:

Gonzalo Campos Garrido

DIRIGIDO POR:

Eduardo Casilari Pérez

DEPARTAMENTO DE: Tecnología Electrónica

TITULACIÓN: Ingeniería de Telecomunicación

PALABRAS CLAVE: Consumo, ZigBee, 802.15.4, CC2480

RESUMEN: En este proyecto se realiza una caracterización del consumode corriente de nodos ZigBee/802.15.4. Se particularizarán los resultadosatendiendo a los distintos tipos de nodos que forman una red ZigBee asícomo a la tarea que realiza cada uno.

Málaga, Junio de 2009

Agradecimientos

Quisiera agradecer a mis padres, Bartolomé y Celia, el apoyo constante que siempre me han ofrecido. Sin

su ayuda, consejo y motivación, jamás habría conseguido llegar hasta aquí.

También me gustaría dar las gracias a mi tutor, Eduardo Casilari. Su ecaz y rápida ayuda, el interés

por este proyecto y, en general, su simpatía mostrada hacia mi, han facilitado enormemente mi trabajo

durante estos últimos meses.

i

ii

Acrónimos

ACLK Auxiliary Clock

ADC Analog to Digital Converter

AF Application Framework

APS Application Support Sub-Layer

AREQ Asynchronous Request

BI Beacon Interval

BO macBeaconOrder

CAP Contention Access Period

CCA Clear Channel Assessment

CCM Counter with CBC-MAC

CFP Contention Free Period

DCO Digitally-Controlled Oscillator

FCS Frame Check Sequence

FHSS Frequency Hop Spread Spectrum

GPIB General Purpose Interface Bus

GTS Guarantee Time Slots

HAL Hardware Abstraction Layer

IEEE Institute of Electrical and Electronics Engineers

IR Infra Red

ISM Industrial, Scientic and Medical

ISR Interrupt Service Routine

iii

iv

ITU International Telecommunication Union

LED Light-Emitting Diode

LPM Low Power Mode

LQI Link Quality Indicator

MAC Medium Access Control

MCLK Main Clock

MT Monitor Test

NV Non-volatile Memory

OFDM Orthogonal Frequency Division Multiplexing

PAN Personal Area Network

PDU Protocol Data Unit

PPDU Physical Protocol Data Unit

RAM Random Access Memory

RF Radio Frequency

RISC Reduced Instruction Set Computer

SD Superframe Duration

SIG Special Interest Group

SMCLK Submain Clock

SO mac Superframe Order

SOF Start of Frame Indicator

SPI Serial Peripheral Interface

SREQ Synchronous Request

SRSP Synchronous Response

SYS Interfaz de Sistema

UART Universal Asynchronous Receiver-Transmitter

UWB Ultra-Wideband

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.1.1. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.2. Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.3. Ultra-WideBand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2. Estándares de bajo consumo: aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4. Estructuración de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2. ZigBee/802.15.4 11

2.1. Introducción a ZigBee/802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Topología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1. Topología en estrella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2. Topología en malla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3. Topología en árbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3. Capa Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4. Capa MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.1. Descripción general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.2. Modos de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.3. Algoritmo CSMA-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.4. Inicialización y mantenimiento de PAN . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4.5. Formato de trama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5. Capa de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23


2.5.2. Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.5.3. Formato de trama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6. Capa de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28


2.6.2. Subcapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6.3. Formato de trama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.7. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.8. Implementaciones comerciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

v

vi ÍNDICE GENERAL

3. Herramientas de desarrollo empleadas y sistema de medida 37

3.1. Kit de desarrollo eZ430-RF2480 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.2. CC2480 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.3. MSP430 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.1.4. Esquemático de conexión entre CC2480 y MSP430 . . . . . . . . . . . . . . . . . . 57

3.1.5. Aplicación de ejemplo ZASA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2. Herramientas de instrumentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.2.1. Osciloscopio Tektronix TDS 3012B . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.2.2. Fuente de alimentación Tektronix PS2520G . . . . . . . . . . . . . . . . . . . . . . 65

3.2.3. Multímetro HP34401A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.2.4. CC2520 Evaluation Module Kit y SmartRF05 Evaluation Board . . . . . . . . . . 66

3.3. Herramientas software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.3.1. Sensor Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.3.2. Z-Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.3.3. Packet Snier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.3.4. IAR Embedded Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.3.5. MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.4. Circuito de medida empleado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.4.1. Esquema general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.4.2. Amplicador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.4.3. Filtro paso bajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4. Estudio del consumo 77

4.1. Encendido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.2. Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.2.1. Coordinador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.2.2. Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.2.3. Dispositivo nal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.3. Recepción y envío de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.3.1. Coordinador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.3.2. Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.3.3. Dispositivo nal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

4.4. Pérdida de conexión con el dispositivo padre . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.4.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.4.2. Dispositivo nal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.5. Tabla de resumen de consumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5. Conclusiones y líneas futuras de trabajo 111

5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

5.2. Líneas futuras de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

ÍNDICE GENERAL vii

A. Desarrollo de una aplicación para las comunicaciones vía el puerto serie 115

Referencias 119

viii ÍNDICE GENERAL

Índice de guras

1.1. Espectro electromagnético. Fuente: [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Algunas de las frecuencias ISM para distintas localizaciones. Fuente: [2] . . . . . . . . . . 3

1.3. Rango respecto a tasa de transferencia para diferentes tecnologías inalámbricas. . . . . . . 4

1.4. Espectros de UWB y Wi-Fi 802.11a. Fuente: [7] . . . . . . . . . . . . . . . . . . . . . . . 6

2.1. Pila de protocolos ZigBee/802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Topologías de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3. Canales radio 802.15.4. Fuente: [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4. PDU (Protocol Data Unit) de nivel físico o PPDU. Fuente: [10] . . . . . . . . . . . . . . . 15

2.5. Tratamiento de la PPDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6. Estructura de supertrama. Fuente: [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.7. Diagrama de bloques del algoritmo CSMA-CA. Fuente: [10] . . . . . . . . . . . . . . . . . 20

2.8. Distintos formatos de tramas MAC. Fuente: [11] . . . . . . . . . . . . . . . . . . . . . . . 22

2.9. Ejemplo de red mostrando el Cskip(d) y las direcciones de red . . . . . . . . . . . . . . . . 27

2.10. Formato general de trama de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.11. Capa de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.12. Formato general de trama de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.13. Formato de trama con seguridad habilitada . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1. Distribución de la pila de protocolos entre microprocesador y CC2480 . . . . . . . . . . . 38

3.2. Componentes del kit eZ430-RF2480. Fuente: [22] . . . . . . . . . . . . . . . . . . . . . . . 38

3.3. Conexión de los componentes del kit eZ430-RF2480. Fuente: [22] . . . . . . . . . . . . . . 39

3.4. Conexión entre el integrado CC2480 y un microprocesador . . . . . . . . . . . . . . . . . . 40

3.5. Distribución de pines en CC2480. Fuente: [13] . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.6. Formato de trama de comunicación entre microprocesador y CC2480 . . . . . . . . . . . . 42

3.7. Bits de comando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.8. AREQ. Fuente: [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.9. SREQ. Fuente: [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.10. POLL. Fuente: [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.11. Ejemplo de asignación de direcciones en una red de 6 nodos formada con el CC2480 . . . 53

3.12. Arquitectura interna del MSP430. Fuente: [19] . . . . . . . . . . . . . . . . . . . . . . . . 55

3.13. Distribución de pines en MSP430. Fuente: [20] . . . . . . . . . . . . . . . . . . . . . . . . . 56

ix

x ÍNDICE DE FIGURAS

3.14. Esquemático de conexión entre CC2480 y MSP430. Fuente: [21] . . . . . . . . . . . . . . . 58

3.15. Máquina de estados de la aplicación de ejempolo ZASA. Fuente: [22] . . . . . . . . . . . . 61

3.16. Red formada por un coordinador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.17. Coordinador y router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.18. Red compuesta por 3 dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.19. Tektronix TDS 3012B. Fuente: [23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.20. Tektronix PS2520G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.21. HP34401A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.22. CC2520EMK y SmartRF05EB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.23. Monitorización de una red de 6 dispositivos ejecutando ZASA . . . . . . . . . . . . . . . . 67

3.24. Z-Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.25. Packet Snier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.26. IAR Embedded Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.27. Representación de una medida de corriente con MATLAB . . . . . . . . . . . . . . . . . . 71

3.28. Esquema general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.29. Esquema para la medida del consumo de potencia . . . . . . . . . . . . . . . . . . . . . . 72

3.30. Amplicador INA195 de Texas Instruments. Fuente: [33] . . . . . . . . . . . . . . . . . . . 73

3.31. INA 195 conectado a un ltro paso bajo. Fuente: [33] . . . . . . . . . . . . . . . . . . . . . 74

3.32. Filtro Paso Bajo de primer orden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.33. Esquema completo del circuito medida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.1. Consumo de corriente al conectar la alimentación . . . . . . . . . . . . . . . . . . . . . . . 78

4.2. Consumo de corriente del dispositivo en espera . . . . . . . . . . . . . . . . . . . . . . . . 78

4.3. Consumo al conectar la alimentación y en espera . . . . . . . . . . . . . . . . . . . . . . . 79

4.4. Inicio del coordinador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.5. Inicio del coordinador con búsqueda en varios canales . . . . . . . . . . . . . . . . . . . . 81

4.6. Escaneo activo sobre dos canales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.7. Visión en detalle del escaneo activo sobre dos canales . . . . . . . . . . . . . . . . . . . . . 83

4.8. Baliza emitida por el nodo para determinar si ya existe un coordinador . . . . . . . . . . . 83

4.9. Consumo durante el inicio de un router con escaneo sobre dos canales . . . . . . . . . . . 84

4.10. Inicio de un router con escaneo sobre dos canales . . . . . . . . . . . . . . . . . . . . . . . 85

4.11. Baliza enviada por el router y respuesta del coordinador . . . . . . . . . . . . . . . . . . . 85

4.12. Desglose del paso 8 (vinculación al coordinador) . . . . . . . . . . . . . . . . . . . . . . . 86

4.13. Asociación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.14. Vinculación del router al coordinador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.15. Consumo durante el inicio de un dispositivo nal con escaneo sobre un canal . . . . . . . 88

4.16. Inicio de un dispositivo nal con escaneo sobre dos canales . . . . . . . . . . . . . . . . . . 89

4.17. Desglose del paso 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.18. Consumo de corriente durante el funcionamiento regular del coordinador de red . . . . . . 90

4.19. Consumo de corriente del coordinador de red . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.20. Pasos 4 y 5 y desglose del paso 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.21. Consumo de corriente en un dispositivo nal durante el envío de datos . . . . . . . . . . . 93

ÍNDICE DE FIGURAS xi

4.22. Consumo de corriente durante la transmisión de un paquete de datos . . . . . . . . . . . . 94

4.23. Paquete de datos enviado por un dispositivo nal . . . . . . . . . . . . . . . . . . . . . . . 95

4.24. Conrmación ack a nivel MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.25. Consumo de corriente durante una secuencia activa . . . . . . . . . . . . . . . . . . . . . . 97

4.26. Corriente media consumida y vida útil de las baterías en función de P . . . . . . . . . . . 98

4.27. Consumo de corriente durante una secuencia activa . . . . . . . . . . . . . . . . . . . . . . 99

4.28. Paquete de datos de 5 bytes de carga útil . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.29. Duración del intervalo de transmisión (TX) para distintos tamaños de paquete . . . . . . 100

4.30. Consumo durante una secuencia activa por partes . . . . . . . . . . . . . . . . . . . . . . . 101

4.31. Consumo de corriente y vida útil de las baterías en función del tamaño de paquete (n) . . 102

4.32. Envío de 2 bytes utilizando seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.33. Consumo durante el envío de datos con ack activo y mensaje POLL . . . . . . . . . . . . 103

4.34. Consumo debido a la recepción del mensaje ack de aplicación y envío de mensaje POLL . 104

4.35. Petición de ack a nivel de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.36. Ack a nivel MAC y de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.37. Ack a nivel MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.38. Mensaje POLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.39. Ack a nivel MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.40. Corriente media consumida y vida útil con y sin error de funcionamiento en el CC2480 . . 106

4.41. Mensajes de reconexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.42. Noticación de orfandad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.43. Proceso de reasociación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.44. Consumo de corriente durante la reconexión realizando escaneo sobre un canal . . . . . . 108

A.1. Formato de trama de comunicación entre microprocesador y CC2480 . . . . . . . . . . . . 116

A.2. Diagrama de ujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A.3. Aplicación desarrollada para PC en funcionamiento . . . . . . . . . . . . . . . . . . . . . . 118

xii ÍNDICE DE FIGURAS

Índice de tablas

1.1. Comparativa entre los protocolos Wi-Fi, Bluetooth, ZigBee y UWB. Fuente: [3] . . . . . . 3

2.1. Características de las frecuencias 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2. Ejemplo de tamaño de subgrupos de direcciones . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1. Descripción de los principales pines del CC2480 . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2. Valores posibles para los campos tipo y subsistema de comando . . . . . . . . . . . . . . . 43

3.3. Comandos de la interfaz SYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4. Comandos de la interfaz Simple API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.5. Comandos de la interfaz AF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.6. Comandos de la interfaz ZDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.7. Parámetros especícos de un dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.8. Parámetros especícos de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.9. Consumo de corriente en el CC2480 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.10. Cskip(d) en CC2480 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.11. Modos de bajo consumo en el microprocesador MSP430 . . . . . . . . . . . . . . . . . . . 57

3.12. Estado de los diodos LED de acuerdo con el programa ZASA . . . . . . . . . . . . . . . . 60

3.13. Velocidad de muestreo del osciloscopio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.1. Consumo en función del número de canales escaneados durante el inicio de red . . . . . . 81

4.2. Consumo en función del número de canales escaneados durante el inicio de un router . . . 84

4.3. Consumo máximo y mínimo durante el inicio de un dispositivo nal . . . . . . . . . . . . 88

4.4. Consumo medio de corriente en el coordinador de red . . . . . . . . . . . . . . . . . . . . 91

4.5. Consumo medio de corriente en el coordinador de red . . . . . . . . . . . . . . . . . . . . 92

4.6. Consumo de corriente en los diferentes intervalos de una secuencia activa . . . . . . . . . 101

4.7. Consumo máximo y mínimo durante la reasociación a la red . . . . . . . . . . . . . . . . 108

4.8. Resumen del consumo medio de corriente y potencia. La tensión de alimentación es de 3 V. 109

xiii

xiv ÍNDICE DE TABLAS

Capítulo 1

Introducción

1.1. Ubicación tecnológica

Durante muchos años, la comunicación mediante cables ha sido la forma más habitual de intercambiar

información entre dos puntos. No obstante, y a pesar de sus evidentes ventajas, este tipo de comunicaciones

presenta las siguientes limitaciones:

Geográcas: Dependiendo de la geografía del terreno donde queramos realizar las comunicaciones,

la instalación y el mantenimiento de la infraestructura necesaria pueden resultar complicados. Esto

sucede especialmente en áreas rurales, donde la orografía y la extensión del terreno son variables a

tener en cuenta.

Económicas: El coste de una red es proporcional a la longitud de cable requerido, así como al

número de repetidores necesarios para contrarrestar los efectos de la atenuación. Esto signica que

un aumento en la envergadura de nuestra red implica un aumento considerable en su coste.

Comodidad: Teniendo en cuenta las necesidades de portabilidad de los usuarios de hoy en día, el uso

de cables para el intercambio de información entre aparatos electrónicos se hace extremadamente

inadecuado.

Estas tres principales limitaciones de las comunicaciones por cable explican el auge que están viviendo las

tecnologías inalámbricas en los últimos años.

Dentro del espectro electromagnético, que podemos ver en la gura 1.1, se usan principalmente las

bandas infrarrojos (IR) y de radiofrecuencia (RF) para transmitir señales de forma inalámbrica. Las co-

municaciones por IR pueden alcanzar tasas de transferencia de hasta 4 Mbps o más, pero presentan el

inconveniente de que sólo permiten las comunicaciones para pequeñas distancias y siempre que el trans-

misor y el receptor tengan línea directa de visión. Su uso se centra principalmente en las comunicaciones

de periféricos electrónicos como teléfonos móviles. Por contra, las comunicaciones por radiofrecuencia a

la vez que poseen altas tasas de transferencia, también permiten la comunicación entre dos puntos muy

alejados y sin línea directa de visión.

Dentro del espectro de RF podemos encontrar la banda ISM (Industrial, Scientic and Medical). Ésta

es una parte del espectro electromagnético de propósito general, que puede ser usada sin necesidad de

1

2 CAPÍTULO 1: INTRODUCCIÓN

Figura 1.1: Espectro electromagnético. Fuente: [1]

licencia siempre que se respeten unos ciertos límites de potencia emitida. La banda ISM fue denida por el

sector de radiocomunicaciones de la Unión Internacional de Telecomunicaciones (ITU-R). El único requer-

imiento para desarrollar un producto que use la banda ISM es adaptarse a diversas normas especicadas

por los organismos que regulan el espectro electromagnético en diversas zonas geográcas. En concreto, si

nos encontramos en Europa tendremos que seguir las normas de la ETSI (European Telecommunications

Standars Institute) y si nos encontramos en los Estados Unidos las de la FCC (Federal Communication

Commision).

Los sistemas diseñados para trabajar en la banda ISM se caracterizan por un bajo consumo y, en

principio, tasas de transmisión no muy altas. No obstante, en los últimos años se ha venido trabajando

intensamente para aumentar dichas tasas de transmisión de datos. La mayor parte de los sistemas que

trabajan en la banda ISM lo hacen bien a 2,4 GHz o bien en la banda por debajo de 1 GHz. Mientras la

banda a 2,4 GHz es universal, por debajo de 1 GHz las frecuencias estandarizadas varían de un país a otro.

Por ejemplo, mientras en Europa la frecuencia estándar por debajo de 1 GHz es 868 MHz, en Estados

Unidos se usa aquella centrada en los 915 MHz. En la gura 1.2 podemos ver las frecuencias usadas en

diferentes partes del globo. A la hora de elegir una determinada frecuencia de trabajo, los diseñadores

deben tener muy en cuenta las ventajas y desventajas asociadas a dicha elección. En concreto:

La banda de 2,4 GHz es recomendable cuando la interoperabilidad es un requerimiento para nuestro

dispositivo. Además, si necesitamos que dicho dispositivo funcione correctamente en distintas zonas

geográcas, 2,4 GHz es la mejor elección. Por otro lado, puesto que a esta frecuencia trabajan un

gran número de tecnologías (Wi-Fi, Bluetooth, ZigBee, etc) e incluso algunos hornos microondas, los

1.1: UBICACIÓN TECNOLÓGICA 3

altos niveles de interferencia son un problema a superar. Por último, una frecuencia mayor implica

que la señal será absorbida más fácilmente por el entorno y los objetos circundantes, con lo que el

rango de alcance disminuirá respecto al caso de usar frecuencias menores.

Usando el rango de frecuencias por debajo de 1 GHz mejoramos algunas de las características que

presentaban problemas para el caso de los 2,4 GHz, en concreto aquellas relacionados con las inter-

ferencias y con el rango de alcance. No obstante, y como ya sabemos, trabajar con una frecuencia

menor hace que disminuya el ciclo de trabajo y, en consecuencia, el ancho de banda. Además la

interoperabilidad y la movilidad geográca de nuestro dispositivo también se ven ampliamente mer-

mandas.

Para el caso de nuestro proyecto nos centraremos en dispositivos que trabajan en la banda de los 2,4 GHz

puesto que damos prioridad a la interoperabilidad, la movilidad geográca y una tasa de bits aceptable.

Figura 1.2: Algunas de las frecuencias ISM para distintas localizaciones. Fuente: [2]

En los últimos años hemos asistido al desarrollo de diversos estándares inalámbricos que operan en la

banda ISM. En consecuencia, un gran número de productos basados en tecnología inalámbrica han visto

la luz. Dichos estándares se diferencian unos de otros por su tasa de transferencia, rango de alcance, sus

dominios de aplicación, técnicas de modulación usadas, etc. A día de hoy, los más usados y con mayor

proyección de futuro son Wi-Fi, Bluetooth, ZigBee y Ultra-WideBand (UWB). En la tabla 1.1 podemos

ver una comparativa de dichos estándares y en la gura 1.3 vemos representado de forma aproximada su

rango de alcance respecto a la tasa de transferencia.

Estándar ZigBee/802.15.4 Bluetooth Wi-Fi UWB

IEEE 802.15.4 802.15.1 802.11 a/b/g 802.15.3aBanda de frecuencia 868/915 MHz ; 2,4 GHz 2,4 GHz 2,4 GHz ; 5 GHz 3,1 - 10,6 GHz

Máxima tasa de transmisión 250 Kbps 1 Mbps 54 Mbps 110 MbpsRango de alcance 10 - 20 m 10 - 100 m 100 m 10 m

Número de canales RF 1/10 ; 16 79 14 (2,4 GHz) 1-15Ancho de banda de canal 0,3/0,6 MHz ; 2 MHz 1 MHz 22 MHz 500 MHz - 7,5 GHz

Cuadro 1.1: Comparativa entre los protocolos Wi-Fi, Bluetooth, ZigBee y UWB. Fuente: [3]


Figura 1.3: Rango respecto a tasa de transferencia para diferentes tecnologías inalámbricas.

A continuación explicaremos de forma resumida los fundamentos de estas tecnologías. No obstante, ya

que este texto se centra en la tecnología ZigBee 802.15.4, ésta será explicada en profundidad en el próximo

capítulo.

1.1.1. Bluetooth

En 1994 la compañía sueca Ericsson comienza un estudio para desarrollar una interfaz radio de bajo

coste y bajo consumo para la interconexión de dispositivos electrónicos, principalmente teléfonos móviles.

En 1997 se forma el Special Interest Group (SIG) [4] formado por Ericsson, Nokia, Intel, Toshiba e IBM

con el objetivo de promover el uso de este nuevo estándar. Para 1999 más de 400 empresas forman ya

parte del SIG, asegurando el futuro del nuevo estándar.

Bluetooth trabaja en la banda ISM a una frecuencia de 2,4 GHz con 79 canales de 1 MHz entre 2402

y 2480 MHz. Esto hace muy alta la probabilidad de interferencia debido la proximidad de redes 802.11,

hornos microondas, mandos de garaje, etc. Para evitar en lo posible las interferencias, Bluetooth usa un

sistema llamado Frequency Hop Spread Spectrum (FHSS). Dicho sistema realiza 1600 saltos de frecuencia

por segundo entre los 79 canales radio.

El rango de alcance de Bluetooth es de 10 metros con un consumo de 1 mW, aunque dicho rango

puede alcanzar los 100 metros si aumentamos la potencia de transmisión hasta los 100 mW. La tasa de

transmisión es de 1 Mbps cuando utilizamos modulación GFSK (Gaussian Frequency Shift Key) aunque

para versiones más avanzadas del estándar (Bluetooth 2.0) se pueden alcanzar velocidades de hasta 2

Mbps gracias a la combinación de GFSK con PSK.

Una red Bluetooth (comúnmente conocida como piconet) puede estar formada por hasta 8 dispositivos,

uno de los cuales asume el papel de maestro y el resto el de esclavo. Con objeto de reducir el consumo,

Bluetooth dene cinco estados diferentes:

Standby : Es el estado por defecto. En él todavía no se ha producido un enlace de comunicación.

Activo: En este estado el dispositivo sí que ha establecido un enlace de comunicación. Se produce

intercambio de paquetes.

1.1: UBICACIÓN TECNOLÓGICA 5

Sni : El maestro transmite información al esclavo pero únicamente en unos determinados slots

temporales (que previamente han acordado). Así, el esclavo sólo estará activo una fracción del

tiempo, ahorrando energía.

Hold : En este modo, un nodo apaga el sistema de radio para ahorrar energía. Antes de entrar en el

modo hold tanto el maestro como el esclavo acuerdan cuando deben volver al modo activo.

Park : Este estado se utiliza cuando un nodo no quiere tomar parte activa en la piconet pero tampoco

quiere perder la sincronización con el maestro.

Podemos ver un estudio muy interesante sobre el consumo de potencia para los distintos estados Bluetooth

en [5].

1.1.2. Wi-Fi

Wi-Fi es una marca usada por la Alianza Wi-Fi. Esta tecnología se basa en el estándar IEEE 802.11

y pretende ser la alternativa inalámbrica a las redes de área local (LAN), así, también se la conoce como

WLAN (Wireless LAN).

Una típica red Wi-Fi se compone por un Wi-Fi Access Point (WAP) que está conectado por un lado

a la red Ethernet y por otro a los demás dispositivos Wi-Fi a los que pretende dar cobertura. El alcance

es de hasta 100 metros aproximadamente y el consumo es mayor que el de Bluetooth pero, a cambio,

Wi-Fi puede alcanzar velocidades de hasta 54 Mbps. Como hemos visto en la primera sección de este

capítulo esta tecnología también trabaja en la banda ISM pero, al contrario que Bluetooth, existen varios

estándares Wi-Fi, los principales son:

802.11b: Al igual que Bluetooth trabaja a 2,4 GHz por lo cual sufre las mismas interferencias que éste

(además de la interferencia entre Bluetooth y Wi-Fi [6]). Su rango de alcance es de aproximadamente

100 metros con una tasa de transferencia de 11 Mbps. Esta vez, en lugar de FHSS se utiliza DSSS

(Direct Sequence Spread Spectrum) para evitar las interferencias, de forma que se envían varios bits

redundantes por cada bit que compone la señal. Mientras Bluetooth saltaba de una frecuencia a

otra para evitar interferencias, Wi-Fi disminuye la tasa de transmisión. En el estándar 802.11b sólo

se utilizan 3 canales radio de una anchura de 22 MHz y centrados en los 2412, 2437 y 2462 MHz.

De esta manera, sólo 3 redes W-Fi pueden operar simultáneamente en una misma localización. La

principal ventaja de los dispositivos Wi-Fi basados en 802.11b es su bajo coste.

802.11a: Este estándar surgió en paralelo a 802.11b. Trabaja a una frecuencia de 5 GHz con lo que su

tasa de transferencia puede alcanzar los 54 Mbps. Una ventaja es que al trabajar en una frecuencia

menos usada, no se dan tantas interferencias. No obstante tiene un rango de unos 30 metros y

su coste es mayor. Emplea modulación OFDM (Orthogonal Frequency Division Multiplexing). Es

incompatible con 802.11b.

802.11g: Es el más reciente de los tres estándares y, al igual que 802.11b, trabaja a 2,4 GHz. De

hecho, la compatibilidad con 802.11b es una de sus principales ventajas. Al igual que 802.11a, utiliza

modulación OFDM pudiendo alcanzar velocidades de hasta 54 Mbps y, al igual que 802.11b, tiene

un rango de alcance de unos 100 metros. Por contra, su coste y consumo de potencia son mayores.


1.1.3. Ultra-WideBand

Basado en los trabajos del IEEE Task Group 802.15.3a, Ultra-WideBand es una tecnología que pre-

tende saciar la necesidad del intercambio de datos con una alta tasa de transferencia, como pueden ser

las videocámaras digitales, sistemas home cinema, etc. De los estándares vistos hasta ahora, UWB es el

menos desarrollado y con un futuro más incierto.

UWB hace uso de un espectro muy ancho de frecuencias: desde los 3,1 hasta los 10,6 GHz. Pero, al

contrario que Bluetooth y Wi-Fi, no realiza el envío de información de forma continua sino en determinados

instantes temporales, utilizando gran parte de ese ancho de banda y emitiendo con menos potencia. Así,

el consumo de los dispositivos basados en este estándar es relativamente bajo. En la gura 1.4 podemos

ver una comparación entre los espectros de UWB y Wi-Fi 802.11a.

Figura 1.4: Espectros de UWB y Wi-Fi 802.11a. Fuente: [7]

Con UWB se pueden alcanzar tasas de transmisión de 110 Mbps con un rango de alcance de 10 metros

aproximadamente.

No obstante, y de acuerdo con publicaciones como [8], UWB no está alcanzando el éxito que a principios

de esta década algunos auguraban. En parte porque no se están cumpliendo las expectativas respecto a

su capacidad y en parte por el alto coste de fabricación de los dispositivos basados en este estándar.

1.2. Estándares de bajo consumo: aplicaciones

Como hemos visto en los apartados anteriores, Bluetooth es ideal para la transmisión de datos a

distancias cortas; Wi-Fi aumenta tanto la tasa de transmisión como el rango de alcance, con un mayor

consumo, lo que nos permite formar redes inalámbricas equiparables en prestaciones a Ethernet; UWB

suple las necesidades de transmisión de grandes cantidades de información punto a punto y dentro de un

corto rango de alcance, perfecto para el uso de dispositivos multimedia de última generación dentro del

entorno doméstico. Pero todavía hay un campo de aplicación donde las tecnologías inalámbricas tienen

una gran variedad de usos y por el que todavía no nos hemos preguntado: el control automatizado de

hogares, edicios y plantas industriales. A continuación se muestran algunos de los requerimientos que

una tecnología inalámbrica debería cubrir para desempeñar un buen papel en este campo de aplicación:

Puesto que el objetivo es cubrir no solo pequeñas distancias (como el hogar) sino también medias

distancias (como fábricas o naves industriales), el rango de alcance es una característica a tener en

1.2: ESTÁNDARES DE BAJO CONSUMO: APLICACIONES 7

cuenta. Así, UWB no parece apta puesto que su alcance es del orden de 10 metros.

Dichas redes inalámbricas de control industrial y del hogar no necesitarían grandes tasas de transfer-

encia. Por contra, bastaría con el envío de pequeñas cantidades de datos, como pueden ser comandos

con instrucciones, valores discretos leídos por sensores, etc. Wi-Fi y UWB quedan claramente fuera

de lugar puesto que se centran en el envío de grandes cantidades de información.

Larga vida de las baterías. Puesto que los sensores o controles repartidos por la hipotética instalación

podrían no tener acceso a la red eléctrica, sería idóneo que dicha tecnología inalámbrica presentase

un muy bajo consumo, haciendo independientes por un largo tiempo a los diferentes dispositivos

que compongan la red. Wi-Fi es claramente inadecuado debido a su alto consumo energético.

En el escenario que estamos proponiendo, los diferentes dispositivos inalámbricos no tendrían necesi-

dad de estar el 100% del tiempo activos. Por contra, bastaría con que sólo estuvieran activos a

instantes periódicos, aprovechando esos momentos para enviar la información acumulada.

Sería muy deseable poder formar subredes con los distintos dispositivos de la red. Por ejemplo, una

subred podría ser la encargada del control de la calefacción, mientras otra lo sería del control de

iluminación. Como ya hemos dicho, Bluetooth puede formar piconets pero su tamaño máximo es

únicamente de un maestro y siete esclavos.

Por todo lo visto en los puntos anteriores, una tecnología inalámbrica que funcionase en un escenario de

control de dispositivos en la industria o dentro del hogar debería estar centrada en:

Bajo consumo energético.

Posibilidad de formar subredes.

Dispositivos en modo de ahorro energético cuando no están siendo usados.

Varios estándares han sido diseñados para cumplir dichos requerimientos. ZigBee es el estándar con más

proyección en este sector puesto que cumple todos los requerimientos anteriores. En el siguiente capítulo

veremos un estudio en profundidad de dicha tecnología. Además de ZigBee, otras tecnologías están com-

pitiendo por abrirse un hueco en este mercado, ejemplos son Z-Wave o Wibree. Posibles usos de estas

tecnologías inalámbricas son:

Control de sistemas de iluminación, sonido o calefacción.

Centralización de datos enviados por sensores remotos (temperatura, presión, humedad, movimiento,

etc).

Recepción de alarmas.

Control remoto de puertas, persianas, etc.

Estas funciones ofrecen una inmensa gama de posibilidades a empresas centradas en domótica, inmótica

(edicios) o control industrial.


1.3. Objetivos del proyecto

Este proyecto se centra en las redes inalámbricas de bajo consumo, en concreto estudiaremos el estándar

ZigBee 802.15.4. Nuestro objetivo es realizar una caracterización del consumo energético de dichas redes.

En nuestra opinión, el estudio de redes ZigBee tiene un interés enorme. Esto se debe a que es una

tecnología emergente, en parte desconocida y en la cual un gran número de empresas están centrando su

atención.

Básicamente lo que haremos será medir la corriente que consume un nodo ZigBee/802.15.4 mientras

realiza diferentes tareas. Para la realización de dicho estudio debemos tener en cuenta los siguientes

parámetros:

Tipo de nodo que estamos estudiando. Como veremos en el siguiente capítulo, dentro de una red Zig-

Bee/802.15.4, un nodo puede desempeñar tareas de coordinador, router o simplemente de dispositivo

nal, siendo su consumo diferente para cada uno de los casos.

Tarea que realiza: inicio de una red, conexión a una red, transmisión de datos, etc.

Conguración del nodo: frecuencia de envío de información, requerimiento de conrmación, permisos

de conexión, longitud del paquete de datos a enviar, etc.

Casos extremos como la pérdida de conexión con el padre (nodo inmediatamente por encima en la

jerarquía de red), intento de conexión a una red inexistente, etc.

Aparte de estos objetivos, la realización de este proyecto también tiene por meta asentar y mejorar el

conocimiento sobre herramientas de instrumentación, así como sobre el software y hardware necesarios

para el desarrollo de componentes electrónicos relacionados con las tecnologías inalámbricas.

1.4. Estructuración de la memoria

El presente texto pretende mostrar de forma ordenada y clara los pasos seguidos para la realización

del proyecto. Para ello explicaremos los fundamentos de la tecnología ZigBee, describiremos el sistema

de medida usado, expondremos los resultados de las medidas de consumo y sacaremos unas conclusiones.

Más concretamente la estructura de esta memoria es:

Capítulo 1: Introducción. Es el presente capítulo y en él hemos expuesto una visión general de

las tecnologías inalámbricas. También hemos expuesto el objetivo de nuestro proyecto.

Capítulo 2: ZigBee/802.15.4. En este capítulo analizaremos en profundidad los estándares Zig-

Bee/802.15.4.

Capítulo 3: Herramientas de desarrollo empleadas y sistema de medida. Se comenzará

describiendo el sistema sobre el que se realizará el estudio. A continuación hablaremos sobre las

tecnologías involucradas en dicho estudio: herramientas de instrumentación y herramientas software.

Capítulo 4: Estudio del consumo. En este capítulo expondremos los resultados obtenidos tras

realizar el estudio del consumo de corriente.

1.4: ESTRUCTURACIÓN DE LA MEMORIA 9

Capítulo 5: Conclusiones y líneas futuras de trabajo. Por último, detallaremos las conclu-

siones a las que hemos llegado y plantearemos posibles líneas de trabajo por las que ampliar nuestro

proyecto.

Apéndice A: Se expondrá el desarrollo de una aplicación cuyo objetivo es comunicarse con un

dispositivo ZigBee/802.15.4 vía el puerto serie. La aplicación en cuestión se ha programado utilizando

Visual Basic .NET.


Capítulo 2

ZigBee/802.15.4

2.1. Introducción a ZigBee/802.15.4

Como ya hemos visto en el capítulo 1, ZigBee/802.15.4 es una tecnología inalámbrica de bajo consumo,

baja tasa de transmisión y coste reducido. Se engloba dentro del grupo de las tecnologías WPAN (Wireless

Personal Area Network). El estándar ha sido denido por la ZigBee Alliance, de la que forman parte más

de 300 empresas, y por el IEEE Task Group 4. En concreto, la ZigBee Alliance se encarga de la denición

de las capas de red y aplicación mediante el estándar ZigBee [9] mientras que el Task Group 4 se centra

en la denición de las capas física y MAC (Medium Access Control) mediante estándar 802.15.4 [10].

Estos términos, ZigBee y 802.15.4, son a veces utilizados como sinónimos cuando en realidad denen

partes diferentes de la pila de protocolos. En la gura 2.1 podemos ver una simplicación de dicha pila

de protocolos.

Figura 2.1: Pila de protocolos ZigBee/802.15.4

Esta tecnología es idónea para formar redes de sensores. Los posibles usos de ZigBee/802.15.4, como

principal exponente de las redes inalámbricas de bajo consumo, han sido expuestos en la sección 1.2.

Dentro del estándar ZigBee encontramos dos versiones: ZigBee-2006 y ZigBee PRO (2007). En las

siguientes secciones utilizaremos el término ZigBee para referirnos a ZigBee PRO. La mayoría de los

fabricantes comercializan dispositivos compatibles con ambas versiones.

11

12 CAPÍTULO 2: ZIGBEE/802.15.4

2.2. Topología

Antes de describir los distintos tipos de redes ZigBee es necesario denir los 3 tipos distintos de

dispositivos que la componen. Estos son:

Coordinador. Este dispositivo inicializa y controla la red. También se encarga de gestionar las

tareas de seguridad. Para poder formar una red ZigBee debe existir un coordinador.

Router . Estos dispositivos son los encargados de extender la cobertura de la red, gestionando

nuevos caminos en el caso de que la red experimente congestión o se produzca la caída de algún

nodo. Pueden conectarse directamente al coordinador o a otros routers. Gestionan dispositivos hijo.

Dispositivo nal. Este tipo de dispositivo puede enviar y recibir datos pero no realizar tareas de

encaminamiento. Deben estar conectados a un router o al coordinador y no admiten dispositivos

hijo.

Los dispositivos también pueden organizarse según otro criterio:

FFD (Full Function Device). Este dispositivo tiene una funcionalidad completa. Puede funcionar

como Coordinador, router o dispositivo nal.

RFD (Reduced Function Device). Tiene una implementación mínima del protocolo 802.15.4.

Está pensado para realizar tareas extremadamente simples en las que se envíen pequeñas cantidades

de datos. Ejemplos de esto pueden ser interruptores de luz, sensores de infrarrojos u otros dispositivos

con una funcionalidad básica. Sólo pueden estar conectados a un FFD. Únicamente pueden funcionar

como dispositivos nales.

Como podemos ver en la especicación de ZigBee [9], el estándar soporta 3 tipos de topologías de red:

estrella, malla y árbol (gura 2.2). Una red se caracteriza por su identicador PAN (PAN ID), que la

distingue de otras posibles redes funcionando en la misma zona.

2.2.1. Topología en estrella

Este tipo de redes se componen por un FFD funcionando como coordinador y varios FFD o RFD

funcionando como dispositivos nales. Todos los dispositivos nales están directamente conectados al

coordinador, que es el encargado de haber iniciado la red y de gestionarla. En una red tipo estrella todas

las comunicaciones entre dos dispositivos nales deben pasar antes por el coordinador. Se recomienda

que mientras los dispositivos nales estén alimentados por baterías el coordinador lo esté directamente a

través de la red eléctrica ya que su consumo es mucho mayor. Un problema de esta conguración es que

la expansión de la red está muy limitada puesto que el rango de alcance del coordinador es el que dene

el tamaño de la red.

2.2.2. Topología en malla

En este tipo de red se puede establecer comunicación directa entre cualquier par de nodos. El coor-

dinador no realiza funciones muy diferentes a las que realizan el resto de routers de la red; de hecho, la

2.3: CAPA FÍSICA 13

función de coordinador la realiza el primer router que forme parte de la red. Al no depender de un único

dispositivo para gestionar la red, la abilidad de esta conguración es mayor.

En la topología en malla ganamos en exibilidad a costa de aumentar la complejidad. Esto se debe a que

para comunicar cualquier par de dispositivos hay más de un camino posible. La elección de dicho camino

conlleva un aumento de computación que debe realizarse a nivel de red. Por lo tanto, estas consideraciones

no se tienen en cuenta en la especicación del IEEE 802.15.4 si no que se denen en la especicación de

ZigBee.

2.2.3. Topología en árbol

La topología en árbol es un caso particular de la topología en malla. En ella los diferentes componentes

de la red se organizan en una estructura jerárquica. El coordinador o los routers, que son los encargados

de gestionar el encaminamiento, pueden tener dispositivos hijos. Estos dispositivos hijos pueden ser otros

routers o dispositivos nales. La topología en árbol, al igual que la mallada, es idónea para expandir la

red de forma dinámica. Al igual que en el caso anterior se recomienda que el coordinador y los routers

estén alimentados de forma cableada.

(a) Estrella (b) Malla (c) Árbol

Figura 2.2: Topologías de red

2.3. Capa Física

La capa física gestiona la transmisión y recepción de datos usando determinados canales radio. En

802.15.4 tenemos tres posibles bandas de frecuencia en las que poder trabajar: 868 MHz, 915 MHz y 2,4

GHz. En la primera banda únicamente tenemos un canal entre 868 y 868,6 MHz. En la siguiente banda

tenemos 10 canales entre 902 y 928 MHz. Por último, 16 canales más están localizados entre 2,405 y 2,48

GHz. El protocolo permite una selección dinámica del canal, de forma que se elija el menos ruidoso de

entre aquellos posibles. Lógicamente, la tasa de transferencia es distinta para cada una de las bandas de

frecuencia. Para 868 MHz la tasa de transferencia es de 20 Kbps, para 915 MHz es de 40 kbps y para 2,4


GHz es de 250 kbps. Por supuesto, las bandas de 868 y 915 MHz tienen un rango de alcance mayor que la

de 2,4 GHz a cambio de una menor tasa de transferencia. Otra diferencia es que, como vimos en la sección

1.1, la banda de 868 MHz está disponible sólo en Europa mientras que la de 915 MHz sólo en Estados

Unidos y Australia. Sin embargo la banda a 2,4 GHz es universal, por lo que su uso está permitido en

la mayoría de países del mundo. En la gura 2.3 podemos ver una representación de los canales radio

802.15.4.

Figura 2.3: Canales radio 802.15.4. Fuente: [11]

En 804.15.4 se utiliza DSSS (Direct Sequence Spread Spectrum) como técnica de ensanchado de espec-

tro. En la tabla 2.1 mostramos la tasa de transferencia y el tipo de modulación usada para las distintas

frecuencias de transmisión.

Banda de frecuencia Tasa de transferencia Modulación

868 MHz 20 kbps BPSK915 MHz 40 kbps BPSK2,4 GHz 250 kbps O-QPSK

Cuadro 2.1: Características de las frecuencias 802.15.4

Para congurar la capa física se emplean una serie de constantes y atributos. Podemos ver un listado

exhaustivo a partir de la página 45 de [10]. Ejemplos de dichas constantes y atributos son aMaxPHY-

PacketSize, aTurnaroundTime, phyCurrentChannel, phyCCAMode, etc.

Respecto a las funciones que realiza la capa física en 802.15.4 podemos destacar:

Activar y desactivar el transceptor radio. El transceptor radio tiene tres modos de fun-

cionamiento: transmisión, recepción y sleeping (descanso). Bajo petición de la capa MAC la capa

física debe conmutar entre estos tres estados. El estándar exige que la conmutación entre transmisión

y recepción, o viceversa, se haga en menos de 12 símbolos (aTurnaroundTime = 12). Para el caso

de 2,4 GHz y teniendo en cuenta que cada símbolo corresponde a 4 bits, se puede calcular el tiempo

máximo de conmutación entre los estados de transmisión y recepción:

2.3: CAPA FÍSICA 15

12 símbolos = 48 bits (2.1)

48 bits

250kbits

s

= 192 µs (2.2)

Detección de energía de cada canal (ED, Energy Detection). La capa física también es la

encargada de comprobar qué nivel de potencia tiene un determinado canal. Esta medida es utilizada

por la capa de red como parte de su algoritmo para la elección de canal.

Indicación de la calidad de enlace (LQI, Link Quality Indicator). Mide la potencia en dBm

de la señal que ha transmitido el último paquete.

Evaluación de canal libre (CCA, Clear Channel Assessment). Este indicador será utilizado

por el algoritmo CSMA-CA (Carrier Sense Multiple Access with Collision Avoidance) como se verá

más adelante.

Selección de frecuencia. Dentro de los 27 canales posibles de ZigBee, la capa física debe ser capaz

de seleccionar aquel que le especiquen las capas superiores.

Envío y recepción de datos.

De acuerdo con el estándar 802.15.4, el sistema radio debe ser capaz de emitir con una potencia de -3

dBm o superior y debe tener una sensibilidad mínima de -20 dBm.

En la gura 2.4 se muestra el formato de trama 802.15.4 a nivel físico. Dicha trama está compuesta

principalmente por una cabecera de sincronización (SHR), un campo para indicar la longitud de la trama

(PHR) y la carga útil.

Figura 2.4: PDU (Protocol Data Unit) de nivel físico o PPDU. Fuente: [10]

Una vez generada la PPDU, y de acuerdo con el estándar 802.15.4 [10], los bits se convierten en

símbolos. Puesto que cada símbolo está formado por 4 bits, se tienen 16 posibles símbolos. Para cada uno

de ellos existe una secuencia de chips (formada por 32 bits cada una) que será la que denitivamente se

module y envíe gracias al sistema de radio. El proceso se esquematiza en la gura 2.5.

Figura 2.5: Tratamiento de la PPDU


2.4. Capa MAC

2.4.1. Descripción general

La capa MAC, o capa de acceso al medio, es la responsable de asegurar la comunicación entre un

nodo y todos los nodos conectados directamente a él, evitando colisiones y mejorando la eciencia. Más

concretamente, las tareas que la capa MAC tiene que realizar son:

Generar balizas (beacons) si el dispositivo es un coordinador y se funciona en modo balizado.

Sincronizar las balizas de la red.

Gestionar la conexión y desconexión a la red de los dispositivos asociados al propio nodo.

Emplear el algoritmo CSMA-CA para gestionar el acceso al canal.

Asegurar un enlace able con la capa MAC de los nodos contiguos.

Al igual que ocurre con la capa física, para congurar la capa MAC se utilizan una serie de constantes y

atributos. Podemos ver un listado exhaustivo en la página 159 de [10]. Ejemplos de dichas constantes y

atributos son macBeaconOrder, macSuperframeOrder o aBaseSuperframeDuration, que, junto con otros,

serán utilizados en las siguientes secciones para profundizar en la descripción de la capa de acceso al

medio.

2.4.2. Modos de funcionamiento

El protocolo MAC soporta dos modos de funcionamiento (el coordinador es el encargado de seleccionar

uno u otro en el momento de iniciar la red):

Modo balizado. La baliza es generada periódicamente por el coordinador y distribuida por toda

la red gracias a los routers. Dicha baliza sirve para sincronizar todos los nodos de la red, de modo

que estos puedan despertarse en un momento determinado (conocido por todos), enviar los datos

almacenados y volver al modo de ahorro energético (sleep). Así, tanto el coordinador, como los

routers y los dispositivos nales pueden pasar gran parte del tiempo en modo de bajo consumo. La

topología en malla no admite el modo balizado debido a la complejidad que ello conllevaría (a un

mismo dispositivo podrían llegarle balizas provenientes de distintos routers).

Modo no balizado. En este modo los dispositivos no están sincronizados unos con otros. Así,

únicamente los dispositivos nales pueden entrar en el modo sleep mientras que los routers y el

coordinador deben estar continuamente con el sistema radio en modo recepción y así estar preparados

para recibir datos en cualquier momento. Este modo es más simple pero hace que gran parte de sus

nodos (el coordinador y los routers) tengan un mayor consumo energético. Asimismo, impide que

los coordinadores puedan planicar sus envíos a los dispositivos nales.

2.4: CAPA MAC 17

Modo balizado

El coordinador es el que determina si trabajamos o no en este modo. En caso positivo, él será el

encargado de distribuir la baliza a todos los elementos de la red.

Cuando se trabaja en el modo balizado se utiliza una estructura de envío de datos conocida como

supertrama. Una supertrama está delimitada por dos balizas consecutivas y se compone por una parte

activa y otra inactiva (gura 2.6). Durante la parte activa el coordinador interactúa con la red mientras que

en la inactiva entra en modo sleep. La estructura de una supertrama viene denida por dos parámetros:

BO (macBeaconOrder). Determina el intervalo de transmisión de las balizas. El valor del BO y

del BI (Beacon Interval) están relacionados según la siguiente expresión, donde 0 ≤ BO ≤ 14y aBaseSuperframeDuration representa el número de símbolos que forman una supertrama de

orden 0 (por defecto toma el valor de 960):

BI = aBaseSuperframeDuration · 2BO sımbolos

SO (macSuperframeOrder). Determina el tamaño de la parte activa de la supertrama. El valor

del SO y del SD (Superframe Duration) están relacionados según la siguiente expresión, donde

0 ≤ SO ≤ BO ≤ 14:

SD = aBaseSuperframeDuration · 2SO sımbolos

Si los valores de BI y SD coinciden la supertrama carecerá de periodo inactivo. Por otra parte, de

acuerdo con el estándar 802.15.4, si SO y BO valen 15 el coordinador congurará la red para trabajar en

modo no balizado.

Figura 2.6: Estructura de supertrama. Fuente: [10]

La parte activa de la supertrama se divide en 16 slots temporales, el primero de los cuales contiene

la baliza. Estos slots se dividen en dos grupos: el Contention Access Period (CAP) y el Contention Free

Period (CFP). A continuación los detallamos:

CAP. Un dispositivo que desee comunicarse con su nodo padre debe competir por el canal utilizando

el algoritmo CSMA-CA. Si consigue transmitir lo hará utilizando uno de los slots del CAP.

CFP. Bajo petición de un nodo, el coordinador puede asignarle uno o varios slots temporales del

CFP de forma que no tenga que competir con otros nodos de la red por el envío de información. Un


grupo de slots temporales asignados a un determinado nodo se denominan Guarantee Time Slots

(GTS). Mediante esta característica, el protocolo 802.15.4 puede ofrecer cierta calidad de servicio a

ciertas aplicaciones con requerimientos especiales.

Modo no balizado

Como hemos dicho en el punto anterior, si se asigna el valor de 15 a las variables BO y SO activaremos

el modo no balizado. En él no existen los conceptos de slots temporales, balizas ni supertramas. Cada nodo

disputa el acceso al canal mediante el algoritmo CSMA-CA y, si lo consigue, los demás dispositivos tendrán

que esperar su turno. Únicamente los mensajes de reconocimiento de mensaje recibido (acknowledgment

o ack en inglés) podrán ser enviados inmediatamente y sin necesidad de competir por acceder al medio

mediante CSMA-CA.

En este modo el consumo del coordinador y los routers es mucho mayor que en el modo balizado. El

consumo de los dispositivos nales sí se mantiene prácticamente igual en ambos modos puesto que siempre

pueden pasar al modo de bajo consumo una vez transmitidos los datos. Viéndolo de otra forma podemos

decir que en una red con balizas todos los dispositivos están dormidos la mayor parte del tiempo, gracias

a la sincronización entre ellos que les permite despertarse a la vez. En una red sin balizas el coordinador

y los routers no tienen manera de saber cuándo se despertarán los dispositivos nales, por lo que tienen

que estar el 100% del tiempo con el sistema radio activado.

El modo no balizado nos ofrece simplicidad a cambio de un consumo mayor y una menor eciencia.

2.4.3. Algoritmo CSMA-CA

Cuando se emplea este algoritmo los dispositivos anuncian que están listos para enviar paquetes de

datos antes de acceder al canal. De esta forma se evita la colisión. Dependiendo de unos ciertos parámetros

se da prioridad a uno de los candidatos, que podrá acceder al canal para enviar su paquete de datos. El

resto de dispositivos esperarán un tiempo aleatorio (distinto en cada uno de ellos) para volver a intentar

acceder al canal.

Se denen dos tipos distintos de algoritmo CSMA-CA según estemos usando el modo balizado o el no

balizado. Para el modo balizado se emplea el CSMA-CA ranurado mientras que para el no balizado se

utiliza el CSMA-CA no ranurado. En ambos casos, un transmisor sólo puede intentar acceder al medio

con una periodicidad concreta (determinada por el tiempo de backo ). En el CSMA-CA ranurado, este

tiempo de backo debe estar sincronizado con la baliza. Para el caso del CSMA-CA no ranurado, cada

transmisor tiene su propio tiempo de backo.

El algoritmo CSMA-CA utiliza tres variables para priorizar el acceso al medio:

NB (Number of Backos). Es el número intentos de acceso al canal que un dispositivo lleva acumu-

lados. Cada vez que un dispositivo quiere enviar un nuevo paquete esta variable debe ser inicializada

a 0.

CW (Contention Window). Es la longitud de la ventana de contienda. Representa el número de pe-

riodos de backo que el canal debe estar sin actividad para que se considere libre y, en consecuencia,

poder ser asignado a un dispositivo.

2.4: CAPA MAC 19

BE (Backo Exponent). Se emplea para determinar, aleatoriamente, el número de periodos de backo

que el dispositivo debe esperar para intentar acceder al canal después de un acceso fallido.

A continuación explicaremos de forma detallada ambos algoritmos. En la gura 2.7 podemos ver su

diagrama de bloques.

CSMA-CA ranurado

Este algoritmo se divide en cinco pasos:

1. Inicialización de NB, CW y BE. NB = 0 y CW = 2. El valor de BE depende de la variable mac-

BattLifExt. Si ésta es FALSE entonces BE = macMinBe, que por defecto vale 3. Si macBattLifExt

= TRUE (extensión de vida de la batería) entonces BE = mınimo(2, macMinBE).

2. Tiempo de espera aleatorio para intentar acceder al canal. Este tiempo de espera valdrá como

máximo 2BE − 1 periodos de backo. Si BE = 1 entonces el tiempo de espera es nulo, con lo que

saltamos directamente al paso 3.

3. Evaluación de canal libre (CCA o Clear Channel Assessment). El dispositivo escucha el canal en

el siguiente periodo de backo. Si el canal no se encuentra en uso, saltamos al paso 5. Si el canal

resulta estar ocupado pasamos al paso 4.

4. CW es reiniciado a su valor original (2). NB se incrementa en 1. BE también se incrementa en 1

siempre que no sobrepasemos el valor de macMaxBE (constante de valor 5 según el estándar). Si

NB > macMaxCSMABackoffs (también de valor 5) se considera que la transmisión ha fallado.

Si no, volvemos al paso 2.

5. El canal no está siendo usado. Se disminuye en 1 el parámetro CW. Si CW es 0 entonces se ha

superado la ventana de contienda y el canal se considera libre. La transmisión puede comenzar. Si

CW no es 0 todavía no hemos superado la ventana de contienda con lo que se vuelve al paso 3.

CSMA-CA no ranurado

Este algoritmo es muy similar al visto en el punto anterior. Los pasos a seguir son:

1. Inicialización de NB, CW y BE. Al igual que en el caso anterior NB = 0. En este caso sin embargo

CW = 0 con lo que no existe ventana de contienda: si se detecta una única vez que el canal no está

siendo usado se considera que está libre. Por otro lado, el modo no balizado no soporta el modo

macBattLifExt, por lo que directamente BE se iguala a macMinBE.

2. Idéntico al caso de CSMA-CA ranurado.

3. Idéntico al caso de CSMA-CA ranurado.

4. Idéntico al caso de CSMA-CA ranurado excepto que en este caso no reiniciamos CW a su valor

original puesto que estamos utilizando la ventana de contención..

5. Transmisión (como en el caso ranurado).


Figura 2.7: Diagrama de bloques del algoritmo CSMA-CA. Fuente: [10]

2.4.4. Inicialización y mantenimiento de PAN

Como hemos mencionado, la capa MAC es la encargada de gestionar la conexión y desconexión de un

dispositivo a la red. Para realizar esta tarea, así como la de inicializar la red para el caso del coordinador,

la capa MAC se sirve de los siguientes procedimientos:

Detección de energía de canal. Mediante este procedimiento, y a petición de las capas superiores,

la capa MAC mide la energía de un canal o lista de canales determinados. Para ello indica a la capa

física realizar una detección de energía de canal (ED) para cada uno de los canales elegidos. Mediante

este procedimiento el coordinador puede elegir, entre varios, canales aquel con menos tráco e iniciar

la red PAN en él.

2.4: CAPA MAC 21

Escaneo activo de canal. Permite a un dispositivo localizar a un coordinador que transmita balizas

y esté dentro de su rango de alcance. Los routers y los dispositivos nales usan este procedimiento

a la hora de asociarse a la red. Si el dispositivo se trata de un coordinador, este método se puede

usar para detectar las redes PAN dentro de un canal y así seleccionar un identicador distinto a los

ya existentes para la nueva red. Un dispositivo que realice un escaneo activo de canal transmitirá

periódicamente balizas. Si la red trabaja en modo no balizado, el coordinador responderá a cada una

de estas balizas con una nueva baliza. Si la red trabaja en modo balizado, el coordinador ignorará

estas balizas y seguirá transmitiendo de forma regular las suyas. Así, en cualquier caso, el dispositivo

que realiza el escaneo recibirá una serie de balizas como respuesta a su petición de asociación.

Escaneo pasivo de canal. La única diferencia con el caso anterior es que el dispositivo que realiza

el escaneo no transmite baliza alguna. Lo único que hará será escuchar el canal en busca de balizas

emitidas por el coordinador. Obviamente, este modo no es adecuado para el modo no balizado.

Escaneo de canal por un dispositivo huérfano. Si el dispositivo ha perdido la sincronización

con su coordinador emitirá lo que se conoce como noticaciones de orfandad. Las capas superiores

indicarán a la capa MAC por qué canales transmitir dichas noticaciones. El coordinador debe

responder a dicha noticación haciendo que la sincronización entre él y el dispositivo huérfano se

recupere.

2.4.5. Formato de trama

Se denen cuatro tipos distintos de tramas: formato general de trama MAC, tramas de baliza, tramas

de datos y tramas de ack.

Estas tramas están compuestas por:

Cabecera (MHR o MAC Header): Se compone por un campo de control, número de secuencia,

información de dirección destino y fuente e información relativa a la seguridad utilizada.

Carga útil. Este campo varía para cada uno de los cuatro tipos de tramas. Las tramas de ack no

contienen este campo.

Secuencia de control (MFR o MAC Footer): secuencia de 16 bits conocida como FCS (Frame Check

Sequence) que no es más que un código CRC (código de redundancia cíclico).

Formato general de trama MAC

MHR compuesto por:

− Control de trama: 16 bits para indicar el tipo de trama, si la trama utiliza un código de

seguridad, si se requiere de ack por parte del nodo adyacente, etc.

− Número de secuencia: 8 bits para identicar la trama.


(a) Formato general de trama MAC

(b) Trama de baliza

(c) Trama de datos

(d) Trama de ack

Figura 2.8: Distintos formatos de tramas MAC. Fuente: [11]

− Identicador de PAN destino: 16 bits para identicar el número de PAN con el que nos estamos

comunicando. Usamos el valor hexadecimal FFFF para indicar cualquier PAN.

− Dirección destino (16 ó 64 bits).

− Identicador de PAN origen (16 bits).

− Dirección origen (16 ó 64 bits).

Carga útil.

MFR.

2.5: CAPA DE RED 23

Tramas de baliza

El MHR y el MFR son exactamente iguales que en el caso anterior.

En este caso el campo de carga útil tiene el siguiente formato:

Especicación de supertrama: 16 bits para especicar los parámetros BO, SO, macBattLifExt, per-

miso de asociación, etc.

Información sobre los campos GTS.

Direcciones pendientes de ser atendidas (Pending address): Lista con las direcciones de los disposi-

tivos pendientes de comunicarse con el coordinador.

Carga útil: opcional.

Tramas de datos

El MHR y el MFR son exactamente iguales a los casos anteriores.

El campo de carga útil contiene la información pasada por las capas superiores.

Tramas de ack

El MHR está compuesto únicamente por los campos de control de trama y de número de secuencia.

Este tipo de trama no posee carga útil. El campo MFR es igual que en los casos anteriores.

2.5. Capa de red


La capa de red se dene en la especicación de ZigBee [9]. Esta capa es necesaria para gestionar las

capas físicas y MAC del estándar 802.15.4 y para proveer de una adecuada interfaz de servicio al nivel de

aplicación. Básicamente las tareas que realiza la capa de red son las siguientes:

Conguración de nuevos dispositivos.

Inicialización de la red PAN.

Asociación, reasociación y abandono de una red.

Adjudicación de direcciones de red.

Descubrimiento de la topología de red.

Encaminamiento (routing).

Las constantes y atributos utilizadas para congurar la capa de red son listadas en la denición del

estándar ZigBee [9] a partir de la página 338. Ejemplos de dichas constantes y atributos son nwkcCoordi-

natorCapable, nwkcDefaultSecurityLevel, nwkMaxChildren, nwkMaxDepth, nwkNeighborTable, etc.


A nivel de red, existen dos tipos de direcciones: direcciones cortas (16 bits) y direcciones largas o

direcciones IEEE (64 bits). Cada dispositivo debe tener asignada una dirección IEEE única. No puede

haber dos dispositivos que cumplan con la especicación ZigBee y que posean la misma dirección IEEE.

Así, esta dirección es asignada en el momento de la fabricación del dispositivo. Por contra, la dirección

corta es asignada por la capa de red de forma dinámica. Dentro de una red ZigBee no puede haber más

de un dispositivo con igual dirección corta.

2.5.2. Funciones

A continuación explicamos de forma más detallada las funciones principales que realiza la capa de red

ZigBee.

Establecer una nueva red

Sólo los dispositivos con capacidad para comportarse como coordinador (constante nwkcCoordinator-

Capable igual a 1) y no están actualmente asociados a una red pueden realizar este procedimiento.

El primer paso para establecer una nueva red es indicar a la capa MAC que realice una detección

de energía de canal para un determinado conjunto de canales o, en su defecto, para todos. Si estamos

obligados a trabajar únicamente en un canal, no es necesario realizar dicha detección de energía. Una

vez realizada la detección de energía de los canales, se ordenan de mayor a menor calidad, descartando

aquellos con un nivel de interferencia demasiado elevado. A continuación se realiza un escaneo activo de

canal para cada uno de ellos. Finalmente se elige aquel canal con menor interferencia y en el que trabaje

un menor número de redes ZigBee.

Una vez seleccionado el canal se elige un identicador de red menor que el valor hexadecimal 0xFFFF

(ya que éste signica cualquier red) y se indica a la capa MAC dicho valor. A continuación el dispositivo

que ha iniciado la red, el coordinador, se autoasigna la dirección corta 0x0000. Por último se indica a la

capa MAC que la red ha sido establecida con éxito.

Permitir a los dispositivos unirse a una red

Sólo el coordinador y los routers pueden realizar este procedimiento.

La capa de red modicará el valor del atributo macAssociationPermit de la capa MAC. Para el caso de

que macAssociationPermit sea TRUE el dispositivo en cuestión permitirá a otros dispositivos asociarse a

él. La capa de red puede modicar dicho valor de forma indenida o simplemente durante una cantidad

de tiempo determinada.

Descubrimiento de red

Mediante este procedimiento la capa de red indica a la capa superior qué redes ZigBee están operando

dentro del rango de alcance del dispositivo en cuestión.

La capa de red solicita a la capa MAC realizar un escaneo activo de canal para un determinado grupo

de canales. Una vez realizado la capa MAC responderá indicando en qué canales lógicos están trabajando

las redes encontradas, cuáles son sus identicadores (PAN ID) y si permiten o no a otros dispositivos

unirse a ellas.

2.5: CAPA DE RED 25

Unirse a una red

El primer paso para unirse a una red es efectuar un descubrimiento de red, como hemos visto en

el punto anterior. Una vez seleccionada la red en la que vamos a trabajar se realiza un listado con los

candidatos a padre (estos dispositivos serán routers y/o el coordinador que estén dentro del rango

de alcance del dispositivo en cuestión). Lógicamente descartaremos aquellos que no tengan activado el

permiso para unirse ellos. Entre los candidatos restantes seleccionaremos aquellos con menor profundidad

(mínima distancia hasta el coordinador); esto quiere decir que el coordinador siempre será prioritario, a

continuación los routers conectados directamente a él y así en adelante. Si varios candidatos cumplen las

mismas condiciones el dispositivo que intenta unirse a la red puede elegir libremente entre ellos.

Durante el procedimiento de unión a la red, el dispositivo debe enviar su dirección IEEE al candidato a

dispositivo. El dispositivo padre guardará en su lista de direcciones dicha dirección IEEE, le asociará una

dirección corta y, acto seguido, enviará esta dirección corta al dispositivo. En adelante ambos dispositivos,

padre e hijo, utilizarán esta dirección corta para comunicarse.

Cuando un dispositivo hijo pierde la conexión con su dispositivo padre, puede solicitar una reasociación

con éste. El procedimiento es idéntico al que acabamos de describir excepto por el detalle de que, aunque

el dispositivo padre haya cambiado su conguración y ya no acepte a otros dispositivos unirse a él,

permitirá asociarse al dispositivo hijo puesto que no se trata de una nueva asociación. Otra opción cuando

el dispositivo hijo ha perdido la conexión con el dispositivo padre es solicitar a la capa MAC realizar

un escaneo de canal por dispositivo huérfano. Cuando la capa MAC de un dispositivo huérfano realiza

este procedimiento envía su dirección IEEE. Cuando el padre recibe dicha dirección comprueba que dicho

dispositivo era su hijo y le responde indicando su antigua dirección corta, con lo que se considera que la

conexión se ha recuperado.

Tablas de vecindad

Un dispositivo debe guardar información de cada uno de los dispositivos dentro de su rango de al-

cance. Esta información es almacenada en la tabla de vecindad. Dicha tabla es de utilidad en diferentes

contextos. Primero, cuando un dispositivo intenta unirse a la red utiliza esta tabla para realizar el listado

de candidatos a dispositivos padre, como hemos visto en el punto anterior. Segundo, una vez asociado,

esta tabla se utiliza para almacenar parámetros relacionados con la calidad del enlace, tipo de relación y

demás información referente a los dispositivos dentro de nuestro rango de alcance. La tabla de vecindad

debe ser actualizada cada vez que recibimos una trama proveniente del otro dispositivo.

Los parámetros que se almacenan en esta tabla para cada uno de los distintos dispositivos son: dirección

IEEE, dirección corta, tipo de dispositivo, relación con dicho dispositivo (el dispositivo es el padre, hijo,

hijo asociado a un padre común, antiguo hijo, etc), LQI, número de saltos hasta dicho dispositivo, permiso

de asociación, si ha sido seleccionado como candidato a padre, etc.

Mecanismo distribuido de asignación de dirección corta.

Cuando un dispositivo padre (coordinador o router) recibe la petición de conexión por parte de otro

dispositivo (candidato a dispositivo hijo), el dispositivo padre debe asignarle una dirección corta.

Este algoritmo se basa en la generación de subgrupos de direcciones. El coordinador elige la primera


dirección libre, 0x0000. A continuación, asigna un subgrupo de las direcciones restantes a cada uno de

sus hijos con capacidades de router. Cada uno de esos hijos tendrá como dirección propia la primera del

subgrupo que le ha sido asignado, teniendo las restantes direcciones disponibles para repetir el proceso

con los dispositivos hijos que se conecten a él. Una vez asignados estos subgrupos de direcciones a los

routers, se asignan las direcciones a los dispositivos nales, comenzando por la primera dirección libre.

Para calcular el tamaño de estos subgrupos de direcciones se tienen en cuenta ciertos parámetros de

la red denidos por el coordinador: máximo número de hijos que un padre puede tener (nwkMaxChildren

o Cm), máxima profundidad de la red (nwkMaxDepth o Lm) y máximo número de routers que un padre

puede tener como hijos (nwkMaxRouters o Rm). Teniendo en cuenta que d es la profundidad de un deter-

minado dispositivo [9] (número de saltos necesarios por el camino más corto hasta llegar al coordinador,

0 ≤ d ≤ Lm) denimos la función Cskip(d) como sigue:

Cskip(d) =

1 + Cm · (Lm − d− 1) si Rm = 11 + Cm −Rm − Cm ·RLm−d−1

m1−Rm

en otro caso(2.3)

Cskip(d) es el tamaño del subgrupo de direcciones asignado a cada hijo de dicho dispositivo. Si el

resultado de la expresión anterior es negativo, se asume que Cskip(d) = 0, en cuyo caso el dispositivo

no puede tener dispositivos hijo. Formalmente, las direcciones asignadas a los dispositivos nales vienen

dadas por la siguiente expresión, donde Direcn es la dirección asignada al hijo número n y Direcpadre es

la dirección de su dispositivo padre:

Direcn = Direcpadre + Cskip(d) ·Rm + n (2.4)

En la denición del estándar ZigBee [9] podemos ver un ejemplo de dicho algoritmo. En él, para todos

los dispositivos de la red: Cm = 8, Rm = 4 y Lm = 3. En la tabla 2.2 podemos ver el tamaño de los

subgrupos de direcciones, Cskip(d), para los distintos valores de profundidad. En la gura 2.9 podemos

ver una representación de dicha red.

Profundidad en la red, d Cskip(d)0 311 72 1

3 (= Lm) 0

Cuadro 2.2: Ejemplo de tamaño de subgrupos de direcciones

Además de este, es importante mencionar que existe otro mecanismo de asignación de direcciones. Su

nombre es mecanismo estocástico de asignación de dirección [9]. En él, todas las direcciones (excepto la

del coordinador, que sigue siendo la 0x0000) se asignan de manera aleatoria. Únicamente ZigBee PRO

soporta el mecanismo estocástico de asignación de dirección.

2.5: CAPA DE RED 27

Abandonar una red

A la hora de abandonar una red se pueden dar dos casos distintos: el padre decide que un hijo debe

abandonar la red o el hijo comunica al padre que quiere abandonar la red. En ambos casos el dispositivo

padre debe actualizar su tabla de vecindad de forma que el dispositivo eliminado no aparezca en ella.

Encaminamiento

El coordinador de red y los routers tienen la opción de crear tablas de encaminamiento. Dichas tablas

contienen datos como la dirección corta del destino, el estatus de la ruta, o la dirección corta del siguiente

dispositivo en la ruta.

Para calcular la mejor ruta posible se usa un algoritmo que se basa en el coste de un camino

determinado. El coste se puede calcular teniendo en cuenta el número de saltos necesario y la calidad de

los enlaces (usando el indicador LQI).

Figura 2.9: Ejemplo de red mostrando el Cskip(d) y las direcciones de red


El formato general de trama de capa de red se muestra en la gura 2.10.

Figura 2.10: Formato general de trama de red


La trama está formada por:

Campo de control de trama. Está compuesto por 16 bits que indican el tipo de trama, la versión

del protocolo y si se está empleando seguridad en la transmisión, principalmente.

Dirección corta de destino. El valor 0xFFFF se usa para enviar el paquete a todos los nodos

dentro del rango de alcance.

Dirección corta de origen.

Radio. Cada dispositivo que reciba la trama restará uno al valor de esta variable. Así podremos

limitar el máximo número de saltos de la trama.

Número de secuencia. Gracias a la dirección origen y al número de secuencia se puede identicar

una trama de forma unívoca.

Dirección IEEE destino. Su uso es opcional y es indicado en el campo de control de trama.

Dirección IEEE origen. Su uso es opcional y es indicado en el campo de control de trama.

Campo de control Multicast . Su uso es opcional y es indicado en el campo de control de trama.

Dene parámetros necesarios para la transmisión multicast.

Subtrama de ruta origen. Su uso es opcional y es indicado en el campo de control de trama.

Carga útil.

2.6. Capa de aplicación


La capa de aplicación ZigBee está compuesta por la subcapa de soporte de aplicación (APS), el marco

de aplicación (application framework) y el objeto de dispositivo ZigBee (ZigBee Device Object o ZDO).

En la gura 2.11 podemos ver una representación de la capa de aplicación y sus diferentes partes.

Figura 2.11: Capa de aplicación

2.6: CAPA DE APLICACIÓN 29

En el siguiente subapartardo explicaremos cada una de las partes que componen la capa de aplicación

ZigBee. No obstante, antes es necesario explicar el signicado de varios términos bastante recurrentes a

la hora de hablar de la capa de aplicación:

Perl de aplicación. Describe el intercambio de mensajes de un conjunto de dispositivos empleados

para una determinada aplicación. Por ejemplo, el perl de aplicación que dene un sistema de

domótica es distinto al que dene un sistema de control de sensores para la industria.

Cluster . Es un conjunto de atributos que se utilizan en la comunicación de los distintos dispositivos

ZigBee. Por ejemplo, dentro de un sistema de domótica, se puede denir un cluster para el control

de luces, otro para el control de temperatura, etc.

Punto de acceso (endpoint). Dentro de un mismo dispositivo, se pueden denir varios puntos de

acceso. Cada uno de estos puntos de acceso gestiona el funcionamiento de una aplicación diferente.

Siguiendo con el ejemplo del sistema de domótica, un router que funcione como control remoto

puede tener un punto de acceso para el manejo del sistema de alarmas, otro para el control de luces,

otro para el de temperatura, etc.

Vínculo (binding). Es una conexión lógica entre un punto de acceso origen y uno o varios de

destino. Sólo se puede realizar un vínculo entre puntos de acceso que compartan el mismo cluster.

Ya que un dispositivo puede poseer varios puntos de acceso, también puede soportar varios vínculos.

2.6.2. Subcapas

Subcapa de soporte de aplicación (APS o Application Sublayer)

La subcapa de soporte de aplicación proporciona una interfaz de comunicación entre la capa de red y

la capa de aplicación. Las tareas que realiza esta capa son:

Genera la PDU a nivel de aplicación.

Una vez los puntos de acceso de dos dispositivos están vinculados, la capa APS es la encargada de

gestionar el intercambio de mensajes.

Mejorar la abilidad de la capa de red. Por ejemplo, se puede denir una conrmación ack a nivel

de aplicación.

Rechaza mensajes recibidos por duplicado.

Marco de aplicación (AF o Application Framework)

El marco de aplicación es el entorno en el cual se gestionan las diferentes aplicaciones. Cada una de

dichas aplicaciones está relacionada a un punto de acceso distinto.

Se permiten hasta 240 aplicaciones distintas dentro de un mismo dispositivo. El punto de acceso 0 está

asignado al nivel ZDO. El rango de 241-254 está reservado para uso futuro. Por último, el punto de acceso

255 es usado para la comunicación broadcast con todas las aplicaciones dentro del marco de aplicación.

Esta capa es la encargada de denir tanto el perl de aplicación como los diferentes clusters. Cada

cluster se caracteriza por un identicador propio (cluster ID).


Objeto de dispositivo ZigBee (ZDO o ZigBee Device Object)

Este nivel satisface necesidades comunes a todas las aplicaciones dentro del marco de aplicación. Las

tareas que realiza son:

Inicializar las capas APS y de red.

Denir el rol del dispositivo dentro de la red (coordinador, router o dispositivo nal).

Gestiona los vínculos entre puntos de acceso.

Asegura una comunicación segura entre dispositivos.

Como hemos dicho anteriormente, el ZDO se encuentra en el punto de acceso 0.


El formato general de trama de capa de aplicación se muestra en la gura 2.12.

Figura 2.12: Formato general de trama de aplicación

La trama está compuesta por:

Campo de control de trama. Está formado por 8 bits que indican el tipo de trama, si se utiliza

seguridad, si estamos empleando la extensión de cabecera y si se requiere conrmación ack a nivel

de aplicación.

Dirección del punto de acceso destino.

Dirección de grupo. Si se usa direccionamiento de grupo la trama no debe incluir la dirección del

punto de acceso destino. Todos los puntos de acceso asociados a la dirección de grupo en cuestión

recibirán esta trama.

Cluster ID. Identicador de cluster.

Perl ID. Identicador del perl de aplicación.

Dirección del punto de acceso origen.

Contador APS. Se usa para evitar la recepción de tramas duplicadas.

Extensión de cabecera. Extiende la funcionalidad de la cabecera.

Carga útil.

2.7: SEGURIDAD 31

2.7. Seguridad

Desde el punto de vista de la seguridad, las redes inalámbricas son altamente vulnerables debido a que

no se requiere tener acceso a un medio cableado para participar en las comunicaciones. ZigBee/802.15.4

está orientado hacia un mercado en el que el bajo consumo y el bajo coste son requisitos esenciales.

Debido a la restricción en lo que al coste se reere, los dispositivos que trabajan con esta tecnología

se enfrentan a una limitación computacional evidente. Esto quiere decir que los sistemas de seguridad

son mas difíciles de implementar en sistemas que trabajan bajo ZigBee/802.15.4. Además, a la hora de

implementar mecanismos de seguridad para ZigBee/802.15.4 se ha tenido en cuenta que los dispositivos no

tienen por qué tener acceso a una base de datos de forma continua. De esta forma, los distintos dispositivos

deben ser capaces de gestionar los mecanismos de seguridad por sí mismos. Por último, es importante

destacar que ZigBee/802.15.4 está orientado hacia en envío de pequeños paquetes de información, por lo

que los mecanismo de seguridad utilizados no deberían aumentar en exceso el tamaño de la cabecera

En los estándares ZigBee [9] y 802.15.4 [10] se denen mecanismos de seguridad para las capas MAC,

de red y de aplicación. El mecanismo criptográco utilizado se basa en el uso de claves simétricas. La

clave en cuestión debe ser generada por las capas superiores. El mecanismo criptográco debe ser capaz

de asegurar:

Condencialidad de los datos o privacidad. Esto quiere decir que la información transmitida sólo de

llegar a los dispositivos asociados a la red.

Autenticación de los datos. Se debe asegurar que la información recibida proviene de un dispositivo

válido (en otras palabras, no ha habido intromisión en las comunicaciones).

Detección de información duplicada. Los paquetes de información deben de ser recibidos únicamente

una vez.

De acuerdo al estándar [10] la clave utilizada puede ser conocida por los dos dispositivos que participan en

la comunicación o por un grupo de dispositivos. Si utilizamos una única clave para un grupo de dispositivos

ganamos en simplicidad pero, por contra, estamos desprotegidos ante el ataque de un dispositivo de la

propia red.

ZigBee/802.15.4 usa el modo CCM*, una variante del modo CCM (Counter with CBC-MAC ). CCM*

usa bloques de encriptación basados en el algoritmo AES-128 (Advanced Encryption Standard). CCM* es

un modo simétrico, lo que quiere decir que tanto el dispositivo que transmite como el que recibe usan la

misma clave para descifrar el mensaje.

En caso de que la seguridad esté habilitada, el coordinador es normalmente el que realiza las funciones

de centro de seguridad, permitiendo o no la asociación de un nuevo dispositivo. El centro de seguridad

debe actualizar periódicamente la clave utilizada, cambiándola por una nueva si lo estima necesario. Para

ello, distribuye la nueva clave encriptada con la antigua. Después comunica a todos los dispositivos que a

partir de ese momento deben usar la nueva clave.

El centro de seguridad, que como hemos dicho suele ser el coordinador pero que también puede ser un

dispositivo expresamente dedicado a ello, realiza las siguientes funciones:

Autenticar dispositivos que quieren unirse a la red.


Generar y distribuir nuevas claves.

Habilitar el uso de seguridad punto a punto entre dispositivos.

ZigBee/802.15.4 usa tres tipos de claves:

Claves de enlace. Sirven para dotar de seguridad las comunicaciones punto a punto a nivel de

aplicación. Sólo lo dos dispositivos que participan en la comunicación conocen esta clave.

Claves de red. Esta clave se usa para la seguridad a nivel de red. Todos los dispositivos dentro de

una misma red deben compartir esta clave.

Claves maestro. Esta clave es utilizada por dos dispositivos en el inicio de la comunicación para

generar la clave de enlace. La clave maestro no se usa para encriptar tramas.

Se denen dos tipos de seguridad:

Modo de seguridad estándar. En este modo la lista de dispositivos pertenecientes a la red y

las diferentes claves pueden estar almacenadas dentro de cada uno de los distintos dispositivos. El

centro de seguridad solamente se encarga de mantener una clave de red común y de controlar las

políticas de admisión. Así, el centro de seguridad no necesita una gran memoria para almacenar los

datos relacionados con la seguridad de la red.

Modo de seguridad avanzado. En este caso el centro debe almacenar tanto las claves como el

listado de dispositivos, así como de controlar las políticas de admisión. Conforme crezca el número de

dispositivos asociados a la red, aumentarán los requerimientos de memoria del centro de seguridad.

Solamente ZigBee PRO soporta este modo de seguridad.

Las diferentes capas añadirán una cabecera auxiliar en el caso de que utilicemos un modo seguro de trans-

misión. Además, se debe incluir un código de integridad (MIC o Message Integrity Code) a continuación

de la carga útil. Figura 2.13.

(a) Capa MAC

(b) Capa de red

(c) capa de aplicación

Figura 2.13: Formato de trama con seguridad habilitada

2.8: IMPLEMENTACIONES COMERCIALES 33

2.8. Implementaciones comerciales

Algunos de los principales fabricantes de dispositivos electrónicos basados en ZigBee/802.15.4 son:

Atmel (www.atmel.com)

Esta empresa ofrece dispositivos basados en la combinación de su serie de microcontroladores cono-

cida como AVR y un sistema radio especialmente diseñado para 802.15.4. Atmel ofrece dos gamas de

dispositivos:

Series AT86RF230 y AT86RF231. Ambas trabajan a 2,4 GHz.

Serie AT86RF212. Esta serie trabaja en las frecuencias de 868 y 915 MHz y cumple con el estándar

802.15.4c. Dicho estándar es una variante del 802.15.4 que especica el uso de la banda ISM en

China. Con la comercialización de esta serie Atmel pretende expandir su cuota de mercado en dicho

país.

El entorno de desarrollo utilizado para la programación de los microcontroladores es AVR Studio.

Atmel también dispone de kits de desarrollo/evaluación, como ATAVRRZRAVEN, muy útiles para

desarrolladores en las primeras etapas de diseño.

Ember (www.ember.com)

Ember se centra casi exclusivamente en la fabricación de dispositivos relacionados con ZigBee/802.15.4.

Los productos básicos que ofrece son:

EM250 SoC. Sistema que engloba tanto el microprocesador como el transceptor. Trabaja a 2,4 GHz.

EM260 Co-Processor. Este chip combina un transceptor, que también trabaja a 2,4 GHz, con un

microprocesador de capacidad limitada. Tiene una conexión SPI (Serial Peripheral Interface)/UART

(Universal Asynchronous Receiver-Transmitter) para poder conectar cualquier microprocesador a

dicho sistema. De esta forma se permite al diseñador implementar de forma independiente la parte

más alta de la capa de aplicación (marco de aplicación).

Las capas de red y de aplicación de dichos dispositivos trabajan usando EmberZNet PRO, una versión

propia del estándar ZigBee.

Ember también ofrece kits de desarrollo basados bien en EM250 o en EM260.

Freescale (www.freescale.com)

En relación con ZigBee/802.15.4, Freescale ofrece las siguientes gamas de productos:

MC1320X RF Transceiver. Transceptor basado en 802.15.4. Posee una conexión SPI para poder

conectarlo a cualquier microprocesador.

MC1321X System in Package. Combina un transceptor MC13202 con un microprocesador de freescale

(MC9S08GT).


MC13224 Platform in Package. Combinación de transceptor 802.15.4 y microcontrolador centrada

en la optimización energética del transceptor.

La versión ZigBee de Freescale es conocida como BeeStack. Respecto a la capa MAC, Freescale ofrece la

posibilidad de usar el protocolo SMAC (simple MAC), una versión propia y simplicada de la capa MAC

802.15.4.

Los kits de desarrollo que ofrece son 1321X ó 1322X Development Kits.

Jennic (www.jennic.com)

Jennic oferta los siguientes chips:

JN5148.

JN5139.

JN5121.

Los tres están compuestos por un transceptor y un microprocesador. JN5148 es el producto más reciente

y el que ofrece unas mejores características.

Jennic tiene una versión propia de la capa de red conocida como JenNet.

Dispone de un kit de desarrollo para principiantes, JN5139 IEEE802.15.4/JenNet Starter Kit, y de

una versión más profesional, JN5139 IEEE802.15.4/JenNet Evaluation Kit.

Texas Instruments (www.ti.com)

Texas Instruments (TI) ofrece varias gamas de productos ZigBee/802.15.4, todas ellas trabajando a

2,4 GHz:

CC2430 y CC2431. Combinación de transceptor y microcontrolador en un único chip. Trabaja usando

Z-Stack, la versión de ZigBee de TI. Los Kits de desarrollo asociados son CC2430DK y CC2431DK.

CC2480. Coprocesador ZigBee con conexión SPI/UART. Está pensado para trabajar conectado a

un microprocesador. El coprocesador ZigBee maneja el sistema radio y en él se integran las capas

física, MAC, de red y parte de la de aplicación. El Kit de desarrollo asociado es eZ430-RF2480.

CC2420 y CC2520. Transceptor 802.15.4 pensado para trabajar conectado a un microprocesador

MSP430 de TI. El Kit de desarrollo asociado es CC2520DK.

TI también brinda la oportunidad de trabajar con una capa MAC propia conocida como TIMAC.

El entorno de desarrollo utilizado para la programación de los microcontroladores es IAR Embedded

Workbench [31].

El listado de empresas expuesto no es exhaustivo y sólo pretende servir como visión general del mercado

de componentes electrónicos ZigBee/802.15.4. Por supuesto, otras muchas empresas dedican sus esfuerzos

al desarrollo y comercialización de este tipo de dispositivos. Ejemplos de ello son Microchip Technology,

STMicroelectronics, Uniband Electric Corporation, ZMD, etc.

2.8: IMPLEMENTACIONES COMERCIALES 35

De entre todas las opciones comerciales posibles hemos elegido el kit de desarrollo eZ430-RF2480 de

TI para la realización de nuestro proyecto. En primer lugar TI es una empresa con gran proyección de

futuro dentro del campo de los componentes electrónicos orientados a ZigBee/802.15.4. En segundo lugar,

eZ430-RF2480 nos ofrece todo lo necesario para realizar nuestro estudio sobre el consumo de corriente en

nodos 802.15.4 de forma más simple y rápida que utilizando otros kits de desarrollo.

En el siguiente capítulo expondremos en profundidad las componentes hardware y software del kit

eZ430-RF2480.


Capítulo 3

Herramientas de desarrollo empleadas y

sistema de medida

En el presente capítulo expondremos todas las herramientas de las cuales nos hemos servido durante

el desarrollo de nuestro proyecto. En primer lugar veremos el kit de desarrollo eZ430-RF2480, el cual está

compuesto por una serie de dispositivos congurables que nos permitirán formar una red ZigBee/802.15.4.

A continuación daremos un repaso a todas las herramientas de instrumentación y el software que hemos

utilizado. Por último, expondremos el circuito de medida empleado para realizar nuestras medidas.

3.1. Kit de desarrollo eZ430-RF2480

3.1.1. Introducción

Para la realización de nuestro estudio del consumo de potencia en redes ZigBee/802.15.4 usaremos el

kit de desarrollo eZ430-RF2480 de Texas Instruments. Antes de entrar en detalles deniremos los tres

tipos distintos de dispositivos ZigBee/802.15.4 en lo que a arquitectura hardware se reere:

Arquitectura basada en un transceptor 802.15.4 y un Microprocesador. En este tipo de dispositivos

el transceptor se ocupa de la parte radio (capa física 802.15.4) mientras que el microprocesador se

encarga de gestionar la capa MAC, de red y de aplicación.

Arquitectura basada en un procesador ZigBee/802.15.4 y un Microprocesador. Ahora, el procesador

ZigBee/802.15.4 gestiona tanto la capa física como las capas MAC y de red, dejando al microproce-

sador encargado únicamente de la parte de aplicación. Estos sistemas son más simples, pero menos

exibles, de cara al desarrollador puesto que éste sólo se debe ocupar de la aplicación, dejando que

el procesador ZigBee/802.15.4 gestione el resto de capas.

Arquitectura basada en un dispositivo completamente integrado (System-on-chip o SoC). En este

último caso, tanto el transceptor como el microprocesador están integrados en un único chip.

El kit de desarrollo eZ430-RF2480 pertenece al segundo tipo de los mencionados arriba, se trata de un

procesador ZigBee/802.15.4 más microprocesador. El procesador ZigBee/802.15.4 es un CC2480 y, como

37

38 CAPÍTULO 3: HERRAMIENTAS DE DESARROLLO EMPLEADAS Y SISTEMA DE MEDIDA

hemos dicho, realiza las tareas de la capa física, MAC y de red. El microprocesador es un MSP430. Ambos

dispositivos están conectados por un bus SPI. En la gura 3.1 podemos ver una representación de la

distribución de las capas del protocolo ZigBee/802.15.4 entre CC2480 y MSP430.

La versión propia del estándar ZigBee que ha realizado TI se denomina Z-Stack. Así, se puede decir

que en este tipo de dispositivo el procesador CC2480 se encarga del protocolo Z-Stack. A esta combinación

de procesador ZigBee/802.15.4 y del protocolo Z-Stack, TI la denomina Z-Accel. El objetivo es hacer que

el desarrollador se centre en la creación de su aplicación dejando que el dispositivo Z-Accel se encargue

de la parte ZigBee/802.15.4.

Figura 3.1: Distribución de la pila de protocolos entre microprocesador y CC2480

La aplicación que, por defecto, viene instalada en el MSP430 se denomina ZASA (ZigBee Accelerator

Sample Application) y pretende ser un ejemplo simple de una aplicación ZigBee.

El kit eZ430-RF2480 está compuesto por tres tabletas iguales (gura 3.2c), un conector USB (gura

3.2a) y dos conectores para baterías AAA (gura 3.2b). La tableta, aparte de contener el procesador

CC2480 y el microprocesador MSP430 también está compuesta por un sensor de luz, un botón, dos

diodos LED (uno verde y otro rojo) y, lógicamente, por una antena que, para este caso particular y para

ahorrar en tamaño y consumo, es de tipo chip.

(a) Conector USB eZ430 (b) Conector de baterías AAA (c) Tableta vista por ambas caras

Figura 3.2: Componentes del kit eZ430-RF2480. Fuente: [22]

3.1: KIT DE DESARROLLO EZ430-RF2480 39

En la gura 3.3 vemos como las diferentes partes se conectan entre sí. Como vemos, con un kit

disponemos de hasta tres nodos ZigBee/802.15.4 para formar nuestra red. Estos nodos son de tipo FFD

puesto que pueden funcionar como coordinador, router o dispositivo nal. Dos dispositivos están alimen-

tados por baterías y un tercero lo está a través de la conexión USB a un PC. Gracias al dispositivo

conectado al PC, podemos visualizar diferentes parámetros de la red.

Figura 3.3: Conexión de los componentes del kit eZ430-RF2480. Fuente: [22]

Cuando utilizamos los dispositivos con ZASA como aplicación, es en el momento de la inicialización

cuando denimos la funcionalidad del dispositivo. Así, una conguración básica sería congurar el primer

dispositivo como coordinador, el siguiente como router, y el último de ellos como dispositivo nal. Una

vez los dispositivos han sido congurados, todos ellos comienzan a enviar de forma periódica datos al

coordinador. La idea es que el coordinador sea el que esté conectado al PC de forma que podamos

visualizar los paquetes de datos recibidos mediante alguna aplicación.

Esta es simplemente una visión general de la aplicación ZASA. En la sección 3.1.5 describiremos su

funcionamiento en profundidad y propondremos posibles modicaciones de dicha aplicación.

3.1.2. CC2480

Como hemos dicho, el CC2480 es un procesador ZigBee/802.15.4 que abarca las capas física, MAC y

de red. Posee una conexión SPI/UART para poder conectarse con cualquier microprocesador. La imple-

mentación ZigBee de TI, Z-Stack, está cargada en el CC2480. CC2480 cumple con el estándar ZigBee-2006

[9].

Por último es importante destacar que el procesador CC2480 trabaja en modo no balizado.

Para una comprensión en profundidad de las características técnicas del procesador CC2480 aconse-

jamos acudir a su hoja de características en [13].

Arquitectura

En la gura 3.4, realizada basándonos en [12], se muestra un esquema de la arquitectura de conexión

entre el CC2480 y un microprocesador funcionando como host .


Figura 3.4: Conexión entre el integrado CC2480 y un microprocesador

Las diferentes interfaces del chip CC2480 son:

Interfaz SPI/UART. Es el bus que permite el intercambio de datos entre CC2480 y el microproce-

sador. SPI es un bus serie de transmisión síncrono. UART es un bus asíncrono que convierte los bits

de paralelo a serie antes de enviarlos. Esta interfaz requiere 4 pines. Más adelante profundizaremos

en su funcionamiento.

Control de activación. Esta interfaz está compuesta por 2 señales: SRDY (slave ready) y MRDY

(master ready). SRDY es activada por el CC2480 cuando éste está listo para recibir datos, se activa

a nivel bajo. MRDY es activada a nivel bajo por el microprocesador para indicar que tiene datos

listos que enviar al CC2480.

Reset. El microprocesador puede inicializar, mediante esta interfaz, el chip CC2480. Está compuesto

por un pin. Aparte de este reseteo hardware, también existe la posibilidad de realizar un reseteo

software a través de la interfaz SPI/UART.

Conguración. Compuesta por dos pines, denominados CFG0 y CFG1. CFG0 indica si el os-

cilador de cristal opcional de 32,768 kHz está instalado. CFG1 está activo cuando seleccionamos

comunicación por SPI e inactivo cuando lo hacemos por UART.

GPIO. Está compuesto por 4 pines. El microprocesador puede leer y escribir en dichos pines a

través del CC2480.

Entrada ADC. El CC2480 posee un conversor analógico digital. La entrada ADC (Analog to Digital

Converter) está compuesta por dos pines que pueden ser utilizados como entrada a este conversor.

En la gura 3.5 mostramos los diferentes pines del CC2480 y en la tabla 3.1 describimos los más signi-

cativos.


Figura 3.5: Distribución de pines en CC2480. Fuente: [13]

Pin Nombre Dirección Conexión Descripción

3 GPIO3 Congurable Opcional Pin congurable4 GPIO2 Congurable Opcional Pin congurable5 SRDY Salida Obligatoria para SPI Esclavo listo (SPI)6 MRDY Entrada Obligatoria para SPI Maestro listo (SPI)8 GPIO1 Congurable Opcional Pin congurable9 GPIO0 Congurable Opcional Pin congurable10 RESET_N Entrada Recomendada Reset (activo a nivel bajo)11 CFG0 Entrada Opcional Pin de conguración12 CFG1 Entrada Opcional Pin de conguración13 SO/RX Salida/Entrada Obligatoria Salida SPI o RX UART14 SI/TX Entrada/Salida Obligatoria Entrada SPI o TX UART15 SS/CT Entrada/Salida Obligatoria Slave Select (SPI) o Clear to Send (UART)16 C/RT Entrada Obligatoria reloj SPI o Request to Send (UART)17 A0 Entrada Opcional Entrada analógica al conversor ADC18 A1 Entrada Opcional Entrada analógica al conversor ADC

Cuadro 3.1: Descripción de los principales pines del CC2480


Vemos que el CC2480 está concectado a dos relojes de cristal: XTAL1, de 32 MHz y XTAL2, de

32,768 kHz. Como hemos mencionado más arriba, el reloj de 32,768 kHz es opcional y su instalación la

indicaremos activando el pin CFG0. En eZ430-RF2480 tenemos instalado el reloj de 32,768 kHz luego

CFG0 está activo por defecto. Aparte de estos relojes de cristal externos, el dispositivo CC2480 tiene dos

relojes RC internos de valores 32 kHz y 16 MHz que son calibrados usando el reloj de cristar externo

XTAL1.

Respecto a la antena podemos mejorar las caracteristicas de transmisión utilizando un dipolo o una

antena impresa en lugar de una antena tipo chip. El kit eZ430-RF2480 viene de serie con una antena chip

de forma que tanto el consumo como su coste, como ya hemos dicho antes, sean menores. Por supuesto,

el alcance con una antena chip es menor que utilizando otro tipo de antena más sosticado.

En eZ430-RF2480, el microprocesador (MSP430 en este caso) y el CC2480 están conectos a través de

un bus SPI. Esto lo indicamos de cara al CC2480 activando el pin CFG0.

El conversor ADC interno del CC2480 está conectado a los pines de entrada A0 y A1 que, para el caso

particular del modelo eZ430-RF2480, no son utilizados.

A continuación, veremos con más profundidad el formato de trama que se intercambian microproce-

sador y CC2480 y cómo funcionan las comunicaciones entre ellos.

Formato de trama de comunicación entre los integrados MSP430 y CC2480

En la gura 3.6 se muestra el formato de trama de los mensajes intercambiados entre CC2480 y

MSP430. El byte de la izquierda se transmite primero por el bus SPI y así hasta llegar al último.

Figura 3.6: Formato de trama de comunicación entre microprocesador y CC2480

El primer byte que se transmite es SOF (Start Of Frame indicator) que indica el comienzo de trama.

En ZASA, por defecto, SOF tiene el valor de 0xFE. El siguiente byte indica la longitud del campo de

datos. Los dos siguientes bytes sirven para indicar el comando. A continuación se transmiten los datos

(este campo puede estar vacío). Por último se transmite el campo FCS (Frame Check Sequence), que no

es más que un checksum (XOR) entre todos los bytes de la trama excepto el SOF.

Los bits del comando se distribuyen tal y como vemos en la gura 3.7.

Figura 3.7: Bits de comando

Los comandos intercambiados entre microprocesador y CC2480 pueden ser de tres tipos. El caso más


simple es cuando el microprocesador envía una petición al CC2480 de la que no espera respuesta. Este

tipo de petición se denomina asíncrona (AREQ o Asynchronous Request en inglés). En el segundo, cuando

el microprocesador necesita recibir una repuesta por parte del CC2480, se dice que la petición es síncrona

(SREQ o Synchronous Request). La repuesta por parte del CC2480 debe ser inmediata y se denomina

SRSP (Synchronous Response). Por último, el CC2480 tiene la posibilidad de enviar también peticiones al

microprocesador. Como el microprocesador es siempre quien lleva la iniciativa, deberá enviar un comando

POLL (sondeo) al CC2480 para ver si éste tiene una petición para él. Los bits que indican el tipo de

comando toman los valores que vemos en la tabla 3.2a.

Valor Tipo de comando

0 POLL1 SREQ2 AREQ3 SRSP

Resto Reservado

(a) Tipo de comando

Valor Subsistema

1 Interfaz SYS4 Interfaz AF5 Interfaz ZDO6 Interfaz Simple API

Resto Reservado

(b) Subsistema del comando

Cuadro 3.2: Valores posibles para los campos tipo y subsistema de comando

Como vimos en la sección 2.6.2, la parte más alta de la capa de aplicación ZigBee está formada por las

subcapas Marco de aplicación (AF) y Objeto de dispositivo ZigBee (ZDO). Los bits de subsistema dentro

del campo comando sirven para indicar a qué subcapa de aplicación va destinado el comando (tabla 3.2b).

Las interfaces SYS y Simple API (Application Programming Interface) serán explicadas más adelante.

Por último, el subcampo ID, formado por 8 bits, sirve como identicador para cada uno de los coman-

dos.

Comunicaciones entre MSP430 y CC2480

Como ya hemos dicho en varias ocasiones, MSP430 y CC2480 pueden utilizar un bus SPI o UART para

sus comunicaiones. La elección de uno u otro la realiza el microprocesador, el cual se la indica al CC2480

mediante el pin CFG0 (activo para SPI e inactivo para UART). Tanto si utilizamos uno u otro mecanismo

de comunicación los pines empleados son los mismos: SO/RX, SI/TX, SS/CT y C/RT (pines 13 a 16).

En el kit de desarrollo eZ430-RF2480 se utiliza el bus SPI para las comunicaciones por lo que será este

procedimiento el que explicaremos a continuación. También es importante señalar que las comunicaciones

por SPI se sirven del uso de los pines SRDY y MRDY gestionados respectivamente por CC2480 (esclavo)

y MSP430 (maestro) para indicar que están listos para realizar las comunicaciones.

Puesto que SPI es un bus de transferencia síncrono, es necesario transmitir una señal de reloj. El pin

C/RT sirve para transmitir dicha señal de reloj como vemos en la tabla 3.1. El pin SS (slave select),

activo a nivel bajo, se usa cuando hay más de un esclavo conectado a un maestro. En ese caso, el esclavo

seleccionado debe activar este pin. Puesto que en nuestro caso sólo tenemos un esclavo, el valor de SS y de

MRDY siempre deben coincidir. Cuando SS y MRDY están activos (0 lógico) quiere decir que el CC2480

es elegido como destinatario y que el MSP430 está listo para enviar información. El pin SI se utiliza para

el envío serie en el sentido maestro a esclavo mientras que el pin SO funciona en sentido inverso, del


esclavo hacia el maestro.

Cuando el microprocesador quiera enviar una petición al CC2480 activará MRDY y SS y esperará

a que SRDY se active indicando que éste está listo para recibirla. Repetimos que MRDY, SRDY y SS

se activan a nivel bajo (0 lógico). El microprocesador nunca deberá desactivar MRDY sin antes haber

transmitido todos los bytes de la trama.

A continuación mostramos las variaciones de las distintas señales para los casos de envío de AREQ,

SREQ con SRSP como respuesta y POLL con respuesta:

AREQ

Figura 3.8: AREQ. Fuente: [12]

1. El microprocesador tiene una trama AREQ por transmitir. Activa MRDY a nivel bajo y espera a

SRDY.

2. CC2480 detecta el anco de bajada de MRDY. Cuando está listo para recibir la trama activa SRDY

a nivel bajo.

3. El microprocesador detecta que SRDY está a nivel bajo y comienza la transmisión.

4. El microprocesador transmite la trama al completo.

5. El CC2480 recibe la trama al completo.

6. El microprocesador ha nalizado de transmitir y espera que SRDY se desactive (nivel alto).

7. CC2480 ha recibido todos los datos y pone SRDY a nivel alto.

8. El microprocesador detecta que SRDY está a nivel alto y pone MRDY a nivel alto también.


SREQ

Figura 3.9: SREQ. Fuente: [12]

Es importante señalar que, en este caso, cuando el CC2480 está listo para enviar su respuesta síncrona

(SRSP) al microprocesador, pone SRDY a nivel alto indicando que ya no está listo para recibir sino para

transmitir (paso 8). Los pasos ahora seguirían la siguiente secuencia:

1. El microprocesador tiene una trama SREQ por transmitir. Activa MRDY a nivel bajo y espera a

SRDY.

2. CC2480 detecta el anco de bajada de MRDY. Cuando está listo para recibir la trama activa SRDY

a nivel bajo.

3. El microprocesador detecta que SRDY está a nivel bajo y comienza la transmisión.



6. El microprocesador espera a que SRDY vuelva a nivel alto.

7. CC2480 procesa el comando solicitado por el microprocesador y ejecuta la función.

8. Una vez ejecutada la función el CC2480 prepara la trama SRSP y pone SRDY a nivel alto indicando

que ya no está listo para recibir sino para transmitir.

9. El microprocesador detecta SRDY a nivel alto y comienzan las comunicaciones.

10. El microprocesador recibe la trama al completo.

11. CC2480 transmite la trama al completo.

12. El microprocesador ha recibido todos los bytes y desactiva MRDY poniéndolo a nivel alto.


POLL

Figura 3.10: POLL. Fuente: [12]

Al igual que en el caso anterior, el CC2480 pondrá SRDY a nivel alto para indicar que tiene los datos

listos para transmitir hacia el microprocesador (paso 6).

1. CC2480 está listo para enviar una trama AREQ hacia el microprocesador. Como es necesario que

el microprocesador le solicite primero dicha trama, el CC2480 coloca SRDY a nivel bajo a la espera

de un comando POLL por parte del microprocesador.

2. El microprocesador detecta SRDY a nivel bajo y coloca MRDY a nivel bajo también. Prepara el

comando POLL y comienza la transmisión de la trama.



5. El microprocesador espera hasta que SRDY se ponga a nivel alto.

6. El CC2480 prepara la trama AREQ a enviar y, cuando está listo, coloca SRDY a nivel alto.

7. El microprocesador detecta SRDY a nivel alto y comienzan las comunicaciones.

8. El microprocesador recibe la trama al completo.

9. El CC2480 transmite la trama al completo.

10. El microprocesador ha recibido todos los bytes y desactiva MRDY poniéndolo a nivel alto.

Interfaz de aplicación

En este apartado explicaremos la función de las cuatro interfaces que se utilizan para las comunicaciones

entre microprocesador y CC2480. Para cada una de ellas daremos un listado con los comandos que la

componen. En este documento no entramos en detalles respecto a cómo utilizar cada comando ni de qué

partes está compuesto su campo de datos. Para ello se propone la consula del documento CC2480 Interface

Specication [12]. Aunqué será más adelante cuando explicaremos de forma detallada el funcionamiento


de la aplicación ZASA, mencionaremos ahora cuáles de los comandos expuestos son utilizados por esta

aplicación.

Las diferentes interfaces son:

Interfaz de sistema (SYS).

Esta interfaz proporciona al microprocesador un medio para modicar atributos software y hardware

del CC2480. Por ejemplo podremos manejar el conversor ADC, acceder a la memoria NV (non-

volatile memory), manejar los pines GPIO, los relojes software o el generador de números aleatorios

que también incorporta el CC2480. En la tabla 3.3 podemos ver todos los compandos que pertenecen

a esta interfaz. Todos los comandos tipo SREQ llevan asociada una respuesta SRSP que no se muestra

ni en esta tabla ni en las siguientes por simplicidad.

En ZASA el único comando de la interfaz SYS que se utiliza es sys_reset_ind.

Comando Tipo Nombre

0x4100 AREQ sys_reset_req0x4180 AREQ sys_reset_ind0x2102 SREQ sys_version0x2109 SREQ sys_osal_nv_write0x2108 SREQ sys_osal_nv_read0x210A SREQ sys_osal_start_timer0x210B SREQ sys_osal_stop_timer0x4181 AREQ sys_osal_timer_expired0x210C SREQ sys_random0x210D SREQ sys_ADC_read0x210E SREQ sys_GPIO0x4140 AREQ sys_test_RF0x2141 SREQ sys_test_loopback

Cuadro 3.3: Comandos de la interfaz SYS

Simple API [14].

Esta es una versión reducida de la interfaz API [15] que proporciona Texas Instrument para Z-Stack.

La interfaz Z-Stack API está pensada para dispositivos en los que la pila de protocolos está cargada

en el procesador (sección 3.1.1). Entre otras, Z-Stack API está compuesta por una serie de primitivas

con las que manejar tanto la capa de red como la subcapa APS. Como hemos dicho, CC2480 abarca

las capas física, MAC y de red. Por lo tanto no es necesario disponer de todas las primitivas de las

que está compuesta Z-Stack API. La solución es esta versión reducida conocida como simple API.

Los comandos de esta interfaz simplicada nos permitirán cambiar la conguración del dispositivo,

formar una red, realizar vínculos entre puntos de acceso y transferir la información. En la tabla 3.4

podemos ver todos los comandos que pertenecen a esta interfaz.

ZASA utiliza todos los comandos que ofrece Simple API.


Comando Tipo Nombre0x4609 AREQ zb_systemreset0x2604 SREQ zb_read_conguration0x2605 SREQ zb_write_conguration0x260A SREQ zb_app_register_req0x2600 SREQ zb_start_req0x4680 AREQ zb_start_conf0x2608 SREQ zb_permit_joining_req0x2601 SREQ zb_bind_device0x4681 AREQ zb_bind_conf0x2602 SREQ zb_allow_bind0x4682 AREQ zb_allow_bind_conf0x2603 SREQ zb_send_data_req0x4683 AREQ zb_send_data_conf0x4687 AREQ zb_receive_data_ind0x2606 SREQ zb_get_device_info0x2607 SREQ zb_nd_device_req0x4685 AREQ zb_nd_device_conf

Cuadro 3.4: Comandos de la interfaz Simple API

Interfaz AF.

Nos proporciona una interfaz con el Marco de aplicación (sección 2.6.2). Básicamente lo que podemos

hacer con las primitivas que nos proporciona esta interfaz es registar la aplicación en el CC2480 y,

al igual que con la interfaz Simple API, enviar y recibir datos hacia otros dispositivos de la red. En

la tabla 3.5 podemos ver todos los comandos que pertenecen a esta interfaz.

La aplicación de ejemplo ZASA emplea los cuatro comandos AF.

Comando Tipo Nombre

0x2400 SREQ af_register0x2401 SREQ af_data_req0x4480 AREQ af_data_conf0x4481 AREQ af_incoming_msg

Cuadro 3.5: Comandos de la interfaz AF

Interfaz ZDO.

Es una interfaz con el Objeto de dispositivo ZigBee (sección 2.6.2). Es necesaria para manejar la

funcionalidad del coordinador, routers y dispositivos nales. Esto incluye la creación, descubrimiento

y asociación a una red ZigBee y la vinculación de puntos de acceso. En la tabla 3.6 podemos ver

todos los comandos que pertenecen a esta interfaz.

ZASA sólo hace uso de los comandos zdo_match_desc_req y zdo_match_desc_rsp.


Comando Tipo Nombre

0x2500 SREQ zdo_nwk_addr_req0x4580 AREQ zdo_nwk_addr_rsp0x2501 SREQ zdo_ieee_addr_req0x4581 AREQ zdo_ieee_addr_rsp0x2502 SREQ zdo_node_desc_req0x4582 AREQ zdo_node_des_rsp0x2504 SREQ zdo_simple_desc_req0x4584 AREQ zdo_simple_desc_rsp0x2505 SREQ zdo_active_ep_req0x4585 AREQ zdo_active_ep_rsp0x2506 SREQ zdo_match_desc_req0x4586 AREQ zdo_match_desc_rsp0x45C2 AREQ zdo_match_desc_resp_sent0x2508 SREQ zdo_user_desc_req0x4588 AREQ zdo_user_desc_rsp0x250B SREQ zdo_user_desc_set0x4589 AREQ zdo_user_desc_conf0x250A SREQ zdo_end_device_annce0x45C1 AREQ zdo_end_device_annce_ind0x2520 SREQ zdo_end_device_bind_req0x45A0 AREQ zdo_end_device_bind_rsp0x2521 SREQ zdo_bind_req0x45A1 AREQ zdo_bind_rsp0x2522 SREQ zdo_unbind_req0x45A2 AREQ zdo_unbind_rsp0x2531 SREQ zdo_mgmt_LQI_req0x45B1 AREQ zdo_mgmt_LQI_rsp0x2534 SREQ zdo_mgmt_leave_req0x45B4 AREQ zdo_mgmt_leave_rsp0x2536 SREQ zdo_mgmt_permit_join_req0x45B6 AREQ zdo_mgmt_permit_join_rsp0x45C0 AREQ zdo_state_change_ind

Cuadro 3.6: Comandos de la interfaz ZDO

Parámetros de conguración

El integrado CC2480 tiene varios parámetros que pueden ser modicados por el microprocesador. Estos

parámetros son almacenados en una memoria ash interna de 128 kbytes. Este tipo de memoria es no

volátil (NV) por lo que estos parámetros permanecen en ella aun cuando el dispositivo no está alimentado.

Para leer o escribir dichos parámetros de conguración usamos los comandos zb_read_conguration y

zb_write_conguration de la interfaz Simple API.

Estos parámetros de conguración se dividen en dos grupos: los especícos de un dispositivo y los

especícos de la red. Para un correcto funcionamiento, los parámetros especícos de la red deben ser

compartidos por todos los dispositivos que pertenezcan a una determinada red ZigBee. Los especícos


de un dispositivo pueden variar de un dispositivo a otro. En [12] podemos encontrar una descripción

pormenorizada de cada uno de estos parámetros, tamaño en bytes, valor por defecto, etc. Aquí simplemente

los nombraremos y daremos una breve descripción de cada uno (ver tablas 3.7 y 3.8).

Algunos de dichos parámetros hacen referencia a los mensajes de tipo POLL (sondeo). Es importante

hacer incapié en la diferencia entre un comando POLL que, como hemos visto en las secciones anteriores,

es un tipo de comando entre CC2480 y microprocesador, y un mensaje POLL entre dos dispositivos de

la red ZigBee. Los mensajes POLL entre dispositivos de la red ZigBee son necesarios en las redes no

balizadas. En estas redes, cuando un dispositivo nal debe enviar un paquete a su dispositivo padre no

hay ningún problema puesto que éste, bien sea un router o un coordinador, siempre tendrá el sistema radio

encendido. El problema surge cuando el ujo de información es en sentido inverso. Como hemos dicho,

los dispositivos nales entran en modo de bajo consumo cuando no necesitan enviar información. Por lo

tanto el dispositivo padre nunca sabrá con certeza si un dispositivo nal conectado a él estará activo. La

solución a este problema es el envío de un mensaje POLL del dispositivo nal hacia el padre. Este mensaje

sirve para preguntar al padre si hay información a la espera de ser transmitida en el sentido padre-hijo.

Resumiendo, cuando un dispositivo nal tenga información para su dispositivo padre simplemente la

enviará. Cuando un dispositivo padre tenga información para un dispositivo nal conectado a él, deberá

esperar que dicho dispositivo nal le envíe un mensaje POLL y en ese momento enviar el paquete de

información.

Parámetro Descripción

ZCD_NV_STARTUP_OPTION Controla opciones de inicio.ZCD_NV_LOGICAL_TYPE Coordinador (0), router (1) o dispositivo nal (2)ZCD_NV_POLL_RATE Si el dispositivo es un dispositivo nal se despertará

con la frecuencia indicada por este parámetro (enms) para comprobar si su padre tiene información

para él.ZCD_NV_QUEUED_POLL_RATE Si el dispositivo nal realiza un sondeo a su padre y

éste tiene información para él, se vuelve a sondearuna vez más con un intervalo menor. Este

parámetro, expresado en ms, indica dicho intervalo.ZCD_NV_RESPONSE_POLL_RATE Si el dipositivo nal envía un paquete de datos al

padre puede comprobar si hay una respuestapasado un intervalo de tiempo. Este parámetro,

expresado en ms, indica dicho intervalo.ZCD_NV_POLL_FAILURE_RETRIES Máximo número de intentos de reenvío de

información a un dispositivo padre.ZCD_NV_INDIRECT_MSG_TIMEOUT Tiempo máximo en ms durante el cual un padre

almacenará datos para enviar a un dispositivo hijo.ZCD_NV_APS_FRAME_RETRIES Número de veces que se reintentará el envío de un

paquete si el ack a nivel de aplicación falla.ZCD_NV_APS_ACK_WAIT_DURATION Tiempo en ms que esperará un dispositivo con ack

a nivel de aplicación activado a dicha conrmación.ZCD_NV_BINDING_TIME Tiempo máximo en ms que un dispositivo esperará

la respuesta a un intento de vinculación (binding).ZCD_NV_USERDESC Parámetro a denir por el desarrollador.

Cuadro 3.7: Parámetros especícos de un dispositivo


Parámetro Descripción

ZCD_NV_PANID Identicador de la red PAN. Valor menor a 0x3FFF.Para indicar cualquier red se usa 0xFFFF.

ZCD_NV_CHANLIST Listado de canales en los que el dispositivo puedefuncionar.

ZCD_NV_PRECFGKEY 128 bits para la clave de seguridad.ZCD_NV_PRECFGKEYS_ENABLE Si este parámetro es TRUE se considera que todos

los dispositivos de la red conocen la clave deseguridad. Si es FALSE el coordinador debe

distribuirla.ZCD_NV_SECURITY_MODE Indica si usamos o no seguridad.ZCD_NV_BCAST_RETRIES Máximo número de intentos de envío de un paquete

broadcast sin recibir ack.ZCD_NV_PASSIVE_ACK_TIMEOUT Cantidad de tiempo (en unidades de 100 ms) que un

dispositivo espera antes de retransmitir un paquete.ZCD_NV_BCAST_DELIVERY_TIME Tiempo máximo (en unidades de 100 ms) que

puede tardar un paquete broadcast en propagarsepor toda la red.

ZCD_NV_ROUTE_EXPIRY_TIME Tiempo máximo (en segundos) que una ruta puedeestar sin tráco antes de marcarla como inutilizable.

Cuadro 3.8: Parámetros especícos de la red

Consumo

Como ya hemos mencionado, el CC2480 trabaja en modo no balizado. En este modo, los dispositivos

nales pueden activar el modo de bajo consumo cuando no están enviando información. Por el contrario,

tanto el coordinador como los routers deben estar siempre despiertos. Por despiertos se entiende que

deben tener el sistema radio encendido (a la escucha en este caso) y con el procesador CC2480 activo.

Para el caso de tratarse de un dispositivo nal, el CC2480 entra en modo de bajo consumo automáti-

camente.

En la tabla 3.9, obtenida de la hoja de características del CC2480 [13], podemos ver el consumo de

corriente para los principales modos de funcionamiento, incluyendo los modos de bajo consumo (LPM o

Low Power Modes en inglés).

Modo Consumo Características

CPU activa 12,3 mA Oscilador de cristal de 32 MHz activoCPU activa y recibiendo 26,7 mA Potencia de entrada -50 dBm

CPU activa y transmitiendo 26,9 mA Potencia de salida 0 dBmLPM2 0,5 µA Osc. RC de 16 MHz y Osc. de cristal de 32 MHz inactivos

Osc. de cristal de 32,768 kHz activoLPM3 0,3 µA Todos los osciladores inactivos

Cuadro 3.9: Consumo de corriente en el CC2480


Según el documento de noticación de errata [16] de Texas Instruments, el CC2480 puede no entrar en

el modo de bajo consumo en momentos en los que sí debería hacerlo. Este fallo del procesador CC2480,

que será analizado en profundidad en el capítulo 4, aumenta considerablemente el consumo.

Características del Transceptor

El sistema radio está completamente integrado en el CC2480. El transceptor, que trabaja en la banda

de los 2,4 GHz, está basado en el diseño del CC2420.

Como podemos ver en la hoja de características el integrado CC2480 transmite con una potencia

igual a 0 dBm (1 mW), la cual supera el mínimo de -3 dBm especicado en el estándar 802.15.4 [10].

La sensibilidad, de -50 dBm, también mejora el mínimo de -20 dBm especicado en dicho documento. El

tiempo de conmutación entre los estados de recepción y transmisión o viceversa es de 192 µs. Dicho valorcumple con lo especicado en el estándar y visto en la expresión 2.2 de la sección 2.3.

Para una descripción pormenorizada del esquema del transceptor y de sus propiedades se recomienda

acudir a la hoja de características [13].

Conrmación de recibo Ack

Para los mensajes que no sean broadcast (dirección corta destino distinta de 0xFFFF) hay dos tipos

de conrmación de recibo: ack a nivel de capa MAC o ack a nivel de aplicación. El ack de capa MAC

está siempre activo en el CC2480. Esto quiere decir que el bit que indica si se requiere ack dentro de la

cabecera MAC (sección 2.4.5) siempre vale 1. El ack a nivel de aplicación, o punto a punto, lo gestiona

la subcapa APS y es opcional. Su uso conlleva un aumento en el consumo de corriente. Esta repercusión

sobre el consumo será analizada en el capítulo 4.

Asignación de direcciones

El CC2480 utiliza el mecanismo distribuido de asignación de dirección corta descrito en la sección

2.5.2. De acuerdo con el documento [17] el coordinador o los routers pueden tener un máximo de 20

dispositivos hijo (Cm = 20). De ellos, un máximo de 6 pueden ser otros routers (Rm = 6) y un máximo

de 14, dispositivos nales. La profundidad máxima de la red o distancia máxima entre un dispositivo y

el coordinador es 5 (Lm = 5)1. En estas condiciones, y aplicando la expresión 2.3, tenemos los siguientes

valores de Cskip(d):

Profundidad en la red, d Cskip(d)0 5.1811 8612 1413 214 1

5 (= Lm) 0

Cuadro 3.10: Cskip(d) en CC2480

1Según este documento de Texas Instruments Lm = 6. No obstante, tras comprobar en el laboratorio las direccionesasignadas y el número máximo permitido de saltos desde un hijo hasta el coordinador, se ha deducido que dicho documentopresenta un error y que Lm = 5.


En la gura 3.11 podemos ver, como ejemplo, cuáles son las direcciones asignadas dentro de una red

con seis nodos. Como vimos en la sección 2.5.2 cada router toma la primera dirección dentro del subgrupo

de direcciones (de tamaño Cskip(d)) que se le ha asignado. Para asignar una dirección a un dispositivo

nal se utiliza la expresión 2.4 de la misma sección. Para el hijo directamente conectado al coordinador

(Direcpadre = 0) tendríamos:

Direc1 = 0 + 5181 · 6 + 1 = 31087 (0x796F ) (3.1)

Para el dispositivo nal conectado al router (Direcpadre = 1):

Direc1 = 1 + 861 · 6 + 1 = 5168 (0x1430) (3.2)

Figura 3.11: Ejemplo de asignación de direcciones en una red de 6 nodos formada con el CC2480

Seguridad

El integrado CC2480 tiene un bloque de cifrado AES-128 que realiza las tareas de seguridad especi-

cadas en el estándar ZigBee y explicadas en la sección 2.7.

El uso o no de seguridad se indica al procesador CC2480 a través de uno de sus parámetros de

conguración: ZCD_NV_SECURITY_MODE. Es lógico que se trate de un parámetro especíco de la

red, y no especíco de un dispositivo, puesto que debe tomar el mismo valor para todos los dispositivos

que forman la red ZigBee. Si este parámetro es TRUE la red aplicará el mecanismo de seguridad. Por

defecto, ZCD_NV_SECURITY_MODE toma el valor FALSE por lo que no se aplica el mecanismo de

seguridad.

Si activamos el uso de seguridad en nuestra red debemos tener en cuenta que existen dos métodos

de distribución de la clave. El primero asume que todos los dispositivos tienen precongurada la misma

clave de seguridad. Esta clave común debe ser indicada al CC2480 a través del microprocesador. En

el segundo método únicamente el coordinador de red tiene precongurada esta clave de seguridad. Así,

deberá transmitirla a cada uno de los dispositivos conectados a la red para que éstos pueden aplicar

mecanismos de seguridad. En este segundo método hay un momento de vulnerabilidad justo cuando el

coordinador distribuye la clave. En ese momento, un dispositivo que no pertenezca a la red pero que


escuche el canal puede obtener dicha clave. Por lo tanto este segundo método de distribución de clave sólo

debe ser utilizado si el desarrollador considera que el riesgo de intromisión no es demasiado alto.

La elección de uno u otro método se indica a los distintos dispositivos a través de otro parámetro

especíco de la red, ZCD_NV_PRECFGKEYS_ENABLE. Cuando este parámetro es TRUE, valor por

defecto, se utilizará el primer método por lo que todos los dipositivos utilizarán la clave precongurada

indicada por el parámetro especíco de la red ZCD_NV_PRECFGKEY (16 bytes).

En el capítulo 4 estudiaremos el efecto sobre el consumo que tiene el uso de seguridad en la red.

3.1.3. MSP430

El kit eZ430-RF2480 hace uso de un microprocesador MSP430 como sistema de control del procesador

CC2480. Texas Instruments dispone de varios modelos dentro de la familia MSP430. La diferencia básica

entre ellos es la cantidad de memoria ash y RAM de que disponen. El modelo exacto de microprocesador

que usa este kit es MSP430F2274. Este modelo dispone de 32 Kbytes + 256 bytes de memoria ash y 1

Kbyte de memoria RAM.

El MSP430 es un microprocesador RISC (Reduced Instruction Set Computer) de 16 bits. Los proce-

sadores RISC se basan en un número reducido de instrucciones que, para este caso, es de 27. Que el

procesador sea de 16 bits implica que todos los registros y buses internos de comunicaciones estén forma-

dos por 16 bits.

En esta sección sólo daremos un repaso general a las características del MSP430. Para obtener informa-

ción de manera mas detallada se recomienda acudir a la guía de usuario [19] y a la hoja de características

[20].

Arquitectura y funcionamiento básico

La gura 3.12 muestra la arquitectura interna del MSP430. La CPU contiene 16 registros. El fun-

cionamiento básico es el siguiente: a una frecuencia dada, por ejemplo 1 MHz, se copia una instrucción

desde la memoria ash hasta un registro determinado y a continuación se ejecuta. Un ejemplo simple sería

sumar dos registros y guardar el resultado en un tercero. El código necesario para hacer que el micro-

procesador lleve a cabo estas tareas se escribe en ensamblador. No obstante, para agilizar y simplicar el

diseño de aplicaciones se suelen usar compiladores que pasan nuestro código de C o C++ a ensamblador

de forma que el programador no tenga que involucrarse en procesos de muy bajo nivel. Este es el sistema

que utilizamos en nuestro caso. Más concretamente usamos un entorno de desarrollo conocido como IAR

Embedded Workbench especialmente diseñado para el trabajo con el microprocesador MSP430 [18]. Este

entorno de desarrollo será expuesto en la sección 3.3.4 del presente capítulo. Una vez compilado nuestro

código en C o C++ y, tras pasar de ensamblador a código binario, se carga el resultado en la memoria

ash de nuestro microprocesador. De esta forma, al encenderlo la CPU ejecuta la primera instrucción que

encuentra en dicha memoria. Para el caso particular de nuestro proyecto la aplicación que cargamos en el

MSP430 se llama ZASA, como ya hemos dicho, y será explicada en la siguiente sección.


Figura 3.12: Arquitectura interna del MSP430. Fuente: [19]

En cualquier aplicación es muy común necesitar esperar un tiempo determinado antes de realizar una

cierta tarea. Para ello usamos las diferentes señales de reloj del MSP430. Este microprocesador posee una

señal de reloj interna conocida como DCO (digitally-controlled oscillator). Existen diferentes registros

dentro del microprocesador que generan interrupciones con frecuencias que son divisores de la frecuencia

de la señal DCO. Así, podemos obtener señales de reloj de 1, 8, 12 y 16 MHz dependiendo de a qué registro

accedamos.

Cuando queremos comunicarnos con un elemento exterior al microprocesador, como es el caso un

botón, un sensor de luz o el propio CC2480, conectamos dicho dispositivo a uno de los pines de entra-

da/salida de que dispone el MSP430. El MSP430 debe ser programado de forma que un cambio en el

valor digital de dicho pin genere una interrupción y podamos actuar en consecuencia. Cuando generamos

una interrupción el microprocesador detiene la tarea que esté realizando en ese momento y ejecuta un

tipo de función denominada ISR (Interrupt Service Routine), que realiza una tarea especíca relacionada

con dicha interrupción. Una vez ejecutada la función ISR el microcontrolador puede seguir realizando sus

anteriores tareas.

El MSP430 tiene 40 pines (gura 3.13) de los cuales 4 realizan funciones de alimentación del dispositivo,

2 son usados para testeo, 2 para conectar un reloj de cristal externo (no es el caso de eZ430-RF2480) y

32 pines para conexiones digitales con otros dispositivos. Estos 32 pines de entrada salida se agrupan en

cuatro puertos de 8 pines cada uno. La nomenclatura es Px.y donde x indica el puerto e y indica la

posición del pin dentro de ese puerto. Para poder trabajar con estos pines se usan los siguientes registros:

PxDIR.y dene la dirección del puerto: salida si PxDIR.y vale 1 y entrada si vale 0.

Ejemplo: P1DIR = 0b111100002 hace que los pines P1.0 a P1.3 sean de entrada y los pines P1.4 a

P1.7 sean de salida.

2Igual que la expresión 0xz indica que z está representado en hexadecimal, 0bz indica que z está expresado en binario


PxOUT.y da un valor al pin Px.y si éste es de salida.

PxIN.y lee el valor del pin Px.y si éste es de entrada.

PxIE.y habilita las interrupciones en el puerto Px.y.

Por último decir que el MSP430 también tiene incorporado un conversor analógico-digital (ADC). Como

veremos más adelante, la aplicación ZASA hará uso de este conversor para digitalizar los valores del voltaje

de alimentación y del sensor interno del MSP430.

Figura 3.13: Distribución de pines en MSP430. Fuente: [20]

Consumo

La familia MSP430 está orientada a conseguir un bajo consumo. Es por ello que resulta idónea para el

control de transceptores y procesadores ZigBee/802.15.4. Siempre que el microprocesador está esperando

una interrupción es de vital importancia apagar los relojes que no estemos usando si queremos disminuir

el consumo. Para ello se denen cuatro modos de bajo consumo (LPM) que se diferencian en el número

de relojes de que prescinde cada uno. Podemos ver dichos modos de bajo consumo en la tabla 3.11. El

consumo de corriente del microprocesador es proporcional tanto a la frecuencia de trabajo como a la

tensión de alimentación. Así, para los valores representados en la tabla, se ha supuesto una tensión de

alimentación de 3 V y una frecuencia de trabajo de 8 MHz en el modo activo, que son los valores con los

que trabajaremos en nuestro proyecto. Para unos valores de consumo más detallados se recomienda acudir

a la hoja de características [20]. MCLK (Main Clock) es el reloj principal usado por la CPU, SMCLK

(Submain Clock) es un reloj secundario y ACLK (Auxiliary Clock) es un reloj auxiliar. Podemos ver su

distribución en la arquitectura interna anteriormente mostrada (gura 3.12).


En la práctica sólo dejando activo el reloj auxiliar ACLK, que despierta el integrado MSP430 después

de un determinado intervalo de tiempo, es suciente. Esto se consigue usando el modo LPM3.

Modo Consumo Características

Activo 2,8 mA CPU activadaTodos los relojes activos

LPM0 90 µA CPU desactivadaACLK y SMCLK activos

MCLK inactivoLPM1 90µA LPM0

+generador de continua de DCO inactivo si DCO no

se usa durante el modo activoLPM2 25µA CPU desactivada

MCLK y SMCLK inactivosgenerador de continua de DCO activo

ACLK activoLPM3 1µA CPU desactivada

MCLK y SMCLK inactivosgenerador de continua de DCO inactivo

ACLK activoLPM4 0,1µA CPU desactivada

MCLK, SMCLK y ACLK inactivosgenerador de continua de DCO inactivo

Oscilador de cristal inactivo

Cuadro 3.11: Modos de bajo consumo en el microprocesador MSP430

3.1.4. Esquemático de conexión entre CC2480 y MSP430

En la gura 3.14 mostramos el esquemático de conexión entre CC2480 y MSP430. Las principales

conexiones entre ellos son:

Comunicación SPI. Se realiza conectando los pines P3.0, P3.1, P3.2 y P3.3 del MSP430 a los pines

SS, SI, SO y C del CC2480 respectivamente.

Control de activación. Se conectan los pines P2.6 y P3.6 a SRDY y MRDY respectivamente.

Conguración. Los pines P4.0 y P4.1 controlan la conguración del CC2480 mediante los pines

CFG0 y CFG1.

Aparte de las conexiones entre ambos dispositivos el MSP430 se conecta a dos diodos LED mediante los

pines P1.0 y P1.1, a un botón mediante el pin P1.2 y a un sensor de luz a través de los pines P2.0 y P2.1.

Además, también permite la conexión a 5 de sus pines GPIO (P2.2, P2.3, P2.4, P4.4 y P4.5). Por último,

los pines P3.5 (RX) y P3.4 (TX) están controlados por el conector USB y es gracias a ellos, y usando una

conexión UART, que podemos cargar nuestra aplicación en el microprocesador.

Por otra parte, como ya se ha mencionado, el CC2480 se conecta a dos osciladores de cristal de 32

MHz y 32,768 kHz (siendo el segundo de estos opcional) y a una antena tipo chip.


Figura 3.14: Esquemático de conexión entre CC2480 y MSP430. Fuente: [21]


3.1.5. Aplicación de ejemplo ZASA

ZASA, o ZigBee Accelerator Sample Application por sus siglas en inglés, es la aplicación que viene

cargada por defecto en el microcontrolador MSP430. Su objetivo es demostrar de una manera simple cómo

funciona una red basada en tecnología ZigBee/802.15.4.

Básicamente lo que hace esta aplicación es centralizar y monitorizar la lectura de unos sensores de

temperatura y voltaje. ZASA nos proporciona dos puntos de acceso a nivel de aplicación: sumidero y

fuente. La función de sumidero sólo la puede realizar el coordinador. Su tarea será recibir las lecturas

de temperatura y voltaje que las fuentes le proporcionan. La función de fuente la realizan los routers y

los dispositivos nales. Por defecto, cada 10 segundos la fuente envía los datos al sumidero. Si la fuente,

bien sea un router o un dispositivo nal, está directamente conectada al coordinador el envío únicamente

debe efectuar un salto. Si por el contrario la fuente está conectada a un router, éste tendrá que recibir los

datos y encaminarlos hacia el coordinador por la ruta correspondiente.

Como hemos dicho, el procesador CC2480 está preprogramado para realizar las tareas de las capas

inferiores del protocolo ZigBee/802.15.4 por lo que no tenemos acceso a él. Por contra, podemos modicar

la aplicación cargada en el MSP430 y situada en lo alto de la pila de protocolos (ZASA en este caso).

El mecanismo para modicar dicha aplicación, como hemos mencionado anteriormente, es a través del

entorno de desarrollo IAR Embedded Workbench. En los apartados siguientes comenzaremos explicando

el funcionamiento de ZASA.

Respecto a los periféricos, ZASA hace uso del pulsador conectado al MSP430. Como veremos en el

siguiente punto, lo utiliza como mecanismo de conguración del dispositivo. También hace uso de los dos

diodos LED, uno verde y otro rojo, de que se dispone. Mediante ellos sabremos si el dispositivo ha sido

congurado como un dispositivo nal, router o coordinador y cuándo se ha transmitido o recibido un

paquete de datos.

Funcionamiento

El kit de desarrollo eZ430-RF2480 proporciona tres dispositivos FFD por lo que, potencialmente,

todos pueden ser congurados como coordinador, router o dispositivo nal. Por supuesto, al programar

una aplicación ZigBee podemos denir de antemano de qué tipo será nuestro dispositivo. Sin embargo

ZASA nos da la oportunidad de elegir si un dispositivo será coordinador, router o dispositivo nal en

pleno proceso de ejecución. Esto se consigue gracias al uso del pulsador que incorpora la tableta. Cuando

encendemos un dipositivo éste queda a la espera. El usuario puede reconocer este estado porque ambos

LED, tanto el rojo como el verde, parpadean una vez por segundo. En el momento que el usuario presiona

una vez el botón se inicia una ventana de espera que dura dos segundos. Si se vuelve a pulsar una segunda

vez el botón dentro de ese margen de tiempo, ZASA interpretará que el dispositivo debe comportarse

como un dispositivo nal. Si dentro de esos dos segundos no volvemos a presionar el botón, el dispositivo

se congurará como router e intentará conectarse a un coordinador. Si no encuentra un coordinador, el

propio dispositivo funcionará como coordinador e inicializará la red. Cuando un dispositivo funciona como

coordinador tendrá siempre encendido el diodo LED rojo, cuando funciona como router tendrá siempre

encendido el verde y cuando lo hace como dispositivo nal hará parpadear el LED verde una vez por

segundo.

Como hemos explicado en la sección 2.5.2 un coordinador o router puede permitir o no que otros


dispositivos se asocien a él. La manera que ZASA proporciona para modicar esta opción es utilizando

de nuevo el botón. Cuando un dispositivo se congura como coordinador o como router tiene activado el

permiso de asociación por defecto. Si pulsamos el botón de nuevo desactivaremos dicho permiso por lo

que un dispositivo que intente conectarse a él será rechazado. Si pulsamos el botón otra vez se volverá a

activar el permiso de asociación. Los diodos LED nos darán información de cómo está congurado dicho

permiso. Cuando el permiso de asociación está desactivado, el LED (rojo para el coordinador y verde para

el router como hemos dicho) pasará de estar continuamente encendido a parpadear una vez por segundo.

Una vez que un dispositivo que funcione como fuente se ha conectado correctamente al coordinador,

bien directamente o a través de un padre, comienza a enviar datos de forma periódica cada 10 segundos. Los

datos que envía son la temperatura del sensor interno del MSP430 y el valor de la tensión de alimentación.

El tamaño es de un byte para la temperatura y otro para el voltaje. Cuando un dispositivo nal o un

router envían un paquete de datos hacia el coordinador, el LED verde del dispositivo parpadea una vez.

Cuando el coordinador recibe el paquete de datos parpadea una vez su LED rojo.

En la tabla 3.12 podemos ver un resumen del estado de los diodos LED para los distintos casos de

funcionamiento.

Tipo de dispositivo LED rojo LED verde

Sin congurar Parpadeando ParpadeandoCoordinador(sumidero)

Permiso de conexión: EncendidoSin permiso de conexión: Parpadeando

Datos recibidos: Un parpadeo

Router(fuente)

Envío de datos: Un parpadeo Permiso de conexión: EncendidoSin permiso de conexión: Parpadeando

Dispositivo nal(fuente)

Envío de datos: Un parpadeo Parpadeando

Cuadro 3.12: Estado de los diodos LED de acuerdo con el programa ZASA

Un dispositivo nal pasará la mayor parte de su tiempo en modo de bajo consumo, despertando

únicamente para enviar los datos hacia el cordinador cada 10 segundos. El coordinador y los routers

deben estar siempre activos y con el sistema radio encendido puesto que en cualquier momento puede

llegarles un paquete de datos o una solicitud de asociación.

En la gura 3.15 podemos ver la máquina de estados de ZASA.

Como ya sabemos, el kit eZ430-RF2480 viene incorporado con un adaptador USB. Dicho adaptador

proporciona una conexión UART entre el MSP430 y un PC. Idealmente el coordinador debe ir conectado

a este adaptador lo que permitirá la monitorización en un PC los datos enviados por todos los dispositivos

que funcionen como fuente. El programa utilizado para dicha monitorización que nos proporciona Texas

Instuments se llama Sensor Monitor. Aparte de la posibilidad de monitorizar, también se puede aprovechar

esta conexión UART para comunicarnos de forma más general con el microprocesador en tiempo de

ejecución. De hecho, cuando un dispositivo está conectado al adaptador USB, ZASA envía por el puerto

serie UART una copia de todos los comandos intercambiados entre los integrados MSP430 y CC2480.

Además, también podremos hacer que el MSP430 envíe un comando determinado hacia el CC2480. La

aplicación que se emplea para este propósito se llama Z-Tool. Tanto Sensor Monitor como Z-Tool serán

expuestos en la sección 3.3 de este capítulo. Por otra parte, en el apéndice que se incluye al nal de este

texto explicaremos cómo podemos utilizar Visual Basic .NET para desarrollar una aplicación propia que


nos permita realizar tareas similares a las de Sensor Monitor y Z-Tool.

Figura 3.15: Máquina de estados de la aplicación de ejempolo ZASA. Fuente: [22]

Ejemplo del funcionamiento de una red ZigBee con dispositivos ejecutando ZASA

A continuación veremos un ejemplo de inicialización de red, asociación de dispositivos y funcionamiento

general de una red cuyos dispositivos están ejecutando ZASA. Puesto que el kit eZ430-RF2480 sólo nos

proporciona tres unidades, nos limitaremos a mostrar una red con tres nodos. La manera de añadir más

dispositivos puede inferirse a partir de este ejemplo.

Conectamos la tableta con el adaptador USB a nuestro PC. Ambos diodos comenzarán a parpadear

indicando que el dispositivo debe ser congurado. Pulsamos una vez el botón y esperamos primero

a que se agote la ventana de dos segundos y luego a que el CC2480 realice un escaneo activo a la

búsqueda de una red existente. Puesto que no encuentra ninguna dentro de un tiempo determinado


por la constante APP_JOIN_TIME (que será expuesta más adelante), ZASA congura el dispositi-

vo como coordinador de red y el LED rojo se enciende. Nuestra red está ahora formada únicamente

por un coordinador. Este dispositivo tiene siempre el sistema radio a la escucha, preparado para

recibir peticiones de asociación y datos. Su consumo es mayor que el de un dispositivo nal pero, al

estar alimentado a través del puerto USB, esto no supone un gran problema.

Figura 3.16: Red formada por un coordinador.

Conectamos otra tableta a la batería y pulsamos el botón una única vez. Pasada la ventana de dos

segundos el CC2480 realiza un escaneo activo y encuentra que ya existe una red. El dispositivo toma

entonces la funcionalidad de router, enciende el LED verde y se intenta conectar al coordinador.

Este proceso se realiza exitosamente puesto que el coordinador acepta peticiones de asociación.

Es necesario destacar que aquí también se realiza la vinculación entre los puntos de acceso de

ambos dispositivos (binding). Para poder vincularse ambos dispositivos deben estar ejecutando la

misma aplicación (ZASA en este caso). Puesto que todo es correcto, se realiza la vinculación entre

el sumidero (coordinador) y fuente (router). A partir de ahora, el router enviará una medida de

temperatura y otra de voltaje hacia el coordinador cada 10 segundos. Cada vez que el router envíe

un paquete de datos parpaderá su LED rojo. Cuando el coordinador los reciba parpadeará su LED

verde. Aquí es necesario señalar que el router está siempre en modo activo y con el sistema de

radio conectado por si otro dispositivo intenta asociarse a él. En esta conguración la batería no

aguantaría mucho tiempo por lo que se recomienda alimentar el dispositivo de forma cableada.

Figura 3.17: Coordinador y router

Conectamos ahora la tercera tableta a la batería y pulsamos el botón dos veces. El dispositivo se

congura como dispositivo nal e intenta conectarse a la red. Si el coordinador tiene activado el

permiso de conexión el dispositivo nal se conectará a él (gura 3.18a). Si antes de conectar el

dispositivo nal pulsamos una vez el botón del coordinador, este desactivará el permiso de conexión

y el dispositivo nal no tendrá más remedio que conectarse al router (gura 3.18b). En cualquiera

de los dos casos el dispositivo nal envirá los datos cada 10 segundos hacia el sumidero, haciendo

parpadear el LED rojo. Puesto que el dispositivo nal apaga el sistema radio cuando no está enviando

datos, su consumo es muy bajo y la batería presentará una larga vida útil.


(a) Dispositivo nal conectado al coordinador (b) Dispositivo nal conec-tado al router

Figura 3.18: Red compuesta por 3 dispositivos

Estructuración del código

ZASA está escrito en lenguaje C y pensado para ser compilado y cargado en el MSP430 usando el

entorno de desarrollo IAR Embedded Workbench. La versión gratuita de dicho entorno de desarrollo tiene

un límite de 4 Kbytes para el código a compilar y cargar en el microprocesador. Así, ZASA ha sido

diseñado para no sobrepasar dicho límite y ocupa poco menos de 4 Kbytes.

El código de ZASA se divide en los siguientes módulos:

APP (Aplicación). Implementa la funcionalidad a más alto nivel. Se encarga de hacer que el

dispositivo funcione según lo descrito en el punto anterior.

HAL (Hardware Abstraction Layer). Esta parte del código se encarga de controlar al MSP430.

Gestiona las conexiones SPI y UART, los relojes software, modos de funcionamiento (activo, LPM)

y dispositivos externos conectados al MSP430 como el pulsador o los LED.

MT (Monitor Test). Realiza las funciones necesarias para poder comunicar el MSP430 con el

PC a través de una conexión UART. MT envía una copia de todos los comandos intercambiados

entre MSP430 y CC2480 a través de la conexión UART. Así, podremos ver en nuestro PC todos

los comandos que se intercambian dichos dispositivos. Además de esto el módulo MT también nos

permite ordenar al MSP430, desde el PC, el envío de un comando determinado al CC2480. Los

programas Sensor Monitor y Z-Tool se comunican con el microprocesador gracias a esta parte del

código.

SAPI (Simple API). Gestiona la interfaz Simple API vista en la sección 3.1.2 de este mismo

capítulo.

ZACCEL (Z-Accel). Controla el intercambio de comandos entre MSP430 y CC2480 actuando

como maestro y esclavo, respectivamente, a través de la conexión SPI.


3.2. Herramientas de instrumentación

3.2.1. Osciloscopio Tektronix TDS 3012B

Como dijimos en la sección 1.3 del capítulo 1 el objetivo de nuestro proyecto es medir el consumo en

nodos ZigBee/802.15.4. Para realizar dicho estudio mediremos la tensión que cae sobre una resistencia

conectada entre la fuente de alimentación y el dispositivo ZigBee. Aplicando la ley de Ohm deduciremos

la corriente que circula por dicha resistencia y así el consumo en cada momento del nodo ZigBee/802.15.4

en cuestión. Así, teniendo en cuenta que los estados cambian muy rápidamente, el uso de un osciloscopio

digital resulta de gran interés.

Figura 3.19: Tektronix TDS 3012B. Fuente: [23]

A continuación resumimos las principales particularidades del modelo utilizado, el Tektronix TDS

3012B, obtenidas a partir de su hoja de características [23]:

Ancho de banda de 100 MHz.

Frecuencia de muestreo máxima: 1 Gmuestras/s.

2 canales.

Resolución vertical: 9 bits.

Sensibilidad vertical: 10 mV/div a 10 V/div.

Precisión vertical: ±2 %.

Rango de la base de tiempos: 4 ns/div a 10 s/div.

Impedancia de entrada a elegir entre 1 MΩ y 50 Ω.

Conexión Ethernet.

Pantalla a color.

3.2: HERRAMIENTAS DE INSTRUMENTACIÓN 65

3.2.2. Fuente de alimentación Tektronix PS2520G

El kit eZ430-RF2480 proporciona dos conectores para la alimentación mediante baterías. No obstante,

es conveniente reemplazarlos por una fuente de alimentación indendiente para asegurar la estabilidad y

continuidad de dicha alimentación. En la realización de nuestro proyecto hemos usado la fuente Tektronix

PS2520G.

Figura 3.20: Tektronix PS2520G

Sus principales propiedades, obtenidas a partir de su hoja de características [24], son:

Dos salidas con un rango de 0 a 26 V y 0 a 1,5 A.

Una salida con un rango de 0 a 6 V y 0 a 3 A.

Precisión de voltaje: 0,05% + 25 mV.

Precisión de corriente: 0,2% + 10 mA.

Conexión GPIB (General Purpose Interface Bus).

Pantalla LED digital de 4 dígitos.

3.2.3. Multímetro HP34401A

A la hora de calcular la tensión que cae sobre la resistencia que colocamos entre la fuente de tensión

y el nodo ZigBee/802.15.4 alternaremos entre dos casos generales: cuando el nodo está en modo bajo

consumo y cuando está transmitiendo/recibiendo información (activo). Cuando el nodo está en modo de

bajo consumo el valor de la tensión que cae sobre la resistencia toma un valor muy pequeño, como veremos

en la sección 4.3.3 del capítulo 4. Así, necesitamos un instrumento con más precisión que el osciloscopio

para realizar dicha medida de tensión. La solución es utilizar un multímetro, en su funcionalidad como

voltímetro, que para nuestro caso será el HP34401A de Hewlett-Packard.

Figura 3.21: HP34401A


En la hoja de características [25] podemos ver todas las propiedades de este multímetro. Aquí nos

centraremos en aquellas que lo caracterizan en su funcionamiento como voltímetro en DC. Características:

Mínimo rango de tensión en DC: 100.0000 mV.

Precisión para dicho rango: 0.0030 mV.

Resistencia de entrada: 10 MΩ .

Conexión GPIB.

3.2.4. CC2520 Evaluation Module Kit y SmartRF05 Evaluation Board

A la hora de realizar el estudio sobre el consumo de potencia usando el kit eZ430-RF2480 es de gran

utilidad analizar los paquetes de datos en el momento de ser transmitidos. Para ello utilizaremos un

Snier. Este Snier se compone por una parte hardware (la aquí expuesta) y una parte software. El

software nos lo proporciona gratuitamente Texas Instruments y será descrito en la seccion 3.3.

El hardware está compuesto por el modulo de evaluación CC2520 que está formado básicamente por

dos transceptores CC2520 ZigBee/802.15.4 de Texas Instruments y por las antenas correspondientes. Estos

dispositivos serán los que escuchen e interpreten en tiempo real los paquetes de datos que se intercambian

los distintos nodos de nuestro kit eZ430-RF2480.

Uno de los transceptores CC2520 estará conectado a la placa SmartRF05EB, que será la que nos

permitirá visualizar los datos al estar conectada por USB con el PC.

Para más información sobre el sistema CC2520EMK es recomendable acudir a la hoja de características

del transceptor CC2520 [26] y la guía de inicio rápido del kit CC2520EMK [27]. Respecto a la placa

SmartRF05Eb encontraremos más información en su guía de usuario [28].

(a) CC2520EMK. Fuente: [28] (b) SmartRF05EB. Fuente: [29]

Figura 3.22: CC2520EMK y SmartRF05EB

3.3: HERRAMIENTAS SOFTWARE 67

3.3. Herramientas software

3.3.1. Sensor Monitor

Sensor Monitor es una aplicación diseñada para trabajar conjuntamente con los nodos del kit eZ430-

RF2480 cuando estos ejecutan ZASA. Esta aplicación para PC nos permite monitorizar los datos recibidos

por el sumidero (coordinador) y procedentes de las fuentes (routers y dispositivos nales).

Es una aplicación gratuita que nos proporciona Texas Instruments como herramienta para la moni-

torización. En [29] vemos los pasos necesarios para instalarla así como una descripción en profundidad de

su funcionamiento.

Sensor Monitor es una aplicación muy simple que puede resultar muy útil para familiarizarse con el

kit eZ430-RF2480. En la gura 3.23 podemos ver la ventana principal de Sensor Monitor. En este caso,

la red está formada por 6 nodos (hemos utilizado dos kits eZ430-RF2480). El coordinador se representa

en color rojo, los routers en azul y los dispositivos nales en dorado. Se ha congurado el dispositivo que

utiliza el adaptador USB como coordinador de red o sumidero. Este dispositivo será el que se comunique

con Sensor Monitor a través de la conexión UART entre MSP430 y PC. El módulo MT del código de

ZASA es el encargado de gestionar el intercambio de información entre el microprocesador y el PC. Vemos

que Sensor Monitor nos permite visulizar los datos que recibe el coordinador. Así, podemos ver cuál es

la temperatura y el voltaje que lee cada nodo, su dirección corta y la topología general de la red.

Figura 3.23: Monitorización de una red de 6 dispositivos ejecutando ZASA

3.3.2. Z-Tool

Como hemos explicado en la sección 3.1.2 de este capítulo, MSP430 y CC2480 se intercambian una

serie de comandos pertenecientes a cuatro tipos de interfaces (SYS, Simple API, AF y ZDO). Z-Tool hace

uso de la conexión UART entre MSP430 y PC para:


Visualizar por pantalla los comandos recibidos por el MSP430. Estos comandos siempre serán tipo

AREQ (el CC2480 inicia la comunicación con el MSP430) o tipo SRSP (CC2480 responde a una

petición por parte del MSP430).

Hacer que el MSP430 envíe un comando determinado hacia el CC2480. Podremos, por ejemplo,

enviar el comando zb_systemreset de la interfaz Simple API para hacer que el integrado CC2480 se

resetee.

En genearal, Z-Tool está pensado para trabajar con cualquier dispositivo que implemente la pila de

protocolos Z-Stack de Texas Instruments. En la imagen 3.24 vemos la aplicación Z-Tool en ejecución. Sus

distintas partes son:

Monitorización. En la subventana derecha se muestran todos los comandos, AREQ o SRSP, que

recibe el MSP430 por parte del CC2480 (<RX>, en azul). Cuando el usuario hace que el MSP430

envíe un comando al CC2480 éste también aparece por pantalla (<TX>, en rojo).

Selección de comando. Cuando queremos enviar un comando determinado al CC2480 debemos

previamente seleccionarlo en la subventana de selección de comando. En dicha ventana podemos ver

todos los comandos agrupados según el tipo de interfaz: SYS, Simple API, AF o ZDO.

Conguración de comando. Algunos comandos deben ser congurados antes de ser enviados.

Por ejemplo, imaginemos que queremos leer un parámetro de conguración del CC2480. Para ello el

MSP430 debe enviar el comando zb_read_conguration al CC2480. Antes de enviar dicho comando

debemos congurarlo para indicar qué parámetro queremos leer (tipo lógico, PAN ID, y demás

parámetros vistos en la sección 3.1.2).

Figura 3.24: Z-Tool

3.3: HERRAMIENTAS SOFTWARE 69

Es importante destacar que, mientras Sensor Monitor está pensado para trabajar únicamente con el

coordinador (conectado a travás del adaptador USB), Z-Tool puede comunicarse con cualquier tipo de

dispositivo. Así, aunque no sea recomendable mantener al coordinador alimentado por baterías, podemos

usar esta conguración y conectar un dispositivo nal al PC a través del adaptador USB.

3.3.3. Packet Snier

Como hemos mencionado en la sección anterior, el CC2520 Evaluation Module Kit y el SmartRF05

Evaluation board necesitan una aplicación en nuestro PC para poder visualizar los paquetes interceptados

en el aire. Esta aplicación es Packet Snier, un programa gratuito suministrado por Texas Instruments.

Gracias a esta aplicación podemos monitorizar cualquier paquete interceptado por el transceptor

CC2520. Dentro de una trama, Packet Snier diferencia la parte física, MAC, de red y de aplicación.

Aparte de esto también numera todas las tramas, indica el tiempo en ms entre una trama y otra, y, por

último, señala la intensidad en dBm con que se recibe la señal.

En conjunto, CC2520EMK, SmartRF05EB y Packet Snier representan una potente herramienta

para el estudio de nuestra red. Como veremos más adelante, su uso nos aclara muchos aspectos del

funcionamiento de nuestra red ZigBee/802.15.4.

En la gura 3.25 vemos la pantalla principal de Packet Snier. Remitimos al lector al manual de

usuario de esta aplicación [30] para conocer más en detalle su conguración y funcionamiento.

Figura 3.25: Packet Snier

3.3.4. IAR Embedded Workbench

IAR Embedded Workbench V4.11B es un entorno de desarrollo especialmente pensado para la familia

de microprocesadores MSP430 de Texas Instruments. Con esta herramienta compilamos el código (escrito

en lenguaje C) y posteriormente lo cargamos en el microprocesador. Texas Instruments nos ofrece el código


fuente de ZASA de manera gratuita por lo que, usando este entorno de desarrollo, podemos modicarlo

y cargarlo en el microprocesador cuantas veces veamos oportuno.

Como ya hemos dicho con anterioridad, IAR ofrece una versión gratuita de este producto que limita el

código compilado a 4 Kbytes. ZASA fue creado pensando en cumplir con dicha limitación. Es por ello que

su tamaño es prácticamente de 4 Kbytes. El Departamento de Tecnología Electrónica de la Universidad

de Málaga dispone de la versión completa de IAR Embedded Workbench por lo que, afortunadamente,

no tenemos ningún límite más allá del propio espacio de memoria que ofrece el microprocesador MSP430.

Como cualquier otro entorno de desarrollo, IAR Embedded Workbench está compuesto principalmente

por la ventana donde escribir el código fuente, el espacio de trabajo y la ventana de depuración (gura

3.26).

Para una descripción detallada del funcionamiento de este entorno de desarrollo se recomienda acudir

al tutorial ocial de IAR [31].

Figura 3.26: IAR Embedded Workbench

3.3.5. MATLAB

A la hora de realizar el estudio sobre el consumo de potencia es necesario analizar las capturas de

pantalla del osciloscopio. Utilizamos MATLAB para leer estos datos de forma automática. En este texto

asumiremos que el lector conoce de antemano esta aplicación por lo que prescindiremos de dar una

descripción más detallada de ella (que puede encontrar, en cualquier caso, en [32]).

El osciloscopio Tektronix TDS 3012B guarda los archivos de captura de pantalla en formato de hoja

de cálculo (.csv). Usando MATLAB, hemos creado un script que nos permite cargar y representar estos

datos de forma sistemática. Además, tambien podemos calcular y representar la media de dicho consumo

de corriente para un intervalo dado. En la gura 3.27 vemos un ejemplo de una captura de pantalla y

la media asociada. El eje de las abcisas representa el tiempo en ms y el de las ordenadas la corriente en

3.4: CIRCUITO DE MEDIDA EMPLEADO 71

mA. Utilizamos la expresión 3.3 para calcular la corriente media consumida por un dispositivo, donde I[n]representa la enésima muestra de corriente y N el número total de muestras.

Figura 3.27: Representación de una medida de corriente con MATLAB

IMedia =∑N

n=1 I[n]N

(3.3)

3.4. Circuito de medida empleado

En esta sección se explicará el esquema del circuito que se ha usado para medir la corriente consumida

por los nodos de nuestro kit eZ430-RF2480. En primer lugar hablaremos del esquema general de medida. A

continuación justicaremos la inclusión de un amplicador y de un ltro paso bajo a dicha conguración.

3.4.1. Esquema general

El esquema general para medir el consumo de corriente en un nodo se representa en la gura 3.28.

Como vemos, utilizaremos una resistencia entre la alimentación y el nodo sobre la cual se realiza la medida.

Figura 3.28: Esquema general


Para calcular el consumo de potencia (gura 3.29) utilizaremos la siguiente expresión, por todos cono-

cida:

P = I ·V (3.4)

V representa la tensión en bornas del nodo, I la corriente entrante. La relación entre V y Valim (tensión

proporcionada por la fuente, tal y como se observa en la gura 3.29) sigue la siguiente expresión:

Valim = V +R · I (3.5)

Si hacemos R · I V entonces:

V w Valim (3.6)

La alimentación de la tableta es de 3 V. Por otra parte, y como veremos en el siguiente capítulo, I

toma valores máximos del orden de los 40 mA luego:

R · 40 mA 3 V (3.7)

R 75 Ω (3.8)

Llegamos pues a la conclusión de que un buen valor para la resistencia colocada entre la fuente de

alimentación y el nodo ZigBee/802.15.4 sería:

R = 1 Ω (3.9)

Así, se podría considerar que la de tensión que cae en nuestro nodo es despreciable frente a la que nos

proporciona la fuente de alimentación. Tomando en cuenta entonces las expresiones 3.4 y 3.6 llegamos a

la siguiente relación lineal entre la potencia consumida por nuestro nodo y la corriente que circula por la

resistencia R:

P = I ·Valim (3.10)

En conclusión podemos decir que midiendo únicamente la corriente que circula por nuestra resistencia

tenemos una medida del consumo de potencia del dispositivo. Para calcular la corriente I medimos el

voltaje que cae en R utilizando el osciloscopio y aplicamos la ley de Ohm.

Figura 3.29: Esquema para la medida del consumo de potencia


3.4.2. Amplicador

Del apartado anterior se puede deducir que si Imax ' 40 mA y R = 1 Ω entonces el voltaje máximo

que el osciloscopio debería ser capaz de leer es:

Vmax = Imax ·R = 40 mV (3.11)

Este valor no es de un orden muy superior a la sensibilidad máxima del osciloscopio, que es de 1 mV/div.

Por este motivo y para mejorar además la relacion señal a ruido, es deseable el uso de un amplicador

entre nuestro circuito y el osciloscopio.

Se ha elegido para ello el amplicador INA195 de Texas Instruments [33]. Este amplicador está

especícamente pensado para ser conectado a una resistencia de un valor pequeño, dando a la salida un

voltaje 100 veces mayor al que cae en ella (A = 100 VV ). En la gura 3.30 vemos el esquema de dicho

amplicador.

Figura 3.30: Amplicador INA195 de Texas Instruments. Fuente: [33]

3.4.3. Filtro paso bajo

Para la implementación del ltro utilizaremos la conguración de primer orden que nos propone Texas

Instruments en [33] (gura 3.31). El ltro se coloca antes del amplicador, en lugar de a su salida,

para aprovechar la baja impedancia de salida del INA195 (1.5 Ω según la hoja de características). Esta

conguración está formada por dos resistencias idénticas RFILT , de forma que la entrada a las patillas

del INA195 sea simétrica, y por un condensador CFILT .


Figura 3.31: INA 195 conectado a un ltro paso bajo. Fuente: [33]

Figura 3.32: Filtro Paso Bajo de primer orden

La expresión 3.12 calcula la frecuencia de corte en función de los valores de RFILT y CFILT .

fc =1

2π · (2RFILT ) ·CFILT(3.12)

A continuación calcularemos los valores de resistencia y condensador de nuestro ltro.

Resistencia RFILT .

Por un lado interesa que R RFILT de forma que la mayor parte de la corriente siga circulando por

R. Por otro lado, según [33], esta conguración presenta el problema de que la amplicación real es menor

a la teórica (A = 100VV ), como vemos en la expresión 3.13. Debido a este hecho interesa elegir valores no

demasiado altos para RFILT .

Areal = 100 ·5 kΩ

5 kΩ +RFILT(3.13)


Llegado a un compromiso entre ambos criterios, hemos elegido para RFILT el valor de 47 Ω, lo que

cumple con R RFILT y nos da una amplicación real de:

Areal = 100 ·5 kΩ

5 kΩ + 47 Ω= 99,068

V

V(3.14)

De este modo el error relativo introducido por nuestro ltro, expresión 3.15, resulta ser inferior al 1%.

Errorrelativo = 1− Areal

A= 1− 99,068

100' 0,93 % < 1 % (3.15)

Condensador CFILT

Una vez conocida RFILT será el valor de CFILT el que nos dena la frecuencia de corte de nuestro

ltro.

Para hallar dicha frecuencia de corte buscaremos una cota superior y una inferior. La superior viene im-

puesta por el osciloscopio, como veremos a continuación. La inferior la calcularemos de forma aproximada

mediante medidas en el laboratorio.

El osciloscopio, lógicamente, tiene una limitación a la hora de tomar muestras de la señal a medir. Por

otra parte, el teorema de Nyquist nos dice que una señal periódica puede ser perfectamente reconstruida

siempre que se utilice una frecuencia de muestreo superior al doble de su ancho de banda. Por lo tanto,

la frecuencia de muestreo de nuestro osciloscopio nos determinará la frecuencia máxima (fc) de la señal

de entrada que éste será capaz de distinguir.

Frecuencia de muestreo > 2 · fc (3.16)

Para nuestras medidas hemos congurado el osciloscopio de forma que tenga una resolución horizontal

total de 10.000 muestras. Esto da un valor de 1.000 muestras/div. Conociendo este valor de muestras dentro

de cada división y la resolución horizontal expresada en segundos/div, podemos calcular la frecuencia de

muestreo de nuestro osciloscopio.

Frecuencia de muestreo =1000 (muestras/division)

Resolucion horizontal (segundos/division)(3.17)

En la tabla 3.13 vemos como ejemplo la frecuencia de muestreo de nuestro osciloscopio para algunos

valores de resolución horizontal. Como dijimos en la sección 3.2.1 la frecuencia de muestreo máxima del

osciloscopio Tektronix TDS 3012B es de 1 Gmuestras/s por lo que, a partir de una resolución de 1 µs/div,

dicha frecuencia se mantiene constante.

Resolución horizontal Frecuencia de muestreo

10 s/div 100 muestras/s1 s/div 1 Kmuestras/s

200 ms/div 5 Kmuestras/s20 ms/div 50 Kmuestras/s1 µs/div 1 Gmuestras/s10 ns/div 1 Gmuestras/s

Cuadro 3.13: Velocidad de muestreo del osciloscopio


Como veremos en el siguiente capítulo, la mínima resolución horizontal que vamos a necesitar es de

20 ms/div. Esto nos da una frecuencia de muestreo máxima de 50 Kmuestras/s. Por lo tanto, y aplicando

3.16, la máxima frecuencia que el osciloscopio será capaz de distinguir será:

fc <Frecuencia de muestreo

2=

50 · 103

2= 25 kHz (3.18)

Por lo tanto, podemos ltrar la señal con un ltro de fc < 25 kHz sin miedo a que el osciloscopio

pierda parte de la información.

Respecto a la cota inferior, no podemos hacer fc muy pequeña puesto que estaríamos ignorando

componentes importantes de la señal. Así, debemos llegar a un compromiso entre un valor menor de

25 kHz, que nos permita cumplir con el criterio de Nyquist, pero no demasiado pequeño, de forma que

no deformemos la señal original. Después de repetidas pruebas en el laboratorio hemos elegido el valor

comercial de 220 nF para nuestro condensador.

Así pues, para los valores de RFILT = 47 Ω y CFILT = 220 nF la frecuencia de corte del ltro es:

fc =1

2π · (2 · 47) · 220 · 10−9= 7,7 kHz (3.19)

La gura 3.33 muestra el esquema nal de nuestro sistema para la medida del consumo de potencia

en nodos ZigBee/802.15.4.

Figura 3.33: Esquema completo del circuito medida

Capítulo 4

Estudio del consumo

En el presente capítulo realizaremos el estudio sobre el consumo de potencia en nodos ZigBee/802.15.4.

Para ello nos basaremos en los dispositivos del kit eZ430-RF2480. En cada sección nos centraremos en la

tarea que realiza el dispositivo: encendido, inicialización y conexión a la red, envío/recepción de datos,

etc. Además, dentro de cada sección distinguiremos entre el consumo que presentan el coordinador, los

routers y los dispositivos nales.

Es importante resaltar que el presente estudio sólo pretende ser un indicador del consumo en redes

ZigBee/802.15.4. Nosotros nos hemos centrado en los dispositivos del kit eZ430-RF2480 con la aplicación

de ejemplo ZASA cargada en el microcontrolador pero, como hemos dicho, existen un gran número de

otros dispositivos en el mercado (así como aplicaciones), tanto de Texas Instruments como de otros muchos

fabricantes. Así pues, repetimos que los datos obtenidos en este estudio sólo deben ser tenidos en cuenta

como un indicador general del reducido consumo que dispositivos basados en esta tecnología pueden

alcanzar.

4.1. Encendido

Como hemos dicho en la sección 3.1.5 los dispositivos del kit eZ430-RF2480, una vez conectada la

alimentación, quedan a la espera de ser congurados por parte del usuario. Éste les indicará, mediante el

uso del pulsador conectado al MSP430, si deben congurarse como router/coordinador o como dispositivo

nal. En esta sección estudiaremos el consumo de corriente que presentan los nodos desde que conectamos

la alimentación hasta que el usuario presiona el botón por primera vez.

Consumo

En la gura 4.1 vemos representada la corriente consumida por el dispositivo justo en el momento de

la conexión de la fuente de alimentación.

La corriente media, obtenida gracias a la implementación de la expresión 3.3 en MATLAB, es:

IMedia = 3,9 mA (4.1)

77

78 CAPÍTULO 4: ESTUDIO DEL CONSUMO

Figura 4.1: Consumo de corriente al conectar la alimentación

Una vez pasado este intervalo de tiempo de 1,3 segundos aproximadamente, el dispositivo queda en

espera (gura 4.2) hasta que el usuario presiona el pulsador . En este estado el procesador CC2480 debe

estar activo puesto que, en cualquier momento, el microprocesador MSP430 puede enviarle los comandos

necesarios para su conguración. La corriente media en este estado es:

IMedia = 15,5 mA (4.2)

Figura 4.2: Consumo de corriente del dispositivo en espera

Llegados a este punto sería muy interesante calcular la vida útil de nuestro dispositivo para el caso

de que continuara indenidamente en este estado. Para el cálculo de la vida útil utilizaremos la expresión

4.3. La capacidad de batería, expresada en unidades de mAh varía de un fabricante a otro. Para el caso

de baterías tipo AAA los valores típicos oscilan entre 900 y 1500 mAh. En este texto usaremos como valor

de referencia 1200 mAh.

4.1: ENCENDIDO 79

V ida util =Capacidad de la baterıa

IMedia=

1200 mAh15,5 mA

= 77,4 horas ' 3 dıas y 5 horas (4.3)

Descripción detallada del consumo

En la gura 4.3 podemos ver de nuevo las grácas anteriores, indicándose los distintos estados por los

que pasa el dispositivo.

(a) Consumo al conectar la alimentación (b) Consumo del dispositivo en espera

Figura 4.3: Consumo al conectar la alimentación y en espera

1. El microprocesador MSP430 puede funcionar a 1, 8, 12 ó 16 MHz. En el caso particular de ZASA la

frecuencia de trabajo es de 8 MHz. Así pues, nada más conectar el microprocesador a la alimentación

el reloj del sistema debe sincronizarse con esta frecuencia. El chip MSP430 no puede realizar dicha

sincronización a no ser que la tensión de alimentación sea de, al menos, de 2,2 V. Este punto es un

margen de tiempo, de aproximadamente 1 segundo, que el MSP430 da a la tensión de alimentación

para asentarse. La corriente consumida es de 1,8 mA aproximadamente.

2. Calibración del reloj del sistema. En este intervalo, la corriente toma el valor de 4,6 mA.

3. Cuando el reloj se ha calibrado el MSP430 despierta al procesador CC2480. Nos mantenemos in-

denidamente en este estado en el que el procesador CC2480 se encuentra activo. El valor medio de

la corriente en este punto es de 15,4 mA

4. Los picos de corriente que vemos son debidos al parpadeo de los diodos LED que, como hemos

explicado, ocurre una vez por segundo para indicar que el dispositivo se encuentra en espera de ser

congurado. Los picos de corriente tienen una valor de 3 mA.


4.2. Inicio

4.2.1. Coordinador

En esta sección analizaremos el consumo desde el momento que el usuario presiona el pulsador hasta

que el dispositivo se ha congurado correctamente. Como hemos explicado en la sección 3.1.5, una vez que

el dispositivo está en espera, si el usuario presiona una vez el pulsador, se inicia una ventana de 2 segundos

de duración. Si no volvemos a presionar el pulsador, ZASA congurará el dispositivo como coordinador

o como router. Si el dispositivo encuentra una red a la que poder conectarse se congurará como router

y se conectará a ella. Si por el contrario no encuentra ninguna red, se comportará como coordinador y

procederá a la inicialización de la red. En este apartado estudiaremos el consumo durante el inicio de un

dispositivo que se comporta como coordinador.

Cuando un dispositivo intenta asociarse a la red, la capa MAC gestiona el nivel físico de forma que

se realice un escaneo para una lista de canales determinada, en busca de algún dispositivo padre. Puesto

que el procesador CC2480 trabaja en modo no balizado, el escaneo debe ser activo. Esto signica que

el dispositivo que realiza un escaneo de canal enviará una baliza y, justo a continuación, permanecerá a

la escucha en busca de una baliza de respuesta por parte del coordinador1. Realizará este proceso varias

veces para cada uno de los canales seleccionados. Si en alguno de los canales se encuentra un padre que

responda a dicha solicitud, nuestro dispositivo se conectará a él.

En la gura 4.4 vemos el consumo de corriente de un dispositivo desde que presionamos el pulsador

hasta que forma la red.

Figura 4.4: Inicio del coordinador

Para obtener un resultado más general, no tendremos en cuenta el consumo de corriente durante la

ventana de 2 segundos ya que esta es una característica particular de ZASA. Así pues, el consumo de

corriente desde que transcurre dicha ventana hasta que el dispositivo forma la red es:

IMedia = 28,6 mA (4.4)

1Recordamos aquí que en el modo balizado, el escaneo es pasivo (sin envío de balizas) puesto que se sobreentiende queya existe un coordinador que envía balizas de forma periódica.

4.2: INICIO 81

El dispositivo anterior sólo busca la red en un canal. Recordemos que los 26 canales ZigBee se dis-

tribuyen de la siguiente manera: 1 canal para la frecuencia 868 MHz (canal 0), 10 canales para 915 MHz

(canales de 1 a 10) y 16 canales para 2,4 GHz (canales de 11 a 26). Por defecto, ZASA intenta conectarse

únicamente al canal número 16. Si pasado un tiempo denido por la variable APP_JOIN_TIME no

ha encontrado red alguna, formará la suya propia. Dentro del módulo APP de ZASA podemos acceder

al chero sample_app.cfg en el que es posible seleccionar la lista de canales en los cuales el dispositivo

buscará la red. Conforme aumentamos el número de canales de esta lista, es necesario incrementar el

tiempo de espera APP_JOIN_TIME, que por defecto vale 6 segundos (variable denida en el chero

sample_app.c del módulo APP). De forma práctica hemos comprobado que si elegimos escanear los 16

canales de la banda de 2,4 GHz esta variable debe ser, de al menos, 30 segundos para que dé tiempo a

enviar y recibir una posible respuesta.

Utilizando IAR Embedded Workbench hemos modicado el número de canales sobre los que ZASA

realiza el escaneo activo. En la gura 4.5, mostramos el consumo de un dispositivo que realiza el escaneo

activo sobre más de un canal2 (tras lo cual, al no encontrar una red, se congura como coordinador).

(a) Escaneo activo sobre 2 canales (b) Escaneo activo sobre 3 canales

Figura 4.5: Inicio del coordinador con búsqueda en varios canales

Como hemos dicho, conforme aumentamos el número de canales sobre los que se realiza el escaneo activo

debemos aumentar el tiempo máximo de asociación (APP_JOIN_TIME). En la tabla 4.1 mostramos el

consumo para el caso de escaneo de 1 y 16 canales, teniendo en cuenta que también podemos medir el

consumo como el producto de corriente media por tiempo (mA·ms).

Número de canalesescaneados

APP_JOIN_TIME(s)

IMedia(mA) Tiempo totalempleado (s)

mA·ms

1 6 28,6 8 228,8 · 103

16 30 34,3 46 1578 · 103

Cuadro 4.1: Consumo en función del número de canales escaneados durante el inicio de red

2En la imagen no se muestra la ventana de espera de 2 segundos



A continuación analizaremos el consumo de un modo más detallado. Para ello nos basaremos en el

caso de que el dispositivo realice el escaneo activo sobre dos canales (gura 4.6).

Figura 4.6: Escaneo activo sobre dos canales

1. El dispositivo se encuentra en espera tal y como se ha visto en la sección anterior. Los diodos LED

parpadean una vez por segundo.

2. El usuario presiona el pulsador.

3. Ventana de espera de 2 segundos. En este caso el pulsador no se vuelve a presionar por lo que

el dispositivo se comportará como router/coordinador dependiendo de si encuentra o no una red

ZigBee.

4. El MSP430 envía los comandos necesarios al CC2480 para que éste realice el escaneo activo.

5. El CC2480 comienza el escaneo activo para el primer canal, enviando una baliza y permaneciendo

a continuación a la escucha. En la gura 4.7 se muestran ampliados los pasos 5, 6 y 7 así como el

paso 5 (que es idéntico al 7) en detalle3.

3Las caidas de corriente de la gura 4.7b no se aprecian en la gura 4.7a debido a la gran diferencia en la escala detiempos de ambas grácas.

4.2: INICIO 83

(a) Pasos 5, 6 y 7 (b) Desglose de los pasos 5 y 7

Figura 4.7: Visión en detalle del escaneo activo sobre dos canales

El paso número 5 está compuesto por:

a) En primer lugar el dispositivo escucha el canal según requiere el algoritmo CSMA-CA explicado

en la sección 2.4.3.

b) A continuación el dispositivo transmite la baliza, que puede ser visualizada utilizando Packet

Snier (gura 4.8). Como vemos, este es un mensaje tipo broadcast (0xFFFF) que no requiere

de conrmación ack a nivel MAC.

Figura 4.8: Baliza emitida por el nodo para determinar si ya existe un coordinador

c) Por último, el dispositivo vuelve a escuchar el canal a la busca de una baliza de respuesta.

6. Cambio al siguiente canal.

7. Paso idéntico al número 5. Se transmite una baliza, pero esta vez sobre el segundo canal. Tras realizar

el escaneo en todos los canales, el CC2480 espera un intervalo de tiempo de aproximadamente 100

ms antes de comenzar de nuevo.

8. Tras repetir los pasos 5, 6 y 7 tantas veces como es posible dentro de APP_JOIN_TIME, el

dispositivo entiende que no existe ninguna red ZigBee y se congura como coordinador de red. El

aumento de consumo de unos 3 mA se debe a que, cuando funcionamos como coordinador, el diodo

LED rojo permanece encendido, aumentando el consumo de corriente del dispositivo.


4.2.2. Router

El inicio de un router es similar al del coordinador. La principal diferencia es que ahora el dispositivo

recibirá respuesta por parte de la red antes de que acabe el tiempo APP_JOIN_TIME, por lo que enten-

derá que no debe congurarse como coordinador. En lugar de ello simplemente se asociará al coordinador

de red ya existente (o a un router si éste tiene el permiso de asociación desactivado) y comenzará su

funcionamiento normal, enviando datos cada cierto periodo de tiempo. En la gura 4.9 podemos observar

el consumo de corriente durante el inicio de un router para el caso de escaneo activo sobre dos canales.

No hemos considerado la ventana de espera de 2 segundos por ser una característica particular de ZASA.

Figura 4.9: Consumo durante el inicio de un router con escaneo sobre dos canales

De nuevo, la corriente media así como el tiempo empleado en el inicio del dispositivo dependerá

del número de canales que escaneemos y del valor del tiempo límite de espera para asociarse a la red

(APP_JOIN_TIME). En la tabla 4.2 vemos los valores de corriente para el caso de escaneo de 1 y 16

canales.


APP_JOIN_TIME(s)


mA·ms

1 6 26,6 2 53,2 · 103

16 30 33,8 27,5 929,5 · 103

Cuadro 4.2: Consumo en función del número de canales escaneados durante el inicio de un router


En la gura 4.10 vemos los puntos más importantes durante el inicio de un router que realiza un

escaneo sobre dos canales.

4.2: INICIO 85

Figura 4.10: Inicio de un router con escaneo sobre dos canales

1. Parpadeo de LED durante el modo de espera.

2. El usuario presiona el pulsador.

3. Ventana de espera de 2 segundos.


5. El CC2480 comienza a escanear el primer canal, enviando una baliza y permaneciendo a la escucha.

Suponiendo que este sea el canal sobre el cual funciona la red, recibiremos una baliza como respuesta,

que podemos visualizar utilizando Packet Snier (gura 4.11).

Figura 4.11: Baliza enviada por el router y respuesta del coordinador

El coordinador (dirección corta 0x0000) responde a la baliza del escaneo con otra baliza en la que

especica algunos parámetros de la red. Podemos ver en el campo de especicación de supertrama

que SO y BO valen 15 lo que, como explicamos en la sección 2.4.2, signica que la red funciona en

modo no balizado. También podemos ver que el coordinador tiene el permiso de asociación (campo

Assoc) activado.

6. Se cambia al siguiente canal.

7. El CC2480 escanea este canal enviando una baliza. Si suponemos que la red funciona en el primero

de los canales, dicha baliza no recibirá ninguna respuesta por parte del coordinador.

8. Tras repetir el escaneo activo sobre todos los canales el router da por localizado el canal sobre el

cual trabaja la red. Si se obtuviera respuesta en más de un canal, el CC2480 elegiría aquel con una


mejor calidad de enlace. El siguiente paso es asociarse a un dispositivo padre y realizar la vinculación

(binding) a nivel de aplicación.

Figura 4.12: Desglose del paso 8 (vinculación al coordinador)

En la gura 4.12 vemos de forma ampliada el consumo de corriente durante los procesos de asociación

y vinculación. Utilizando el Packet Snier podemos monitorizar los paquetes intercambiados durante

el proceso de asociación (gura 4.13).

Figura 4.13: Asociación

El paquete número 7 (P.nbr. = 7) es una petición de asociación (Association request) por parte del

router que, como vemos, requiere de conrmación ack a nivel MAC. Este ack es el paquete 8. El

paquete 9 sirve para reclamar una respuesta por parte del coordinador. Cuando dicho coordinador

recibe la petición calcula una dirección corta para el router según el mecanismo distribuido de

asignación visto en la sección 2.5.2. Una vez calculada esta dirección, es comunicada al router

mediante el paquete 10 (conrmado a su vez por el paquete 11). De ahora en adelante ambos

dispositivos se comunicarán utilizando dichas direcciones cortas.

Una vez asociados, los dispositivos deben vincularse a nivel de aplicación. Esto sirve para comprobar

que ambos dispositivos funcionan con la misma aplicación (mismo perl de aplicación), y que sus

puntos de acceso son compatibles. Como explicamos en la sección 2.6.2 la subcapa ZDO (punto de

4.2: INICIO 87

acceso 0) es la encargada de realizar la vinculación y de inicializar la subcapa APS. En la gura 4.14

vemos los paquetes intercambiados en dicho proceso.

Como vemos, todos los puntos de acceso, tanto de origen como de destino, son 0x00 (ZDO). El

identicador de perl de aplicación es 0x0000, lo que quiere decir que todavía no hemos registrado

nuestra aplicación. ZASA tiene como identicador 0x0F10. En la carga útil de los paquetes 12 y 13

podemos ver como coordinador y router se comunican mutuamente el identicador de ZASA.

El proceso de vinculación también requiere que el padre comunique al hijo su dirección larga IEEE. El

paquete 18 (cluster ID 0x0001) sirve para preguntar al padre dicha dirección. El paquete 20 (cluster

ID 0x8001), que es la respuesta a dicha petición, adjunta la dirección IEEE en la carga útil. Como

podemos observar en el campo de control esta trama requiere de conrmación a nivel de aplicación.

El paquete 22 representa dicha conrmación. Como vemos, las tramas 20 a 23 representan un buen

ejemplo de cómo un paquete puede requerir solamente conrmación ack a nivel MAC (paquete 22)

o conrmación a nivel MAC y a nivel de aplicación (paquete 20).

Una vez realizada la vinculación, ambos dispositivos comenzarán a comunicarse según lo denido

por la aplicación ZASA. Utilizando para ello las direcciones de puntos de acceso e identicadores de

cluster denidos por dicha aplicación y que serán expuestos más adelante.

9. El dispositivo se ha congurado correctamente como router y comienza su funcionamiento regular.

Figura 4.14: Vinculación del router al coordinador


4.2.3. Dispositivo nal

La gura 4.15 muestra la corriente media consumida por un dispositivo nal durante la inicialización

para el caso de que realice el escaneo activo sobre un canal. En la tabla 4.3 vemos el consumo para el caso

de escaneo de 1 y 16 canales. En general, la corriente consumida durante el inicio del dispositivo nal es

menor que en el caso del coordinador de red o de un router.

Figura 4.15: Consumo durante el inicio de un dispositivo nal con escaneo sobre un canal


APP_JOIN_TIME(s)


mA·ms

1 6 17,2 2 34,4 · 103

16 30 29,6 27,5 814 · 103

Cuadro 4.3: Consumo máximo y mínimo durante el inicio de un dispositivo nal


En la gura 4.16 vemos los puntos más importantes durante el inicio de un dispositivo nal que realiza

el escaneo activo sobre dos canales.

1. Parpadeo de LED durante el modo de espera.

2. El usuario presiona dos veces el pulsador, indicando que el dispositivo debe congurarse como

dispositivo nal.

3. La ventana de espera de 2 segundos se agota.


4.2: INICIO 89

Figura 4.16: Inicio de un dispositivo nal con escaneo sobre dos canales

5. Se escanea el primer canal. Este apartado es idéntico al paso número 5 visto para el caso de un

router.

6. Se cambia al siguiente canal.

7. Escaneo del segundo canal. De nuevo, este apartado es igual al paso 7 para el caso de un router.

8. Tras repetir los pasos 5, 6 y 7 tres veces el dispositivo nal da por localizado el canal e inicia los

procesos de asociación y vinculación. Dichos mecanismos son prácticamente iguales al caso de un

router por lo que no entraremos de nuevo en detalle. En la gura 4.17 podemos ver en detalle el

consumo durante este paso.

Figura 4.17: Desglose del paso 8

9. El dispositivo se ha congurado correctamente como dispositivo nal y comienza su funcionamiento

regular.


4.3. Recepción y envío de datos

En esta sección analizaremos el consumo de corriente durante la recepción y el envío de datos, es decir,

durante el funcionamiento regular de los dispositivos. Como ya hemos expuesto en diversas ocasiones, el

consumo de los dispositivos nales será mucho menor que el del coordinador y los routers puesto que

estos deben tener siempre activado el sistema radio. Por contra, los dispositivos nales sólo saldrán del

modo de bajo consumo para enviar o recibir datos (en el caso particular de ZASA, sólo enviarlos) y, acto

seguido, volverán a él. Comenzaremos estudiando el consumo de corriente para el caso del coordinador

y los routers y, a continuación, nos centraremos en el de los dispositivos nales para distintos casos de

funcionamiento.

4.3.1. Coordinador

En la gura 4.18a se muestra el consumo de corriente en el coordinador. Con el programa ZASA el

coordinador actúa como sumidero de la información. Esto quiere decir que nunca enviará datos a sus

dispositivos hijo, exceptuando el caso de los paquetes ack a nivel MAC y de aplicación. Como vemos, el

consumo es alto debido a que el sistema radio siempre está conectado en modo de recepción. Como se ha

explicado, ZASA hace que el diodo LED rojo esté encendido cuando el dispositivo es el coordinador de red

y tiene el permiso de asociación activado. En la gura 4.18b se muestra el consumo una vez desactivado

dicho permiso de asociación (se ha presionado una vez el pulsador). Como vemos, el consumo de corriente

disminuye aproximadamente 3 mA, que es exactamente lo que consume el LED rojo. En dicha gura

también podemos observar los picos de corriente de periodicidad 1 segundo que son provocados por el

parpadeo del LED, indicando que el dispositivo tiene desactivado el permiso de asociación.

(a) Permiso de asociación activado (LED encendido) (b) Permiso de asociación desactivado (LED parpadeando)

Figura 4.18: Consumo de corriente durante el funcionamiento regular del coordinador de red

La tabla 4.4 muestra el consumo medio de corriente en ambos estados así como la vida media para una

batería de capacidad 1200 mAh. Para hallar la vida útil de una batería conocida la corriente media con-

4.3: RECEPCIÓN Y ENVÍO DE DATOS 91

sumida remitimos al lector a la expresión 4.3. Como vemos, utilizando una batería de estas características

la vida útil es muy baja, por lo que es muy recomendable alimentar al coordinador de red conectándolo

a la red de distribución.

Estado IMedia(mA) Vida útil de la batería

Permiso de asociación activado 38,45 '1 día y 7 horasPermiso de asociación desactivado 35,45 '1 día y 10 horas

Cuadro 4.4: Consumo medio de corriente en el coordinador de red


En esta descripción detallada del consumo de corriente se considerará que el coordinador ha recibido

dos paquetes de información por parte de un dispositivo hijo. Dichos paquetes requieren de conrmación

ack a nivel MAC, que es obligatorio, pero no a nivel de aplicación. Igualmente, en la gura 4.19 se muestra

dicho caso de funcionamiento.

Figura 4.19: Consumo de corriente del coordinador de red

Los eventos señalados en la gura son los que a continuación se describen:

1. El coordinador está a la escucha y con el permiso de asociación activado (LED rojo encendido).

2. Se recibe un paquete de datos. El pico de corriente hacia abajo se debe al cambio del sistema radio de

recepción a transmisión (para enviar el ack a nivel MAC) y de nuevo a recepción. El pico hacia arriba

se debe al parpadeo del LED verde que demuestra que el paquete ha sido recibido correctamente.

Este paso es idéntico al paso 5, que será desglosado a continuación.

3. El usuario presiona una vez el pulsador por lo que se desactiva el permiso de asociación del coordi-

nador y el LED rojo pasa de estar permanentemente encendido a parpadear una vez por segundo.

4. El LED rojo parpadea.


5. De nuevo, el coordinador recibe un paquete de información proveniente de una fuente de datos

(paso es idéntico al número 2). En la gura 4.20a vemos en detalle los pasos 4 y 54. Este último está

compuesto por:

a) El coordinador recibe el paquete de datos.

b) Se envía el ack a nivel MAC.

c) El coordinador vuelve a poner el sistema radio en modo de recepción.

d) Se enciende el LED verde (durante 20 ms) para indicar que se ha recibido correctamente el

paquete de información.

(a) Pasos 4 y 5 (b) Desglose del paso 5

Figura 4.20: Pasos 4 y 5 y desglose del paso 5

4.3.2. Router

El caso del consumo de un router cuando funciona de manera regular es análogo al del coordinador. No

obstante, para la placa de desarrollo que estamos utilizando, su consumo medio de corriente es levemente

inferior puesto que el LED verde consume menos que el rojo, aproximadamente 2 mA. En la tabla 4.5 se

muestra el consumo medio de corriente para los dos estados posibles, así como la vida útil para el caso de

utilizar baterías 1200 mAh de capacidad.

Estado IMedia(mA) Vida útil de la batería

Permiso de asociación activado 37,28 '1 día y 8 horasPermiso de asociación desactivado 35,26 '1 día y 10 horas

Cuadro 4.5: Consumo medio de corriente en el coordinador de red

Cuando un router recibe un paquete de datos el consumo sigue el mismo patrón que para el caso

del coordinador. Por otro lado, puesto que un router funciona como fuente a nivel de aplicación, también4El paso 4 mostrado en la gura 4.20a corresponde al segundo parpadeo del LED, y no al primero, como señala la gura

4.19


realiza envío de datos de forma periódica hacia su padre aunque, nuevamente, el impacto sobre el consumo

total debido al envío de paquetes no es signicativo. Por todo lo anterior, obviaremos la descripción

detallada del consumo para el caso de un router.


Introducción

Como hemos visto en los apartados anteriores, el consumo de corriente del coordinador y de los routers

es del orden de los 35 mA por lo que la vida útil de dos baterías AAA de capacidad 1200 mAh no llega

a los dos días de duración. Por este motivo, tal y como hemos dicho, es muy recomendable alimentar

tanto el coordinador como los diferentes routers de forma cableada. Como veremos en esta sección, el caso

del dispositivo nal cambia radicalmente puesto que pasa la mayor parte del tiempo en modo de bajo

consumo, despertando únicamente en el momento de enviar los datos.

En este apartado estudiaremos el consumo de corriente en un dispositivo nal que únicamente emplea

mensajes de ack a nivel MAC, y lo relacionaremos con diversos parámetros como el periodo de envío de

información, el tamaño del paquete de datos y si utilizamos o no seguridad en nuestra red.

Descripción general del consumo

En la gura 4.215 se muestra el consumo de corriente de un dispositivo nal con periodo de envío de

datos de 2 y 8 segundos (guras 4.21a y 4.21b respectivamente). Se denomina secuencia activa a cada uno

de dichos pulsos de corriente. Como se puede ver, un dispositivo nal pasa la mayor parte de su tiempo

en modo de bajo consumo.

(a) Periodo de envío igual a 2 s (b) Periodo de envío igual a 8 s

Figura 4.21: Consumo de corriente en un dispositivo nal durante el envío de datos

5El eje de tiempos tiene unidades de 5 s/div por lo que el ancho de pulso del parpadeo de los LED es comparativamentemuy pequeño. Esta es la razón por la cual la mayoría de los pulsos debidos al parpadeo de dichos diodos no se representanpor pantalla.


En el caso del coordinador y los routers la corriente media toma valores cercanos a 35 mA, como se

ha visto. Sin embargo, la corriente media durante el modo de bajo consumo en un dispositivo nal toma

valores menores de 1 µA, como se demostrará más adelante. Puesto que las medidas realizadas están

tomadas sobre una resistencia de 1 Ω, la tensión que caerá sobre ella será del orden de 1 µV. Como se

puede ver en la hoja de características del amplicador INA195 [33], la tensión de oset a la entrada toma

valores típicos de 0,5 mV. Llegamos pues a la conclusión de que el error introducido por el amplicador

tiene un orden de magnitud mucho mayor que el parámetro que se desea medir. En conclusión, para

el estudio del consumo de corriente en un dispositivo nal aplicaremos métodos más precisos que nos

permitirán calcular el valor medio de corriente con mayor exactitud.


La gura 4.22 muestra una visión ampliada de una secuencia activa (picos anteriormente mostrados

en la gura 4.21).

Figura 4.22: Consumo de corriente durante la transmisión de un paquete de datos

Los puntos señalados en la gura se corresponden con:

1. Este paso representa el consumo (de unos 3 mA) del parpadeo del LED verde que, como se ha

explicado, parpadea una vez por segundo para mostrar que el dispositivo está congurado como

dispositivo nal. Además del parpadeo del LED, este pico de corriente también es debido a la lectura

de temperatura que realiza el MSP430. Tras leer dicho valor de temperatura, el microprocesador

espera 20 ms para de digitalizarlo utilizando el conversor ADC.

2. Transcurrida dicha ventana de 20 ms, el MSP430 realiza la lectura de la tensión de alimentación.

De nuevo, se vuelve a esperar 20 ms antes de digitalizar dicho valor.

3. El MSP430 ha terminado de realizar las medidas por lo que despierta al CC2480 y le envía un

comando zb_send_data_req (comando tipo SREQ) para que éste envíe los datos al nodo destino.

Este pico de corriente también es debido al inicio del oscilador RC de 16 MHz interno del CC2480

y del oscilador de cristal externo de 32,768 kHz (vistos en la sección 3.1.2).


4. El CC2480 inicia el reloj de cristal externo de 32 MHz, que será utilizado como reloj principal.

5. El CC2480 se encuentra en estado activo, la corriente en este estado es de 13 mA, valor que coincide

con el que se muestra en su hoja de características [13].

6. El procesador CC2480 despierta al MSP430 y le envía la respuesta síncrona (SRSP) que el comando

zb_send_data_req requiere. Además, este pico de corriente también es debido a que el LED rojo

parpadea para indicar que el paquete de datos ha sido entregado al CC2480 para proceder a su

envío.

7. El CC2480 activa el sistema radio y lo pone en modo de escucha, conforme requiere el algoritmo

CSMA-CA. El ancho de este pulso es variable y depende de lo ocupado que esté el canal. El ancho

de pulso que se muestra en la gura es un valor típico. El consumo en este estado es de 32,5 mA,

valor levemente superior al que nos especica la hoja de características [13] (valor típico de 26,7

mA).

8. El procesador CC2480 cambia el sistema radio de recepción a transmisión. La duración de este

intervalo es de exactamente 192 µs según vemos en la gura y en la hoja de características [13],

valores que cumplen con el estándar [10].

9. El CC2480 se encuentra ahora en modo de transmisión, enviando los dos bytes de datos (uno de

temperatura y otro de medida de voltaje) a una velocidad de 250 kbps. Utilizando Packet Snier

podemos ver el paquete de datos conforme es transmitido (gura 4.23). En ella podemos observar que

el identicador del perl de aplicación es 0x0F10, lo que determina que se está usando ZASA. Los

puntos de acceso tienen por direcciones 0x01 (fuente) y 0x02 (sumidero). Por último, el identicador

de cluster es 0x0001, lo que signica que la fuente (dispositivo nal) está enviando información al

sumidero (coordinador). Por otro lado vemos como la carga útil (APS Payload) toma el valor 0x1C

y 0x1E, que son los bytes que representan la temperatura y la medida de voltaje de alimentación,

respectivamente.

Figura 4.23: Paquete de datos enviado por un dispositivo nal

Como veremos más adelante, este pulso se ensanchará si aumentamos el número de bytes que trans-

mitimos, como es lógico. El consumo en este paso es de 30,5 mA, de nuevo levemente por encima

del que nos indica la hoja de características del CC2480 (valor típico de 26,9 mA).

10. Se cambia de transmisión a recepción.

11. El procesador CC2480 permanece a la escucha para recibir la conrmación ack del nodo contiguo.

De nuevo, podemos visualizar dicho paquete (gura 4.24).


Figura 4.24: Conrmación ack a nivel MAC

De nuevo, el consumo de corriente en este intervalo es 32,5 mA.

12. El CC2480 despierta al MSP430 para enviarle un comando zb_send_data_conf (AREQ) para in-

dicar que el paquete de datos ha sido correctamente entregado al siguiente nodo.

13. Los dispositivos CC2480 y MSP430 entran en modo de bajo consumo hasta el siguiente envío de

datos.

Cálculo exacto de la corriente media consumida

El siguiente paso es obtener la corriente media consumida durante el funcionamiento de un dispositivo

nal. Como se ha dicho anteriormente, no podemos calcularla con el circuito de medida que se ha empleado

hasta ahora puesto que en el modo de bajo consumo, donde la corriente toma valores muy pequeños, el error

introducido por el amplicador es comparativamente alto. Así pues, se prescindirá de dicho elemento por

lo que mediremos la tensión directamente sobre la resistencia. Como complemento, se usará un multímetro

en lugar del osciloscopio ya que éste nos brinda una mayor precisión.

El osciloscopio se utilizará únicamente para calcular la corriente media consumida durante una secuen-

cia activa puesto que en ella los valores de corriente son del orden de 20 mA.

Una vez realizadas dichas medidas utilizaremos la siguiente expresión para el cálculo exacto de la

corriente media consumida:

IMedia =d

P· ISec + (1− d

P) · ISleep (4.5)

Donde:

d = Duración de la secuencia activa. Esto es, el tiempo que se tarda en enviar un paquete de datos y

conrmar su recepción.

P = Periodo de envío de datos.

ISec = Corriente media consumida durante la secuencia activa.

ISleep = Corriente media consumida durante el modo de bajo consumo.

En la gura 4.256 se muestra una secuencia activa. Como se puede ver, los valores de la corriente

media consumida y la duración de la secuencia activa son:

ISec = 17, 27 mA (4.6)

d = 17 ms (4.7)

6Para simplicar los cálculos se supone que la secuencia activa comienza en el paso 3 de los expuestos anteriormente


Figura 4.25: Consumo de corriente durante una secuencia activa

El siguiente paso es calcular la corriente del modo de bajo consumo (ISleep). Para ello cambiaremos

nuestra resistencia de 1 Ω por una de valor mayor. Este valor debe ser sucientemente grande para que la

tensión que caiga sobre ella sea medible por el multímetro, y sucientemente pequeño para que nuestro

dispositivo siga funcionando debidamente. Recordamos que según la expresión 3.5 la relación entre el

voltaje de alimentación y el que cae en las bornas de nuestro dispositivo es:

Valim = V +R · I (4.8)

Luego:

R =Valim − V

I(4.9)

V representa la tensión que cae en las bornas de nuestro dispositivo que, según la hoja de características

del MSP430 [20], no debe ser menor que 2,2 V:

V = Valim −R · IMax ≥ 2,2 V (4.10)

IMax representa el caso en el que nuestro dispositivo ZigBee consume la mayor corriente posible

(IMax w 40 mA en el caso del coordinador y de un router). Nuestro objetivo es hacer R lo más grande

posible sin que V baje de 2,2 V (Vmin), ya que en ese caso el dispositivo dejaría de funcionar. Aplicando

una tensión de alimentación (Valim) de 3,6 V y considerando el caso más desfavorable de consumo de

corriente (IMax) tenemos:

R ≤ Valim − Vmin

IMax=

3,6− 2,240 · 10−3

= 35 Ω (4.11)

Luego si utilizamos una resistencia de valor aproximado 35 Ω estaremos asegurando tanto la correcta

alimentación de nuestro dispositivo (V no bajará de 2,2 V) como un valor de tensión sucientemente alto

como para que nuestro multímetro lo lea correctamente. El valor que se ha usado es de 32 Ω, a partir delparalelo dos resistencias de 47 y 100 Ω.


Utilizando el multímetro obtenemos el siguiente valor para la tensión que cae sobre la resistencia en

el modo de bajo consumo:

VSobre R = Valim − V = 0,024 mV (4.12)

Esto nos da el siguiente valor para la corriente de bajo consumo:

ISleep =VSobre R

R=

0,024 mV32 Ω

= 750 nA (4.13)

Así pues, ya hemos encontrado el valor de todos los parámetros necesarios para caracterizar el consumo

en un dispositivo nal, a excepción de P , que será impuesto por nosotros. Como muestra, cuando P toma

el valor de 10 segundos (caso por defecto en ZASA) la corriente media consumida por un dispositivo nal

es 30,1 µA. En la gura 4.26a se puede ver la relación entre corriente media consumida y periodo de envío

de datos (P ). Para su obtención se ha aplicado la expresión 4.19. Por otra parte, en la gura 4.26b se

muestra la vida útil que obtendríamos con esta corriente media para unas baterías AAA de capacidad

1200 mAh (valores calculados gracias a la expresión 4.3).

(a) Corriente media consumida por un dispositivo nal (b) Vida útil para baterías AAA con capacidad 1200 mAh

Figura 4.26: Corriente media consumida y vida útil de las baterías en función de P

Como vemos, la corriente media consumida por un dispositivo nal toma por lo general valores muy

inferiores a 1 mA. Este resultado es considerablemente inferior al obtenido en un coordinador o un router

que, recordamos, consumen alrededor de 38 mA cuando funcionan de manera regular. Este bajo consumo

permite obtener una vida útil para las baterías de hasta 5 años o más, dependiendo del valor de P.

Efecto del tamaño de paquete de datos sobre el consumo de corriente

Hasta ahora se ha estudiado el caso de envío de un paquete de datos de tamaño jo. En ZASA este

tamaño es de 2 bytes, uno para la medida de temperatura y otro para la de voltaje. En este apartado

estudiaremos el efecto del aumento de tamaño de dicho paquete sobre el consumo total.


En la gura 4.27 vemos una imagen ampliada de una secuencia activa en la que se transmite un paquete

de 2 bytes de tamaño (1,1 ms aproximadamente).

Figura 4.27: Consumo de corriente durante una secuencia activa

Conforme incrementamos el número de bytes que contiene dicho paquete aumentará la duración del

intervalo de transmisión (TX) y, en consecuencia, el de la secuencia activa. Ello tiene como resultado

el aumento del consumo medio de corriente de nuestro dispositivo. El procedimiento que se ha seguido

es modicar el código de ZASA para aumentar el tamaño de paquete a enviar y medir la duración del

intervalo de transmisión asociado. En la gura 4.28 vemos un paquete de datos que transmite 5 bytes (en

APS Payload), los dos primeros de los cuales siguen siendo las medidas de temperatura y voltaje.

Figura 4.28: Paquete de datos de 5 bytes de carga útil

Se ha realizado dicha medida para ciertos valores del tamaño del paquete de datos y, aplicando el

método de los mínimos cuadrados, se ha extrapolado el resultado (gura 4.29). Como vemos, la recta corta

al eje de las ordenadas en el punto 1 mA aproximadamente, esto es debido a que, aun en el hipotético

caso de enviar un paquete vacío, es necesario transmitir las cabeceras de las capas física, MAC, de red y

de aplicación.


Figura 4.29: Duración del intervalo de transmisión (TX) para distintos tamaños de paquete

Antes de seguir señalaremos que la anterior gráca nos permite, además, comprobar de manera práctica

el régimen binario que presta el estándar 802.15.4 [10]. Como vemos, en ella se relaciona el tamaño del

paquete de datos (bytes) con la duración del intervalo de transmisión (segundos). En consecuencia, se

puede deducir el régimen binario como la inversa de la pendiente de la recta representada en dicha gráca.

Esto es:

Pendiente = 0,032msbyte

(4.14)

Regimen binario =1

Pendiente= 31,25

bytes

ms= 250 kbps (4.15)

Como vemos, el régimen binario es exactamente de 250 kbps lo que coincide con la denición del

estándar para la frecuencia de 2,4 GHz.

Cuando aumentamos el tamaño del paquete de información la duración de una secuencia activa (d)

y el valor de corriente media en dicho intervalo (ISec) aumentarán. Esto hace que el valor de corriente

media consumida por nuestro dispositivo (IMedia, expresión 4.19) también aumente.

Anteriormente vimos que la secuencia activa (d) dura 17 ms, de los cuales 0,1 ms se emplean en

transmitir los 2 bytes de datos, 1 ms en transmitir las cabeceras a nivel físico, MAC, de red y de aplicación

y 15,9 ms en el resto de procesos. Si denimos n como el número de bytes del paquete de información,

estamos ya en condiciones de generalizar la duración d(n) de una secuencia activa para cualquier valor den:

d(n) = 15,9 ms + 1 ms +n (bytes)

Regimen binario (bytes/ms)(4.16)

El siguiente paso es calcular ISec en función de n. Teniendo en cuenta la gura 4.30 y la tabla 4.6 se

puede aproximar ISec(n) como:


ISec(n) =∑

i

[corriente intervalo(i) ·duracion intervalo(i)

d(n)] (4.17)

Siendo i el número que indica el estado por el que pasa el dispositivo.

Figura 4.30: Consumo durante una secuencia activa por partes

i Estado Corriente (mA) Duración del intervalo (ms)

1 CC2480 en estado activo 13 7,82 CC2480 activo y LED rojo 17 1,23 CC2480 en estado activo 13 1,24 Recepción (CSMA-CA) 32,5 1,6 (valor medio)

5 Transmisión 30,5 1 ms + n (bytes)Regimen binario (bytes/ms)

6 Recepción (ack a nivel MAC) 32,5 1,37 CC2480 en estado activo 13 2,8

Cuadro 4.6: Consumo de corriente en los diferentes intervalos de una secuencia activa

La expresión 4.19 nos quedaría ahora como:

IMedia(n) =d(n)P

· ISec(n) + (1− d(n)P

) · ISleep (4.18)

Así pues, podemos ahora caracterizar el consumo en un nodo para distintos tamaños de paquete. En

la gura 4.31 vemos la corriente consumida y la vida útil para baterías de 1200 mAh, todo ello en función

de n. Como vemos, la vida útil disminuye en gran medida conforme aumentamos el tamaño de paquete.

Es por ello que ZigBee/802.15.4 está recomendado para envíos de paquetes de datos pequeños, y no para

una conexión ja de comunicación entre dos nodos.


(a) Consumo de corriente (b) Vida útil

Figura 4.31: Consumo de corriente y vida útil de las baterías en función del tamaño de paquete (n)

Efecto del uso de seguridad sobre el consumo de corriente

Por defecto, la aplicación de ejemplo ZASA no utiliza el mecanismo de seguridad que nos proporciona

el integrado CC2480 (sección 3.1.2). Para estudiar el efecto del uso de seguridad sobre el consumo de

corriente se ha tenido que modicar el código de dicha aplicación. En concreto, hemos utilizado el comando

zb_write_conguration de la interfaz Simple API para, en el momento de la inicialización, congurar el

parámetro especíco de la red ZCD_NV_SECURITY_MODE. Haciendo que dicho parámetro valga 1,

tanto en el dispositivo hijo como en el padre, ambos nodos utilizarán el modo seguro en sus comunicaciones.

En la gura 4.32 vemos un paquete de datos enviado desde un dispositivo nal hasta el coordinador.

Podemos ver como los dos bytes se codican usando un total de 20 bytes. Como no podía ser de otra

manera, en el campo de control de trama a nivel de aplicación se indica que la seguridad está activada

(Sec vale 1).

Figura 4.32: Envío de 2 bytes utilizando seguridad

Se deduce pues, que el uso de seguridad implica un aumento en el tamaño de la carga útil del nivel de

aplicación. Por lo tanto nos remitimos al punto anterior, en el que se estudia el efecto sobre el consumo

cuando enviamos paquetes de tamaño variable. De forma práctica hemos comprobado que, al codicar un

paquete de tamaño n, el paquete resultante tiene un tamaño de n + 18 bytes.

Para más información respecto a la codicación a nivel de aplicación remitimos al lector al estándar

ZigBee [9].


Efecto del uso de ack a nivel de aplicación y mensajes POLL

En la aplicación de ejemplo ZASA, podemos activar la opción de ack a nivel de aplicación. Este tipo

de conrmación se realiza extremo a extremo, lo que quiere decir que, para el caso particular de ZASA,

el sumidero deberá enviar a la fuente un mensaje de conrmación una vez recibos los datos.

Por otra parte, recordamos que un dispositivo nal tiene la opción de enviar mensajes POLL (sondeo)

a su dispositivo padre por si éste tiene información para él. Aunque este tipo de mensajes no tienen

relación con el ack a nivel de aplicación, ZASA está congurado de tal forma que cuando activamos el

ack de aplicación el dispositivo nal también envía mensajes POLL a su padre. En concreto, se enviará

un mensaje POLL después de cada envío de datos. ZASA está congurado de forma que la fuente nunca

reciba datos, es por ello que un dispositivo nal nunca recibirá respuesta a un mensaje POLL.

Por todo lo anterior es necesario enfatizar que los resultados mostrados a continuación son meramente

orientativos y especícos de la aplicación de ejemplo ZASA.

La gura 4.33a muestra el consumo de corriente durante el envío de un paquete de datos (1), la

recepción del ack de aplicación (2), y el envío de un mensaje POLL (3). El tiempo entre el paso 1 y el 2, y

entre el 2 y el 3, siempre es el mismo y viene denido en ZASA por la variable APP_RESPONSE_POLL

(100 ms por defecto). En este punto es importante destacar que, como vemos en dicha gráca, entre el paso

1 y el 2 el integrado CC2480 queda en modo activo, consumiendo 13 mA. En dicho intervalo el CC2480

debería estar en modo de bajo consumo pero, por contra, prácticamente la totalidad de las ocasiones el

integrado CC2480 se mantiene en modo activo consumiendo como media 13 mA. En la gura 4.33b se

muestra un caso de funcionamiento correcto. Este error del dispositivo CC2480 está especicado en el

documento Errata Notes CC2480 de Texas Instruments [16]. Dicho problema aumenta en gran medida

el consumo de corriente total.

(a) Funcionamiento incorrecto (b) Funcionamiento correcto

Figura 4.33: Consumo durante el envío de datos con ack activo y mensaje POLL

El paso 1 es idéntico al caso expuesto con anterioridad, en el cual el dispositivo nal envía un paquete

de datos hacia el coordinador. Los pasos 2 y 3, para el caso de funcionamiento incorrecto, se muestran

detalladamente en las guras 4.34a y 4.34b respectivamente.


(a) Envío de ack de aplicación (paso 2) (b) Envío de mensaje POLL (paso 3)

Figura 4.34: Consumo debido a la recepción del mensaje ack de aplicación y envío de mensaje POLL

Desglose de los pasos:

1. Envío de información. Paso idéntico al caso expuesto en el apartado Descripción detallada del

consumo del presente capítulo. Al igual que antes, y por simplicidad, se considera que la secuencia

activa comienza en el momento que el CC2480 comienza a consumir 13 mA (modo activo).

2. Envío de la conrmación ack a nivel de aplicación. Paso compuesto por:

a) El CC2480 se encuentra en modo activo debido al error que presenta dicho integrado.

b) Se escucha el canal según requiere el algoritmo CSMA-CA.

c) Se transmite una petición de ack a nivel de aplicación.

Figura 4.35: Petición de ack a nivel de aplicación

d) Se reciben el ack a nivel MAC asociado a c) y el ack a nivel de aplicación.

Figura 4.36: Ack a nivel MAC y de aplicación

e) Se envía un ack a nivel MAC para conrmar que se ha recibido el ack a nivel de aplicación.


Figura 4.37: Ack a nivel MAC

f ) Se enciende el LED rojo para indicar que se ha enviado correctamente el paquete de datos.

g) El CC2480 entra en modo de bajo consumo.

3. Mensaje tipo POLL. Es importante remarcar que el microprocesador MSP430 no interere en este

proceso. Únicamente en el caso de que, efectivamente, el dispositivo padre tuviera datos para el hijo,

el MSP430 sería despertado por el integrado CC2480.

a) El CC2480 se despierta.

b) CC2480 pasa a modo activo.

c) Sistema radio en modo recepción conforme al algoritmo CSMA-CA.

d) Envío del mensaje POLL.

Figura 4.38: Mensaje POLL

e) Recepción de ack a nivel MAC.

Figura 4.39: Ack a nivel MAC

f ) CC2480 en modo activo. Al nal de este paso se considere que termina la secuencia activa.

De nuevo, utilizaríamos la expresión (4.19) para calcular la corriente media consumida por nuestro dis-

positivo:

IMedia =d

P· ISec + (1− d

P) · ISleep (4.19)

La duración de una secuencia activa es en este caso:

d = 235 ms (4.20)

Para el caso de que ocurra el error, es decir, entre el paso 1 y el 2 el CC2480 sigue en modo activo, la

corriente media durante una secuencia activa sería:

ISec = 8,7 mA (4.21)


Teniendo en cuenta que la corriente en modo de bajo consumo toma el valor de 750 nA tendríamos

el siguiente resultado para la corriente media consumida (con P igual a 10 segundos, que es el valor por

defecto en ZASA):

IMedia = 0,2 mA (4.22)

En el caso de que no se diera el error, ISec tomaría el valor de 3,64 mA, por lo que para un periodo

de envío de datos de 10 segundos, la corriente media consumida sería sólo de 86,27 µA. Como vemos, el

consumo aumenta considerablemente debido al error del integrado CC2480. En la gura 4.40 mostramos

el consumo de corriente y la vida útil de las baterías para el caso de funcionamiento con error y sin él.

(a) Corriente media consumida (b) Vida útil

Figura 4.40: Corriente media consumida y vida útil con y sin error de funcionamiento en el CC2480

4.4. Pérdida de conexión con el dispositivo padre

En este punto estudiaremos el consumo de un dispositivo una vez pierde la conexión con su dispositivo

padre. Lógicamente, sólo tiene sentido analizar este caso para un router o para un dispositivo nal.

4.4.1. Router

Cuando un router pierde la conexión con su dispositivo padre, es decir, no recibe respuesta ack a nivel

MAC, comenzará un proceso de reconexión. Durante este proceso el dispositivo hijo envía un paquete

broadcast en busca de un nuevo dispositivo padre. En la gura 4.41a podemos ver una captura de dicho

paquete realizada con Packet Snier. Puesto que se trata de un mensaje tipo broadcast, la dirección MAC

destino es 0xFFFF; sin embargo, a nivel de red, se utiliza la dirección 0xFFFC, que signica todos los

routers (incluido el coordinador) en el rango de alcance [10]. Esto es así puesto que, como es lógico,

resulta imposible conectarse a un dispositivo nal. En el caso particular de ZASA este mensaje se envía

con un periodo igual al de envío de información. Si el router recibe una respuesta a dicho mensaje (gura

4.4: PÉRDIDA DE CONEXIÓN CON EL DISPOSITIVO PADRE 107

4.41b) por parte de un candidato a padre que pertenezca a la red de la que formaba parte, se conectará

a él.

(a) Solicitud de reconexión

(b) Respuesta de reconexión

Figura 4.41: Mensajes de reconexión

Respecto al consumo de corriente, al tratarse de un router, el sistema radio deberá seguir activo

continuamente. Es por ello que el consumo durante este proceso coincide con el caso del funcionamiento

regular del router (apartado 4.3.2).


Cuando un dispositivo nal pierde la conexión envía una noticación de orfandad (gura 4.42) en

todos los canales de su lista de canales posibles. De esta forma se intenta recuperar la conexión de manera

inmediata.

Figura 4.42: Noticación de orfandad

Si no recibe respuesta, comenzará un escaneo activo sobre dicha lista de canales. Esto quiere decir

que enviará balizas y permanecerá a la escucha de forma periódica, tal y como se ha visto en la sección

4.2.3. Si el dispositivo nal recibe una respuesta a alguna de las balizas que ha transmitido, enviará al

candidato a padre un mensaje de reasociación (para comprobar si pertenece a la red de la que previamente

formaba parte). En caso de recibir respuesta, se dará por concluido el proceso de reasociación. En la gura

4.43 se muestra el proceso de envío de baliza, respuesta y reasociación. El paquete 54 (P.nbr. = 54) es

la baliza emitida por el dispositivo nal. El paquete 55 se trata de la respuesta a dicha baliza por parte

del coordinador de red. Acto seguido, el dispositivo nal envía una petición de reasociación (paquete 56)

que requiere de conrmación ack a nivel MAC (paquete 57). Los paquetes 58 y 59 son una solicitud de

respuesta al mensaje anterior y su conrmación ack. Por último, el dispositivo padre responde a la petición

de reasociación (paquete 60) conrmando la dirección corta asignada al dispositivo hijo. El paquete 61 se

trata de una nueva conrmación ack a nivel MAC.


Figura 4.43: Proceso de reasociación

En la gura 4.44 se puede ver el consumo de corriente durante la búsqueda de un dispositivo padre para

el caso de escaneo activo sobre un canal. En la tabla 4.7 se resume el consumo para los casos de búsqueda

sobre uno y dieciséis canales (como vemos, los valores de corriente son muy similares a los obtenidos para

el proceso de inicio en la sección 4.2.3).

Figura 4.44: Consumo de corriente durante la reconexión realizando escaneo sobre un canal


IMedia(mA)

1 9,3416 27,64

Cuadro 4.7: Consumo máximo y mínimo durante la reasociación a la red

4.5: TABLA DE RESUMEN DE CONSUMO 109

4.5. Tabla de resumen de consumo

La tabla 4.8 muestra un resumen de la corriente media consumida para cada uno de los casos estudiados.

Destacamos aquí que estos resultados son meramente orientativos puesto que han sido obtenidos para el

caso particular de un integrado CC2480, un microprocesador MSP430 y la aplicación de ejemplo ZASA.

Además, dentro del estado de envío y recepción de datos, se ha tomado el caso básico de ack sólo a nivel

MAC, paquetes de datos de tamaño 2 bytes, envío cada 10 segundos y modo sin seguridad.

Estado Subestado IMedia (mA) Duración (s) Potencia (mW)

Proceso Conexión de la alimentación 3,9 1,3 11,7de encendido Espera 15,5 Variable 46,5

Inicio Escaneo sobre 1 canal 28,6 8 85,8Escaneo sobre 16 canales 34,3 46 100,6

Recepción

Permiso de asociación activado(LED rojo)

38,45 Variable 115,3

de datos Permiso de asociación desactivado(Parpadeo de LED rojo)


(a) Coordinador



Inicio Escaneo sobre 1 canal 26,6 2 79,8Escaneo sobre 16 canales 33,8 27,5 101,4

Recepción y

Permiso de asociación activado(LED verde)


envío de datos Permiso de asociación desactivado(Parpadeo de LED verde)


Pérdida

Permiso de asociación activado(LED verde)


de conexión Permiso de asociación desactivado(Parpadeo de LED verde)


(b) Router



Inicio Escaneo sobre 1 canal 17,2 2 51,6Escaneo sobre 16 canales 29,6 27,5 88,8

Secuencia activa 17,27 0,017 51,8Envío de datos Modo de bajo consumo 0,00075 Variable 0,00225

Total 0,03 Variable 0,09Pérdida Escaneo sobre 1 canal 9,34 Variable 28

de conexión Escaneo sobre 16 canales 27,64 Variable 82,9

(c) Dispositivo nal

Cuadro 4.8: Resumen del consumo medio de corriente y potencia. La tensión de alimentación es de 3 V.


Recordamos además que la corriente media consumida por un dispositivo nal para paquetes de datos

de tamaño n bytes viene denida por:

IMedia(n) =d(n)P

· ISec(n) + (1− d(n)P

) · ISleep (4.23)

Donde:

d(n) dene la duración de la secuencia activa y su expresión es:

d(n) = 15,9 ms + 1 ms +n (bytes)

Regimen binario (bytes/ms)(4.24)

Con Regimen binario = 31,25 bytesms .

ISec(n) es la corriente media consumida durante una secuencia activa denida como:

ISec(n) =∑

i

[corriente intervalo(i) ·duracion intervalo(i)

d(n)] (4.25)

ISleep es la corriente en el modo de bajo consumo y su valor es de 750 nA.

P es el periodo de envío de datos.

Capítulo 5

Conclusiones y líneas futuras de trabajo

En el presente capítulo expondremos de forma breve las conclusiones a las que hemos llegado tras la

realización de este proyecto. Además, plantearemos una serie de posibilidades en cuanto a la ampliación

del mismo, de forma que otros alumnos de esta u otra escuela puedan utilizar en benecio propio.

5.1. Conclusiones

Tras el estudio que se ha realizado sobre el estándar ZigBee/802.15.4 y su consumo de corriente,

podemos resaltar las siguientes ventajas que aportan los dispositivos basados en dicha tecnología:

El bajo consumo de corriente que presentan. Como se ha visto en el capítulo anterior, un dispositivo

ZigBee/802.15.4, bajo determinadas condiciones y durante su funcionamiento regular, puede alcanzar

un consumo medio muy por debajo de 1 mA. Esto permite que las baterías que alimenten dicho

dispositivo puedan alcanzar una vida útil del orden de años. Dado el n de esta tecnología, que no

es otro que formar redes de domótica, inmótica o control industrial, que los dispositivos que forman

la red tengan una gran independencia energética se hace altamente deseable.

Bajo coste. Tal y como se ha mencionado, los componentes mínimos de un dispositivo basado en

este estándar es un microprocesador, un transceptor o procesador ZigBee/802.15.4 y una antena

chip. Estos tres componentes pueden alcanzar precios muy bajos en el mercado, convirtiendo este

tipo de tecnología en accesible a gran número de desarrolladores.

Facilidad de programación. Como hemos visto con la aplicación de ejemplo ZASA, no es necesario

un gran conocimiento en el campo de la programación de microcontroladores para ser capaz de

desarrollar una aplicación ZigBee.

Por otro lado, también hemos comprobado una serie de dicultades que este estándar tendrá que salvar

en el futuro:

Dicultad de desarrollo de aplicaciones basadas en el modo balizado. Como se ha visto en el capítulo

4, los dispositivos nales son capaces de alcanzar un consumo mínimo mientras que, el coordinador

de red y los routers tienen un mayor consumo. Esto es así, conforme a lo que se ha explicado, puesto

111

112 CAPÍTULO 5: CONCLUSIONES Y LÍNEAS FUTURAS DE TRABAJO

que estos últimos deben estar continuamente escuchando el canal a la espera de información de sus

dispositivos hijo. Claramente este es un problema que presenta el modo no balizado, en el que no

existe una sincronización entre los nodos de la red. La dicultad en este punto se encuentra en el hecho

de que las distintas compañías están centradas por ahora en dicho modo de funcionamiento, que

ofrece peor rendimiento (en routers y coordinadores) a cambio de una mayor simplicidad. En el caso

de Texas Instruments, en lugar de utilizar Z-Stack, existe la posibilidad de trabajar con un protocolo

de nivel MAC conocido como TIMAC [34]. Éste nos permite formar una red en conguración de

estrella utilizando el modo balizado, aunque su uso no está muy generalizado.

El estándar se encuentra en sus primeros pasos. Aunque ya existe un gran número de empresas que

fabrican tanto hardware como software basado en ZigBee/802.15.4, todavía es demasiado pronto

para hablar de una completa implantación. Esto hace que, en ocasiones, encontrar información

sobre dicha tecnología, tanto a nivel comercial como técnico, se haga una tarea difícil.

Existencia de otros estándares similares. Dado el amplio mercado existente para este tipo de tec-

nología, han aparecido una serie de estándares paralelos que se presentan como una alternativa a

ZigBee/802.15.4. Algunos ejemplos son Z-Wave [35] o Bluetooth Low Energy Technology [36].

5.2. Líneas futuras de trabajo

ZigBee/802.15.4 es una tecnología relativamente nueva por lo que se nos abre un amplio abanico de

posibilidades en cuanto a su estudio se reere. A continuación mencionamos algunas opciones que, por su

relación con el presente proyecto, nos resultan muy interesantes:

Estudio del efecto de la potencia de transmisión sobre el consumo. El integrado CC2480 transmite

con una potencia de 1 mW (0 dBm) que no es congurable [13]. No obstante, otros dispositivos de

Texas Instruments, como el CC2520 [37] sí nos permiten variar dicha potencia de transmisión. Esto

nos da la posibilidad de ampliar el presente estudio atendiendo a la variación que dicha potencia de

transmisión provoca en el consumo de corriente.

Mejora del sistema de medidas. Como se ha visto en el capítulo anterior, todas las medidas de

tensión sobre la resistencia utilizada han sido tomadas utilizando un osciloscopio Tektronix TDS

3012B. Este instrumento nos permite la conexión al PC mediante un cable de red RJ45. Esto hace

posible su control (así como el envío de las capturas de pantalla) desde un ordenador. Para ello, se

recomienda el uso del entorno LabVIEW de National Instruments [38].

Realización una comparativa entre el consumo de ZigBee y Bluetooth.

Estudio de las interferencias entre ZigBee, Bluetooth y Wi-Fi.

Realización de un estudio sobre el consumo de corriente en un dispositivo que utilice el modo balizado

comprobando que, aparte de los dispositivos nales, el coordinador de red y los routers también

alcanzarían un mínimo consumo. Para ello recomendamos utilizar el kit de desarrollo CC2430DK

[39] de Texas Instruments junto con TIMAC.

5.2: LÍNEAS FUTURAS DE TRABAJO 113

Desarrollo de una aplicación ZigBee. El presente estudio se ha realizado basado en la aplicación de

ejemplo ZASA. Proponemos aquí el desarrollo de una aplicación similar, que sirva para demostrar

las posibilidades comerciales de dispositivos basados en la tecnología ZigBee/802.15.4.

Desarrollo de una aplicación para PC. Al igual que, gracias a la aplicación ejecutable en el ordenador

Sensor Monitor, podemos monitorizar los datos de nuestra red basada en ZASA, proponemos aquí

igualmente el desarrollo de una aplicación para PC que nos permita monitorizar e interactuar con

la supuesta aplicación ZigBee del punto anterior.

114 CAPÍTULO 5: CONCLUSIONES Y LÍNEAS FUTURAS DE TRABAJO

Apéndice A

Desarrollo de una aplicación para las

comunicaciones vía el puerto serie

Introducción

El objetivo de este anexo es mostrar el desarrollo de una aplicación de PC que se comunique, vía

el puerto serie, con un dispositivo que ejecute ZASA. Así, podremos monitorizar en nuestro ordenador

algunos de los parámetros de los distintos dispositivos. Esta funcionalidad es muy similar a la que nos

dan Z-Tool o Sensor Monitor. No obstante, nuestro objetivo es simplemente abrir una posible vía de

trabajo futuro ya que, adaptando esta aplicación a nuestros requerimientos, podríamos comunicarnos con

cualquier microprocesador.

La manera que tenemos de comunicar el PC y el microprocesador MSP430 es a través de la conexión

UART que nos proporciona el conector USB del kit eZ430-RF2480 (sección 3.1.1). ZASA, la aplicación

cargada en dicho microprocesador, tiene un módulo especialmente diseñado para las comunicaciones por

el puerto serie: MT (sección 3.1.5). Básicamente, lo que hace esta parte del código es enviar una copia

por la conexión UART de cualquier comando intercambiado entre los integrados MSP430 y CC2480. Así,

podremos monitorizar algunos de los parámetros de la red. Además de enviar esta copia, el módulo MT

también hace que el microprocesador MSP430 envíe una copia hacia el CC2480 de cualquier comando que

reciba por la conexión UART. Esto nos permite controlar, en cierta medida, el CC2480 desde el PC.

Respecto a ZASA, podremos monitorizar los datos recibidos por el coordinador, identicar el tipo de

dispositivo conectado al PC (coordinador, router, dispositivo nal), descubrir la topología de red, resetear

el dispositivo, etc.

El entorno de desarrollo que hemos elegido es Visual Studio y el lenguaje de programación Visual

Basic .NET.

Repetimos aquí que, aunque esta aplicación está especícamente desarrollada para funcionar junto a

ZASA, el esquema que deberíamos seguir para comunicarnos con cualquier otra aplicación en un micro-

procesador sería muy similar.

115

116CAPÍTULO A: DESARROLLO DE UNAAPLICACIÓN PARA LAS COMUNICACIONES VÍA EL PUERTO SERIE

Funcionamiento general

Lo primero que haremos al iniciar nuestra aplicación es indicar el puerto serie utilizado (COM1, COM2,

etc.). Una vez hecho esto se establecerá la conexión y leeremos continuamente todos los bytes recibidos

por dicho puerto, gracias a la conexión UART entre el PC y el MSP430. Estos bytes forman los comandos

que se intercambian los integrados MSP430 y CC2480, enviados a hacia el PC gracias al módulo MT de

ZASA. El formato de estos comandos, que ha sido expuesto la sección 3.1.2, se muestra de nuevo en la

gura A.1.

Figura A.1: Formato de trama de comunicación entre microprocesador y CC2480

Cada comando recibido será identicado gracias al campo Comando, de tamaño dos bytes. Para una

descripción detallada de todos los comandos disponibles se recomienda la lectura del documento [12]

Para que nuestra aplicación funcione correctamente debemos conectar el dispositivo al PC antes de que

haya sido congurado como coordinador, router o dispositivo nal. Si estoy es así, los pasos que seguirá

nuestra aplicación serán:

1. Leemos todos los comandos recibidos por el puerto serie. Si el comando recibido es zb_start_conf

esto signica que el usuario ha presionado el pulsador y el dispositivo ha sido congurado. En este

caso enviamos el comando zb_read_conguration con el parámetro ZCD_NV_LOGICAL_TYPE

en el campo de datos. Así, estaremos preguntando al nodo cuál es su tipo lógico.

2. Recibimos un comando como respuesta a la anterior solicitud (comando SRSP). Dicho comando nos

especicará en su campo de datos el tipo lógico del dispositivo conectado. Mostraremos por pantalla

si es un coordinador de red, router o un dispositivo nal.

3. Si el dispositivo conectado es un router o un dispositivo nal (fuentes de datos), no se realizará

ninguna tarea más. Si es un coordinador (sumidero) mostraremos por pantalla los valores de tem-

peratura y voltaje recibidos, así como la dirección corta del nodo que nos envía dichos datos. Esto se

consigue ignorando todos los comandos recibidos excepto zb_receive_data_ind, que contiene tanto

la información enviada por la fuente como su dirección corta.

Básicamente esta es la funcionalidad de nuestra aplicación. Aunque es muy simple, como ya hemos dicho,

sólo pretende ser una muestra de cómo realizar las comunicaciones entre PC y microcontrolador.

117

Diagrama de ujo

En la gura A.2 mostramos el diagrama de ujo de nuestra aplicación.

Figura A.2: Diagrama de ujo

Ejemplo de funcionamiento

En la gura A.3a vemos la pantalla inicial de la aplicación de comunicación. Lo primero que debemos

hacer es introducir el puerto serie al cual hemos conectado nuestro dispositivo. A continuación presion-

aremos el pulsador para congurarlo. Si dicho dispositivo es un coordinador de red, la pantalla de eventos

se mostrará roja. Conforme el dispositivo, que en este caso funciona como sumidero, reciba datos, se

irán mostrando por pantalla (gura A.3b). Cada vez que recibimos un paquete de datos proveniente de

una fuente se muestra por pantalla DATOS RECIBIDOS, la dirección corta del dispositivo que nos ha

enviado dicho paquete, el valor de la temperatura y el del voltaje. Si por contra, el dispositivo es un router

o un dispositivo nal, la pantalla se coloreará azul o amarillo, respectivamente, y la aplicación termina su

funcionamiento. En la gura A.3c se muestra el caso en el que el dispositivo conectado al puerto serie es

un router.

118CAPÍTULO A: DESARROLLO DE UNAAPLICACIÓN PARA LAS COMUNICACIONES VÍA EL PUERTO SERIE

(a) Inicio

(b) Coordinador recibiendo datos (c) Router

Figura A.3: Aplicación desarrollada para PC en funcionamiento

Referencias

[1] Santa Cruz Institute for Particle Physics. http://scipp.ucsc.edu/

[2] Texas Instrumentas, TI Low Power Wireless, ZigBee Technical Overview, 2007, Documento en

formato pdf accesible por internet en la dirección: http://focus.ti.com/lit/ml/swrp086a/swrp086a.pdf

[3] L. Jin-Shyan, S. Yu-Wei, S. Chung-Chou, A Comparative Study of Wireless Protocols: Bluetooth,

UWB, ZigBee, and Wi-Fi, The 33rd Annual Conference of the IEEE Industrial Electronics Society

(IECON), Taipei (Taiwan), Noviembre, 2007. Documento en formato pdf accesible por internet en

la dirección: http://eee.guc.edu.eg/Announcements/Comparaitive_Wireless_Standards.pdf

[4] URL de Bluetooth SIG. http://www.bluetooth.com

[5] J.C. Cano, J.M. Cano, E. González, C. Calafate, P. Manzoni, Evaluation of the Energetic Impact

of Bluetooth Low-Power Modes for Ubiquitous Computing Applications, 3rd ACM* International

Workshop on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous Networks, Octubre,

2006.

[6] Wi-Fi and Bluetooth - Interference Issues, Revisión 1, Informe interno, HP,

Enero, 2002. Documento en formato pdf accesible por iternet en la dirección:

http://www.hp.com/rnd/library/pdf/WiFi_Bluetooth_coexistance.pdf

[7] K. Mandke, H. Nam, L. Yerramneni, C. Zuniga, The Evolution of UWB and IEEE 802.15.3a for

Very High Data Rate WPAN, Informe interno, Mayo, 2003. Documento en formato pdf acesible por

internet en la dirección: http://users.ece.utexas.edu/~mandke/docs/Evolution_of_UWB.pdf

[8] D. Takahashi, Tzero Technologies shuts down; that's the end of ultrawideband, Publicación

electrónica Venture Beat, Febrero, 2009. Documento accesible por internet en la dirección:

http://venturebeat.com/2009/02/12/tzero-technologies-shuts-down-thats-the-end-of-ultrawideband/

[9] ZigBee Alliance, ZigBee Specication, Enero, 2008.

[10] IEEE Computer Society, Part 15.4: Wireless Medium Access Control (MAC) and

Physical Layer (PHY) Specications for Low-Rate Wireless Personal Area Networks

(WPANs), Septiembre, 2006. Documento accesible por internet en la dirección:

http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf

119

120 REFERENCIAS

[11] A. Koubaa, M. Alves, E. Tovar, IEEE 802.15.4 for Wireless Sensor Networks: A Technical Overview,

TR-050702, Technical Report, Julio, 2005. Documento en formato pdf accesible por internet en la

dirección: http://www.hurray.isep.ipp.pt/asp/

[12] CC2480 Interface Specication, SWRA175A, Texas Instruments, Abril, 2008. Documento en for-

mato pdf accesible por internet en la dirección: http://focus.ti.com/lit/er/swra175a/swra175a.pdf

[13] CC2480 Data Sheet, SWRS074A, Texas Instruments, Mayo, 2008. Documento en formato pdf ac-

cesible por internet en la dirección: http://focus.ti.com/lit/ds/symlink/cc2480a1.pdf

[14] Simple API for Z-Stack, SWRA196 versión 1.2, Texas Instruments, Abril, 2008. Documento en

formato pdf accesible por internet en la dirección: http://focus.ti.com/docs/toolsw/folders/print/z-

stack.html#Technical Documents

[15] Z-Stack Application Programming Interface, SWRA19 versión 1.5, Texas Instru-

ments, Abril, 2008. Documento en formato pdf accesible por internet en la dirección:

http://focus.ti.com/docs/toolsw/folders/print/z-stack.html#Technical Documents

[16] Errata Notes CC2480, SWRZ027, Texas Instruments, Abril, 2008. Documento en formato pdf ac-

cesible por internet en la dirección: http://focus.ti.com/docs/prod/folders/print/cc2480a1.html

[17] CC2480 Developer's Guide, SWRA176, Texas Instruments, Mayo, 2008. Documento en formato pdf

accesible por internet en la dirección: http://focus.ti.com/docs/prod/folders/print/cc2480a1.html

[18] IAR Embedded Workbench for TI MSP430. http://iar.com/website1/1.0.1.0/220/1/

[19] MSP430x2xx Family User's Guide, SLAU144E, Texas Instruments, Julio,

2008. Documento en formato pdf accesible por internet en la dirección:

http://focus.ti.com/docs/prod/folders/print/msp430f2274.html

[20] MSP430F22x2, MSP430F22x4 Mixed Signal Microcontroller, SLAS504B, Texas Instru-

ments, Julio, 2007. Documento en formato pdf accesible por internet en la dirección:

http://focus.ti.com/docs/prod/folders/print/msp430f2274.html

[21] CCZACCC06 Target Board Schematics 1 3, Project No. 02598, Revisión 1.3, Texas In-

struments, Marzo, 2008. Documento en formato pdf accesible por internet en la dirección:

http://focus.ti.com/docs/toolsw/folders/print/ez430-rf2480.html

[22] eZ430-RF2480 Demonstration Kit, SWRU151A, Texas Instruments, Abril, 2008. Documento en for-

mato pdf accesible por internet en la dirección: http://focus.ti.com/docs/toolsw/folders/print/ez430-

rf2480.html

[23] Digital Phosphor Oscilloscopes TDS 3012B, Tektronix, Agosto, 2005.

Documento en formato pdf accesible por internet en la dirección:

http://www.valuetronics.com/Details.aspx?ProdID=72&Model=Tektronix_TDS3000B%20Series

[24] PS2520, PS2520G, PS2521 & PS2521G User Manual, Tektronix, Enero,


http://www.ptc.edu/OnlineLabs/Devices/Manuals/PS2520G_um.pdf

REFERENCIAS 121

[25] HP 34401A User's Guide, Part Number 34401-90004, Hewlett-Packar, Febrero,


http://centrum.feld.cvut.cz/?download=_/hp34401a/hp34401.pdf

[26] CC2520 Datasheet, SWRS068, Texas Instruments, Diciembre, 2007. Documento en formato pdf

accesible por internet en la dirección: http://focus.ti.com/lit/ds/symlink/cc2520.pdf

[27] CC2520-CC2591EMK Quick Start Guide, SWRU172A, Texas Instruments, Agos-

to 2008. Documento en formato pdf accesible por internet en la dirección:

http://focus.ti.com/lit/ml/swru172a/swru172a.pdf

[28] SmartRF05 Evaluation Board User's Guide, SWRU210, Texas Instruments, Mar-

zo, 2009. Documento en formato pdf accesible por internet en la dirección:

http://focus.ti.com/lit/ug/swru210/swru210.pdf

[29] eZ430-RF2480 Sensor Monitor User's Guide, Revisión B, SWRU157, Texas Instru-

ments, Abril, 2008. Documento en formato pdf accesible por internet en la dirección:

http://focus.ti.com/lit/ug/swru157b/swru157b.pdf

[30] SmartRF Packet Snier User Manual Rev. 1.9, SWRU187, Texas Instruments,

Febrero, 2009. Documento en formato pdf accesible por internet en la dirección:

http://focus.ti.com/lit/ug/swru187a/swru187a.pdf

[31] MSP430 IAR EMBEDDED WORKBENCH Tutorials, IAR Systems, Ju-

nio, 2000. Documento en formato pdf accesible por internet en la dirección:

http://www.eecs.berkeley.edu/~boser/courses/40/labs/docs/IAR%20tutorial.pdf

[32] URL de MATLAB. http://www.mathworks.com/

[33] Current Shunt Monitor, SBOS307, revisión E, Texas Instruments, Mayo, 2004. Documento en for-

mato pdf accesible por internet en la dirección: http://focus.ti.com/lit/ds/symlink/ina195.pdf

[34] URL de Texas Instruments sobre TIMAC. http://focus.ti.com/docs/toolsw/folders/print/timac.html

[35] URL de Z-Wave Alliance. http://www.z-wavealliance.org

[36] URL de Bluetooth Low Energy Technology. http://www.bluetooth.com/Bluetooth/Products/Low_Energy.htm

[37] CC2520 Data Sheet, SWRS074A, Texas Instruments, Abril, 2008. Documento en formato pdf ac-

cesible por internet en la dirección: http://focus.ti.com/lit/ds/symlink/cc2520.pdf

[38] URL de National Instruments sobre LabVIEW. http://www.ni.com/labview/

[39] CC2430DK Development Kit User Manual, SWRU133, Texas Instruments, Oc-

tubre, 2007. Documento en formato pdf accesible por internet en la dirección:

http://focus.ti.com/lit/ug/swru133/swru133.pdf