Estimaciones del Ancho de Banda en redes de Banda Ancha

Texto completo

(1)

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 Micr

osoft Research

Gabriel Firme

Ing. Mateo Ruetalo

(2)

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.

(3)

• 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

(4)

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

(5)

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

(6)

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.

(7)

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

(8)

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.

(9)

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.

(10)

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.

(11)

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

Tasa Tamaño

Paquete Pathload Spruce ProbeGap

300 1472 300 1472

1 300 2.9 – 2.9 3.7 2.4 3.4 2.5 3.7

1472 3 – 3 4.2 2.7 3.9 2.7 4.2

2 300 2.2 – 2.3 3.2 1.6 2.3 1.7 2.3

1472 2.2 – 2.3 3.5 2.0 2.9 2.0 3.3

3 300 2.3 – 2.3 3.8 0.8 1.1 0.4 0.6

1472 1.6 – 1.6 1.5 1.4 2.1 1.4 2.4

4 300 2.3 – 2.3 3.7 0.4 0.6 0.1 0.1

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.

(12)

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

(13)

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.

(14)

Cross-Traffic Estimación Tasa Tamaño Paquete

0 - 31.3 – 33.3

2 300 23.8 – 27.8

1472 24.3 – 27.66

4 300 28.8 – 31.2

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

(15)

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

Tasa Tamaño

Paquete Pathload Spruce ProbeGap

300 1472 300 1472

2 300 5.7 – 5.7 12 4.7 13.1 5.1 13.9

1472 8.6 – 10.1 25.7 6.1 17.0 6.5 18

4 300 2.6 – 2.9 0 0.8 2.3 0.3 0.3

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.

(16)

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)

(17)

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

kbps inyectados paq/seg

Tiempo entre paquetes

tiempo entre 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):

(18)

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_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..

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 128Kbps

Tamaño de

paquete 500 bytes

(en un canal de 128 Kbps 31,25 ms 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 tren

tiempo entre ultimo y primero

paq/seg 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:

(19)

Vista de la simulación:

V

ista 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 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ó 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).

Dichos resultados se grafican y se obtiene “aproximadamente” el valor medio del retardo entre paquetes en el destino a partir de la grafica del .

(20)

Datos obtenidos:

Cuello de botella 128Kbps

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

kbps inyectados paq/seg

Tiempo entre paquetes

tiempo entre 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.

E

n 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 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:

(21)

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).

(22)

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).

(23)

# 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

(24)

set deltaT0 [open DT0.tr w]

set deltaT1 [open DT1.tr w]

set deltaT2 [open DT2.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

(25)

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]

set deltaT1 [open DT1.tr w]

set deltaT2 [open DT2.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]

(26)

# 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

(27)

$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

# 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

(28)

$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"

#

======================================================================

# Definición de ubicación "inicial" de nodos inalambricos en NAM

# Nodo 3 NAM

$node_(0) set X_ 20.0

(29)

$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 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 xgraph DT1.tr -geometry 800x400 &

exec xgraph DT2.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)

(30)

$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

# 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)

(31)

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"

(32)

$ns_ at 10 "$cbr2 stop"

$ns_ at 10 "$cbr1 stop"

$ns_ at 10 "$cbr0 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

$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 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 xgraph DT1.tr -geometry 800x400 &

exec xgraph DT2.tr -geometry 800x400 &

exec nam monografia-out.nam }

#

======================================================================

# Comienzo de simulacion puts "Comienza Simulación"

$ns_ run

#

======================================================================

Figure

Actualización...

Referencias

Actualización...

Related subjects :