Análisis de desempeño de redes mediante NS2

en entorno Linux Ubuntu

Est. Miguel Salazar Nathaly Silvina, Estudiante IX EPIE, UNPRG, Est. Rodas Carrasco Frank
Orlando, Estudiante IX EPIE, UNPRG

TABLA II
INFORMACIÓN DE CODEC
Resumen— En el presente artículo se presenta el uso y
aplicación del software NS2, a través de la cual se pueden
configurar ciertos parámetros de la red, topologías y protocolos,
todo eso con el fin de evaluar el impacto que estos cambios
conllevan en su comportamiento. Dado esto es que se presenta un
análisis explicando sea de paso el funcionamiento de dicho
simulador.

Palabras Claves—NS2, desempeño, red.

I. INTRODUCCIÓN

E
n el presente artículo se analizará el desempeño de las
redes y su comportamiento al cambiar en ella ciertos
factores, todo ello haciendo uso del software NS2,
además de una interpretación de las gráficas que se obtengan
con el fin de demostrar las variaciones entre los ejemplos
mostrados.

II. VOIP
La tecnología VoIP trata de transportar la voz, previamente
procesada, encapsulándola en paquetes para poder ser
transportadas sobre redes de datos sin necesidad de disponer
de una infraestructura telefónica convencional. (Gutiérrez Gil,
2012)

Para que Internet pueda manejar cualquier información

En la siguiente tabla proporciona cálculos para los tamaños
analógica (como la voz), es necesario que ésta se convierta de carga de voz predeterminados en Cisco CallManager o
previamente en digital. Este proceso se conoce como CUBE.(«Voice Over IP - Per Call Bandwidth Consumption»,
digitalización. (Carballar, 2007) 2016)

Para hacer posible la digitalización de la voz es preciso el

uso de los codecs.

A. Codecs:
Como su mismo nombre lo deja entrever, un códec
desempeña la función tanto de un codificador, como la de un
decodificador, aplicando una serie de algoritmos para
empaquetar flujos de datos multimedia, ya sea voz o audio,
para ser transmitidos a través de la red de datos.

Algunos de los codecs más usuales son los siguientes:

 TABLA III
INFORMACIÓN DE ANCHO DE BANDA
4) Eco
5) Jitter
6) Tamaño de los paquetes
III. CALIDAD DE VOZ EN REDES IP
Para que la tecnología VoIP pueda ser utilizada tanto a nivel
corporativo como a nivel de operadores telefónicos, es
esencial garantizar una calidad de voz aceptable.
VoIP enfrenta problemáticas propias de las redes de datos,
que se manifiestan como degradaciones en la calidad de
servicio (QoS) o la calidad de experiencia (QoE) percibida por
los usuarios. Estas degradaciones pueden deberse por ejemplo
a retardos, jitter, pérdida de paquetes, ente otros. (Joskowicz
José, 2013)
Es por eso que se analizarán los factores específicos que
afectan la calidad de voz percibida sobre redes de paquetes.
A. Factores que afectan la calidad de la voz sobre redes de
paquetes
Algunos de los parámetros que influyen en la calidad de la
voz transmitida a través de la red de datos son los siguientes:
1) Factor de compresión y codificación
En el proceso de transmisión de la voz, es indispensable
realizar un proceso de digitalización y de codificación, los
cuales emplean técnicas de compresión, que llegan a
degradar la señal de voz original.
2) Pérdida de paquetes
A diferencia de las redes telefónicas, donde se establece
un vínculo “estable y seguro” en cada conversación, en las
redes de datos se admite la pérdida de paquetes.
Si el porcentaje de pérdida es pequeño, la degradación de
la voz también lo es.
También se consideran como “perdidos” los paquetes que
llegan a destiempo o fuera de orden.
3) Retardo
Es uno de los factores más importantes en la percepción
de la calidad de la voz. Está determinada por varios
factores, entre los que se encuentran: Retardo debido a los
algoritmos de codificación, retardos de procesamiento,
retardos propios de la red, etc.
Es uno de los factores más importantes en la percepción
de la calidad de la voz. Está determinada por varios
factores, entre los que se encuentran: Retardo debido a los
algoritmos de codificación, retardos de procesamiento,
retardos propios de la red, etc.
Es la variación en los retardos. El receptor debe recibir los
paquetes a intervalos constantes, para poder regenerar de
forma adecuada la señal original. Dado que el “jitter” es
inevitable, los receptores disponen de un “buffer” de
entrada, con el objetivo de “suavizar” el efecto de la
variación de las demoras.
Este parámetro influye en dos aspectos fundamentales en
la transmisión de la voz: el retardo y el “ancho de banda”
requerido.
Para la transmisión de las muestras codificadas de la voz
sobre una red de datos, es preciso armar “paquetes”, según
los protocolos de datos utilizados.
Un paquete de datos puede contener varias muestras de
voz. Por ellos es necesario esperar a recibir varias muestras
para poder armar y enviar el paquete. Esto introduce un
retardo en la transmisión.
IV. NS2
Es un simulador de redes que permite simular protocolos
de red. El usuario define mediante un script la pila de
protocolos y otros aspectos básicos de la red a simular,
proporcionando datos al programa acerca del escenario a
simular y del tipo y características del tráfico a utilizar.
Conforme avanza la simulación, se generan un conjunto de
datos de salida que se almacenan en un fichero de traza. A
partir de las trazas de simulación se pueden utilizar
lenguajes como Perl y AWK para filtrar la traza y obtener
los índices de prestaciones que se deseen evaluar.
Finalmente, herramientas tales como Network Animator
(nam) permiten realizar un análisis visual del envío y
recepción de paquetes de datos y control a medida que
avanza la simulación.
La sintaxis que este programa usa es el siguiente:
Para simular el archivo .tcl se sigue el siguiente proceso.

V. ANÁLISIS DEL DESEMPEÑO DE UNA RED

Como ya se ha mencionado anteriormente, el análisis del De ello se puede observar algunas de las partes más
desempeño de una red se realizará a través del software NS2, importantes:
donde se simularán el desarrollo de llamadas a través de una
red.

El código principal es el siguiente:

Para iniciar el proceso de análisis. Primero se entra a la

carpeta donde se ubica el archivo .tcl.

Se crea la carpeta llamada “simulacion1” donde se guardarán

los archivos que se creen con el fin de analizarlos.

En el código mostrado antes de nada, se agrega la ubicación a

la carpeta.
 6. Tamaño del paquete
7. Algunas banderas.

El resto de datos casi no tiene tanta relevancia.

Para demostrar el porqué del tiempo que se observa en
recibido se hace:
Tamaño de paquete: 138 Bytes
Para iniciar el proceso de análisis se ejecuta el archivo .tcl Se multiplica por 8 para convertir a bits.
Tamaño de paquete: 1104 bits
mediante:
Velocidad de transmisión: 0.5 Mb
Tiempo de transmisión: 1104 b / 0.5 Mb
Tiempo de transmisión: 2,208 ms
Tiempo de retardo: 90 ms
Como consecuencia se crearán 2 archivos. Tiempo total: 2.208 ms + 90 ms
Tiempo total: 92.208 ms = 0.092208

El tiempo que suelta el paquete es:

El archivo .nam representa la simulación de la red.

Soltó el paquete y debe llegar un tiempo total después:

0.1 + 0.092208 = 0.192208 s

Indica el tiempo el que llegó: r: recibido.

Siguiente paso:

Se buscan los archivos con extensión .awk ubicados en la

carpeta.

A partir de ellos se genera un archivo con extensión .tr para

ser analizados.

Mientras que el archivo con extensión .tr representa el fichero Se ingresa a la carpeta donde se encuentren los archivos y
de traza. desde allí mediante “gnuplot” se obtienen sus respectivas
gráficas.

Para “delay.tr”

1. r: recibido, +: en cola, -: sale de la cola, d: descartado.

2. Tiempo. Según el código se estableció que inicie en el
segundo 0.1 y tenga un intervalo de 0.02.
3. Nodo fuente.
4. Nodo destino.
5. Tipo de paquete.
 La forma de la gráfica indica que el uso del ancho de banda es
constante al haber una sola llamada en curso, sin embargo, el
ancho de banda establecido en un inicio fue de 500Kb.

Y solo se está haciendo un uso de 55kb. Habiendo un

desperdicio. Por lo que se reduce.

Las nuevas gráficas obtenidas como resultado son:

Para “delay.tr”

Según los cálculos hallados anteriormente, se obtuvo un

tiempo total de: 0,092208 y es lo que se muestra en la gráfica.

Para “jitter.tr”.

Según los cálculos el resultado es correcto.

Para “jitter.tr”

Según la teoría del jitter, en la gráfica al mostrarse en cero,

indica que no hay variación en las demoras.

Para “th.tr”.

No hay variación en demoras.

Para “th.tr”

Se usa un aproximado de 55kb y el ancho de bando dado fue
de 60kb. Por lo que el uso es más eficiente. Sin desperdicio.
Para “loss.tr”
No hay pérdida de paquetes, y no hay variación de demoras
por lo que el desempeño durante una llamada es la ideal.
Ahora, para lograr analizar mucho más el
comportamiento de una red, se irán agregando más
“llamadas”, al código principal. En este caso se agregara
una más. Lo único que cambia el nuevo código con el
anterior, es escribir 2 veces este código.
Y escribiendo 2 veces también esta parte del código, poniendo
sin embargo valores diferentes.
Asegurándose de que este valor sea más alto que los
anteriores.
Se aplica entonces nuevamente el proceso visto arriba. Y se
obtienen los siguientes resultados.
Para “delay.tr”
En este caso, en el cual existen dos llamadas en curso, se
puede visualizar que los retardos ya no son constantes, esto
debido a que al haber más datos que transmitir a través de una
misma red, los datos se mantendrán en la cola más tiempo que
cuando se desempeñaba una sola llamada.
Para “jitter.tr”
En el caso del “jitter”, debido a que sí se presenta variaciones
en los retardos a causa de los tiempos de encolamiento.
Se puede visualizar en la gráfica que si bien es cierto, al inicio
de la transmisión no se presenta variaciones porque solo se
tiene una llamada en curso, conforme se inicia la segunda
llamada, los datos se van almacenando en la cola, haciendo
que su tiempo de llegada aumente ligeramente, y por lo tanto
aumentando el valor del “jitter”.
Como se puede observar en la figura, se disntigue claramente
que existen tiempos de encolamientos distintos, lo que
provocan la aparición del “jitter”.
Para “th.tr”
En la gráfica del “throughput” podemos visualizar cuánto Para “th.tr”
ancho de banda se está consumiendo verdaderamente en el
transcurso de las llamadas, y podemos comprobar que se está
desperdiciando más del 80% del ancho de banda que hemos
establecido, por lo tanto es necesario que disminuyamos la
velocidad de transmisión para así no desaprovechar recursos.

Para “loss.tr”

En el caso en el que hemos establecido 0.5 Mb de velocidad Para “loss.tr”

de transmisión no se presenta pérdida de paquetes.

Como se mencionó anteriormente es necesario modificar la

velocidad de transmisión, es por eso que se realizó la siguiente
En este caso, con el cambio de velocidad, resulta una pérdida
modificación:
de paquetes, que se puede solucionar modificando el tamaño
de la cola, de la siguiente manera:

Una vez realizada esta modificación, la gráficas resultan de la

siguiente manera: Donde se obtiene:

Para “delay.tr”

Ahora se agrega otra llamada más.

En este caso se escribe 3 veces este mismo código del códec.

Para “jitter.tr”
 La forma de la gráfica indica una constante variación en la
demora, y esto es debido a que los paquetes al ser encolados
Y se escribe 3 veces esta parte del código, cambiando valores. no tienden a llegar en el tiempo esperado.

Para “th.tr”

Y teniendo en cuenta que el tiempo final sea mucho mayor.

Se aplica el mismo proceso y se analiza sus gráficas.

Para “delay.tr” La forma de la gráfica indica que conforme inicia una llamada
el uso del ancho de banda aumenta hasta llegar un punto
constante y mayor que es cuando las 3 llamadas están en
curso, y luego empiezan a terminar una por una. Sin embargo
tal como cuando había una llamada, el uso del ancho de banda
no es apropiado para el ancho de banda establecido.

Se decide disminuir de 0.5 Mb a 0.1Mb. Nuevos resultados:

Para “delay.tr”

Se observa que al haber 3 llamadas ya se considera un tiempo

de encolamiento y en este caso mayor al que pueda haber con
2 llamadas, es por tal la forma de la gráfica.

Para “jitter.tr”
 De 10 a un valor en el que no haya pérdidas. En este caso se le
puso 250. Y estos fueron los resultados:

Para “delay.tr”

Para “jitter.tr”

Para “jitter.tr”

Para “th.tr”

Para “th.tr”

Para “loss.tr”

Como se aprecia en las imágenes y el resultado de “loss.tr”,

hay un mejor aprovechamiento del ancho de banda, pero se
genera una gran cantidad de pérdida de paquetes.
Una solución a esto sería aumentar el tamaño de la cola.
Para “loss.tr”
Como se observa al aumentar el tamaño de cola se evitan las
pérdidas y se genera un mejor transcurso de las 3 llamadas.

Y finalmente se agrega una llamada más.

En la figura anterior se puede observar que cada paquete pasa
más tiempo en la cola, esperando a ser transmitidos.

Para “th.tr”

Donde se obtienen las siguientes gráficas.

Para “delay.tr”

Como se menciona en los casos anteriores, se visualiza el

desperdicio de ancho de banda, siendo necesario el reajuste de
velocidad de transmisión.

La modificación a realizar es la siguiente:

Para “loss.tr”:

Con la velocidad de transmisión anterior, no se presenta

ninguna pérdida de paquetes.
En este caso se comprueba una vez más que mientras más
llamadas se realicen en simultáneo el retardo va aumentando.
Con el reajuste de velocidad, las demás gráficas quedarían de
la siguiente manera:
Para “jitter.tr”
Para “delay.tr”

En el “jitter” podemos verificar que mientras más llamadas

estén en curso, más tiempo pasarán los paquetes de datos en
las colas.
Para “jitter.tr”
 https://www.cisco.com/c/en/us/support/docs/voice/voice-
quality/7934-bwidth-consume.html

Miguel S. Nathaly Estudiante de Ingeniería

Electrónica en la Universidad Nacional
Pedro Ruiz Gallo, cursando actualmente el
noveno ciclo. Ha asistido a disntitas
conferencias relacionadas a su carrera, asi
como talleres. Ha sido organizadora del
Para “th.tr” SINTEL, actividad que se lleva a cabo
como parte del aniversario de su Facultad,
misma actividad que reune a diversas universidaes para
conferencias y concursos relacionadas a la carrera. Tiene
conocimientos en programas de escritorio tales como
AutoCAD, Matlab, Arduino, EAGLE, Proteus, entre otros.
Además de conocimientos en lenguajes de programación,
elaboración de placas circuitales y proyectos de ingeniería.

Rodas C. Frank Estudiante de Ingeniería

Electrónica en la Universidad Nacional
Aquí se puede visualizar el correcto uso del ancho de banda. Pedro Ruiz Gallo, cursando actualmente el
noveno ciclo. Asistió a diversas
Para “loss.tr” conferencias organizadas por EPIE
Universidad Nacional Pedro Ruiz Gallo.
Tiene conocimientos intermedios de
lenguajes tales como Arduino, Assembler,
C++. Domina plataformas tales como
Aquí podemos observar que con el reajuste de velocidad
EAGLE, Proteus, emu8086, Borland C++, entre otros. Tiene
parece la pérdida de paquetes, que se puede solucionar con el
intereses futuros respecto a la Bioingeniería.
reajuste de tamaño de cola:

Una vez hecha la modificación se puede observar que se

solucionó el problema de la pérdida de paquetes.

VI. CONCLUSIÓN
Se comprendió el uso del software NS2 para simular
diversos escenarios y entender los factores que afectan en el
desempeño de la red. A la vez que se logró entender las
gráficas obtenidas según los diversos cambios realizados.

VII. REFERENCIAS

[1] Carballar, J. A. (2007). VoIP : la telefonía de Internet.

Editorial Paraninfo.
[2] Gutiérrez Gil, R. (2012). Seguridad en VoIP: Ataques,
Amenazas y Riesgos., 39.
[3] Joskowicz José. (2013). Voz Video y Telefonia sobre IP.
Montevideo, Uruguay.
[4] Voice Over IP - Per Call Bandwidth Consumption. (2016,
abril). Recuperado 2 de mayo de 2018, a partir de