Simulación por eventos discretos de una red WLAN utilizando OMNET++

Texto completo

(1)SIMULACION POR EVENTOS DISCRETOS DE UNA RED WLAN UTILIZANDO OMNET++. DIEGO ALEJANDRO RIVERA POLANCO. UNIVERSIDAD DE LOS ANDES DEPARTAMENTO DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA BOGOTÁ, AGOSTO DE 2004.

(2) IEL2-I-04-40. SIMULACION POR EVENTOS DISCRETOS DE UNA RED WLAN UTILIZANDO OMNET++. DIEGO ALEJANDRO RIVERA POLANCO. Trabajo de Grado para optar al título de Ingeniero Electrónico. ASESOR ROBERTO BUSTAMANTE MILLER. UNIVERSIDAD DE LOS ANDES DEPARTAMENTO DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA BOGOTÁ, AGOSTO DE 2004. 2.

(3) IEL2-I-04-40. RESUMEN ........................................................................................................................................ 6 INTRODUCCION…………………………………………………………………………..................................7 1 DESCRIPCION DEL ESTANDAR IEEE 802.11. ESPECIFICACION DE LA CAPA DE ACCESO AL MEDIO PARA LAS REDES LAN INALAMBRICAS. ........................................................................... 8 1.1 ARQUITECTURA DE UNA RED DE AREA LOCAL INALAMBRICA (WLAN). ................. 9 1.2 FORMATO DE LA TRAMA............................................................................................ 10 1.2.1 Formato general de la trama .............................................................................. 10 1.3 DESCRIPCION FUNCIONAL DE LA CAPA MAC.......................................................... 14 1.3.1 Distributed coordination function (DCF)............................................................ 14 1.3.1.1 Detección de portadora ................................................................................. 15 1.3.1.2 Generación de ventana aleatoria de tiempo backoff time ............................. 15 1.3.1.3 Mecanismo rts/cts.......................................................................................... 17 1.3.2 Point coordination function (PCF)...................................................................... 18 2 DISEÑO DEL SIMULADOR.................................................................................................... 20 2.1 INTRODUCCION A LA HERRAMIENTA OMNET++[2] .................................................. 20 2.2 MODELAMIENTO DE LA SOLUCION EN LENGUAJE UML.......................................... 21 2.2.1 Diagrama de casos de uso ................................................................................. 22 2.2.2 Diagrama conceptual de estructura estatica ..................................................... 25 2.2.3 Diagrama de actividades .................................................................................... 26 3 EL MODELO DE SIMULACION.............................................................................................. 28 3.1 ARQUITECTURA DEL MODELO .................................................................................. 28 3.2 FUNCIONAMIENTO Y CONSIDERACIONES DEL MODELO DE SIMULACION ............ 30 3.3 MODELO DE DISPERSION DEL CANAL...................................................................... 31 3.4 MODELO DE DISPERSION IMPLEMENTADO .............................................................. 32 4 PRUEBAS REALIZADAS EN EL SIMULADOR ...................................................................... 33 4.1 VALOR OPTIMO DEL RTS THRESHOLD ..................................................................... 34 4.2 EFECTO DE LA LONGITUD DE LA TRAMA SOBRE EL RENDIMIENTO DE LA RED... 35 4.3 EFECTO DEL BERbad SOBRE EL RENDIMIENTO DE LA RED................................... 36 5 CONCLUSIONES................................................................................................................... 37 BIBLIOGRAFIA………………………………………………………………………...............................……38 A. ANEXO: CODIGO DE IMPLEMENTACIÓN DEL SIMULADOR EN OMNET++ UTILIZANDO EL LENGUAJE NED……………………………………………...........................................................………..39 B. ANEXO: CODIGO DE IMPLEMENTACION DEL SIMULADOR EN C++……..............................….42. 3.

(4) IEL2-I-04-40. FIGURAS Y TABLAS. Fig. 1.1 Fig. 1.2 Fig. 1.3 Fig. 1.4 Fig. 1.5 Fig. 1.6 Fig. 2.1 Fig. 2.2 Fig. 2.3 Fig. 2.4 Fig. 3.1 Fig. 3.2 Fig. 4.1 Fig. 4.2 Fig. 4.3. Familia de estándares para redes de área local (LAN) y metropolitana (MAN). Tomada de ANSI/IEEE 802.11, 1999 Edition P iii.....................................................................................8 Arquitectura de la red...............................................................................................................9 Formato general de la trama. Tomado de ANSI/IEEE 802.11, 1999 Edition P 75 ...............11 Secuencia de actualización del vector NAV..........................................................................15 Diagrama del algoritmo de Back Off.....................................................................................16 Secuencia de transmisión en modo DCF...............................................................................18 Diagrama de casos de uso......................................................................................................22 Diagrama conceptual de estructura estática...........................................................................25 Diagrama de actividades (Swimlane).....................................................................................26 Diagrama de actividades (Swimlane).....................................................................................27 Arquitectura de la red en el simulador...................................................................................29 Modelo de dispersión del canal..............................................................................................32 Resultados de simulación para diferentes valores de RTS_threshold ...................................34 Resultados de simulación para diferentes valores de longitud de la trama ...........................35 Resultados de simulación para diferentes valores de BER_Bad............................................36. Tabla 4.1. Valores típicos de simulación.................................................................................................33. 4.

(5) IEL2-I-04-40. AGRADECIMIENTOS. Gracias a todos aquellos que de una u otra manera hicieron posible que alcanzara esta meta. Un agradecimiento especial a Roberto Bustamante por su apoyo, sus consejos pero sobre todo su paciencia durante el desarrollo de este trabajo de grado. A mi familia por el apoyo incondicional y por supuesto a Dios.. 5.

(6) IEL2-I-04-40. RESUMEN. Este documento presenta el diseño de una herramienta de simulación para una red LAN inalámbrica que fue implementada utilizando el software OMNET++ y desarrollada en lenguaje de programación C++. En el capítulo 1 se presenta una breve descripción del protocolo IEEE 802.11 dando especial énfasis a los apartes más importantes que se utilizarán en la implementación del simulador, más adelante, en el capítulo 2 el autor presenta todo el proceso de diseño del prototipo apoyándose en el lenguaje de descripción UML. También se presenta una breve introducción a la herramienta de simulación por eventos discretos OMNET++ en el capítulo 3 mostrando el resultado final del simulador. Ya en el capítulo 4 se desarrollan pruebas específicas de evaluación de la red usando el simulador implementado en el cual se tuvo en cuenta un modelo de desvanecimiento del canal para hacer que la simulación fuera más real. Al final se presentan los resultados obtenidos en las pruebas para luego mostrar las conclusiones alcanzadas en el capítulo final.. 6.

(7) IEL2-I-04-40. INTRODUCCION. Este proyecto de grado tiene como objetivo implementar un simulador de la capa de acceso al medio para una red inalámbrica de área local (WLAN) de acuerdo a lo especificado en el estándar IEEE 802.11 cuando opera en el modo asincrónico o DCF, con el fin de establecer su rendimiento en términos de capacidad real ofrecida a los usuarios medida en Mega-bits por segundo (Mbps). El simulador fue implementado utilizando el software OMNET++ y desarrollado usando el lenguaje de programación C++. El OMNET++ es una herramienta que se basa en la teoría de la simulación por eventos discretos y en la programación orientada a objetos para realizar simulaciones sobre diversas aplicaciones entre las que sobresalen las redes de comunicaciones. En ese sentido y en parte gracias a la flexibilidad que ofrece, la herramienta se ha hecho bastante popular sobre todo en el medio científico. Por otra parte, la teoría de la simulación por eventos discretos ha sido ampliamente utilizada para estudiar redes de computadores debido a la facilidad que ofrece en el modelamiento de entidades como esta, simplificando considerablemente su estudio y arrojando resultados satisfactorios. En general, un modelo utilizando la teoría de los eventos discretos es más funcional que un modelo analítico. Por último, este proyecto de grado pretende ofrecer un pequeño aporte a toda la teoría que se ha desarrollado alrededor de la tecnología inalámbrica y que en estos tiempos ha tomado tanta fuerza, para lograr que en el mediano plazo ésta sea de uso masivo brindándonos todas las facilidades y beneficios disponibles.. 7.

(8) IEL2-I-04-40. 1. DESCRIPCION DEL ESTANDAR IEEE 802.11. ESPECIFICACION DE LA CAPA DE ACCESO AL MEDIO PARA LAS REDES LAN INALAMBRICAS.. El estándar IEEE 802.11 forma parte de la familia de estándares para redes de área local (LAN) y metropolitana (MAN) [1] tal como se muestra en la figura 1.1 (tomada del ANSI/IEEE Std 802.11, 1999 Edition, p iii).. Figura 1.1. El estándar aborda específicamente las dos primeras capas del sistema de referencia OSI, definiendo el protocolo que deben utilizar los equipos que pertenezcan a una red de área local (LAN) que se comuniquen a través de cualquier medio inalámbrico (aire, ondas de radio o puertos infrarrojos) utilizando el mecanismo de Acceso Múltiple con Detección de Portadora y Omisión de Colisiones (Carrier Sense Multiple Access with Colission Avoidance CSMA/CA). El control de acceso al medio soporta dos tipos de operación, el primero utiliza un equipo principal o Access Point (AP) en el cual se centraliza el control del tráfico de la red (redes estructuradas), mientras que el segundo permite comunicación directa entre dos estaciones independientes (redes ad hoc). El protocolo incluye los servicios de asociación, autentificación, encripción y ahorro de energía utilizados por las estaciones para acoplarse a la red aprovechando los beneficios que les brinda su movilidad.. 8.

(9) IEL2-I-04-40. 1.1. ARQUITECTURA DE UNA RED DE AREA LOCAL INALAMBRICA (WLAN).. El bloque fundamental de una red WLAN es llamado Basic Service Set (BSS) y se conforma como mínimo por dos estaciones que tienen la capacidad de mantener una comunicación entre si. El BSS puede entenderse como el área de cobertura sobre la cual funciona una red WLAN, por lo tanto si una estación abandona el BSS al cual pertenece, no podrá enviar ni recibir información de ningún otro equipo. Sin embargo, dadas las restricciones impuestas por el medio físico (PHY), una red WLAN no podría extenderse a través de un área relativamente grande si su funcionamiento estuviera restringido por el alcance de un simple BSS, razón por la cual aparece una nueva entidad llamada Sistema de Distribución (DS), el cual permite interconectar varios BSS haciendo que el tamaño de una red crezca tanto como sea necesario. En cada BSS el respectivo AP es el equipo encargado de realizar la interfase entre el sistema de distribución y el medio inalámbrico sobre el que trabaja la red. El estándar no hace ninguna referencia con respecto a las características físicas que debe seguir el medio del sistema de distribución, por lo tanto el diseño de la red WLAN es independiente de éste. Lógicamente el AP deberá integrar los dos medios, ya que va a servir de puente entre ellos. Finalmente, un último elemento que aparece para completar la arquitectura de una red WLAN es llamado Portal, y sirve para integrar una red LAN tradicional 802.x con el sistema de distribución de las redes 802.11. Todo el tráfico proveniente de una red externa alámbrica debe ingresar a la red WLAN a través del portal. En la figura 1.2 se describe la arquitectura de una red WLAN incluyendo todas las entidades mencionadas anteriormente.. 9.

(10) IEL2-I-04-40. BSS 1 AP STA 1. DS. STA 2. BSS 2. STA 3. AP. STA 1 STA 2. STA 3. 802.x. PORTAL. Figura 1-2. 1.2. FORMATO DE LA TRAMA. Todas las tramas sugeridas por el estándar IEEE 802.11 para una red WLAN tienen 3 campos básicos. El primero corresponde al encabezado MAC, en donde se encuentran campos de control tales como duración, direcciones e información de secuencia. El segundo campo corresponde al cuerpo de la trama, y contiene información específica de acuerdo al tipo de mensaje. Finalmente, en el último campo se encuentra el código de verificación de trama. Para este campo se usa el algoritmo de código de redundancia cíclica de 32-bits (CRC).. 1.2.1 Formato general de la trama En la figura 1.3 (tomada del ANSI/IEEE Std 802.11, 1999 Edition, p 75) se muestra el formato general de la trama, y a continuación se presenta una breve descripción de sus campos. Algunos de ellos no aplican para todos los tipos de mensaje.. 10.

(11) IEL2-I-04-40. Figura 1-3. Campo de control de trama: El campo de control de trama se encarga de transportar información propia de la misma. Está compuesto por 11 sub-campos y es obligatorio para todo tipo de tramas. A continuación se presentan los sub-campos más significativos de este campo.. o Versión: Es un campo de 2 bits de longitud. Actualmente su valor es 0 y todos los demás valores están reservados.. o Tipo y Sub-Tipo: Son campos de 2 y 4 bits de longitud respectivamente. Identifican cual es la función de la trama. Existen tres tipos de trama: Control, Manejo y Datos. Cada uno de estos tipos tiene varios subtipos de trama. En la tabla 1 se relacionan todas las combinaciones posibles.. o Banderas: El estándar incluye las siguientes banderas en el campo de control de trama:. o Más Fragmentos: Su valor es puesto en uno en las tramas de datos o manejo cuando existen más fragmentos de ésta.. o Retransmisión: Toma el valor de uno cuando la trama corresponde a una retransmisión, si no entonces su valor es cero.. o A DS: Indica si el mensaje se dirige al sistema de distribución. o De DS: Indica si el mensaje proviene del sistema de distribución. o Manejo de Energía: Indica el estado en que quedará la estación después de la transmisión actual. Un uno en ese campo indica que la estación entrará en el modo de ahorro de energía. Un valor de cero indica que la estación sigue despierta.. o Más Datos: Indica si existen mas tramas pendientes para ser enviadas a la estación destino.. 11.

(12) IEL2-I-04-40. o Campo WEP: Indica si se utiliza el sistema de encripción establecido en el estándar para transmitir el mensaje.. o Campo Orden: Indica si el modo de transmisión en orden estricto está activo. Campo de Duración: Este campo es usado por las estaciones para transmitir información acerca de cuanto tiempo (en mS) estará reservado el medio en la transmisión actual. Todas las estaciones que escuchen una trama en el medio utilizan este campo para actualizar el valor de su vector NAV. Campos de Direcciones: Dentro del formato general de la trama existen cuatro campos asignados para direcciones. Estos campos están diseñados para identificar la dirección del BSS, la dirección de la estación fuente, de la estación destino, de la estación receptora y la dirección de la estación transmisora. No todos los tipos de tramas deben utilizar los cuatro campos asignados, pues por ejemplo algunas tramas de control solamente especifican la dirección de destino. A continuación se presenta la descripción de cada uno de los tipos de dirección posibles:. o BSSID Corresponde a una dirección MAC que identifica plenamente cada BSS de la red. En una red estructurada, esta dirección es administrada por el correspondiente AP. Generalmente la dirección del BSS es la misma dirección del AP.. o Dirección de destino (DA) Es la dirección correspondiente al receptor final de la trama.. o Dirección de origen (SA) Es la dirección correspondiente a la estación que inicialmente envía la trama.. o Dirección receptora (RA) Es la dirección de la próxima estación en recibir la trama. Por ejemplo, en caso de que una estación envíe una trama a otra que no pertenezca al mismo BSS, el campo RA deberá indicar la dirección del AP.. 12.

(13) IEL2-I-04-40. o Dirección transmisora (TA) Corresponde a la dirección de la estación que actualmente transmite la trama. En el ejemplo anterior, cuando el AP recibe el mensaje y lo transmite al correspondiente AP del BSS de destino, en el campo TA de la trama estará relacionada la dirección del AP. Campos de control de secuencia: Este campo tiene una longitud de 16 bits y está dividido en dos sub-campos llamados número de secuencia y número de fragmento. Se diseñó para asignar a cada trama un número de secuencia que se debe mantener constante en cada fragmento de la trama. El sub-campo número de fragmento identifica cada uno de los fragmentos de la trama. Estos campos los utiliza la estación de destino para ensamblar una trama cuando ha sido fragmentada. Hasta aquí se han presentado los campos correspondientes al encabezado de la trama. A continuación se presentarán los campos correspondientes al cuerpo de la trama y verificación de la misma. Cuerpo de la trama: El cuerpo de la trama es un campo de longitud variable entre 0 y 2.312 octetos en el cual se transmiten los datos provenientes de la capa superior. Campos de verificación de error: La longitud de este campo es de 32 bits. Contiene el código de redundancia cíclica con 32 bits para determinar si alguno de los campos del encabezado o del cuerpo de la trama tiene algún error.. 13.

(14) IEL2-I-04-40. 1.3. DESCRIPCION FUNCIONAL DE LA CAPA MAC. A continuación se presenta el funcionamiento de la capa MAC descrito en el estándar IEEE 802.11. Se enfatiza sobre todo en el modo de operación asincrónico también llamado Distributed Coordination Function (DCF) porque éste fue el modelo utilizado para implementar el simulador objeto de este proyecto de grado.. 1.3.1 Distributed coordination function (DCF) Este es el modo de operación básico que todas las estaciones deben soportar cuando trabajen sobre una red WLAN que siga éste estándar. El protocolo utilizado para acceder al medio se llama Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA), y permite que varias estaciones compartan el medio inalámbrico evitando al máximo las colisiones entre los mensajes que cada una transmite. En general esto se logra generando una ventana de tiempo aleatorio cada vez que el medio quede libre y exista un mensaje almacenado en la cola de transmisión del equipo, adicionalmente, el protocolo obliga a que se realice un procedimiento de acuse de recibo positivo cada vez que se reciba una trama. Por otro lado, la prioridad de acceso al canal se maneja por medio de distintos intervalos de tiempo que las estaciones deben esperar antes de poder transmitir cuando el medio quede libre. Estos intervalos de tiempo son llamados Inter Frame Space (IFS) y en el modo DCF se manejan 3 categorías de ellos. El primero y más corto es el SIFS (Short IFS) seguido del DIFS (DCF IFS) y por último el EIFS (Extended IFS). De acuerdo a la secuencia de la transmisión y al papel que cada estación ocupe en esta, deberá esperar un SIFS, un DIFS o un EIFS. Más adelante se presentarán con más detalle estos procedimientos, por ahora solo se pretende dar una pequeña introducción al funcionamiento macro del protocolo.. 14.

(15) IEL2-I-04-40. 1.3.1.1 Detección de portadora Dadas las condiciones impuestas por el medio físico, las estaciones no pueden sensar el medio tal como lo hacen en una red LAN tradicional, esta situación obliga a que la detección de portadora se realice de modo virtual utilizando una entidad lógica llamada Vector de Ocupación de la Red (NAV). En este vector se almacena la información enviada en el campo Duración de cada trama. Cuando el vector alcanza el valor de cero, la estación interpreta que el medio está disponible, de lo contrario entiende que hay una transmisión en curso y disminuye en uno el valor almacenado. Cada vez que una estación escucha una trama en el medio que no está dirigida hacia ella, actualiza el valor de su vector NAV (Solo cuando el valor almacenado es menor que el de la trama), en la figura 1.4 se muestra como es la secuencia de actualización del vector NAV de una estación de la red durante la transmisión de una trama. DIFS RTS. DATA SIFS. SIFS. SIFS. CTS. ACK DIFS. Otra. NAV (RTS) NAV (CTS). Figura 1-4. 1.3.1.2 Generación de ventana aleatoria de tiempo backoff time Cuando una estación tiene un mensaje para transmitir, antes de iniciar la transmisión debe verificar que el medio está disponible observando el valor almacenado en su vector NAV. Si éste indica que el medio está ocupado entonces la estación deberá esperar hasta que el medio se libere y verificar que permanezca así durante un periodo de tiempo DIFS.. 15.

(16) IEL2-I-04-40. Después de este periodo de inactividad en el medio, se generara un tiempo aleatorio de espera adicional que la estación debe cumplir antes de poder iniciar la transmisión, a menos que previamente tenga almacenado un valor diferente de cero en su ventana de tiempo. Este procedimiento se realiza con el fin de minimizar las colisiones que puedan ocurrir en el momento en que la probabilidad de choque es mayor, justo cuando el medio quede disponible y pueda existir más de una estación pendiente por transmitir una trama. La ventana de tiempo está definida de la siguiente manera: Backoff Time = Random() x SlotTime. (1-1). Donde Random() es un número entero proveniente de una distribución uniforme entre el intervalo [0,CW], CW es un valor dentro del rango (CWmin,CWmax) propio de la implementación de PHY. SlotTime a su vez es otro de los parámetros propios de PHY. Una vez generada la ventana de tiempo, la estación debe verificar en cada Slot Time el estado en que se encuentra el medio, si determina que este aún sigue disponible entonces disminuirá en uno el valor del Backoff Time, de lo contrario este valor se mantiene hasta la próxima vez que el medio esté disponible. Cuando el valor del Backoff Time sea cero la estación puede iniciar la transmisión tal como se ilustra en la figura 1.5. DIFS. Sta A. Frame Frame. Sta B Sta C. Frame Frame. Sta D = Tiempo de espera = Back off = Back off Pendiente. Figura 1-5. Todas las estaciones tienen un contador de retransmisión (SRC) cuyo valor inicial es cero, y se incrementa en uno por cada transmisión fallida hasta que alcance el límite de intentos. 16.

(17) IEL2-I-04-40. o hasta que la retransmisión sea exitosa. Adicionalmente cada vez que el contador aumenta, el parámetro CW también lo hace siguiendo la siguiente serie dada en (2) hasta que alcance el valor máximo CWmax: CW = 22-i -1. (1-2). Donde el símbolo i representa el valor de SRC. El valor CW regresa a su mínimo cada vez que haya una transmisión exitosa o que el contador SRC alcanza su valor máximo y la retransmisión se cancele.. 1.3.1.3 Mecanismo rts/cts El estándar IEEE 802.11 establece un mecanismo de intercambio de tramas de control previo al envío de una trama de datos con el fin de minimizar el ancho de banda del canal desperdiciado a causa de las colisiones, pues es menos significativa la pérdida de una trama de control que la pérdida de una trama de datos cuya longitud es mucho mayor (20 y 14 octetos para RTS y CTS respectivamente contra 2312 octetos de una trama de datos). Un RTS es enviado por la estación origen hacia la estación destino cuando necesita transmitir una trama de datos cuya longitud supera el valor del parámetro configurable RTSthreshold. El objetivo del RTS es reservar el medio para realizar la transmisión y además determinar si la estación destino está dispuesta a recibir el mensaje. Cuando una estación recibe un RTS, debe enviar un mensaje CTS de respuesta si se acepta la transmisión, si no lo hace, simplemente no envía ninguna trama y descarta el RTS recibido. Este mecanismo no es utilizado para todas las transmisiones de la red, solamente se usa para aquellas en las que la longitud de la trama de datos supera el valor establecido en el RTSthreshold. Dependiendo del valor de este parámetro, el mecanismo de RTS/CTS puede sobrecargar el tráfico de la red logrando que su eficiencia disminuya.. 17.

(18) IEL2-I-04-40. En la figura 1.6 se presenta la secuencia completa de transmisión de una red operando en el modo asincrónico.. Ventana de contención DIFS Frame actual (Transmisión actual). SIFS. Medio Ocupado. Backoff Window. Siguiente Frame. Slot Time. Tiempo que se debe esperar antes de intentar transmitir. Disminuir el Backoff mientras el medio esté libre. Figura 1-6. 1.3.2 Point coordination function (PCF) PCF es un modo de operación opcional en el que las estaciones no deben luchar por el canal, sino que por el contrario existe un equipo que controla el acceso al medio llamado Point Coordinator (PC). Este equipo se encarga de asignar a cada estación un turno para que transmita las tramas que tenga pendientes por enviar y usualmente es una labor desarrollada por el AP. El algoritmo que el PC utilice para realizar los llamados a las estaciones no está especificado por el estándar. El modo PCF interactúa con el DCF intercambiando el control de operación cada cierto tiempo. El intervalo de tiempo en el cual se opera sobre PCF es llamado Contention Free Period (CFP). Este periodo es iniciado cuando el PC envía una trama de manejo llamada Beacon que tiene como objetivo sincronizar a todas las estaciones y controlar la duración del CFP, así mismo el CFP finaliza cuando el PC envía una trama especial llamada CFEnd.. 18.

(19) IEL2-I-04-40. La duración del CFP está expresada como un número entero de tramas de manejo Beacon y es un parámetro configurable de la red. Una de las características del modo PCF es que al AP puede terminar prematuramente el CFP si determina que el tráfico sobre la red no es significativo y trasladar el control de operación al modo DCF. Cuando el AP envía el Beacon, todas las estaciones ajustan su vector NAV con el valor de la duración del CFP establecido en el parámetro CFP_Max_duration, esto conlleva a que las estaciones solamente puedan transmitir dando respuesta a una solicitud hecha por el AP. Para comenzar la transmisión, el AP censa el medio y verifica que este permanezca libre por un periodo PIFS, en ese momento envía un Beacon, luego espera un periodo SIFS e inicia la secuencia de solicitudes hacia las estaciones hasta que se termine el CFP o hasta que decida que no hay tráfico suficiente para continuar operando sobre PCF. El AP inicia la secuencia de transmisión con cualquiera de las siguientes tramas: CF-Poll, Data o CF-Poll + Data. Donde un CF-Poll es un llamado hecho a la estación. A su vez, cuando una estación recibe una trama CF-Poll puede responder con una trama CF-ACK (no tiene datos para transmitir) o con una trama Data + CF-ACK luego de que haya transcurrido un periodo SIFS. El PC puede transmitir una trama Data + CF-ACK + CF-Poll dirigida a cualquier estación en la red donde el acuse de recibo es enviado para confirmar la transmisión anterior proveniente de otra estación diferente. Con esto se logra que la efectividad de la red aumente.. 19.

(20) IEL2-I-04-40. 2. DISEÑO DEL SIMULADOR. En el capítulo anterior se realizó una descripción de los aspectos más importantes del estándar IEEE 802.11. Se hizo especial énfasis en el modo de operación asincrónico porque sobre este se basa el diseño del simulador. En este capítulo se presta atención al diseño de la solución implementada en OMNET++, de acuerdo a los lineamientos dados en el capítulo 1.. 2.1. INTRODUCCION A LA HERRAMIENTA OMNET++[2]. Omnet++ es un software basado en la teoría de la simulación por eventos discretos, usado para simular varios tipos de sistemas entre los que sobresalen las redes de comunicaciones, protocolos de comunicaciones o modelos de colas entre otros. Un modelo desarrollado en Omnet++ está constituido por varios bloques organizados jerárquicamente que se comunican entre si por medio de mensajes (eventos) a través de links o conexiones y puertos de entrada o de salida. En la terminología utilizada en el manual del usuario de Omnet++ [3], a estos bloques se les llama módulos, donde los bloques fundamentales son llamados módulos simples y los bloques formados por varios módulos simples son llamados módulos compuestos. En cada módulo el usuario especifica los parámetros del modelo, lo que le permite ser bastante flexible en cuanto a su arquitectura y funcionamiento, facilitando el estudio y el análisis de los resultados, pues estos son los parámetros que el usuario podrá variar al ejecutar las simulaciones. En la declaración de los módulos también se especifican cuales son los puertos de entrada y de salida válidos que el este utilizará para comunicarse con los demás.. 20.

(21) IEL2-I-04-40. El modelo se debe desarrollar implementando su algoritmo en los módulos simples utilizando el lenguaje de programación C++. Teniendo en cuenta lo anterior, en Omnet++ se diseña la arquitectura del modelo, para luego describir su funcionamiento en C++ utilizando las funciones de la librería omnetpp.h que también es parte de la aplicación.. 2.2. MODELAMIENTO DE LA SOLUCION EN LENGUAJE UML. Para diseñar el simulador se siguieron apartes de la metodología UML los cuales se presentan a continuación. De acuerdo a [3], el primer paso que se debe dar para alcanzar la solución es conocer y entender perfectamente cuales son los requerimientos del problema y las limitaciones impuestas por las herramientas disponibles. Teniendo esto claro se genera una primera etapa de diseño en la que se identifican las principales entidades del sistema así como también cuales son las tareas que el modelo debe desarrollar. El siguiente paso es relacionar todas estas entidades con las tareas identificadas estableciendo los atributos propios de cada objeto. Finalmente, se realiza una descripción funcional del modelo, en donde se especifican las tareas y relaciones existentes entre todas las entidades presentando al final un diagrama con la operación completa. A continuación se presentan los diagramas UML realizados durante la etapa de diseño del simulador.. 21.

(22) IEL2-I-04-40. 2.2.1 Diagrama de casos de uso En los diagramas de casos de uso se identifican los procesos que debe realizar el prototipo que se pretende diseñar así como también los actores que intervienen en su ejecución, presentando para cada uno de ellos una breve descripción. 802.11. Fuente. Estación Origen. Enviar Mensajes. Canal. Estación Origen. Generar Mensajes. Recibir Mensajes. Canal. Estación Destino. 802.11. Canal. Escuchar el medio. Sumidero. Eliminar Mensajes. Sumidero. Tomar estadísticas. Estación. Figura 2-1. •. Generar mensaje –. Actores: Fuente, Estación origen. –. Descripción: La fuente generadora de mensajes producirá tramas cada cierto tiempo de acuerdo a una distribución de probabilidad dada. La longitud de los mensajes también resultará de una distribución de probabilidad.. 22.

(23) IEL2-I-04-40. Cuando se generen los mensajes, estos se almacenaran en la cola de mensajes de la estación. Los mensajes se generarán respetando el formato de trama especificado en la norma.. •. Enviar mensajes –. Actores: Estación origen, Canal.. –. Descripción: Cuando se genere una petición de envío (RTS, CTS, DATA), la estación origen debe escuchar el canal verificando su vector NAV, si determina que está libre, entonces debe generar y agotar la ventana de tiempo. En ese instante, el mensaje es puesto en el canal y este se encarga de transportarlo hasta su destino.. •. Recibir mensajes –. Actores: Estación destino, Canal.. –. Descripción: Escuchar los mensajes que están en el canal, y para cada uno verificar el campo de dirección destino. Si la dirección en este campo coincide con la dirección propia de la estación, el mensaje es aceptado y se verifican los demás campos de este. De acuerdo a la petición recibida se tramita la respuesta correspondiente. Si por el contrario la dirección de destino no corresponde con la dirección propia, se actualiza el vector NAV con el campo Duración del mensaje y este se descarta.. •. Escuchar el medio. –. Actores: Canal, Estaciones.. –. Descripción: Tomar el campo Duración de los mensajes en el medio, y actualizar con ese valor el vector NAV propio. Disminuir periódicamente (Cada slot time) el valor del vector NAV hasta que llegue a cero. Cuando el valor del vector NAV sea diferente de cero, se entenderá que el medio está ocupado.. 23.

(24) IEL2-I-04-40. •. Eliminar mensaje –. Actores: Sumidero. –. Descripción: Borrar el mensaje del cuando este haya llegado a su destino y se hayan actualizado todas las estadísticas.. •. Tomar estadísticas –. Actores: Sumidero.. –. Descripción: El sumidero toma los datos de cada transmisión, tiempo de transmisión y calcula el rendimiento de la red en términos de Mbps. Luego almacena los resultados en un archivo para ser analizados posteriormente.. 24.

(25) IEL2-I-04-40. 2.2.2 Diagrama conceptual de estructura estática En el siguiente diagrama se identifican todas las entidades que participarán en el prototipo diseñado, indicando sus atributos y las relaciones que mantienen entre si.. Contiene. AP MAC ID BSS ID. BSS. Sumidero. Fuente. # Sta ID AP. Contenedor. Dist. Prob.. Contiene. Se conecta con. Descripción de mensaje Tipo ID Origen ID Destino FCS Duración Cadena (Data). Se conecta con. Genera Describe a. Mensaje. Envía. # Msg. Almacena. Contiene. STA RTSThreshold MAC ID ubicación. PHY. Canal Usa. Dist. Prob. (Colisiones) Bit rate Slot time. Indicador de m edio libre. Determina Se conecta con. Verifica Verifica. Cola Msg. Contenedor FIFO. IFS. BT Dist. Prob. Uniforme CW. Figura 2-2. 25. NAV. Tipo Sifs Difs Eifs.

(26) IEL2-I-04-40. 2.2.3 Diagrama de actividades En este diagrama se presenta el flujo de actividades o tareas a realizar en el modelo y se establecen las entidades más importantes del mismo de acuerdo a lo presentado en el diagrama anterior. Al final de este paso es muy sencillo comenzar a implementar una primera versión del prototipo, pues en este momento se tiene claro como debe ser su arquitectura y funcionamiento. Figura 2-3. Fuente. Estación. Mensaje. Canal. Esperar Mensaje ID origen=My ID? Si No ID destino=My ID?. Verificar tiempo de ocupación. No Si T <= NAV ? RTS. CTS. No. Si NA V = T. NA V = N AV - 1. (Mientras NAV sea > 0) Verificar NAV. R egresa a Inicio. NAV = 0?. No Si. Verificar BT. BT = 0? Verificar N AV. Disminuir N AV. No Si Generar BT. 26. MSG. No. Si. Verificar NAV. ACK.

(27) IEL2-I-04-40. Fuente. Frame. Estación. Canal No. Verificar NAV. NAV = 0?. Verificar NAV. Si. No. Disminuir BT. BT = 0? Si. No. MSG < Rtsth?. Si Enviar Mensaje. No Enviar RTS. Hay respuesta? Verificar NAV. No Si. ACK. CTS. Enviar Mensaje. Regresa a Inicio. Figura 2-4. A partir de este momento, se puede comenzar a realizar la implementación del simulador, pues ya se tienen claros los requerimientos del problema, se conoce la herramienta que se va a utilizar, se han establecido las tareas más importantes del modelo así como también las entidades que lo conforman, sus atributos y la manera en que estas se relacionan entre si. Y por último se tiene claro el funcionamiento del proceso y las responsabilidades asignadas a cada una de las entidades para su correcto desarrollo.. 27.

(28) IEL2-I-04-40. 3. EL MODELO DE SIMULACION. El modelo de simulación utilizado es el de una red estructurada en la que se simula un BSS con su correspondiente AP y un número variable de estaciones que intercambian tramas de datos únicamente, esto quiere decir que todos los usuarios de la red son usuarios asincrónicos que trabajan sobre el modo de operación DCF.. 3.1. ARQUITECTURA DEL MODELO. Para desarrollar el modelo del simulador se implementó un sistema en Omnet++ con parámetros configurables: el número de estaciones de la red, la duración del Slot Time, el valor del RTSthreshold, la longitud de la trama, el tiempo entre arribos de las tramas y la probabilidad de error del medio. El sistema está construido sobre un módulo compuesto de Omnet++ llamado BSS en el cual trabajan tres módulos. Un módulo simple llamado Canal en donde se desarrollan las actividades desarrolladas por el medio, aquí el sistema se encarga de recibir y difundir los mensajes recibidos a todas las estaciones de la red. Sobre este módulo también está implementado un modelo de dispersión del medio que asigna la probabilidad de error para cada una de las tramas. Los otros dos módulos representan a las estaciones de la red y a su correspondiente AP. Sobre estos a su vez trabajan los siguientes tres módulos simples: El primer módulo es llamado Fuente y es el encargado de generar las tramas provenientes de los niveles superiores de la estación o de las redes externas para el caso del AP. Allí se define el valor de los parámetros de longitud de la trama y de tiempo entre arribos de estas. Lógicamente, para el AP este último parámetro será menor que el asignado a las estaciones, pues sobre este equipo está soportado todo el tráfico tanto interno como externo de la red.. 28.

(29) IEL2-I-04-40. El segundo módulo es llamado MAC. Sobre este se desarrollan todas las reglas de acceso al medio dictadas por el estándar, y se puede decir que es el corazón del simulador. El último módulo con que cuentan las estaciones (y el AP) es el Sumidero. Es el que se encarga de tomar todas las estadísticas durante la ejecución del simulador y almacenarlas en un archivo de texto para su posterior análisis. En la figura 3.1 se muestran las características del simulador y en el capítulo 4 se presentan los valores típicos utilizados durante la simulación.. Figura 3-1. 29.

(30) IEL2-I-04-40. 3.2. FUNCIONAMIENTO Y CONSIDERACIONES DEL MODELO DE SIMULACION. Como anteriormente se dijo, Omnet++ es una herramienta utilizada para desarrollar simulaciones por eventos discretos, en donde todos los módulos presentes en el sistema se corren paralelamente ordenando cronológicamente en una cola de eventos, aquellos que han sido programados por cada uno de los módulos, para luego ser ejecutados en ese mismo orden. Un evento puede ser programado como respuesta a la ejecución previa de otro, y por lo tanto será almacenado en la cola de eventos en el lugar que cronológicamente le corresponda. Teniendo esto claro, a continuación se presenta un resumen del funcionamiento del simulador. Los módulos fuentes generan cada cierto tiempo proveniente de una distribución exponencial [6], una trama de longitud resultante de la misma distribución pero con media 1000 octetos tal como en [7]. A esta trama se le asignan los valores básicos utilizados en el simulador (Direcciones origen, destino, longitud y duración), y se envía al módulo MAC. Allí, siguiendo las reglas dadas por el estándar, es enviado al módulo canal para que este distribuya el mensaje en el medio y le asigne un valor al campo de error de la trama de acuerdo al estado del canal (esto se verá en el siguiente apartado) y a las probabilidades de error asignadas. La estación destino recibe la trama, tramita su respuesta y actualiza las estadísticas en su módulo sumidero. Adicionalmente a estas consideraciones, en el modelo se tuvieron en cuenta algunas otras tendientes a reducir su complejidad. Tales consideraciones son presentadas a continuación. Se asume que el tiempo de propagación es 0, es decir, cuando un bit es emitido por la estación origen inmediatamente es recibido por la estación de destino. Esta situación es correcta siempre y cuando la distancia entre las estaciones no supere los 50 m., de otra manera asumir esto no sería viable. Tampoco se tuvo en cuenta el efecto de las estaciones ocultas. Este efecto se presenta cuando una estación determina que el medio está libre y simultáneamente otra estación. 30.

(31) IEL2-I-04-40. está llevando a cabo una transmisión. Para evitar este efecto, en el simulador todas las estaciones son capaces de escuchar los mensajes emitidos por cualquier otro equipo en la red. Se supuso también que ninguna estación opera en el modo de ahorro de energía, es decir todos los equipos están despiertos durante la simulación. Se asume que el canal transmite a una velocidad de 2Mbps para todas los tipos de tramas, independientemente si son tramas de control, manejo o de datos. Se asume que una trama está corrupta cuando uno de sus bits es recibido con errores, en cuyo caso la trama se descarta.. 3.3. MODELO DE DISPERSION DEL CANAL. De acuerdo a lo que se muestra en [8], una cadena de Markov de dos estados puede ser utilizada para generar errores en las tramas que transitan sobre el medio. El primer estado es llamado estado G (good) y el otro es llamado estado B (bad, burst). En el estado G las transmisiones están libres de error, mientras que en el estado B el canal tiene una probabilidad h de transmitir correctamente cada bit recibido. Adicionalmente, la transición entre ambos estados también está gobernada por dos probabilidades; p para la transmisión entre BÆG y P para la transmisión entre GÆB. Estas transiciones, el tiempo estimado para el cambio de estado y la probabilidad de error generan un modelo de dispersión del canal y de transmisión de errores en la trama. El valor de h es puesto en 0.5, y cada vez que se transmita un bit, el estado actual del canal tenderá a mantenerse. Así, las probabilidades Q y q de que el medio permanezca en el estado G y B respectivamente son altas. En la figura 3.2 se muestra el diagrama del modelo anterior.. 31.

(32) IEL2-I-04-40. β. B G α. Figura 3-2. 3.4. MODELO DE DISPERSION IMPLEMENTADO. En la simulación, este modelo se construyó basado en [7], en donde se modifica ligeramente el modelo expuesto anteriormente. Aquí la dispersión del canal también se modela como una cadena de Markov de dos estados continuos en el tiempo donde el estado G representa al canal en un estado limpio operando con una tasa de error muy baja (BERgood) y el estado B representa un canal disperso que opera con una tasa de error alta llamada BERbad. La transición entre los dos estados se produce a ratas de cambio fijas en donde la transición entre G y B ocurre a una rata llamada α mientras que la transición entre B y G es llamada β. Siguiendo este modelo, puede suceder que una porción de la trama se transmita en el estado G y el resto de trama se transmita en el estado B. Por lo tanto, de acuerdo con lo que dice [9] la probabilidad de transmitir correctamente la trama se calcula siguiendo la siguiente ecuación: Pexito = (1-BERbad)n1·(1-BERgood)n2. (3.1). Donde el número de bits transmitidos en el estado B está representado por n1 y el número de bits transmitidos en el estado G está representado por n2.. 32.

(33) IEL2-I-04-40. 4. PRUEBAS REALIZADAS EN EL SIMULADOR. Utilizando el simulador se realizaron varias pruebas con las que se pretendía evaluar distintos aspectos del rendimiento de la red. Así se obtuvieron gráficas para determinar cual era el valor óptimo del RTS threshold, o como la longitud promedio de la trama afectaba el desempeño de la red. También se realizaron pruebas para determinar el efecto producido por la dispersión del canal, realizando simulaciones para diferentes valores de BERbad. En la tabla 5.1 se presentan los valores típicos con los que se trabajó durante las simulaciones. ATRIBUTO. Valor Típico. Vel. Del canal. 2 Mbps.. BERgood. 10-8. α. 30 s-1. β. 10 s-1. RTSthreshold. 300. SRC. 5. Slot Time. 20µs. SIFS. 10 µs. DIFS. 50 µs. No. Estaciones. 10. Longitud Trama. 1000 Octetos Tabla 4-1. A continuación se presentan los resultados obtenidos para cada una de las simulaciones realizadas.. 33.

(34) IEL2-I-04-40. 4.1. VALOR OPTIMO DEL RTS THRESHOLD. En la figura 4.1 se presentan los resultados obtenidos al simular el modelo de la red, para varios valores de RTSthreshold con dos longitudes de tramas diferentes.. 0,9 0,8. Throughput. 0,7 0,6 0,5 0,4 0,3. MSDU 200 MSDU 1000. 0,2 0,1. 2312. 2250. 2000. 1750. 1500. 1250. 1000. 750. 500. 400. 300. 100. 0. 0. RTS Threshold. Figura 4-1 En la gráfica se observa que el valor óptimo del parámetro RTSthreshold se ubica dentro del rango de 300 a 500 octetos, pues a partir de ese valor el rendimiento de la red disminuye, y con un valor menor a 300 octetos el desempeño se ve sacrificado a causa de la sobrecarga ofrecida por los mensajes de control. Para una longitud de trama de 200 octetos, la capacidad máxima del canal asciende al 73%, y para una longitud de trama de 1000 octetos la capacidad máxima está cerca del 80%. Se evidencia, que una longitud mayor de trama genera una mejora en el rendimiento de la red.. 34.

(35) IEL2-I-04-40. 4.2. EFECTO DE LA LONGITUD DE LA TRAMA SOBRE EL RENDIMIENTO DE LA RED. En la figura 4.2 se observan los resultados obtenidos en la red cuando en la simulación se varía la longitud promedio de la trama utilizando los parámetros dados en la tabla 4.1 para longitudes de trama de 200, 1000 y 2000 octetos.. Carga Recibida. Efecto debido a la longitud de la trama 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 0,000. 0,212. 0,405. 0,587. 0,785. 1,000. Carga Ofrecida MSDU 200. MSDU 1000. MSDU 2000. Figura 4.2 Se observa que entre mayor sea la longitud de la trama, mayor será la eficiencia de la red mientras el medio opere en el estado limpio pero cuando el medio cambia al estado B del modelo de dispersión, la capacidad de la red disminuye debido a que existe una mayor probabilidad de error sobre la trama.. 35.

(36) IEL2-I-04-40. 4.3. EFECTO DEL BERbad SOBRE EL RENDIMIENTO DE LA RED. La siguiente simulación demuestra el comportamiento de la red para distintos valores de BERbad.. Carga Recibida. Efecto del BER_bad 0,8 0,6 0,4 0,2 0 0. 0,196. 0,424. 0,605. 0,812. 1. Carga Ofre cida BER bad 10e-3. BER bad 10e-5. BER bad 10e-8. Figura 4.3 Como era de esperarse, con una tasa de error mas alta el rendimiento de la red apenas supera el 30%, mientras que con un BER muy pequeño, el rendimiento de la red es altamente satisfactorio. Para realizar esta simulación, se mantuvieron constantes los parámetros dados en la tabla 4.1 y se ejecutaron varias pruebas con tres valores diferentes de probabilidad de error BERbad.. 36.

(37) IEL2-I-04-40. 5. CONCLUSIONES. Se implementó una herramienta que simula exitosamente el funcionamiento de la capa de control de acceso al medio (MAC) de una red inalámbrica de computadores logrando evaluar su capacidad y desempeño. El sistema permite variar algunos parámetros configurables de la red logrando analizar su comportamiento bajo diferentes esquemas de simulación. Concretamente se encontró que un valor por fuera del rango de 300 y 500 octetos en el parámetro RTSthreshold, disminuye el rendimiento de la red, ya sea porque esta se sobrecarga con una cantidad considerable de mensajes de control, o porque. las. colisiones que ocurren involucran tramas de datos con una longitud considerable, desperdiciando en ambos casos el ancho de banda del canal. Se encontró que la longitud de la trama es un aspecto fundamental a tener en cuenta cuando se evalúa la red. Con respecto a este parámetro se encontró que cuando la longitud de la trama era mayor, el rendimiento de la red aumentaba siempre y cuando el canal opere en el estado limpio, si el canal opera sobre el estado de desvanecimiento se obtiene el resultado contrario. Se implementó en el simulador un modelo de dispersión del canal con una cadena de Markov de dos estados continuos en el tiempo obteniendo los resultados esperados, donde un canal limpio ofrece un rendimiento de la red cercano al 80%, mientras que un canal en estado de desvanecimiento ofrece un rendimiento de la red de tan solo el 40%. En este trabajo se explican los principales conceptos presentados por el estándar IEEE 802.11 facilitándole al lector su estudio y comprensión.. 37.

(38) IEL2-I-04-40. BIBLIOGRAFIA. [1]. IEEE Std 802.11 – 1999, “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications” [2]. Omnet++ Discrete Event Simulation System. http://www.omnetpp.org/ [3]. OMNeT++ Discrete Event Simulation System Version 2.3 User Manual. http://www.omnetpp.org/external/doc/html/usman.php [4]. Larman Craig, “Applying UML and patterns: an introduction to object-oriented analysis and design”, Prentice Hall, 1998 [5]. Pressman Roger, “Ingeniería del Software. Un enfoque práctico”, 4ª. Ed. Mexico, McGraw Hill, 1997 [6]. Anastasi G., Lenzini L., (2000) QoS provided by the IEEE 802.11 wireless LAN to advanced data applications: a simulation analysis, Wireless Networks, 6, p. 99–108. [7]. Crow B., Widjaja I., Kim G., Sakai P., (1997) Investigation of the IEEE 802.11 Medium Acces Control (MAC) Sublayer Functions. [8]. Crow B., Widjaja I., Kim G., Sakai P., (1997) IEEE 802.11 Wireless Local Area Networks. IEEE Communications Magazine,9, p. 116-126. [9]. Gilbert E., (1960) Capacity of a Burst-Noise Channel, The Bell System Technical Journal,9.. 38.

(39) IEL2-I-04-40. A. ANEXO: CODIGO DE IMPLEMENTACIÓN DEL SIMULADOR EN OMNET++ UTILIZANDO EL LENGUAJE NED.. A continuación se presenta el código con el que se implementó la arquitectura del simulador en Omnet++ utilizando su lenguaje de descripción NED. module Sta parameters: macID : numeric const, slot_time : numeric const, cw : numeric const, time_out : numeric const, estaciones : numeric const, rts_threshold : numeric const; gates: in: in; out: out; submodules: sumidero: Sumidero; display: "p=219,130;i=sink;b=32,30"; fuente: Fuente; parameters: numStas = estaciones, macID = macID; display: "p=151,131;i=gen;b=32,30"; wmac: Wmac; parameters: MacId = macID, Slot_Time = slot_time, CW = cw, timeout = time_out, rtsthreshold = rts_threshold; display: "p=189,194;i=cogwheel;b=32,30"; connections: fuente.a_mac --> wmac.de_fuente; wmac.a_sumidero --> sumidero.de_mac; wmac.a_canal --> out; in --> wmac.de_canal; display: "p=122,90;b=121,156"; endmodule //Generador de mensajes, simula las capas superiores de la estación simple Fuente // parameters: numStas : numeric const,. 39.

(40) IEL2-I-04-40. macID : numeric const; gates: out: a_mac; endsimple simple Sumidero gates: in: de_mac; endsimple //Módulo donde está implementado el protocolo de acceso al medio //para una red inalambrica CSMA/CA simple Wmac parameters: MacId : numeric const, Slot_Time : numeric const, CW : numeric const, timeout : numeric const, rtsthreshold : numeric const; gates: out: a_canal; out: a_sumidero; in: de_fuente; in: de_canal; endsimple //Módulo que representa el medio inalámbrico simple Canal // parameters: numStas : numeric const; gates: in: de_sta[]; out: a_sta[]; endsimple module BSS parameters: numStas : numeric const, slot_time : numeric const, cw : numeric const, time_out : numeric const, rts_threshold : numeric const; submodules: sta: Sta[numStas]; parameters: macID = index, // De 0 a numStas-1 slot_time = slot_time, cw = cw, time_out = time_out, estaciones = numStas, rts_threshold = rts_threshold; display: "i=laptop3"; canal: Canal; parameters: numStas = numStas;. 40.

(41) IEL2-I-04-40. gatesizes: de_sta[numStas+1], a_sta[numStas+1]; display: "i=cloud;p=167,252;b=41,19"; AP: Sta; parameters: macID = numStas, slot_time = slot_time, cw = cw, time_out = time_out, estaciones = numStas, rts_threshold = rts_threshold; display: "p=164,348;i=server1;b=30,34"; connections: for i=0..numStas-1 do sta[i].out --> datarate 4000000 --> canal.de_sta[i]; canal.a_sta[i] --> datarate 4000000 --> sta[i].in; endfor; canal.a_sta[numStas] --> datarate 4000000 --> AP.in; AP.out --> datarate 4000000 --> canal.de_sta[numStas]; display: "p=27,8;b=360,392"; endmodule network Network : BSS parameters: numStas = input(5,"Número de estaciones en la red."), time_out = input(0.02,"Ingrese el valor time out"), rts_threshold = input(250, "Ingrese el valor del RTS threshold"), cw = 7, slot_time = input(0.00002,"Ingrese el valor de cada Slot Time (En Segundos)"); endnetwork. enum PacketType { CTS = 1; RTS = 2; ACK = 3; UPPERDATA = 4; DATA = 5; }; message WlanMsg { fields: int Destino; int Origen; double DurationID; bool Error; };. 41.

(42) IEL2-I-04-40. B. ANEXO: CODIGO DE IMPLEMENTACION DEL SIMULADOR EN C++. //------------------------------------------------------------// file: Canal.cpp //------------------------------------------------------------#include <math.h> #include <omnetpp.h> #include "mensajes_m.h". // Módulo que representa al medio inalámbrico class Canal : public cSimpleModule { int Num_Colisiones; int frames; int Total_bits; Module_Class_Members(Canal,cSimpleModule,16384) virtual void activity(); }; Define_Module( Canal ); void Canal::activity() { int numstas = par("numStas"); int Num_Colisiones=0; int frames=0; int Total_bits=0; bool G=0; WlanMsg *msg, *msgin, *copy; cMessage *TxEnd = new cMessage("TxEnd"); cMessage *Ch = new cMessage("Channel",30); scheduleAt(simTime()+30, Ch); for (;;) { cMessage *temp = receive (); if (temp == TxEnd) delete temp; else if (temp->kind()==30) { delete temp; cMessage *Ch = new cMessage("Channel",10); scheduleAt(simTime()+10, Ch); G=1;. 42.

(43) IEL2-I-04-40. } else if (temp->kind()==10) { delete temp; cMessage *Ch = new cMessage("Channel",30); scheduleAt(simTime()+30, Ch); G=0; } else { ev<< "Mensaje recibido en el medio.\n"; msgin = (WlanMsg *) temp; frames++; WATCH(frames); int msglong = msgin->length()*8; Total_bits = Total_bits+msglong; simtime_t Txtime = msglong/2000000; scheduleAt(simTime()+Txtime, TxEnd); if ((msg = (WlanMsg *) receive()) != TxEnd) { ev<< "Colisión!!!\n"; frames++; Total_bits=Total_bits+msglong; msglong = msg->length()*8; Txtime = msglong/2000000; cancelEvent(TxEnd); scheduleAt(simTime()+Txtime, TxEnd); msgin ->setError(1); msg ->setError(1); Num_Colisiones++; for (int i=0;i <= numstas;i++) { copy = (WlanMsg *) msgin->dup(); send(copy,"a_sta",i); copy = (WlanMsg *) msg->dup(); send(copy,"a_sta",i); } } else { if (G==0) { double Prob = pow((1-1.0e-8),msglong); int error = uniform(1,101); if (error > 100*Prob) msgin -> setError(1); } else. 43.

(44) IEL2-I-04-40. { double Prob = pow((1-1.0e-5),msglong); int error = uniform(1,101); if (error > 100*Prob) msgin -> setError(1); } for (int i=0; i <= numstas; i++) { if (i==msgin->getOrigen()) continue; copy = (WlanMsg *) msgin->dup(); send(copy,"a_sta",i); } delete msgin; } } } }. 44.

(45) IEL2-I-04-40. //------------------------------------------------------------// file: Fuente.cpp //------------------------------------------------------------#include <omnetpp.h> #include "mensajes_m.h" // Fuente de mensajes que simula la generación de tramas // de las capas superiores. class Fuente : public cSimpleModule { Module_Class_Members(Fuente,cSimpleModule,16384) virtual void activity(); }; Define_Module( Fuente ); void Fuente::activity() { int numStas = par("numStas"); int macID = par("macID"); double tiempo = exponential(1.0); WATCH(tiempo); int destino; for(;;) { if (macID == numStas) { wait(tiempo/numStas); destino=intrand(numStas); } else { wait(tiempo); destino=numStas; } int long_Msg = exponential(2000); while (long_Msg>2346) { long_Msg = exponential(2000); }. 45.

(46) IEL2-I-04-40. WlanMsg *upperdata = new WlanMsg ("Upper Data",UPPERDATA); upperdata->setDestino(destino); upperdata->setOrigen(macID); upperdata->setLength(long_Msg*8); upperdata->setError(0); ev<<"Enviando trama...\n"; send(upperdata, "a_mac"); carga.record(long_Msg*8); tiempo = exponential(1.0); } }. 46.

(47) IEL2-I-04-40. //------------------------------------------------------------// file: Sumidero.cpp //------------------------------------------------------------#include <omnetpp.h> #include "mensajes_m.h" // Sumidero simple module class // // Módulo encargado de eliminar los mensajes que // llegan a la estación y de tomar algunas estadísticas // del protocolo. // class Sumidero : public cSimpleModule { Module_Class_Members(Sumidero,cSimpleModule,16384) virtual void activity(); }; Define_Module( Sumidero ); void Sumidero::activity() { cOutVector rendimiento("Rendimiento",1); cKSplit endToEndDelayKS("End-to-End Delay histogram (K-split)"); endToEndDelayKS.setRangeAutoUpper(0.0, 100, 2.0); cPSquare endToEndDelayPS("End-to-End Delay histogram (P2)"); WlanMsg *msg; double Mbps; simtime_t eed; for(;;) { msg = (WlanMsg *) receive(); if (msg->getDestino()==-1) { Mbps = 0; ev<< "Mensaje descartado, rendimiento de la red = 0\n"; } else {. 47.

(48) IEL2-I-04-40. eed = simTime() - msg->creationTime(); Mbps = msg->length()/eed; ev << "Mensaje recibido, end-to-end delay=" << simtimeToStr(eed) << endl; ev << "Rendimiento de la red (Mbps)=" << Mbps << endl; } // Almacenar estadísticas endToEndDelay.record(eed); rendimiento.record(Mbps); endToEndDelayKS.collect(eed); endToEndDelayPS.collect(eed); delete msg; } }. 48.

(49) IEL2-I-04-40. //------------------------------------------------------------// file: Wmac.cpp //------------------------------------------------------------#include <omnetpp.h> #include "mensajes_m.h" // // Módulo en donde está implementado el protocolo // IEEE 802.11 class Wmac : public cSimpleModule { cQueue WmacQueue; int msgtosend; Module_Class_Members(Wmac,cSimpleModule,16384) virtual void activity(); }; Define_Module( Wmac ); void Wmac::activity() { int MacId = par ("MacId"); double Slot_time = par ("Slot_Time"); int CW = par ("CW"); simtime_t timeout = par ("timeout"); int rtsthreshold = par("rtsthreshold"); int retrx=0; double NAV=0; int BT=0; int flag=0; int SRC = 0; msgtosend = 0; WmacQueue.setName("WmacQueue"); WlanMsg *data, *msg, *copy, *rtx; cMessage *dar; char msgname[15]; for(;;) { cMessage *msgin = receive(); SRC=0; if (msgin->kind()==UPPERDATA) { ev<<"Mensaje recibido de las capas superiores.\n"; data = (WlanMsg *) msgin; sprintf(msgname, "%d->Data->%d", MacId, data->getDestino());. 49.

(50) IEL2-I-04-40. data->setName(msgname); data->setKind(DATA); data->setDurationID(0.000056+0.5*Slot_time); WmacQueue.insert(data); retransmision: rtx = (WlanMsg *) WmacQueue.tail(); if ( rtx->length()/8 >= rtsthreshold) { ev<< "Longitud de la trama ="<< rtx->length()/8 << " Bytes. Se debe enviar RTS!!!\n"; WlanMsg *rts = new WlanMsg ("",RTS); sprintf(msgname, "%d->RTS->%d", MacId, rtx->getDestino()); rts->setName(msgname); rts->setOrigen(MacId); rts->setDestino(rtx->getDestino()); rts->setDurationID((double) rtx->length()/2000000+0.00008+Slot_time+(rtx>getDurationID())); rts->setError(0); rts->setLength(160); WmacQueue.insertAfter(rtx,rts); } else ev<< "Longitud de la trama ="<< rtx->length()/8 << " Bytes. No se debe enviar RTS!!!\n"; if (retrx == 1) { if (SRC==4) { CW = par("CW"); ev<< "Mensaje descartado...\n"; rtx = (WlanMsg *) WmacQueue.tail(); if (rtx->kind()==RTS) { delete WmacQueue.pop(); msg = (WlanMsg *) WmacQueue.pop(); msg -> setDestino(-1); send (msg,"a_sumidero"); } else { msg = (WlanMsg *) WmacQueue.pop(); msg -> setDestino(-1); send (msg, "a_sumidero"); } continue; } CW=2*CW+1; } if (CW == 255) CW = par("CW"); wait (NAV); WATCH(NAV); BT = intuniform(0,CW-1); NAV=0; while(BT>0) {. 50.

(51) IEL2-I-04-40. msg = (WlanMsg *) receive(Slot_time); if (msg==NULL) { wait (NAV); WATCH (BT); BT--; } else { if (msg->getDestino()==MacId) { if(msg->kind()==RTS) { if(msg->getError()==0) { WlanMsg *cts = new WlanMsg ("", CTS); sprintf(msgname,. "%d->CTS->%d",. MacId, data->getOrigen()); NAV = msg -> getDurationID(); cts -> setName(msgname); cts -> setOrigen(MacId); cts -> setDestino(msg->getOrigen()); cts -> setLength(112); cts -> setDurationID(msg>getDurationID()-(0.5*Slot_time+0.00008)); cts -> setError(0); wait (0.5*Slot_time); ev<< "Enviando mensaje de respuesta CTS...\n"; send(cts,"a_canal"); delete msg; } else { ev<< "Mensaje " << msg->name() << " recibido con errores, el mensaje se descarta...\n"; NAV = 0; delete msg; } } else if(msg->kind()==DATA) { if(msg->getError()==0) { WlanMsg *ack = new WlanMsg ("", ACK); sprintf(msgname,. "%d->ACK->%d",. MacId, data->getOrigen()); ack -> setName(msgname); ack -> setOrigen(MacId); ack -> setDestino(msg->getOrigen()); ack -> setLength(112); ack -> setDurationID(0); ack -> setError(0); NAV = 0;. 51.

(52) IEL2-I-04-40. wait (0.5*Slot_time); ev<< "Enviando acuse. de. recibo. ACK...\n"; send(ack, "a_canal"); send(msg, "a_sumidero"); } else { ev<< "Mensaje " << msg->name() << " recibido con errores, el mensaje se descarta...\n"; NAV = 0; delete msg; } } else { ev<< "Error del protocolo...\n"; NAV = 0; delete msg; } } else { NAV = msg->getDurationID(); delete msg; } } } msg = (WlanMsg *) WmacQueue.pop(); if (msg -> kind() == DATA) { copy = (WlanMsg *) msg->dup(); rtx = (WlanMsg *) WmacQueue.tail(); if (rtx == NULL) { WmacQueue.insert(copy); } else { WmacQueue.insertAfter(rtx,copy); } } if (retrx == 1) { wait(3*Slot_time); } else { wait(2.5*Slot_time); } ev<< "Enviando mensaje: "<< msg->name() <<endl; if (msg->kind()==RTS) timeout=(0.5*Slot_time+0.000137); else timeout=(0.5*Slot_time+0.00945); send( msg,"a_canal"); ev<< "Esperando mensaje de respuesta...\n";. 52.

(53) IEL2-I-04-40. dar = (cMessage *) receive(timeout); if (dar==NULL) { ev<<"Programar retransmisión!!!\n"; retrx=1; SRC++; goto retransmision; } else { msg = (WlanMsg *) dar; if (msg->getError()==0) { if(msg->kind()==ACK && msg->getDestino()==MacId) { ev<< "Mensaje de datos recibido satisfactoriamente.\n"; retrx=0; CW= par("CW"); delete msg; delete WmacQueue.pop(); NAV = 0; } else if (msg->kind()==CTS && msg->getDestino()==MacId) { delete msg; msg = (WlanMsg *) WmacQueue.pop(); copy = (WlanMsg *) msg->dup(); rtx = (WlanMsg *) WmacQueue.tail(); if (rtx == NULL) { WmacQueue.insert(copy); } else { WmacQueue.insertAfter(rtx,copy); } wait (0.5*Slot_time); ev<< "Enviando mensaje de datos.\n"; send (msg,"a_canal"); ev<< "Esperando mensaje de respuesta...\n"; timeout=(0.5*Slot_time+0.00945); dar = (cMessage *) receive(timeout); if (dar==NULL) { ev<<"Programar retransmisión!!!\n"; retrx=1; SRC++; goto retransmision; } else { msg = (WlanMsg *) dar; if(msg->getError()==0) { if(msg->kind()==ACK && msg>getDestino()==MacId) {. 53.

(54) IEL2-I-04-40. ev<<. "Mensaje. de. datos. recibido satisfactoriamente!\n"; retrx=0; CW= par ("CW"); NAV = 0; delete msg; delete WmacQueue.pop(); } else { ev<< "Error del protocolo.\n"; ev<< "Programar retransmisión.\n"; SRC++; retrx=1; NAV = 0; delete msg; goto retransmision; } } else { ev<< "Mensaje recibido con errores, el mensaje se descarta.\n"; ev<< "Programar retransmisión.\n"; retrx=1; SRC++; NAV = 0; delete msg; goto retransmision; } } } else { ev<< "Error del protocolo.\n"; ev<< "Programar retransmisión.\n"; SRC++; retrx=1; NAV = 0; delete msg; goto retransmision; } } else { ev<< "Mensaje recibido con errores, el mensaje se descarta.\n"; ev<< "Programar retransmisión.\n"; retrx=1; SRC++; NAV = 0; delete msg; goto retransmision; } } } else. 54.

(55) IEL2-I-04-40. { msg = (WlanMsg *) msgin; if (msg->getDestino()==MacId) { if (msg->kind()==RTS) { if (msg->getError()==0) { WlanMsg *cts = new WlanMsg ("", CTS); sprintf(msgname, "%d->CTS->%d", MacId,. msg-. >getOrigen()); NAV = msg -> getDurationID()-(0.5*Slot_time+0.000056); WATCH(NAV); cts -> setName(msgname); cts -> setOrigen(MacId); cts -> setDestino(msg->getOrigen()); cts -> setLength(112); cts -> setDurationID(msg->getDurationID()(0.5*Slot_time+0.000056)); cts -> setError(0); wait (0.5*Slot_time); ev<< "Enviando mensaje de respuesta CTS...\n"; send(cts,"a_canal"); delete msg; } else { ev<< "Mensaje " << msg->name() << " recibido con errores, el mensaje se descarta...\n"; NAV = 0; delete msg; } } else if (msg->kind()==DATA) { if (msg->getError()==0) { WlanMsg *ack = new WlanMsg ("", ACK); sprintf(msgname, "%d->ACK->%d", MacId,. msg-. >getOrigen()); NAV = 0; WATCH(NAV); ack -> setName(msgname); ack -> setOrigen(MacId); ack -> setDestino(msg->getOrigen()); ack -> setLength(112); ack -> setDurationID(0); ack -> setError(0); wait (0.5*Slot_time); ev<< "Enviando acuse de recibo ACK...\n"; send(ack, "a_canal"); send(msg, "a_sumidero"); } else { ev<< "Mensaje " << msg->name() << " recibido con errores, el mensaje se descarta...\n";. 55.

(56) IEL2-I-04-40. NAV = 0; delete msg; } } else { ev<< "Error del protocolo...\n"; NAV = 0; delete msg; } } else { NAV=msg->getDurationID(); WATCH(NAV); delete msg; } } } }. 56.

(57)