network simulator ns

15
Network Simulator NS. Para obtener información real acerca del funcionamiento del sistema se ha realizado una simulación mediante la herramienta Network Simulator - ns-2. NS2 es un simulador de eventos discretos dirigido a la investigación de redes ya sean estas inalámbricas o cableadas, NS provee un apoyo substancial para la simulación de TCP, enrutamiento y protocolos de multidifusión a través de redes de cable e inalámbricas (locales y por satélite). Una de las características de NS es su funcionamiento basado en Linux, debido a esto su instalación debe realizarse sobre el sistema operativo Ubuntu. NS ha sido desarrollado en C++ y su interfaz en OTCL, soporta diferentes tecnologías a nivel de capas por ejemplo: Capa Aplicación, HTTP, FTP, CBR, Telnet. Capa Transporte. TCP, UDP, RTP. Capa red, dentro de esta se enmarcan los siguientes parámetros: VectorDistancia, EstadoEnlace DSR, AODV, OLSR* BeeAdhoc* Filas. FIFO, RED. Capa Enlace. 802.3, 802.11 Capa Física Adicionalmente NS permite también: Crear o Modificar Nuevos Protocolos. Mediciones. Throughtput, Jitter, Estado de filas. Caracterización de Tráfico. Visualización grafica de las simulaciones (NAM) NS trabajo en su programación con objetos. Generación de tráfico en NS-2 con distintas propiedades Los objetos que se incluyen en NS-2 para la generación de tráfico pueden ser de cuatro tipos:

Upload: pato-geovanny

Post on 25-Dec-2015

240 views

Category:

Documents


0 download

DESCRIPTION

Resultados NS2

TRANSCRIPT

Network Simulator NS.Para obtener información real acerca del funcionamiento del sistema se ha realizado una simulación mediante la herramienta Network Simulator - ns-2.

NS2 es un simulador de eventos discretos dirigido a la investigación de redes ya sean estas inalámbricas o cableadas, NS provee un apoyo substancial para la simulación de TCP, enrutamiento y protocolos de multidifusión a través de redes de cable e inalámbricas (locales y por satélite).

Una de las características de NS es su funcionamiento basado en Linux, debido a esto su instalación debe realizarse sobre el sistema operativo Ubuntu.

NS ha sido desarrollado en C++ y su interfaz en OTCL, soporta diferentes tecnologías a nivel de capas por ejemplo:

Capa Aplicación, HTTP, FTP, CBR, Telnet. Capa Transporte. TCP, UDP, RTP. Capa red, dentro de esta se enmarcan los siguientes parámetros:

VectorDistancia, EstadoEnlace DSR, AODV, OLSR* BeeAdhoc* Filas. FIFO, RED.

Capa Enlace. 802.3, 802.11 Capa Física

Adicionalmente NS permite también:

Crear o Modificar Nuevos Protocolos. Mediciones. Throughtput, Jitter, Estado de filas. Caracterización de Tráfico. Visualización grafica de las simulaciones (NAM)

NS trabajo en su programación con objetos.

Generación de tráfico en NS-2 con distintas propiedades

Los objetos que se incluyen en NS-2 para la generación de tráfico pueden ser de cuatro tipos:

ExponentialLos Objetos de tráfico exponencial generan tráfico en periodos On/Off. Durante periodos "On", los paquetes son generados a una velocidad constante. Durante los periodos "Off", no se genera tráfico. Los tiempos de generación y de inactividad son tomados por la distribución exponencial. Los parámetros de configuración son:

PacketSize_ tamaño constante de paquetes generados

burst_time_ promedio de tiempo activo del generadoridle_time_ promedio de tiempo inactivo del generadorrate_ velocidad de envío durante tiempo activo

ParetoLos tiempos de generación y de inactividad son tomados por la distribución pareto. Los parámetros de configuración son:

PacketSize_ tamaño constante de paquetes generados

burst_time_ promedio de tiempo activo del generadoridle_time_ promedio de tiempo inactivo del generadorrate_ velocidad de envío durante tiempo activoshape_ el parámetro forma usado por la distribución pareto

CBRObjetos CBR generan paquetes a una velocidad de bits constante.$cbr start inicia el generador

$cbr stop detiene el generador de paquetes

Los parámetros de configuración son:

PacketSize_ tamaño constante de paquetes generados

rate_ velocidad de envío durante tiempo activoidle_time_ promedio de tiempo inactivo del generadorinterval_ (opcional) intervalo entre paquetesrandom_ introducir ruido aleatorio, de forma determinada se encuentra offmaxpkts_ número máximo de paquetes a enviar

Traffic Trace Estos objetos son usados para generar tráfico desde un archivo de rastreo. Un lugar de partida aleatorio en el archivo de rastreo se elige. No hay parámetros de configuración para este objeto.

Para realizar la simulación del sistema WiMAX se toma como punto de partida los requerimientos planteados en el capítulo tres de esta Tesis. En los cuales se han especificado los principales parámetros para la transición de voz y video sobre IP. Debido a que se pretende simular tráfico de voz y video se han establecido tipos de tráfico que permita emular de manera más real el comportamiento de la red.

Simulación Voz sobre IP en el sistema WiMAXEn base a la cantidad de tráfico generado por cada sede en hora pico, especificados en la tabla 2. Se procede con la creación del script TCL de ns2, en el cual se especifican tantas características técnicas de equipo y configuraciones a nivel de IP. La arquitectura de la red se establece en la figura 8, misma que ha sido simulada en NS.

Para generar trafico interactivo de voz.

Actualmente hay dos métodos de generación de tráfico de voz sintética disponible en esta herramienta. Uno se basa en el tráfico de flujo CBR. El otro se genera de acuerdo con un estado

ON / OFF, en el que los estados ON y OFF se distribuyen exponencialmente. El tamaño de los paquetes de voz es de 200 bytes, incluyendo el paquete de 160 bytes de datos (codec G711, la velocidad de 64 kbps y 20 ms de duración), 20 bytes de cabecera IP, 8 bytes de cabecera UDP, y el 12 bytes de cabecera RTP. Estos parámetros se pueden cambiar mediante el uso de otros codecs de voz / audio.

Simulación de Video Streaming en el sistema WiMAXPara simular Tráfico de Streaming de Video.

Tráfico Streaming se modela utilizando tráfico CBR sobre UDP. Tanto la velocidad de envío y tamaño de paquete son ajustables.

Análisis de resultados.Resultados de la simulación mediante NS2 para tráfico de voz.

Figura 1: Visualización grafica (NAM) de NS2

Mediante la ejecución del archivo .nam producido por ns2 se logra la visualización grafica de la simulación, para el caso actual se visualiza en la figura 1, la red establecida en la cual se observa un enlace doble ya que la comunicación es bidireccional, y la transmisión inalámbrica es graficada mediante círculos crecientes. Los nodos 0 a 5 representan a los nodos reales de la red 0 y 1 equivalen a las sedes de la ESPE Quito, el nodo 2 representa a la matriz en Sangolqui, el nodo 3 es una repetidora, finalmente los 4 y 5 representan las sedes ESPE Latacunga.

Resultados de Throughput.

Figura 2: Throughput de voz de la red WiMAX

En la Figura 2 se muestra el throughput de la red para un tráfico de Voz, se observa que desde el segundo 0 hasta el segundo 10, tiende a crecer linealmente esto se debe a que se simula eventos (llamadas) aleatorios con una duración media de 3 minutos, a partir del segundo 10 se observa una estabilidad hasta el segundo 18 que es donde se realizan nuevas llamadas tendiendo a crecer linealmente. Como se observa en la leyenda de la Figura 2, la gráfica que se observa es la suma acumulativa de toda la información generada por cada nodo (sede) de la red al final en el segundo 30 la red a alcanzado un Throughput de 130 Kbytes el cual trasladado a bits es de 1.040 Mb.

Conclusión: al generarse un Throughput de 1 Mb a partir de los 30 segundos de simulación se traduce en que la red soporta tranquilamente una mayor demanda en cuanto a tráfico de voz ya que las características técnicas del equipamiento a desplegar y la estandarización de WiMAX proveen un ancho de banda de 35 Mb.

Delay

Figura 3: Delay vs Throughput, de la red con tráfico de voz

En base a la Figura 3 en la cual se muestra la gráfica de Delay vs. Throughput donde se puede apreciar que al segundo 0 se tiene un Delay muy alto equivalente a 18 ms, esto se debe que al inicio de la simulación tanto las estaciones base como el repetidor transmiten tramas de sincronización y control de enlace lo que se traduce en demora ya que estas tramas son de tipo Broadcast. Luego a medida que el Throughput incrementa a partir del segundo 2.2 el Delay decrece hasta encontrarse con un valor de 0 ms debido a que la cantidad de información que generan los nodos (sedes) no sobre carga el canal, a medida que más nodos empiezan a comunicarse la utilización del canal se hace evidente en el incremento del Throughput lo que hace que el Delay tienda a incrementar.

Conclusión: Al ser Delay el tiempo que transcurre entre la emisión de los datos, hasta el momento en que llegan al receptor. Se concluye que mientras el Throughput incrementa el Delay también lo hace peri sin sobrepasar los 5ms, esto demora se debe a la existencia de una gran cantidad de componentes y subsistemas de comunicación, situados en el sistema receptor así como en la red. Cada uno de esos componentes pueden ser caracterizados por su velocidad de procesamiento y por la capacidad de almacenamiento (buffers) donde los datos esperan para ser procesados. El máximo retardo que es el que ocurre de extremo a extremo conocido como mouth-to-ear (de boca a oído) recomendado para conversaciones en tiempo real no debe exceder los 150 ms por lo

que la red no presenta problemas en lo que respecta a mantener conversaciones en tiempo real que es el objetivo final.

Jitter

Figura 4: Jitter vs Throughput para tráfico de voz

El retardo por Jitter o simplemente Jitter es usualmente definido como la variación en el tiempo de llegada al punto receptor, sufrida entre paquetes de datos sucesivos. Los paquetes deberían llegar igualmente espaciados entre sí para permitir una conversión trasparente a voz analógica. La medición del Jitter se realiza en segundos y expresa la distorsión que ocurre en el patrón original de datos enviados, o dicho de otra manera la degradación que ocurre en tiempo sobre la calidad de dato. El Jitter solo tiene sentido cuando es medido a un set de datos y no a datos individuales.

En base a esto y a la Figura 4 se aprecia que el nivel de Jitter es relativamente alto a los instantes en que las llamadas son realizadas o iniciadas en la red, esto se debe a que al momento de iniciar una nueva conversación las primeras tramas en enviarse son tramas de sincronización y tienen cierta prioridad originando así que exista un desfase en la llegada de los paquetes de datos de los otros nodos.

Conclusión: El Jitter más alto que se registra es de 90 ms, mismo que no afecta de sobre manera el funcionamiento de la red.

Paquetes perdidos

Figura 5: Resultados de paquetes pedidos en la simulación de tráfico de voz.

La pérdida de paquetes ocurre cuando uno o más paquetes de datos que viajan en una red IP fallan en alcanzar su destino. La causa de la perdida de paquetes es debida a varios factores, entre los que se puede nombrar, degradación de la señal al viajar por el medio, interconexiones de la red sobresaturadas, paquetes con error rechazados en el tránsito, falla en el hardware de la red, o rutinas normales de enrutamiento. Cuando la perdida de paquetes es causada por problemas en la red, los paquetes perdidos pueden resultar en problemas de desempeño que causen fallas notables en el desempeño de la red, sin embargo la perdida de paquetes no siempre es tan dañina, como por ejemplo cuando es usada para contrarrestar la latencia.

Conclusión: En la figura 5 se muestra un diagrama en 3D de la perdida de paquetes desde el nodo transmisor al nodo receptor, aquí se refleja que la cantidad de paquetes perdidos no es alta, sin embargo es un buen indicador para corregir por ejemplo líneas de vista, parámetro necesario en el enlace, aumento de la potencia u otras variables manipulables y que no sobrepasen las reglas establecidas en el manual de implementación de redes inalámbricas expedidas por el ente regulador. Para el caso de servicios de voz la cantidad de paquetes caídos no significa que la conversación mantenida sea inentendible ya que no supera ni el 30% del total de información trasmitida por la red, con lo cual se asegura que la red opera en excelentes condiciones.

Resultados de la simulación mediante NS2 para tráfico de Streaming de video.

Figura 6: Visualización grafica de la simulación de la red.

En la Figura 6, nuevamente se aprecia el resultado grafico de la simulación (archivo .nam) para este caso de la transmisión de video sobre el sistema a implementar. Como se aprecia en la Figura 6 la arquitectura de la red es la misma que para el caso de Voz la diferencia radica en el tipo de tráfico que cursa la red, mismo que se muestra en la figura mediante señalización de tráfico.

Resultados de Throughput

Figura 7: Throughput de video en el sistema WiMAX.

El Throughput que cursa la red al momento de transmitir video es de 220 Kbytes, de la misma forma que en el caso de la transmisión de voz, aquí se muestra la suma acumulativa ya que al generarse llamadas en diferentes instantes de tiempo la información que genera cada nodo se va acumulando en la red, de esta manera se puede evaluar el comportamiento de la red en general.

Para este caso el Throughput de la red tiende a estabilizarse muy rápidamente ya que las tramas de datos generadas y enviadas son de tamaño constante, algo que no ocurre con la voz.

Conclusión: En la figura 7 el throughput total de la red una vez que se genera información de parte de todos los nodos es de 1.8 Mb, de igual manera el tamaño de información no sobrepasa los límites establecidos por las características físicas de los equipos a utilizar, en conclusión se dice que la red tiene un muy buen desempeño en la transmisión de video llamada.

Delay

Figura 8: Delay vs Throughput de la transmisión de video

El retraso generado en la red para el caso de la transición de video crece de forma lineal en relación al Throughput, esto se debe a que a medida que la cantidad de información que cursa la red mientras el tiempo transcurre crece, se generan colas en los receptores lo cual da lugar al retraso en la recepción de paquetes desde el transmisor, generalmente este es un resultado esperado ya que las tramas de video son mucho más grandes que en la transmisión de voz.

Conclusión: En la Figura 8 se aprecia que la red en cuanto a retraso experimenta una complicación ya que ha sobrepasado lo estandarizado para considerarse una conversación entendible por parte del oyente y hablante que es de 150 ms, la red muestra un retraso de 180 ms, esto puede mejorarse si se utilizan técnicas de compresión más eficaces de lo que es video y codecs de audio mucho mas simples.

Jitter

Figura 9: Jitter vs Throughput en video Streaming

En la Figura 9, se aprecia que el Jitter es inversamente proporcional a la cantidad de información que cursa la red, lo que se traduce en que los paquetes llegan hasta el receptor con un espacio uniforme de tiempo, lo que garantiza el buen funcionamiento de la red.

Conclusión: la red en cuanto a Jitter no presenta complicación alguna, ya que al estar los paquetes espaciados de forma igualitaria garantizan una bueno conversión digital análoga logrando que la conversación sea entendible.

Paquetes perdidos

Figura 10: paquetes perdidos en la transmisión de video sobre la red WiMAX

En la Figura 10 se observa la cantidad de paquetes perdidos en la red, de igual forma que en el caso de la transmisión de voz, no son muchos los paquetes perdidos se generan más cantidad de estos cuando una se intenta establecer una video llamada desde el nodo 1 al nodo 5, quizá se deba a que esta información debe pasar por un nodo central ubicado en la matriz y un repetidor, pues al ser procesados por dos entes claves del sistema se corre mucho riesgo de que la información sea alterada o ente caso perdida.

Conclusión: La cantidad de paquetes perdidos refleja el funcionamiento de la red para el caso actual esta cantidad no rebasa los límites establecidos para garantizar una buena calidad en la transmisión de video.

En general la red evidencia un muy buen comportamiento en cuanto a transmisión de tráfico ya sea de voz o video, lo cual garantiza que a la hora de la implementación se puedan bridar excelentes servicios con un buen margen de QoS.