LEMR-CEL: Protocolo Multicapa Multicanal para Aplicaciones ...

1

LEMR-CEL: Protocolo Multicapa Multicanal para Aplicaciones Multimedia en

Redes Inalámbricas de Sensores con Topología Radial

OSCAR CAMILO VALDERRAMA RIVEROS

Trabajo de grado para optar por el titulo de:

Magister en Ingeniería Electrónica y de Computadores

Asesor:

Néstor Misael Peña Traslaviña

UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIERIA

DEPARTAMENTO DE INGENIRIA ELECTRICA Y ELETRONICA

BOGOTA D.C. -2012

2

AGRADECIMIENTOS

En primer lugar quiero agradecerle a Dios, que siempre me dio las fuerzas para seguir

adelante. Luego a mis papas los cuales me apoyaron, aconsejaron y ayudaron durante

todo este proceso. A mi asesor Dr. Néstor Peña, por toda la asesoría brindada.

3

Contenido

1. INTRODUCCION ..............................................................................................................................4

2. OBJETIVOS ......................................................................................................................................5

2.1 OBJETIVOS GENERAL ................................................................................................................5

2.2 OBJETIVOS ESPECIFICOS ...........................................................................................................5

3. MARCO TEORICO ............................................................................................................................6

3.1 CONCEPTOS BASICOS ...............................................................................................................6

3.2 REVISION ESTADO DEL ARTE DE LAS FUENTES DE TRÁFICO MULTIMEDIA .............................11

3.3 REVISION ESTADO DEL ARTE DE LOS PROTOCOLOS PARA TRÁFICO MULTIMEDIA. ................14

4. IMPLEMENTACION DE FUENTES DE TRÁFICO MULTIMEDIA ........................................................20

5. DISEÑO DEL PROTOCOLO .............................................................................................................32

5.1 LEMR ......................................................................................................................................32

5.2 LEMR-Multichannel ................................................................................................................33

5.3 LEMR-Cel ................................................................................................................................35

5.4 PROGRAMACION LEMR-Cel EN QUALNET ..............................................................................38

6. RESULTADOS ...............................................................................................................................42

7. CONCLUSIONES ............................................................................................................................48

8. REFERENCIAS ................................................................................................................................50

4

1. INTRODUCCION

El uso de las redes inalámbricas de sensores, Wireless Sensor Networks (WSN), ofrece

ventajas importantes porque al disponer de fuente de alimentación propia no dependen

de los recursos energéticos del área, ofrecen una gran movilidad y pueden ser instalados

en cualquier sitio. Estas redes están compuestas por un número finito de dispositivos,

llamados nodos, los cuales se comunican entre sí con el fin de transmitir datos, por

ejemplo información de sensores, hacia un sumidero (sink) [1].

Los nodos se pueden ubicar en diferentes lugares para crear diferentes topologías, una de

estas se conoce con el nombre de Long-Thin, en español topología radial [2]. Esta

topología tiene características únicas, entre estas se encuentra la facilidad de modelar

escenarios reales, como las calles de una ciudad.

Normalmente las redes inalámbricas de sensores están diseñadas para tráfico liviano es

decir, para datos procedentes de sensores escalares como sensores de movimiento, luz o

sonido. Adicional al tráfico liviano existe el tráfico pesado como el multimedia, el cuál

requiere caudales más elevados y retardos pequeños para satisfacer la calidad del servicio

de una transmisión en tiempo real.

Este proyecto de grado pretende el diseño, implementación y validación de un protocolo

en la capa MAC utilizando la herramienta de simulación Qualnet® [3], para aplicaciones

multimedia en redes inalámbricas de sensores con topología radial. Este documento

empieza con la descripción general de las redes WSN. Continuando con la revisión del

estado del arte de las fuentes de tráfico multimedia y los protocolos para aplicaciones

multimedia. Posteriormente la implementación de las fuentes. Siguiendo con el diseño,

implementación y resultados del protocolo propuesto. Finalizando con las conclusiones.

5

2. OBJETIVOS

2.1 OBJETIVOS GENERAL

Desarrollar un protocolo para la capa MAC con la herramienta QualNet® para redes

inalámbricas de sensores, con el fin de implementar monitoreo en redes utilizando la

topología radial para la transmisión de tráfico multimedia.

2.2 OBJETIVOS ESPECIFICOS

Diseño e implementación del protocolo en la capa MAC utilizando una

herramienta de simulación.

Caracterización e implementación de las fuentes de tráfico.

Creación de escenarios con topología radial, variando parámetros como número

de nodos y distancia entre éstos.

Validación e implementación del protocolo.

Análisis de los resultados obtenidos utilizando la plataforma de simulación.

6

3. MARCO TEORICO

3.1 CONCEPTOS BASICOS

Una WSN, en su forma mas básica es una red de comunicaciones, por lo que hereda todas

las características de éstas. Es decir, tiene como función básica, el intercambio de

información entre los miembros de la red. Para este fin las WSN utilizan la comunicación

inalámbrica [4] en otras palabras, el medio de transmisión es el aire, haciendo uso de

ondas electromagnéticas. Los datos se agrupan en paquetes, cuyo tamaño puede variar

dependiendo del tipo de información a enviar. En la figura 1 se observa la típica

representación de la comunicación entre dos dispositivos.

Figura 1. Comunicación inalámbrica de dos dispositivos.

Normalmente las WSN tienen dos tipos de dispositivos, nodos y sumideros. Los nodos

están equipados con sensores los cuales, envían la información censada hacia el sumidero.

Por lo que se ve el sumidero como el centro de recibo de la información. Los nodos

cuentan con alimentación propia, generando gran movilidad, pero a costa de tiempo de

vida y capacidad de cómputo. A diferencia del sumidero los cuales normalmente no

7

cuentan con estas limitaciones. Algunos de estos nodos son: Ambient µ [5], MICAz [6] y

TelosB [6].

En la figura 2 se puede observar la topología de una WSN. La cual está compuesta por 4

nodos y 1 sumidero. Los nodos se comunican punto a punto con el objetivo de llegar al

sumidero. Es normal en este tipo de redes las congestiones y las colisiones. Con el fin de

medir el comportamiento de la red existen parámetros de desempeño.

El primero de estos se conoce como el retardo, el cual es el tiempo entre la salida y la

llegada del paquete. Como no todos los paquetes llegan al mismo tiempo se introduce el

concepto de Jitter, el cual es la variación entre los retardos. Para medir el tráfico se define

el termino Caudal o Throughtput, el cual es la cantidad de datos transmitidos o recibidos

en un periodo de tiempo, normalmente se expresa en bits por segundo (bps).

Figura 2. Topología de WSN.

Con el objetivo de simular un protocolo en Qualnet®, se hace uso del diseño multicapa, el

cual se podría asimilar a la arquitectura OSI [4], la cual es ampliamente usada en las redes

de sensores. El diseño se hace al aplicar una abstracción al sistema y dividirlo en secciones

llamadas capas. Donde cada sección se encarga de un servicio específico [8]. En Qualnet®

5.0 se encuentran 5 capas (Figura 3): Aplicación, transporte, red, control de acceso al

medio y física. Qualnet® en todas las capas ofrece protocolos desarrollados y validados

por el fabricante.

8

Figura. 3. Interacción de las capas en Qualnet®. Tomado de [8].

En la capa física se representa el hardware es decir las antenas, el medio, los radios, etc.

La capa MAC, es la encargada de programar el método para el acceso al medio. La capa de

red tiene la función de definir el destino de los paquetes y la ruta a seguir. Para simplificar

esta capa se hace una subdivisión en donde la capa de enrutamiento (Routing), es la

encargada de definir la ruta por la cual, el paquete debe de ir para llegar a su destino. La

siguiente capa se llama transporte, en está se hace la conexión entre la red y las posibles

aplicaciones que se estén ejecutando. Por último esta la capa de aplicación, como su

nombre lo indica, están las aplicaciones que se van a realizar en los nodos.

Debido a la gran movilidad de los nodos es posible tener varias topologías. El estándar

IEEE 802.15.4 [9] soporta tres tipos diferentes de topologías (Figura 3): Estrella, Punto a

Punto y Agrupación de Árbol (Cluster Tree). Como se había presentado anteriormente,

existe otra topología la cual no está especificada en el estándar, la cual es la topología

radial [2].

9

Figura 3. Ejemplo de topologías soportadas por la norma IEEE 802.15.4. Adaptado de [2].

En la topología Radial, o Long Thin, los nodos forman caminos lineales (Figura 4), cuyo

objetivo es extender la red para cubrir las áreas deseadas, formando una sóla ruta desde

la fuente hasta el sumidero. Con este tipo de topología es muy sencillo modelar diferentes

escenarios reales, como por ejemplo las calles de una ciudad [10].

Debido a su característica, un sólo camino al sumidero, es muy probable que se presenten

congestiones en los puntos donde dos o más rutas convergen, por lo que a la hora de

transmitir grandes caudales es muy probable la presencia de retardos en estos puntos.

Otro concepto importante de exponer es el que hace referencia al tipo de comunicación.

Esta el camino simple y multi-camino (Figura 5). En el camino simple como su nombre lo

indica existe solo una ruta entre el nodo sensor y el sumidero. Mientras que en el multi-

camino existe más de una ruta al sumidero. En la figura 5, se puede apreciar tres distintos

caminos, todos cumplen con la función de comunicar el nodo sensor con el sumidero, es

de esperar que cada camino tenga características diferentes.

10

Figura. 4. Ejemplo topología Radial o Long-Thin. Adaptado de [2]

.

Figura 5. Modelo de comunicación multi-camino

11

3.2 REVISION ESTADO DEL ARTE DE LAS FUENTES DE TRÁFICO

MULTIMEDIA

El tráfico multimedia es la combinación entre tráfico de datos, voz y video. Por lo que se

modela como la combinación de estos tres tráficos, es decir se utilizan 3 fuentes

diferentes una para datos, otra para voz y la última para video.

El primero [11] consiste en el modelo del tráfico multimedia como la suma de 3 tráficos

(Figura 6). En este estudio los 3 tráficos corresponden a voz sobre IP (VoIP), aplicaciones

de video las cuales utilizan el codec MPEG y sesiones Web.

Figura 6. Modelo fuente de tráfico adaptado de [11]

Para cada tráfico en [11] se establece un modelo. El primero es el de VoIP, para esta

aplicación se utiliza el modelo de Markov de dos estados (ON y OFF) con parámetros α y β.

En lo que respecta al video se conoce que estas fuentes tiene tasas de bits variables, por

lo que se usa el modelo de encolamiento M/G/∞. Por último está el modelo de sesiones

web, el cual se modela como una fuente ON-OFF, donde se utiliza la distribución normal

para el número de página, y Pareto para el tamaño en ON y el tiempo en OFF.

Siguiendo con el modelo de varias fuentes para representar el tráfico está [12], en el cual

en vez de tener varias aplicaciones, se trabaja con los patrones de tráfico (Figura 7).

Donde para el tráfico de datos se presenta como tráfico en bloque (Block traffic), este

tráfico se caracteriza por enviar pocos paquetes pero de gran tamaño. Para voz como

tráfico de transacción (Transaction traffic), para la cual hay dos periodos (Encendido y

12

Apagado); en encendido (ON) se envía varios pequeños paquetes, mientras que en

apagado (OFF) no se transmite nada. Por último video como un tráfico de transmisión

(Streaming traffic), en el cual se envían mucho paquetes de tamaños variables.

Figura 7. Patrones de tráfico, adaptado de [12].

Con el fin de modelar el tráfico de bloque, se utiliza las funciones de distribución:

exponencial, weibull, Pareto, normal, log normal, distribución discreta de poisson y la

geométrica. Para el tráfico de transacción se utilizan las mismas distribuciones

anteriormente expuestas para definir el tiempo de sesión, el periodo de ON y OFF, el

tamaño del paquete y el tiempo de llegada de los paquetes en el periodo de encendido.

Para modelar el tráfico de transmisión se describen cuatro alternativas. La primera es una

fuente con tasa constante de bit (CBR), en la cual se define la tasa. La segunda una fuente

con tasa variable de bit utilizando el modelo auto regresivo [13]; el tercero como una

13

fuente variable de bit utilizando el modelo F-ARIMA (Fractional ARIMA) [14]; y el cuarto

como una fuente variable de bit utilizando el modelo de ondas [15].

Como se puede observar, todas estas fuentes son basadas en modelos, los cuales fueron

estimados a partir de datos reales, lo que nos lleva al trabajo realizado en [16]. El cual se

basa en trazas reales utilizando el codec H.264, lo cual ofrece una guía para la simulación

de fuentes. Por lo que en este documento se explica de manera detallada el

funcionamiento general del codec, el procedimiento de generar tráfico de paquetes de

video basados en trazas de video reales. Adicionalmente los autores cuentan con una

página web [17], la cual provee una variedad de trazas ofrecidas al público en general para

la investigación.

Se escogió el trabajo realizado en [16], debido a dos razones: la primera es que es

reciente, y la segunda consiste en que lo anteriores trabajos son modelos, que tienen

como objetivo crear una aproximación al tráfico real. Mientras que en [10] se esta

trabajando con tráficos reales lo cual garantiza resultados mas acordes a la realidad. En la

sección 4, se explicara en detalle este trabajo.

14

3.3 REVISION ESTADO DEL ARTE DE LOS PROTOCOLOS PARA TRÁFICO

MULTIMEDIA.

Como se dijo anteriormente las redes inalámbricas de sensores están diseñadas para

tráfico liviano. Se han desarrollado para este tipo de tráfico varios protocolos,

especialmente en la capa de acceso al medio (MAC), como es el caso de S-MAC [18], T-

MAC [19] y SCP-MAC [20].

De manera similar para tráfico pesado se han desarrollado varios protocolos, con el fin de

satisfacer la calidad del servicio de una transmisión en tiempo real [4].

Una primera posible solución para la transmisión de tráfico multimedia, consiste en

enfocarse en la capa de enrutamiento, donde se han desarrollado varios protocolos como

Multimedia Reliable Energy Efficient Routing Protocol (MREEP) [21] y el Multipath Data

Transfer (MPDT) [22].

En Multimedia Reliable Energy Efficient Routing Protocol [21] el objetivo es la creación de

dos tablas de enrutamiento, una para tráfico en tiempo real y otra para tráfico en tiempo

no real. Gracias a estas tablas, se garantiza que la red conserve recursos energético,

porque cada tipo de tráfico implica un consumo diferente de energía, es decir que al tener

varias rutas, no se concentrara el consumo de energía en los mismos nodos. Para construir

estas dos tablas, el protocolo tiene tres fases.

En la primera fase el nodo sumidero envía paquetes a todos los nodos en donde cada uno

es informado de su tarea. La segunda fase consiste en la transmisión de un paquete desde

un nodo sensor, quien lo envía a sus vecinos. Este paquete será retransmitido de nuevo a

los vecinos del nodo que lo recibe, hasta llegar al nodo sumidero. En la tercera fase el

nodo sumidero obtiene la información de todas las retransmisiones de este paquete, por

lo que está en la capacidad de crear ambas tablas de enrutamiento, las cuales son

enviadas a los nodos que conforman estas rutas.

15

En el Multipath Data Transfer [22] la idea es enviar los datos por diferentes caminos al

mismo tiempo, con el fin de mejorar la transmisión y de ahorrar energía. La selección de

estos caminos se basa en la distancia al sumidero y en la energía restante del nodo, por lo

que nodos con baja energía son descartados. El proceso de creación de rutas es simple, el

nodo transmisor envía paquetes hacia los vecinos ubicados a una distancia de un salto. Si

el nodo receptor cuenta con energía superior al límite establecido, éste reenvía el paquete

hasta llegar el sumidero. Luego el sumidero envía un paquete hacia el nodo transmisor

con lo cual este puede determinar las rutas. A cada ruta se le asigna un valor de energía y

las características de calidad de servicio asociadas.

El MREEP y el MPDT están diseñados para tráfico multimedia, ambos parten de topologías

donde existe más de un camino al sumidero, por lo que pueden evitar las congestiones.

A diferencia de lo anterior, en la topología radial sólo existe un camino por lo que el

protocolo de enrutamiento es simple y se podría implementar sin ningún problema un

enrutamiento estático, lo que significa que el diseño del protocolo se debe realizar en la

capa MAC. De hecho, como se mencionó al comienzo de esta sección, existen varios

protocolos en capa MAC para tráfico liviano pero también, recientemente se han

desarrollado en ella protocolos para tráfico multimedia, específicamente protocolos

multicanal. Estos protocolos son: Clustered On-Demand Multi-channel (COM-MAC) [23],

Multifrequency Media Access Control for Wireless Sensor Networks (MMSN) [24], Self-

Organizing Multi-Channel Medium Access Control (SMMAC) [25], Multi-Channel

Lightweight Medium Access Control (MC-LMAC) [26] y Y-MAC [27], los cuales se explican a

continuación.

Clustered on-demand multi-channel MAC [23], como su nombre lo indica es un protocolo

para redes con topología tipo agrupación de árbol, cuyo objetivo es la transmisión de

aplicaciones multimedia. En este protocolo existen tres tipos de nodos: sensores, líderes

de grupo (Cluster Head) y sumidero. Después de formados los grupos, el líder de grupo

organiza sus operaciones en intervalos de tiempo, donde cada intervalo consta de tres

sesiones: petición (request), programación (scheduling) y transmisión de datos (data

16

transmission). En las dos primeras sesiones se hace uso de una única frecuencia

(frecuencia de control), mientras que en la última sesión se utilizan varias frecuencias.

En la primera sesión cada nodo sensor envía un paquete de petición al líder de grupo,

especificando los parámetros de calidad del servicio que requiere como, la cantidad de

multimedia a transmitir (duración de la transmisión), el tiempo máximo de espera y la

prioridad de la información. En la sesión de programación, el líder del grupo asigna

segmentos de tiempo y frecuencias a los nodos sensores para transmitir los datos en la

tercera sesión.

Por ultimo el desempeño en términos de caudal y retardos de COM-MAC se comparo con

M-TDMA [28], demostrando un desempeño superior de COM-MAC.

Multifrequency media access control for wireless sensor networks [24] es un protocolo de

acceso al medio compuesto por dos fases: asignación de canales y acceso al medio.

En la primera fase existen cuatro diferentes opciones de asignación de canales: asignación

exclusiva de frecuencia (exclusive frequency assignment), selección uniforme (even

selection), escucha secreta (eavesdropping) y consenso implícito (implicit-consensus).

La primera opción, asignación exclusiva de frecuencia, requiere que el número de

frecuencias disponibles sea mayor o igual al número de nodos vecinos a dos saltos.

Después del envió por cada nodo de dos paquetes broadcast se conocerá el número de

identificación (ID) de los vecinos ubicados a dos saltos. El nodo con el menor ID,

comparado con sus vecinos, selecciona la frecuencia más baja y les transmite esta

decisión. Los nodos al recibir esa información seleccionan su frecuencia de operación.

Si existen menos frecuencias que el número total de vecinos a dos saltos, se utiliza la

segunda opción de selección uniforme en la cual, después que los nodos con menor ID

tomen su decisión, los demás nodos, al no encontrar frecuencias disponibles seleccionan

la frecuencia con menor uso.

17

La tercera opción igualmente se utiliza cuando no existan suficientes frecuencias

disponibles. En esta opción los nodos realizan aleatoriamente una espera para la selección

pero mientras esperan, escuchan las decisiones de sus vecinos, por lo que al terminar el

periodo de espera, el nodo selecciona la frecuencia menos usada.

Para la cuarta opción, se requiere que el número de frecuencias disponibles sea mayor al

número de nodos vecinos a dos saltos. Para la asignación de las frecuencias, cada nodo

realiza una operación de cómputo local basada en la generación de números aleatorios

utilizando como semilla el ID del nodo.

En la segunda fase, acceso al medio, cada nodo tiene dos intervalos de tiempo, uno para

paquetes broadcast y otro para paquetes unicast. En cada intervalo el nodo debe

competir por la frecuencia es decir, para enviar un paquete primero verifica si la

frecuencia asignada está ocupada, de no estarlo transmite el paquete o de lo contrario,

espera hasta el siguiente intervalo de tiempo.

El desempeño de este protocolo fue comparado en términos de caudal, retardos y

consumo de energía contra CSMA [29], en donde se demostró un desempeño superior de

MMSN.

Self-Organizing Multi-Channel Medium Access Control [25], tiene como objetivo asignar

varios canales para la transmisión simultánea de datos. Para este fin se utilizan dos

paquetes de datos para la asignación de canales: Request Tune to Channel (RTC) y Channel

to Send (CTS). El RTC lo envía el nodo transmisor al receptor donde se específica cuales

canales de frecuencias quiere utilizar y el número de paquetes a enviar. Para saber cuáles

frecuencias puede usar, el nodo transmisor censa el medio buscando frecuencias

ocupadas. Al llegar este paquete al receptor, éste verifica cuales frecuencias están

disponibles y envía el CTS confirmando las frecuencias que puede utilizar. Después el nodo

transmisor envía un acuse de recibo con lo cual cambia a la frecuencia asignada para

empezar la transmisión. El desempeño del caudal de este protocolo se comparo con B-

MAC [30], en donde SMMAC fue superior.

18

Multi-Channel Lightweight Medium Access Control [26], como su nombre lo indica es un

protocolo basado en LMAC [31]. Este protocolo está diseñado para redes tipo agrupación

de árbol en las cuales, para el acceso al medio se les asigna a los nodos intervalos de

tiempo. Tanto en LMAC como en MC-LMAC, uno de estos intervalos es asignado como el

intervalo común, con el objetivo de enviar paquetes de control, mientras que los demás

intervalos son para la transmisión de datos.

Después de la asignación del intervalo común, cada nodo debe seleccionar un intervalo de

tiempo propio con el objetivo de transmitir datos. Para este fin, cada nodo selecciona

aleatoriamente un intervalo e informa al padre su selección. De estar disponible el

intervalo, el padre envía un acuse de recibo confirmando que puede usarlo. Si el intervalo

seleccionado no está disponible el nodo seguirá seleccionando otro intervalo hasta

encontrar uno. En LMAC esto significa que si todos los intervalos están ocupados el nodo

se quedará buscando, por lo que en MC-LMAC, si un nodo selecciona el mismo intervalo

que otro nodo de su grupo pero está a más de dos saltos, el nodo padre le asigna ese

intervalo pero con una frecuencia diferente.

El desempeño de este protocolo fue comparado en términos de caudal y retardo con

CSMA y MMSN, en donde se demostró un desempeño superior de MC-LMAC.

Por último en Y-MAC [27], el tiempo se divide en ciclos, y cada ciclo a su vez se vuelve a

dividir en intervalos, en los cuales estarán las transmisiones de un solo paquete de datos

bien sea broadcast o unicast. En los intervalos broadcast todos los nodos están a la misma

frecuencia en espera de datos. Si un nodo desea transmitir, espera el primer intervalo

unicast y compite por la frecuencia, en caso que otros nodos también quieran transmitir

datos en este intervalo. Después de ganar el medio, si necesita enviar más datos, tanto el

nodo transmisor como el receptor cambian de frecuencia, según un orden prestablecido y

ocupan el siguiente intervalo de tiempo para la transmisión. El desempeño del retardo de

este protocolo se comparo con LPL [32] y Crankshatf [33], en donde Y-MAC fue superior.

Adicional a estos protocolos, recientemente en la Universidad de los Andes se han

desarrollado protocolos en la capa MAC para redes inalámbricas a base de sensores tanto

19

para tráfico liviano como para tráfico multimedia. Estos protocolos son Latency Energy

MAC Routing-LEMR [34] y LEMR-Multichannel [35]. Los cuales serán explicados mas

adelante.

20

4. IMPLEMENTACION DE FUENTES DE TRÁFICO MULTIMEDIA

Un video consiste en una secuencia de imágenes, conocidas con el nombre de cuadros

(frames), generalmente tienen tamaños grandes por lo que es necesario el uso del codec

con el fin de disminuirlos. Actualmente el codec H.264 SVC [16] es muy utilizado. El codec

codifica los cuadros en tres tipos I, P o B. Los tipos I son cuadros codificados directamente

de las imágenes del video, por lo que son datos de mayor tamaño. Los tipos P son creados

a partir de predicciones de un cuadro tipo I o de un cuadro de la secuencia original. Por lo

que su tamaño es menor. Por último están los tipos B, los cuales se obtienen de la

predicción ente dos cuadros, pueden ser tipo I o P en el modelo de predicción clásico,

pero en SVC se pueden obtener a partir de otro tipo B. Es decir que el orden de

codificación para H.264 SVC sería el siguiente, por ejemplo (Figura 8):

La ventaja que se obtiene con SVC, es la reducción del tamaño de los cuadros y una

mejora en el proceso de codificación y decodificación.

Figura 8. Predicción del cuadro tipo B, adaptado de [16]

Ahora observando un poco más la figura 8, es posible interpretar el significado de las

flechas. Las cuales son las capas temporales que se necesitan para la codificación. En la

21

figura 8 se puede apreciar que se necesitan 5 capas temporales para la codificación de

todos los cuadros. En la primera capa están los cuadros , en la segunda en la

tercera , en la cuarta y el resto en la quinta.

Un segmento de video se codifica en cuadros I, P o B, a esta estructura se le conoce con el

nombre de GoP, el cual se denota con el símbolo GgBb. Donde g es el número de cuadros

tipo B entre el número b de cuadros I o P. Por ejemplo G13B3, significa que hay 13

cuadros B entre 3 cuadros I o P. Entre mas cuadros I es mejor la calidad, pero también es

mayor el tamaño de los datos. Lo que crea una competencia entre tamaño y calidad.

Adicional a la codificación en cuadros, H.264 SVC soporta escalabilidad en capas, esta

consiste en codificar las capas temporales, llamadas de ahora en adelante capa base, con

una o varias capas de mejoramiento.

El primer tipo de escalabilidad se conoce con el nombre de escalabilidad temporal. Gracias

a ésta es posible una adaptación de la frecuencia de los cuadros. Porque esta permite la

eliminación de capas temporales, siendo menos los cuadros utilizados. Aunque al eliminar

cuadros se pierde calidad de video.

La segunda se llama escalabilidad espacial. Ésta genera diferentes resoluciones de los

cuadros, lo que significa que tanto la capa base como las capas de mejoramiento pueden

estar a diferentes resoluciones, lo cual no afecta la resolución final del video.

La tercera es CGS (Coarse Grain Scalability) puede proveer hasta 8 capas de

mejoramiento, las cuales mejoran la relación señal a ruido de los cuadros. Las últimas

capas necesitan de las primeras, por ejemplo la tercera capa de mejoramiento necesita,

tanto de la capa base como la primera y segunda capa de mejoramiento para su

codificación.

Además de la escalabilidad por capas, también existe la escalabilidad de calidad, Medium

Grain Scalability (MGS). Según la calidad, ésta se divide en varias capas de mejoramiento,

lo que significa que todas las capas de mejoramiento sumada a la capa base, pueden llegar

22

a aproximarse a la codificación de una sola capa. Se pueden sacrificar capas de

mejoramiento con el fin de obtener una calidad inferior para obtener un menor caudal.

Normalmente las trazas contienen el tamaño del paquete y el tiempo del video, las cuales

varían dependiendo de la escalabilidad. Adicional a esto están unos pequeños paquetes

de información necesaria para la codificación conocidos como NALU (Network Abstraction

Layers Units). Al principio de toda codificación se envía un paquete de 200 bytes, y

después con cada cuadro se envía otro NALU, normalmente cada uno de 48 bytes. Por lo

que en la traza es necesario añadir este paquete, para obtener una simulación más real.

Por ultimo en la figura 9, se observa el proceso de captura, codificación, transporte,

decodificación y proyección de un video codificado. De entrada se observa un retraso

entre la codificación y la captura de 15Δ, donde Δ es el intervalo de tiempo entre la

captura de los cuadros. Porque es necesario obtener los cuadros I0 e I16 para codificar.

Debido a que los cuadros en SVL no se envían en orden se paga una penalidad de 3Δ.

Figura 9. Proceso de transmisión en vivo, tomado de [16]

Con el fin de analizar el comportamiento de la fuente multimedia se escogieron tres trazas

[17] pertenecientes a tres segmentos del video Big Buck Bunny [36], el cual tiene una

resolución CIF de (352x288) y un GoP G16B15. El primer segmento corresponde a los

primeros 20 segundos de video (Figura 10). El segundo entre los 7 minutos y los 7 minutos

23

con 20 segundos (Figura 11), una de las partes con más acción del video. Y el tercero son

20 segundos de los créditos (Figura 12).

Para cada secuencia de video se tomaron las trazas con cuatro diferentes configuraciones

del codec: capa sencilla (sin escalabilidad), escalabilidad temporal, CGS y MGS. La capa

sencilla la componen 5 capas temporales, por lo que para la escalabilidad temporal se

eliminó la última capa, con lo que los cuadros por segundo (Frames per second) cambiaron

de 24 a 12. En CGS se codificó la capa base con 2 capas de mejoramiento y en MGS se

codificó la capa base y 6 capas de mejoramiento.

Figura 10. Primer segmento Big Buck Bunny, tomado de [36]

24

Figura 12. Tercer segmento Big Buck Bunny, tomado de [36]

Figura 11. Segundo segmento Big Buck Bunny, tomado de [36]

25

En Qualnet® existe una aplicación llama Trace File-based Traffic Generator (Traffic-Trace)

[26]. En el cual mediante la generación de un archivo tipo trc. La aplicación envía paquetes

con los tamaños asignados en el tiempo asignado. A continuación se observa un ejemplo

del contenido del archivo.

0,66667 47

0,66666 56

0,66667 164

0,66667 288

0,66666 327

En la columna de la derecha está el tiempo de envió del siguiente paquete, y en la

columna de la izquierda se encuentra el tamaño del paquete que se va a transmitir. Por lo

que la transmisión de paquetes será de la siguiente forma: El primer paquete de 47 bytes

se enviará en el tiempo inicial de la aplicación, a los 0.6667 segundos será enviado el

paquete de 56 bytes de tamaño, y de esta manera hasta terminar con el tiempo de la

aplicación o con los paquetes. El último tiempo no es relevante pero no puede ser 0.

En Qualnet® se simuló un escenario simple, el cual consta de dos nodos (Figura 13), con

comunicación alámbrica donde el ancho de banda disponible es de 10 Mbps. Se creo este

escenario con el objetivo de que la red tenga la capacidad suficiente para el transporte de

todos los paquetes, y así observar el comportamiento de la fuente con una mínima

afectación de la red.

Figura 13. Escenario de simulación fuente de tráfico multimedia.

26

A continuación los resultados de las simulaciones:

Capa Sencilla:

A. Primer segmento capa sencilla

B. Segundo segmento capa sencilla

C. Tercer segmento capa sencilla

Tabla I. Resultados capa sencilla

Total Paquetes 483 Paquetes Enviados 483

Total Bytes 57.749 Total Bytes Enviados 57.749

Caudal (Mbps) 23,100 Caudal de Salida (Mbps) 23.001

Paquetes Recibidos 483

Total Bytes Recibidos 57.749

Caudal de Entrada (Mbps) 23.001

Retardo (ms) 1,140

Jitter (ms) 0,140

Segmento 00:00:00-00:00:20

Traza Simulación







Retardo (ms) 1,200

Jitter (ms) 0,220

Segmento 00:07:00-00:07:20

Traza Simulación







Retardo (ms) 1,100

Jitter (ms) 0,120

Segmento 00:08:10-00:08:30

Traza Simulación

27

Escalabilidad Temporal:

A. Primer segmento escalabilidad temporal

B. Segundo segmento escalabilidad temporal

C. Tercer segmento escalabilidad temporal

Tabla II. Resultados escalabilidad temporal







Retardo (ms) 1,180

Jitter (ms) 0,270

Segmento 00:00:00-00:00:20

Traza Simulación







Retardo (ms) 1,300

Jitter (ms) 0,380

Segmento 00:07:00-00:07:20

Traza Simulación







Retardo (ms) 1,100

Jitter (ms) 0,230

Simulación

Segmento 00:08:10-00:08:30

Traza

28

CGS:

A. Primer segmento CGS

B. Segundo segmento CGS

C. Tercer segmento CGS

Tabla III. Resultados CGS







Retardo (ms) 2,500

Jitter (ms) 2,380

Traza Simulación

Segmento 00:00:00-00:00:20


Total Bytes 2.859.139 Total Bytes Enviados 2.859.139

Caudal (Mbps) 1.143,656 Caudal de Salida (Mbps) 1.104.450


Total Bytes Recibidos 2.859.139

Caudal de Entrada (Mbps) 11.041.100

Retardo (ms) 5,700

Jitter (ms) 3,550

Traza Simulación

Segmento 00:07:00-00:07:20







Retardo (ms) 2,000

Jitter (ms) 1,600

Traza Simulación

Segmento 00:08:10-00:08:30

29

MGS:

A. Primer segmento MGS

B. Segundo segmento MGS

C. Tercer segmento MGS

Tabla IV. Resultados MGS







Retardo (ms) 2,800

Jitter (ms) 3,050

Segmento 00:00:00-00:00:20

Traza Simulación



Caudal (Mbps) 1.151,184 Caudal de Salida (Mbps) 1.111.720



Caudal de Entrada (Mbps) 1.111.290

Retardo (ms) 5,700

Jitter (ms) 3,750

Traza Simulación

Segmento 00:07:00-00:07:20







Retardo (ms) 2,400

Jitter (ms) 1,600

Traza Simulación

Segmento 00:08:10-00:08:30

30

Lo primero que se puede observar es el comportamiento del caudal frente a las

secuencias de imágenes. El desempeño de GSC (Tabla III) y MGS (Tabla IV), es similar

porque ambos utilizan capas de mejoramiento. Mientras que en capa sencilla (Tabla I) y

en escalabilidad temporal (Tabla II) son también similares. Porque la escalabilidad

temporal es la capa sencilla, pero sin la última capa temporal conformada por cuadros

tipo B, con lo que se reduce la cantidad de bits. Además debido a que los cuadros tipo I no

se eliminan, los valores máximos se sostienen.

Se espera que en las secuencias con más movimientos, los caudales aumenten. Esto se

observa en la diferencia entre los caudales del segmento 00:07:00 – 00:07:20, con

respecto a los otros dos segmentos. Adicional a esto en el segmento 00:00:00-00:00:20 se

puede observar que en la escena del movimiento del agua, la cual abarca la mayoría de

espacio, se presenta un pico. Porque a pesar de ser una escena sin mucha acción, esta

presente un movimiento en la mayoría del espacio.

En los resultados de la simulación es necesaria una etapa de validación. Para esto en todas

las tablas se observa la columna de nombre traza. En esta columna están los datos

ingresados a la herramienta. Mientras que en la columna de nombre simulación, están los

datos de la simulación. Con el fin de validar las simulaciones se observaron en todos los

casos que, tanto el retardo como el jitter son del orden de los ms, además de que no hay

pérdida de paquetes por lo que todos los datos llegan a sus destinos. Lo que significa que

le escenario creado no introduce retardos a la transmisión, lo cual era de esperar.

La única variación que se observa es en el caudal de entrada y de salida, la cual es

alrededor de un 3%. Ésta obedece a la forma con la que el programa lo calcula.

Básicamente el programa guarda el tiempo entre la salida del primer paquete y del último,

con lo que obtiene el tiempo total. Se divide el total de bytes enviados o recibidos sobre

este tiempo, con lo que se obtiene el caudal. Es normal ver variaciones, debido a que la

herramienta esta basada en simulación por eventos aleatorios, además de los pequeños

efectos de la red sobre la cual se esta simulando. Si bien los retardos son del orden de ms,

31

es de esperar que no todos los paquetes salgan al mismo tiempo y por ende no lleguen

exactamente al mismo tiempo, con lo cual se ve afectado el cálculo del caudal.

Al tener menos cuadros por segundos, la escalabilidad temporal es la simulación con

menos caudal. Aunque al eliminar capas temporales se esta cambiando la calidad del

video. Adicionalmente se observa que los caudales de CGS y MGS tienen valores cercanos.

Siendo MGS la simulación con más caudal, pero es importante recordar que MGS esta con

6 capas de mejoramiento, y CGS solo con 2. Con lo que se podría concluir que se puede

bajar el caudal de MGS sacrificando capas de mejoramiento, sin perder calidad. Mientras

que en CGS si se sacrifican más capas la calidad se vera afectada.

El Δ para las simulaciones capa sencilla, GSC y MGS es el mismo porque tiene el mismo

cuadros por segundos (24), en este caso es igual a 0.04167 segundos. Es decir que cada

0.04167 segundos se envía un cuadro. Mientras que para escalabilidad temporal se reduce

el doble porque tiene la mitad de los cuadros por segundo (12). Ahora se sabe que el

codec introduce un retardo igual a 18 Δ, lo que significa un retraso de 0.75006 segundos al

principio para capa sencilla, GSC y MGS, y 1.50012 segundos para escalabilidad temporal.

Con lo cual se puede concluir que escalabilidad temporal introduce un mayor retardo al

principio.

Por último es importante resaltar la posibilidad de simular el mismo segmento de video

utilizando varias escalabilidades en Qualnet®. Porque al poder simular trazas, se puede

generar un sinfín de simulaciones de fuentes de video, debido a que el códec involucra

muchas diferentes estrategias. Creando variaciones para un mismo secuencia de video,

especialmente en el caudal. Ahora si pensamos en los recursos limitados de las WSN. Es

posible, conociendo el caudal máximo de esta red, utilizar el codec para obtener caudales

que acordes los recursos de la red.

32

5. DISEÑO DEL PROTOCOLO

5.1 LEMR

En LEMR La interferencia en la transmisión es un concepto clave. Se asume que el rango

de interferencia ( ) es igual al rango de transmisión ( . Imaginemos una red lineal

conformada por 5 nodos (4 enlaces), como la de la Figura 14. Lo primero a observar es

que los nodos A y B no pueden transmitir al mismo tiempo. De otra parte, los nodos C y A,

tampoco pueden transmitir al mismo tiempo porque se interfieren en el nodo B, pero D

si puede transmitir al mismo tiempo que A.

Figura 14. Escenario interferencia

En Latency Energy MAC Routing [34], los nodos inyectan paquetes en un periodo de

tiempo delta (Δ), es decir cuando A esté en este periodo ni B ni C pueden estar

inyectando paquetes pero D si puede, lo que significa que B tiene que esperar un periodo

Δ y C dos periodos Δ. Adicional a esto, para que el nodo A pueda volver a enviar paquetes

tiene que esperar a que B y C terminen de inyectar, es decir por lo menos 2 periodos, lo

cual sumado al periodo que él usó, son 3 periodos. El intervalo de tiempo entre una

transmisión y otra se llama el tiempo del ciclo ( .

33

Esta espera sincronizada es el eje del funcionamiento de LEMR, en otras palabras en LEMR

los nodos ubicados a n- saltos inyectan paquetes un periodo delta después que los nodos

a (n-1) saltos, y para volver a enviar paquetes tienen que esperar que los nodos ubicados a

(n-2) saltos terminen su transmisión. En [34] y [37] se define delta como:

( ) ( )

Donde es el tiempo para transmitir un paquete y recibir el acuse de recibo, es el

tiempo de inicio, es el tiempo de procesamiento, y es el tiempo de

propagación.

Adicional al acceso al medio, LEMR cuenta con una estrategia simple de enrutamiento en

la cual un nodo selecciona el vecino con el menor número de saltos al sumidero y de

haber más de un vecino con los mismos saltos, éste selecciona el nodo con la mayor

energía residual.

5.2 LEMR-Multichannel

El protocolo Latency Energy MAC Routing-Multichannel [35], es una extensión de

protocolo LEMR, diseñado para transportar una mayor capacidad de tráfico, en este caso

datos multimedia. Para este fin el protocolo utiliza más de una frecuencia, con lo cual

mientras un paquete de datos va al sumidero los nodos cambian de frecuencia para envíar

otro paquete de datos.

En el LEMR era necesario esperar a que el nodo ubicado a dos saltos terminara de

transmitir para poder inyectar otro paquete, pero en LEMR-Multichannel al cambiar de

34

frecuencia solo es necesario esperar a que el nodo ubicado a un salto de diferencia

termine de transmitir para inyectar otro paquete, por lo que cada frecuencia que se

agrega se necesita un tiempo Δ.

Debido a que cambiar de frecuencia requiere un tiempo el cálculo de Δ se define en [35] y

[37] como:

( ) ( )

Donde es el tiempo para transmitir un paquete y recibir el acuse de recibo, es el

tiempo de inicio, es el tiempo necesario para cambiar de canal, es el tiempo de

procesamiento, y es el tiempo de propagación.

Para no gastar energía por sondear todos los canales de frecuencia, en el LEMR-

Multicahnnel se implementa el temporizador AMCP Timer (Adapative Multi-channel

Polling Timer), el cual dependiendo del tráfico ordena al nodo sondear el canal base o los

canales de frecuencia para transmisión de datos. Básicamente se busca que cuando no

haya tráfico, el AMCP ordene al nodo sondear periódicamente el canal base, mientras que

cuando haya tráfico, se sondeen todos los canales de frecuencias utilizados para la

transmisión.

Otro parámetro importante a definir es el número de frecuencias a utilizar. En LEMR-

Multichannel se busca en un ciclo cambiar frecuencias para transmitir más paquetes por

lo que el número de frecuencias esta relacionado al tiempo del ciclo. Por cada frecuencia

que se agrega se necesita un tiempo Δ, es decir que para sondear dos frecuencias es

necesario 2Δ, por lo que si se expresa , sólo se pueden utilizar N/2 número

de frecuencias.

Con el número máximo de frecuencias fijado, lo siguiente es la asignación de éstas. Si un

nodo desea trasmitir un paquete lo envía por la frecuencia base. Al llegar cada paquete a

35

los nodos, dentro de la ruta, cada nodo activa el AMCP, lo cual hace que los nodos

empiecen a cambiar de frecuencia.

5.3 LEMR-Cel

El LEMR-Cel es una extensión de LEMR-Multichannel, diseñado para redes con topología

radial. El gran cambio en LERM-Cel está en la asignación de canales, en la cual a cada nodo

fuente se le asignan unas frecuencias exclusivas. Es decir, que cada nodo fuente crea una

celda con unas frecuencias determinadas.

En LEMR-Cel, existen dos tipos de nodos que son: los nodos fuente y los nodos de la

columna principal de transmisión. Los nodos de la columna principal de transmisión

utilizan LEMR-Multichannel, es decir utilizan todos los canales de frecuencia fijados para la

transmisión de datos, mientras que en los nodos fuente se usan canales de frecuencias

exclusivos para la transmisión. Es decir que, por ejemplo en los nodos de la columna de

transmisión se fijan 5 frecuencias para transmitir (f0, f1, f2, f3, f4), donde f0 es el canal

base en la cual se transmiten los paquetes de control. En este ejemplo una fuente utiliza

los canales f0, f1 y f3; y la otra fuente f0, f2 y f4. El estándar IEEE 802.15.4 asigna 16

frecuencias en la banda de los 2.4Ghz, por lo que en el ejemplo anterior se pueden asignar

5 frecuencias de las establecidas por le estándar.

Otro parámetro importante es el orden de las frecuencias. En la figura 15, se observa que

se tienen 4 frecuencias disponibles de las cuales cada fuente debe de utilizar dos, ahora el

objetivo es tener esperas menores. Si las frecuencias están seguidas (f1 y f2) se tiene un

periodo de espera de 2Δ; un Δ para transmitir y otro Δ esperando a que el vecino a un

salto termine de transmitir por lo que, entre frecuencias consecutivas existe un periodo

de espera de 2Δ.

Ahora si la siguiente frecuencia no es la consecutiva si no es una frecuencia después (f1 y

f3), el periodo de espera es de 4Δ porque no se transmite en la frecuencia siguiente es

36

decir se espera 2Δ adicionales, los cuales corresponden a la frecuencia en la que se dejo

de transmitir. Siguiendo con esta lógica si la siguiente frecuencia a usar ésta ubicada en

dos posiciones después de la siguiente frecuencia (f1 y f4) el periodo de espera es de 6Δ

porque se dejó de transmitir en dos frecuencias consecutivas, es decir 4Δ debido a que no

se transmitió en estas frecuencias sumando 2Δ el cual es el periodo de espera mínimo.

Por lo anterior, se decidió que las frecuencias se asignarían intercaladas, con lo que se

obtiene esperas entre 2Δ y 4Δ. Por lo que, de las 4 frecuencias disponibles se forman dos

grupos, donde f1 y f3 son el primer grupo, mientras que f2 y f4 son el segundo grupo. De

agregar más frecuencias (f5 y f6), se obtendrían los mismos retardos, porque de igual

forma se obtendrían esperas entre 2Δ y 4Δ. Pero se estarían ocupando esta frecuencias, y

como se menciono anteriormente el estándar solo define 16 frecuencias, es decir que de

utilizar mas frecuencias se ocupara un gran porcentaje del espectro disponible.

Lo nodos activan el AMCP al recibir el primer paquete por el canal base. Por lo cual, si dos

nodos fuentes ubicados en distintos saltos, transmiten al mismo tiempo, van a activar el

AMCP de los nodos de la columna de transmisión con un leve retraso. Para reducir este

problema al mínimo se diseñó un algoritmo de asignación dinámico de frecuencias (Figura

16).

Figura 15. Algoritmo asignación canales LEMR-Cel

37

El objetivo de este algoritmo es asignar el primer grupo de frecuencias al nodo fuente con

menor número de saltos, para lo cual cada nodo fuente que va transmitir envía el primer

paquete es decir, el cuadro tipo I. A este paquete se le introduce un encabezado en donde

esta el número de saltos de la fuente. Por lo que, al llegar al sumidero éste sabe cuál es el

paquete cuya fuente tiene el menor número de saltos. Después de esperar un tiempo

pequeño, el sumidero envía un paquete broadcast donde informa cuál es el menor

número de saltos entre las fuentes que transmitieron en ese intervalo de tiempo.

Figura 16. Algoritmo asignación dinámico de frecuencias

Al recibir el número de saltos, cada fuente que está transmitiendo lo compara con sus

saltos y dependiendo de esto, selecciona el grupo de frecuencias. También existe la

posibilidad de que las fuentes tengan los mismos saltos por lo que, de detectarse este

caso el sumidero envía un paquete broadcast informando el empate. Asumiendo que

solamente existe la posibilidad de que sólo dos fuentes tengan exactamente los mismos

saltos, a cada fuente se le predefine un grupo de frecuencias a utilizar por lo que se

garantiza que cada una selecciona un grupo diferente.

38

Si bien este algoritmo introduce un retardo al inicio de la transmisión, teniendo en cuenta

que el funcionamiento del codec también tiene un retardo, lo que se hace es usar este

retardo para el funcionamiento del algoritmo.

Resumiendo se tienen dos posibles casos, el primero fuentes a distintos saltos y el

segundo fuentes con los mismos saltos. En el caso que las fuentes estén con los mismos

saltos, éstas transmitirán paquetes al mismo tiempo en diferentes frecuencias, por lo que

los nodos de la columna de transmisión activarán el AMCP de manera sincronizada con las

dos fuentes. Pero en el caso de estar a distintos saltos, el nodo fuente más cercano será el

que activará el AMCP de los nodos de la columna de transmisión primero que la fuente

con mayor número de saltos, por lo que es de esperar que la fuente más lejana presente

problemas de retardo. Así, para disminuir estos posibles problemas el nodo más cercano

toma el primer grupo de frecuencias, transmitiendo en la frecuencia inmediatamente

siguiente a la frecuencia base, con el objetivo de que la fuente más lejana, que transmitirá

más tarde, tenga una ventana de tiempo más amplia para evitar retardos.

5.4 PROGRAMACION LEMR-Cel EN QUALNET

Con el objetivo de la implementar LEMR-Cel en la herramienta Qualnet®, se adicionaron

funciones y variables nuevas a los protocolos desarrollados en [37]. Para empezar se

nombraran las variables agregadas en el protocolo de la capa MAC:

maclemr->soyFuente: Define si el nodo es fuente.

maclemr->soySink: Define si el nodo es sumidero.

maclemr-> verificarPrimo: Bandera la cual termina el proceso de asignación de canales.

maclemr->saltos: Define el número de saltos al sumidero.

maclemr->empateAsign: Bandera la cual predefine las frecuencias en caso de empate.

TRUE asigna el primer grupo de frecuencias y FALSE el segundo.

39

maclemr->saltosNodosF[]: Vector donde se almacenan los saltos de las fuentes en el

sumidero.

maclemr->saltosNodoPointer: Apuntador del vector de los saltos.

maclemr->saltoMenor: Define el número del menor salto, entre las fuentes que

transmitieron.

También se implementaron varias funciones en el protocolo de la capa MAC, las cuales

son:

BOOL MacLemrAsignarCanales(Node *node, MacDataMacLemr *maclemr): En esta

función se asignan el grupo de canales a cada nodo fuente.

void MacLemrVerificarPrimero (Node *node, MacDataMacLemr *maclemr, Message

*msg): Esta función recolecta los encabezados de los paquetes con la información de los

saltos.

void MacLemrMenorSalto (Node *node, MacDataMacLemr *maclemr): Determina el

menor salto o define un empate.

Como se mencionó anteriormente LEMR-Cel es un protocolo multicapa por lo que

también se agregaron tanto funciones como variables al protocolo de enrutamiento de

LEMR. Las variables son:

lemr->soyPrimo: Bandera activada en caso de ser la fuente con menor número de saltos.

lemr->mismoSalto: Bandera activada en caso de presentarse un empate en los números

de saltos.

Las funciones son las siguientes:

void CanalesBroadcast(Node *node, int srcId): Es la función encargada de transmitir el

paquete broadcast, con la decisión del sumidero.

BOOL SoyPrimero(Node* node): Retorna el valor de la variable lemr->soyPrimo

40

int DarSaltos (Node* node): Retorna el número de saltos de la fuente al sumidero.

BOOL DarMismoSaltos (Node* node): Retorna el valor de la variable lemr->mismoSalto.

Figura 17. Algoritmo implementación de LEMR-Cel en Qualnet®.

En la figura 17 se describe el algoritmo en términos de las funciones programadas. En la

etapa de inicio, a los paquetes se les adiciona el número de saltos al llamar a la función int

DarSaltos.

Al llegar los paquetes al sumidero la información de los encabezados, es recolectada y

almacenada por la función void MacLemrVerificarPrimero. Con la información almacenada

se espera un corto periodo de tiempo, en el caso de que más de una fuente quiera

transmitir. Este periodo este predefinido como 1 segundo, porque se esperan

transmisiones simultaneas. La función void MacLemrMenorSalto determina cual es el

menor salto, o si hay empate. Al terminar llama a la función void CanalesBroadcast, en

donde se transmite la información obtenida en void MacLemrMenorSalto.

Al llegar el paquete broadcast, cada fuente verifica si es su salto, de serlo activa la bandera

lemr->soyPrimo a TRUE, o de presentarse un empate activa la bandera lemr->mismoSalto.

Toda esta información está en la capa de enrutamiento por lo que en la función BOOL

41

MacLemrAsignarCanales, se hace uso de las funciones BOOL SoyPrimero y BOOL

DarMismoSaltos, para determinar los canales a utilizar. La función BOOL

MacLemrAsignarCanales retorna TRUE o FALSE, dependiendo del canal de frecuencia para

el cual debe transmitir, es decir si está en el intervalo de transmisión de una frecuencia no

asignada, la función retorna FALSE. Lo que evita la transmisión del paquete en esa

frecuencia.

42

6. RESULTADOS

Con el objetivo de evaluar el desempeño del LEMR-Cel, se crearon tres diferentes

escenarios en donde se compara con el LEMR-Multichannel. En la capa física se utilizó el

modelo del radio transmisor CC2420 [38] con los parámetros de la Tabla V. El Δ es de

15ms, el ciclo es 10Δ es decir 150ms, el temporizador AMCP es de 300 ms, y se utilizaron 5

canales de frecuencias: 2.4GHz, 2.405GHz, 2.41GHz, 2.415GHz y 2.42GHz. Los tiempos se

calcularon utilizando (2) y los parámetros de la Tabla V.

Se define 2.4GHz como la frecuencia base (f0). En LEMR-Cel el primer grupo de frecuencias

lo componen: 2.405GHz y 2.415GHz, las cuales serán llamadas f1 y f3 respectivamente.

Mientras que el segundo grupo lo componen: 2.41GHz y 2.42GHz, cuyos nombres serán f2

y f4 respectivamente. En el LEMR-Multichannel los nodos cambiarán de frecuencias

siguiendo el siguiente orden: f0, f1, f2, f3, f4, f0, f1, f2, f3, f4…….. Todas las simulaciones se

repitieron 30 veces variando la semilla en cada repetición, porque la herramienta de

simulación se basa en eventos aleatorios, es decir que con las 30 repeticiones se obtienen

un espacio muestral lo suficiente para obtener resultados representativos.

Tabla V. Parámetros de Simulación

El primer escenario lo conforman 12 fuentes (Figura 18), cada una ubicada a diferentes

saltos del sumidero. El objetivo de este escenario es evaluar para cada fuente el caudal

máximo. Para esto cada fuente envía 100 paquetes cada uno con tamaño de 128 bytes.

Parámetro Valor

Potencia de transmisión 10dBm

Sensibilidad -95dBm

Umbral del receptor -77dBm

Velocidad de transmisión 250kbps

Potencia consumida en modo Tx 91.4mW

Potencia consumida en modo Rx 59.1mW

Potencia consumida en modo apagado 15uW

Tamaño máximo de paquete 128 bytes

C1 y C2 1

Parámetros de Simulación

43

Disminuyendo el tiempo entre el envío de los paquetes se aumenta el caudal hasta

cuando se obtiene el caudal máximo constante.

Figura 18. Topología Escenario 1

De la figura 19 se puede observar que en ambos protocolos, los caudales de las fuentes

ubicados a más de 10 saltos son muy inferiores a los de las fuentes ubicadas a menos de

10 saltos. La razón de esto se debe al tiempo de ciclo. Como se sabe, es necesario un Δ

para transmitir un paquete por salto, por lo que para que un paquete llegue dentro del

ciclo (10 Δ) a su destino, sin presentar retardos adicionales, tiene que estar máximo a 10

saltos, porque de lo contrario, es necesario otro ciclo, es decir un retardo de por lo menos

10 Δ, ocasionando una caída en el caudal.

Es de esperar que LEMR-Multichannel tenga caudales más altos que LEMR-Cel en el caso

de que sólo una fuente esté transmitiendo porque LEMR-Cel deja de usar canales de

frecuencias para que una segunda fuente pueda transmitir. Explicando en más detalle, en

LEMR-Multichannel la fuente utiliza todos los canales de frecuencias disponibles es decir

que, mínimo cada , es posible transmitir un paquete, por lo que el tiempo mínimo de

transmisión está entre 2Δ y 3Δ. En los resultados se observa que el caudal máximo es

32kbps, por lo que el tiempo entre la transmisión de paquetes es de 32ms, lo cual se

encuentra dentro del rango esperado. En LEMR-Cel se espera obtener un caudal menor al

de LEMR-Multichannel, debido a que LEMR-Cel deja de utilizar dos canales de frecuencias,

causando que no se puedan enviar paquetes en los canales que no utiliza. Además, se

44

agruparon las frecuencias de manera que se espere máximo 4Δ, por lo que es de esperar

un intervalo de paquetes entre 3Δ y 4Δ, lo cual concuerda con el tiempo mínimo entre

envió de paquetes el cual es de 50ms, porque el caudal máximo es de 20.48kbps.

Figura 19. Resultado Escenario 1.

El segundo escenario (Figura 20) tiene como objetivo evaluar el desempeño de los

protocolos frente al envío simultáneo de varias fuentes. Para estas fuentes se fijaron

caudales de 16kbps porque varios fabricantes de cámaras [39] exigen este caudal mínimo

para los dispositivos que usan el codec H 264. Por esta razón, se van a generar paquetes

de 128bytes cada 64ms durante 5 minutos, con el fin de simular una trasmisión de video

de 5 minutos por fuente. Para esto se utilizaron fuentes CBR.

45

Figura 20. Topología escenarios 2 y 3.

Observando los resultados en la Tabla VI, se determina que el desempeño frente a la

transmisión de una sola fuente es muy similar entre los dos protocolos. Este resultado no

es de sorprender porque en el escenario anterior se determinaron los caudales máximos

para cada protocolo al estar transmitiendo una fuente.

Tabla VI. Resultados Escenario 2

Se puede verificar un desempeño muy superior de LEMR-Cel con respecto a LEMR-

Multichannel, en términos de retardos en el momento en que dos fuentes transmitan al

mismo tiempo. Con esto se demuestra que la estrategia de utilizar diferentes frecuencias

mejora en gran medida el desempeño de la red al estar frente a transmisiones

simultáneas de las fuentes. También es interesante comprobar los efectos del número de

saltos a los que se encuentran las fuentes. Es decir, comprobar el desempeño de los

protocolos al estar las fuentes ubicadas en diferentes o igual número de saltos. Los

Valor Promedio (s) σ Valor Promedio (s) σ

0,64 0,19

297,39 2,94 259,43 2,45

0,17 1,26x10-4

45,43 1,73 5,99 1,39

Una fuente

(Fuente 13)

Dos fuentes

(Fuentes 13 y 11)

Dos fuentes

(Fuentes 13 y 11)

Tres fuentes

(Fuentes 10,11 y 13)

0,15 1,20x10-4

37,83 1,75

Retardos LEMR-Multichannel LEMR-Cel

Protocolo

46

retardos observados en el caso de las fuentes 11 y 12 (mismo salto) son menores a los de

las fuentes 13 y 11 (saltos diferentes), lo cual confirma que al estar en el mismo salto, van

a transmitir paquetes exactamente al mismo tiempo. En el caso de las fuentes 11 y 12 el

AMCP va a estar activado al mismo tiempo, obteniendo retardos de 0.64s y en el caso de

las fuentes 13 y 11 un retardo de 5.99s.

Por último se puede apreciar, de los retardos de la Tabla 2, que ni LEMR-Cel ni LEMR-

Multichannel están en la capacidad de soportar 3 fuentes simultáneas.

El tercer escenario utiliza la misma topología del escenario anterior (Figura 20). Para este

escenario las fuentes serán las trazas, correspondientes a los primeros 5 minutos del video

Big Buck Bunny (Figura 21), las cuales fueron codificadas con el códec H 264. El video tiene

una resolución de 352 x 288 pixeles con 3 cuadros por segundo. Para este escenario las

fuentes a transmitir son las identificadas con los números 12 y 11.

Figura 21. Traza Big Buck Bunny.

En los resultados (Tabla VII), era de esperar un desempeño en términos de retardo y

caudal superior del LEMR-Cel en comparación con el LEMR-Multichannel, a tal punto que

es posible pensar en aplicaciones multimedia para tiempo real.

47

Es interesante observar que un caudal variable mejora el desempeño del LEMR-

Multichannel, lo cual se debe a que la red por momentos no está sometida a grandes

caudales, que copan su capacidad, por lo que en esos lapsos de tiempo las colas de

paquetes disminuyen ocasionando menores retardos.

Tabla VII. Resultados Escenario 3

Adicional al retardo y al caudal, para ambos protocolos el jitter (variación del retardo) es

del orden de los ms, lo cual es de esperarse porque ambos son basados en LEMR en el

cual contar con jitter pequeños; es una de las características principales de LEMR.

Por último es importante analizar la energía promedio consumida (Tabla VII), puesto que

se está trabajando sobre redes inalámbricas de sensores donde la energía es un

parámetro de diseño sumamente importante. Por lo que se puede apreciar el LEMR-Cel es

más eficiente energéticamente en comparación con el LEMR-Multicahnnel, debido a que

los radios de las fuentes en LEMR-Cel están apagados en las frecuencias donde no se

transmite, por lo cual el consumo es menor.

Valor Promedio σ Valor Promedio σ

0,07

12,22

27066,96

6,72

0,23 8,60

27539,32141,46 9,34

0,033,340,03

0,14

Retardo Promedio (s)

Jitter Promedio (ms)

Caudal Agregado

Promedio (bps)

LEMR-Multichannel LEMR-Cel

Protocolo

Parámetros

6,58 0,79 0,89

Energía Promedio

Consumida (mWhr)

48

7. CONCLUSIONES

En este documento se presentó, el protocolo LEMR-Cel diseñado para la trasmisión

simultánea de aplicaciones multimedia. Se demostró que LEMR-Cel en términos de

retardo, jitter, caudal y energía consumida es una opción viable para la transmisión de

tráfico multimedia de una o dos fuentes en simultáneo. También se demostró que la

asignación de canales de frecuencia adaptativa mejora su desempeño en comparación al

LEMR-Multichannel, además de reducir posibles retardos debido a diferencias en el

tiempo de activación del AMCP.

Gracias al estudio de las fuentes de tráfico multimedia, en el diseño de LEMR-Cel, se logro

utilizar el retardo el cual el codec introduce, para desarrollar un proceso importante. Con

lo cual se aseguro que el protocolo no introdujera retardos adicionales, los cuales en el

caso de WSN no son deseables.

Se observa en el estado de los protocolos, que la mayoría de estos están diseñados para

WSN con topologías especificas. LEMR-Cel no es la excepción, debido a que tanto el

diseño y las posteriores simulaciones fueron desarrolladas para WSN con topología radial.

Por lo que en un futuro se podría implementar LEMR-Cel en otras topologías diferentes.

Si bien los fabricantes exigen un caudal mínimo y ofrecen opciones para mantener este

caudal constante. Se observó que al evaluar los protocolos usando las trazas de un

segmento de video, en el escenario 3, los resultados fueron distintos comparados con el

escenario 2, en el cual se hizo una aproximación basada en los requerimientos de los

fabricantes de las cámaras. Por lo que es importante resaltar el gran impacto que tiene el

modelamiento de las fuentes en los resultados de simulación.

Todas las simulaciones se desarrollaron para calidades de video muy bajas, es decir, lo

suficiente para aplicaciones multimedia que no requieren mucha calidad de la imagen.

Esto se debió a las limitaciones en el caudal disponible de las WSN. Se espera en un futuro

mejorar el caudal para enviar contenido multimedia de alta calidad. Por otra parte el

49

desarrollo de los codecs es muy activo, por lo que también es de esperar que con el mismo

caudal en un futuro cercano sea posible enviar contenido multimedia de mayor calidad.

Gracias al uso de la herramienta de simulación Qualnet®, se logro implementar tanto las

fuentes de tráfico multimedia como el protocolo LEMR-Cel usando la topología radial. Con

lo cual se logro observar el desempeño del protocolo y de su predecesor, LEMR-

Multichannel, frente al trafico multimedia basados en la traza de un video real, es decir se

logro observar lo que seria el desempeño de los protocolos frente a contenido multimedia

real.

50

8. REFERENCIAS

[1]. I.F.Akyildiz, T.Melodia, and K.R.Chowdry, ‘‘A Survey on Wireless Multimedia Sensor Networks,’’ Computer Networks (Elsevier) Journal, 2007.

[2]. Meng-Shiuan Pan; Hua-Wei Fang; Yung-Chih Liu; Yu-Chee Tseng; , "Address Assignment and

Routing Schemes for ZigBee-Based Long-Thin Wireless Sensor Networks," Vehicular Technology Conference, 2008. VTC Spring 2008. IEEE , vol., no., pp.173-177, 11-14 May 2008

[3]. The Qualnet® simulator. Versión 5.0, disponible en: http://www.scalablenetworks.com.

[4]. L. L. Peterson y B. S. Davie, “Computer Networks A System Approach”, Third Edition, Morgan Kaufmann Publishers, USA 2003

[5]. Ambient-systems unode product sheet, Disponible en: http://www.ambientsystems.net.

[6]. Crossbow MICAz Mote Specifications. Disponible en: http://www.xbow.com.

[7]. Crossbow TelosB Mote Specifications. Disponible en: http://www.xbow.com.

[8]. Qualnet® 5.0.2, Programmers Guide. Disponible en: http://www.scalable-networks.com, 2010

[9]. IEEE, IEEE Std 802.15.4-2005, IEEE Standard for Information Technology -Telecommunications and information exchange between systems-Local and metropolitan area network-Specific requirements- Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs). American National Standards Institute, 2006, pages 14-16.

[10]. Y.-C. Wang, C.-H. Chuang, Y.-C. Tseng, and C.-C. Shen, "A Lightweight, Self-Adaptive Lock Gate Designation Scheme for Data Collection in Long-Thin Wireless Sensor Networks", Wireless Communications and Mobile Computing. (SCIE) (to appear).

[11]. H.Hassan, J-M.Garcia, and O.Brun: Generic Modeling of Multimedia Traffic Sources,

Proceedings HETNET'05, Ilkley, 2005

[12]. Assen Golaup , Hamid Aghvami, A multimedia traffic modeling framework for simulation-

based performance evaluation studies, Computer Networks: The International Journal of

Computer and Telecommunications Networking, v.50 n.12, p.2071-2087, 24 August 2006.

[13]. Golaup, A.H. Aghvami, Modeling of MPEG4 traffic at GoP level using autoregressive processes, IEEE Veh. Technol. Conference Fall 2002, Vancouver, British Columbia, Canada, 2002, pp. 854–858.

http://www.ambientsystems.net/

http://www.xbow.com/

http://www.xbow.com/

http://www.scalable-networks.com/

51

[14]. M.W. Garrett, W. Willinger, Analysis, modeling and generation of self-similar VBR video traffic, in: Proceedings of ACM SIGCOMM_94, pp. 269–280.

[15]. S. Ma, C. Ji., Modeling video traffic in the wavelet domain, in: Proceedings of

INFOCOM_98, San Francisco, CA, vol. 1, 1998, pp. 201–208.

[16]. Seeling, P.; Reisslein, M.; , "Video Transport Evaluation With H.264 Video Traces," Communications Surveys & Tutorials, IEEE , vol.PP, no.99, pp.1-24 Sep. 2011

[17]. Video Trace Library. [Online]. Disponible en: http://trace.eas.asu.edu/

[18]. W. Ye, J. Heidemann, y D. Estrin, “Medium access control with coordinated adaptive

sleeping for wireless sensor networks”, IEEE/ACM Transactions on Networking, 12(3):34–

39, 2004.

[19]. T.V. Dam y K. Langendoe, “An adaptive energy-efficient mac protocol for wireless sensor

networks”, in Proc. of the 1st International Conference on Embedded Networked Sensor

Systems, 2003.

[20]. W. Ye, F. Silva, y J. Heidemann, “Ultra-low duty cycle mac with scheduled channel polling”,

in Proc. of the 4th International Conference on Embedded Networked Sensor Systems, 2006.

[21]. Mohajerzadeh, A.H.; Yaghmaee, M.H.; Toroghi, N.N.; Parvizy, S.; Torshizi, A.H.; , "MREEP: A

QoS based routing protocol for wireless multimedia sensor networks," Electrical Engineering (ICEE), 2011 19th Iranian Conference on , vol., no., pp.1, 17-19 May 2011

[22]. Poojary, S.; Pai, M.M.M.; , "Multipath Data Transfer in Wireless Multimedia Sensor

Network," Broadband, Wireless Computing, Communication and Applications (BWCCA), 2010 International Conference on , vol., no., pp.379-383, 4-6 Nov. 2010

[23]. Cheng Li; Pu Wang; Hsiao-Hwa Chen; Guizani, M.; , "A Cluster Based On-demand Multi-Channel MAC Protocol for Wireless Multimedia Sensor Networks," Communications, 2008. ICC '08. IEEE International Conference on , vol., no., pp.2371-2376, 19-23 May 2008

[24]. Gang Zhou , Yafeng Wu , Ting Yan , Tian He , Chengdu Huang , John A. Stankovic , Tarek F.

Abdelzaher, A multifrequency MAC specially designed for wireless sensor network applications, ACM Transactions on Embedded Computing Systems (TECS), v.9 n.4, p.1-41, March 2010

[25]. Kae-Hsiang Kwong; Tsung-Ta Wu; Michie, C.; Andonovic, I.; , "A Self-Organizing Multi-Channel Medium Access Control (SMMAC) Protocol for Wireless Sensor Networks," Communications and Networking in China, 2007. CHINACOM '07. Second International Conference on , vol., no., pp.845-849, 22-24 Aug. 2007

http://trace.eas.asu.edu/

52

[26]. O.D. Incel, L. van Hoesel, P.G. Jansen, P.J.M. Havinga,, MC-LMAC: A multi-channel MAC protocol for wireless sensor networks, Ad Hoc Networks, Volume 9, Issue 1, January 2011, Pages 73-94

[27]. Youngmin Kim; Hyojeong Shin; Hojung Cha; , "Y-MAC: An Energy-Efficient Multi-channel

MAC Protocol for Dense Wireless Sensor Networks," Information Processing in Sensor

Networks, 2008. IPSN '08. International Conference on , vol., no., pp.53-63, 22-24 April 2008

[28]. Motorola, “TDMA Technology Bringing Increased Capacity and Functionality to

Professional Digital Two-way Radio” [Online], 2008, Disponible en:

http://www.motorola.com/.

[29]. IEEE, IEEE Std 802.15.4-2005, IEEE Standard for Information Technology -Telecommunications and information exchange between systems-Local and metropolitan area network-Specific requirements- Part 3: Carrier Sense Multiple Access whit Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. American National Standards Institute, 2009.

[30]. J. Polastre, J. Hill, D. Culler: Versatile Low Power Media Access for Wireless SensorNetworks. ACM SenSys, 2004.

[31]. Ang-Hsi Lee; Ming-Hui Jing; Cheng-Yan Kao; , "LMAC: An Energy-Latency Trade-off MAC

Protocol for Wireless Sensor Networks," Computer Science and its Applications, 2008. CSA

'08. International Symposium on , vol., no., pp.233-238, 13-15 Oct. 2008.

[32]. S. Moon, T. Kim, H. Cha, "Enabling Low Power Listening on IEEE 802.15.4-based Sensor

Nodes", The 5th IEEE Wireless Communications & Networking Conference (WCNC 2007),

Hong Kong, China, March 2007.

[33]. G. Halkes and K. Langendoen, “Crankshaft: An Energy- Efficient MAC-Protocol For Dense Wireless Sensor Networks.”, EWSN07, 2007.

[34]. A. Cortes, R. Gamboa, N. M. Pena, y M. Labrador, “Low energy and low latency in wireless

sensor networks”, in Proc. of IEEE ICC, 2009.

[35]. A. Cortes, R. Gamboa, N. M. Pena, y M. Labrador, "An adaptive multi-channel approach for

real-time multimedia wireless sensor networks," Communications, 2009. LATINCOM '09.

IEEE Latin-American Conference on, vol., no., pp.1-6, 10-11 Sept. 2009.

[36]. Blender Foundation; Big Buck Bunny. [Online]. Disponible en:

http://www.youtube.com/watch?v=XSGBVzeBUbk

http://www.motorola.com/

http://www.youtube.com/watch?v=XSGBVzeBUbk

53

[37]. A. Cortes. “Diseño Cross-Layer para la transmisión de datos escalares y contenidos

multimedia en tiempo real en redes inalámbricas de sensores”. Tesis de Doctorado.

Universidad de los Andes. 2011.

[38]. Chipcon, “Cc2420 datasheet”, disponible en: http://www.chipcon.com,2005

[39]. Autodomo IP PTZ para exteriores /480TVL/1/4 Sony CCD/22 X; disponible en:

http://www.economizadores.net/

http://www.economizadores.net/index.php?option=com_virtuemart&Itemid=5&category_id=80&flypage=flypage.tpl&lang=es&limitstart=0&page=shop.product_details&product_id=1050

LEMR-CEL: Protocolo Multicapa Multicanal para Aplicaciones ...

Documents

Transcript of LEMR-CEL: Protocolo Multicapa Multicanal para Aplicaciones ...