trabajo de final de grado€¦ · trabajo de final de grado tÍtulo del tfg:estudio de las...

TRABAJO DE FINAL DE GRADO

TÍTULO DEL TFG:Estudio de las prestaciones de IEEE 802.15.4e TITULACIÓN: Grado en ingeniería Telemática AUTOR: Víctor Alcázar Alcázar DIRECTOR: Carles Gómez Montenegro FECHA: 5 de octubre del 2013

Título: Estudio de las prestaciones de IEEE 802.15.4e Autor: Víctor Alcázar Alcázar Director: Carles Gómez Montenegro Fecha: 5 de octubre del 2013

Resumen

Las redes de sensores han evolucionado mucho en los últimos años. Han emergido una gran cantidad de servicios en distintas áreas de aplicación: sensores ambientales, eficiencia energética, sensores industriales, automoción, domótica, etc. Un ejemplo de un pequeño abanico de servicios puede ser: monitorización de la temperatura en un bosque que permita alertar ante un posible riesgo de incendio, monitorización del consumo eléctrico de un edificio y que además optimice el consumo de la energía, control y gestión de máquinas dentro de una fábrica, acceso directo a elementos del propio hogar (luces, aire acondicionado, cerradura de puertas), etc. El IEEE ha definido el estándar 802.15.4e como un añadido de la capa MAC que incorpora varios modos de funcionamiento que son específicos para distintos escenarios en redes de sensores. El objetivo de este TFG es evaluar experimentalmente las prestaciones del modo de operación Time Slotted Channel Hopping (TSCH) de IEEE 802.15.4e, que permite solucionar problemas como el multipath fading. Para ello, se miden los parámetros: a) Packet Delivery Ratio (PDR) donde se espera obtener un resultado positivo gracias al channel hopping(las medidas se realizarán en tres escenarios distintos); b) la latencia, donde se verá cómo este parámetro varía en función de la distancia de los nodos y, de forma indirecta, del PDR; c)el throughput, donde se comprueba que el tamaño del slotframe es quien determina el valor máximo alcanzable, y por último el tiempo de sincronización entre dos nodos, donde se compara con el valor esperado teórico. En algunos de estos experimentos no se han obtenido resultados similares a lo que indica la teoría, incluso sin haber encontrado una explicación. Otros sin embargo sí que se han podido explicar o los resultados han sido similares a los esperados.

Title:Study of the performance of IEEE 802.15.4e

Author: Víctor Alcázar Alcázar

Director: Carles Gómez Montenegro

Date: October, 5th 2013

Overview

Sensor networks have evolved greatly in recent years. They have emerged a large number of services in a different applications areas: environment sensors, energy efficiency, industrial sensors, automotive, home automation, etc.. An example of a small variety of services can be: temperature monitoring in a forest that allows to alert a possible risk of fire, electrical consumption monitoring of a building and also optimizing its energy consumption, control and management of machines within a factory, direct access to elements of home (lights, air conditioning, lock doors, etc.). IEEE has defined the standard 802.15.4e as an added of the MAC layer that incorporates multiple operating modes which are specific for different scenarios in sensor networks. The aim of this project is to evaluate experimentally the the performane of the operating mode Time Slotted Channel Hopping (TSCH), which allows to solve the problem of multipath fading To do this, we will measure the following parameters: a) Packet Delivery Ratio (PDR) which is expected to get a positive result due to channel hopping (it will take place in three different scenarios); b) latency, which we will see how this parameter varies with the distance of the nodes and, indirectly, the PDR; c) the throughput where it is verified that the size of the slotframe is who sets the maximum value of it, and finally the synchronization time where it is compared with the theoretical expected value. In some of these experiments we have not obtained similar result according to the theory, even these anomalies have not been possible to be explained. Others nevertheless, have been explained, or the results have been similar to those expected.

ÍNDICE

CAPÍTULO 1. INTRODUCCIÓN ...................................................................... 1

CAPÍTULO 2. PROTOCOLOS PARA REDES DE SENSORES ..................... 2

2.1. 802.15.4 ............................................................................................................................... 2 2.1.1. Tipos de nodos ....................................................................................................... 2 2.1.2. Topologías .............................................................................................................. 2 2.1.3. Arquitectura de capas IEEE 802.15.4 .................................................................... 3

2.2. 802.15.4e ............................................................................................................................. 6 2.2.1. Modos de operación ............................................................................................... 6 2.2.2. Low Energy ............................................................................................................. 7 2.2.3. Formato de trama IEEE 802.15.4e ......................................................................... 8 2.2.4. Information Elements .............................................................................................. 9 2.2.5. Enhanced Beacon y Enhanced Beacon Requests................................................. 9 2.2.6. TSCH .................................................................................................................... 10 2.2.7. Sincronización ...................................................................................................... 15

2.3. Pila de protocolos basada en IP para redes de sensores ........................................... 16 2.3.1. Visión general ....................................................................................................... 16 2.3.2. Iniciativa 6TSCH ................................................................................................... 18

2.4. Otras pilas de protocolos ............................................................................................... 19

CAPÍTULO 3. ENTORNO HARDWARE Y SOFTWARE ............................... 22

3.1. Plataforma hardware ....................................................................................................... 22

3.2. Plataforma software ........................................................................................................ 23 3.2.1. OpenVisualizer ..................................................................................................... 23 3.2.2. uRes y 6TSCH ...................................................................................................... 24 3.2.3. Aplicaciones utilizadas ......................................................................................... 25

CAPÍTULO 4. EXPERIMENTOS Y RESULTADOS ...................................... 27

4.1. Packet Delivery Ratio (PDR) ........................................................................................... 27 4.1.1. Escenario 1: interior sin Line of Sight (NLoS) ...................................................... 27 4.1.2. Escenario 2: interior con Line of Sight (LoS) ........................................................ 32 4.1.3. Escenario 3: exterior con Line of Sight (LoS) ....................................................... 34

4.2. Latencia ............................................................................................................................ 37 4.2.1. Escenario 1: interior sin Line of Sight (NLoS) ...................................................... 38 4.2.2. Escenario 2: interior con Line of Sight (LoS) ........................................................ 38 4.2.3. Escenario 3: exterior con Line of Sight (LoS) ....................................................... 39

4.3. Throughput ....................................................................................................................... 40

4.4. Tiempo de sincronización .............................................................................................. 44

CAPÍTULO 5. CONCLUSIONES ................................................................... 49

GLOSARIO ...................................................................................................... 50

REFERENCIAS ................................................................................................ 52

ANEXOS .......................................................................................................... 53

TABLAS Tabla 1 Comandos utilizados en la capa 6top [5] ............................................. 18 Tabla 2 Distintos estados de un timeslot [5] ..................................................... 19 Tabla 3 PDR obtenido para el modo sin TSCH y con TSCH ............................ 29

Tabla 4 PDR específico para cada punto, con 3 retransmisiones. ................... 34 Tabla 5 PDR con 3 retransmisiones para los distintos puntos ......................... 36 Tabla 6 Tabla donde se muestra la latencia en el primer escenario, sin

retransmisiones. ........................................................................................ 38 Tabla 7 Latencia para el primer escenario, interior sin LoS, con 3

retransmisiones. ........................................................................................ 38 Tabla 8 Latencia para el escenario interior con LoS, sin retransmisiones. ....... 39 Tabla 9 Tabla con la latencia para el caso del segundo escenario con 3

retransmisiones. ........................................................................................ 39 Tabla 10 Latencia para el último escenario, exterior con LoS y con 3

retransmisiones. ........................................................................................ 40 Tabla 11 Resultados obtenidos de la prueba de tiempo de sincronización ...... 45

Tabla 12 Tiempos de sincronización superiores al tiempo máximo de sincronización. .......................................................................................... 48

Tabla 13 Aplicaciones utilizadas en las implementaciones del proyecto .......... 57

FIGURAS Fig. 1 Ejemplo de topologías de red [2] .............................................................. 3

Fig. 2 Arquitectura de red de un dispositivo IEEE 802.15.4 [2] .......................... 4 Fig. 3 Características principales de IEEE 802.15.4-2003 ................................. 4

Fig. 4 Características principales de 802.15.4-2006 .......................................... 5 Fig. 5 Estructura de supertrama [2] .................................................................... 6 Fig. 6 Funcionamiento del mecanismo CLS [3] .................................................. 7

Fig. 7 Funcionamiento del mecanismo RIT [3] ................................................... 8 Fig. 8 Estructura de la trama IEEE 802.15.4e [3] ............................................... 8

Fig. 9Formato de cabecera de los IEs [3] ........................................................... 9 Fig. 10 Formato de trama de un Enhanced Beacon (EB) ................................. 10 Fig. 11 Slotframe de TSCH que utiliza 3 timeslots ........................................... 11

Fig. 12 Estructura de slotframe. En un timeslot pueden haber varias transmisiones en distintos canales. ........................................................... 12

Fig. 13 Organización del timeslot [4] ................................................................ 13

Fig. 14 IE utilizado para sincronizarse con el modo TSCH .............................. 14

Fig. 15 IE con información de tiempo utilizado en tramas ACK/NACK ............. 14 Fig. 16 Este IE contiene información del número de slotframes de la red ........ 14 Fig. 17 IE con contenido de cada uno de los slotframes. ................................. 15

Fig. 18 IE con información del enlace .............................................................. 15 Fig. 19 IE con información del timeslot ............................................................. 15

Fig. 20 Pila de protocolos basada en IP para redes de sensores .................... 17 Fig. 21 Pila de protocolos ZigBee ..................................................................... 20 Fig. 22 Pila de protocolos de BLE [13] ............................................................. 21 Fig. 23Componentes del nodo sensor TelosB [1] ............................................. 22

Fig. 24 Interfaz OpenVisualizer ........................................................................ 24

Fig. 25 Distintas formas de establecer un enlace mediante uRes [4] ............... 25 Fig. 26 Escenario utilizado para esta primera prueba de PDR. En este

escenario se encuentran muchas paredes y los nodos no tienen LoS en la mayoría de los puntos. Además, hay interferencias WiFi ya que existe un router con interfaz WiFi activada en el mismo escenario. ......................... 28

Fig. 27 PDR medido. En azul se muestra los valores obtenidos sin utilizar el modo channel hopping. En rojo se muestran los valores utilizando channel hopping. .................................................................................................... 28

Fig. 28 PDR en el escenario dentro de casa con 3 retransmisiones. En rojo se ve el gráfico con el modo TSCH y en azul sin TSCH. ............................... 30

Fig. 29 PDR en el escenario interior sin LoS. En azul se indica el PDR para el caso que hay retransmisiones y el modo TSCH activado. En rojo, retransmisiones sin TSCH. En verde se muestran los resultados de las pruebas sin retransmisiones usando TSCH y por último, en lila, se representan los resultados sin retransmisiones y sin el modo TSCH. ...... 31

Fig. 30 Escenario utilizado para las pruebas de PDR en interior teniendo LoS 32 Fig. 31 PDR obtenido en el escenario interior con LoS. En verde se muestra la

curva sin utilizar channel hopping con 0 retransmisiones. En lila se muestra el PDR con channel hopping y con 3 retransmisiones. En rojo y azul se muestran las curvas sin utilizar retransmisiones y con el modo sin channel hopping y con, respectivamente. ............................................................... 33

Fig. 32 Escenario exterior con LoS ................................................................. 35 Fig. 33 PDR en el escenario exterior con LoS. En azul se muestra el modo sin

channel hopping y en rojo con channel hopping. Se han utilizado 3 retransmisiones. ........................................................................................ 36

Fig. 34 Estructura del schedule que los nodos emplearán. El tamaño del slotframe es de 9 timeslots. ....................................................................... 40

Fig. 35 Throughput medido en función del tiempo entre envío de paquetes. ... 41 Fig. 36 Throughput teórico. .............................................................................. 41 Fig. 37 Throughput medido y teórico ................................................................ 42

Fig. 38 Schedule de los nodos. El tamaño del slotframe es 5 .......................... 42

Fig. 39 Throughput medido, considerando tiempos entre de envío de paquetes desde 60 ms hasta 135ms ........................................................................ 43

Fig. 40 Schedule utilizado para poner a prueba el tiempo de sincronización. .. 44 Fig. 41 Gráfica tiempo de sincronización en función del tiempo entre envío de

tramas ADV ............................................................................................... 46

Fig. 42 Tiempo sincronización teórico comparado con el tiempo de sincronización medido anteriormente ........................................................ 47

Fig. 43Los puertos COM6 y COM7 hacen referencia a dos nodos TelosB conectados por USB al PC ........................................................................ 54

Fig. 44 Mensajes de consola al compilar el firmware en un nodo .................... 55 Fig. 45 OpenVisualizer. En la pestaña de motes se pueden ver los nodos que

están conectado mediante un puerto COM ............................................... 56

Fig. 46 OpenVisualizer. Información para cada uno de los nodos ................... 56 Fig. 47 En la izquierda: el nodo sensor de la izquierda actúa como DAGroot,

está sincronizado, sin embargo el nodo de la derecha aún no se ha sincronizado. En la derecha: el nodo de la derecha a pasado a estar sincronizado, ambos tienen el led azul ..................................................... 57

Introducción 1

CAPÍTULO 1. INTRODUCCIÓN Las redes de sensores han evolucionado mucho en los últimos años. Han emergido una gran cantidad de servicios en distintas áreas de aplicación: sensores ambientales, eficiencia energética, sensores industriales, automoción, domótica, etc. Un ejemplo de un pequeño abanico de servicios puede ser: monitorización de la temperatura en un bosque que permita alertar ante un posible riesgo de incendio, monitorización del consumo eléctrico de un edificio y que además optimice el consumo de la energía, control y gestión de máquinas dentro de una fábrica, acceso directo a elementos del propio hogar (luces, aire acondicionado, cerradura de puertas), etc. El protocolo IEEE 802.15.4 define la capa física (PHY) y control de acceso al medio (MAC) de una interfaz radio de bajo consumo. Es el estándar más reconocido por la industria y tiene buena aceptación debido a que proporciona mecanismos de eficiencia energética, ciclos de trabajo bajos, estructura de supertrama con espacios de tiempo garantizados para las transmisiones (GTS), etc. Aún así hay algunos problemas como por ejemplo el modo de operación en un único canal. Este problema es realmente importante si el área de aplicación es la industria, la automoción o cualquier otro lugar donde fenómenos que pueden afectar selectivamente a algunas bandas estrechas de frecuencia como el multipathfading pueda afectar notablemente a las transmisiones. El objetivo de este TFG es evaluar experimentalmente las prestaciones del modo de operación Time Slotted Channel Hopping (TSCH) de IEEE 802.15.4e, que permite solucionar problemas como el multipath fading. En concreto, se quiere medir los parámetros PDR (Packet Delivery Ratio), throughput, latencia y tiempo de sincronización. La organización del trabajo se puede dividir en dos partes: una teórica y otra práctica. En la primera parte se detallan aspectos teóricos sobre los protocolos utilizados (CAPÍTULO 2) en el proyecto, donde se hablará básicamente del protocolo IEEE 802.15.4, IEEE 802.15.4e y protocolos basados en IP para redes de sensores. También se detalla información sobre la plataforma hardware y software utilizada (CAPÍTULO 3). En la segunda parte del trabajo se exponen los resultados de los experimentos realizados para evaluar los objetivos (CAPÍTULO 4). Para finalizar, el último capítulo recoge las conclusiones del trabajo. El documento también incluye un apartado de anexos en el que se muestra información adicional, relacionada con el proyecto, como por ejemplo cómo se ha instalado y puesto en marcha el entorno a estudiar y qué archivos se han modificado para los distintos estudios.

2 Estudio de las prestaciones de IEEE 802.15.4e

CAPÍTULO 2. PROTOCOLOS PARA REDES DE SENSORES

En este capítulo se detallarán los protocolos utilizados en redes de sensores, empezando por el IEEE 802.15.4 y 802.15.4e, que definen la capa física y MAC de un estándar de comunicaciones inalámbricas de bajo consumo, empleado en redes de sensores. Posteriormente se hablará sobre la pila de protocolos basada en IP para redes de sensores donde se hablará sobre la capa IP, transporte y aplicación. Finalmente se dará una breve explicación sobre otras pilas de protocolos existentes.

2.1. 802.15.4 El estándar IEEE 802.15.4 define el nivel físico y el control de acceso al medio de una interfaz de bajo consumo. Desarrollado por el IEEE, está principalmente diseñado para redes LR-WPAN (Low-Rate Wireless Personal Area Network) debido a que el volumen de datos por unidad de tiempo que suelen generar los dispositivos de una red de sensores es muy bajo comparado con otras redes, como por ejemplo redes con tecnología IEEE 802.11. Lo habitual es encontrarse con transmisiones poco frecuentes, y de baja cantidad de datos. El principal objetivo de este estándar es lograr un bajo consumo ya que alguno de los dispositivos que usan esta tecnología se alimentan con una batería o mediante otras fuentes de energía limitadas, por lo tanto es necesario el bajo consumo para garantizar un alto tiempo de vida del nodo.

2.1.1. Tipos de nodos El estándar IEEE 802.15.4 define dos tipos de nodos, Full Function Device (FFD) y Reduced Function Device (RFD). Los FFD son dispositivos con la capacidad de desempeñar todos los roles que define el estándar. Se trata de tres roles distintos: dispositivo final (device), coordinadores de otros nodos de menor capacidad (coordinator) y coordinadores de toda una red PAN1 (PAN coordinator). Los RFD son dispositivos de menor capacidad a nivel de hardware y/o software que los FFD. En una red sólo pueden actuar como devices debido a sus limitadas prestaciones. En la práctica, en muchos despliegues no existe una distinción entre nodos FFD y RFD, Sin embargo, se suele diseñar la red de sensores de forma que algunos nodos se comportan de forma similar a un RFD, mientras que otros realizan tareas que pueden atribuirse a un FFD.

2.1.2. Topologías

1 Personal Area Network

Protocolos para redes de sensores 3

En función de los requisitos de una aplicación, se definen dos topologías de red: topología en estrella o topología peer-to-peer.

Fig. 1 Ejemplo de topologías de red [2]

La topología en estrella se basa en que un dispositivo FFD actúa como coordinador de todos los dispositivos de la red, es decir, actúa como PAN Coordinator (PANC). La comunicación siempre es directa desde el device hasta el PANC o viceversa. Normalmente el PANC está alimentado mediante la red eléctrica ya que siempre está operativo, mientras que los devices usan baterías. Algunos ejemplos de escenarios con esta topología se pueden ver en domótica, eHealth, etc. La topología peer-to-peer permite formar redes más complejas, como por ejemplo, redes con topología mesh. En este escenario también hay un PANC pero ahora los devices pueden estar conectados a otros devices, no necesariamente al PANC tal y como ocurría en la topología en estrella. Para formar este tipo de red se necesita un protocolo de encaminamiento ya que las comunicaciones pueden requerir realizar más de un salto (comunicaciones multihop) entre origen y destino. Estas topologías se pueden ver en escenarios de monitorización industrial, seguridad, smart cities, etc.

2.1.3. Arquitectura de capas IEEE 802.15.4 Tal y como se ha mencionado anteriormente, el estándar IEEE 802.15.4 define dos capas: la física y la MAC. En la Fig. 2 se muestra la arquitectura de capas de un dispositivo con 802.15.4. En esta arquitectura, tanto en la capa física como en la capa MAC, se utilizan las funcionalidades definidas por IEEE 802.15.4. Por encima de la capa MAC, se encuentran dos capas de adaptación: Service-Specific Convergence Sublayer y Logical Link Control (SSCS y LLC, respectivamente). Sin embargo, las capas superiores pueden acceder directamente a los servicios de la capa MAC de IEEE 802.15.4. En este documento se hablará de las capas superiores en el CAPÍTULO 2.


Fig. 2 Arquitectura de red de un dispositivo IEEE 802.15.4 [2]

2.1.3.1. Capa física (PHY) Existen dos versiones principales para la capa física de IEEE 802.15.4: IEEE 802.15.4-2003 y IEEE 802.15.4-2006. En la siguientes figuras se muestra las especificaciones de cada una de ellas.

Fig. 3 Características principales de IEEE 802.15.4-2003

Tal y como se puede apreciar en la Fig. 3, existen 3 bandas de frecuencias para la versión IEEE 802.15.4-2003 del estándar: 868 MHz, 915 MHz y 2.4 GHz. El número de canales es 1, 10 y 16 respectivamente. Para el caso de 2.4 GHz los canales son de 2 MHz con una separación de 5 MHz para minimizar interferencias entre canales adyacentes. Además, dado que la banda de 2.4 GHz es una banda libre, también es la más utilizada y es la banda en la que se realizarán los experimentos del proyecto. El estándar también ofrece mecanismos de ensanchado de espectro para las transmisiones. En este caso, se utiliza Direct Sequence Spread Spectrum (DSSS). Es importante utilizar el ensanchado de espectro para poder filtrar interferencias a pesar de tener una mayor ineficiencia del ancho de banda. La modulación es BPSK para las dos primeras bandas y O-QPSK para la banda de 2.4 GHz. Por último, la tasa de bit a nivel físico (bitrate) es de 20 kbps


para la banda de 868MHz, 40kbps para 915MHz y 250kbps para la banda de 2.4GHz.

Fig. 4 Características principales de 802.15.4-2006

En la versión IEEE 802.15.4-2006 (Fig. 4) no se definen capas físicas en la banda de 2.4 GHz. Para las otras bandas (868 MHz y 915 MHz) se utilizan distintas técnicas de ensanchado de espectro: Parallel Sequence Spread Spectrum (PSSS) y la ya conocida DSSS. Cada una de las dos bandas mencionadas define dos modulaciones: ASK u O-QPSK. Para el caso de la banda de 915 MHz el bitrate es 250 kbps con ambas modulaciones. Para la banda de 868 MHz el bitrate varía entre 250 kbps con la modulación ASK y 100 kbps con la modulacion O-QPSK. 2.1.3.2. Capa de control de acceso al medio (MAC) La capa MAC ofrece servicio a partir de dos interfaces: el MAC Management Service (o MAC Layer Management Entity, MLME) y el MAC Data Service (o MAC Common Part Layer, MCPS). Las funciones básicas de la capa MAC de IEEE 802.15.4 son la gestión del acceso al medio, la fiabilidad mediante el uso de ACKs, la asociación y la seguridad. El uso de ACKs es opcional debido a que hay aplicaciones que no necesariamente requieren confirmación o por motivos de eficiencia energética, ya que el uso de ACKs implica un mayor tiempo de encendido de las radios. El acceso al medio puede ser con o sin beacons. Si no se utilizan beacons el mecanismo de acceso al medio es CSMA/CA. Se trata de un mecanismo de acceso al medio sencillo donde los nodos no guardan información sobre el estado de otros nodos de la red. Sin embargo, si se utilizan beacons, existe una sincronización entre todos los nodos de la red. De hecho, deben seguir una estructura de supertrama (superframe), que incluye intervalos que requieren usar mecanismos de acceso al medio como CSMA/CA ranurado o TDMA mediante el empleo de Guaranteed Time Slots (GTS). En la Fig. 5 se muestra un ejemplo de estructura de supertrama. La supertrama está delimitada por tramas de tipo beacon que son enviadas por el PANC y que contienen información para los nodos que quieran sincronizarse con la red. Básicamente, la supertrama consta de 3 partes: el Contention Access Period (CAP), el Contention Free Period (CFP) y un periodo inactivo.


El CAP define el intervalo de tiempo durante el cual los nodos competirán para transmitir en slots usando el protocolo CSMA/CA. El CFP define el periodo durante el cual se ofrecen slots garantizados para nodos que requieran una transmisión con latencia limitada. Es decir, durante este periodo no se utiliza CSMA/CA ya que los slots están pre-asignados. Durante el periodo inactivo ningún nodo puede transmitir. Todos los nodos entran en un estado de bajo consumo (sleep). La supertrama vuelve a repetirse al siguiente envío de un beacon, y así, sucesivamente.

Fig. 5 Estructura de supertrama [2]

2.2. 802.15.4e El Task Group (TG4) de IEEE 802.15 ha desarrollado una mejora de la especificación MAC de IEEE 802.15.4. Se trata del nuevo estándar IEEE 802.15.4e, publicado en abril del 2012, que está enfocado a dar soporte a mercados industriales. En esta sección se hablará de los cambios más importantes que aporta este nuevo estándar.

2.2.1. Modos de operación El estándar IEEE 802.15.4e incorpora nuevos modos de operación: Deterministic & Synchronous Multi-channel Extension (DSME), Low Latency Deterministic Network (LLDN), Time Slotted Channel Hopping (TSCH), Radio Frequency Identification Blink (RFID Blink) y Asynchronous Multi-Channel Adaption (AMCA). Cada uno de estos modos de operación ofrece un servicio muy específico que beneficia a las distintas aplicaciones de la red. Por ejemplo, el DSME está


diseñado para aplicaciones cuyos requisitos son alta disponibilidad, eficiencia, escalabilidad y robustez. El modo LLDN está desarrollado para aplicaciones que requieran muy poca latencia: robots, grúas, etc. El modo TSCH se enfoca principalmente para entornos industriales. Este es el modo de funcionamiento que se evaluará mediante experimentos en el proyecto. El modo RFID Blink se usa para la comunicación con dispositivos a partir de un identificador que cada uno posee. Se utiliza para aplicaciones de identificación de objetos o personas, localización o seguimiento de los mismos. Por último, el modo de funcionamiento AMCA se utiliza en redes de gran tamaño y dispersión geográfica tales como las redes para smart utility, redes de monitorización de infraestructuras y redes de control de proceso.

2.2.2. Low Energy El estándar IEEE 802.15.4e define el protocolo Low Energy (LE) que permite a los dispositivos operar bajo un duty cycle de la fracción del 1%. Este protocolo incorpora dos mecanismos que garantizan un menor consumo de energía. Estos mecanismos son Coordinated Sampled Listening (CSL) y Receiver Initiated Transmissions (RIT). CSL es un mecanismo de ahorro de energía que consiste en que el receptor periódicamente escucha el canal y comprueba si hay alguna transmisión pendiente. Si durante la escucha recibe una trama wakeup con su misma dirección MAC, el mecanismo desactiva el receptor durante un tiempo Rendezvouz (RZTime), valor que está incluido en la trama wakeup. Este RZTime indica el tiempo entre el final de la trama wakeup y el principio de la trama de datos, por lo que el receptor sabrá exactamente cuándo despertarse para empezar a recibir los datos del emisor.

Fig. 6 Funcionamiento del mecanismo CLS [3]


El mecanismo RIT se usa en PANs que no utilizan beacons. Se basa en enviar tramas datareq de forma periódica utilizando CSMA/CA sin ranurar. Cada vez que envía una de estas tramas, escucha posteriormente el canal durante un tiempo corto para recibir transmisiones. El emisor espera a recibir una trama datareq para empezar a transmitir inmediatamente una trama de datos.

Fig. 7 Funcionamiento del mecanismo RIT [3]

2.2.3. Formato de trama IEEE 802.15.4e La Fig. 8 muestra la estructura de la trama IEEE 802.15.4e. Ésta se divide en tres partes: MAC Header (MHR), MAC Payload o MAC Service Data Unit (MSDU) y MAC Footer (MFR).

Fig. 8 Estructura de la trama IEEE 802.15.4e [3]

En el MHR existen distintos campos: Frame Control, encargado de especificar el tipo de trama; Sequence Number, para especificar un número único a la trama y Adressing fields, un conjunto de campos que especifican el identificador destino de la PAN, la dirección destino, el identificador origen de la PAN y la dirección de origen. A continuación hay un campo opcional usado para la seguridad y, finalmente, se encuentran las cabeceras de los Information Elements (IEs) que serán descritos posteriormente.


En el MSDU, o sea el MAC Payload, se transporta el payload de los IEs y el payload propio de la trama. Para acabar, la trama contiene dos octetos para el FCS con el que se verifica la integridad de los datos recibidos. La novedad con respecto al formato de trama que aparece en 802.15.4e son los campos variables de IEs, que anteriormente no existían. En el siguiente apartado se detallará este componente.

2.2.4. Information Elements IEEE 802.15.4e define los Information Elements (IEs) como métodos de encapsulación de información. El formato general de un IE contiene un campo identificador (ID), un campo de longitud y un campo de contenido. Los IEs proporcionan contenedores flexibles de información que son utilizados par encapsular información relacionada con la sincronización, estado de la red, etc. Tal y como se ha visto en el apartado anterior, los IEs se encapsulan dentro de las tramas IEEE 802.15.4e, con su parte de cabecera en la MHR, y su parte de payload en el MAC Payload. En la cabecera de la trama 802.15.4 se encuentra la cabecera de los IEs. Esta cabecera tiene la siguiente estructura (Fig. 9):

Fig. 9Formato de cabecera de los IEs [3]

La cabecera tiene un campo para indicar la longitud del campo de contenido, un identificador único y un campo type que permite identificar el tipo de IE. El contenido de un IE es muy variable, cada modo de funcionamiento (DSME, TSCH, LLDN, etc.) o funcionalidades (CSL, RIT, fiabilidad con ACKs, beacons, etc.) tiene definidos unos IEs específicos. Estas estructuras de IE se detallarán en los siguientes apartados.

2.2.5. Enhanced Beacon y Enhanced Beacon Requests Los Enhanced Beacon (EB) son extensiones basadas en IEEE 802.11 que proporcionan una mayor flexibilidad en contenido que los beacons del estándar IEEE 802.15.4. El campo de versión de la trama permite diferenciar un beacon de un EB, si este campo tiene el valor "0b10" entonces se trata de un EB. De igual manera, los Enhanced Beacon Request (EBR) se diferencian del comando beacon request de MAC a partir del campo versión. Éstos se utilizan para solicitar un EB y permiten especificar ciertos filtros en la respuesta, de tal


manera que sólo se envíe en el EB la información solicitada por el EBR. De este modo, se reduce el tamaño de la trama enviada. Las extensiones presentadas se usan en los modos de funcionamiento DSME y TSCH y su contenido está formado a partir de IEs. En la Fig. 10 se muestra el formato de trama de un EB. Como señala la Fig. 10, el MHR contiene un campo específico para IEs y en el MAC Payload un campo de datos para el payload de los IEs.

Fig. 10 Formato de trama de un Enhanced Beacon (EB)

2.2.6. TSCH El modo de funcionamiento Time Slotted Channel Hopping (TSCH) utiliza comunicaciones sincronizadas en el tiempo y con saltos de canal para proporcionar a la red robustez frente a fenómenos espectrales como el multipath fading. Este fenómeno puede resultar muy grave ya que puede llegar a destruir por completo las señales en el receptor. Además, TSCH divide el tiempo en slots de uso predefinido, lo cual garantiza transmisiones sin colisiones, con lo que puede incrementar el throughput de las comunicaciones. TSCH puede ser utilizado independientemente de la topología de la red. Funciona tanto en una red en estrella como en una topología peer-to-peer. Este modo de funcionamiento se basa en una estructura de slotframe (supertrama). El slotframe contiene un conjunto de timeslots que se repite en el tiempo. Cada timeslot tiene una duración suficiente como para que un emisor envíe una trama de máximo tamaño y que el receptor pueda enviar un ACK. El número total de timeslots del slotframe determina la longitud del mismo. Una vez finaliza el slotframe, esta estructura se repite y por lo tanto también lo hacen los timeslots.


Fig. 11 Slotframe de TSCH que utiliza 3 timeslots

La Fig. 11 ilustra un slotframe con 3 timeslots (TS0, TS1 y TS2). En cada timeslot hay asignada una transmisión (A->B, B->C, etc.). La configuración del slotframe y timeslots viene dada por una capa superior. Un atributo de los timeslots es el Absolute Slot Number (ASN), es un número que se incrementa en cada timeslot.A pesar de que el slotframe se repita el ASN siempre se incrementa. Este valor determina el número total de timeslots que han transcurrido desde que la red se puso en marcha o desde un tiempo arbitrario determinado por el PANC. Los nodos deben sincronizarse con la estructura de slotframe de la red. Si no están sincronizados con el resto de la red no podrán comunicarse con otros nodos. Cada uno de los nodos sigue un schedule el cual le indica qué debe hacer en cada timeslot (sus posibilidades son transmitir datos, recibir datos o dormir). En un timeslot en el que el nodo deba permanecer dormido (sleep) no será necesario encender ninguna interfaz radio, esto conlleva un gran ahorro de energía ya que el uso de las interfaces radio en modo de transmisión o recepción representa el mayor consumo del nodo. En los timeslots activos, el schedule indica de qué nodo vecino debe un nodo recibir los datos o transmitir, y en qué canal. Cuando un protocolo de capa superior de un nodo genera un paquete, este se pasa a la capa MAC del dispositivo, donde se guarda el paquete en una cola para ser transmitido. En cada timeslot de transmisión la capa MAC comprueba si tiene algún paquete en la cola de transmisión para algún nodo vecino en ese preciso timeslot. En tal caso, la capa transmite el paquete. En caso opuesto, el nodo permanece dormido sin encender sus interfaces radio. En cada slot de recepción el nodo enciende su radio antes del tiempo esperado de llegada del paquete. Una vez comprobado que el paquete tiene como destinatario el mismo nodo receptor, se envía un ACK al emisor y se apaga la interfaz radio. Por último se envía el paquete a la capa superior correspondiente para que sea procesado. En la Fig. 12 se muestra de nuevo la estructura del slotframe, pero esta vez se representan los distintos canales en cada slot. El slotframe no sólo está dividido


en el tiempo sino que también se divide en frecuencia, con lo que las transmisiones ocurren en distintos canales (channel hopping).

Fig. 12 Estructura de slotframe. En un timeslot pueden haber varias transmisiones en distintos canales.

Además, es posible que un dispositivo tenga varias interfaces radio y que en un mismo canal pueda transmitir en uno o más offsets (es decir, canales). Este es el caso de las tres casillas marcadas en rojo en la Fig. 12: hacen referencia a un mismo slot en el que se producen tres transmisiones en distintos offsets de canal. También es posible que, dentro del slotframe, el dispositivo tenga varios timeslots (con sus channel offset correspondientes) para transmitir. Este caso se ha pintado en gris en la figura anterior y se conoce como asignación de bloques de timeslot y offset. Por último, si el dispositivo sólo tiene una interfaz radio sólo podrá realizar una transmisión en el mismo timeslot, pero es posible que dentro del slotframe se le conceda más de un timeslot, como es el caso de las casillas en azul. El cálculo del canal en el que se debe transmitir o recibir se realiza a partir de la siguiente fórmula:

𝑐𝑎𝑛𝑎𝑙 = 𝐴𝑆𝑁 + 𝑐ℎ𝑎𝑛𝑛𝑒𝑙 𝑂𝑓𝑓𝑠𝑒𝑡 %16 (1) El canal es un valor entre 0 y 15 que se calcula a partir de la suma del ASN y del channel Offset. El rango entre 0 y 15 es debido a que los canales en la banda de 2.4GHz son de 2MHz con una separación de 5MHz, esto supone una cantidad de 16 canales útiles en esta banda. 2.2.6.1. Estructura de un timeslot


Como se ha indicado anteriormente, el slotframe es un grupo de timeslots. Cada uno de estos timeslots tiene una estructura definida. En la siguiente figura se muestra esta estructura (Fig. 13):

Fig. 13 Organización del timeslot [4]

Durante el tiempo en un timeslot, normalmente un nodo transmisor envía una trama y el receptor envía un ACK si la recibe correctamente. En la figura se muestra que antes de una transmisión hay un tiempo de offset donde el nodo se prepara para la transmisión y recepción de los datos. Durante este periodo se configura la interfaz radio para configurar el canal de transmisión y posteriormente se activa esta interfaz. Una vez las radios están listas, el receptor empieza la escucha en el canal antes de que el emisor comience a transmitir los datos. Una vez se ha acabado la transmisión, el emisor espera un tiempo para recibir el ACK. Durante este tiempo debe cambiar la interfaz a modo de escucha y lo hace antes de que el receptor haya empezado a transmitir sus datos. De igual manera, el receptor espera un tiempo para empezar a transmitir el ACK, en el que también configura la interfaz radio. Para finalizar hay un periodo de parada, ambos nodos apagan las interfaces radio. Estas pasan a modo sleep hasta que no tengan otro timeslot asignado en el que deban transmitir o recibir datos. 2.2.6.2. Retransmisión Cuando un dispositivo envía una trama espera durante un tiempo para recibir el ACK. Si no se recibe dicho ACK en un periodo de tiempo (valor TsAckWaitTime de la figura anterior), o el ACK recibido no es correcto, el dispositivo concluye que la transmisión ha sido fallida.


Cuando esto sucede, repite el proceso de transmisión de la trama, en el siguiente slot que tenga asignado, y vuelve a esperar el tiempo de recepción de ACK. Este proceso se repite un máximo de n veces. En el caso que se supere este número máximo de retransmisiones, se asume que la transmisión no se ha podido realizar y se notifica a las capas superiores. 2.2.6.3. IEs en TSCH TSCH utiliza varios IEs para transmitir información. Esta información se usa para construir EBs que permiten a nuevos dispositivos sincronizarse con el PANC, obtener información de la red o para que los nodos se mantengan sincronizados. Los IEs pueden ser enviados por distintos nodos de la red: tanto el nodo raíz como nodos intermedios. A continuación se verá la estructura de los IEs en TSCH. 1. IE para sincronización en TSCH:

Fig. 14 IE utilizado para sincronizarse con el modo TSCH

Este IE contiene el campo Absolute Slot Number (ASN) que identifica el timeslot en el que el EB se envía y la prioridad. 2. IE para corrección de tiempo en ACK/NACK:

Fig. 15 IE con información de tiempo utilizado en tramas ACK/NACK

Los IEs para la corrección de tiempo son utilizados por los nodos cuando envían un ACK para que el transmisor ajuste su reloj, con el fin de mantenerse sincronizados. Posteriormente se verá la sincronización con más detalle. 3. IEs de slotframe y enlace: En la Fig. 16 se muestra la estructura del IE que contiene información del número de slotframes que hay en la red.

Fig. 16 Este IE contiene información del número de slotframes de la red


Para cada uno de los slotframes existe un IE como el de la Fig. 17. El campo slotframe handle contiene un identificador único del slotframe. Se indica también la longitud de dicho slotframe y el número de enlaces.

Fig. 17 IE con contenido de cada uno de los slotframes.

Además por cada enlace se da información adicional (Fig. 18). En esta figura se muestra el IE que contiene información sobre un enlace. Los dos primeros campos identifican el timeslot y el offset de canal en el que este enlace estará operativo. En las opciones se indica el tipo de enlace que será: puede ser un enlace de transmisión o de recepción.

Fig. 18 IE con información del enlace

4. IE de timeslot

Fig. 19 IE con información del timeslot

El IE del timeslot contiene toda la información necesaria para construir un EB que permitan a nuevos dispositivos sincronizarse con la PAN.

2.2.7. Sincronización La sincronización entre los nodos de la red es un aspecto muy importante ya que si un nodo pierde la sincronización y no es capaz de seguir correctamente la estructura de la supertrama, no podrá comunicarse con ningún otro nodo ni podrá recibir datos. Los nodos normalmente utilizan un cristal de cuarzo con el que cuentan las oscilaciones y pueden tener una estimación aproximada como base de tiempo. Pero debido a que es un material físico y que puede tener defectos de fábrica, verse afectado por condiciones atmosféricas, entre otras situaciones, suelen tener derivas. Aproximadamente, el cristal de cuarzo utilizado en el nodo que


se usará en el proyecto tiene una deriva aproximada de 10 ppm. Esto es, cada segundo puede ocurrir una pérdida de sincronización de hasta 10 us. Por este motivo se deben implementar mecanismos para mantener la sincronización. El estándar define dos métodos para realizar esta sincronización: 1. Sincronización basada en ACKs: el receptor calcula el tiempo delta (la

diferencia de tiempos) entre el tiempo esperado de llegada de la trama y el tiempo real en la que llega la trama. Este valor calculado lo proporciona el receptor en la trama ACK que envía al emisor. Esto permite al emisor mantener la sincronización con el reloj del receptor.

2. Sincronización basada en trama: el receptor calcula el tiempo delta entre el tiempo esperado de llegada de la trama y el tiempo real en la que recibe la trama. Ahora es el receptor quien a partir de este valor delta ajusta su propio reloj para estar sincronizado con el emisor.

Con estos mecanismos mientras haya tráfico en la red los nodos podrán estar sincronizados. Si los nodos no han hecho ninguna transmisión o recibido datos en un periodo de tiempo largo (normalmente, 30 segundos), enviarán un paquete de datos vacío simplemente para volver a sincronizarse. Considerando una topología en árbol, formada por RPL, un nodo sólo se sincronizará con el reloj de un nodo que está por encima de él. Esto permite asegurarse que todos los nodos tienen una noción del tiempo, en la que el nodo raíz es quien acaba dictando el valor del tiempo de la red.

2.3. Pila de protocolos basada en IP para redes de sensores

Hasta ahora se ha hablado de la capa física y MAC, capas en las que se ha utilizado el estándar IEEE 802.15.4 (PHY) y IEEE 802.15.4e (MAC). En este apartado se verán las capas superiores utilizadas en redes de sensores IP.

2.3.1. Visión general Usar una pila de protocolos basada en IP permite conectar la red de sensores a Internet y poder acceder a ella de forma sencilla. Para ello, se ha definido la siguiente pila (Fig. 20):


Fig. 20 Pila de protocolos basada en IP para redes de sensores

Por encima de la capa MAC existe una capa de adaptación 6LoWPAN, desarrollada por el 6LoWPAN Working Group de la IETF. Esta capa de adaptación entre MAC e IPv6 proporciona una serie de mecanismos para la compresión de cabeceras, fragmentación y encaminamiento a nivel 2. Estas funcionalidades son imprescindibles ya que al usar IPv6 hay un excesivo coste en las cabeceras de los paquetes que hace que los datos a nivel de aplicación sean mínimos. Además, la MTU de IPv6 y IEEE 802.15.4 es diferente (1280 bytes en IPv6 por un centenar de bytes en 802.15.4) con lo que se requiere de un mecanismo para adaptar esta diferencia. 6LoWPAN implementa un algoritmo de fragmentación para que haya compatibilidad entre ambas capas. Por encima de 6LoWPAN se encuentra la capa IPv6, con el añadido de RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks), un protocolo de encaminamiento diseñado por el ROLL Working Group de la IETF para redes Low-Power and Lossy Networks (LLN). Este protocolo define una topología de red lógica similar a una topología en árbol. Cada jerarquía en la topología tiene un valor llamado rank, donde el nodo raíz tiene el rank=1. Al tener una topología en árbol, las rutas upward (es decir, las que van de un nodo hoja hasta el nodo raíz) son sencillas de determinar ya que el next-hop de los nodos será siempre su default parent. Sin embargo, si es el nodo raíz quien quiere transmitir datos a un nodo, se debe crear una ruta downward específica. Se puede realizar de dos maneras distintas: mediante storing mode o non-storing mode. Primero se deben enviar mensajes DAO desde los nodos hoja. Si se usa el storing mode, los nodos intermedios deben guardar información de todos los hijos que tienen para poder enrutar los paquetes downward. En el caso que se utilice non-storing mode, será el nodo raíz quien guarde todas las rutas posibles hasta los nodos hoja, y se empleará source routing. Estos dos modos de funcionamiento tienen características positivas y negativas, con lo que el uso de una u otra deberá adecuarse a los distintos tipos de aplicaciones y escenarios que se pueden dar en una red de sensores.


Por último, se ha definido un protocolo de aplicación llamado Constrained Application Protocol (CoAP). Se trata de un protocolo desarrollado por el CoRE Working Group de la IETF, con las mismas bases que HTTP pero adaptado para redes de sensores, con un menor overhead. CoAP define dos subcapas: la capa de petición/respuesta y la capa de mensaje. En la primera se definen los tipos de peticiones que puede solicitar el cliente (GET, POST, PUT, DELETE) y las posibles respuestas del servidor (2.00 OK, 2.01 Created, 2.02 Deleted, 4.04 Not Found, etc.). La capa de mensaje especifica el tipo de mensaje que será enviado. Las diferentes opciones son: CON, NON, ACK, RST. Si el mensaje es CON significa que se debe confirmar mediante un ACK. Si es NON no se requiere una confirmación. Un mensaje ACK es una confirmación de un mensaje CON recibido anteriormente. Por último, el mensaje RST hace referencia a Reset, y se usa cuando un nodo no puede procesar adecuadamente los mensajes (p.ej. porque se acaba de reiniciar tras una caída).

2.3.2. Iniciativa 6TSCH 6TSCH (pronunciado "sixtus") es una iniciativa que pretende convertirse en Working Group del IETF cuyo objetivo es utilizar IPv6 sobre el modo de funcionamiento TSCH del estándar IEEE 802.15.4e. IEEE 802.15.4e no define ningún método para construir y mantener el schedule que utiliza TSCH. Dado que TSCH requiere mecanismos para gestionar el schedule, este grupo de trabajo está definiendo una capa intermedia entre la capa MAC IEEE 802.15.4e con el modo TSCH y la capa 6LoWPAN. Esta capa recibe el nombre de 6top [10,11] y ofrece interfaces de gestión y datos para capas superiores. A continuación se muestra una tabla (Tabla 1) con algunos de los comandos:

Tabla 1 Comandos utilizados en la capa 6top [5]

Tipo comando Lista de comandos

Timeslot

CREATE.hardcell CREATE.softcell READ.cell UPDATE.cell DELETE.hardcell DELETE.softcell REALLOCATE.softcell

Slotframe

CREATE.slotframe READ.slotframe UPDATE.slotframe DELETE.slotframe

Datos SEND.data RECEIVE.data


Formación red CONFIGURE.eb READ.eb

Tal y como representa, se definen métodos para organizar el slotframe y los timeslots. Además, se diferencia entre dos tipos de celdas (o timeslots), las hardcell y las softcell. Las hardcell son timeslots que no pueden ser redistribuidas de forma dinámica, sin embargo las sotfcell sí que tienen esta propiedad. Una celda que ha sido redistribuida será instalada en un timeslot distinto y channel offset distinto. 6TSCH define, para ambos tipos de celdas, diferentes estados:

Tabla 2 Distintos estados de un timeslot [5]

Estado Descripción

ADV Timeslot compartido por todos los nodos de la red en el que se intercambian paquetes de advertising.

RES Timeslot en el que un nodo recibe paquetes 6top de cualquiera de sus vecinos.

TX Timeslot en el que se transmite a un vecino.

RX Timeslot en el que se recibe información de un vecino.

OFF Timeslot en el que no hay actividad radio, estará apagada.

2.4. Otras pilas de protocolos Existen otras pilas de protocolos utilizadas en redes de sensores que también emplean IEEE 802.15.4 como capa física y MAC. Un ejemplo conocido podría ser la pila de protocolos ZigBee, definida por la ZigBee Alliance, que establece una serie de especificaciones propias a partir del nivel MAC, pero que utiliza IEEE 802.15.4 en los niveles físico y MAC. A continuación se muestra la pila de protocolos completa.


Fig. 21 Pila de protocolos ZigBee

ZigBee Alliance define una serie de perfiles de aplicación (application profiles) que pueden ser instalados en los nodos, que proporcionan funciones muy específicas en función del perfil utilizado. Otro ejemplo de pila de protocolos es la pila de Bluetooth Low Energy (BLE). Esta tecnología, definida por el Bluetooth SIG en la especificación Bluetooth v4.0 puede hallar aplicación en el ámbito de la salud, seguridad, deportes y en el hogar. Su objetivo es reducir el consumo de energía en los dispositivos, el tamaño y el coste, además de ser compatibles con el máximo número de dispositivos posibles. Un aspecto clave de esta tecnología es el hecho de que los smartphones que disponen de Bluetooth podrán fabricarse con soporte también para BLE con bajo coste adicional, dado que BLE reaprovecha parte de la circuitería de Bluetooth. En la Fig. 22 se muestra la pila de protocolos utilizada.


Fig. 22 Pila de protocolos de BLE [13]

Existen otros estándares propietarios que no utilizan 802.15.4 como capa física y MAC, y que definen una pila de protocolos totalmente propietaria. Algunos ejemplos podrían ser Z-Wave, un protocolo diseñado especialmente para aplicaciones de domótica, utiliza diferentes bandas de frecuencia dependiendo el país en el que se utilice. Otro ejemplo parecido, usado también en domótica, es el X10, que a diferencia de Z-Wave utiliza la transmisión por la red eléctrica.


CAPÍTULO 3. ENTORNO HARDWARE Y SOFTWARE Anteriormente se ha proporcionado una visión de los protocolos de comunicaciones usados en redes de sensores, con énfasis en las tecnologías que son objeto de este proyecto. En este capítulo se hablará sobre las plataformas hardware y software utilizadas durante el desarrollo del proyecto.

3.1. Plataforma hardware La plataforma hardware empleada en el proyecto ha sido el nodo TelosB. Este producto es un módulo que incorpora un microcontrolador, una antena, un transceptor, varios sensores y una entrada USB que sirve de alimentación y como medio de conexión a un ordenador para su programación. Este dispositivo ha sido desarrollado y publicado por la comunidad de investigación de la Universidad de California en Berkeley. En la Fig. 23 se muestra los distintos componentes de este nodo.

Fig. 23Componentes del nodo sensor TelosB [1]

El dispositivo está diseñado para trabajar con baja potencia. Utiliza el transceptor CC2420 y está preparado para utilizar el estándar IEEE 802.15.4 en la banda de 2.4 GHz, con velocidad nominal de 250 kbps y alcances hasta las decenas de metros. Tiene también un sistema de fast wakeup que permite pasar de un estado dormido a un estado activo (con la radio encendida) en

Entorno hardware y software 23

menos de 6 microsegundos.Da soporte para utilizar el sistema operativo TinyOS. TinyOS es un sistema operativo open source que está basado en componentes para redes de sensores inalámbricas. Está desarrollado por la Universidad de California en Berkeley en cooperación con Intel Research y Crossbow Technology. El lenguaje de programación utilizado es nesC, un dialecto del C optimizado para las limitaciones de memoria de las redes de sensores.

3.2. Plataforma software La plataforma software utilizada en el proyecto es OpenWSN [6]. Se trata de un proyecto open-source donde se ha creado una pila de protocolos en la que se implementa el estándar IEEE 802.15.4e y utilizando como capas superiores la pila de protocolos basada en IP, como la mostrada en la Fig. 20. Aunque OpenWSN se encuentra en fase de desarrollo, actualmente se pueden realizar pruebas con distintos dispositivos hardware, entre ellos el nodo TelosB. Además, incorpora un espacio de información (Confluence [4]) donde se pueden consultar guías para instalar el proyecto en el dispositivo. OpenWSN utiliza un sistema operativo de código abierto (OpenOS [7]) desarrollado en C. Para hacer debug se requiere un JTAG acoplado al dispositivo. A continuación se hablará de un software de monitorización, llamado OpenVisualizer y posteriormente se presentará la capa uRes y la relación que tiene con 6TSCH.

3.2.1. OpenVisualizer OpenVisualizer es un programa escrito en Python y desarrollado por los integrantes de OpenWSN en el que se muestra información sobre los nodos que están activos en la red. En concreto, da información de cada uno de los nodos sobre:

Información sobre la PAN a la que está conectado el nodo

Tabla con información del schedule (número de timeslots y tipo, número de transmisiones en cada timeslot)

Tabla con información del scheduler del sistema operativo(número de paquetes que hay en la cola para ser transmitidos)

Tabla con información de los vecinos activos, el rango a nivel RPL, el valor delRSSI y el número de transmisiones de cada uno de ellos.

Además incorpora un botón que permite convertir en DAG root (rank = 1) al nodo seleccionado. En la siguiente figura se representa la interfaz de este software.


Fig. 24 Interfaz OpenVisualizer

3.2.2. uRes y 6TSCH En el apartado 2.3.2 se ha presentado la iniciativa 6TSCH, en la que se propone el uso de una capa entre 802.15.4e MAC y 6LoWPAN para configurar el schedule de un nodo. OpenWSN tiene implementado un protocolo propio llamado uRes en el que se permite a un nodo establecer una conexión bidireccional con sus vecinos. uRes es en realidad una parte de la capa 6top donde está implementado el uso de los Information Elements, formatos de paquetes, Time Sequence of Network Formation, y gestión (creación, borrado y mantenimiento) de celdas soft. En la siguiente figura (Fig. 25) se muestran dos métodos para establecer un enlace mediante uRes:

Entorno hardware y software 25

Fig. 25 Distintas formas de establecer un enlace mediante uRes [4]

El primer método se llama "Fast join in" en el que el nodo 6 recibe un advertisement beacon y se sincroniza con la red. El beacon contiene información de los enlaces que deberá usar el nodo para enviar datos. El segundo método es mediante la reserva, en el que el nodo 6 envía una petición Reserve Link Request. Una vez obtiene la respuesta con información de todo el slotframe y todos los enlaces, el nodo debe enviar o recibir datos por los enlaces reservados. En el caso que requiera más QoS deberá volver a iniciar el proceso de reserva de enlace.

3.2.3. Aplicaciones utilizadas Para realizar los experimentos se han utilizado distintas aplicaciones en los nodos. OpenWSN proporciona una serie de aplicaciones que pueden ser implementadas en los nodos cuando se compila todo el firmware. Algunas de las aplicaciones utilizadas han sido adaptadas para los distintos parámetros que se quieren medir. En el último anexo se puede encontrar más información sobre el código. Estas aplicaciones se ejecutan en el nodo hijo, el nodo raíz (con rank=1) no las ejecuta.


Para el PDR se ha utilizado una aplicación en uno de los nodos que genera un número determinado de paquetes, con un cierto tamaño y con un valor de tiempo de envío configurable. Además, para detectar paquetes duplicados, se ha forzado a los paquetes a tener un número de secuencia. El siguiente paso es exportar los datos capturados por el Wireshark a un fichero XML, que será leído por una aplicación escrita en Java que contará cuántas veces se ha repetido este número de secuencia. Con esto se cuentan los paquetes duplicados y se puede calcular el PDR. Para el caso de la latencia y el throughput se ha utilizado una aplicación que genera paquetes UDP y que se permite configurar la longitud del mismo y el tiempo entre envío de paquetes. Por último, para el tiempo de sincronización, se ha utilizado una aplicación que genera paquetes CoAP, cuyo tamaño puede ser modificado y también el tiempo entre envío. Para calcular este parámetro no ha sido necesario modificar el código proporcionado por OpenWSN.

Experimentos y resultados 27

CAPÍTULO 4. EXPERIMENTOS Y RESULTADOS En este capítulo se presentan distintos experimentos para evaluarlas prestaciones del estándar IEEE 802.15.4e. En primer lugar, seme dirá el Packet Delivery Ratio (PDR), después se evaluará el tiempo de latencia en transmisiones, a continuación se realizarán pruebas de throughput y para terminar se estudiarán los tiempos de sincronización entre dos nodos.

4.1. Packet Delivery Ratio (PDR) El PDR es un parámetro de rendimiento muy interesante ya que la teoría aplicable al estándar IEEE 802.15.4e indica que al utilizar el channel hopping, los efectos del multipath fading e interferencias (p.ej de transmisiones WiFi) se ven reducidos con lo que la probabilidad de que las transmisiones sean exitosas aumenta. Para evaluar el PDR se realizarán distintos experimentos en diferentes situaciones. El primer escenario es un escenario interior (una planta de una casa) donde los nodos no tienen Line of Sight (LoS). El segundo escenario también es interior pero los nodos sí tienen LoS. Por último, se realizará el experimento en un escenario exterior, donde los nodos también tienen LoS.

4.1.1. Escenario 1: interior sin Line of Sight (NLoS) En este primer escenario se evaluará el PDR en un entorno interior sin Line of Sight. En los escenarios interiores, donde existen paredes y otros objetos, los efectos de multicamino son mayores que en los escenarios abiertos, con lo que teóricamente el modo TSCH de IEEE 802.15.4e debe tener un buen PDR, ya que estos efectos conllevan bajo rendimiento en bandas de frecuencia estrechas y el Channel Hopping permite realizar transmisiones en distintas frecuencias portadoras. De este modo,si una frecuencia determinada está interferida por estos fenómenos, al realizar una retransmisión será en una frecuencia distinta y la señal no volverá a ser afectada por dicho fenómeno. En la Fig. 26 se muestra el plano del escenario utilizado. Para realizar este experimento se han utilizado dos nodos separados a distintas distancias. Uno de ellos ejecuta una aplicación que envía 2500 paquetes, a una cadencia de 5 paquetes/s, mientras el otro se mantiene en una posición fija conectado al ordenador el cual captura los paquetes mediante Wireshark. Se ha ajustado la potencia de transmisión al mínimo (-25 dBm)2 para reducir las dimensiones del escenario. En este caso se ha conseguido transmitir hasta una distancia de 13 metros. Para las pruebas realizadas sin channel hopping se ha utilizado el canal 20, cuyas interferencias por señales WiFi son menores que otros canales.

2Se puede configurar en el siguiente archivo: https://github.com/openwsn-berkeley/openwsn-

fw/blob/develop/firmware/openos/openwsn/02a-MAClow/IEEE802154E.h#L21

https://github.com/openwsn-berkeley/openwsn-fw/blob/develop/firmware/openos/openwsn/02a-MAClow/IEEE802154E.h#L21

https://github.com/openwsn-berkeley/openwsn-fw/blob/develop/firmware/openos/openwsn/02a-MAClow/IEEE802154E.h#L21


En el caso del escenario utilizado hay varios puntos donde los nodos no tienen LOS (Line Of Sight) y la señal se atenúa debido a obstáculos tales como paredes, puertas o ventanas, además de los problemas de multicamino. Además, se han suprimido la retransmisiones.

Fig. 26 Escenario utilizado para esta primera prueba de PDR. En este escenario se encuentran muchas paredes y los nodos no tienen LoS en la mayoría de los puntos. Además, hay interferencias WiFi ya que existe un router con interfaz WiFi activada en el mismo escenario.

En la siguiente figura se representa el gráfico que muestra el PDR obtenido en todas las distancias.

Fig. 27 PDR medido. En azul se muestra los valores obtenidos sin utilizar el modo channel hopping. En rojo se muestran los valores utilizando channel hopping.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0 1 2 3 4 5 6 7 8 9 10 11 12 12.5 13

Pac

ket

De

live

ry R

atio

(%

)

Distancia entre los nodos (m)

Packet Delivery Ratio (PDR)

NO CH. HOPPING

CH. HOPPING


La distancia entre las pruebas ha sido de 1 metro exceptuando las dos últimas pruebas, donde se han añadido los resultados obtenidos a una distancia entre los nodos de 12.5 metros. En rojo se representa la curva obtenida utilizando el modo de funcionamiento channel hopping y en azul sin channel hopping. En algunas ocasiones, algunas de las pruebas en la misma distancia han dado valores muy distintos que puede ser debido a interferencias u otros fenómenos como el multipath fading o posibles problemas de los nodos, como pérdida de la sincronización debido a la baja potencia recibida. Estas pruebas, que han dado resultados fuera de lo común, han sido repetidas ya que se ha considerado que no corresponden a una situación normal. Mirando en la gráfica, en los puntos a partir del noveno metro donde la separación entre los nodos no sólo se encuentran entre delgadas paredes, sino entre una pared de mayor grosor que es la que separa el interior de la vivienda (cocina) del exterior (terraza), el PDR empieza a descender más rápidamente. En este punto la señal resulta ser muy atenuada y los únicos sitios por donde no se atenúa es por la ventana y la puerta corredera. En la prueba, en general el modo con channel hopping ha obtenido una mejor PDR que el modo sin channel hopping. Aún así, durante los 3 primeros metros se aprecia cómo el modo de funcionamiento sin channel hopping obtiene incluso mejor valor de PDR. En la siguiente tabla se pueden ver los valores exactos obtenidos en cada uno de los puntos de distancia y la diferencia entre el modo con y sin channel hopping.

Tabla 3 PDR obtenido para el modo sin TSCH y con TSCH

Distancia (m) Modo sin ch.

hopping Modo con ch.

hopping Diferencia

0 97.83% 92.35% -5.48%

1 94.37% 93.40% -0.97%

2 92.90% 89.80% -3.10%

3 91.80% 93.70% 1.90%

4 93.40% 96.73% 3.33%

5 93.33% 96.47% 3.13%

6 86.77% 89.70% 2.93%

7 82.30% 90.80% 8.50%

8 73.90% 78.67% 4.77%

9 73.00% 84.30% 11.30%

10 62.10% 63.87% 1.77%

11 60.23% 63.63% 3.39%

12 40.63% 43.78% 3.14%

12.5 17.47% 39.73% 22.26%

13 2.77% 12.60% 9.83%


Como se observa, exceptuando los 3 primeros valores, el modo con channel hopping obtiene un mayor PDR. El promedio indica que el PDR usando channel hopping aumenta un 4.45%. Tener un alto PDR es importante en redes de sensores puesto que indica que los paquetes podrán ser entregados a su destino con una probabilidad alta. Por otra parte, trabajar en un canal donde las interferencias o fenómenos como el multipath fading afectan altamente a las transmisiones implica un mayor coste energético ya que se requerirán retransmisiones. A continuación se muestran los resultados de otra serie de pruebas donde el número de retransmisiones es 3 (valor por defecto recomendado por 6TSCH). También se modificará el canal de las transmisiones sin channel hopping al número 18 (anteriormente se utilizaba el 20). Este canal se ve más afectado por otras señales -las del canal 6 de WiFi-. También se desactivará el WiFi en el router que había en el anterior escenario.

Fig. 28 PDR en el escenario dentro de casa con 3 retransmisiones. En rojo se ve el gráfico con el modo TSCH y en azul sin TSCH.

Como se puede observar, el PDR ha aumentado en todos los puntos ya que en algunos casos las retransmisiones han permitido la entrega correcta de paquetes que en el escenario anterior se hubieran considerado como perdidos. La curva roja muestra el PDR obtenido utilizando channel hopping. En general, este modo ha obtenido iguales o mejores resultados que en el modo sin

80%

82%

84%

86%

88%

90%

92%

94%

96%

98%

100%

0 1 2 3 4 5 6 7 8 9 10 11 12 13

Pac

ket

De

live

ry R

atio

(%

)



NO CH. HOPPING

CH. HOPPING


channel hopping. Sin embargo, en el punto de 5 metros el modo sin channel hopping obtuvo un mayor PDR (99,80% y 94,80% respectivamente, una diferencia de 5% de paquetes perdidos). Este ha sido el punto donde ha habido un mejor rendimiento sin channel hopping. Por ejemplo, en los 2 metros, 12 metros y 13 metros también ha habido una ligera mejora utilizando el modo sin channel hopping pero la diferencia es mínima (0,52%, 1,28% y 0,80% respectivamente). La curva azul muestra el resultado del PDR sin channel hopping. En los puntos 3, 8, 10 y 11 metros ha obtenido significativamente peores resultados que utilizando el modo con channel hopping. En dichos puntos se ha obtenido una mejora del 2,80%, 6,2%, 5,68% y 11,08% con el modo channel hopping. En la resta de puntos, el modo con channel hopping obtiene mejoras poco significativas o iguales resultados. Sin embargo tampoco se puede afirmar que utilizando el modo channel hopping siempre habrá un mayor PDR ya que, como ya se ha comentado, hay situaciones puntuales en las que una prueba puede dar el resultado contrario. Esto posiblemente sea debido a que el proyecto OpenWSN no tiene implementada una blacklist (lista negra) con los canales que más interferencias tienen. Esta blacklist debería excluir los peores canales para aumentar aún más el PDR cuando se usa channel hopping. Aún así, el promedio muestra una mejora del 1,50% utilizando channel hopping. Si se recopilan los datos de la primera prueba, donde no había retransmisiones y la segunda, donde sí había, el gráfico resultante es el siguiente (Fig. 29):

Fig. 29 PDR en el escenario interior sin LoS. En azul se indica el PDR para el caso que hay retransmisiones y el modo TSCH activado. En rojo, retransmisiones sin TSCH. En

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0 1 2 3 4 5 6 7 8 9 10 11 12 13

Pac

ket

De

live

ry R

atio

(%

)



3 RETX CH. HOPPING

3 RETX NO CH. HOPPING

0 RETX CH. HOPPING



verde se muestran los resultados de las pruebas sin retransmisiones usando TSCH y por último, en lila, se representan los resultados sin retransmisiones y sin el modo TSCH.

Como se puede apreciar, las retransmisiones han hecho aumentar el PDR de forma notable.

4.1.2. Escenario 2: interior con Line of Sight (LoS) A continuación se realizará el mismo experimento en un escenario distinto, donde los nodos están en un entorno interior pero disponen de LoS. En la siguiente figura se muestra el escenario utilizado, que se corresponde con el pasillo de la planta 1 del edificio de la EETAC (Fig. 30). En este escenario, al igual que en los próximos, el canal utilizado para las transmisiones sin channel hopping es el 18. La potencia de transmisión se mantiene al mínimo, esto es, -25dBm.

Fig. 30 Escenario utilizado para las pruebas de PDR en interior teniendo LoS

En este escenario se han realizado cuatro pruebas: dos con 3 retransmisiones (una con y otra sin channel hopping) y otras dos sin retransmisiones. En la Fig. 31 se muestran los resultados de las pruebas. En lila y verde se muestran las curvas utilizando 0 retransmisiones. La curva de color lila indica los resultados obtenidos con el uso de channel hopping, y la curva en verde indica los resultados sin channel hopping. Como se muestra, el modo de channel hopping logra un mayor PDR a partir de los 24 metros (en los puntos anteriores también está por encima pero la diferencia apenas se puede apreciar ya que ambos modos de funcionamiento están por encima del 98%).


Desde los 24 metros hasta los 39 metros, el PDR obtenido con channel hopping es superior al del modo sin channel hopping, a pesar de que este último también consiga buenos resultados. En el último punto, en la distancia entre nodos de 42 metros, el modo con channel hopping consigue un PDR del 25,76% mientras que si se desactiva este mecanismo sólo se ha obtenido el 5,36%. Las dos siguientes curvas, en azul y rojo, son los resultados utilizando sin y con channel hopping, respectivamente y configurado con 3 retransmisiones. Si se comparan estas dos curvas se puede afirmar que apenas hay diferencia entre ambos casos. El PDR con channel hopping es mayor en algunos puntos, obteniendo entre el 0,12 - 8% de mejoría. En otros, sin embargo, el PDR es muy parecido o ligeramente inferior al obtenido sin channel hopping.

Fig. 31 PDR obtenido en el escenario interior con LoS. En verde se muestra la curva sin utilizar channel hopping con 0 retransmisiones. En lila se muestra el PDR con channel hopping y con 3 retransmisiones. En rojo y azul se muestran las curvas sin utilizar retransmisiones y con el modo sin channel hopping y con, respectivamente.

Se aprecia claramente cómo el mecanismo de retransmisión consigue mejores resultados. Además, se ha visto que sin las retransmisiones el beneficio del channel hopping no parece tan claro, ya que estas mejoras aparecen en puntos aleatorios y no se muestra una mejora constante en todos los puntos. Por otra parte, cada nueva retransmisión con channel hopping se realiza en un canal distinto al original.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0 3 6 9 12 15 18 21 24 27 30 33 36 39 42

Pac

ket

De

live

ry R

atio

(%

)




3 RETX CH. HOPPING

NO CH. HOPPING

CH. HOPPING


A continuación se muestra una tabla con el valor del PDR medido en cada uno de los puntos y la diferencia entre el modo channel hopping y sin channel hopping (Tabla 4).

Tabla 4 PDR específico para cada punto, con 3 retransmisiones.



hopping Diferencia

0 100% 100% 0%

3 100% 100% 0%

6 99,20% 100% 0,80%

9 100% 100% 0%

12 99,16% 100% 0,84%

15 99,88 100% 0,12%

18 98,76% 99,96% 1,20%

21 98,80% 100% 1,20%

24 98,52% 96,44% -2,08%

27 94,76% 99,48% 4,72%

30 97,48% 99,80% 2,32%

33 91,40% 96,48% 5,08%

36 72,68% 80,96% 8,28%

39 84,20% 81,24% -2,96%

42 5,36% 25,76 20,40%

La máxima diferencia en el PDR se da en los 42m donde se ha obtenido un 20,40% mejor PDR con channel hopping. En los puntos 24 y 39 metros el PDR con channel hopping ha caído un 2,08% y un 2,96% respectivamente. Aún así, considerando todos los puntos, se puede afirmar que con channel hopping se obtienen mejores resultados en este escenario.

4.1.3. Escenario 3: exterior con Line of Sight (LoS) Por último, se estudiará el PDR en un escenario exterior con LoS. En este escenario intervienen menos elementos que produzcan propagación multicamino, pero aún así existen algunos: árboles, personas y alguna pared. El escenario ha alcanzado los 50 metros entre ambos nodos, las pruebas se han realizado cada 3,5 metros. En la siguiente imagen se muestra el escenario que se ha utilizado, ubicado en el exterior de la EETAC (Fig. 32).


Fig. 32 Escenario exterior con LoS

El resultado en este escenario se muestra en la siguiente gráfica (Fig. 33). En azul se muestra el modo sin channel hopping y en rojo con channel hopping. Se ha utilizado 3 retransmisiones. Como señala la Fig. 33, el modo con channel hopping obtiene siempre un mejor resultado. Comparado con otros escenarios este es el escenario en que se ha obtenido un mayor PDR promedio ya que en los anteriores escenarios hay puntos en los que el PDR era similar o en algún punto ligeramente inferior. A diferencia del escenario anterior, se ha conseguido una mayor distancia ya que a partir de los 42 metros el PDR sin channel hopping era prácticamente 0. Sin embargo, en este caso el PDR es mucho mayor, incluso en el último punto analizado, los 50 metros. Sin embargo, el PDR en los puntos intermedios ha sido inferior comparado con los anteriores escenarios. Por ejemplo, en los 11,5 metros con channel hopping, se ha obtenido un valor de 94,48%, mientras que en los anteriores escenarios, con 3 retransmisiones, se obtuvo un PDR del 98,20% para el caso del primer escenario y 100% para el caso del segundo escenario.


Fig. 33 PDR en el escenario exterior con LoS. En azul se muestra el modo sin channel hopping y en rojo con channel hopping. Se han utilizado 3 retransmisiones.

Por lo tanto en este escenario el PDR con channel hopping ha sido mucho más efectivo ya que en todos los puntos se ha podido mejorar la tasa de pérdida de paquetes, pero en los puntos intermedios el PDR por lo general ha sido inferior si se compara con otros escenarios. Este resultado demuestra que las pruebas del PDR varían mucho dependiendo del escenario. También lo hacen dependiendo de la hora, la posición geográfica o la frecuencia. A continuación se muestra una tabla con el resultado de todos los puntos y el valor de PDR obtenido (Tabla 5).

Tabla 5 PDR con 3 retransmisiones para los distintos puntos



hopping Diferencia

1 100% 100% 0%

4,5 99,40% 100% 0,60%

8 92,12% 99,56% 7,44%

11,5 87,60% 94,48% 6,88%

15 95,44% 97,84% 2,40%

18,5 71,60% 84,24% 12,64%

22 79,12% 91,48% 12,36%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 4,5 8 11,5 15 18,5 22 25,5 29 32,5 36 39,5 43 46,5 50

Pac

ket

De

live

ry R

atio

(%

)



NO CH. HOPPING

CH. HOPPING


25,5 86,36% 94,12% 7,76%

29 80,72% 82,88% 2,16%

32,5 63,96% 81,04% 17,08%

36 44,28% 66,44% 22,16%

39,5 51,72% 54,32% 2,60%

43 49,04% 71,84% 22,80%

46,5 36,72% 52,52% 15,80%

50 33,16% 46,84% 13,68%

Como señala la Tabla 5, este es el escenario que mejores resultados ha proporcionado ya que con channel hopping se han obtenido siempre mejores valores de PDR. En promedio, se aumenta un 9,75% el PDR si se utiliza channel hopping. Es un elevado porcentaje si se compara con los anteriores escenarios.

4.2. Latencia En esta prueba se va a estudiar la latencia enlas transmisiones entre nodos en distintos escenarios. Se utilizará una aplicación llamada udpLatency, la cual envía paquetes UDP desde el nodo que la tiene instalada y guarda un registro del tiempo transcurrido desde que la capa de aplicación genera el paquete hasta queel destinatario recibe el paquete. La aplicación realiza el cálculo de la latencia en función del tiempo de duración del timeslot. Internamente, el nodo conectado al ordenador que ejecuta el OpenVisualizer cuenta el número de timeslots que han transcurrido desde que la capa de aplicación genera el paquete hasta que el receptor lo recibe. Esto es posible gracias al identificador único del timeslot, el ASN. De este modo, como mínimo la latencia puede tener un valor de 15ms. En este caso, se enviarían los datos y en el mismo timeslot se recibiría el ACK conforme la transmisión ha sido realizada con éxito. A partir de este valor, la latencia puede variar siendo siempre múltiplos de 15 ms. Por otra parte, si un nodo necesita enviar un paquete pero el schedule que sigue está en modo OFF, este timeslot también se tiene en cuenta para calcular la latencia, a pesar de que posteriormente la transmisión se realice con éxito en un único timeslot, sin necesidad de retransmitir. Los cálculos de latencia se realizarán en los mismos escenarios que en los del apartado anterior. Primero se verá el resultado de las pruebas en el escenario interior sin LoS (con y sin retransmisiones), posteriormente en un escenario interior con LoS y por último en un escenario exterior con LoS. Los resultados que se muestran son la media de aproximadamente 1000 paquetes enviados, excepto en los últimos puntos, donde en algunos casos, debido a la gran pérdida de paquetes.


4.2.1. Escenario 1: interior sin Line of Sight (NLoS) Este escenario (Fig. 26) tiene una longitud de 13 metros. Para mostrar los resultados, en vez de gráficas, se ha decidido utilizar tablas para poder apreciar mejor las pequeñas variaciones de latencia. Esto es porque en los últimos puntos la latencia suele aumentar mucho, de modo que una gráfica dificulta apreciar las diferencias en los otros puntos. En la siguiente tabla (Tabla 6) se muestra la latencia para el caso en el que no hay retransmisiones. En este caso las latencias han sido similares en todos los puntos, oscilando entre los 41 y 42,67ms.

Tabla 6 Tabla donde se muestra la latencia en el primer escenario, sin retransmisiones.

Distancia (m) Latencia (ms)

0 3 6 9 13

Channel Hopping

41,33 41 41,67 42,67 42,67

No Channel Hopping

41 41,33 41 42,67 42,33

En la Tabla 7 se indican los resultados utilizando 3 retransmisiones. Como se observa, las latencias varían un poco en las primeras pruebas, y bastante más en la última, a una distancia de 13 metros. En este caso la latencia en los primeros puntos no aumenta demasiado ya que el PDR es casi del 100%.

Tabla 7 Latencia para el primer escenario, interior sin LoS, con 3 retransmisiones.


0 3 6 9 13

Channel Hopping

41,33 43 44,33 44,33 135

No Channel Hopping

41,67 42,67 44 44,33 54,67

4.2.2. Escenario 2: interior con Line of Sight (LoS) A continuación se muestran los resultados de latencia en este segundo escenario, interior con LoS (Fig. 30). Primero se presenta la tabla con el resultado sin utilizar retransmisiones (Tabla 8), donde para ambos modos de funcionamiento (con y sin channel hopping) la latencia se sitúa entre los 41 y 45ms, exceptuando el último punto, a 42 metros, donde la latencia aumenta de forma muy notable hasta los 860,50 y 979 para el caso con channel hopping y sin, respectivamente.


Este aumento latencia puede ser debido a posibles problemas en la sincronización. Es decir, pérdidas momentáneas en la sincronización, por lo que el nodo debe esperar a volver estar sincronizado para enviar el paquete que tiene en cola.

Tabla 8 Latencia para el escenario interior con LoS, sin retransmisiones.


0 12 24 30 42

Channel Hopping

41 41 41 41,33 860,50

No Channel Hopping

41,33 45,33 42,67 42 979

En la siguiente tabla (Tabla 9) se muestra el resultado con las 3 retransmisiones. En el último punto se vuelve a observar cómo los nodos sufren una gran latencia cuando están a distancias límite. En estos puntos en los que el PDR tiende a 0, la latencia aumenta drásticamente. En los anteriores puntos, la latencia también aumenta respecto el caso anterior, aunque en menor medida, también debido a las retransmisiones.

Tabla 9 Tabla con la latencia para el caso del segundo escenario con 3 retransmisiones.


0 12 24 30 42

Channel Hopping

41,67 42,33 48,33 63 1615

No Channel Hopping

41,67 42,67 44,33 48 2103

4.2.3. Escenario 3: exterior con Line of Sight (LoS) Para finalizar este apartado se muestra el resultado de la latencia para el último escenario (Fig. 32). En este escenario el PDR obtenido ha sido en general más bajo que en los anteriores escenarios. Esto representa un mayor problema para que los paquetes alcancen el destino por lo que lo más probable es que ocurran muchas más retransmisiones. En la siguiente tabla señala cómo la latencia es mucho mayor que en los casos anteriores (Tabla 11). Para el caso de 1 metro ya se han obtenido latencias mayores que en los anteriores casos. En los 12 y 25,5 metros también ha aumentado considerablemente la latencia si se compara con el escenario anterior. Por último, en los 39,5 y 50 metros la latencia aún es mayor debido al alto número de retransmisiones y posibles problemas de sincronización que hacen que los paquetes tarden varios segundos en llegar al receptor.


Tabla 10 Latencia para el último escenario, exterior con LoS y con 3 retransmisiones.


1 12 25,5 39,5 50

Channel Hopping

52,67 152 327 439 905

No Channel Hopping

46,67 152 231 2177 1076

4.3. Throughput El siguiente experimento medirá la capacidad máxima del sistema de entregar datos por unidad de tiempo (throughput). El escenario consiste en dos nodos, uno que envía paquetes a la máxima tasa posible y el otro, que será el DAG root, será el receptor de los datos. El throughput es un parámetro que dependerá del schedule del nodo. Por ello, se van a proponer distintos slotframes para poder comparar resultados. Para empezar se utilizará un schedule sencillo en el que sólo habrá un timeslot (ADV) para transmitir tramas EB, otro para transmitir información y los demás estarán en OFF. En la siguiente figura se muestra cómo será el schedule que emplearán los nodos en este escenario. Este es el schedule que utiliza OpenWSN por defecto

Fig. 34 Estructura del schedule que los nodos emplearán. El tamaño del slotframe es de 9 timeslots.

Sólo hay un timeslot en el schedule para realizar las transmisiones de datos (el segundo timeslot). El primer timeslot se utilizará para enviar información para sincronizarse con la red, el tercer timeslot se usa para enviar información por el puerto serie de la conexión nodo-PC mediante el cable USB. El resto de timeslots están desactivados. Cada timeslot tiene una duración de 15 ms, con lo que sólo se podrá realizar

una transmisión cada 135 ms (9 𝑡𝑖𝑚𝑒𝑠𝑙𝑜𝑡𝑠 ·15 𝑚𝑠

𝑡𝑖𝑚𝑒𝑠𝑙𝑜𝑡= 135 𝑚𝑠). Esto significa

que el throughput máximo se obtendrá cuando el tiempo de envío entre paquetes sea 135 ms (o inferior). Si el tiempo de envío es superior el throughput descenderá. El tamaño de los paquetes a nivel físico es de 112 bytes, que es el tamaño máximo que se ha podido transmitir. En la Fig. 35 se muestrar la gráfica del throughput obtenido en función del tiempo entre envío de paquetes.


Fig. 35 Throughput medido en función del tiempo entre envío de paquetes.

Como se observa, el throughput máximo se obtiene en los 135 ms. También se han realizado pruebas con tiempos de envío de paquetes menores a 135 ms, pero el throughput medido en esos casos ha sido inferior ya que el sistema operativo tiene una cola limitada y como se generan más paquetes de los que la red puede soportar, esta cola se desborda y en algunas ocasiones el nodo pierde la sincronización con los demás nodos de la red. Por esto el throughput en 100 ms decrece hasta los 3,8 kbps aproximadamente. A continuación se muestra la curva del throughput teórico y la comparativa entre el throughput medido y el teórico (Fig. 36).

Fig. 36 Throughput teórico.

0

1

2

3

4

5

6

7

100 135 150 175 200 225 250 275 300 325 350 375 400

Thro

ugh

pu

t (k

bp

s)

Tiempo entre envío de paquetes (ms)

Throughput medido

0

1

2

3

4

5

6

7

100 135 150 175 200 225 250 275 300 325 350 375 400

Thro

ugh

pu

t (K

bp

s)


Throughput teórico


El throughput máximo se obtiene para valores por debajo o igual a 135 ms

como es de esperar. En estos casos, el valor es de 112∗8 𝑏𝑦𝑡𝑒𝑠

135 𝑚𝑠= 6,637 𝑘𝑏𝑝𝑠,

igual que el valor medido durante el experimento. En la siguiente figura se muestran las dos curvas en la misma gráfica.

Fig. 37 Throughput medido y teórico

Como se puede observar, el throughput medido coincide con el teórico, exceptuando para tiempos de envío de paquets de envío inferiores a 135 ms donde, como ya se ha explicado, el nodo sufre problemas que llegan a afectar al throughput. A continuación se va a modificar el schedule del nodo para intentar mejorar el throughput. En el anterior experimento, el nodo tenía 6 timeslots en OFF donde no se realizan transmisiones. En términos de throughput esto es ineficiente ya que es un tiempo donde no se envían datos. En la siguiente figura se muestra la nueva estructura que tendrá el schedule de los nodos.

Fig. 38 Schedule de los nodos. El tamaño del slotframe es 5

Idealmente, el throughput máximo se conseguiría utilizando un slotframe de tamaño 1 en el que hubiera un timeslot para transmitir. En ese caso, el nodo podría estaría siempre transmitiendo. Pero esto es imposible ya que la

0

1

2

3

4

5

6

7

100 135 150 175 200 225 250 275 300 325 350 375 400

Thro

ugh

pu

t (K

bp

s)


Throughput: medido vs teórico

Throughput medido

Throughpute teórico


supertrama requiere como mínimo un timeslot para sincronizarse (ADV) y en el caso del proyecto OpenWSN se utiliza un puerto SERIAL para la transmisión de datos desde el nodo al PC. Se ha intentado utilizar un schedule sin SERIAL y con un único timeslot en OFF pero debido a problemas en la sincronización de los nodos se ha utilizado el schedule mostrado en la anterior figura (Fig. 38). En este caso, el throughput máximo se obtiene cuando el tiempo de envío entre

paquetes es de 5 𝑡𝑖𝑚𝑒𝑠𝑙𝑜𝑡𝑠 ∗15 𝑚𝑠

𝑡𝑖𝑚𝑒𝑠𝑙𝑜𝑡= 75 𝑚𝑠. En ese punto se debe tener un

throughput de 112∗8 𝑏𝑦𝑡𝑒𝑠

75 𝑚𝑠= 11.95 𝑘𝑏𝑝𝑠. A continuación se muestra la gráfica

obtenida a partir de las medidas.

Fig. 39 Throughput medido, considerando tiempos entre de envío de paquetes desde 60 ms hasta 135ms

Como señala la Fig. 39, se ha realizado el experimento entre los tiempos de 60 ms y 135 ms. A partir de 135 ms se obtendrán los mismos valores que los mostrados anteriormente (Fig. 35). En el punto de 75 ms se obtiene el máximo throughput (11.85 kbps medidos). Igual que sucedía anteriormente, si se envían paquetes a una tasa mayor a la tasa máxima que puede procesar la red (75 ms) el nodo se ve afectado por problemas de desbordamiento de paquetes en la cola del buffer y el rendimiento cae bruscamente. En teoría, en valores por debajo de 75 ms el throughput debería mantenerse en los 11.95 kbps.

0

2

4

6

8

10

12

14

60 75 80 90 100 110 120 130 135

Thro

ugh

pu

t (K

bp

s)


Throughput medido


Otras pruebas que se han realizado para medir el throughput han sido con más de un timeslot del tipo TXRX. Teóricamente, el nodo debe mantener el mismo throughput en los casos anteriores e incluso si se redujera el tiempo de envío de paquetes, se podría usar el resto de timeslots (y no sólo 1) para transmitir, de forma que aún se podría incrementar el throughput. Sin embargo, el resultado de las pruebas ha mostrado lo contrario: utilizando más de un timeslot del tipo TXRX el throughput se reduce (siempre está por debajo del teórico).

4.4. Tiempo de sincronización El último tipo de experimento realizado es la medida de tiempo de sincronización. A diferencia de la antigua capa MAC de 802.15.4 donde no se utilizaba channel hopping, ahora un nodo sensor que quiera sincronizarse con el resto deberá escuchar en distintos canales hasta que coincida con un canal en el que un nodo envía una trama con información para realizar la sincronización. Este proceso puede durar entre pocos segundos hasta varios minutos dependiendo de la frecuencia de envío de los mensajes con EB. Por defecto, en OpenWSN, este valor está predeterminado a 10 segundos. Para realizar este experimento se utilizará la estructura de slotframe recomendada por la capa 6top. Este slotframe tiene una longitud de 101 timeslots. El schedule recomendado es el siguiente [8]:

Fig. 40 Schedule utilizado para poner a prueba el tiempo de sincronización.

Como se observa, el schedule consta de un timeslot tipo ADV, 5 timeslots TXRX y el resto (95 timeslots) en modo OFF. El total suma un tiempo de slotframe de 1515ms. Tal y como se ha dicho antes, el tiempo de envío de tramas con EB (en los timeslots de tipo ADV) es de 10 segundos por defecto. Para calcular el tiempo de sincronización se modificará este valor entre 10 segundos hasta 2 segundos de tiempo entre envío de estas tramas. Los resultados de esta prueba pueden variar mucho, por lo que se han realizado 20 pruebas para cada uno de los valores de tiempo de envío de EB. En la siguiente tabla muestran los resultados obtenidos:


Tabla 11 Resultados obtenidos de la prueba de tiempo de sincronización

Tiempo entre

envío de EB(s)

10 9 8 7 6 5 4 3 2

Resultado medio

1m 57s

1m 42s

1m 34s

1m 17s

1m 6s 56s 44s 36s 22s

Valor mínimo

26s 17s 7s 6s 9s 6s 2s 1s 2s

Valor máximo

4m 15s

4m 16s

4m 56s

3m 9s

4m 21s

4m 1s

2m 10s

1m 29s

1m 4s

Los valores mostrados son el resultado de la media aritmética, el mínimo y el máximo de las 20 pruebas realizadas para cada uno de los tiempos entre envío de tramas EB. Se muestran también los valores obtenidos mediante una gráfica (Fig. 41). En rojo se representa el valor medido máximo en cada uno de los puntos, en verde el valor mínimo y en azul el valor promedio. Como se puede observar, al disminuir el tiempo entre tramas EB el tiempo de sincronización se reduce (de forma lineal). Variar este tiempo tiene distintas consecuencias. Por una parte, si se reduce el tiempo entre paquetes, la red sufrirá una mayor congestión. Esto significa que los nodos en vez de estar durmiendo (en modo OFF o sleep), estarán con las interfaces radio activas, con lo que el tiempo de vida de los mismos se verá reducido. Por otro lado, si el tiempo de envío se mantiene en un valor alto, los nodos no tendrán durante tanto tiempo la radio encendida y ahorrarán energía a medio o largo plazo. Sin embargo, cuando un nodo quiere unirse a la red, mantiene siempre activa la radio para recibir tramas EB en un canal específico3, cuando el tiempo entre envío de tramas EB es alto, estará más tiempo escuchando el canal hasta que logre sincronizar. En principio esto no supondría un problema ya que es más problemático que todos los nodos de la red tengan que escuchar tramas EB cada poco tiempo frente a que un único nodo tarde un poco más en sincronizarse. Un problema de este largo tiempo de sincronización sería que el nodo se mantendría inactivo (fuera de la red) durante algunos minutos y podría dejar de proporcionar información crucial, dependiendo del escenario. Con esto se demuestra que las redes que usan TSCH están pensadas para que la topología no varíe demasiado, es decir, los nodos están fijos.

3 En OpenWSN por defecto está configurado en el canal 20


Fig. 41 Gráfica tiempo de sincronización en función del tiempo entre envío de tramas ADV

Estos resultados se pueden contrastar con un estudio teórico. El tiempo de sincronización se puede calcular mediante la siguiente fórmula:

𝐽𝑜𝑖𝑛 𝑇𝑖𝑚𝑒 𝑠 =𝐶 · 𝑇

𝑃 · 𝐷 (2)

Donde C = nº de canales, T = tiempo de envío entre tramas EB, P = PDR y D = duty cycle del receptor. [9] En el caso del experimento, el número de canales es 16, el parámetro T dependerá del caso a analizar (10, 9, 8….2). El PDR, tal y como se ha calculado anteriormente, será del 92.35% ya que el experimento se ha realizado a una distancia de 0 metros. El duty cycle del receptor es del 100% ya que el nodo cuando intenta sincronizarse con la red siempre está escuchando el canal 20 hasta que encuentra una trama ADV que le permite sincronizarse.

Para el caso de T = 10s quedaría: 𝐽𝑇 =16 𝑐𝑎𝑛𝑎𝑙𝑒𝑠 ·10𝑠

0.9235·1= 173.25𝑠 = 2𝑚 53𝑠.

Aproximadamente 3 minutos, mientras que en los experimentos, la media ha resultado ser de 1 minuto y 57 segundos, a pesar de que haya habido varios resultados donde el tiempo de sincronización ha sido de 3 y 4 minutos. En la siguiente tabla se muestran los tiempos de sincronización realizando el cálculo teórico mostrado anteriormente.

0:00:00

0:00:43

0:01:26

0:02:10

0:02:53

0:03:36

0:04:19

0:05:02

0:05:46

10 9 8 7 6 5 4 3 2

Tie

mp

o s

incr

on

izac

ión

(H

H:M

M:S

S)

Tiempo entre envío tramas EB (s)

Tiempo sincronización medido

Tiempo medido promedio

Tiempo medido máximo

Tiempo medido mínimo


Tiempo entre

envío de EB(s)

10 9 8 7 6 5 4 3 2

Resultado 2m 53s

2m 36s

2m 18s

2m 1s

1m 43s

1m 26s

1m 9s

52s 34s

Como se muestra, todos los valores teóricos indican un tiempo de sincronización mayor. En la siguiente gráfica se muestra el resultado teórico, que es el tiempo máximo que puede tardar un nodo en sincronizarse (rojo), el tiempo medio teórico, que es la mitad del tiempo teórico (verde) y el tiempo medido, que corresponde al valor medio medido (azul). Para calcular el tiempo teórico se ha utilizado la fórmula descrita en (2).

Fig. 42 Tiempo sincronización teórico comparado con el tiempo de sincronización medido anteriormente

Teóricamente, el valor medido debería ser igual al tiempo medio de sincronización. Sin embargo, la curva obtenida se encuentra por encima de la media. Esto es debido a situaciones en las que no se ha recibido correctamente el EB y se ha tenido que esperar a un nuevo EB en el canal 20 (pese a que al cálculo teórico incluye la estimación del valor de PDR), además, se necesitarían infinitas pruebas para acabar obteniendo la recta con el valor medio.

0:00:00

0:00:43

0:01:26

0:02:10

0:02:53

0:03:36

10 9 8 7 6 5 4 3 2

Tie

mp

o s

incr

on

izac

ión

(H

H:M

M:S

S)

Tiempo entre envío tramas EB (s)

Tiempo sincronización: medido vs teórico

Tiempo medido

Tiempo teórico

Tiempo medio


En la siguiente tabla se muestran los tiempos que han excedido 1 periodo de sincronización (es decir, donde ha habido un error en la transmisión del EB).

Tabla 12 Tiempos de sincronización superiores al tiempo máximo de sincronización.

Tiempo entre envío de EB(s)

10s 9s 8s 7s 6s

Tiempo máximo

recepción 2m 40s 2m 36s 2m 18s 2m 01s 1m 43s

4m 15s 4m 16s 2m 41s 2m 17s 2m 38s

3m 45s 4m 05s 2m 22s 3m 01s 4m 21s

2m 56s - 3m 01s 2m 08s -

3m 09s - 3m 48s 3m 09s -

3m 32s - 4m 56s 2m 10s -

- - - - -

Tiempo entre envío de

EB(s) 5s 4s 3s 2s

Tiempo máximo

recepción 1m 26s 1m 09s 52s 34s

4m 01s 1m 20s 1m 02s 1m 04s

1m 48s 2m 10s 1m 26s 38s

- 1m 29s 1m 05s 39s

- 1m 27s 1m 01s 37s

- 1m 20s 1m 13s 58s

- - 1m 29s -

Como se puede observar en las anteriores tablas hay tiempos medidos en los que son mayores que el tiempo máximo de sincronización. Esto es debido a que hay errores en la transmisión del EB y el nodo debe esperar a recibir de nuevo una trama EB por el canal de sincronización (que por defecto es el canal 20).

Conclusiones 49

CAPÍTULO 5. CONCLUSIONES IEEE 802.15.4e es una nueva especificación que complementa la capa MAC deI EEE 802.15.4. Este nuevo estándar sigue utilizando la capa física 802.15.4 y sólo se necesita cambiar la programación del nivel MAC. Con este cambio se pueden conseguir grandes mejoras, gracias a los modos de funcionamiento definidos por IEEE 802.15.4e. Los objetivos del proyecto es evaluar TSCH realizado distintos experimentos: PDR, latencia, throughput y tiempo de sincronización, utilizando la plataforma hardware TelosB y como plataforma software OpenWSN, que proporciona una pila de protocolos basada en IP sobre IEEE 802.15.4e. Respecto al resultado de las pruebas, cabe decir que algunos resultados no son similares a los que indica la teoría. Empezando por las pruebas de pérdida de paquetes (PDR), teóricamente se espera que el mecanismo de channel hopping que incorpora el modo de funcionamiento TSCH, obtenga mucho mejores resultados respecto sin channel hopping. En los dos primeros escenarios se han obtenido mejores resultados con channel hopping en algunos puntos. Y no siempre la mejora ha sido tan notable como se esperaba. Sin embargo, en el escenario exterior sí que se ha notado una mayor mejora. No obstante, el modo TSCH es especialmente indicado para entornos interiores, por lo que se esperaba que el resultado en el exterior fuera menor la diferencia entre el uso de channel hopping y sin channel hopping. El resultado obtenido en las pruebas de latencia es el esperado. A medida que los nodos pierden más paquetes se producen más retransmisiones y si están muy alejados también pueden perder la sincronización durante algunos segundos. Esto hace aumentar la latencia, que es lo que ha sucedido durante las pruebas. Por otro lado, se han hecho pruebas de throughput. En este escenario se ha visto cómo la longitud del slotframe determina el throughput máximo. Los primeros resultados han proporcionado resultados próximos a los teóricos, sin embargo cuando se ha puesto a prueba el throughput en un stloframe donde hay más de un timeslot que permite transmitir, no se ha podido alcanzar el valor de throughput esperado. El estándar indica que si un nodo requiere una mayor calidad de servicio (QoS) puede solicitar más timeslots en los que transmitir, dentro del mismo slotframe. Esto no se ha podido comprobar en la práctica. Por último, el tiempo de sincronización medido se ha aproximado bastante al teórico. Esta prueba ha demostrado que el modo TSCH está orientado a topologías de red estáticas ya que los tiempo que se requiere para sincronizarse son elevados y esto puede causar problemas en algunas aplicaciones.


GLOSARIO 6top: capa por encima de 802.15.4e que da soporte al modo de funcionamiento TSCH. ACK: confirmación. ADV: timeslot específico donde se envían tramas para sincronizarse con la red. ASN: nombre absoluto de un timeslot (Absolute Slot Number). Identifica un timeslot de forma única. Channel hopping: mecanismo en el que cada transmisión ocurre en un canal distinto. CSL: mecanismo de ahorro energético en el que el receptor hace escuchas constantes para saber si tiene un paquete pendiente. DODAG: topología que se forma a nivel IP. Forma parte del protocolo RPL. DAG rank: rango de un nodo en el DODAG. EB: enhanced beacon, tramas con información útil para sincronizarse con la red de sensores. FFD: full function device, dispositivos capaces de desempeñar cualquier rol en la red. GTS: ranuras de tiempo garantizadas para las transmisiones. IE: contenedores de información. Definen métodos para encapsular los datos de tal forma que el receptor los sepa interpretar. IP: protocolo de Internet. IPv6: protocolo de Internet, versión 6. MAC: control de acceso al medio. MHR: cabecera MAC. MTU: unidad máxima de datos de envío. OpenWSN: proyecto open-source que implementa 802.15.4e. OpenVisualizer: software que proporciona información sobre los nodos en la red. PAN: red de área personal.

Glosario 51

PANC: coordinador de una PAN. PDR: porcentaje de paquetes recibidos. PHY: capa física. RFD: reduced function device, dispositivo capaz de actuar sólo como dispositivo final debido a sus bajas prestaciones. RPL: protocolo de encaminamiento usado en redes de sensores. RIT: mecanismo de ahorro energético de 802.15.4e en el que un nodo envía periódicamente tramas para saber si algún nodo tiene información para él. Schedule: mecanismo utilizado por los nodos en el que se dicta el comportamiento de un nodo en un timeslot. Scheduler: pila del sistema operativo que utilizan los nodos para guardar futuras transmisiones/recepciones de paquetes. Slotframe: conjunto de timeslots que se repiten en el tiempo. Delimitado por EBs. Timeslot: unidad fija en el tiempo en el que los nodos efectúan una acción dependiendo del schedule asignado. TSCH: modo de funcionamiento de 802.15.4e en el que todos los nodos siguen un schedule concreto.


REFERENCIAS [1] Telos (Rev B) : PRELIMINARY Datasheet (12/5/2004) < http://moss.csc.ncsu.edu/~mueller/rt/rt11/readings/projects/g4/datasheet.pdf> [2] IEEE Standard Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless. Personal Area Networks (LR-WPANs). <http://standards.ieee.org/findstds/standard/802.15.4-2006.html> [3]IEEE Standard Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs). Amendment 1: MAC sublayer <http://standards.ieee.org/findstds/standard/802.15.4e-2012.html > [4] OpenWSN Confluence: <https://openwsn.atlassian.net/> [5] 6tsch bitbucket <https://bitbucket.org/6tsch/> [6] Proyecto OpenWSN <https://github.com/openwsn-berkeley/> [7] OpenWSN overview <https://openwsn.atlassian.net/wiki/download/attachments/1081520/overview.pptx?version=1&modificationDate=1353383938352&api=v2> [8] 6tsch basic <http://tools.ietf.org/html/draft-vilajosana-6tsch-basic-01> [9] Time Slotted Channel Hopping System <https://mentor.ieee.org/802.15/dcn/08/15-08-0582-02-004e-time-slotted-channel-hopping-system.ppt> [10] 6tsch architecture <http://tools.ietf.org/html/draft-thubert-6tsch-architecture-02> [11] 6top <http://tools.ietf.org/html/draft-wang-6tsch-6top-00> [12] OpenWSN Jira <https://openwsn.atlassian.net/secure/Dashboard.jspa> [13] Bluetooth 4.0: Low Energy <http://chapters.comsoc.org/vancouver/BTLER3.pdf>

Anexos 53

ANEXOS

ANNÈX A INSTALACIÓN DEL PROYECTO OPENWSN

En este anexo se explican los pasos a seguir para instalar OpenWSN. Este proyecto está ubicado en un repositorio de github. Github es una plataforma que permite alojar proyectos que pueden ser públicos o privados. Utiliza el sistema de control de versiones de Git. Por lo tanto se requiere de un cliente Git que permita acceder a un respositorio para descargar un proyecto o nuevas actualizaciones, o subir cambios.

A.1.1 Descarga del proyecto

1. El cliente escogido es TortoiseGit (http://code.google.com/p/tortoisegit/downloads/list).

2. Descargar e instalar el software PuTTY y PuTTYgen

(http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html). Una vez instalado se deben generar dos claves (una pública y otra privada) SSH. Para hacer este paso se ejecuta PuTTYgen.

3. Descargar Msysgit

4. Crear una cuenta GitHub

5. Una vez creada la cuenta GitHub, hacer login e introducir la clave pública SSH generada en el segundo punto.

6. Crear un directorio donde OpenWSN será descargado. Por ejemplo en C:\openwsn

7. Una vez creado, entrar en el directorio (C:\openwsn) y hacer click derecho en el directorio vacío. Seleccionar Git Clone.

8. Cuando pida la dirección a ser clonada se debe introducir las siguientes URLs (sólo deja poner una dirección, repetir los pasos 8, 9 y 10 para las 5 carpetas del proyecto):

a. https://github.com/openwsn-berkeley/openwsn-fw b. https://github.com/openwsn-berkeley/openwsn-sw c. https://github.com/openwsn-berkeley/openwsn-hw d. https://github.com/openwsn-berkeley/openwsn-docs

e. https://github.com/openwsn-berkeley/openwsn-utils

9. Hacer click en Load PuTTY Key y se busca la clave privada generada con el PuTTY gen

10. Finalmente hacer click en aceptar

https://github.com/openwsn-berkeley/openwsn-fw

https://github.com/openwsn-berkeley/openwsn-sw

https://github.com/openwsn-berkeley/openwsn-hw

https://github.com/openwsn-berkeley/openwsn-docs

https://github.com/openwsn-berkeley/openwsn-utils


A.1.2 Instalación de elementos adicionales Una vez descargado el proyecto se deben instalar otros elementos para poder realizar pruebas posteriormente. El siguiente paso es instalar Python. La versión de Python que se debe descargar es la 2.7. Se puede descargar en http://www.python.org/download/ Una vez se ha instalado Python, se instala PySerial. Es una extensión que Python necesita para comunicarse por un puerto serial virtual. La versión a instalar es la 2.6 para que sea compatible con Python 2.7. Por último se instala SCons. Este software es una herramienta de construcción como el make. Está escrita en Python y va a permitir compilar el firmware de OpenWSN en los nodos TelosB. Para instalarlo, se puede utilizar la herramienta easy_install que permite instalar o actualizar herramientas en Python. El ejecutable easy_install debe estar en el directorio de Python/Scripts/. Una vez instalado, instalar SCons es tan sencillo como ejecutar el siguiente comando en el cmd: <C:\Python27\Scripts> easy_install scons Una vez instalado SCons, ya están todas las herramientas listas para proceder a poner en funcionamiento la red con los sensores.

ANNÈX B PUESTA EN MARCHA DEL ESCENARIO Una vez se tienen todo el software necesario para comenzar a realizar las pruebas. Primero se debe conectar los nodos al PC mediante un cable USB. Los drivers se instalarán automáticamente y cuando esto suceda, desde el administrador de dispositivos se podrá ver que hay puertos COM activos.

Fig. 43Los puertos COM6 y COM7 hacen referencia a dos nodos TelosB conectados por USB al PC

El siguiente paso es instalar el firmware de OpenWSN en los nodos. Tal y como se ha dicho antes, se realizará mediante la herramienta SCons. Se abre la consola de Windows (cmd) y accede al directorio de firmware del proyecto de OpenWSN. Si el proyecto se bajó en C:\openwsn tal y como se explicó en el primer anexo, la carpeta del firmware está en C:\openwsn\openwsn-fw. Una vez dentro del directorio se ejecuta el siguiente comando: <C:\openwsn\openwsn-fw>scons board=telosb toolchain=mspgcc bootload=COM6 oos_openwsn

http://pypi.python.org/packages/source/p/pyserial/pyserial-2.6.tar.gz

https://pypi.python.org/pypi/setuptools

Anexos 55

En el campo bootload se debe especificar el puerto COM en el que se quiere hacer la instalación. En este caso se compilaría el firmware y se instalaría en el nodo que tiene el puerto COM6. Para instalar el firmware en el otro nodo se debe repetir el comando cambiando bootload=COM6 por bootload=COM7. Si todo va según lo previsto, este proceso durará unos cuantos segundos y después terminará diciendo que se ha instalado correctamente.

Fig. 44 Mensajes de consola al compilar el firmware en un nodo

Una vez ambos nodos tienen instalado el firmware el siguiente paso es ejecutar el software OpenVisualizer para poder establecer un DAG root. Para ello hay que acceder a la carpeta de software del proyecto OpenWSN, recibe el nombre openwsn-sw. Para ejecutar el OpenVisualizer se debe acceder al directorio openwsn-sw/software/openvisualizer/bin/openVisualizerGui. Dentro se encuentra el archivo openVisualizerGui.py. Si se abre y se ejecuta se mostrará la interfaz gráfica el software.


Fig. 45 OpenVisualizer. En la pestaña de motes se pueden ver los nodos que están conectado mediante un puerto COM

En la Fig. 45 se muestra que hay dos nodos conectados al PC vía USB. En la pestaña de motes aparecen todos estos nodos. Para cada uno de ellos se muestra información sobre el Schedule, sus vecinos, la cola e información de la PAN. El último paso es poner uno de los nodos sensores como DAG root. Para ello se pulsa el botón "toggle" que hay en el recuadro de DAGroot del OpenVisualizer.

Fig. 46 OpenVisualizer. Información para cada uno de los nodos

Cuando el nodo pasa a ser DAG root, la casilla isSync cambia para tener valor 1. Además, la plataforma hardware pasará de tener un led amarillo a uno azul. Esto significa que el nodo está sincronizado. En la siguiente figura se pueden ver estos dos estados (Fig. 47).

Anexos 57

Fig. 47 En la izquierda: el nodo sensor de la izquierda actúa como DAGroot, está sincronizado, sin embargo el nodo de la derecha aún no se ha sincronizado. En la

derecha: el nodo de la derecha a pasado a estar sincronizado, ambos tienen el led azul

ANNÈX C ARCHIVOS MODIFICADOS PARA LAS IMPLEMENTACIONES

En este anexo se va a hablar de los archivos que se han modificado para realizar las implementaciones. El proyecto OpenWSN tiene una serie de aplicaciones que pueden ser instaladas en los nodos que se pueden encontrar en el directorio openwsn/openwsn-fw/firmware/openos/openwsn/07-App. La aplicación siempre será instalada en un nodo que no sea DAGroot. A continuación se muestra una tabla con las distintas aplicaciones utilizadas:

Tabla 13 Aplicaciones utilizadas en las implementaciones del proyecto

Nombre de la aplicación Descripción

rex

Envía paquetes CoAP a un servidor de Berkeley. Se puede configurar el tiempo entre envío de los paquetes y su tamaño


udpLatency Envía paquetes UDP que permiten calcular la latencia en número de timeslots del paquete

udprand Envía paquetes UDP, permitiendo especificar el tiempo entre envío de paquetes y la longitud de los mismos

udpstorm

Envía paquetes UDP, se puede especificar el tiempo entre envío entre envío de paquetes, la longitud de los paquetes y el número de paquetes a enviar. Una vez se han enviado el número de paquetes especificado no realiza más transmisiones con esta aplicación.

Para habilitar o deshabilitar estas aplicaciones se debe abrir el archivo openwsn.c (situado en openwsn/openwsn-fw/firmware/openos/openwsn). Este archivo define todas las capas que serán instaladas cuando se compile el firmware mediante SCons. La estructura de este archivo comienza con una serie de #include donde se importan los archivos especificados. Posteriormente está la función openwsn_init() donde se inicializan cada uno de los componentes con una función. Para agregar una aplicación al compilar el firmware se debe tener el #include y la función que inicia la aplicación descomentada. Por ejemplo, si se quiere utilizar la aplicación rex, el archivo debería quedar de la siguiente manera:

/** \brief General OpenWSN definitions \author Thomas Watteyne <[email protected]>, September 2012 */ #include "openwsn.h" //===== drivers #include "openserial.h" //===== stack //-- cross-layer #include "idmanager.h" #include "openqueue.h" #include "openrandom.h" #include "opentimers.h" //-- 02a-TSCH #include "IEEE802154E.h"

… … …

//-- CoAP

Anexos 59

#include "rleds.h" //#include "rt.h" #include "rex.h" //#include "rheli.h" //#include "rrube.h" //#include "rxl1.h" //#include "layerdebug.h" void openwsn_init() { //===== drivers openserial_init(); //===== stack //-- cross-layer idmanager_init(); // call first since initializes EUI64 and isDAGroot openqueue_init();

… … …

//-- CoAP //rleds_init(); //rt_init(); rex_init(); //rheli_init(); //rrube_init(); //rxl1_init(); //layerdebug_init();

Además de añadir aplicaciones, ha sido necesario modificar parámetros del 802.15.4e, de la capa 6top y del Scheduler del sistema operativo. A continuación se muestran los cambios realizados. En el archivo IEEE802154E.c, ubicado en el directorio llamado 02a-MAClow, se encuentra una función llamada calculateFrequency (línea de código 1737). Retorna dos posibles valores: un valor constante o un valor que varía. El valor constante implica desactivar el uso del channel hopping. De lo contrario, retorna 11+(ASN+channelOffset)%16, un rango de canales entre el 11 y el 26. La capa 6top está implementada en la carpeta 02b-MAChigh. Son un conjunto de archivos escritos en C. En el archivo schedule.c y schedule.h está la configuración del scheduling que tendrá el nodo. Se puede modificar los parámetros de la slotframe, indicando el tipo de celdas que tendrá cada timeslot (ADV; TXRX, SERIAL). En el archivo res.c se define, entre otras cosas, el tiempo entre envío de mensajes EB que facilitan la sincronización de los nodos que se quieren incorporar en la red. Este valor se puede hacer variar en la función timers_res_fired() (línea 172).

trabajo de final de grado€¦ · trabajo de final de grado tÍtulo del tfg:estudio de las...

Documents