LEMR-CEL: Protocolo Multicapa Multicanal para Aplicaciones ...
Transcript of 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
Total Paquetes 498 Paquetes Enviados 498
Total Bytes 134.471 Total Bytes Enviados 134.471
Caudal (Mbps) 53,788 Caudal de Salida (Mbps) 51.944
Paquetes Recibidos 498
Total Bytes Recibidos 134.471
Caudal de Entrada (Mbps) 51.942
Retardo (ms) 1,200
Jitter (ms) 0,220
Segmento 00:07:00-00:07:20
Traza Simulación
Total Paquetes 498 Paquetes Enviados 498
Total Bytes 61.664 Total Bytes Enviados 61.664
Caudal (Mbps) 24,666 Caudal de Salida (Mbps) 23.820
Paquetes Recibidos 498
Total Bytes Recibidos 61.664
Caudal de Entrada (Mbps) 23.819
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
Total Paquetes 243 Paquetes Enviados 243
Total Bytes 41.608 Total Bytes Enviados 41.608
Caudal (Mbps) 16,643 Caudal de Salida (Mbps) 16.504
Paquetes Recibidos 243
Total Bytes Recibidos 41.608
Caudal de Entrada (Mbps) 16.503
Retardo (ms) 1,180
Jitter (ms) 0,270
Segmento 00:00:00-00:00:20
Traza Simulación
Total Paquetes 250 Paquetes Enviados 250
Total Bytes 91.470 Total Bytes Enviados 91.470
Caudal (Mbps) 36,588 Caudal de Salida (Mbps) 35.262
Paquetes Recibidos 250
Total Bytes Recibidos 91.470
Caudal de Entrada (Mbps) 35.261
Retardo (ms) 1,300
Jitter (ms) 0,380
Segmento 00:07:00-00:07:20
Traza Simulación
Total Paquetes 250 Paquetes Enviados 250
Total Bytes 41.229 Total Bytes Enviados 41.229
Caudal (Mbps) 16,492 Caudal de Salida (Mbps) 15.894
Paquetes Recibidos 250
Total Bytes Recibidos 41.229
Caudal de Entrada (Mbps) 15.894
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
Total Paquetes 483 Paquetes Enviados 483
Total Bytes 898.000 Total Bytes Enviados 898.000
Caudal (Mbps) 359,200 Caudal de Salida (Mbps) 357.680
Paquetes Recibidos 483
Total Bytes Recibidos 898.000
Caudal de Entrada (Mbps) 357.548
Retardo (ms) 2,500
Jitter (ms) 2,380
Traza Simulación
Segmento 00:00:00-00:00:20
Total Paquetes 498 Paquetes Enviados 498
Total Bytes 2.859.139 Total Bytes Enviados 2.859.139
Caudal (Mbps) 1.143,656 Caudal de Salida (Mbps) 1.104.450
Paquetes Recibidos 498
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
Total Paquetes 498 Paquetes Enviados 498
Total Bytes 639.992 Total Bytes Enviados 639.992
Caudal (Mbps) 255,997 Caudal de Salida (Mbps) 247.220
Paquetes Recibidos 498
Total Bytes Recibidos 639.992
Caudal de Entrada (Mbps) 247.153
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
Total Paquetes 483 Paquetes Enviados 483
Total Bytes 1.052.672 Total Bytes Enviados 1.052.672
Caudal (Mbps) 421,069 Caudal de Salida (Mbps) 419.288
Paquetes Recibidos 483
Total Bytes Recibidos 1.052.672
Caudal de Entrada (Mbps) 419.093
Retardo (ms) 2,800
Jitter (ms) 3,050
Segmento 00:00:00-00:00:20
Traza Simulación
Total Paquetes 498 Paquetes Enviados 498
Total Bytes 2.877.960 Total Bytes Enviados 2.877.960
Caudal (Mbps) 1.151,184 Caudal de Salida (Mbps) 1.111.720
Paquetes Recibidos 498
Total Bytes Recibidos 2.877.960
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
Total Paquetes 498 Paquetes Enviados 498
Total Bytes 841.474 Total Bytes Enviados 841.474
Caudal (Mbps) 336,590 Caudal de Salida (Mbps) 325.050
Paquetes Recibidos 498
Total Bytes Recibidos 841.474
Caudal de Entrada (Mbps) 324.934
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.
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
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
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/