Estimacion BW

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 técnicas 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 tráfico de paquetes tipo FIFO.
En el siguiente trabajo se muestra que redes de banda ancha como las de cable módem
y redes inalámbricas basadas en el estándar 802.11 no cumplen con este modelo por varios
motivos:
• el camino cursado por los paquetes puede utilizar mecanismos de administración de
velocidad de trasmisión como “token bucket”,
• puede traficar paquetes de una forma diferente a una cola FIFO,
• puede soportar múltiples velocidades diferentes,
etc.
En el presente trabajo también se analiza como estas características impiden la

operación de varios métodos y herramientas de estimación de capacidad y ancho de banda
disponible y presenta una nueva técnica de estimación de ancho de banda disponible;
PROBEGAP, el cual tiene en cuenta estas dificultades.
Se evalúa dicha herramienta en enlaces Cable módems y 802.11a.
INTRODUCCIÓN
Se han desarrollado muchas técnicas 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 más pequeño
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 congestión 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
transmisión 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 tráfico 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 módem o inalámbricas
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 desviación 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
regulación de velocidad “token bucket” utilizada en la tecnología cable módem o
esquemas de múltiple velocidad dinámica 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 módem.
• Los enlaces de múltiples 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 características de las redes de banda ancha que presentan

cambios en las técnicas existentes de estimación de capacidad y ancho de
banda disponible.
2. Evalúa estos problemas a través 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 específicamente
las características de la banda ancha.
3. Se presenta una nueva técnica de estimación de ancho de banda llamada
ProbeGap la cual promete poder resolver algunas de estas dificultades. La idea
principal de dicha técnica es investigar la existencia de huecos (periodos
ociosos) en el enlace mediante el cálculo del retardo de las muestras en un
sentido (OWD: One Way Delay).
Métodos de medida
Metodos PRM (packet rate method):
Las herramientas basadas en este método 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 debería 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 recepción es menor que la de trasmisión 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 observación
de la velocidad de trasmisión en la cual sucede una transición entre estos dos
comportamientos.
En este trabajo se tomó la herramienta Pathload como representativa de este método.
Figura 1
Metodos PGM (packet gap method):
Herramientas basadas en este método como Spruce, Delphi e IGI envían pares de
paquetes de prueba de igual tamaño separados acorde al tiempo de transmisión 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 método.
Figura 2
Regulación del tráfico
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 través de él. Sin embargo, esta suposición no es valida
cuando se utiliza un plan de regulación de tráfico.
Típicamente, los ISPs dividen la subida al enlace de acceso físico en pequeñas ranuras
que reparten en lotes a sus clientes.
Por ejemplo, el ancho de banda total de una red de cable módem típica 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 típicamente un orden de magnitud más pequeño, en ambas
direcciones.
Para repartir el ancho de banda el ISP utiliza un plan de regulación de tráfico en su
equipo terminal. El mecanismo usado normalmente en las redes cable módem es el método
“token bucket” el cual especifica la velocidad de acceso media a la red en bits por segundo y el
tamaño del pico máximo en bytes.
Aunque la velocidad lograda por una transferencia prolongada está acotada por la
velocidad media, es posible enviar un flujo datos del tamaño del “token bucket a una velocidad
igual al ancho de banda del enlace.
Por lo tanto es necesario hacer una distinción entre el ancho de banda de enlace y el
máximo ancho de banda posible para una transferencia prolongada. Es posible que pares de
paquetes o pequeños trenes de paquetes pueden medir el ancho de banda total del enlace.
Esquema no-FIFO y contención
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 crítico el tamaño de los paquetes del “cross-traffic”.
Sin embargo en configuraciones de redes de banda ancha el modelo basado en enlaces
FIFO falla. En redes inalámbricas basadas en el estándar 802.11 las estaciones compiten por el
acceso al canal de una forma distribuida.
En el caso de una red cable-módem, el acceso a la red desde el usuario es administrado
por el CMTS quien periódicamente envía 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 podrían
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 estación 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 separación fija impide la
operación de las técnicas de estimación 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 estación. Por lo que el paquete de prueba no experimenta el retardo
proporcional al volumen total de “cross-traffic” existente en la red, produce una subestimación
del trafico cursado sobre la red y esto genera una subestimación del ancho de banda
disponible.
La situación es complicada por el hecho de que los esquemas donde los equipos
compiten por el acceso al medio se basan en tramas independientemente del tamaño de estas.
Al competir flujos con tamaños de paquetes diferentes tienden a compartir el ancho de banda
proporcionalmente al tamaño de los mismos.
Por lo tanto la estimación producida por la técnica de estimación de ancho de banda
disponible va a depender del tamaño relativo del tráfico de prueba y del cross-traffic.
Finalmente un control de acceso al medio competitivo típicamente 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 3
Enlaces multi-velocidades
Los enlaces pueden operar o variar entre diferentes velocidades. Por ejemplo el estándar
802.11b soporta adaptación de velocidad dinámica, es decir que un terminal puede cambiar su
velocidad entre 1, 2, 5.5 y 11 Mbps mediante el cambio de la modulación utilizada dependiendo
de la calidad del canal utilizado, la cual puede variar dinámicamente dependiendo de la
movilidad del usuario, cambios en el entorno, etc.
De la misma forma el estándar 802.11a soporta velocidades variables entre 6 y 54 Mbps.
Por lo tanto el ancho de banda total del enlace entre una estación inalámbrica y un “Access-
point” puede variar abruptamente.
Aún si la velocidad del enlace para cada estación no cambia frecuentemente, estaciones
diferentes en la misma región pueden estar operando a diferentes velocidades compartiendo el
mismo espectro inalámbrico. Por lo tanto el impacto que un volumen dado de cross-traffic a una
estación genera sobre el ancho de banda disponible de otra estación 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 sólo a 6 Mbps (esto puede deberse a la distancia a la que se encuentra del
Access-point).
Dado que el estándar 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 estimación del ancho de banda disponible en ambas técnicas PRM y
PGM.
Estas técnicas trabajan mejor en los casos en que el “cross-traffic” se modela como un
fluido (asumiendo tamaños de paquetes infinitesimales) es decir que los paquetes de cross-
traffic y los de prueba se entremezclan uniformemente .
Los picos grandes de cross-traffic complican la detección del crecimiento de velocidad
cuando la velocidad de prueba sobrepasa el ancho de banda disponible. Esto afecta mas a las
técnicas basadas en PRM como el Pathload.
Por otro lado la ausencia de burst (picos) complica a las técnicas 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 técnicas existentes en el siguiente punto se presenta
ProbeGap una nueva herramienta para la estimación del Ancho de Banda disponible que alivia
estos problemas.
La idea es estima la fracción de tiempo que el enlace está libre mediante el sondeo de
huecos en los períodos de enlace ocupado y luego al multiplicarla por la capacidad se obtiene
una estimación del Ancho de Banda disponible.
ProbeGap estima la fracción de tiempo libre reuniendo muestras de retardo del enlace en
un sentido OWD (One-Way delay).
El trasmisor envía series de paquetes de prueba espaciados según la distribución 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 – Caracterización de ProbeGAP

Como se muestra en la figura 6 la distribución 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 fracción de tiempo que el canal está libre.
El vértice 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 regresión lineal de todos los puntos dentro de 0.05 del
punto de interés a lo largo del eje CDF. Se toma 0.05 para ser lo suficientemente pequeño
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 relación mínima tiene que ser 2. Si no se logra
ubicar dicho punto se puede concluir que el canal está 100% ocupado.
Como una refinación 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 típicamente tiene un valor normalizado del OWD mucho menor que 100 microsegundos.
Aunque esta heurística 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 método mas robusto basado en la estimación de
parámetros 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 técnicas
PGM y PRM a los efectos de modelos no-fifo, contención por paquete y “cross-traffic”.
ProbeGap no es totalmente inmune a los efectos no-fifo dado que existe una pequeña
chance de que un paquete de prueba arribe durante un periodo ocioso entre sucesivos “cross-
traffic” y logre tomar el canal por lo tanto sufrirá un pequeño OWD.
Este problema se puede reducir haciendo que la herramienta ProbeGap envíe grupos de
paquetes de prueba y tomar el máximo 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
complicación, por ejemplo en enlaces con múltiples 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 estimación del ancho de banda disponible incluso en dichas configuraciones locales con un
enlace comprometido dominante son de interés.
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 interés.
Herramientas
Para estimación de capacidad, se utilizó Pathrate, la cual utiliza gran parte de la teoría
desarrollada hasta ahora sobre estimación de capacidad a partir de generación de pares de
paquetes y trenes de paquetes.
Para la estimación del ancho de banda disponible se utilizó Pathload (herramienta
basada en PRM) y Spruce (herramienta basada en PGM). También se utilizó la herramienta
propuesta en este trabajo ProbeGap para la estimación 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
distribución de Poisson a distintas velocidades y distintos tamaños de paquetes (la distribución
de Poisson para el espaciado entre paquetes asegura que el cross-traffic contenga mas picos
que un trafico CBR).
RESULTADOS EXPERIMENTALES
La evaluación por medio de un “token bucket” se hizo sobre una red de cable-módem
mientras que los experimentos restantes en 802.11.
Impacto de token bucket en cable-módem
Inicialmente se analiza el downlink del banco de pruebas de cable-módem. 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 estación (i.e., cable-módem) como tráfico de
prueba, por esto la manejo no-FIFO de las colas no fue problema en los experimentos.
Estimación de la capacidad del canal
Los autores corrieron Pathrate con varios niveles del cross-traffic variándolo de 0 a 6
Mbps. Cuando la tasa de cross-traffic era de 6 Mbps, Pathrate no pudo terminar debido a que
las pérdidas 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.. Básicamente, 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 estimación de Pathrate será correcta. Sin embargo esta
estimación no es muy usada debido a que esta tasa es inasequible de un modo sostenido, aún
en la ausencia de cross-traffic.
Estimación 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 razón para
esta sobre estimación es que Pathload para estas tasas usa paquetes de prueba de 300 bytes,
y como el tamaño 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 estimación mediante Spruce para diferentes
niveles de cross-traffic sobre un enlace de bajada en una red
cable-módem.
La diferencia de la estimación 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 tamaño de paquete sobre el “throughput”

(rendimiento). La capacidad nominal del canal nominal es 6Mbps para la
grafica de la izquierda y 54Mbps para la gráfica derecha. Cada columna
representa el promedio de 3 corridas.
Spruce: Necesita una estimación 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 razón es que dependiendo del estado del token bucket, los paquetes de prueba
pequeños pudieron pasar a la tasa supuesta aún en presencia de cross-traffic, obteniendo una
sobreestimación del ancho de banda.
Hacemos dos observaciones adicionales. En primer lugar, cuando la capacidad es
supuesta es de 26 Mbps, la estimación 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 congestión en este último caso causa que el 60-70% de los paquetes de
prueba de Spruce se pierdan, estimándose como si el cross-traffic fuera comparativamente
mayor. En segundo lugar, cuando la tasa de cross-traffic es de 3 Mbps, la estimación obtenida
asumiendo una capacidad de 6Mbps (4.5 Mbps) es considerablemente más grande que se
obtuvo asumiendo una capacidad de 26Mbps ( 2.5 Mbps ). La razón es que en este último caso
el aumento de la separación entre los paquetes de prueba de Spruce debida al cross-traffic son
mucho más altas en relación a la separación a la entrada.
Sumario: Los experimentos indican que la capacidad y el ancho de banda disponible
estimadas están comprometidas debido a la dicotomía entre el ancho de banda de enlace bruto
y el simbólico del token-bucket. El problema es particularmente agudo en el caso de un método
de PGM como Spruce, desde el momento en que no existe ninguna estimación de capacidad
correcta que se pueda hacer.
Impacto del tamaño de paquete en 802.11
Dado que la transmisión de paquetes con un control de acceso al medio basado en

contención como el estándar 802.11 involucra un “overhead” significativo (como el preámbulo y
el espaciamiento mínimo entre paquetes sucesivos), los autores midieron el impacto del
tamaños de los pequeños en el máximo throughput alcanzable inyectando en el sentido de
“subida” una ráfaga de paquetes consecutivos de varios tamaños. También se varió el número
de pares de nodos de 1 a 3. La figura 8 muestra los resultados cuando la velocidad de la tarjeta
inalámbrica fue configurada a 6 Mbps y 54 Mbps.
Cross-traffic total 0 3 4
Estimación 5.2 – 5.4 5.1 – 5.4 5.3 – 5.5
Figura 9 - muestra la estimación de la capacidad del canal utilizando

Pathrate bajo varias cargas. Capacidad nominal del canal 6 Mbps.
Cross-Traffic Estimación Medidas

Tamaño ProbeGap
Tasa Pathload Spruce
Paquete 300 1472 300 1472
300 2.9 – 2.9 3.7 2.4 3.4 2.5 3.7
1
1472 3–3 4.2 2.7 3.9 2.7 4.2
300 2.2 – 2.3 3.2 1.6 2.3 1.7 2.3
2
1472 2.2 – 2.3 3.5 2.0 2.9 2.0 3.3
300 2.3 – 2.3 3.8 0.8 1.1 0.4 0.6
3
1472 1.6 – 1.6 1.5 1.4 2.1 1.4 2.4
300 2.3 – 2.3 3.7 0.4 0.6 0.1 0.1
4
1472 0.9 – 0.9 1.2 0.7 1.1 0.7 1.1
Figura 10 - muestra la tasa sencilla: Estimación 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 tamaño de paquete pequeño, pero no dependa fuertemente en el
número 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” debería haber crecido con el número de pares.
Impacto del Control de Acceso al Medio basado en contienda del standard 802.11
Para los experimentos realizados en esta sección, todas las tarjetas de red inalámbricas
se configuraron para trabajar a 6 Mbps.
Estimación de la capacidad del canal
Los autores corrieron Pathrate entre las maquinas M1 y M2, mientras que las máquinas
M3-M6 se utilizaron para generar cross-traffic a varias velocidades y tamaños de paquetes.
En todas las corridas, Pathrate produjo una estimación consistente entre 5.1 y 5.5 Mbps.
Esta estimación es cercana al máximo valor de tráfico UDP que soporta el canal, como se ve en
la figura 8.
Para comprender porque los resultados de Pathrate no son afectados por el método 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 estándar 802.11's tiene una predisposición 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 contención es
pequeña 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 dispersión asintótica usualmente genera un
modo que incluye por lo menos parte del modo de baja velocidad.
Así, la herramienta siempre escoge el modo más alto, resultando en la estimación de
capacidad correcta.
Estimación de ancho de banda disponible
En este punto los autores utilizaron las siguientes herramientas de estimación de ancho
de banda disponible; Pathload, Spruce y ProbeGap.
Estas herramientas siempre se corrieron entre M1 y M2, mientras que se generó “cross-
traffic” entre M3 y M4.
La tasa del cross-traffic se varió entre 1 y 4 Mbps en pasos de 1 Mbps. Se utilizaron dos
tamaños 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 tamaño de paquete de 300
bytes y a 5.1 Mbps para un tamaño 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.
También, 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 tamaños de paquete, por razones discutidas mas adelante.
Los resultados se muestran en la figura 10.
Pathload: Según los autores bajo condiciones de carga baja, la estimación de Pathload
coincide bien con la medida del ancho de banda disponible para paquetes de 300 bytes , sin
tener en cuenta el tamaño 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 método 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 métodos 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 estimación 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 tamaño 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 tamaño 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
estimación es de solo 0.1 Mbps.
Esto se debe a que el método de contención es por paquete el cual resulta en un numero
pequeño de paquetes de 300 bytes de cross-traffic insertados entre los pares de paquetes de
prueba del Spruce (los cuales son de mayor tamaño).
ProbeGap: Como se explicó, ProbeGap estima la fracción 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 tamaño del paquete, los autores
tomaron el valor de la capacidad correspondiente al tamaño 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
tamaño de paquete dado se acercan mas a la medida de ancho de banda estimado para el
tamaño de paquete correspondiente.
Por otro lado, ProbeGap sobrestima el ancho de banda disponible para cuando el cross-
traffic es alto.
Esto se debe a que aun cuando el canal está saturado de cross-traffic existe una
pequeña 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 pequeño que ProbeGap toma equivocadamente como un
canal ocioso. Este efecto puede verse en la figura 11, donde aún con 4 Mbps cross-traffic, casi
10-20% de los paquete de prueba llegan a su término produciendo un pequeño aumentando
pequeño 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 Estimación
Tasa Tamaño Paquete
0 - 31.3 – 33.3
300 23.8 – 27.8
2
1472 24.3 – 27.66
300 28.8 – 31.2
4
1472 26.5 – 32.5
Figura 12 - muestra la estimación de la capacidad del canal mediante Pathrate

bajo varios valores de carga.
Figura 13
Impacto del manejo de múltiples velocidades en el estándar 802.11
En esta sección, se presentan resultados cuantitativos que muestran el impacto sobre las
estimaciones (de todas las herramientas) que produce el manejo de múltiples velocidades en
entornos 802.11.
La configuración utilizada es la siguiente:

• 2 maquinas (M1 y M2) configuradas a 54 Mbps (todas las herramientas de
estimación corrieron sobre estas dos maquinas)
• 2 maquinas configuradas a 6 Mbps (todo el cross-traffic se genero entre estas
dos maquinas)
Estimación de la capacidad de canal
Las estimaciones de capacidad producidas por Pathrate se muestran en figura 12. Se ve

que la estimación de Pathrate es consistente con la capacidad del canal.
Estimación del ancho de banda disponible
Se realizaron ensayos con el mismo conjunto de parámetros 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 estimación 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 tamaño de paquete fue de 300
bytes Pathload sobreestimo significativamente el ancho de banda disponible.
Cross-Traffic Estimación Medidas

Tamaño ProbeGap
Tasa Pathload Spruce
Paquete 300 1472 300 1472
300 5.7 – 5.7 12 4.7 13.1 5.1 13.9
2
1472 8.6 – 10.1 25.7 6.1 17.0 6.5 18
300 2.6 – 2.9 0 0.8 2.3 0.3 0.3
4
1472 2.6 – 2.7 20.9 2.6 7.3 2.7 7.5
Figura 14 - analiza el comportamiento en entornos con múltiples

velocidades: Estimación del ancho de banda disponible bajo
diferentes niveles de carga.
Figura 15 - muestra una secuencia de OWD (One Way Delay) para una
ráfaga 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.
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): conexión a la radiobase wireless 802.11
- Nodos 3, 4 y 5 nodos inalambricos
En la siguiente figura se muestra la topología creada:
Sobre dicha topología se crearon tres fuentes generadoras de trafico constante CBR sobre UDP
de tamaño 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 tamaño
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 tamaño 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

• conexión a la radiobase a 10 Mbps y 2 ms de retardo
• se utilizó solo un CBR con tamaño 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 128Kbps

Tamaño de paquete 200 bytes
Cross Traffic 0
Tiempo de Simulación 100 segundos
Tiempo de rutina
Record 1 mseg
Tiempo entre tiempo entre paquetes

kbps inyectados paq/seg paquetes (recibido)
10 6.25 160ms 155ms
90 56.25 17,777 17.0
100 62.5 16 15.5
110 68.75 14,5454 14
120 75 13,3 13.7
130 81,25 12,31 13,7
140 87,5 11,43 13,7
150 93,75 10,67 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 estimación 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 utilizó solo un CBR_PP de tres paquetes con tamaño 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..
los paquetes del tren y entre el ultimo y el primer paquete del tren siguiente.
Tabla:

Tamaño de (en un canal de 128 Kbps 31,25 ms
paquete 500 bytes en TX)
Tren 3 paquetes
Cross Traffic 0
Tiempo de
Simulación 1 seg
Tiempo de rutina
Record 1 mseg
Kbps inyectados paq/seg medidas

tiempo entre paquetes del tiempo entre ultimo y paq/seg
tren primero RX
ms ms
90 22,5 32,5 68,1 22,54
100 25 32,5 54,84 25,03
110 27,5 32,5 43,9 27,55
120 30 32,5 34,83 30,05
130 32,5 32,5 32,5 30,77
140 35 32,5 32,5 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 bufferear en el enlace de menor ancho de banda.
Cabe aclarar que el tiempo entre paquetes del tren es siempre 32,5 ms ya que es el valor de
trasmitir un paquete de 520 bytes por un enlace de 128 Kbps (520 bytes =500payload + 20
bytes overhead).
En lo siguiente se muestra los graficos obtenidos en las simulacions:

Vista de la simulación:
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
estimación del AdeB disponible

• se utilizó un segundo CBR con tamaño de paquete 200 bytes y tiempo entre
paquetes de 25 ms generando un bit rate de 64 Kbps.
• se utilizó un CBR con tamaño 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).
paquetes en el destino a partir de la grafica del .
Datos obtenidos:

Tamaño de paquete 200 bytes
Cross Traffic 1 fuente 64 Kbps 1 paq 200 bytes cada 25 ms
Tiempo de Simulación 100 segundos
Tiempo de rutina
Record 1 mseg
Tiempo entre tiempo entre paquetes

kbps inyectados paq/seg paquetes (recibido)
ms Ms
10 6.25 160 155 +/- 10%
20 12.5 80 80 +/- 10%
30 18.75 53.3 55 +/- 15 %
40 25 40 37 +/- 20%
50 31.25 32 34 +/- 20%
60 37.5 26.7 28 *+/- 40%
70 43.75 29 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 imágenes de las simulaciones:
Simulación para el caso de paquetes

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

gerando a un CBR de 70Kbps (verde) en
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
64 Kbps (cuello de botella de 128 Kbps).

generando un CBR de 30 Kbps en



# Scripts realizados a partir del archivo wireless2.tcl
#
======================================================================
# Definición de Parametros
#
======================================================================
set opt(chan) Channel/WirelessChannel ;# Tipo de canal
set opt(prop) Propagation/TwoRayGround ;# Modelo de Propagación
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 Topología
set opt(y) 100 ;# Alto de la Topología
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 Simulación
#
======================================================================
set ns_ [new Simulator]
$ns_ color 1 Red

$ns_ color 2 Green
$ns_ color 3 Blue
#
======================================================================
# Configuración de la Jerarquía 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
#
======================================================================
# Definición 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]
#
======================================================================
# Definición de la Topología
set topo [new Topography]
$topo load_flatgrid $opt(x) $opt(y)
create-god [expr $opt(nn) + $Num_Radiobases]
# Definición 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
# Creación 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
#Configuración de Nodos Inalambricos

$ns_ node-config -wiredRouting OFF # deshabilito capacidad d# Scripts
realizados a partir del archivo wireless2.tcl
#
======================================================================
# Definición de Parametros
#
======================================================================
set opt(chan) Channel/WirelessChannel ;# Tipo de canal
set opt(prop) Propagation/TwoRayGround ;# Modelo de Propagación
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 Topología
set opt(y) 100 ;# Alto de la Topología
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 Simulación
#
======================================================================
set ns_ [new Simulator]
$ns_ color 1 Red

$ns_ color 2 Green
$ns_ color 3 Blue
#
======================================================================
# Configuración de la Jerarquía 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
#
======================================================================
# Definición 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

#
======================================================================
# Definición de la Topología
set topo [new Topography]
$topo load_flatgrid $opt(x) $opt(y)
create-god [expr $opt(nn) + $Num_Radiobases]
# Definición 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
# Creación 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
#Configuración de Nodos Inalambricos

$ns_ node-config -wiredRouting OFF # deshabilito capacidad de 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]]
}
# Creación 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 generación y recepción 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
#tamaño en bytes de cada paquete
$cbr0 set packetSize_ 200
$cbr0 attach-agent $udp0

$udp1 set class_ 2
# 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

$udp2 set class_ 3
# Creo una fuente de Trafico Constante CBR 50 Kbps y lo asocio a udp2 NAM=Azul
#Crea 3 agentes sinks necesarios para medir trafico y los asocia al nodo final W(0)
set sink0 [new Agent/LossMonitor]
$ns_ attach-agent $W(0) $sink0

#Conecto fuentes generadoras de trafico con agentes de recepcion finales

$ns_ connect $udp0 $sink0
#
======================================================================
# 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 now [$ns_ now]
if {$ultimopaq0 > $paqant0} {

puts $deltaT0 "$now [expr $ultimopaq0-$paqant0]"}
set paqant0 $ultimopaq0

$ns_ at [expr $now+$timevar] "record"

}
#
======================================================================
# Agendo eventos
$ns_ at 0.001 "set paqant0 0"

$ns_ at 0.01 "$cbr0 start"
$ns_ at 0.1 "record"
$ns_ at 10 "$cbr2 stop"

#
======================================================================
# Definición de ubicación "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
# Nodo 5 NAM
$node_(2) set X_ 20.0
$node_(2) set Y_ -18.0
#
======================================================================
# Fin de simulación
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 Simulación\" ; $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 nam monografia-out.nam
}
#
======================================================================
# Comienzo de simulacion
puts "Comienza Simulación"
$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]]
}
# Creación 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 generación y recepción de trafico

$udp0 set class_ 1
# 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
#tamaño en bytes de cada paquete

$udp1 set class_ 2
# Creo una fuente de Trafico Constante CBR 50 Kbps y lo asocio a udp1 NAM=Verde

$udp2 set class_ 3
# Creo una fuente de Trafico Constante CBR 50 Kbps y lo asocio a udp2 NAM=Azul
#Crea 3 agentes sinks necesarios para medir trafico y los asocia al nodo final W(0)

#Conecto fuentes generadoras de trafico con agentes de recepcion finales

#
======================================================================
# 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 now [$ns_ now]


$ns_ at [expr $now+$timevar] "record"

}
#
======================================================================
# Agendo eventos

$ns_ at 0.1 "record"

#
======================================================================
# Definición de ubicación "inicial" de nodos inalambricos en NAM
# Nodo 3 NAM
$node_(0) set X_ 20.0
$node_(0) set Y_ 22.0
# Nodo 4 NAM
$node_(1) set X_ 25.0
$node_(1) set Y_ 2.0
# Nodo 5 NAM
$node_(2) set X_ 20.0
$node_(2) set Y_ -18.0
#
======================================================================
# Fin de simulación
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 Simulación\" ; $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 nam monografia-out.nam
}
#
======================================================================
# Comienzo de simulacion
puts "Comienza Simulación"
$ns_ run
#
======================================================================

Estimacion BW

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Estimacion BW

Uploaded by

Copyright:

Available Formats

Estimaciones del Ancho de Banda en redes

“Bandwidth Estimation in Broadband Access Network”

En el presente trabajo también se analiza como estas características impiden la

Se han desarrollado muchas técnicas para estimar la capacidad y ancho de banda

En el presente trabajo se muestra que muchas de las suposiciones utilizadas en el

Existen varias razones por las cuales el “modelo tradicional” falla:

Este trabajo realiza tres contribuciones:

1. Identifica las características de las redes de banda ancha que presentan

Metodos PRM (packet rate method):

Metodos PGM (packet gap method):

Regulación del tráfico

Esquema no-FIFO y contención

Finalmente un control de acceso al medio competitivo típicamente resulta en una perdida

Figura 6 – Caracterización de ProbeGAP

La prueba realizada con la herramienta ProbeGap consistió en 200 paquetes de 20 bytes

Impacto de token bucket en cable-módem

Inicialmente se analiza el downlink del banco de pruebas de cable-módem. La tasa bruta

Estimación de la capacidad del canal

Estimación del ancho de banda disponible

Pathload: Como se muestra en la figura 4 , Pathload tiende a sobreestimar el ancho de

La diferencia de la estimación depende de la capacidad asumida por Spruce; el ancho de

Figura 8 - muestra el impacto del tamaño de paquete sobre el “throughput”

Spruce: Necesita una estimación de la capacidad de enlace como la entrada. No queda

Impacto del tamaño de paquete en 802.11

Dado que la transmisión de paquetes con un control de acceso al medio basado en

Figura 9 - muestra la estimación de la capacidad del canal utilizando

Cross-Traffic Estimación Medidas

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

Estimación de la capacidad del canal

Estimación de ancho de banda disponible

Spruce: Las estimaciones de Spruce se aproximan a la medida del ancho de banda

ProbeGap: Como se explicó, ProbeGap estima la fracción de tiempo en la que el canal

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

Figura 12 - muestra la estimación de la capacidad del canal mediante Pathrate

Impacto del manejo de múltiples velocidades en el estándar 802.11

La configuración utilizada es la siguiente:

Estimación de la capacidad de canal

Las estimaciones de capacidad producidas por Pathrate se muestran en figura 12. Se ve

Estimación del ancho de banda disponible

Se realizaron ensayos con el mismo conjunto de parámetros como en el caso de una

Cross-Traffic Estimación Medidas

Figura 14 - analiza el comportamiento en entornos con múltiples

Para las simulaciones se creo la siguiente topologia en el archivo monografia.tcp el cual se

- Enlace entre los nodos W0 y W1: enlace “cuello de Botella”

En la siguiente figura se muestra la topología creada:

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

Cuello de botella 128Kbps

Tiempo entre tiempo entre paquetes

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

Cuello de botella 128Kbps

Kbps inyectados paq/seg medidas

En lo siguiente se muestra los graficos obtenidos en las simulacions:

Vista del resultado de los tiempos entre

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

Cuello de botella 128Kbps

Tiempo entre tiempo entre paquetes

En las siguientes figuras se muestran algunas imágenes de las simulaciones:

Simulación para el caso de paquetes

Simulación para el caso de paquetes

Grafico del deltaT entre paquetes recibidos

Grafico del deltaT entre paquetes recibidos

Grafico del deltaT entre paquetes recibidos

Grafico del deltaT entre paquetes recibidos