APLICACIÓN DE MICROCHIP PARA ZIGBEE

(1)

Rodrigo de Marcos Peirotén 1

27 de abril de 2012

APLICACIÓN DE MICROCHIP PARA ZIGBEE

AUTOR

Rodrigo de Marcos Peirotén 4ºB IIND

Escuela Técnica Superior de Ingeniería (ICAI) - Universidad Pontificia Comillas. Asignatura: Comunicaciones Industriales Avanzadas. Curso 2011-2012

RESUMEN

Este trabajo trata sobre la aplicación que ha desarrollado la empresa Microchip Technology basado en el estándar IEEE 802.15.4, que es la base sobre la que se define la especificación de ZigBeeTM. Así nace el protocolo MiWiTM, diseñado para redes inalámbricas de área personal con tasas bajas de transmisión de datos y de bajo coste (LR-WPAN, del inglés Low Rate Wireless Personal Area Network).El protocolo MiWiTM es de código abierto, gratuito y libre de usar. Sin embargo, este protocolo está limitado a ciertos componentes hardware de Microchip Technologies. Se analizarán sus características y se comparará con ZigBeeTM o el IEEE 802.15.4. En este trabajo no se entrará en detalle con la programación, ya que el objetivo de este trabajo es explicar cómo funcionan las redes inalámbricas de Microchip Wireless, o sea, MiWiTM.

1. Introducción

Hoy en día se pueden encontrar más y más aplicaciones que requieran una comunicación inalámbrica. Desde que el IEEE publicó la especificación del WPAN (IEEE 802.15.4) en el año 2003, se ha convertido en un sector poderoso en el ámbito de las LR-WPAN. Esta especificación sirve para aplicaciones de baja tasa de transmisión de datos, de bajo consumo y de bajo coste. [1]

Después, en el 14 de diciembre de 2004, se aprobó la primera especificación de ZigBeeTM, que es un conjunto de protocolos de comunicación inalámbrica basada en el IEEE 802.15.4. ZigBeeTM se diseñó para aplicaciones de radio frecuencia que requieren un bajo caudal de datos, una autonomía larga para la batería. ZigBeeTM tiene un caudal definido de 250 Kbps adecuado para transmisiones intermitentes o señales con poca información y normalmente se transmiten a 2.4 GHz. [2]

Durante varios años, se ha usado ZigBeeTM en varias aplicaciones, sobre todo en el campo de la domótica. En el año 2006, la empresa Microchip Technology se ha interesado por las WPAN y sus aplicaciones; y ha desarrollado su propio protocolo de comunicación inalámbrica basado en el estándar IEEE 802.15.4 (y por lo tanto, en ZigBee): es el MiWiTM Developer Environment (DE); la solución inalámbrica de Microchip para ayudar a sus clientes a desarrollar aplicaciones inalámbricas y reducir su tiempo para comercializar. [3]

2. Introducción al

MiWiTM DE

(2)

27 de abril de 2012

El MiWiTM DE se compone de 3 capas principales: 1) La de aplicación inalámbrica

2) La de los protocolos de pila

3) La de los drivers de los transceptores (transmisor y receptor)

Cada capa tiene su archivo de configuración correspondiente. Microchip ha definido las capas de interfaz MiApp y MiMac que enlazan las 3 capas anteriores. Se ha desarrollado de tal manera que sea poco laborioso cambiar de protocolo de pila o de transceptor; es decir, en un archivo simplemente hay que comentar o descomentar una línea de código para poder realizar estos cambios. El MiWiTM DE soporta varias familias de microprocesadores de Microchip: PIC18, PIC24, PIC32 y dsPIC33. El MiWiTM DE solamente es compatible con los transceptores de Microchip [5]:

1) MRF24J40: transmite a 2.4 GHz

2) MRF49XA: transmite a 433, 868 ó 915 MHz 3) MRF89XA: transmite a 868 ó 915 MHz

Figura 1. Arquitectura del MiWiTM Development Environment

(3)

27 de abril de 2012

Se han mostrado los dispositivos mencionados anteriormente en la figura 2. Se puede combinar cualquier transceptor RF (en rojo) con cualquier placa de desarrollo (en verde). Obviamente, las comunicaciones entre distintos nodos se han de llevar a cabo con la misma frecuencia, luego se debe usar un único tipo de transceptor para una misma aplicación.

Si el usuario desea monitorizar lo que ocurre en una red soportada por MiWiTM DE Microchip ofrece varias soluciones mostradas en la siguiente tabla:

Tabla 1. Distintas soluciones que ofrece Microchip para monitorizar una red que usa MiWiTM

El método más cómodo para monitorizar es con el ZENATM Wireless Adapter (sólo compatible con el transceptor de 2.4 GHz). Es un sniffer, un dispositivo que captura toda comunicación inalámbrica que usa el protocolo MiWiTM en su radio de recepción. Este dispositivo se conecta por USB y, junto con el programa necesario, muestra en la pantalla del ordenador las tramas de paquetes que se están transmitiendo, con toda su información asociada.

De momento, Microchip ofrece de manera gratuita un proyecto de código abierto que, junto con el entorno de desarrollo MPLAB IDE, se puede programar en el microprocesador con un ejemplo simple para iniciar al cliente en este protocolo. El lenguaje de programación en el que se ofrece este proyecto es C. Este ejemplo trata de lo siguiente:

Figura 3. Ejemplo simple de interacción entre dos microprocesadores usando MiWiTM

Se tienen dos microprocesadores en su placa de desarrollo con un transceptor de 2.4 GHz incorporado. Una de las placas tiene incorporado un cable a su puerto serie para monitorizar en HyperTerminal lo que está ocurriendo. Las dos placas tienen un papel distinto.

(4)

27 de abril de 2012

La del cable serie es un maestro: es el nodo que se convierte en el centro de la red establecida en un canal (frecuencia). Los canales disponibles para la frecuencia de 2.4GHz son del 11 al 26:

Figura 4. Monitorización del escaneo de energía que ejecuta el maestro usando MiWiTM

Lo que hace el maestro antes de establecer una red es determinar qué canal dentro de la banda de los 2.4 GHz tiene menos cantidad de ruido para establecer su red en ese canal. Una vez establecida la red se puede iniciar el otro microprocesador, que va jugar el papel de esclavo: es un nodo que busca las redes establecidas por un dispositivo que usa MiWiTMpara conectarse a él. A continuación veremos cómo se monitoriza esto usando ZENATM:

Figura 5. Tramas capturadas en una conexión esclavo-maestro con ZENATM

La primera trama significa que el esclavo realiza un escaneo en todos los canales para encontrar una red establecida por un maestro, que en la segunda trama se puede ver que un dispositivo con una dirección distinta responde a ese escaneo. Una vez terminado este escaneo, entonces en la cuarta trama (la tercera trama es una trama ACK) el esclavo solicita al maestro la admisión a su red. Finalmente, en la sexta trama el maestro acepta al esclavo como un nodo en su red. Una vez realizado esto, los dos nodos se pueden intercambiar tramas de datos.

(5)

27 de abril de 2012

Este ejemplo que ofrece Microchip Technology Inc. facilita bastante la comprensión del establecimiento de una red con MiWiTM. Para adaptarlo a cualquier aplicación habrá que modificar el proyecto en lenguaje C con el entorno de desarrollo MPLAB IDE teniendo en cuenta las notas de aplicación siguientes, disponibles en la web de Microchip:

1) AN1066: MiWi™ Wireless Networking Protocol Stack 2) AN1204: Microchip MiWi™ P2P Wireless Protocol

3) AN1283: Microchip Wireless (MiWi™) Media Access Controller – MiMAC

4) AN1284: Microchip Wireless (MiWi™) Application Programming Interface – MiApp

3. Protocolo inalámbrico de pila de

MiWiTM [6]

3.1. Especificación del IEEE 802.15.4 y el protocolo inalámbrico de pila de MiWi

TM

3.1.1. Capas PHY y MAC del IEEE 802.15.4

El protocolo MiWi™ se basa en las capas MAC (control de acceso al medio) y PHY (física) del IEEE 802.15.4. Este estándar define tres bandas de frecuencias de operación:

1) Banda de 868 MHz, canales disponibles: 1 (0), caudal máximo de datos: 20 Kbps 2) Banda de 915 MHz, canales disponibles: 10 (1-11), caudal máximo de datos: 40 Kbps 3) Banda de 2.4 GHz, canales disponibles: 16 (11-26), caudal máximo de datos: 250 Kbps

La longitud máxima de un paquete MAC del IEE 802.15.4 es de 127 bytes, incluyendo un CRC de 16 bits, que verifica el contenido de la trama. También, el IEEE 802.15.4 usa un mecanismo de transmisión de datos de confirmación (ACK) en el MAC. Este método usa un flag de ACK en la cabecera del paquete que si está activo, el receptor del paquete debe confirmar el recibo. Si el transmisor no ha recibido esta confirmación antes de declarar un timeout, el transmisor intentará enviar el paquete otra vez un número fijado de intentos antes de declarar un error. Nótese que método simplemente verifica si la trama se ha recibido correctamente pero no si se ha procesado correctamente debido a falta de recursos. Habría que establecer otro método más de confirmación para resolver estos casos.

3.1.2. Tipos de dispositivos del IEEE 802.15.4 y de MiWi

TM

El IEEE 802.15.4 define dispositivos basados en su totalidad de funciones. Hay dos tipos, mostrados en la tabla a continuación. El protocolo MiWiTM define tres tipos de dispositivos, aunque uno de ellos puede resultar redundante, dependiendo de la aplicación en la que se use:

(6)

27 de abril de 2012

3.1.3. Topologías de red del protocolo inalámbrico de pila de MiWi

TM

En este protocolo existen cuatro tipos de topologías que se basan en el IEEE 802.15.4: topología en estrella, topología en árbol, topología en malla y topología P2P:

1) En la topología en estrella existe un único maestro (el PAN coordinator) y varios esclavos (los end devices) conectados únicamente al maestro .

2) La topología en árbol permite tener de los tres tipos de dispositivos, en el que todos los dispositivos extremos están conectados al coordinador de la red o a un subcoordinador, y todos los subcoordinadores se conectan al coordinator de la red.

3) La configuración en malla es similar a la configuración en árbol, excepto que los dispositivos extremos son capaces de transmitir mensajes entre ellos sin tener que pasar por algún coordinador.

4) La configuración P2P es la manera más simple de comunicarse, con solo un dispositivo comunicándose directamente con otro. No se distinguen maestros de esclavos.

A continuación se muestran de manera esquemática cómo pueden ser las redes con estas topologías:

3.2. Asignación de direcciones

Este protocolo usa las direcciones que proporciona el IEEE 802.15.4. Este estándar define tres tipos de direcciones:

1) Extended Unique Identifier (EUI): es un número de 8 bytes que debería ser único en cada dispositivo, o habrá problemas de identidad para distinguir dos nodos diferentes. Los primeros 3 bytes del EUI son comprados del IEEE, y los otros 5 están disponibles para el usuario.

2) PAN Identifier (PANID): es una dirección de 16 bits que define un grupo de nodos. Todos los nodos en el mismo PAN comparten un PANID en común. Un dispositivo adquiere un PANID cuando decide unirse al PAN asociado.

(7)

27 de abril de 2012

3) Short Address: también conocido como la dirección del dispositivo. Este número, de 16 bits, se le asigna a un dispositivo cuando se conecta a un coordinador de la red. Esta dirección es única dentro de un mismo PAN, y el IEEE fija la dirección del coordinador del PAN al 0000h. El protocolo MiWiTM usa estos 16 bits para ayudar con el direccionamiento de mensajes y con el intercambio de información entre nodos. Los bits de esta dirección se muestran en la figura 7, y un ejemplo de asignación de mensajes se muestra en la figura 8:

El segundo campo de bits (Parent’s Number) es único para cada subcoordinador en la red, incluyendo al coordinador del PAN. Nótese que este campo de bits es de 3, luego como mucho hay 8 coordinadores en total en un solo PAN.

El último campo de bits (Child’s Number) distingue a los dispositivos extremos de los coordinadores; ya que un coordinador tiene todo este campo de bits a 0.

El bit 7 (RxOffWhenIdle) es lo contrario de lo que el IEEE 802.15.4 definió como RxOnWhenIdle. Cuando este bit toma el valor de 1, el dispositivo apagará su transceptor cuando se encuentre ocioso y por lo tanto no podrá recibir paquetes. Todos los paquetes destinados a este dispositivo en standby se redireccionarán a su maestro asociado, y éste guardará el paquete hasta que el dispositivo esclavo active su transceptor. Si este bit tiene valor 0 entonces siempre podrá recibir paquetes.

Figura 7. Organización de los bits de la dirección corta del protocolo MiWiTM

(8)

27 de abril de 2012

3.3. Protocolo de mensajes de MiWi

TM

Una vez se haya formado una red, lo siguiente que hay que tener en cuenta es cómo enviar mensajes por la red. Cualquier dispositivo que sea miembro de una red de protocolo

MiWi

TM

usará su dirección corta (Short Address) para comunicarse en el entorno de la

red. Esta dirección corta ayuda a otros dispositivos en la misma red a determinar el

paradero del nodo en cuestión y cómo dirigirse a este nodo. Dispositivos que están

usando relaciones P2P usarán su dirección larga para comunicarse.

3.3.1. Formato de los paquetes y paquetes de tipo informe

El protocolo MiWi

TM

usa el formato de paquetes de la capa MAC del IEEE

802.15.4 para todos sus paquetes. Sobre esta capa reside la cabecera del protocolo

MiWi

TM

que contiene la información necesaria para guiar y procesar paquetes. El

formato de la cabecera se muestra en la figura 9:

1) Hops: Es el número de retransmisiones (o saltos) permitidos para el paquete.

2) Frame Control: Es un campo de bits que define el comportamiento del paquete.

a) Los bits marcados como r (reservado) valen 0 en esta implementación)

b) ACKREQ: si está a 1, el transmisor ha pedido una confirmación de capa superior del receptor.

c) INTRCLST: también es un bit reservado que se mantiene a 1.

d) ENCRYPT: si está a 1, el paquete está codificado al nivel de aplicación. 3) Dest PANID: la identificación del PAN del nodo de destino del paquete (2 bytes). 4) Dest Short Address: la dirección corta del nodo de destino del paquete (2 bytes). 5) Source Short Address: la dirección corta del nodo de origen del paquete (2 bytes). 6) Sequence number: un número de secuencia que se puede usar para vigilar el estado de

los paquetes mientras viajan por la red.

7) Report type: es el agrupamiento del mensaje contenido en este paquete. 8) Report ID: es el tipo de mensaje contenido en este paquete.

(9)

27 de abril de 2012

Estos últimos 2 bytes son usados por el protocolo para organizar a los nodos en la red y también para las confirmaciones de paquetes recibidos. Los distintos tipos e identificaciones de estos informes se muestran en la tabla 3:

1) OPEN_CLUSTER_SOCKET: Un nodo que quiere comunicarse con otro envía una petición al coordinador del PAN. Después, el coordinador del PAN mantiene en espera esta petición durante un periodo determinado. Si el coordinador del PAN recibe la misma petición del otro nodo antes del tiempo establecido, entonces combina la información de los dos nodos en una respuesta que manda a los dos nodos. Estos dos nodos extraen la información de esta respuesta para determinar si es en realidad el nodo con el que quieren comunicarse. Esta decisión pertenece a la capa de aplicación, no se proporciona por la capa de pila.

2) OPEN_P2P_SOCKET: el nodo que realiza esta petición realiza un broadcast (transmisión a todos los dispositivos que puedan recibir este paquete, este tipo de mensajes se dirige a una dirección corta especial que es FFFFh) para establecer una relación P2P con un nodo existente en la red. Una vez el nodo en cuestión haya recibido esta petición, le contesta al nodo origen con su EUI para terminar de establecer el enlace P2P. Solo los coordinadores son capaces de establecer un enlace P2P.

3) EUI_ADDRESS_SEARCH: esta petición también se realiza por broadcast, y se usa para buscar al dispositivo que tenga un cierto EUI. Una vez un nodo haya recibido este mensaje, si conoce directamente el dispositivo en cuestión, le contesta al nodo origen con el PANID y la dirección corta del dispositivo que se está buscando. En caso contrario y si este nodo es un coordinador, entonces se realiza un rebroadcast para que la petición llegue más lejos. La respuesta siempre se guiará al nodo origen.

4) ACK_REPORT_TYPE: si un nodo pide una confirmación de paquete recibido al enviar un paquete a otro nodo, este nodo le contesta con un informe de tipo ACK para confirmar que ha recibido el paquete.

3.3.2. Direccionamiento (routing) de los paquetes

Para guiar un mensaje en una red inalámbrica puede requerir procesos

laboriosos. El protocolo MiWi

TM

resuelve este problema de la siguiente manera, tal y

como se puede resumir en la figura 10:

(10)

27 de abril de 2012

Una de las tareas de un algoritmo para guiar mensajes es determinar el siguiente salto o retransmisión para un paquete que se va a enviar. Para ello, un nodo debe tener la información acerca de los coordinadores y subcoordinadores cercanos a él. Cuando un dispositivo se une a la red, este manda un paquete de petición de baliza (beacon request packet). Los coordinadores que reciban esta petición contestan con un paquete baliza que contiene información sobre los dispositivos cercanos al nodo que ha enviado la petición. Dicho paquete se compone de:

1) Protocol ID (1 byte): Esto ayuda a distinguir el protocolo

MiWi

TM

de otros

protocolos relacionados con el IEEE 802.15.4 que puedan operar en el

mismo rango de frecuencias. El valor de este byte es siempre 4Dh.

2)

Versión (1 byte): En este caso vale 10h.

3)

Coordinadores locales (1 byte): Cada bit indica qué coordinadores son

visibles por el coordinador que ha mandado este paquete (recordar que hay

como mucho 8 coordinadores). Si por ejemplo el coordinador 0x0200 es

capaz de hablar al coordinador 0x0500 y al coordinador del PAN (0x0000),

entonces este conjunto de bits debería ser: 00100101b.

Este último byte es clave para el retransmisión de los mensajes, así los coordinadores sabrán qué caminos puede recorrer el paquete para guiarlo a su destino. En el caso de paquetes que se transmiten de manera global (broadcast), éstos son procesados por todos los nodos que lo reciban y solo los coordinadores realizan el rebroadcast. Estos paquetes deben tener el bit ACKREQ a 0.

3.4. Seguridad del protocolo MiWi

TM

El protocolo

MiWi

TM

sigue la definición de seguridad MAC especificada en el

IEEE 802.15.4. Los siete modos de seguridad definidas en la especificación están

incluidas en el protocolo MiWi

TM

. Se puede categorizar estos modos en tres grupos:

1)

El modo AES-CTR codifica el contenido del mensaje de un paquete de protocolo

MiWi

TM

. El atacante no entenderá su contenido sin una clave. Este modo de

seguridad no puede verificar la trama del contenido de la cabecera y la

dirección del transmisor de este paquete.

(11)

27 de abril de 2012

2)

Los modos AES-CBC-MAC aseguran la integridad de un paquete de protocolo MiWiTM. El código de de integridad del mensaje (MIC, del inglés Message Integrity Code) adjuntado al paquete asegura que el paquete, incluyendo su cabecera y contenido, no se ha modificado de ninguna manera durante la transmisión. Cada modo tiene su tamaño del MIC asociado: cuanto más tamaño más protección se le proporciona al paquete. Sin embargo, el contenido del mensaje no se puede cifrar mediante estos modos.

3)

Los modos AES-CCM combinan el cifrado y la protección de los dos modos anteriores, asegurando de manera simultánea la codificación y la integridad del paquete de protocolo MiWiTM.

En la tabla 4 se ha mostrado un resumen de los distintos modos de seguridad que ofrece el IEEE 802.15.4TM. El modo de seguridad con identificación 00h significa no habilitar ninguna seguridad. En la figura 11 se muestra la cabecera de un paquete de protocolo MiWiTM con un modo cualquiera de seguridad habilitado:

La Pila proporciona un soporte de seguridad en la capa del protocolo MiWiTM. Al habilitar la seguridad, el bit 0 del campo Frame Control se pone a 1. Si esto ocurre, la Pila protege los paquetes de la capa del protocolo MiWiTM. Los campos de bytes de la cabecera de este protocolo (excepto los campos Hops, Report ID y Report ID) se usan como datos de autentificación para todos los modos de seguridad, excepto el modo AES-CTR. El tipo, la identificación y el contenido del informe quedan protegidos. Al habilitar la seguridad, la Pila añade 3 nuevos elementos en la cabecera del paquete justo antes del contenido del paquete:

1) El campo Frame Counter (4 bytes). 2) El campo Long Source Address (8 bytes). 3) El campo Key Sequence Number (1 byte).

Figura 11. Formato de una cabecera de un paquete del protocolo MiWiTM con seguridad habilitada Tabla 4. Modos de seguridad del IEEE 802.15.4TM

(12)

27 de abril de 2012

Si se habilita la seguridad, se necesitan entre 13 y 29 bytes adicionales para la cabecera auxiliar de seguridad y el MIC, dependiendo del modo de seguridad escogido y de la capa protegida. Los usuarios necesitarán equilibrar la necesidad de seguridad y el impacto sobre el tamaño del paquete (y el impacto asociado al rendimiento) asociado a la combinación de configuraciones de seguridad.

La seguridad del protocolo MiWiTM comprueba el contador de trama (frame counter) para evitar ataques de repetición. Solo paquetes de este protocolo de un familiar (maestro o esclavo) de un nodo son comprobados para actualizar el contador de trama, porque solo los familiares son capaces de saber si, entre ellos, se unen o se marchan de la red. Cualquier paquete de un familiar no debe tener el contador de trama menor que el contador de trama almacenado; en caso contrario, se descarta el paquete. Cualquier maestro reiniciará el correspondiente contador de trama entrante almacenado una vez el correspondiente esclavo se une o se re-une a la red.

La seguridad del protocolo MiWiTM asume que toda la información de seguridad, incluyendo la clave de seguridad de 16 bytes, el número de secuencia de clave y el modo de seguridad, son preconfigurados en la Pila. La manera más segura para implementar la seguridad y todo lo que conlleva, es usar la herramienta de análisis ZENATM para configurar la información de seguridad y crear el archivo MiWiDefs.h usado en la aplicación. De esta manera, la información de seguridad se almacena en la memoria de programa y no se puede modificar durante la ejecución; así no se transferirá ninguna clave de seguridad por el aire.

3.5. Establecer un proyecto de pila de protocolo MiWi

TM

En este trabajo se explicará, sin entrar en detalle, la naturaleza de los programas del proyecto desarrollado por Microchip. En la dirección http://www.microchip.com/MiWi se puede descargar la última versión del proyecto. La arquitectura de este proyecto es el siguiente:

En la tabla 5 se puede apreciar cómo se organiza el proyecto. Sin embargo, este trabajo se centra en el funcionamiento del protocolo, no en la programación del mismo en un microprocesador. Para más información acerca de la programación consultar el documento AN1066 en esta dirección:http://ww1.microchip.com/downloads/en/appnotes/01066A.pdf.

(13)

27 de abril de 2012

4. Protocolo inalámbrico P2P de

MiWiTM [7]

4.1. Especificación del IEEE 802.15.4 y el protocolo inalámbrico P2P de MiWi

TM

4.1.1. Introducción

Después del lanzamiento inicial del IEEE 802.15.4, se publicó una revisión posterior en 2006 para aclarar ciertos problemas. Esta revisión se refiere al IEEE 802.15.4b o 802.15-2006, y se añadieron dos definiciones de capa física (PHY) en el espectro de los sub-GHz y modificó el módulo de seguridad.

Sin embargo, la mayoría de los productos en el mercado usa la especificación original, el IEEE 802.15.4a o 802.15.2003. En este documento, referencias al IEEE 802.15.4 son de la especificación original. El protocolo P2P de MiWiTM usa como referencia de diseño al

IEEE

802.15.4 y amplía el soporte para transceptores a los transceptores de Microchip.

4.1.2. Tipos de dispositivos del IEEE 802.15.4 y de MiWi

TM

Este apartado es idéntico al apartado 3.1.2 de este trabajo. Los dispositivos del protocolo inalámbrico de pila de MiWiTM se definen de la misma manera en los del protocolo inalámbrico P2P de MiWiTM.

4.1.3. Topologías de red del protocolo inalámbrico P2P de MiWi

TM

El IEEE 802.15.4 y el protocolo P2P de MiWiTM soportan únicamente dos topologías: topología en estrella y topología P2P, tal y como se muestran en la figura 12:

1) La topología en estrella tiene un solo coordinador de la red que inicia las comunicaciones y acepta las conexiones de otros dispositivos. Los dispositivos extremos sólo pueden comunicarse directamente con el coordinador.

2) La topología P2P también tiene un solo coordinador, pero los dispositivos extremos no tienen necesariamente que conectarse al coordinador. Si no se conectan al coordinador, se conectan entre sí.

(14)

27 de abril de 2012

4.1.4. Tipos de redes

La especificación del IEEE 802.15.4 tiene dos tipos de redes: de baliza y de no-baliza. Sin embargo, el protocolo P2P de MiWiTM soporta solo los de no-baliza.

En una red de baliza, los dispositivos pueden solo transmitir datos durante su intervalo de tiempo asignado. El coordinador del PAN asigna los intervalos de tiempo periódicamente enviando una trama baliza. Supuestamente, todos los dispositivos se sincronizan con la trama baliza y transmiten datos solamente durante su intervalo de tiempo asignado. Esto reduce el consumo de potencia ya que los dispositivos se apagan periódicamente.

En una red de no-baliza, cualquier dispositivo puede transmitir datos cuando sea, siempre que el nivel de ruido esté por debajo del nivel predefinido. Estas redes hacen que los dispositivos extremos FFD (full function device) consuman más porque tienen que tener los transceptores encendidos siempre. Sin embargo, los dispositivos extremos RFD (reduced function device) consumen menos porque no tienen que realizar tantas sincronizaciones.

4.1.5. Direccionamiento en redes

La especificación del IEEE 802.15.4 define dos tipos de mecanismos de direccionamiento:

1) Extended Organizationally Unique Identifier (EUI): también conocido como la dirección larga. Se trata de una dirección de 8 bytes que es única para cada dispositivo, en todo el mundo (si dos dispositivos con el mismo EUI se encuentran en la misma red habrá problemas de identidad). Los 3 bytes más significativos son comprados del IEEE, y los otros 5 se pueden cambiar como el usuario desee. 2) Short Address: también conocido como la dirección del dispositivo en la red. Esta

dirección es de 2 bytes y se le asigna a un dispositivo, cuando se conecta a la red, por su maestro. Esta dirección es única en toda la red.

El protocolo P2P de MiWiTM soporta solo comunicación one-hop (de un salto), por lo tanto transmite mensajes a través de la dirección larga. La dirección corta solo se usa cuando la pila transmite un mensaje global (broadcast), debido a que no hay una dirección larga de broadcast predefinida en la especificación del IEEE 802.15.4. Para los transceptores de Microchip, el EUI puede ser de 2 a 8 bytes, dependiendo de las necesidades de la aplicación.

4.1.6. Formato de mensajes para los transceptores del IEEE 802.15.4

El formato de mensajes del protocolo P2P de MiWiTM es un subconjunto del formato de mensajes de la especificación del IEEE 802.15.4:

(15)

27 de abril de 2012

En la figura 13 se ha ilustrado el formato de los paquetes del protocolo inalámbrico P2P de MiWiTM. Los campos de bits son los siguientes:

1) Frame Control: son dos bytes de control de la trama:

a) Frame Type: hay tres tipos de trama con sus respectivos valores: Trama de datos = 001b.

Trama de confirmación = 010b. Trama de comando = 011b.

b) Security Enabled: este bit indica si el paquete en cuestión está encriptado. Si se habilita la seguridad, la cabecera tendrá campos adicionales como en el protocolo inalámbrico de pila de MiWiTM.

c) Frame Pending: este bit solo se usa en el paquete de confirmación que manejan los transceptores MRF24J40. Este bit indica si un paquete adicional seguirá a la confirmación después de recibir un paquete de petición de datos procedente de un dispositivo extremo RFD.

d) Intra PAN: este bit indica si el destino del paquete se encuentra en el mismo PAN que el origen. Si es el caso, se omitirá el campo Source PAN ID en los campos de direccionamiento. En la pila, este bit siempre está a 1, pero se puede poner a 0 para habilitar comunicación inter-PAN. Si es necesario, esta operación se puede realizar en la capa de aplicación.

e) Destination Address Mode: hay dos tipos de modo de dirección de destino: Modo de dirección corta (2 bytes) = 10b.

Modo de dirección larga (8 bytes) = 11b.

En el protocolo inalámbrico P2P de MiWiTM se suele escoger el modo de dirección larga. El modo de dirección corta se usa solo para emitir mensajes broadcast. Para este tipo de mensajes, el destino será siempre FFFFh.

f) Source Address Mode: tiene los mismos valores que el campo de modo de dirección de destino, pero el protocolo inalámbrico P2P de MiWiTM solo puede soportar el modo de dirección del origen largo (8 bytes).

2) Sequence Number: este número de secuencia de 1 byte empieza con un número aleatorio y lo incrementa en 1 cada vez que un paquete que no sea de confirmación sea enviado. El número de secuencia se usa en el paquete de confirmación para identificar el paquete original.

3) Destination PAN ID: es la identificación del PAN en el que se encuentra el destino del paquete. Si se desconoce esta identificación, o no se necesita, se puede emplear la identificación del PAN global, que es FFFFh.

4) Destination Address: esta dirección de destino puede ser de 2 o de 8 bytes. El tamaño se debe corresponder con los bits del modo de dirección en el campo del control de la trama (Destination Address Mode). Si se usa el modo de dirección corta, entonces éste será el global (FFFFh).

5) Source PAN ID: es la identificación del PAN en el que se encuentra el origen del paquete y debe concordar con el bit del Intra-PAN en el campo del control de la trama. Este campo tendrá valor si el Intra-PAN vale 0. Sin embargo, la pila reserva la capacidad de transmitir mensajes de manera Inter-PAN a la capa de aplicación. Si el mensaje se debe transmitir de esta manera, se usará el Source PAN ID.

6) Source Address: este campo está fijado para usar la dirección larga del origen del paquete.

7) Payload: es el contenido del paquete.

4.1.7. Transmisión y recepción

Hay dos maneras de transmitir un mensaje: de manera global (broadcast) y de manera individual (unicast).

(16)

27 de abril de 2012

Los mensajes broadcast tienen como destino todos los dispositivos a su alcance. El IEEE 802.15.4 define una dirección corta específica como la dirección de broadcast, pero no tiene esta definición para una dirección larga. Por ello, para los transceptores del IEEE 802.15.4, el único caso en el que la pila del protocolo P2P de MiWiTM usa una dirección corta. No existen paquetes de confirmación para los mensajes de tipo broadcast.

Los mensajes unicast tienen solo un destino y usan la dirección larga como dirección de destino. El protocolo P2P de MiWiTM requiere confirmación para todos los mensajes de tipo unicast. Si el dispositivo transmisor tiene al menos un dispositivo que desconecta su radio al estar ocioso (idle), el dispositivo transmisor guardará mensaje en una memoria RAM y esperará al dispositivo inactivo a activarse y pedir el mensaje. Esta manera de transmisión de datos se llama mensajería indirecta.

Si el dispositivo inactivo no recibe con éxito el mensaje indirecto, expirará y será descartado. Normalmente, el timeout de los mensajes indirectos necesita durar más que el periodo de inactividad del dispositivo.

En el protocolo P2P de MiWiTM, el dispositivo al cual se le ha enviado un mensaje será solamente notificado por la radio. Si este dispositivo tiene la radio desconectada, el dispositivo debe mandar un comando de petición de datos al otro extremo de la conexión (connection peer). Entonces, adquirirá el mensaje indirecto si es que lo hay.

4.2. Variaciónes en cuanto al handshake

Handshaking es una palabra inglesa que significa “apretón de manos”. Se trata de un proceso complejo de unirse a una red. Una de las mayores diferencias del protocolo P2P de MiWiTM con el estándar del IEEE 802.15.4 es el proceso del handshake. En la figura 14 se muestran los procesos de handshake del IEEE 802.15.4 y del protocolo P2P de MiWiTM:

Según el IEEE 802.15.4, lo primero que debe hacer un dispositivo al activarse es realizar un handshake con el resto del mundo. El proceso del handshake del IEEE 802.15.4 es el siguiente:

1) El dispositivo que busca conexión manda una petición de baliza (beacon request). 2) Todos los dispositivos capaces de conectar con otros le mandan una baliza.

3) El dispositivo inicial recoge todas las balizas que ha recibido durante un cierto periodo de tiempo y después decide qué baliza usar para establecer el handshake y manda un comando de petición de asociación.

4) Después de un tiempo predefinido, el dispositivo inicial manda un comando de petición de datos para recibir la respuesta de asociación desde el otro lado de la conexión.

(17)

27 de abril de 2012

5) El dispositivo del otro lado de la conexión manda una respuesta de asociación.

Un dispositivo solo puede unirse a un solo maestro, luego el handshaking inicial es en realidad el proceso de escoger un maestro. Escoger un maestro requiere: primero, enumerar los posibles maestros; y segundo, escoger el más adecuado como su maestro. Las tramas de baliza no usan la detección CSMA-CA antes de transmitir para cumplir con el requisito temporal del active scan, que es el proceso que realiza un dispositivo para recibir balizas. Por ello, es posible que lagunas tramas sean descartadas debido a la colisión de paquetes.

El protocolo P2P de MiWiTM se ha diseñado para simplicidad y conexiones directas en las topologías en estrella y P2P. Sin embargo, hay algunos requisitos del IEEE 802.15.4 que chocan con este diseño: primero, el proceso de cinco pasos del handshake más dos timeouts (esto requiere una pila más compleja); y segundo, el proceso de asociación usa conexión simple en vez del concepto de conexión múltiple de la topología P2P.

Debido a estas razones precedentes, el protocolo P2P de MiWiTM usa su propio proceso de handshaking como se muestra en la figura 14:

1) El dispositivo que busca conexión manda un comando de petición de conexión P2P. 2) Cualquier dispositivo al alcance de la radio contesta con un comando de respuesta de

conexión P2P que finaliza la conexión.

Este es un proceso de uno a varios que puede establecer conexiones múltiples cuando sea posible para establecer una topología P2P. Debido a que este proceso de handshaking usa un comando de la capa MAC, se aplica el CSMA-CA para cada transmisión para reducir la posibilidad de colisión de paquetes.

Los dispositivos extremos RFD pueden recibir el comando de petición de conexión de varios dispositivos extremos FFD, pero se pueden conectar a un solo FFD (mirar la topología P2P de la figura 12). Cuando un RFD escoge el FFD como su otro extremo de la conexión P2P, escoge el que primero haya contestado al comando de petición de conexión P2P, que suele ser el más adecuado.

4.3. Comandos MAC personalizados para el protocolo inalámbrico P2P de MiWi

TM

(18)

27 de abril de 2012

El protocolo P2P de MiWiTM amplia la funcionalidad del estándar del IEEE 802.15.4 usando comandos MAC personalizados para eliminar la conexión entre dos dispositivos. Estos comandos personalizados se han mostrado en la tabla 6:

1) P2P Connection Request: un dispositivo transmite este comando de manera broadcast, nada más encenderse, para establecer una conexión P2P con otros dispositivos. Esta petición también puede ser mandada de manera unicast a un solo dispositivo para establecer una conexión única. Este comando puede también comenzar un active scan para determinar qué dispositivos están disponibles en el entorno. El protocolo P2P de MiWiTM puede permitir o prohibir la conexión de otros dispositivos a uno en concreto. Si se prohíbe, cualquier P2P Connection Request que se reciba será descartado, excepto si este comando viene de un dispositivo que ya tiene un enlace P2P con otro, o si viene de un active scan. Es necesario especificar el canal de operación para evitar el efecto de subarmónicos que vengan de otro canal. Si este comando es solo por motivos de realizar un active scan se omitirá el byte Optional Payload, que aparecen en la figura 15:

2) P2P Connection Removal Request: este comando se envía al otro extremo para remover la conexión P2P. El formato de la trama se muestra en la figura 16:

3) Data Request: este comando es el mismo que se usa en el IEEE 802.15.4. Si un extremo del enlace P2P es capaz de dormir (sleep) al estar ocioso (idle), y ese nodo es capaz de recibir un mensaje dormido, el lado activo de la conexión debe almacenar el mensaje en su RAM, y debe entregar el mensaje cuando el dispositivo durmiente se despierta y pide el mensaje con este comando. El formato de la trama es el siguiente:

(19)

27 de abril de 2012

4) Channel Hopping: este comando pide a un dispositivo cambiarse su canal de operación a otro. Este comando tiene que ver con una característica que se llama agilidad de frecuencia (frequency agility). Este comando se suele enviar por el iniciador de agilidad de frecuencia, que decide cuándo cambiarse de canal y qué canal escoger. Este comando se suele mandar de manera broadcast para notificar a todos los dispositivos que se deben cambiar de canal. Para asegurar que todos los dispositivos reciben el mensaje, el iniciador de agilidad de frecuencia realizará el broadcast tres veces y los dispositivos FFD harán un re-broadcast. Cuando todos los FFDs se cambian a otro canal, los RFDs deben resincronizarse para restablecer la conexión P2P con sus respectivos FFDs. A continuación, en la figura 18, se muestra el formato de la trama:

5) P2P Connection Response: este comando se usa para contesar a un P2P Connection Request. Este comando se puede usar para establecer una conexión o para contestar a un active scan para identificarse como nodo activo en el entorno. Dependiendo del campo de Capability Information, se puede saber qué tipo de petición fue. Si la petición no se trataba de un active scan y una vez el nodo haya recibido la respuesta, se consigue establecer la conexión P2P. Ahora, los dos extremos del enlace pueden intercambiar paquetes. Si se trataba de un active scan, no se establece ninguna conexión con la respuesta. El formato de la trama se muestra en la figura 19:

6) P2P Connection Removal Response: este comando se usa para responder a un P2P Connection Removal Request. Notifica al otro lado del enlace P2P que el comando de petición de eliminación de conexión P2P se ha realizado pronto o si la conexión se ha eliminado con éxito. El formato de este comando se muestra en la figura 20:

Figura 17. Formato de la trama del comando de petición de datos

Figura 18. Formato de la trama del comando de salto de canal

(20)

27 de abril de 2012

4.4. Características únicas del protocolo inalámbrico de P2P de MiWi

TM

El protocolo inalámbrico P2P de MiWiTM soporta una funcionalidad reducida, punto a punto, conexión directa y una gran variedad de características especiales. Estas características pueden ser habilitadas o deshabilitadas, teniendo en cuenta las necesidades de la aplicación. Esta sección describe las características únicas del protocolo P2P de MiWiTM. Cada una de ellas se puede activar o desactivar en el archivo del proyecto ConfigApp.h:

1) Tamaño pequeño de programación: Para las aplicaciones que requieran mucha memoria de programa, se puede reducir el tamaño del código en más de 3Kbytes. 2) Soporte para dispositivos ociosos para desactivar la radio: Es vital reducir el

consumo de potencia, sobre todo para aquellos dispositivos que operan con baterías. Si el dispositivo no recibe nada durante un determinado tiempo, o un FFD se lo ordena, entonces el dispositivo apaga la radio hasta que ocurra algo, como por ejemplo un evento externo, o expiración de un temporizador predefinido.

3) Mensajería indirecta: esta característica va a la par con la característica anterior. La mensajería indirecta ya ha sido explicada en el apartado 4.1.7.

4) Características especiales de seguridad: esta característica es manejada en la capa MiMac (Microchip Wireless Media Access Controller). Esta capa se explicará en el apartado 5.

5) Active scan para encontrar coordinadores de PAN en cada canal: este escaneo determina los dispositivos que hay en el entorno. La información recoge:

a) El canal de operación del dispositivo

b) La intensidad de la señal del dispositivo en el PAN

c) El código del PAN para los transceptores del IEEE 802.15.4

La duración de este escaneo se puede ajustar si es necesario, pero hay que tener en cuenta que a menor duración se pueden perder balizas.

6) Energy scan para encontrar el canal con la menor cantidad de ruido: esto sirve para el coordinador del PAN, que debe establecer la red con la menor cantidad de ruido para mayor rendimeinto. La duración de este escaneo también se puede ajustar. 7) Agilidad de frecuencia (salto de canales): si las condiciones de operación en un

canal se vuelven desfavorables, esta característica permite cambiar el canal de operación en el que se encuentra el PAN. Si esta característica se implementa, los dispositivos afectados tienen un papel adicional:

a) Iniciador de agilidad de frecuencia: son los dispositivos que deciden si es necesario el salto de canal y a qué canal trasladarse. Solo puede ser un FFD, y estos deben tener activado el energy scan.

b) Seguidores de agilidad de frecuencia: pueden ser RFD o FFD. Cuando un iniciador le indica a un seguidor que debe saltar de canal, éste le sigue. Si las comunicaciones empiezan a fallar con los RFDs, éstos pueden resincronizarse para encontrar el PAN de nuevo.

Como ya se ha mencionado anteriormente, este trabajo no entra en detalles sobre la programación, pero para activar estas características es necesario añadir unas cuantas líneas de código en el archivo ConfigApp.h. Para más información, visitar la web de la nota de aplicación del protocolo P2P: http://ww1.microchip.com/downloads/en/appnotes/01204B.pdf. Para hacerse una idea de cómo puede un microprocesador manejar este protocolo una vez se le

programe el proyecto de código libre que proporciona Microchip en

(21)

27 de abril de 2012

http://www.microchip.com/MiWi, el microprocesador sigue un bucle que se puede explicar con el flujograma de la figura 21:

Una vez el usuario aprenda la programación que subyace en este bucle, el usuario ya puede usar esta solución que ofrece Microchip para las WPAN en varias aplicaciones como en la domótica.

5. Controlador MAC de

MiWiTM: MiMAC [8]

La función primaria de un protocolo de comunicación inalámbrica es transmitir o recibir información entre dos nodos. La capa de control de acceso al medio (MAC) proporciona el acceso básico de canal, funcionalidades de direccionamiento y transmisión/recepción de datos; encima de la capa física (PHY) que maneja estos datos que todavía no han sido procesados. En el modelo OSI, sirve como la capa de enlace (DLL). Debido a la gran variedad de las posibles implementaciones en la capa física, la capa MAC es la más baja para estandarizar en el software de los protocolos de comunicación.

Esta capa trabaja en conjunto con la capa de aplicación de Microchip: MiApp; que se explicará en el apartado 5. MiMAC y MiApp permiten a los desarrolladores de aplicaciones inalámbricas flexibilidad para escoger el transceptor y el protocolo inalámbrico que les convenga más; en cualquier fase del desarrollo del software. MiMAC estandariza las interfaces entre los protocolos inalámbricos de Microchip (explicados en los apartados 3 y 4) y lo transceptores de RF. También MiMAC permite intercambiar los distintos transceptores de Microchip entre sí cambiando pocas líneas de código en el proyecto. La figura 22 ilustra la harmonía que tienen estos interfaces. Hay tres capas de configuraciones: aplicación, protocolo y transceptor:

(22)

27 de abril de 2012

1) Configuraciones de la aplicación: estas configuraciones pueden cambiar entre dispositivos con la misma aplicación, teniendo en cuenta su diseño del hardware, su papel en la aplicación y/o red. Los desarrolladores de aplicaciones inalámbricas suelen realizar más configuraciones en la capa de aplicación.

2) Configuraciones del protocolo de pila: estas ajustan finamente el comportamiento del protocolo de pila. La mayoría de las configuraciones en el nivel de la pila son para configurar los periodos de tiempo de la pila, especificar el mecanismo del routing, etc. 3) Configuraciones del transceptor: definen la banda de frecuencia, la tasa de transmisión

de datos y otras características de radio-frecuencia del transceptor.

5.1 Perspectiva general del MiMAC

Esta capa consiste en tres partes importantes, que se relacionan bastante entre sí. Las primeras dos son definidas para los transceptores de Microchip que tienen poco soporte de hardware en la capa MAC. La última se define para todos los transceptores de Microchip.

1) Formato de trama del MiMAC: el formato de la trama define cómo aparece el paquete a través del aire. Este formato decide la capacidad y eficiencia de la especificación del MiMAC. Actúa como cimientos de las otras dos partes en la arquitectura del MiMAC. 2) Módulo de seguridad del MiMAC: como es relativamente fácil de interceptar

información que va por comunicación inalámbrica, se debe considerar la seguridad para varias aplicaciones. Este módulo ofrece un cifrado por bloques (block cipher) barato con alta seguridad; y define varios modos de seguridad para trabajar con el cifrado por bloques para diferentes requisitos de las aplicaciones.

3) Interfaz universal de programación del MiMAC: esta interfaz actúa como un driver entre todos los transceptores de Microchip y los protocolos inalámbricos de Microchip. Adapta cualquier transceptor a cualquier protocolo y viceversa.

5.2 Formato de la trama del MiMAC

Se ha diseñado el formato para simplificar la implementación de un sniffer; es posible tener sólo un sniffer (conectado a un ordenador) recogiendo paquetes de datos de varios transceptores. Como todos los paquetes tienen el mismo formato en la definición del formato de

(23)

27 de abril de 2012

la trama del MiMAC, la interpolación en la capa MiMAC es la misma entre todos los transceptores RF de Microchip.

Los criterios para evaluar el formato de la trama son su eficiencia y su capacidad. En comparación con el IEEE 802.15.4, el formato de la trama del MiMAC proporciona la misma capacidad con mayor eficiencia. Por ejemplo, una trama típica mínima del IEEE 802.15.4 es de 9 bytes, mientras que una trama de unicast del MiMAC puede ocupar solo 2 bytes.

El formato de la trama del MiMAC se ha mostrado en la figura 23. El formato de los transceptores de RF consiste de al menos dos partes en la capa superior; las capas PHY y MAC.

5.2.1 Capa física (PHY)

Esta capa se usa por el transceptor para sincronizar y asegurar la fiabilidad de la comunicación. Los bytes que lo componen son los siguientes:

1) Preamble se usa para sincronizar la comunicación. Su contenido y longitud varían para cada transceptor, y éstos se pueden configurar referenciándose al datasheet del transceptor correspondiente.

2) Start-of-Frame-Delimiter (SFD) se suele usar con Preamble para asegurar la sincronización de la comunicación. Se puede deshabilitar, pero no es recomendable. 3) Packet Length se utiliza para especificar la longitud de la trama MAC. Algunos transceptores tienen este modo para solo transmitir paquetes con una longitud fija. En este caso, éste campo se puede omitir; pero no se puede regular por el formato de la trama del MiMAC.

(24)

27 de abril de 2012

5.2.2 Capa física (MAC)

Se compone de tres subcapas, que son reguladas por el formato de la trama del MiMAC: la cabecra MAC, el contenido del MAC, y la comprobación de redundancia cíclica.

1) Cabecera MAC: ésta proporciona información crucial al receptor del paquete en cómo interpretar el paquete. Consiste de cinco subcampos:

a) Frame Control: se usa para interpretar la cabecera MAC y tiene ocho bits que controlan diferentes aspectos de la capa MAC:

 Packet Type: especifica cómo tratar el paquete, incluyendo su payload: 00b es un paquete de datos, y el MiMAC pasará el MAC payload a

la capa superior de protocolo o directamente en la aplicación. 01b es un paquete de comando, y este comando se especifica en el

campo del MAC Payload, y el MAC payload se pasará a la capa superior de protocolo con un flag indicando que es un comando. 10b es un paquete de confirmación, que depende del número de

secuencia para saber qué paquete se debe confirmar. El paquete de confirmación es manejado por el MiMAC.

11b es un tipo reservado para características avanzadas para algunos transceptores y protocolos de Microchip.

 Broadcast: especifica si la trama es broadcast (1b) o unicast (0b).  Security: determina si el MAC payload se ha codificado al transmitirse.  Repeat: especifica si el paquete necesita un repetidor para su reenvío.  Ack: determina si se espera un paquete de confirmación del receptor.  DstPrsnt: determina si la dirección del receptor está en la cabecera MAC. Si

no está, es porque el paquete es de broadcasting, de acknowledgement, o de destino inferido usando CRC (con la dirección propia del dispositivo receptor se calcula el CRC y no dará error si el paquete es para él).

 SrcPrsnt: especifica si la dirección del transmisor está en la cabecera MAC. b) Extra ctrl: esta información se requiere en algunos casos. Se compone de 3 partes:

 Ack Info: aparece si se requiere confirmación del paquete.

 Header Index y Payload Index: están presentes si se necesita proteger y autentificar el paquete. Estos campos los maneja la capa superior de protocolo para realizar operaciones de seguridad en la capa de seguridad. c) Sequence Number: se usa para identificar paquetes individuales que se transmiten.

Se inicia este número de manera aleatoria y se incrementa con cada transmisión. d) Destination Address: solo aparece si es unicast, y puede ser de dos a ocho bytes. e) Source Address: puede no aparecer si no se requiere, y puede ser de 2-8 bytes. 2) MAC Payload: es la información transmitida por los protocolos inalámbricos de

Microchip o por la capa de aplicación. Se puede interpretar la información de varias maneras, a elegir por el cliente. La interfaz de programación del MiMAC pasará directamente el payload sin modificaciones a las capa de protocolo inalámbrico de Microchip que se esté usando. Si la información está protegida, primero se desprotegerá por el módulo de seguridad del MiMAC. Esta información se separa de la cabecera y se almacena en un vector de bytes que es fácilmente accesible por el usuario.

3) MAC CRC: se usa para comprobar la integridad del paquete después de la transmisión. Algunos transceptores pueden generar o comprobar el CRC (hardware CRC). Para los que no pueden, se usa el software CRC. El software CRC se puede realizar de dos formas: loop-up (de bucle) o look-up table (comprobación con tabla). El primer método requiere un espacio de 600 bytes menos, pero el segundo tarca 3-4 veces menos.

(25)

27 de abril de 2012

5.3 Módulo de seguridad de MiMAC

Es necesario un módulo de seguridad para que los paquetes no los reciban dispositivos que no sean el destino deseado. Receptores que escuchan de manera no intencionada o intencionada pueden recibir el paquete y esto puede ser perjudicial para la aplicación. Por lo tanto, es necesario proteger el paquete. El módulo de seguridad del MiMAC ayuda a cumplir estos requisitos de seguridad de las maneras siguientes:

1) Si el hardware del transceptor soporta un módulo de seguridad, incluyendo cifrado y diferentes modos de seguridad, se recomienda usar el “motor” de seguridad (security engine) del hardware directamente, ya que ahorra bastante consumo. En este caso, la especificación de seguridad del MiMAC no se aplica.

2) Si el motor de seguridad del hardware proporciona solo el cifrado por bloques, pero no los modos de seguridad, se recomienda usar el cifrado de seguridad del hardware pero aplicando los modos de seguridad del software. Solo se aplicaría la especificación de modos de seguridad del MiMAC.

3) En el caso en el que el hardware no proporcione ninguna de las dos, la especificación de modos de seguridad y la especificación de cifrado de seguridad del MiMAC son aplicados.

Existen tres criterios para escoger el algoritmo de seguridad que se usa con MiMAC: 1) Evitar problemas de IP: los algoritmos de seguridad que hay disponibles son:

Data Encryption Standard (DES/TDES) Blowfish/Twofish

Serpent

Advanced Encryption Standard (AES)

Tiny Encryption Algorithm: familias TEA/XTEA/XXTEA

2) Seguridad barata: se conocen sus debilidades, por lo tanto no son tan demandadas: DES/TDES: generación previa de estándares de criptología.

Blowfish/Twofish, Serpent y AES: proporcionan más seguridad que el DES o el TDES, pero requieren mucho espacio para un sistema empotrado. 3) Alta capacidad de seguridad: no se conocen sus debilidades (excepto el TEA):

Familias TEA/XTEA/XXTEA: TEA es la implementación original que se publicó en 1994. Tiene una debilidad conocida en sus claves equivalentes. XTEA y XXTEA se diseñaron para tener más seguridad que el TEA. Como XXTEA requiere al menos 8 bytes de datos de codificación, se debe modificar el motor de seguridad si se usa.

Por lo tanto, se escoge el algoritmo XTEA para el motor de seguridad de la especificación de seguridad del MiMAC. No se va a entrar en detalle de cómo funciona este algoritmo. El algoritmo XTEA es público y se puede encontrar fácilmente en internet.

Finalmente, cabe destacar que el formato de un paquete protegido cambia con respecto al formato de un paquete no protegido. Aparte de especificar en la trama que se habilita la seguridad, también se debe añadir el modo de seguridad usado (y el MIC si procede) y el número de secuencia de la clave de seguridad.

5.4 Interfaz universal de programación del MiMAC

El último paso es estandarizar la interfaz del software de programación entre MiMAC y las capas superiores de protocolo de Microchip. Este apartado trata de la programación del

(26)

27 de abril de 2012

proyecto, por lo tanto, no se analizará. Si el lector sintiera curiosidad, puede consultar este apartado en la dirección: http://ww1.microchip.com/downloads/en/appnotes/01283A.pdf.

5. Interfaz de programa de aplicación de

MiWiTM: MiApp [9]

No es tarea fácil desarrollar una aplicación inalámbrica que sea de corto alcance, que tenga una tasa de transferencia de datos baja y que tenga un bajo consumo de potencia. Aparte de los diseños complejos de circuitos de radio-frecuencia, el proceso de desarrollo del firmware (programa que usa un dispositivo para funcionar) podría requerir a los desarrolladores que entendieran los detalles de los transceptores de RF, así como los distintos protocolos de comunicación inalámbrica.

La empresa Microchip ha desarrollado una manera para manejar estos elementos tan complejos y difíciles para que permita a los desarrolladores de aplicaciones inalámbricas se concentren menos en la comprensión de los protocolos y los transceptores inalámbricos para así poder dedicarle más tiempo a la aplicación que están desarrollando. Esto se ha conseguido mediante una interfaz de programación concisa y poderosa en la capa de aplicación: es el MiApp.

La especificación de MiApp define la interfaz de programación entre la capa de aplicación y los protocolos de comunicación inalámbrica de Microchip. Se implementa la interfaz de programación de MiApp de dos maneras: como parámetros de configuración definidas en el archivo de configuración, y como un grupo de llamadas a funciones de los protocolos de comunicación inalámbrica de Microchip. Cumpliendo con la especificación de MiApp, cualquier aplicación puede usar los protocolos de comunicación inalámbrica de Microchip. Se podría cambiar la topología de la red de P2P/estrella a topología de malla con pocos cambios; dependiendo de los requisitos de la aplicación.

La especificación de MiApp beneficia a los desarrolladores de varias maneras:

1) El desarrollador podrá concentrarse en su aplicación. Consideraciones sobre RF compleja o protocolos serán manejados de manera transparente por la interfaz de programación de MiApp.

2) La especificación de MiApp permite máxima flexibilidad para escoger sin esfuerzo un protocolo de comunicación en cualquier fase del desarrollo del software. Cualquier requisito de la aplicación que sea cambiar la capacidad de la red no suelen tener ningún impacto en el desarrollo de la aplicación.

3) MiApp usa la misma interfaz de control para los protocolos inalámbricos de Microchip. Una vez se esté familiar con MiApp, se puede aplicar ese conocimiento al desarrollo de otra aplicación, aunque requiera otras capacidades de red.

4) MiApp se comunica indirectamente con los transceptores de RF a través de la interfaz del MiMAC; comunicándose con los protocolos de Microchip. Debido a ello, MiApp permite a los desarrolladores de aplicaciones inalámbricas cambiarse de transceptor a través de MiMAC. Esta flexibilidad reduce el riesgo del desarrollo del proyecto de aplicación inalámbrica.

Una vez explicado por encima el papel de MiApp, ahora queda explicar la parte de programación, que por supuesto no se va a ver. Para más información consultar en el siguiente enlace: http://ww1.microchip.com/downloads/en/appnotes/01284A.pdf.

(27)

27 de abril de 2012

6. Conclusión

Hoy en día, Microchip sigue expandiendo MiWiTM: en el año 2011 desarrolló el protocolo de redes inalámbricas MiWiPRO. Este nuevo protocolo ofrece mayor capacidad de routing. Se pueden establecer hasta 64 coordinadores y los mensajes enviados pueden dar hasta 65 saltos (hops). Cada coordinador puede aceptar hasta 127 dispositivos extremos. Por lo tanto, MiWi PRO ha aumentado el número de nodos que puede tener un PAN hasta más de 8000. [10]

En definitiva, esta solución que ofrece Microchip Wireless (MiWiTM) está al alcance de todo el que necesite desarrollar una aplicación inalámbrica, sea para temas domóticos, industriales, e incluso militares. Es una manera barata y relativamente fácil de establecer una red inalámbrica que tenga una tasa de datos baja, un consumo de potencia bajo, y sea de corto alcance. Este código de proyecto libre, con sus interfaces, facilita bastante al usuario la comprensión del protocolo MiWiTM; y facilita la adaptación de este protocolo a una gran variedad de aplicaciones.

Referencias

[1] http://ww1.microchip.com/downloads/en/AppNotes/01204B.pdf : Y.Yang, Microchip Technology

Inc. – AN1066: Microchip MiWiTM P2P Wireless Protocol Application Note. Última consulta el 20/04/2012

[2] http://es.wikipedia.org/wiki/ZigBee: Wikipedia Última consulta el 20/04/2012

[3] http://www.microchip.com/miwi: Microchip Technology Inc. Última consulta el 20/04/2012

[4] http://www.youtube.com/watch?v=8uvQ9XVk6vE: video informativo presentado por Tyler Smith,

Manager de Marketing de dispositivos de radiofrecuencia de Microchip. Última consulta el 20/04/2012

[5] http://www.microchip.com/wwwproducts/Devices.aspx: Buscador de productos de Microchip

Technology Inc. Última consulta el 20/04/2012

[6] http://ww1.microchip.com/downloads/en/AppNotes/01066A.pdf

:

D. Flowers, Y. Yang, Microchip

Technology Inc. - AN1066: Microchip MiWiTM Wireless Networking Protocol Stack Application Note. Última consulta el 25/04/2012

[7] Véase [1]. Última consulta el 26/04/2012

[8] http://ww1.microchip.com/downloads/en/appnotes/01283A.pdf

:

Y.Yang, Microchip Technology Inc.

– AN1283: Microchip Wireless MiWiTM_{Media Access Controller - MiMAC Application Note. Última} consulta el 27/04/2012

[9] http://ww1.microchip.com/downloads/en/appnotes/01284A.pdf

:

Y.Yang, Microchip Technology Inc.

– AN1243: Microchip Wireless MiWiTM_{Application Programming Interface - MiApp Application Note.} Última consulta el 27/04/2012

[10]http://ww1.microchip.com/downloads/en/appnotes/01371A.pdf

:

Y.Yang, Microchip Technology

Inc. – AN1243: Microchip MiWiTM PRO Wireless Networking Protocol Application Note. Última consulta el 27/04/2012