Estimaciones del Ancho de Banda en redes

de Banda Ancha

Bandwidth Estimation in Broadband Access Network

Karthik Lakshminarayanan
University of California Berkeley
Venkata N. Padmananbhan
Microsoft Research
Jitendra Padhye
Microsoft Research

Gabriel Firme
Ing. Mateo Ruetalo

Consideraciones preliminares
Existen muchos trabajos sobre tcnicas para estimar la capacidad y el ancho de banda
disponible sobre una red basadas en medidas punto a punto. Generalmente los enfoques se
basan en configuraciones modeladas como un enlace punto a punto con un ancho de banda
bien definido y un trfico de paquetes tipo FIFO.
En el siguiente trabajo se muestra que redes de banda ancha como las de cable mdem
y redes inalmbricas basadas en el estndar 802.11 no cumplen con este modelo por varios
motivos:
el camino cursado por los paquetes puede utilizar mecanismos de administracin de
velocidad de trasmisin como token bucket,
puede traficar paquetes de una forma diferente a una cola FIFO,
puede soportar mltiples velocidades diferentes,
etc.
En el presente trabajo tambin se analiza como estas caractersticas impiden la
operacin de varios mtodos y herramientas de estimacin de capacidad y ancho de banda
disponible y presenta una nueva tcnica de estimacin de ancho de banda disponible;
PROBEGAP, el cual tiene en cuenta estas dificultades.
Se evala dicha herramienta en enlaces Cable mdems y 802.11a.
INTRODUCCIN
Se han desarrollado muchas tcnicas para estimar la capacidad y ancho de banda
disponible sobre un camino de red basadas en medidas punto a punto.
La capacidad de un camino se define como el ancho de banda del enlace ms pequeo
del camino.
El ancho de banda disponible se define como la disponibilidad de trafico del enlace mas
comprometido del camino cursado por los paquetes, es decir es el valor del trafico que puede
cursar un nuevo flujo por dicho enlace sin generar congestin en los flujos existentes.
Trabajos previos han asumido un modelo simple de enlaces en una red; el modelo
tradicional. Este modelo le asigna al enlace comprometido (el de menor ancho de banda
disponible) de un camino un valor bien defino de ancho de banda que determina la velocidad de
transmisin por el enlace. Este se asume punto a punto con modelo de tratamiento de paquetes
FIFO, incluyendo los paquetes de medida y el cross-traffic.
El cross-traffic se asume con un modelo de trfico de tipo fluido.
En el presente trabajo se muestra que muchas de las suposiciones utilizadas en el
modelo tradicional fallan al modelar redes de banda ancha tipo cable mdem o inalmbricas
802.11.
Este tipo de redes han proliferado como acceso a hogares y probablemente en muchos
casos pasaron a ser los enlaces comprometidos por lo tanto la desviacin del modelo
tradicional asumido es significativa.
Existen varias razones por las cuales el modelo tradicional falla:

El enlace no cuenta con un Ancho de Banda fijo o bien definido, por ejemplo debido a la
regulacin de velocidad token bucket utilizada en la tecnologa cable mdem o
esquemas de mltiple velocidad dinmica utilizada en redes 802.11. Es necesario
distinguir entre el Ancho de Banda bruto y el ancho de banda visto por un flujo
continuo de paquetes.
El modelo de tratamiento de paquetes no tiene por que ser FIFO debido al protocolo de
control de acceso al medio utilizado en las redes 802.11 o cable mdem.

Los enlaces de mltiples velocidades 802.11 pueden interferir y crear grandes picos de
cross traffic que resultan en desviaciones significativas del modelado del cross traffic
como un fluido.
Este trabajo realiza tres contribuciones:
1. Identifica las caractersticas de las redes de banda ancha que presentan
cambios en las tcnicas existentes de estimacin de capacidad y ancho de
banda disponible.
2. Evala estos problemas a travs de experiencias realizadas sobre redes de
banda ancha reales. El trabajo se enfoca en enlaces de banda ancha aislados y
no en enlaces que forman parte de Internet para poder evaluar especficamente
las caractersticas de la banda ancha.
3. Se presenta una nueva tcnica de estimacin de ancho de banda llamada
ProbeGap la cual promete poder resolver algunas de estas dificultades. La idea
principal de dicha tcnica es investigar la existencia de huecos (periodos
ociosos) en el enlace mediante el clculo del retardo de las muestras en un
sentido (OWD: One Way Delay).

Mtodos de medida
Metodos PRM (packet rate method):
Las herramientas basadas en este mtodo como el Pathload, PTR, Pathchirp y TOPP se
basan en las siguientes observaciones:
un tren de paquete de prueba enviados a una velocidad menor que el ancho de banda
disponible debera ser recibido a la misma velocidad enviada (en promedio)
sin embargo si la velocidad a la cual fue enviado excede el ancho de banda disponible
la velocidad de recepcin es menor que la de trasmisin y los paquetes de prueba van
a tender a encolarse provocando retardo en ese sentido (OWD).
Por lo tanto el ancho de banda disponible puede ser estimado mediante la observacin
de la velocidad de trasmisin en la cual sucede una transicin entre estos dos
comportamientos.
En este trabajo se tom la herramienta Pathload como representativa de este mtodo.

Figura 1

Metodos PGM (packet gap method):

Herramientas basadas en este mtodo como Spruce, Delphi e IGI envan pares de

paquetes de prueba de igual tamao separados acorde al tiempo de transmisin de las pruebas
sobre el cuello de botella del enlace.
Si no se inserta cross-traffic entre los paquetes de prueba el espacio entre los paquetes
de prueba se mantiene hasta el destino. Por otro lado, el incremento del espacio entre paquetes
de prueba se utiliza para estimar el volumen del cross-traffic el cual luego es restado de la
capacidad estimada para obtener el valor del ancho de banda disponible estimado.
A diferencia de PRM, el PGM asume que el enlace comprometido es el enlace mas
estrecho del camino y es susceptible a retardos por encolamiento en los enlaces no
comprometidos.
En este trabajo se tom la herramienta Spruce como representativa de este mtodo.

Figura 2

Regulacin del trfico

Se supone que un enlace tiene un ancho de banda bien definido que indica la velocidad a
la cual los bits pueden ser enviados a travs de l. Sin embargo, esta suposicin no es valida
cuando se utiliza un plan de regulacin de trfico.
Tpicamente, los ISPs dividen la subida al enlace de acceso fsico en pequeas ranuras
que reparten en lotes a sus clientes.
Por ejemplo, el ancho de banda total de una red de cable mdem tpica en USA tiene 27
Mbps aguas abajo y 2.5 Mbps aguas arriba (por canal). Sin embargo, el ancho de banda
comprometido a cada cliente es tpicamente un orden de magnitud ms pequeo, en ambas
direcciones.
Para repartir el ancho de banda el ISP utiliza un plan de regulacin de trfico en su
equipo terminal. El mecanismo usado normalmente en las redes cable mdem es el mtodo
token bucket el cual especifica la velocidad de acceso media a la red en bits por segundo y el
tamao del pico mximo en bytes.
Aunque la velocidad lograda por una transferencia prolongada est acotada por la
velocidad media, es posible enviar un flujo datos del tamao del token bucket a una velocidad
igual al ancho de banda del enlace.
Por lo tanto es necesario hacer una distincin entre el ancho de banda de enlace y el
mximo ancho de banda posible para una transferencia prolongada. Es posible que pares de
paquetes o pequeos trenes de paquetes pueden medir el ancho de banda total del enlace.
Esquema no-FIFO y contencin
El modelo tradicional asume que todos los paquetes que arriban a un enlace son
despachados en orden fifo. Por lo tanto se asume que un paquete de prueba experimenta un
retardo de encolamiento proporcional al volumen total en bytes del cross-traffic que lo precede

en la cola. No asume como crtico el tamao de los paquetes del cross-traffic.

Sin embargo en configuraciones de redes de banda ancha el modelo basado en enlaces
FIFO falla. En redes inalmbricas basadas en el estndar 802.11 las estaciones compiten por el
acceso al canal de una forma distribuida.
En el caso de una red cable-mdem, el acceso a la red desde el usuario es administrado
por el CMTS quien peridicamente enva un mensaje de control indicando los time-slots
asignados a las distintas estaciones e invitando a las estaciones a competir por los time-slots
libres.
Por lo tanto en ambos casos los paquetes encolados en las distintas estaciones podran
no ser enviados en orden FIFO.
Una consecuencia del esquema no-fifo es que puede llegar a ser muy complicado en
situaciones de mucha carga asegurar que un par de paquetes atraviesan la red sin que se les
intercale trafico. Especialmente cuando el protocolo de acceso al medio es equitativo como
cuando se utiliza encolamiento explicito (acceso desde el usuario en las redes cable) o un
mecanismo distribuido (redes 802.11). Lo que sucede es que cuando una estacin deja de
trasmitir una trama pasa a tener una baja probabilidad de acceder al medio en la siguiente
contienda comparada con las restantes estaciones.
Esta dificultad de enviar pares de paquetes consecutivos con separacin fija impide la
operacin de las tcnicas de estimacin de capacidad.
Otra consecuencia del modelo no-fifo es que un nuevo paquete de prueba encolado en
una de las estaciones puede llegar a ser trasmitido antes que un viejo paquete de cross-traffic
que espera en otra estacin. Por lo que el paquete de prueba no experimenta el retardo
proporcional al volumen total de cross-traffic existente en la red, produce una subestimacin
del trafico cursado sobre la red y esto genera una subestimacin del ancho de banda
disponible.
La situacin es complicada por el hecho de que los esquemas donde los equipos
compiten por el acceso al medio se basan en tramas independientemente del tamao de estas.
Al competir flujos con tamaos de paquetes diferentes tienden a compartir el ancho de banda
proporcionalmente al tamao de los mismos.
Por lo tanto la estimacin producida por la tcnica de estimacin de ancho de banda
disponible va a depender del tamao relativo del trfico de prueba y del cross-traffic.
Finalmente un control de acceso al medio competitivo tpicamente resulta en una perdida
de eficiencia proporcionalmente al numero de estaciones que compiten por el medio.
Para un volumen de cross-traffic dado el ancho de bada disponible tiende a decrecer
cuando el numero de estaciones aumenta. Este efecto es significativo solo cuando el numero de
estaciones es grande. En este trabajo no se evaluar este efecto.

Figura

Enlaces multi-velocidades
Los enlaces pueden operar o variar entre diferentes velocidades. Por ejemplo el estndar
802.11b soporta adaptacin de velocidad dinmica, es decir que un terminal puede cambiar su
velocidad entre 1, 2, 5.5 y 11 Mbps mediante el cambio de la modulacin utilizada dependiendo
de la calidad del canal utilizado, la cual puede variar dinmicamente dependiendo de la
movilidad del usuario, cambios en el entorno, etc.
De la misma forma el estndar 802.11a soporta velocidades variables entre 6 y 54 Mbps.
Por lo tanto el ancho de banda total del enlace entre una estacin inalmbrica y un Accesspoint puede variar abruptamente.
An si la velocidad del enlace para cada estacin no cambia frecuentemente, estaciones
diferentes en la misma regin pueden estar operando a diferentes velocidades compartiendo el
mismo espectro inalmbrico. Por lo tanto el impacto que un volumen dado de cross-traffic a una
estacin genera sobre el ancho de banda disponible de otra estacin depende de la velocidad a
la que est trabajando el primero.

Por ejemplo, considerar dos terminales asociados a un mismo Access point, uno de ellos
trata de estimar el ancho de banda disponible y puede comunicarse con el AP a 54 Mbps,
mientras que el otro cliente que es el que genera el cross-traffic puede comunicarse con el
Access-point slo a 6 Mbps (esto puede deberse a la distancia a la que se encuentra del
Access-point).
Dado que el estndar 802.11 maneja la contienda entre terminales por paquetes, un solo
paquete de cross-traffic enviado a 6 Mbps puede ser visto como un gran burst desde el otro
usuario.

Figura 4

Esto influye en la estimacin del ancho de banda disponible en ambas tcnicas PRM y
PGM.
Estas tcnicas trabajan mejor en los casos en que el cross-traffic se modela como un
fluido (asumiendo tamaos de paquetes infinitesimales) es decir que los paquetes de crosstraffic y los de prueba se entremezclan uniformemente .
Los picos grandes de cross-traffic complican la deteccin del crecimiento de velocidad
cuando la velocidad de prueba sobrepasa el ancho de banda disponible. Esto afecta mas a las
tcnicas basadas en PRM como el Pathload.
Por otro lado la ausencia de burst (picos) complica a las tcnicas PGM como Spruce para
obtener una muestra exacta de cross-traffic.

Figura 5

PROBEGAP
Una vez discutido los problemas que las configuraciones no-fifo y las contiendas de
acceso al medio por tramas causan a las tcnicas existentes en el siguiente punto se presenta
ProbeGap una nueva herramienta para la estimacin del Ancho de Banda disponible que alivia
estos problemas.
La idea es estima la fraccin de tiempo que el enlace est libre mediante el sondeo de
huecos en los perodos de enlace ocupado y luego al multiplicarla por la capacidad se obtiene
una estimacin del Ancho de Banda disponible.
ProbeGap estima la fraccin de tiempo libre reuniendo muestras de retardo del enlace en
un sentido OWD (One-Way delay).
El trasmisor enva series de paquetes de prueba espaciados segn la distribucin de
poisson, cada uno de 20 bytes de payload conteniendo una marca de tiempo local.
El receptor sustrae la marca de tiempo del trasmisor para calcular el OWD. Luego
normaliza el OWD a partir del valor menor de las muestras, por lo tanto el valor menor del OWD
normalizado es cero.
Los relojes del trasmisor y receptor no necesitan estar sincronizados solo se necesitan
que mantengan un offset constante.
Si al probar el enlace se encuentra libre se obtiene un OWD bajo. Por otro lado si es
necesario que espere ya que existen paquetes a ser trasmitidos o encolamientos el OWD es
mayor.

Figura 6 Caracterizacin de ProbeGAP

Como se muestra en la figura 6 la distribucin de las muestras del OWD muestran 2

regiones distintas, la menor corresponde al enlace libre y la mayor corresponde al enlace
ocupado. Por lo tanto el codo en la curva CDF (Cumulative Distribution Function) de las
muestras OWD identifica la fraccin de tiempo que el canal est libre.
El vrtice de la curva se identifica de la siguiente forma: para cada punto de la curva CDF
se calcula el valor local de la pendiente entre el punto anterior y el siguiente. El valor local de
la pendiente se calcula mediante una regresin lineal de todos los puntos dentro de 0.05 del
punto de inters a lo largo del eje CDF. Se toma 0.05 para ser lo suficientemente pequeo
como para reflejar el valor local de la pendiente y lo suficientemente grande como para evitar
aberraciones producidas por ruido en los datos.
El punto con el mayor valor de la pendiente entre el punto anterior y el siguiente se
identifica como el codo de la curva CDF, la relacin mnima tiene que ser 2. Si no se logra
ubicar dicho punto se puede concluir que el canal est 100% ocupado.
Como una refinacin adicional para minimizar el efecto del ruido en las medidas, se
consideraron solo los puntos con un OWD normalizado menor a 100 microsegundos como
candidatos a ser el punto de quiebre. Estos valores no excluyen el verdadero punto de quiebre
que tpicamente tiene un valor normalizado del OWD mucho menor que 100 microsegundos.
Aunque esta heurstica es intuitiva y funciona bien en los datos experimentales obtenidos
en el presente trabajo no es muy satisfactorio el haber utilizado constantes arbitrarias.
En el presente trabajo se busca un mtodo mas robusto basado en la estimacin de
parmetros basados en el modelo OWD
La prueba realizada con la herramienta ProbeGap consisti en 200 paquetes de 20 bytes
enviados durante un intervalo de 50 segundos. La herramienta es mas inmune que las tcnicas
PGM y PRM a los efectos de modelos no-fifo, contencin por paquete y cross-traffic.
ProbeGap no es totalmente inmune a los efectos no-fifo dado que existe una pequea
chance de que un paquete de prueba arribe durante un periodo ocioso entre sucesivos crosstraffic y logre tomar el canal por lo tanto sufrir un pequeo OWD.
Este problema se puede reducir haciendo que la herramienta ProbeGap enve grupos de
paquetes de prueba y tomar el mximo OWD de cada grupo como la muestra correcta. Si el
canal est libre en realidad, la medida del OWD en realidad ser baja. Pero si el canal est
ocupado es improbable que todas las medidas de un grupo de pruebas den un bajo OWD,
probablemente se medir un OWD alto.
Como Spruce pero a diferencia de Pathload, ProbeGap es susceptible a variaciones en
los retardos debidas a enlaces diferentes del cuello de botella, lo cual puede ser un a
complicacin, por ejemplo en enlaces con mltiples tramos congestionados. Por lo tanto no se
puede asumir que ProbeGap es la alternativa a las herramientas existentes en dichas
configuraciones.
Por otro lado en este trabajo se analiza enlaces de banda ancha aislados. Se asume que
la estimacin del ancho de banda disponible incluso en dichas configuraciones locales con un
enlace comprometido dominante son de inters.
Por lo tanto no se propone a ProbeGap como una alternativa para tales configuraciones.
Sin embargo, el trabajo se enfoca en la banda ancha aislada. El ancho de banda disponible en
tales coconfiguraciones de rea local con un enlace dominante es del inters.

Herramientas
Para estimacin de capacidad, se utiliz Pathrate, la cual utiliza gran parte de la teora
desarrollada hasta ahora sobre estimacin de capacidad a partir de generacin de pares de
paquetes y trenes de paquetes.

Para la estimacin del ancho de banda disponible se utiliz Pathload (herramienta

basada en PRM) y Spruce (herramienta basada en PGM). Tambin se utiliz la herramienta
propuesta en este trabajo ProbeGap para la estimacin del ancho de banda disponible.
La herramienta Spruce se configur para enviar 1000 muestras.
Se utiliz un generador de trafico UDP simple para generar cross traffic con una
distribucin de Poisson a distintas velocidades y distintos tamaos de paquetes (la distribucin
de Poisson para el espaciado entre paquetes asegura que el cross-traffic contenga mas picos
que un trafico CBR).

RESULTADOS EXPERIMENTALES
La evaluacin por medio de un token bucket se hizo sobre una red de cable-mdem
mientras que los experimentos restantes en 802.11.
Impacto de token bucket en cable-mdem
Inicialmente se analiza el downlink del banco de pruebas de cable-mdem. La tasa bruta
del canal es de 27 Mbps, la tasa token-bucket tiene 6 Mbps, y la capacidad del token-bucket es
9600 bytes. El cross-traffic fue dirigido a la misma estacin (i.e., cable-mdem) como trfico de
prueba, por esto la manejo no-FIFO de las colas no fue problema en los experimentos.
Estimacin de la capacidad del canal
Los autores corrieron Pathrate con varios niveles del cross-traffic varindolo de 0 a 6
Mbps. Cuando la tasa de cross-traffic era de 6 Mbps, Pathrate no pudo terminar debido a que
las prdidas de paquetes de pruebas fueron demasiadas. En los otros casos, Pathrate devolvi
ambas estimaciones la mayor y la menor de 26 Mbps, que est cercan de la tasa bruta de 27
Mbps.. Bsicamente, el token bucket es suficientemente grande (9600 bytes) como para
permitir suficientes paquetes de prueba juntos (back to back) -a pesar del cross-traffic- de modo
de medir la capacidad. Mientras que uno pueda sostener que la tasa bruta del canal es la
capacidad verdadera entonces la estimacin de Pathrate ser correcta. Sin embargo esta
estimacin no es muy usada debido a que esta tasa es inasequible de un modo sostenido, an
en la ausencia de cross-traffic.
Estimacin del ancho de banda disponible
Pathload: Como se muestra en la figura 4 , Pathload tiende a sobreestimar el ancho de
banda disponible. Sin cross-traffic mide un ancho de banda disponible de 6.5-8.3 Mbps mientras
que confirmamos que el enlace no puede sostener una tasa mayor a 6 Mbps. La razn para
esta sobre estimacin es que Pathload para estas tasas usa paquetes de prueba de 300 bytes,
y como el tamao del token-bucket de 9600 bytes una gran parte de los paquetes de prueba
puede desbordar a la tasa bruta del canal, modificando la tendencia de OWD que Pathload
mira. A medida que el cross-traffic aumentaba la tasa es 3 Mbps y 6 Mbps, estas estimaciones
caen hasta 3.3-4.6 Mbps y 0 Mbps, respectivamente.

Figura 7 - muestra la estimacin mediante Spruce para diferentes

niveles de cross-traffic sobre un enlace de bajada en una red
cable-mdem.

La diferencia de la estimacin depende de la capacidad asumida por Spruce; el ancho de

banda bruto del canal (26 Mbps) o la tasa del token bucket (6 Mbps)

Figura 8 - muestra el impacto del tamao de paquete sobre el throughput

(rendimiento). La capacidad nominal del canal nominal es 6Mbps para la
grafica de la izquierda y 54Mbps para la grfica derecha. Cada columna
representa el promedio de 3 corridas.

Spruce: Necesita una estimacin de la capacidad de enlace como la entrada. No queda

claro que capacidad asume Spruce. Corrimos experimentos asumiendo ambas capacidades
obtenidas por Pathrate ( 26 Mbps ) y por token-bucket ( 6 Mbps ). La Figura 6 muestra los
resultados.
Vimos que en ambos casos sobreestiman significativamente el ancho de banda
disponible. La razn es que dependiendo del estado del token bucket, los paquetes de prueba
pequeos pudieron pasar a la tasa supuesta an en presencia de cross-traffic, obteniendo una
sobreestimacin del ancho de banda.
Hacemos dos observaciones adicionales. En primer lugar, cuando la capacidad es
supuesta es de 26 Mbps, la estimacin de Spruce correspondiente al cross-traffic de 3 Mbps
(2.5 Mbps) es significativamente menos que el correspondiente a 6Mbps cross-traffic (6.9
Mbps). El alto nivel de congestin en este ltimo caso causa que el 60-70% de los paquetes de
prueba de Spruce se pierdan, estimndose como si el cross-traffic fuera comparativamente
mayor. En segundo lugar, cuando la tasa de cross-traffic es de 3 Mbps, la estimacin obtenida
asumiendo una capacidad de 6Mbps (4.5 Mbps) es considerablemente ms grande que se
obtuvo asumiendo una capacidad de 26Mbps ( 2.5 Mbps ). La razn es que en este ltimo caso
el aumento de la separacin entre los paquetes de prueba de Spruce debida al cross-traffic son
mucho ms altas en relacin a la separacin a la entrada.

Sumario: Los experimentos indican que la capacidad y el ancho de banda disponible

estimadas estn comprometidas debido a la dicotoma entre el ancho de banda de enlace bruto
y el simblico del token-bucket. El problema es particularmente agudo en el caso de un mtodo
de PGM como Spruce, desde el momento en que no existe ninguna estimacin de capacidad
correcta que se pueda hacer.
Impacto del tamao de paquete en 802.11
Dado que la transmisin de paquetes con un control de acceso al medio basado en
contencin como el estndar 802.11 involucra un overhead significativo (como el prembulo y
el espaciamiento mnimo entre paquetes sucesivos), los autores midieron el impacto del
tamaos de los pequeos en el mximo throughput alcanzable inyectando en el sentido de
subida una rfaga de paquetes consecutivos de varios tamaos. Tambin se vari el nmero
de pares de nodos de 1 a 3. La figura 8 muestra los resultados cuando la velocidad de la tarjeta
inalmbrica fue configurada a 6 Mbps y 54 Mbps.
Cross-traffic total
Estimacin

0
5.2 5.4

3
5.1 5.4

4
5.3 5.5

Figura 9 - muestra la estimacin de la capacidad del canal utilizando

Pathrate bajo varias cargas. Capacidad nominal del canal 6 Mbps.

Cross-Traffic
Tamao
Tasa
Paquete
300
1
1472
300
2
1472
300
3
1472
300
4
1472

Estimacin
Pathload
2.9 2.9
33
2.2 2.3
2.2 2.3
2.3 2.3
1.6 1.6
2.3 2.3
0.9 0.9

Spruce
3.7
4.2
3.2
3.5
3.8
1.5
3.7
1.2

300
2.4
2.7
1.6
2.0
0.8
1.4
0.4
0.7

Medidas
ProbeGap
1472
3.4
3.9
2.3
2.9
1.1
2.1
0.6
1.1

300
2.5
2.7
1.7
2.0
0.4
1.4
0.1
0.7

1472
3.7
4.2
2.3
3.3
0.6
2.4
0.1
1.1

Figura 10 - muestra la tasa sencilla: Estimacin del ancho de banda disponible bajo varias cargas. Capacidad
nominal del canal 6 Mbps.

Vemos esto en ambos casos, el rendimiento acumulativo de los pares crece

significativamente con el tamao de paquete pequeo, pero no dependa fuertemente en el
nmero de comunicar pares. As, se puede concluir que el motivo principal de la baja del
throughput (rendimiento) es el overhead de la capa de control de acceso al medio, y no el
overhead generado por los Sistemas Operativos de los equipos trasmisor y receptor. De otra
manera el throughput debera haber crecido con el nmero de pares.
Impacto del Control de Acceso al Medio basado en contienda del standard 802.11
Para los experimentos realizados en esta seccin, todas las tarjetas de red inalmbricas
se configuraron para trabajar a 6 Mbps.
Estimacin de la capacidad del canal
Los autores corrieron Pathrate entre las maquinas M1 y M2, mientras que las mquinas
M3-M6 se utilizaron para generar cross-traffic a varias velocidades y tamaos de paquetes.

En todas las corridas, Pathrate produjo una estimacin consistente entre 5.1 y 5.5 Mbps.
Esta estimacin es cercana al mximo valor de trfico UDP que soporta el canal, como se ve en
la figura 8.
Para comprender porque los resultados de Pathrate no son afectados por el mtodo de
acceso al medio por contienda los autores analizaron los logs del Pathrate. Encontraron que
Pathrate siempre era capaz de encontrar un modo entre 5.1- 5.3 Mbps, indicando que al menos
ciertas paquetes de prueba salen uno tras del otro. Esto es porque aunque el procedimiento de
contienda del estndar 802.11's tiene una predisposicin contra el equipo que acaba de
trasmitir un paquete, existe la posibilidad de que el mismo terminal gane nuevamente la
contienda especialmente cuando la cantidad de equipos involucrados en la contencin es
pequea como en la experiencia.
El modo ubicado entre los 5.1 y 5.3 Mbps no es el modo dominante especialmente bajo un
cross traffic pesado. Sin embargo la medida de la dispersin asinttica usualmente genera un
modo que incluye por lo menos parte del modo de baja velocidad.
As, la herramienta siempre escoge el modo ms alto, resultando en la estimacin de
capacidad correcta.
Estimacin de ancho de banda disponible
En este punto los autores utilizaron las siguientes herramientas de estimacin de ancho
de banda disponible; Pathload, Spruce y ProbeGap.
Estas herramientas siempre se corrieron entre M1 y M2, mientras que se gener crosstraffic entre M3 y M4.
La tasa del cross-traffic se vari entre 1 y 4 Mbps en pasos de 1 Mbps. Se utilizaron dos
tamaos de paquetes para el cross traffic: 300 y 1472 bytes.
Como se ve en la figura 8 el canal satur a 3.5 Mbps para un tamao de paquete de 300
bytes y a 5.1 Mbps para un tamao de paquete de 1472 bytes.
As, por ejemplo, una carga de cross-traffic ofrecido de 3 Mbps usando paquetes de 300
bytes constituye una carga pesada mientras que la misma tasa con paquetes de 1472 bytes
constituye una carga moderada.
Dado que Pathload usa paquete de 300 bytes los autores compararon sus estimaciones
con las medidas de ancho de banda disponible para paquetes de 300 bytes.
Tambin, como Spruce usa paquetes de prueba de 1472 byte, los autores especificaron
la capacidad con el valor de 5.1 Mbps y sus estimaciones solo se compararon con la medidas
de ancho de banda disponible para paquetes de 1472 bytes.
En cambio, compararon las estimaciones de ProbeGap con el ancho de banda disponible
medido para ambos tamaos de paquete, por razones discutidas mas adelante.
Los resultados se muestran en la figura 10.
Pathload: Segn los autores bajo condiciones de carga baja, la estimacin de Pathload
coincide bien con la medida del ancho de banda disponible para paquetes de 300 bytes , sin
tener en cuenta el tamao del paquete de cross-traffic.
Por otra parte, Pathload sobreestima el ancho de banda disponible cuando el cross-traffic
es alto porque es una herramienta basada del PRM.
Con un tipo de control de acceso al medio por contienda, si un equipo trasmisor est
enviando paquetes a una tasa mayor de la que le corresponde, y un segundo equipo
lentamente comienza a incrementar los paquetes trasmitidos, entonces el mtodo de control de
acceso al medio empujar al primer equipo a trasmitir a la velocidad que le corresponde.
Mientras tanto la velocidad de salida de las pruebas utilizando mtodos PRM siguen al
valor de la velocidad de entrada y no existe incremento en el OWD de los paquetes de prueba.
El resultado neto es que la estimacin tiende al valor del ancho de banda
correspondiente mas que al ancho de banda disponible.
Spruce: Las estimaciones de Spruce se aproximan a la medida del ancho de banda
disponible cuando el tamao de los paquetes utilizados para cross-traffic y para validar son

ambos de 1472 bytes.

Esto se debe a que Spruce utiliza paquetes de 1472 bytes para probar el canal.
Por otro lado si el tamao de los paquetes de cross-traffic es de 300 bytes la
herramienta tiende a sobrestimar el ancho de banda disponible.
Por ejemplo para un cross-traffic de 4 Mbps incluyendo paquetes de 300 bytes, Spruce
estima el ancho de banda disponible en 3.7 Mbps mientras que para paquetes de 1472 bytes la
estimacin es de solo 0.1 Mbps.
Esto se debe a que el mtodo de contencin es por paquete el cual resulta en un numero
pequeo de paquetes de 300 bytes de cross-traffic insertados entre los pares de paquetes de
prueba del Spruce (los cuales son de mayor tamao).
ProbeGap: Como se explic, ProbeGap estima la fraccin de tiempo en la que el canal
est libre y multiplica este valor por la capacidad para estimar el ancho de banda disponible.
Por otro lado, dado que la capacidad depende del tamao del paquete, los autores
tomaron el valor de la capacidad correspondiente al tamao de paquete para el cual queremos
estimar el ancho de banda disponible (3.5 Mbps para paquetes de 300 bytes y 5.1 Mbps para
paquetes de 1472 bytes).
De los resultados, los autores concluyeron que las estimaciones del ProbeGap para un
tamao de paquete dado se acercan mas a la medida de ancho de banda estimado para el
tamao de paquete correspondiente.
Por otro lado, ProbeGap sobrestima el ancho de banda disponible para cuando el crosstraffic es alto.
Esto se debe a que aun cuando el canal est saturado de cross-traffic existe una
pequea chance de que los paquetes de prueba puedan arribar exactamente durante el periodo
ocioso entre sucesivos paquetes de cross-traffic y entonces ganar la contienda.
Esto da por resultado un OWD pequeo que ProbeGap toma equivocadamente como un
canal ocioso. Este efecto puede verse en la figura 11, donde an con 4 Mbps cross-traffic, casi
10-20% de los paquete de prueba llegan a su trmino produciendo un pequeo aumentando
pequeo en OWD.

Figura 11 - muestra el calculo de CDF de OWD bajo varias

condiciones de cross-traffic. Capacidad nominal del canal: 6Mbps
ProbeGap utiliz paquetes de prueba de 20 bytes OWD normalizado.

Cross-Traffic
Tasa
Tamao Paquete
0
300
2
1472
300
4
1472

Estimacin
31.3 33.3
23.8 27.8
24.3 27.66
28.8 31.2
26.5 32.5

Figura 12 - muestra la estimacin de la capacidad del canal mediante Pathrate

bajo varios valores de carga.

Figura 13

Impacto del manejo de mltiples velocidades en el estndar 802.11

En esta seccin, se presentan resultados cuantitativos que muestran el impacto sobre las
estimaciones (de todas las herramientas) que produce el manejo de mltiples velocidades en
entornos 802.11.
La configuracin utilizada es la siguiente:
2 maquinas (M1 y M2) configuradas a 54 Mbps (todas las herramientas de
estimacin corrieron sobre estas dos maquinas)
2 maquinas configuradas a 6 Mbps (todo el cross-traffic se genero entre estas
dos maquinas)
Estimacin de la capacidad de canal
Las estimaciones de capacidad producidas por Pathrate se muestran en figura 12. Se ve
que la estimacin de Pathrate es consistente con la capacidad del canal.
Estimacin del ancho de banda disponible
Se realizaron ensayos con el mismo conjunto de parmetros como en el caso de una
unica velocidad, se muestra un subconjunto de ellos en la figura 14.
Pathload:
Los autores consideraron un cross-traffic de 2 Mbps generado con paquetes de 300

bytes.
La estimacin generada por Pathload fue comparable con la medida del ancho de banda
disponible para paquetes de 300 bytes.
Sin embargo para un cross-traffic de 4 Mbps aunque el tamao de paquete fue de 300
bytes Pathload sobreestimo significativamente el ancho de banda disponible.

Cross-Traffic
Tamao
Tasa
Paquete
300
2
1472
300
4
1472

Estimacin
Pathload

Spruce

5.7 5.7
8.6 10.1
2.6 2.9
2.6 2.7

12
25.7
0
20.9

ProbeGap
300
1472
4.7
13.1
6.1
17.0
0.8
2.3
2.6
7.3

Medidas
300
5.1
6.5
0.3
2.7

Figura 14 - analiza el comportamiento en entornos con mltiples

velocidades: Estimacin del ancho de banda disponible bajo
diferentes niveles de carga.

Figura 15 - muestra una secuencia de OWD (One Way Delay) para una
rfaga de Pathload a una velocidad de 9.79 Mbps enviada en un canal de
54 Mbps, con un cross-traffic de 2 Mbps de paquetes de 1472 bytes en un
canal de 6 Mbps.

1472
13.9
18
0.3
7.5

Simulaciones
Para las simulaciones se creo la siguiente topologia en el archivo monografia.tcp el cual se
incluye al final de las simulaciones:
- Enlace entre los nodos W0 y W1: enlace cuello de Botella
- Enlace entre los nodos W1 y nodo2= BS(0): conexin a la radiobase wireless 802.11
- Nodos 3, 4 y 5 nodos inalambricos
En la siguiente figura se muestra la topologa creada:

Sobre dicha topologa se crearon tres fuentes generadoras de trafico constante CBR sobre UDP
de tamao de paquete y tiempo entre paquetes variable.
Para distintas simulaciones se configuro el archivo monografia.tcl acorde a las necesidades.
Fuentes de trafico:
CBR0: (fuente del tipo CBR_PP) fuente que genera trenes de n paquetes a una velocidad
configurada por usuario, en nuestro caso utilizamos trenes de 3 paquetes de diferentes tamao
a a diferentes velocidades.
Esta fuente genera paquetes desde el nodo inalambrico node_(0) (Nodo 3 en el NAM) hacia el
nodo fijo Wo.
CBR1 y CBR2 son fuentes que generan un flujo continuo de paquetes de tamao configurado
por usuario y tiempo entre paquetes tambien configurado por usuario (indirectamente se
configura el bit rate de la fuente).
Estas generan trafico desde los nodos node_(1) y node_(2)

OBJETIVO DE LA SIMULACION
Utilizar el simulador NS-2 para verificar el metodo de calculo de ancho de banda disponible de
un canal.
Primer caso canal sin Cross Traffic => AdeB disponible = AdeB del Cuello de Botella
Se configur lo siguiene:

enlace cuello de botella a 128 Kbps y 70ms de retardo

conexin a la radiobase a 10 Mbps y 2 ms de retardo
se utiliz solo un CBR con tamao de paquete fijo y se fue reduciendo el tiempo
entre paquetes (aumentando el bit rate) hasta saturar el canal y verificar el
AdeB del cuello de botella.

El proceso record del scripr monografia.tcl paso a paso va calculando el tiempo entre
paquetes recibidos en la fuente destino (W0).
Dichos resultados se grafican y se obtiene aproximadamente el valor medio del retardo entre
paquetes en el destino a partir de la grafica del Xgraph.

Datos obtenidos:
Cuello de botella
Tamao de paquete
Cross Traffic
Tiempo de Simulacin
Tiempo de rutina
Record

kbps inyectados
10
90
100
110
120
130
140
150

128Kbps
200 bytes
0
100 segundos
1 mseg

paq/seg
6.25
56.25
62.5
68.75
75
81,25
87,5
93,75

Tiempo entre
paquetes
160ms
17,777
16
14,5454
13,3
12,31
11,43
10,67

tiempo entre paquetes

(recibido)
155ms
17.0
15.5
14
13.7
13,7
13,7
13.7

Resultados:
Se verifica que para bits rates mayores a los 120 130 Kbps el tiempo entre llegada de
paquetes no disminuye, es decir llegamos a saturar el cuello de botela, los paquetes se
comienzan a bufferear en el enlace de menor ancho de banda.

En el siguiente paso se mejora el metodo de estimacin utilizando una fuente que genera un
tren de tres paquetes en lugar de un tren continuo de paquetes (siempre en ausencia de cross
traffic):

Se configur lo siguiene:

enlace cuello de botella a 128 Kbps y 70ms de retardo

conexin a la radiobase a 10 Mbps y 2 ms de retardo
se utiliz solo un CBR_PP de tres paquetes con tamao de paquete fijo y se
fue aumentando el bit rate hasta saturar el canal y verificar el AdeB del cuello
de botella.

El proceso record del script monografia.tcl paso a paso va calculando el tiempo entre
paquetes recibidos en la fuente destino (W0) en este caso se utiliz 1 mseg..
Dichos resultados se grafican y se obtiene aproximadamente el valor medio del retardo entre
los paquetes del tren y entre el ultimo y el primer paquete del tren siguiente.
Tabla:
Cuello de botella
Tamao de
paquete
Tren
Cross Traffic
Tiempo de
Simulacin
Tiempo de rutina
Record
Kbps inyectados

90
100
110
120
130
140

128Kbps
500 bytes
3 paquetes
0

(en un canal de 128 Kbps 31,25 ms

en TX)

1 seg
1 mseg
paq/seg

22,5
25
27,5
30
32,5
35

tiempo entre paquetes del

tren
ms
32,5
32,5
32,5
32,5
32,5
32,5

medidas
tiempo entre ultimo y
primero
ms
68,1
54,84
43,9
34,83
32,5
32,5

paq/seg
RX
22,54
25,03
27,55
30,05
30,77
30,77

Resultados:
Se verifica que para bits rates mayores a los 120 130 Kbps la cantidad de paquetes por
segundo recibido no crece, es decir llegamos a saturar el cuello de botela, los paquetes se
comienzan a bufferer
nd

Vista de la simulacin:

Vista del resultado de los tiempos entre

paquetes recibidos:
valores bajos: tiempo entre
paquetes del tren
valor alto: tiempo entre el
ultimo paq. y el primer del
tren siguiente.

Segundo caso canal con Cross Traffic => se verific la incidencia del cross trffic en la
estimacin del AdeB disponible

Se configur lo siguiene:

enlace cuello de botella a 128 Kbps y 70ms de retardo

conexin a la radiobase a 10 Mbps y 2 ms de retardo
se utiliz un segundo CBR con tamao de paquete 200 bytes y tiempo entre
paquetes de 25 ms generando un bit rate de 64 Kbps.
se utiliz un CBR con tamao de paquete fijo y se fue reduciendo el tiempo
entre paquetes (aumentando el bit rate) hasta saturar el canal y verificar el
AdeB del cuello de botella.

El proceso record del script monografia.tcl paso a paso va calculando el tiempo entre
paquetes recibidos desde las dos fuentes en el destino (W0).
Dichos resultados se grafican y se obtiene aproximadamente el valor medio del retardo entre
paquetes en el destino a partir de la grafica del .

Datos obtenidos:
Cuello de botella
Tamao de paquete
Cross Traffic
Tiempo de Simulacin
Tiempo de rutina
Record

128Kbps
200 bytes
1 fuente 64 Kbps
100 segundos

1 paq 200 bytes cada 25 ms

1 mseg

kbps inyectados

paq/seg

10
20
30
40
50
60
70

6.25
12.5
18.75
25
31.25
37.5
43.75

Tiempo entre
paquetes
ms
160
80
53.3
40
32
26.7
29

tiempo entre paquetes

(recibido)
Ms
155 +/- 10%
80 +/- 10%
55 +/- 15 %
37 +/- 20%
34 +/- 20%
28 *+/- 40%
27 +/- 50 %

Resultados:
Se verifica la incidencia del efecto combinado del cross traffic y del metodo de acceso al medio
de las fuentes que generan el trafico de medida y del cross traffic.

En las siguientes figuras se muestran algunas imgenes de las simulaciones:

Simulacin para el caso de paquetes
gerando a un CBR de 10Kbps (verde) en
presencia de un CBR de Cross Traffic de
64 Kbps (azul).

Simulacin para el caso de paquetes

gerando a un CBR de 70Kbps (verde) en
presencia de un CBR de Cross Traffic de
64 Kbps (azul).

En las siguientes figras se muestran los resultados graficos de las simulaciones que se
incluyeron en la tabla anterior:

Grafico del deltaT entre paquetes recibidos

generando un CBR de 10Kbps en
presencia de un CBR de Cross Traffic de
64 Kbps (cuello de botella de 128 Kbps).

Grafico del deltaT entre paquetes recibidos

generando un CBR de 30 Kbps en
presencia de un CBR de Cross Traffic de
64 Kbps (cuello de botella de 128 Kbps).

Grafico del deltaT entre paquetes recibidos

generando un CBR de 40Kbps en
presencia de un CBR de Cross Traffic de
64 Kbps (cuello de botella de 128 Kbps).

Grafico del deltaT entre paquetes recibidos

generando un CBR de 50Kbps en
presencia de un CBR de Cross Traffic de
64 Kbps (cuello de botella de 128 Kbps).

Grafico del deltaT entre paquetes recibidos

generando un CBR de 60Kbps en
presencia de un CBR de Cross Traffic de
64 Kbps (cuello de botella de 128 Kbps).

Grafico del deltaT entre paquetes recibidos

generando un CBR de 70Kbps en
presencia de un CBR de Cross Traffic de
64 Kbps (cuello de botella de 128 Kbps).

# Scripts realizados a partir del archivo wireless2.tcl

#
======================================================================
# Definicin de Parametros
#
======================================================================
set opt(chan)
Channel/WirelessChannel ;# Tipo de canal
set opt(prop)
Propagation/TwoRayGround ;# Modelo de Propagacin
set opt(netif)
Phy/WirelessPhy
;# Tipo de Interfaz
set opt(mac)
Mac/802_11
;# MAC
set opt(ifq)
Queue/DropTail/PriQueue ;# Tipo de Cola
set opt(ll)
LL
;# Tipo de Capa de Enlace
set opt(ant)
Antenna/OmniAntenna
;# Tipo de Antena
set opt(ifqlen)
50
;# Cantidad maxima de paquetes
set opt(adhocRouting) DSDV
;# Protocolo de ruteo Vector Distancia
set opt(cp)
""
;# No se utiliza el archivo cp
set opt(sc)
""
set opt(x)
100
;# Ancho de la Topologa
set opt(y)
100
;# Alto de la Topologa
set opt(seed) 0.0
;#
set opt(nn)
3
;# Numero de nodos mobiles
set Num_Nodos_Alamb 2
;# Numero Nodos Cableados
set Num_Radiobases
1
;# Numero Radiobases
set opt(stop)
10
;# Tiempo de Simulacin
#
======================================================================
set ns_ [new Simulator]
$ns_ color 1 Red
$ns_ color 2 Green
$ns_ color 3 Blue
#
======================================================================
# Configuracin de la Jerarqua de Ruteo
$ns_ node-config -addressType hierarchical
AddrParams set domain_num_ 2
;# Dominios de Ruteo 2
;# -un dominio nodos cableados
;# -un dominio nodos inalambricos
lappend cluster_num 2 1
;# Clusters en cada dominiop (2 nodos cabl. y 1
nodos inalam)
AddrParams set cluster_num_ $cluster_num
lappend eilastlevel 1 1 4
;# Nodos por Cluster en cada Dominio
AddrParams set nodes_num_ $eilastlevel
#
======================================================================
# Definicin de Archivos donde se registran datos
set tracefd [open monografia-out.tr w]
set namtrace [open monografia-out.nam w]
$ns_ trace-all $tracefd
$ns_ namtrace-all-wireless $namtrace $opt(x) $opt(y)
# Archivos donde se cargan delta T entre paquetes recibidos por fuente

set deltaT0 [open DT0.tr w]

set deltaT1 [open DT1.tr w]
set deltaT2 [open DT2.tr w]
#
======================================================================
# Definicin de la Topologa
set topo [new Topography]
$topo load_flatgrid $opt(x) $opt(y)
create-god [expr $opt(nn) + $Num_Radiobases]
# Definicin de Nodos Cableados
set temp {0.0.0 0.1.0}
;
for {set i 0} {$i < $Num_Nodos_Alamb} {incr i} {
set W($i) [$ns_ node [lindex $temp $i]]
}
# Parametros de los Nodos Inalambricos (comunes a la Radiobase y a los nodos
"moviles")
$ns_ node-config -adhocRouting $opt(adhocRouting) \
-llType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-antType $opt(ant) \
-propType $opt(prop) \
-phyType $opt(netif) \
-channelType $opt(chan) \
-topoInstance $topo \
-wiredRouting ON \
-agentTrace ON \
-routerTrace OFF \
-macTrace OFF
# Creacin del Nodo Radiobase Gateway entre nodos cableados y nodos inalambricos
set temp {1.0.0 1.0.1 1.0.2 1.0.3}
set BS(0) [$ns_ node [lindex $temp 0]]
$BS(0) random-motion 0
;# Deshabilito movimiento
#Coordenadas Fijas de la Radiobase
$BS(0) set X_ 1.0
$BS(0) set Y_ 2.0
$BS(0) set Z_ 0.0
#Configuracin de Nodos Inalambricos
$ns_ node-config -wiredRouting OFF
# deshabilito capacidad d# Scripts
realizados a partir del archivo wireless2.tcl
#
======================================================================
# Definicin de Parametros
#
======================================================================
set opt(chan)
Channel/WirelessChannel ;# Tipo de canal
set opt(prop)
Propagation/TwoRayGround ;# Modelo de Propagacin
set opt(netif)
Phy/WirelessPhy
;# Tipo de Interfaz
set opt(mac)
Mac/802_11
;# MAC

set opt(ifq)
Queue/DropTail/PriQueue ;# Tipo de Cola
set opt(ll)
LL
;# Tipo de Capa de Enlace
set opt(ant)
Antenna/OmniAntenna
;# Tipo de Antena
set opt(ifqlen)
50
;# Cantidad maxima de paquetes
set opt(adhocRouting) DSDV
;# Protocolo de ruteo Vector Distancia
set opt(cp)
""
;# No se utiliza el archivo cp
set opt(sc)
""
set opt(x)
100
;# Ancho de la Topologa
set opt(y)
100
;# Alto de la Topologa
set opt(seed) 0.0
;#
set opt(nn)
3
;# Numero de nodos mobiles
set Num_Nodos_Alamb 2
;# Numero Nodos Cableados
set Num_Radiobases
1
;# Numero Radiobases
set opt(stop)
10
;# Tiempo de Simulacin
#
======================================================================
set ns_ [new Simulator]
$ns_ color 1 Red
$ns_ color 2 Green
$ns_ color 3 Blue
#
======================================================================
# Configuracin de la Jerarqua de Ruteo
$ns_ node-config -addressType hierarchical
AddrParams set domain_num_ 2
;# Dominios de Ruteo 2
;# -un dominio nodos cableados
;# -un dominio nodos inalambricos
lappend cluster_num 2 1
;# Clusters en cada dominiop (2 nodos cabl. y 1
nodos inalam)
AddrParams set cluster_num_ $cluster_num
lappend eilastlevel 1 1 4
;# Nodos por Cluster en cada Dominio
AddrParams set nodes_num_ $eilastlevel
#
======================================================================
# Definicin de Archivos donde se registran datos
set tracefd [open monografia-out.tr w]
set namtrace [open monografia-out.nam w]
$ns_ trace-all $tracefd
$ns_ namtrace-all-wireless $namtrace $opt(x) $opt(y)
# Archivos donde se cargan delta T entre paquetes recibidos por fuente
set deltaT0 [open DT0.tr w]
set deltaT1 [open DT1.tr w]
set deltaT2 [open DT2.tr w]
#
======================================================================
# Definicin de la Topologa
set topo [new Topography]
$topo load_flatgrid $opt(x) $opt(y)
create-god [expr $opt(nn) + $Num_Radiobases]

# Definicin de Nodos Cableados

set temp {0.0.0 0.1.0}
;
for {set i 0} {$i < $Num_Nodos_Alamb} {incr i} {
set W($i) [$ns_ node [lindex $temp $i]]
}
# Parametros de los Nodos Inalambricos (comunes a la Radiobase y a los nodos
"moviles")
$ns_ node-config -adhocRouting $opt(adhocRouting) \
-llType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-antType $opt(ant) \
-propType $opt(prop) \
-phyType $opt(netif) \
-channelType $opt(chan) \
-topoInstance $topo \
-wiredRouting ON \
-agentTrace ON \
-routerTrace OFF \
-macTrace OFF
# Creacin del Nodo Radiobase Gateway entre nodos cableados y nodos inalambricos
set temp {1.0.0 1.0.1 1.0.2 1.0.3}
set BS(0) [$ns_ node [lindex $temp 0]]
$BS(0) random-motion 0
;# Deshabilito movimiento
#Coordenadas Fijas de la Radiobase
$BS(0) set X_ 1.0
$BS(0) set Y_ 2.0
$BS(0) set Z_ 0.0
#Configuracin de Nodos Inalambricos
$ns_ node-config -wiredRouting OFF
paquetes (solo Radiobase)

# deshabilito capacidad de rutera

# todos los demas parametros se los traspaso

for {set j 0} {$j < $opt(nn)} {incr j} {
set node_($j) [ $ns_ node [lindex $temp \
[expr $j+1]] ]
$node_($j) base-station [AddrParams addr2id \
[$BS(0) node-addr]]
}
# Creacin de enlaces; Radiobase-W1 y W1-W2 (Red Cableada)
$ns_ duplex-link $W(0) $W(1) 128Kb 70ms DropTail
$ns_ duplex-link $W(1) $BS(0) 10Mb 10ms DropTail
$ns_ duplex-link-op $W(0) $W(1) orient right
$ns_ duplex-link-op $W(1) $BS(0) orient right
# Monitoreo de la cola entre W0 y W1
$ns_ duplex-link-op $W(0) $W(1) queuePos -150.2
# Monitoreo de la cola entre W1 y BS

$ns_ duplex-link-op $W(1) $BS(0) queuePos -50.2

#
======================================================================
# Creo Agentes de generacin y recepcin de trafico
# Creo un agente UDP y lo asocio al Nodo inalamrico Nodo0
set udp0 [new Agent/UDP]
$udp0 set class_ 1
$ns_ attach-agent $node_(0) $udp0
# Creo una fuente de Trafico de Trenes de paquetes y lo asocio a udp0 NAM=Rojo
# Esta fuente de trafico simula la utilizada para medir mediante trenes de paquetes
set cbr0 [new Application/Traffic/CBR_PP]
#cada tren es de 3 paquetes
$cbr0 set PBM_ 3
#cantidad total de bits por segundo
#a partir de este valor el NS-2 calcula cuantos trnes por segundo enviar
$cbr0 set rate_ 15Kb
#tamao en bytes de cada paquete
$cbr0 set packetSize_ 200
$cbr0 attach-agent $udp0
# Creo un agente UDP y lo asocio al Nodo inalamrico Nodo1
set udp1 [new Agent/UDP]
$udp1 set class_ 2
$ns_ attach-agent $node_(1) $udp1
# Creo una fuente de Trafico Constante CBR 50 Kbps y lo asocio a udp1 NAM=Verde
set cbr1 [new Application/Traffic/CBR]
$cbr1 set interval_ 0.032
$cbr1 set packetSize_ 200
$cbr1 attach-agent $udp1
# Creo un agente UDP y lo asocio al Nodo inalamrico Nodo2
set udp2 [new Agent/UDP]
$udp2 set class_ 3
$ns_ attach-agent $node_(2) $udp2
# Creo una fuente de Trafico Constante CBR 50 Kbps y lo asocio a udp2 NAM=Azul
set cbr2 [new Application/Traffic/CBR]
$cbr2 set interval_ 0.032
$cbr2 set packetSize_ 200
$cbr2 attach-agent $udp2
#Crea 3 agentes sinks necesarios para medir trafico y los asocia al nodo final W(0)
set sink0 [new Agent/LossMonitor]
set sink1 [new Agent/LossMonitor]
set sink2 [new Agent/LossMonitor]
$ns_ attach-agent $W(0) $sink0
$ns_ attach-agent $W(0) $sink1
$ns_ attach-agent $W(0) $sink2
#Conecto fuentes generadoras de trafico con agentes de recepcion finales
$ns_ connect $udp0 $sink0

$ns_ connect $udp1 $sink1

$ns_ connect $udp2 $sink2
#
======================================================================
# Defino un procedimiento que periodocamente que graba el Delta T entre paquetes
recibidos
# y se graban en los archivos deltaT0 deltaT1 deltaT2
proc record {} {
global sink0 sink1 sink2 paqant0 paqant1 paqant2 deltaT0 deltaT1 deltaT2
set ns_ [Simulator instance]
set timevar 0.001
set ultimopaq0 [$sink0 set lastPktTime_]
set ultimopaq1 [$sink1 set lastPktTime_]
set ultimopaq2 [$sink2 set lastPktTime_]
set now [$ns_ now]
if {$ultimopaq0 > $paqant0} {
puts $deltaT0 "$now [expr $ultimopaq0-$paqant0]"}
if {$ultimopaq1 > $paqant1} {
puts $deltaT1 "$now [expr $ultimopaq1-$paqant1]"}
if {$ultimopaq2 > $paqant2} {
puts $deltaT2 "$now [expr $ultimopaq2-$paqant2]"}
set paqant0 $ultimopaq0
set paqant1 $ultimopaq1
set paqant2 $ultimopaq2
$ns_ at [expr $now+$timevar] "record"
}
#
======================================================================
# Agendo eventos
$ns_ at 0.001 "set paqant0 0"
$ns_ at 0.001 "set paqant1 0"
$ns_ at 0.001 "set paqant2 0"
$ns_ at 0.01 "$cbr0 start"
$ns_ at 0.01 "$cbr1 start"
$ns_ at 0.01 "$cbr2 start"
$ns_ at 0.1 "record"
$ns_ at 10 "$cbr2 stop"
$ns_ at 10 "$cbr1 stop"
$ns_ at 10 "$cbr0 stop"
#
======================================================================
# Definicin de ubicacin "inicial" de nodos inalambricos en NAM
# Nodo 3 NAM
$node_(0) set X_ 20.0

$node_(0) set Y_ 22.0

$node_(0) set Z_ 0.0
$ns_ initial_node_pos $node_(0) 10
# Nodo 4 NAM
$node_(1) set X_ 25.0
$node_(1) set Y_ 2.0
$node_(1) set Z_ 0.0
$ns_ initial_node_pos $node_(1) 10
# Nodo 5 NAM
$node_(2) set X_ 20.0
$node_(2) set Y_ -18.0
$node_(2) set Z_ 0.0
$ns_ initial_node_pos $node_(2) 10
#
======================================================================
# Fin de simulacin
for {set i } {$i < $opt(nn) } {incr i} {
$ns_ at $opt(stop).0 "$node_($i) reset";
}
$ns_ at $opt(stop).0 "$BS(0) reset";
$ns_ at $opt(stop).0002 "puts \"Finaliza Simulacin\" ; $ns_ halt"
$ns_ at $opt(stop).0001 "stop"
proc stop {} {
global deltaT0 deltaT1 deltaT2 ns_ tracefd namtrace
close $tracefd
close $namtrace
close $deltaT0
close $deltaT1
close $deltaT2
exec xgraph DT0.tr -geometry 800x400 &
exec xgraph DT1.tr -geometry 800x400 &
exec xgraph DT2.tr -geometry 800x400 &
exec nam monografia-out.nam
}
#
======================================================================
# Comienzo de simulacion
puts "Comienza Simulacin"
$ns_ run
#
======================================================================e
rutera paquetes (solo Radiobase)
# todos los demas parametros se los traspaso
for {set j 0} {$j < $opt(nn)} {incr j} {
set node_($j) [ $ns_ node [lindex $temp \
[expr $j+1]] ]
$node_($j) base-station [AddrParams addr2id \
[$BS(0) node-addr]]
}
# Creacin de enlaces; Radiobase-W1 y W1-W2 (Red Cableada)

$ns_ duplex-link $W(0) $W(1) 128Kb 70ms DropTail

$ns_ duplex-link $W(1) $BS(0) 10Mb 10ms DropTail
$ns_ duplex-link-op $W(0) $W(1) orient right
$ns_ duplex-link-op $W(1) $BS(0) orient right
# Monitoreo de la cola entre W0 y W1
$ns_ duplex-link-op $W(0) $W(1) queuePos -150.2
# Monitoreo de la cola entre W1 y BS
$ns_ duplex-link-op $W(1) $BS(0) queuePos -50.2
#
======================================================================
# Creo Agentes de generacin y recepcin de trafico
# Creo un agente UDP y lo asocio al Nodo inalamrico Nodo0
set udp0 [new Agent/UDP]
$udp0 set class_ 1
$ns_ attach-agent $node_(0) $udp0
# Creo una fuente de Trafico de Trenes de paquetes y lo asocio a udp0 NAM=Rojo
# Esta fuente de trafico simula la utilizada para medir mediante trenes de paquetes
set cbr0 [new Application/Traffic/CBR_PP]
#cada tren es de 3 paquetes
$cbr0 set PBM_ 3
#cantidad total de bits por segundo
#a partir de este valor el NS-2 calcula cuantos trnes por segundo enviar
$cbr0 set rate_ 15Kb
#tamao en bytes de cada paquete
$cbr0 set packetSize_ 200
$cbr0 attach-agent $udp0
# Creo un agente UDP y lo asocio al Nodo inalamrico Nodo1
set udp1 [new Agent/UDP]
$udp1 set class_ 2
$ns_ attach-agent $node_(1) $udp1
# Creo una fuente de Trafico Constante CBR 50 Kbps y lo asocio a udp1 NAM=Verde
set cbr1 [new Application/Traffic/CBR]
$cbr1 set interval_ 0.032
$cbr1 set packetSize_ 200
$cbr1 attach-agent $udp1
# Creo un agente UDP y lo asocio al Nodo inalamrico Nodo2
set udp2 [new Agent/UDP]
$udp2 set class_ 3
$ns_ attach-agent $node_(2) $udp2
# Creo una fuente de Trafico Constante CBR 50 Kbps y lo asocio a udp2 NAM=Azul
set cbr2 [new Application/Traffic/CBR]
$cbr2 set interval_ 0.032
$cbr2 set packetSize_ 200
$cbr2 attach-agent $udp2
#Crea 3 agentes sinks necesarios para medir trafico y los asocia al nodo final W(0)

set sink0 [new Agent/LossMonitor]

set sink1 [new Agent/LossMonitor]
set sink2 [new Agent/LossMonitor]
$ns_ attach-agent $W(0) $sink0
$ns_ attach-agent $W(0) $sink1
$ns_ attach-agent $W(0) $sink2
#Conecto fuentes generadoras de trafico con agentes de recepcion finales
$ns_ connect $udp0 $sink0
$ns_ connect $udp1 $sink1
$ns_ connect $udp2 $sink2
#
======================================================================
# Defino un procedimiento que periodocamente que graba el Delta T entre paquetes
recibidos
# y se graban en los archivos deltaT0 deltaT1 deltaT2
proc record {} {
global sink0 sink1 sink2 paqant0 paqant1 paqant2 deltaT0 deltaT1 deltaT2
set ns_ [Simulator instance]
set timevar 0.001
set ultimopaq0 [$sink0 set lastPktTime_]
set ultimopaq1 [$sink1 set lastPktTime_]
set ultimopaq2 [$sink2 set lastPktTime_]
set now [$ns_ now]
if {$ultimopaq0 > $paqant0} {
puts $deltaT0 "$now [expr $ultimopaq0-$paqant0]"}
if {$ultimopaq1 > $paqant1} {
puts $deltaT1 "$now [expr $ultimopaq1-$paqant1]"}
if {$ultimopaq2 > $paqant2} {
puts $deltaT2 "$now [expr $ultimopaq2-$paqant2]"}
set paqant0 $ultimopaq0
set paqant1 $ultimopaq1
set paqant2 $ultimopaq2
$ns_ at [expr $now+$timevar] "record"
}
#
======================================================================
# Agendo eventos
$ns_ at 0.001 "set paqant0 0"
$ns_ at 0.001 "set paqant1 0"
$ns_ at 0.001 "set paqant2 0"
$ns_ at 0.01 "$cbr0 start"
$ns_ at 0.01 "$cbr1 start"
$ns_ at 0.01 "$cbr2 start"
$ns_ at 0.1 "record"

$ns_ at 10 "$cbr2 stop"

$ns_ at 10 "$cbr1 stop"
$ns_ at 10 "$cbr0 stop"
#
======================================================================
# Definicin de ubicacin "inicial" de nodos inalambricos en NAM
# Nodo 3 NAM
$node_(0) set X_ 20.0
$node_(0) set Y_ 22.0
$node_(0) set Z_ 0.0
$ns_ initial_node_pos $node_(0) 10
# Nodo 4 NAM
$node_(1) set X_ 25.0
$node_(1) set Y_ 2.0
$node_(1) set Z_ 0.0
$ns_ initial_node_pos $node_(1) 10
# Nodo 5 NAM
$node_(2) set X_ 20.0
$node_(2) set Y_ -18.0
$node_(2) set Z_ 0.0
$ns_ initial_node_pos $node_(2) 10
#
======================================================================
# Fin de simulacin
for {set i } {$i < $opt(nn) } {incr i} {
$ns_ at $opt(stop).0 "$node_($i) reset";
}
$ns_ at $opt(stop).0 "$BS(0) reset";
$ns_ at $opt(stop).0002 "puts \"Finaliza Simulacin\" ; $ns_ halt"
$ns_ at $opt(stop).0001 "stop"
proc stop {} {
global deltaT0 deltaT1 deltaT2 ns_ tracefd namtrace
close $tracefd
close $namtrace
close $deltaT0
close $deltaT1
close $deltaT2
exec xgraph DT0.tr -geometry 800x400 &
exec xgraph DT1.tr -geometry 800x400 &
exec xgraph DT2.tr -geometry 800x400 &
exec nam monografia-out.nam
}
#
======================================================================
# Comienzo de simulacion
puts "Comienza Simulacin"
$ns_ run
#
======================================================================