MODELADO DE LA NORMA 802.11n EN NS-3bibing.us.es/proyectos/abreproy/12207/fichero/MemoriaPFC.pdf ·...

Escuela Tecnica Superior de IngenierıaUniversidad de Sevilla

Departamento de Ingenierıa Telematica

MODELADO DE LA NORMA 802.11n EN NS-3

Autor: David Bravo AlmazanTutor: Juan M. Vozmediano Torres

Proyecto Fin de Carrera

Ingenierıa de Telecomunicacion

Sevilla, 29 de Junio de 2014

Proyecto Fin de Carrera Departamento de Ingenierıa Telematica

Tanto la memoria de este trabajo como el software desarrollado se distribuyen bajola licencia GNU GPL v3.

La Licencia Publica General GNU (GNU GPL) es una licencia libre, sin derechospara software y otro tipo de trabajos.

Las licencias para la mayorıa del software y otros trabajos practicos estan desti-nadas a suprimir la libertad de compartir y modificar esos trabajos. Por el contrario,la Licencia Publica General GNU persigue garantizar su libertad para compartir ymodificar todas las versiones de un programa–y asegurar que permanecera como soft-ware libre para todos sus usuarios. Nosotros, La Fundacion de Software Libre, usamosla Licencia Publica General GNU para la mayorıa de nuestro software; y tambien seaplica a cualquier trabajo realizado de la misma forma por sus autores. Usted tambienpuede aplicarla a sus programas.

Cuando hablamos de software libre, nos referimos a libertad, no a precio. NuestrasLicencias Publicas Generales estan destinadas a garantizar la libertad de distribuircopias de software libre (y cobrar por ello si quiere), a recibir el codigo fuente o poderconseguirlo si ası lo desea, a modificar el software o usar parte del mismo en nuevosprogramas libres, y a saber que puede hacer estas cosas.

Mas informacion sobre las licencias y sus terminos:

http://www.gnu.org/licenses/gpl.html (Licencia original en ingles)

http://www.viti.es/gnu/licenses/gpl.html (Traduccion de la licencia al castellano)

David Bravo Almazan 3

http://www.gnu.org/licenses/gpl.html

http://www.viti.es/gnu/licenses/gpl.html


Antes de comenzar a hablar de conceptos tecnicos me gustarıa agradecer el apoyo quemis familiares y amigos me han dado durante mi paso por la universidad. Suena a topico,pero tengo que resenar que sin ellos llegar hasta aquı hubiera sido imposible para mı. Laconfianza que han depositado siempre en mi ha sido el motor que me ha traıdo hasta aquı.

Gracias de verdad



“The nice thing about standards is that there are so many to choose from.

And if you really don’t like all the standards you just have towait another year until the one arises you are looking for.”

——“Lo bueno de las normas es que hay muchas entre las que elegir.

Y si realmente ninguna norma le gusta solo tiene que esperarotro ano hasta que aparezca la norma que busca.”

– A. Tanenbaum, “Introduction to Computer Networks”



Indice

Resumen 15

1. Introduccion 17

1.1. Objetivo del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2. Planificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2. Antecedentes 19

2.1. Wi-Fi 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1. Historia/Evolucion . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.2. 802.11n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2. Network Simulator 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3. Analisis de debilidades 31

3.1. Dispositivos que operan en modos 802.11n . . . . . . . . . . . . . . . . . . 32

3.2. Sensibilidad de recepcion de senal para modulaciones OFDM de 802.11n . 32

3.3. Gestion de asociaciones entre APs y STAs . . . . . . . . . . . . . . . . . . 33

4. Modelado del modulo Wi-Fi 35

4.1. Dispositivos que operan en modos 802.11n . . . . . . . . . . . . . . . . . . 35

4.1.1. Analisis de la solucion adoptada . . . . . . . . . . . . . . . . . . . . 35

4.1.2. Modelado de la solucion . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.3. Simulaciones de verificacion . . . . . . . . . . . . . . . . . . . . . . 39

4.2. Sensibilidad de recepcion de senal para modulaciones OFDM de 802.11n . 44


Departamento de Ingenierıa Telematica Proyecto Fin de Carrera




4.3. Gestion de asociaciones entre APs y STAs . . . . . . . . . . . . . . . . . . 49




5. Lıneas de continuacion 55

5.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.1. Grados de libertad de la norma . . . . . . . . . . . . . . . . . . . . 55

5.1.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Anexos 63

A. Manual ns-3 63

A.1. Construccion del escenario para la norma 802.11n . . . . . . . . . . . . . . 63

A.2. 802.11n - Modos de transmision . . . . . . . . . . . . . . . . . . . . . . . . 65

A.3. Proceso de recepcion de paquetes . . . . . . . . . . . . . . . . . . . . . . . 68

B. Escenarios 73

C. Modelado corregido 99

Bibliografıa 122

10 David Bravo Almazan


Figuras

2.1. Arquitectura ns-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2. Organizacion del software en ns-3 . . . . . . . . . . . . . . . . . . . . . . . 272.3. Arquitectura del modulo Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . 29

A.1. Diagrama de secuencia para el calculo de PER . . . . . . . . . . . . . . . . 68



Tablas

2.1. Comparativa normas 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2. Indices de esquemas de modulacion y codificacion . . . . . . . . . . . . . . 232.3. Espacio intertrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1. Comparativa de paquetes recibidos correctamente . . . . . . . . . . . . . . 434.2. Sensibilidad mınima de recepcion . . . . . . . . . . . . . . . . . . . . . . . 454.3. Sensibilidad mınima de recepcion +6 dB . . . . . . . . . . . . . . . . . . . 484.4. Protocolo de verificacion del modelado de la gestion de asociaciones . . . . 53

A.1. Tasas de datos para la norma 802.11g . . . . . . . . . . . . . . . . . . . . . 65



Resumen

En la actualidad son valoradas las herramientas que permiten simular el comporta-miento de dispositivos reales. Este tipo de herramientas son tıpicamente de pago, aunquetambien existen alternativas distribuidas bajo licencia libre. La calidad del software tecni-co distribuido bajo licencia libre ha estado siempre ligada al ambito academico.

Network Simulator 3 es un simulador de redes basado en eventos discretos y distribuidobajo licencia libre. El proyecto ns-3 nacio con la idea de dar la posibilidad de simularredes que se comporten bajo las nuevas normas tecnologicas. Hoy en dıa las nuevas normastecnologicas aportan una cantidad tan grande de novedades tecnologicas que no pueden sermodeladas a tiempo por la comunidad de desarrolladores de ns-3. Es el caso de la norma802.11n, esta norma de la IEEE define las modificaciones de sus normas predecesoras quehacen que las redes inalambricas de area local mejoren significativamente su rendimiento.

El modelado que hace ns-3 de la norma 802.11n cuenta con fallos que hacen imposible lacreacion de escenarios en los que dispositivos 802.11n se comuniquen usando las nuevastasas de transmision aportadas por la norma. Por otra parte, ns-3 cuenta con carenciasen el modelado de la sensibilidad de recepcion de senales; y en la gestion de los casos deconexion y desconexion de un cliente.

Este proyecto solventa los fallos comentados y aporta bancos de pruebas que verifican suvalidez. El avance en la calidad del modelado de la norma 802.11n es tan significativo queabre la puerta a investigaciones de la norma 802.11n que se quieran realizar utilizandoNetwork Simulator 3 como herramienta.

Por ultimo, este documento aporta una solida base de conocimiento con la que iniciarel desarrollo de un algoritmo de seleccion de tasa. El diseno de un algoritmo de estascaracterısticas es la lınea de continuacion ofrecida. Ahora, gracias al modelado introducidoen este proyecto, es posible simular de manera fiable el comportamiento del algoritmodisenado.



1. Introduccion

A finales de Julio de 2013 recibı un correo electronico de AOIFE Solutions en el quedecıan buscar alumnos en practicas con la posibilidad de realizar el proyecto fin de carreracon ellos. Mi perfil les llego a traves de Juan Manuel Vozmediano al que le estare siempreagradecido por ello. Tras una entrevista y alguna reunion con Jose Ayub Gonzalez meembarque en las practicas y en la realizacion de este proyecto fin de carrera en el marcode las redes inalambricas.

La red inalambrica mas popular es la denominada red de area local inalambrica, tambienconocida como WLAN (del ingles wireless local area network). La tecnologıa de este tipode redes esta definida por la IEEE y queda recogida en la norma 802.11.

1.1. Objetivo del proyecto

El objetivo del presente proyecto fin de carrera es detectar y corregir las debilidades delmodelado del modulo Wi-Fi de ns-3 que hacen que el comportamiento de la simulacionessea erroneo bajo la norma 802.11n. Se han abordado las debilidades que aun no han sidodetectadas por la comunidad de desarrolladores de ns-3. Las debilidades objetivo han sidocorregidas bajo el prisma del estudio del comportamiento de los algoritmos de seleccionde tasa de datos bajo la norma 802.11n.

Tres han sido las principales debilidades a corregir: dispositivos operando con los esquemasde modulacion y codificacion (MCS) de la norma 802.11n, deteccion de las senales segunel modo de transmision con la que son emitidas y gestion de asociaciones entre APs ySTAs en el caso de una de-asociacion.

Ademas del modelado, el proyecto tambien aporta todos los escenarios en los que estos hansido probados. En la construccion de estos escenarios se ha empleado parte del esfuerzode este proyecto para poder tener un marco fiable de recogida de estadısticas, ademas deun correcto uso de los modelos de ns-3.

1.2. Planificacion

El estudio y desarrollo del modelado de una tecnologıa requiere de unos profundosconocimientos tanto de la tecnologıa en cuestion como de sus diferentes variantes o normas.Varios son los ambitos que han de ser dominados por toda persona que se embarque porprimera vez en un proyecto de estas caracterısticas.



La preparacion comienza con el estudio de las redes de area local inalambrica. Los cono-cimientos adquiridos durante la carrera deben ser complementados con los conocimientosespecıficos de esta tecnologıa en las capas del modelo OSI que se van a tratar. Este cono-cimiento esta recogido en las diferentes normas creadas por la IEEE.

Por otra parte se debe dedicar un tiempo considerable a la familiarizacion con la herra-mienta de trabajo. En este proyecto, la herramienta es un simulador de eventos discretosde redes. La familiarizacion con este software engloba la instalacion, la lectura de tuto-riales, la preparacion del entorno de trabajo y la especializacion en el bloque de interes.

Una vez adquirido el conocimiento necesario, se pasa a hacer un analisis exhaustivo delcomportamiento actual del modelado. Durante ese analisis se manifiestan diferentes de-bilidades o errores de modelado que hacen que el modelo no se comporte acorde a loestablecido por la norma. De esos errores se seleccionan los mas relevantes, y una vezseleccionados, se pasa a descubrir cual es el origen de los mismos.

Conocido el origen del problema se pasa a disenar una correccion que tenga un pequenoimpacto en el esqueleto del modelado actual, pero que solucione de manera efectiva elcomportamiento erroneo. El siguiente paso por tanto sera codificar dicha correccion ycomprobar que el nuevo modelado se comporta acorde al diseno. En caso de que el com-portamiento no sea el deseado, se replanteara el diseno de la correccion o la codificacionde la misma, segun sea el caso. El diseno de la correccion y la codificacion de la mismadeben ser verificadas de tal manera que se eliminen comportamientos transitorios. Tam-bien se eliminara la dependencia con las variables aleatorias del modelado a traves de larealizacion de baterıas de simulaciones con diferentes semillas.

El coste de este proyecto viene dado por todo aquello que supondrıa una inversion si elproyecto se hubiera realizado fuera del ambito academico. Es decir: 900 horas de trabajode un ingeniero junior mas el coste de la adquisicion de un ordenador de gama media-alta.El gasto en software es cero puesto que se ha trabajado con software de libre distribucion:ns-3 y el sistema operativo Fedora 20.



2. Antecedentes

Este capıtulo recoge el conocimiento necesario para una correcta comprension de lamateria que se trata en este documento. Para empezar se hace una revision historica delas normas que regulan el funcionamiento de las redes de area local inalambrica. Despues,se hace un analisis mas exhaustivo de la norma 802.11n, por ser la norma con la que setrabaja en este proyecto.

Parte importante es tambien el simulador de red utilizado, ns-3. En la seccion corres-pondiente de este capıtulo se encuentra tanto la informacion general del software comolos detalles de como esta organizado. Tras la vision general del simulador, se estudia elmodulo que modela el funcionamiento de los dispositivos que operan en redes inalambricasbajo la norma 802.11.

2.1. Wi-Fi 802.11

[1]En 1999 el grupo de empresas formado por 3Com, Airones, Intersil, Lucent Techno-logies, Nokia y Symbol Technologies detectaron la necesidad de establecer un mecanismode conexion inalambrica que fuese compatible entre distintos dispositivos. De esta manera,estas empresas conformaron la Wireless Ethernet Compatibility Alliance, o WECA, ac-tualmente llamada Wi-Fi Alliance. Tenıan como objetivo crear una marca que fomentarael sencillo uso de la tecnologıa inalambrica asegurando a su vez la compatibilidad entreequipos mediante la definicion de los dos niveles inferiores de la arquitectura OSI.

El termino Wi-Fi no responde a ninguna abreviatura, es una simple invencion de unaagencia que a peticion de la WECA creo este termino para sustituir al del nombre de latecnologıa: IEEE 802.11b de Secuencia Directa.

Como concepto general, la norma IEE 802.11 define los dos niveles inferiores de la ar-quitectura OSI (el fısico y de enlace) de las redes inalambricas. Es decir, define como seutilizara el canal fısico (aire) a traves del cual enviamos y recibimos nuestra informacion,y los protocolos utilizados para ello.

2.1.1. Historia/Evolucion

Legacy

La norma original IEEE 802.11 de 1997 (conocido como “legacy”), especificaba dostasas de transmision de 1 y 2 Mbit/s sobre infrarrojos (IR) o sobre radiofrecuencia en labanda ISM de 2,4 GHz. Aunque la transmision por infrarrojos sigue incluida en la norma



no hay en el mercado productos que la utilicen. Permite usar codificacion DSSS (DirectSequence Spread Spectrum) o FHSS (Frequency Hopping Spread Spectrum).

802.11a

La revision 802.11a a la norma original fue ratificada en 1999 y funciona en la bandade 5GHz utilizando 52 subportadoras OFDM (Orthogonal Frequency-Division Multiple-xing). 802.11a tiene una velocidad teorica maxima de 54 Mbit/s, con velocidades realesde aproximadamente 20 Mbit/s. La velocidad de datos se reduce a 48, 36, 24, 18, 12, 9 o6 Mbit/s en caso necesario. 802.11a tiene 12 canales no solapados, 8 para red inalambricay 4 para conexiones punto a punto. Los equipos 802.11a y 802.11b no pueden operarentre ellos. Los primeros productos con soporte para la norma 802.11a aparecieron en elmercado en 2001.

802.11b

La revision 802.11b de la norma original fue ratificada en 1999 y funciona en la bandade 2.4GHz. Fue la primera revision que tuvo una amplia aceptacion en el mercado. 802.11btiene una velocidad teorica maxima de transmision de 11 Mbit/s, pero debido al espacioocupado por la codificacion del protocolo CSMA/CA, en la practica la velocidad maximade transmision es de aproximadamente 5.9 Mbit/s para TCP y 7.1 Mbit/s para UDP.

Los dispositivos 802.11b deben mantener la compatibilidad con la norma original IEEE802.11 (utilizando DSSS). Aunque tambien utiliza una tecnica de ensanchado de espectrobasada en DSSS, en realidad la extension 802.11b introduce CCK (Complementary CodeKeying) para llegar a velocidades de 5,5 y 11 Mbit/s (tasa de bit en capa fısica). La normatambien admite el uso de PBCC (Packet Binary Convolutional Coding) como opcional.

802.11g

La revision 802.11g es la evolucion de la norma 802.11b y fue ratificada en Junio de2003. Es compatible con la norma b y utiliza las mismas frecuencias (2.4GHz) aunquecon una velocidad teorica maxima de transmision de 54 Mbit/s. La velocidad real detransferencia es de aproximadamente 22 Mbit/s, similar a la de la norma 802.11a.



En redes bajo la norma g la presencia de nodos bajo la norma b reduce significativamentela velocidad de transmision. Los equipos que trabajan bajo la norma 802.11g llegaron almercado muy rapidamente, incluso antes de su ratificacion oficial. Esto se debio en partea que para construir equipos bajo esta nueva norma se podıan adaptar los ya disenadospara la norma b. A partir de 2005, la mayorıa de los productos que se comercializan siguenla revision 802.11g con compatibilidad hacia 802.11b.

802.11n

En enero de 2004, el IEEE anuncio la formacion de un grupo de trabajo 802.11 paradesarrollar una nueva revision la norma 802.11. La velocidad real de transmision podrıallegar a los 300 Mbit/s (lo que significa que las velocidades teoricas de transmision serıanaun mayores), y deberıa ser hasta 10 veces mas rapida que una red bajo las normas802.11a y 802.11g, y unas 40 veces mas rapida que una red bajo la norma 802.11b.Tambien se espera que el alcance de operacion de las redes sea mayor con esta nueva normagracias a la tecnologıa MIMO Multiple Input Multiple Output, que permite utilizar varioscanales a la vez para enviar y recibir datos gracias a la incorporacion de varias antenas.Existen tambien otras propuestas alternativas que podran ser consideradas. La norma yaesta redactada, y se viene implantando desde 2008. A principios de 2007 se aprobo elsegundo boceto de la norma. Ha sufrido una serie de retrasos y el ultimo lo lleva hastanoviembre de 2009.

Protocolo802.11

LanzamientoFrecuencia

(GHz)

Ancho debanda(MHz)

Tasa de datospor flujo(Mbit/s)

FlujosMIMO

permitidosModulacion

legacy Junio 1997 2.4 20 1, 2 1 DSSS, FHSSS

aSeptiembre

20095 20

6, 9, 12, 18,24, 36, 48, 54

1 OFDM

bSeptiembre

20092.4 20 1, 2, 5.5, 11 1 DSSS

g Junio 2003 2.4 206, 9, 12, 18,

24, 36, 48, 541 OFDM, DSSS

n Octubre 2009 2.4/5

207.2, 14.4, 21.7,

28.9, 43.3,57.8, 65, 72.2

4 OFDM

4015, 30, 45,60, 90, 120,

135, 150

Tabla 2.1: Comparativa normas 802.11

A diferencia de las otras versiones de Wi-Fi, 802.11n puede trabajar en dos bandas defrecuencias: 2,4 GHz (la que emplean 802.11b y 802.11g) y 5 GHz (la que usa 802.11a).Gracias a ello, 802.11n es compatible con dispositivos basados en todas las edicionesanteriores de Wi-Fi. Ademas, es util que trabaje en la banda de 5 GHz, ya que esta menoscongestionada y en 802.11n permite alcanzar un mayor rendimiento.

802.11n se basa en las normas anteriores, pero hace uso de tecnologıa MIMO (MultipleInput, Multiple Output) para emplear mas de un canal a la vez. De este modo el equiporeceptor puede, por ejemplo, percibir las senales que llegan reflejadas (y por tanto con un



poco de retardo). Ademas, hace uso de channel bonding, una caracterıstica que incrementael ancho de banda de cada canal a 40MHz. Y, como ya sabemos, a mayor ancho de banda,mayor capacidad de transmision de datos. Se ampliaran los detalles tecnicos de esta normaen el siguiente apartado debido a que es la norma usada para este proyecto. Se conoce quela futura norma sustituta de 802.11n sera 802.11ac con tasas de transferencia superioresa 1 Gbit/s.

802.11ac

Norma de conexion Wi-Fi en desarrollo, con notables mejorıas respecto a 802.11n, secalcula que sea de uso comun en 2016. Se utiliza parte de las normas 802.11a y n. Puedesuministrar una velocidad de transmision de mas de 1 Gbit/s en la banda de 5 GHz. Seutiliza canales extendidos de 80 o 160 MHz, el doble o el cuadruple que en n. UtilizaMIMO multi-usuario con 5 a 8 secuencias espaciales, con la modulacion 256-QAM, elcuadruple que en n.

2.1.2. 802.11n

Como ya se ha comentado, dentro de las normas mas extendidas en el mercado,esta revision es la mas avanzada tecnologicamente. Es por esto que a continuacion sedescribiran los mecanismos tecnologicos que le diferencian de sus normas predecesoras.

En la ultima publicacion de la norma 802.11n [2] se recogen los detalles tecnologicos dela misma, detallando cuales son necesarios y optativos segun la capa del modelo OSI. Detodos estos avances que incluye la norma 802.11n nos detendremos en los que mayor pesohan tenido en este proyecto fin de carrera.

Intervalo de guarda (Guard Interval, GI)

El intervalo de guarda es un perıodo de tiempo entre sımbolos OFDM que se utilizapara preparar al sistema ante la llegada tardıa de sımbolos a traves de caminos largos.En escenarios multitrayecto los sımbolos viajan por diferentes caminos. El hecho de quelas senales recorran distancias diferentes hace que dos simbolos emitidos en distintosinstantes de tiempo puedan interferir entre sı al llegar al receptor. Este efecto se conocecomo interferencia entre sımbolos (ISI).

Aunque no es una regla en el sentido legal, una buena regla usada por los disenadoresOFDM es que el intervalo de guarda debe ser igual a 4 veces el maximo retraso deexpansion multitrayecto (multipath delay spread), siendo este la diferencia de tiempoentre varios caminos de una misma senal. Cuando 802.11a fue disenado, los disenadoresusaron un valor conservador de 200 ns para el retraso de expansion, y siguiendo la reglaanterior fijaron el GI a 800 ns. Despues la experiencia ha demostrado que en la mayorıade entornos interiores casi nunca se llega a los 100 ns de retraso de expansion y a menudosuele estar comprendido entre los 50 y 75 ns. Por eso para conseguir un rendimientomayor del enlace radio, 802.11n incluye una opcion para intervalo de guarda corto, elcual se reduce a 400 ns. El exito del GI corto depende de la expansion multitrayecto. Engeneral, la interferencia multitrayecto es peor cuando hay importantes reflexiones debidoa metales.



El resto de parametros OFDM se quedan igual. La velocidad global se incrementa porquela parte del tiempo de sımbolo dedicada a la transmision de datos es todavıa de 3,2 µs,pero cada sımbolo es mas corto. La longitud total de cada sımbolo se reduce de 4 µs conel GI largo a 3,6 (3,2 µs + 0,4 µs) con el GI corto, reduciendo de esta forma la sobrecargade OFDM en un 10 %.

Esquema de modulacion y codificacion

En 802.11n las velocidades de datos estan ahora definidas por un esquema de modula-cion y codificacion (Modulation and Coding Scheme, MCS). En 802.11a/g, las velocidadesse definıan mediante la modulacion y estaban comprendidas entre los 6 y 54 Mbit/s. Sinembargo, en 802.11n las velocidades de datos dependen de varios factores: la modulacion,el numero de flujos espaciales, la anchura del canal, el intervalo de guarda y la tasa decodificacion. Cada MCS puede suponer una variacion del numero de flujos espaciales,la modulacion y la tasa de codificacion. Dentro de cada MCS hay distintas velocida-des en funcion del ancho de banda del canal y el intervalo de guarda. 802.11n define 77MCS diferentes. Los 32 primeros con modulacion igual y el resto con modulacion distin-ta. Actualmente, la mayorıa de los productos solamente soportan modulacion igual. Lamodulacion distinta es util cuando un flujo espacial esta mas danado que los demas. Lasmodulaciones usadas son BPSK, QPSK, 16-QAM y 64-QAM. En la tablas 1.2 se muestranlos primeros 8 MCS con sus diferentes parametros y las velocidades de datos permitidaspara cada MCS, para modulacion igual.

La operacion con un flujo (MCS 0-7) es obligatoria para todas las estaciones. La operacioncon 2 flujos (MCS 8-15) es obligatoria para puntos de acceso. La operacion con 3 y 4 flujos(MCS 16-31) es opcional para todos los dispositivos. Los AP con 3 flujos dominan sobrelos de 4. Al MCS 32 se le conoce como High Throughput Duplicate Mode. Este usa uncanal de 40 MHz y un unico flujo espacial a una tasa de 6 Mbit/s. Es un modo muyconservador para conseguir una alta fiabilidad. Normalmente se utiliza en redes de granescala. Los MCS del 33 al 76 se usan para modulacion distinta.

IndiceMCS

Flujosespaciales

Tipo demodulac.

Tasa decodific.

Tasa de datos (Mbit/s)Canal de 20 MHz Canal de 40 MHz

800ns GI 400ns GI 800ns GI 400ns GI0 1 BPSK 1/2 6.50 7.20 13.50 15.001 1 QPSK 1/2 13.00 14.40 27.00 30.002 1 QPSK 3/4 19.50 21.70 40.50 45.003 1 16-QAM 1/2 26.00 28.90 54.00 60.004 1 16-QAM 3/4 39.00 43.30 81.00 90.005 1 64-QAM 2/3 52.00 57.80 108.00 120.006 1 64-QAM 3/4 58.50 65.00 121.50 135.007 1 64-QAM 5/6 65.00 72.20 135.00 150.00

Tabla 2.2: Indices de esquemas de modulacion y codificacion



Espacio intertrama reducido (RIFS - Reduced Interframe Space)

Las funciones de acceso al canal basicas de 802.11 introducen espacios entre transmi-siones como un metodo para establecer el acceso al medio. La idea principal del metodode mediacion de espacio entre tramas, es que las transmisiones de alta prioridad, comoconfirmaciones, tengan un perıodo de espera menor. En las normas previas a la 802.11nel espacio entre tramas utilizado era el corto (short interframe space, SIFS).Ası, una con-firmacion puede ser transmitida despues de esperar solo un SIFS. De la misma manera,una trama CTS transmitida inmediatamente siguiendo a una trama RTS necesita esperarsolo un SIFS antes de acceder al medio.

Banda SIFS RIFS2.4 GHz 10 µs 2 µs5 GHz 16 µs 2 µs

Tabla 2.3: Espacio intertrama

802.11n define un nuevo espacio entre tramas, denominado reducido (Reduced InterframeSpace, RIFS) y su funcion es equivalente a la del SIFS. Sin embargo, es mas corto, comose muestra en la tabla 1.3. No define un nuevo nivel de prioridad. Su unico proposito esser usado en lugar de SIFS para aumenta la eficiencia. No esta disponible en dispositivos802.11a/b/g por lo que no puede ser usado por un dispositivo 802.11a/b/g.

La mayorıa de los dispositivos no transmiten usando RIFS porque la eficiencia que seconsigue es relativamente pequena. Sin embargo, todos los dispositivos con la certificacionWi-Fi n deben tener la habilidad de recibir tramas transmitidas despues de un RIFS.

Modos PLCP (PHY Layer Convergence Protocol)

Como en las anteriores capas fısicas de 802.11, la especificacion 802.11n define unatrama de capa fısica usando PLCP. En 802.11n PLCP soporta 3 modos diferentes:

Modo No-HT

Todos los dispositivos tienen que soportar este modo, el cual permite la compatibi-lidad con dispositivos 802.11a/b/g. Ninguna funcionalidad de 802.11n esta disponibleen este modo. El formato de trama para este modo es exactamente igual que el de802.11a o 802.11g. Alguna documentacion se refiere a el como modo legado (legacymode), porque opera acorde con las mismas reglas que las especificaciones anteriores.

Modo HT mixto (HT-MM)

Este modo tambien debe ser soportado por todos los dispositivos 802.11n. Este solotiene compatibilidad con 802.11a/g, pero la parte de High Throuhput no puede serdecodificada por un dispositivo 802.11a/g.

Modo greenfield (HT-GF)

Este ultimo modo no es compatible con ninguna otra version de 802.11, por ello esconveniente utilizarlo solamente en areas donde todos los dispositivos son compatibles



con 802.11n. El modo HT greenfield consigue un pequeno aumento en el rendimiento conrespecto al modo mixto, ya que la cabecera PLPC es 8 µs mas corta. No es obligatorioy no es muy frecuente su implementacion en dispositivos 802.11n.

2.2. Network Simulator 3

Mas conocido como ns-3, Network Simulator 3 es un simulador de redes basado eneventos discretos. ns-3 es software libre, acogido a la version 2 de la GNU General PublicLicense igual que su antecesor, el Network Simulator 2 (ns-2). ns-2 fue desarrollado enC++ y provee una interfaz de simulacion a traves de OTcl, una variante orientada aobjetos de Tcl. En ns-2 el usuario describe una topologıa de red por medio de scriptsOTcl, y luego el programa principal simula dicha topologıa utilizando los parametrosdefinidos.

www.nsnam.org

En el ano 2006, ns-3 nace como variantede ns-2, se decidio implementar una nuevaversion desde cero utilizando C++ comolenguaje unico para los modelos y la inter-faz de simulacion. La base del desarrollofue el paquete Yans (Yet Another NetworkSimulator[10]). Su uso esta destinado a las comunidades educativas e investigadoras, elproyecto se esfuerza por mantener un entorno abierto y accesible a los investigadores paracompartir y/o aportar su software. ns-3 no es compatible con su version anterior (ns-2),es un nuevo simulador. Ambos simuladores estan escritos en C++ pero ns-3 no admite lasAPIs de ns-2. Algunos modelos de ns-2 han sido portados a ns-3. Mientras ns-3 este enconstruccion, ns-2 sera mantenido buscando a su vez mecanismos de integracion entreambos.

ns-3 proporciona modelos para ver como trabajan y rinden las redes de paquetes dedatos. Tambien cuenta con un motor de simulacion para realizar diferentes simulacionesde experimentos. Una de las razones para utilizar ns-3 es la posibilidad de realizar estudiosde experimentos imposibles en un sistema real o de experimentos difıciles de ejecutar ensistemas reales. Es util tambien para hacer estudios del comportamiento de un sistemabajo un entorno controlado y reproducible. Por supuesto util tambien para aprender comofuncionan las redes, es una herramienta educativa muy recomendable.

Existen muchas herramientas para realizar estudios de simulacion de redes, a continuacionse presentan algunas de las caracterısticas que diferencia a ns-3 de otras herramientas:

ns-3 esta disenado como un conjunto de bibliotecas que pueden ser usadas conjunta-mente entre ellas, incluso con bibliotecas software externas. Algunas plataformas desimulacion proporcionan al usuario una unica interfaz grafica de usuario integradaen la que se ejecutan todas las tareas, ns-3 es mas modular en ese sentido. Muchasson las herramientas externas de analisis de datos, visualizacion y animacion quepueden ser usadas con ns-3. En cualquier caso, los usuarios deben estar preparadospara trabajar en un terminal y con las herramientas para desarrollo de software enC++ y/o Python.


www.nsnam.org


ns-3 se utiliza principalmente en sistemas Linux, aunque existe soporte para otrasplataformas como FreeBSD y Cygwin (para Windows), el soporte nativo para Win-dows Visual Studio se encuentra en proceso de desarrollo.

ns-3 no es un producto software oficialmente apoyado por ninguna empresa. Elsoporte de ns-3 se realiza a traves de la lista de correo de usuarios de ns-3 y delgrupo de usuarios creado en Google Groups.

En ns-3 el simulador esta escrito enteramente en C++ con enlaces Python opcionales.Por tanto, los scripts de simulacion pueden ser escritos en C++ o Python. Existen nuevosvisualizadores y animadores disponibles y bajo desarrollo. Tambien se pueden utilizarutilidades de analisis de trazas puesto que ns-3 es capaz de generar archivos pcap con lastrazas de los paquetes. ns-2 cuenta con un conjunto mas variado de modulos aportadosdebido a su larga historia. Sin embargo, ns-3 cuenta con modelos mas detallados en muchasde las areas mas populares en investigacion actualmente (incluye modulos detallados paraLTE y Wi-Fi). Otra potente utilidad es que toda la pila de red de Linux puede serencapsulada en un nodo de ns-3, se consigue a traves de un framework llamado DirectCode Execution (DCE). ns-3 incluye tambien un planificador en tiempo real que facilitalas simulaciones en bucle para interactuar con sistemas reales.

ns-3 es una biblioteca de C++ que proporciona un conjunto de modelos de simula-cion de red implementados como objetos C++ y envueltos con Python. Normalmente losusuarios usan estas bibliotecas escribiendo un aplicacion en C++ o Python que crea ejem-plares de un conjunto de modelos de simulacion para construir el escenario de simulaciondeseado, ejecutar el hilo principal y salir de el cuando se complete la simulacion.

STL - Standard Template Library(Biblioteca de plantillas normalizadas)

Figura 2.1: Arquitectura ns-3

La biblioteca ns-3 esta envuelta en Python gracias a la biblioteca pybindgen que delega elanalisis de las cabeceras ns-3 en C++ a gccxml y pygccxml para generar automaticamenteel correspondiente enlazado C++. Estos archivos C++ generados automaticamente soncompilados dentro del modulo python de ns-3 para permitir a los usuarios interactuar conel core y con los modelos de ns-3 en C++ a traves de scripts en python.


https://launchpad.net/pybindgen

http://www.gccxml.org/

http://www.language-binding.net/pygccxml/pygccxml.html


Los eventos de simulacion en ns-3 son simples llamadas a funciones que estan programadaspara ejecutarse en un tiempo de simulacion determinado. Cualquier funcion se puedeconvertir en un evento programado haciendo uso de las funciones callback o retrollamada.Estas funciones se usan mucho en el simulador para reducir las dependencias en tiempode compilacion entre los objetos de simulacion.

ns-3 cuenta con una potente API de bajo nivel que permite a los usuarios expertos hacerdistintas configuraciones de los objetos con una mayor flexibilidad. En lo alto de todoesto existe un conjunto de capas de “helpers” que ofrecen funciones sencillas con uncomportamiento razonable por defecto. Los usuarios pueden mezclar el uso de las APIssencillas de los helpers con las APIs mas complejas de la capas inferiores.

Los nodos de ns-3 siguen el modelo de la arquitectura de red de Linux, las interfaces yobjetos clave (sockets, dispositivos de red...) tambien estan modelados a semejanza de unequipo Linux. Esto facilita la reultilizacion de codigo y mejora el realismo de los modelos,tambien hace que el control de flujo del simulador sea mas sencillo al poderlo compararcon los sistemas reales.

El codigo fuente de ns-3 esta organizado en su mayorıa en el directorio src y puede serdescrito por el esquema de organizacion del software de ns-3 de la figura 2.2. El trabajo serealiza de capas inferiores a superiores, en general los modulos solo tienen dependenciasen modulos de capas inferiores.

Figura 2.2: Organizacion del software en ns-3

En el core del simulador se encuentran aquellos componentes que son comunes para todoslos modelos de protocolo, hardware y entorno. El core del simulador esta implementadoen src/core, otros objetos fundamentales en un simulador como los paquetes estan imple-mentados en src/network. Estos dos modulos estan destinados a conformar el nucleo deun simulador generico que puede ser usado por diferentes tipos de redes y no solo redesbasadas en internet. Ademas del nucleo de ns-3, existen dos modulos que complementanel nucleo con APIs basadas en C++. Los programas de ns-3 pueden acceder directamentea todas las APIs o pueden hacer uso de las APIs llamadas “helpers” que proporcionanun encapsulado de llamadas a APIs de mas bajo nivel. El hecho de que los programas



de ns-3 puedan escribirse usando dos APIs (por separado o de manera conjunta) es unaspecto fundamental del simulador.

Los nodos de ns-3 pueden contener una coleccion de objetos NetDevie, al igual que unequipo real tiene separadas las tarjetas de las interfaces Ethernet, Wi-Fi, Bluetooth, etc.Anadiendo objetos WifiNetDevice a los nodos, uno puede crear modelos infraestructurabasados en 802.11 y redes ad-hoc. Los objetos WifiNetDevice modelan un controlador deuna interfaz de red inalambrica basado en la norma 802.11 de la IEEE[2]. ns-3 proporcionamodelos para las siguientes funcionalidades de 802.11:

Distributed Coordination Function (DCF) basica de 802.11 para los modos infraes-tructura y ad-hoc.

Las capas fısicas de las versiones de la norma 802.11a, 802.11b y 802.11g.

Enhanced Distributed Channel Access (EDCA) basado en Quality of Service (QoS)y extensiones de encolado de 802.11e.

La capacidad de utilizar diferentes modelos de perdidas de propagacion y retrasopor propagacion.

Diversos algoritmos de control de la tasa entre los que se incluyen Aarf[11], Arf[12],Cara[13], Onoe, Rraa[14], ConstantRate y Minstrel.

Redes mesh, norma 802.11s.

El conjunto de modelos 802.11 proporcionados en ns-3 pretende una implementacion fielde la capa MAC especificada en 802.11 y pretende tambien proporcionar un modelo de lacapa PHY de la norma 802.11a. En ns-3, los nodos pueden tener diferentes WifiNetDeviceen canales separados, pudiendo coexistir con otro tipo de dispositivos, eliminando ası unalimitacion de la arquitectura de ns-2. El codigo fuente del WifiNetDevice se encuentra enel directorio src/wifi.

La implementacion es modular y ofrece cuatro niveles de modelos:

Modelos de la capa PHY.

Los llamados modelos MacLow que implementan DCF y EDCAF.

Los llamados modelos ”MAC High“ que implementan la generacion de radiobalizas,sondeo y maquinas de estados de asociaciones del nivel MAC.

Un conjunto de algoritmos de control de tasa usados por los modelos MacLow.

A continuacion veremos alguna de estas capas mas en detalle.

Modelos ”MAC High“

Hay tres grandes modelos de MAC que proveen los tres elementos de una posible to-pologıa Wi-Fi; el punto de acceso o AP (ApWifiMac), la estacion no-AP o STA (StaWi-fiMac) y un STA en un conjunto basico independiente de servicios (IBSS, comunmenteconocido como red ad-hoc), (AdhocWifiMac).El modelo mas sencillo es el AdhocWifiMac, esta clase modela la capa MAC de un dispo-sitivo que no genera radiobalizas, ni realiza sondeos o asociaciones. La clase StaWifiMac


http://wireless.kernel.org/en/users/Drivers/madwifi

http://wireless.kernel.org/en/developers/Documentation/mac80211/RateControl/minstrel


implementa sondeo activo y una maquina de estados de asociacion que se encarga dehacer una reasociacion cada vez que muchas de las radiobalizas se pierden. Por ultimo,ApWifiMac modela un punto de acceso que periodicamente genera radiobalizas y queacepta todos los intentos de asociacion por parte de los STAs.Estos tres modelos ”MAC High“ comparten una misma clase padre, llamada Regu-larWifiMac. A traves de esta clase se puede configurar entre otras cosas el atributoQosSupported que permite la configuracion al estilo QoS 802.11e/WMM y el atributoHtSupported que permite el soporte de 802.11n High Throughput.

Figura 2.3: Arquitectura del modulo Wi-Fi

Capa MAC low

La capa MacLow esta dividida en tres componentes:

MacLow que se encarga de las transacciones de mensajes RTS/CTS/DATA/ACK.

DcfManager y DcfState que implementan las funciones DCF y EDCAF.

DcaTxop y EdcaTxopN que manejan la cola, la fragmentacion y retransmision depaquetes en caso de ser necesario. El objeto DcaTxop es utilizado en capas MACaltas que no tienen el QoS activo, tambien puede ser utilizado para transmitir ciertostipos de tramas. Por ejemplo, la norma dice que las tramas de gestion deben serenviadas accediendo al medio usando DCF. EdcaTxopN es utilizado en capas MAC



altas que tienen el QoS activo, ademas de realizar operaciones de QoS como laagregacion MSDU de 802.11n.

La modularidad proporcionada por la implementacion hace que la configuracion debajo nivel del WifiNetDevice sea potente aunque compleja. Por esta razon, ns-3 ofrecealgunas clases de ayuda para realizar operaciones comunes de manera sencilla y por otraparte aprovechar el sistema de atributos de ns-3 para permitir a los usuarios controlar laparametrizacion de los modelos subyacentes.

Conocidas las bases del modelado en ns-3, en el siguiente capıtulo se hace un analisis desus debilidades. Como ya se ha comentado, se ha puesto el foco en el modelado del moduloWi-Fi y mas en concreto en la implementacion de la norma 802.11n.



3. Analisis de debilidades

Con la ayuda del grupo de usuarios alojado en Google, la lista de distribucion decorreo de desarrolladores de ns-3 y el sistema de seguimiento de errores se realiza unestudio en profundidad de las debilidades reconocidas por la comunidad de usuarios ydesarrolladores de ns-3. Son numerosas las debilidades, pero las que afectan de maneradirecta al proposito de este proyecto estan enumeradas a continuacion:

La utilidad Direct Code Execution esta solo disponible para dispositivos cableados,no existe implementacion para dispositivos inalambricos.

No existe una implementacion solida de la tecnologıa MIMO, la propagacion multi-trayecto es el fenomeno fısico del que se vale esta tecnologıa para sacar provecho dela recepcion de diferentes versiones de una misma senal. ns-3 carece de un modelo depropagacion multitrayecto, lo que imposibilita que en una antena receptora lleguenvarias versiones de la misma senal.

No hay ningun modelo que compute las interferencias en el espectro en el que operanlas redes inalambricas. No se contempla que dos puntos de acceso cercanos operen encanales adyacentes, lo que derivarıa en interferencia mutua, peor relacion senal-ruidoy por tanto un peor rendimiento.

Los algoritmos existentes de adaptacion de la tasa han sido disenados para lasnormas previas a 802.11n. Estos algoritmos han sido probados para 802.11a/b/gpero no para 802.11, donde algunos de ellos producen incluso fallos de memoria.

Actualmente existe un plan de trabajo dentro de la comunidad de desarrolladores de ns-3para corregir estas debilidades. Por otra parte se han detectado deficiencias no registradas,se trata de deficiencias en el modelado de la norma 802.11n ası como en el funcionamientobasico de una conexion entre un cliente y un punto de acceso.

Debido a que las debilidades anteriormente enumeradas son conocidas, se decide corregirlas debilidades no registradas y cuyo origen es aun desconocido por los grupos de trabajode ns-3. En las secciones siguientes de este capıtulo se encuentra el analisis de estasdebilidades.


https://groups.google.com/forum/#!forum/ns-3-users

http://mailman.isi.edu/pipermail/ns-developers/

https://www.nsnam.org/bugzilla/


3.1. Dispositivos que operan en modos 802.11n

La norma 802.11n ha sido la ultima en ser modelada en ns-3 y su funcionamiento aunno ha sido probado en profundidad. El principal problema encontrado es la imposibilidadde configurar un dispositivo para que trabaje con los modos de operacion correspondientesa la norma 802.11n. Ademas el numero de bytes transmitidos correctamente es muy bajoen el caso de que un dispositivo configurado para la norma 802.11n quiera transmitirutilizando modos compatibles con normas anteriores.

ns-3 permite instalar en cada nodo una o varias interfaces de red, esta debilidad se ma-nifiesta en un escenario compuesto por dos nodos; uno de ellos con la interfaz de redcorrespondiente a un punto de acceso y el otro con la interfaz correspondiente a una es-tacion o STA. Los detalles especıficos para la construccion del escenario bajo la norma802.11n se pueden consultar en el anexo A.1.

En las ejecuciones del escenario descrito se observa como el numero de bytes transmitidoses de un orden de magnitud no esperado. En simulaciones de 5 segundos el numero debytes recibidos satisfactoriamente en la capa MAC del STA es de un 1 kB. Esto pone demanifiesto que algo no funciona correctamente.

Un exhaustivo analisis del problema descubre que los modos de transmision DSSS (Direct-Sequence Spread Spectrum) no son compatibles con la configuracion HT de la capa MAC.Para confirmar esto se ha forzado el modo de transmision a un valor constante para todala simulacion. A traves de la clase ConstantRateWifiManager se puede mantenerconstante el modo de transmision al que se transmiten los datos:

WifiHelper wifi = WifiHelper::Default ();wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",

"DataMode",StringValue ("OfdmRate6_5MbpsBW20MHz"));

El modo de transmision elegido es el correspondiente al ındice MCS 0 para intervalo deguarda largo y ancho de canal de 20 MHz de la tabla 2.2.

Tras la simulacion con la nueva configuracion los valores correspondientes a los bytesrecibidos superan los 6000 kB. Se hacen varias ejecuciones con los distintos modos detransmision que soporta ns-3 y que no son DSSS. Los resultados confirman que los modosde transmision DSSS no son soportados bajo la configuracion HT de la capa MAC.

La raız del problema es el error del simulador al trabajar con los modos de transmisionque no son OFDM con la capa MAC configurada para HT.

3.2. Sensibilidad de recepcion de senal para modula-

ciones OFDM de 802.11n

El modelado de ns-3 cuenta con un umbral mınimo para la deteccion de senales enel receptor. Se trata del atributo privado m edThresholdW de la clase YansWifiPhy.Este atributo solo se emplea en un sitio, dentro del metodo StartReceivePacket,para tirar los paquetes cuya potencia de senal en el receptor sea menor que el valor delumbral guardado en m edThresholdW. Por defecto este umbral vale -96 dBm.



Se detecta que este es el unico umbral existente para discernir si la potencia de la senalrecibida es suficiente para recibir correctamente el paquete o no. En este caso no se tratade un modelado erroneo, sino de una carencia del mismo. El modelado si contempla cualdebe ser la potencia mınima de una senal para ser detectada en el receptor, pero noimplementa cual debe ser el valor mınimo de la potencia de dicha senal para que seademodulada correctamente.

3.3. Gestion de asociaciones entre APs y STAs

El modelado que hace ns-3 de la perdida de conexion entre un punto de acceso y unaestacion esta incompleto. El modelado no cuenta con ningun mecanismo que contemplela perdida de conexion por el excesivo aumento de la distancia que separa a un clientedel punto de acceso al que esta conectado. Esta deficiencia del modelado se detecta enel contexto del trabajo con la distancia lımite a la que puede estar el cliente para poderdemodular las senales correspondientes a los ındices MCS.

Con el objetivo de sobrepasar cada una de estas distancias lımites, se configura en el clienteun patron de movimiento por el cual, partiendo de la posicion del punto de acceso al queesta conectado, se desplaza en lınea recta a una velocidad constante (1 m/s). A medidaque el cliente se va alejando del punto de acceso, los ındices MCS utilizados van siendomenores hasta alcanzar la distancia lımite por la que ni siquiera el ındice MCS 0 puedeser recibido correctamente. Este es el momento en el que el cliente pierde conexion con elpunto de acceso, cuando el cliente deja de recibir los paquetes de gestion correspondientesa las radiobalizas.

Es en este caso en el que se manifiesta el error, se observa como el punto de acceso a pesarde que el cliente ha perdido conexion, continua enviandole paquetes correspondientes altrafico configurado en el escenario. Los paquetes enviados al cliente por el punto de accesotras la perdida de conexion son recopilados en las estadısticas como paquetes tirados porsenal insuficiente como para ser recibidos.

El error se considera de importancia porque afecta directamente al estudio de los algo-ritmos de adaptacion de la tasa. Dos son los principales transtornos que produce en losescenarios de estudio de estos algoritmos:

El punto de acceso tiene una carga de trabajo inutil que puede provocar retrasos ala hora de servir paquetes a otros clientes conectados al mismo.

Quedan falseadas las estadısticas de paquetes tirados. En el estudio de un algoritmode seleccion de tasa lo que interesa es conocer los paquetes tirados durante loscambios de tasa de transmision y no ver ese apartado engordado por el hecho deque un cliente haya perdido conexion con el punto de acceso.



4. Modelado del modulo Wi-Fi

Para cumplir con los objetivos descritos, se ha de actuar sobre el modulo Wi-Fi dens-3 para que el modelado de los dispositivos 802.11n sea el correcto. En este capıtulose desgrana como se ha llevado a cabo este modelado a traves de los apartados “Analisisde la solucion adoptada”, “Modelado de la solucion” y “Simulaciones de verificacion”.La descripcion y verificacion del modelado aportado se divide en tres secciones: en laprimera se demuestra como se ha conseguido que los dispositivos 802.11n se comuniquenutilizando modos de transmision especıficos de la norma; en la segunda seccion se explicala introduccion de un umbral de sensibilidad de recepcion de senal para modulacionesOFDM de 802.11n; y en la ultima seccion de este capıtulo se puede ver como se hamodelado la gestion de asociaciones entre APs y STAs para unos casos concretos.

4.1. Dispositivos que operan en modos 802.11n

El modelado actual que hace ns-3 de dispositivos configurados para trabajar bajo lanorma 802.11n no permite que dos dispositivos configurados para 802.11n se comuniquencon modos de operacion especıficos de dicha norma. El objetivo en este apartado es corregireste modelado con el fin de establecer un intercambio de paquetes entre dos nodos. Estosdos nodos deberan trabajar con cualquiera de los modos de operacion de la norma 802.11nrecogidos en la tabla 2.2.

Como se ha comentado anteriormente, no se consigue comunicacion entre dispositivos802.11n, la raız del problema es el error del simulador al trabajar con los modos de trans-mision que no son OFDM con la capa MAC configurada para HT. Puesto que el objetivoque se busca es conseguir operar con los ındices MCS y con las novedades tecnologicas queofrece la norma 802.11n, se descarta abordar la correccion de este error. El enfoque de lasolucion esta puesto en conseguir comunicacion utilizando modos de transmision especıfi-cos de la norma 802.11n y evitar que los dispositivos operen bajo modos de transmisionno OFDM.

4.1.1. Analisis de la solucion adoptada

La solucion que se ha escogido es limitar el uso de los modos de transmision no OFDMa los dispositivos configurados para trabajar bajo la norma 802.11n. La eleccion de estasolucion esta motivada por diferentes artıculos que explican como los modos de transmi-sion no OFDM, obligatorios por compatibilidad con las primeras normas 802.11, hacenque el rendimiento de las redes inalambricas caiga por el ineficiente uso del espectro ra-dioelectrico. Como representante de los artıculos que hablan de este hecho, se cita una



presentacion de Cisco [15] en la que se enumeran los motivos por los que explican a laIEEE las desventajas actuales de usar modos de transmision que no son OFDM.

A modo resumen se enumeran los argumentos mas extendidos para evitar el uso de modosde transmision no OFDM:

Las tasas de transmision DSSS de 1 y 2 Mbit/s son mucho mas lentas que las tasasde transmision mas bajas de los modos OFDM. Esto deriva en un mayor tiempo deocupacion del canal lo que hace que el porcentaje de exito de acceso al canal porparte de otros dispositivos sea menor.

Estos modos de transmision introducen cabeceras de mayor tamano ademas detiempos de preambulo y ranura mas elevados. Esto provoca un menor rendimientode la red debido a que son menores los datos efectivos que viajan en cada trama.

Para que puedan ser usados simultaneamente modos de transmision OFDM conmodos no OFDM, se necesitan mecanismos adicionales de proteccion de colisiones.Estos mecanismos contribuyen tambien a que la cantidad de datos efectivos enviadospor unidad de tiempo sea menor.

El numero de dispositivos en el mundo que solo soportan modos de transmision noOFDM es despreciable a dıa de hoy. Esto hace que el desactivar estos modos detransmision no haga imposible la conexion para la gran mayorıa de dispositivos.

Estos argumentos han llegado a los grupos de trabajo de la IEEE, que se estan planteandoel pasar los modos de transmision no OFDM de obligatorios a opcionales para las normasmas recientes.

4.1.2. Modelado de la solucion

La correccion del modelado esta basada en el conocimiento que se ha adquirido dela gestion de los modos de transmision en ns-3, este conocimiento queda recogido en elanexo A.2.

Para respetar el desarrollo del proyecto ns-3 se han condicionado las modificaciones delmodelado a la activacion del modo Greenfield de la norma 802.11n. Este modo no escompatible con ninguna otra version de 802.11 y su uso esta restringido a redes dondetodos los dispositivos son compatibles con la norma 802.11n. Modela perfectamente elcontexto deseado, una red donde no existen dispositivos con soporte unico de modos detransmision no OFMD. Para activar este modo en la capa PHY, lo unico que hay que haceren el escenario es activar el parametro correspondiente de la clase YansWifiPhyHelper:

YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();wifiPhy.Set ("GreenfieldEnabled", BooleanValue(true));

La activacion de este modo no afecta de ningun manera al modelado, dado que unicamen-te esta creada la bandera. Esta bandera no se utiliza para modelar las caracterısticas delmodo Greenfield, puesto que esta es una caracterıstica sin desarrollar en ns-3. A conti-nuacion se explican los cambios realizados en el modelado de ns-3 para llevar a cabo estacorreccion.



Se modifica el valor que se le da al modo de transmision por defecto. Se ha configurado elmodo por defecto para que tome el valor del primer ındice MCS del conjunto de modosde transmision devuelto por el metodo GetMembershipSelectorModes de la claseWifiRemoteStationManager.

En esta misma clase se encuentra el metodo GetSupported, este es el metodo queutilizan las clases que modelan los algoritmos de seleccion de la tasa de transmision enns-3 para saber que modo de transmision le corresponde al ındice que se le pasa comoparametro. Este ındice lo utilizan estos algoritmos para recorrer los modos de transmisiondisponibles, los modos de transmision estan siempre ordenados de menor a mayor tasa detransmision. Esta lista de modos de transmision debe ser cambiante segun esten configu-rados los parametros de la capa PHY. Los parametros configurables para la capa PHY enns-3 son el intervalo de guarda y el ancho del canal, estos parametros se configuran en elescenario a traves de las siguientes sentencias:

wifiPhy.Set ("ShortGuardEnabled", BooleanValue(false));wifiPhy.Set ("ChannelBonding", BooleanValue(false));

Si ShortGuardEnabled esta a false, se configura el intervalo de guarda como largo(800 ns) mientras que si esta a true el intervalo de guarda sera corto (400 ns). El ancho debanda del canal es de 20 MHz si el parametro ChannelBonding se configura a falsey de 40 MHz si se configura a true. Estas dos variables junto con el ındice MCS elegidopor el algoritmo de seleccion de tasa, determinan la tasa a la que se transmiten los datos.Recordar que estas tasas pueden ser consultadas en todo momento en la tabla 2.2.

GetSupported no tiene en cuenta estos parametros a la hora de devolver el modo detransmision al que se va a transmitir. Para corregir el modelado lo que se ha hecho esutilizar un metodo ya existente pero infrautilizado, se trata del metodo McsToWifiModede la clase YansWifiPhy. Este metodo recibe como parametro el ındice MCS y devuel-ve el modo de transmision correspondiente teniendo en cuenta la configuracion de losparametros ShortGuardEnabled y ChannelBonding.

Estas correcciones realizadas en el archivo wifi-remote-station-manager.cc que-dan reflejadas en el anexo C, parche C.1.

Otra parte fundamental del modelado a corregir es la negociacion previa al estableci-miento de una asociacion entre un punto de acceso y una estacion. Los puntos de accesodifunden periodicamente radiobalizas, que son tramas de gestion en las que viaja infor-macion relativa a los parametros y capacidades del punto de acceso. Las estaciones porsu parte, difunden una peticion de sondeo para descubrir las redes 802.11 cercanas. Estees el punto de partida del proceso de asociacion de una estacion a un punto de acceso,que resumimos a continuacion (se han omitido los detalles del proceso de autenticacionpor no ser utilizado en el modelado que nos ocupa):

1. En la peticion de sondeo viajan las tasas de datos y las capacidades que la estacionsoporta. Esta peticion es enviada en difusion y por tanto todos los puntos de accesoque la reciban responderan.

2. Cuando un punto de acceso recibe una peticion de sondeo, comprueba que al menosuna de las tasas de datos de la estacion sea soportada por dicho punto de acceso. Siambos tienen tasas de datos compatibles, el punto de acceso mandara una respuesta



de sondeo donde viaja el SSID (nombre de la red inalambrica), las tasas de datosque soporta, los tipos de encriptacion (si es necesario) y otras capacidades del puntode acceso.

3. De todas las respuestas de sondeo recibidas la estacion elegira las redes compati-bles. Una vez que las redes compatibles han sido descubiertas, la estacion intercam-biara mensajes de autenticacion con el punto de acceso de una de esas redes.

4. Una vez que el proceso de autenticacion a finalizado con exito, la estacion envıa unapeticion de asociacion al punto de acceso. Esta peticion contiene de nuevo la mismainformacion que la peticion de sondeo ademas de los identificadores acordados en elproceso de autenticacion.

5. Si la informacion que llega en la peticion de asociacion concuerda con las capacidadesdel punto de acceso, este contestara con una respuesta de asociacion con un mensajede acceso satisfactorio para dar acceso a la red a la estacion.

Todo este proceso esta modelado en ns-3, exceptuando el proceso de autenticacion. Deeste proceso se corrige la parte que se encarga de difundir y comprobar las tasas de datossoportadas por los dispositivos que viajan en las tramas del proceso de asociacion. Estose modela en los archivos ap-wifi-mac.cc y sta-wifi-mac.cc, en ellos se modelala capa MAC de un punto de acceso y una estacion respectivamente.

En el archivo ap-wifi-mac.cc se encuentra la clase ApWifiMac y sus metodos. Elmetodo GetSupportedRates debe ser modificado para que, en el caso de que el modoGreenfield este activado, la lista de modos de transmision devuelta sea la que devuelve elmetodo GetMembershipSelectorModes de la clase YansWifiPhy. Con esto, cadavez que se invoque al metodo GetSupportedRates en el proceso de asociacion, serandevueltas las tasas de transmision correspondientes a los ındices MCS de 0 a 7 paraintervalo de guarda largo y ancho de canal de 20 MHz. Por ultimo en este archivo, sedebe modificar tambien la parte que gestiona la recepcion de un mensaje de peticionde asociacion. Se tiene que comprobar si las tasas de datos soportadas por la estacionson soportadas tambien por el punto de acceso, para ello se recorre la lista de modos detransmision devuelta por el ya conocido metodo GetMembershipSelectorModes.

Estas correcciones realizadas en el archivo ap-wifi-mac.cc quedan reflejadas en elanexo C, parche C.2.

En el archivo sta-wifi-mac.cc se encuentra la clase StaWifiMac y sus metodos. Lamodificacion del metodo GetSupportedRates es identica a la explicada en el parrafoanterior puesto que el uso que se le da en esta clase es exactamente el mismo. Tambienexiste un paralelismo con la modificacion de la gestion de la recepcion de un mensaje depeticion de asociacion del parrafo anterior, la modificacion vuelve a ser la misma solo queen este caso enmarcada en la recepcion de un mensaje de respuesta de asociacion. Estascorrecciones realizadas en el archivo sta-wifi-mac.cc quedan reflejadas en el anexoC, parche C.3.

Estas han sido las modificaciones para hacer funcionar a los dispositivos en los modos detransmision OFDM de la norma 802.11n. Para demostrar que son efectivas, se necesitaequipar al escenario de funciones que recopilen estadısticas que demuestren que las modi-ficaciones consiguen su objetivo. En el modelado ademas de codigo para modelar sistemas,



tambien se incluye codigo para la recopilacion de estadısticas que ayuden a valorar si elmodelado es correcto o no. Es el caso de tres metodos de la clase WifiPhy:

NotifyRxBegin indica que un paquete esta siendo recibido.

NotifyRxEnd indica que el paquete ha sido recibido correctamente.

NotifyRxDrop indica que el paquete ha sido tirado debido a la tasa de error depaquete correspondiente a la modulacion utilizada.

Estos metodos te dan accesibilidad desde el escenario al paquete que se encuentra enproceso de recepcion. Para realizar la comprobaciones necesarias en esta correccion, esnecesario tener tambien el modo de transmision con el que se esta recibiendo dicho pa-quete para ver que las modificaciones logran que las transmisiones se hacen con los modosde transmision deseados. Partiendo de estos tres metodos se han creado otros tres meto-dos identicos (NotifyRxBeginMode, NotifyRxEndMode y NotifyRxDropMode),a estos tres metodos nuevos se les ha anadido la informacion del modo de transmision conel que se esta recibiendo el paquete. La creacion de estos metodos implica la modificacionde los archivos wifi-phy.cc y wifi-phy.h, estas modificaciones se pueden ver en elanexo C, parches C.4 y C.5.

Con los nuevos metodos de notificacion creados, queda colocarlos apropiadamente y darlesuso en el escenario. La localizacion elegida ha sido la misma que los metodos originales. Lainclusion de estos nuevos metodos queda recogida en el anexo C, parche C.6. El escenariocreado para verificar que las modificaciones que se han hecho cumplen su objetivo se puedeconsultar en el anexo B, escenario B.2. Destacar que para hacer uso en el escenario de losmetodos de notificacion creados se deben incluir las siguientes sentencias:

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/←↩PhyRxBeginMode", MakeCallback(&PhyRxBeginMode));

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/←↩PhyRxBeginMode", MakeCallback(&PhyRxEndMode));

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/←↩PhyRxBeginMode", MakeCallback(&PhyRxDropMode));

4.1.3. Simulaciones de verificacion

Para verificar el comportamiento deseado tras las modificaciones del modelado se hanrealizado baterıas de simulaciones con cuatro configuraciones diferentes del escenario. Es-tas cuatro configuraciones difieren en los valores que toman las banderas de tipo booleanode los parametros ShortGuardEnabled y ChannelBonding:

wifiPhy.Set ("ShortGuardEnabled", BooleanValue(sge));wifiPhy.Set ("ChannelBonding", BooleanValue(ch));

A traves de un script se realizan baterıas de simulaciones en las que las variables sge y chtoman valores true y false hasta contemplar las cuatro combinaciones posibles. Paracada una de estas cuatro configuraciones se han realizado 2 baterıas de 20 simulacionescada una. La primera baterıa para un tiempo de simulacion corto (5 segundos) y la segundapara un tiempo de simulacion largo (300 segundos). De cada baterıa de 20 simulaciones



se ha computado la media y la desviacion estandar de cada valor a juzgar para tener unavision fiable a la hora de valorar los resultados. En el script se contabilizan el numero depaquetes para cada caso, se han ignorado los paquetes correspondientes a asentimientospuesto que estos siempre son transmitidos usando el modo de transmision por defecto.

La verificacion comienza con la ejecucion de la simulacion del escenario con los dos parame-tros configurados a false. Lo que se espera es que se utilicen modos de transmision del0 al 7 para un ancho de canal de 20 MHz e intervalo de guarda largo. La baterıa de simu-laciones cortas arrojan que los 5835 paquetes transmitidos de media, se han transmitidocon modos de transmision para ancho de canal de 20 MHz e intervalo de guarda largo.Tambien podemos ver como han quedado distribuidos los ındices MCS utilizados.

ChannelBonding=false --ShortGuardEnabled=false --simtime=5

20_MHz 5835.70(12.71) 5835.30(12.64) 0.40(0.68)LGI 5835.70(12.71) 5835.30(12.64) 0.40(0.68)

40_MHz 0.00(0.00) 0.00(0.00) 0.00(0.00)SGI 0.00(0.00) 0.00(0.00) 0.00(0.00)

MCS Inicio Final Tirados

0 11.00(0.00) 11.00(0.00) 0.00(0.00)1 10.00(0.00) 10.00(0.00) 0.00(0.00)2 10.00(0.00) 10.00(0.00) 0.00(0.00)3 10.00(0.00) 10.00(0.00) 0.00(0.00)4 10.00(0.00) 10.00(0.00) 0.00(0.00)5 10.00(0.00) 10.00(0.00) 0.00(0.00)6 10.00(0.00) 10.00(0.00) 0.00(0.00)7 5713.70(12.71) 5713.30(12.64) 0.40(0.68)

No es momento de valorar la distribucion de los ındices MCS utilizados pero lo que sipodemos decir es que el algoritmo de seleccion de tasa no ha tenido ningun problema enir incrementando el ındice MCS con el que transmitir hasta alcanzar el ındice mas alto.De hecho para los ındices del 0 al 6 se observa un comportamiento muy estable puestoque la desviacion estandar es cero en todos los casos.

En la baterıa de simulaciones con tiempo de simulacion largo, se han transmitido correc-tamente 651453 paquetes, tambien con los modo de transmision deseados. No se observaninguna anomalıa en los resultados dado que son proporcionales a los obtenidos con tiem-po de simulacion corto, lo que hace indicar que el modelado es estable con tiempos desimulacion largos.

La siguiente simulacion se hace con el parametro ChannelBonding configurado a falsey ShortGuardEnabled a true. En media, el numero de paquetes transmitidos correc-tamente ha sido 6047 en 5 segundos, logicamente superior al de la simulacion anteriorpuesto que las tasas de los modos de transmision para esta configuracion son mayores quepara la configuracion anterior. Todos estos paquetes han sido transmitidos en modos detransmision para canal de 20 MHz. Sin embargo no han sido todos los paquetes trans-mitidos con intervalo de guarda corto, han sido 5997 de los 6047 paquetes transmitidos.Los 50 paquetes restantes han sido transmitidos con intervalo de guarda largo, estos 50paquetes son los correspondientes a los paquetes transmitidos en el modo por defecto, es



decir los paquetes que contienen tramas de gestion. Esto concuerda con nuestro modeladopuesto que el modo por defecto que se ha elegido es el correspondiente al ındice MCS 0para ancho de canal de 20 MHz e intervalo de guarda largo. La distribucion de los ındicesMCS utilizados es similar a la anterior:

ChannelBonding=false --ShortGuardEnabled=true --simtime=5

20_MHz 6047.65(13.61) 6047.25(13.56) 0.40(0.68)LGI 50.00(0.00) 50.00(0.00) 0.00(0.00)

40_MHz 0.00(0.00) 0.00(0.00) 0.00(0.00)SGI 5997.65(13.61) 5997.25(13.56) 0.40(0.68)


0 11.00(0.00) 11.00(0.00) 0.00(0.00)1 10.00(0.00) 10.00(0.00) 0.00(0.00)2 10.00(0.00) 10.00(0.00) 0.00(0.00)3 10.00(0.00) 10.00(0.00) 0.00(0.00)4 10.00(0.00) 10.00(0.00) 0.00(0.00)5 10.00(0.00) 10.00(0.00) 0.00(0.00)6 10.00(0.00) 10.00(0.00) 0.00(0.00)7 5925.65(13.61) 5925.25(13.56) 0.40(0.68)

La baterıa de simulaciones largas de este caso sigue confirmando que el comportamientodel modelado es estable. Para cada valor, la media y desviacion estandar son del ordende magnitud que se esperan. Se han transmitido correctamente 676329 paquetes, que aligual que para el tiempo de simulacion corto supera al del caso anterior.

La siguiente configuracion del escenario es en la que el parametro ChannelBondingesta configurado a true y el parametro ShortGuardEnabled a false. En principio,se deberıan de esperar mas paquetes puesto que las tasas de datos de los actuales modosde transmision son superiores a los de la configuracion del parrafo anterior. En este casoen 5 segundos de simulacion se han transmitido correctamente 5556 paquetes, se trata deun numero inferior al del caso anterior. De media, se han iniciado un mayor numero detransmisiones de paquetes (6360), pero 804 paquetes se han tirado en su recepcion debidoa la tasa de error de paquetes.

Vemos como a diferencia de los casos anteriores, nunca se alcanza el ındice MCS superior.Esto ocurre porque en el ındice MCS 6 no se logran transmitir correctamente 10 paquetesconsecutivos. Como vemos, aproximadamente, solo 1 de cada 7 paquetes se trasmitensatisfactoriamente. Que casi 6 de cada 7 paquetes sean tirados para el ındice MCS 6 sedebe a que la tasa de error de paquete es superior para modos de transmision con altastasas de datos. Estos paquetes pasan a ser retransmitidos, el numero de retransmisioneses un factor en el que se basan los algoritmos de seleccion de tasa para disminuir la tasaa la que se transmiten, lo que hace que los paquetes se pasen a transmitir con el ındiceMCS 5.



ChannelBonding=true --ShortGuardEnabled=false --simtime=5

20_MHz 50.00(0.00) 50.00(0.00) 0.00(0.00)LGI 6360.35(12.52) 5556.10(15.28) 804.25(10.23)

40_MHz 6310.35(12.52) 5506.10(15.28) 804.25(10.23)SGI 0.00(0.00) 0.00(0.00) 0.00(0.00)


0 11.00(0.00) 11.00(0.00) 0.00(0.00)1 10.00(0.00) 10.00(0.00) 0.00(0.00)2 10.00(0.00) 10.00(0.00) 0.00(0.00)3 10.00(0.00) 10.00(0.00) 0.00(0.00)4 105.00(32.69) 105.00(32.69) 0.00(0.00)5 5473.05(29.69) 5236.30(30.37) 236.75(10.05)6 690.30(24.60) 122.80(14.70) 567.50(11.66)7 0.00(0.00) 0.00(0.00) 0.00(0.00)

Para este caso, el ındice MCS 5 es al que converge el algoritmo de seleccion de tasa, enel se pueden dar 10 transmisiones exitosas consecutivas para subir al ındice superior, ovarias retransmisiones consecutivas que hagan bajar al ındice inferior. En el ındice MCS4 no se tira ningun paquete por lo que se vuelve al ındice MCS 5 sin problema.

De los 5556 paquetes recibidos de media, 5506 han sido para ancho de banda de 40 MHzy los 50 restantes transmitidos, como en escenarios anteriores, corresponden a paquetesen los que viajan tramas de gestion. Paquetes que como hemos dicho son transmitidoscon el modo de transmision por defecto.

En la baterıa con tiempo de simulacion larga se han alcanzado los 614036 paquetes reci-bidos correctamente. Al igual que con el tiempo de simulacion corto, este valor es inferioral del caso anterior para el mismo tiempo de simulacion. Tampoco se ha observado uncomportamiento inestable del modelado, los valores estadısticos se siguen manteniendo encotas razonables.

Por ultimo queda configurar ambos parametros a true. En media, el numero total depaquetes transmitidos es 5684, 50 de esos paquetes han vuelto a ser transmitidos enel modo por defecto (MCS 0, intervalo de guarda largo y canal de 20 MHz). Los 5634paquetes restantes se transmiten de con intervalo de guarda corto y ancho de canal de 40MHz. La distribucion de los ındices MCS para esta configuracion es la siguiente:



ChannelBonding=true --ShortGuardEnabled=true --simtime=5

20_MHz 50.00(0.00) 50.00(0.00) 0.00(0.00)LGI 50.00(0.00) 50.00(0.00) 0.00(0.00)

40_MHz 6461.60(18.97) 5634.45(24.81) 827.15(12.50)SGI 6461.60(18.97) 5634.45(24.81) 827.15(12.50)


0 11.00(0.00) 11.00(0.00) 0.00(0.00)1 10.00(0.00) 10.00(0.00) 0.00(0.00)2 10.00(0.00) 10.00(0.00) 0.00(0.00)3 10.00(0.00) 10.00(0.00) 0.00(0.00)4 112.50(36.11) 112.50(36.11) 0.00(0.00)5 5588.75(46.81) 5347.55(45.34) 241.20(10.74)6 718.35(31.96) 132.40(20.26) 585.95(13.13)7 0.00(0.00) 0.00(0.00) 0.00(0.00)

El comportamiento del algoritmo de seleccion de tasa vuelve a ser el mismo al descrito enel caso anterior. Se ha iniciado un mayor numero de transmisiones de paquetes en media(6511), a su vez el numero de paquetes con fallo de transmision tambien ha aumentado.Logico que en un mismo periodo de tiempo el numero de paquetes a transmitir haya sidomayor, ya que para este caso las tasas de transmision son mas altas.

629403 han sido los paquetes recibidos correctamente de media en la baterıa con tiempode simulacion largo. Con este ultimo caso se ha demostrado tambien estabilidad en elmodelado puesto que los valores obtenidos son proporcionales a los de la baterıa contiempo de simulacion corto.

A modo de resumen se presenta la siguiente tabla en la que podemos ver el numero depaquetes recibidos correctamente, junto con sus valores estadısticos, para cada baterıa desimulacion, se han ordenado de mayor a menor numero de paquetes con el objetivo de verclaramente cuales han sido los resultados de cada configuracion frente a las demas:

Tabla 4.1: Comparativa de paquetes recibidos correctamente

Vistos los datos arrojados por las simulaciones con el escenario de verificacion, podemosdecir que el modelado introducido en ns-3 consigue alcanzar el objetivo de este apartado:que los dispositivos puedan transmitir datos con los modos de transmision de la tabla2.2 segun la configuracion del ancho de banda del canal y de la longitud del intervalo deguarda.



Con estas simulaciones tambien hemos podido observar como un algoritmo de seleccionde tasa puede ser ineficiente. A pesar de disponer de tasas de datos mas elevadas paratransmitir, la mala gestion de las mismas puede hacer que el numero total de paquetesrecibidos correctamente sea inferior al que se recibirıan con ındices MCS con tasas detransmision inferiores.

4.2. Sensibilidad de recepcion de senal para modula-

ciones OFDM de 802.11n

En el apartado anterior se ha visto como la tasa de error de paquetes puede hacer quealgunos paquetes sean recibidos de manera erronea debido a que para una determinadamodulacion la senal no tiene suficiente energıa respecto al ruido. Cuanto mas sımbolostenga una modulacion mas alta sera la tasa de error de paquetes.

La demodulacion correcta de una senal en el receptor esta condicionada por el numerode sımbolos utilizados en su modulacion, por la tasa de codificacion y por la potenciade la senal recibida. Es decir, a cada par formado por una modulacion y una tasa decodificacion le corresponde un valor mınimo de potencia recibida. Este valor mınimode la potencia necesaria para demodular correctamente una senal es dependiente de lasespecificaciones del hardware, que otorga diferentes valores segun el ancho de banda delcanal. Lo denominaremos sensibilidad mınima de recepcion.

El objetivo de este apartado es implementar la sensibilidad mınima de recepcion en ns-3,o lo que es lo mismo modelar la corresponencia entre el valor mınimo de potencia recibiday el par formado por la modulacion y tasa de codificacion de una transmision.


Implementar una nueva caracterıstica dentro de un modelado requiere de un analisisprevio que determine cual debe ser la manera en el que el nuevo codigo se va a integrar enel codigo existente. En este caso la integracion de esta caracterıstica no requiere de unaimplementacion que afecte a varias capas del modelo OSI. Tampoco necesita que variosarchivos del codigo fuente sean modificados, por lo que el analisis se centra unicamenteen el emplazamiento que se le va a dar en el archivo donde se modela la recepcion de lospaquetes.

La eleccion del lugar en el que se decide si un paquete llega con una energıa suficientecomo para ser demodulado se ha hecho bajo criterios de simplicidad y bajo impactoen el modelado de ns-3. Es por esta razon que el sitio elegido es el mismo en el quelos desarrolladores han decidido poner el umbral de energıa ya existente. Lo que se hahecho es introducir la sensibilidad de recepcion de senal solo para paquetes que hayansido transmitidos en modos HT, ya que son los modos de transmision correspondientes almodelado de la norma 802.11n.

La implementacion de la solucion a esta carencia en el modelado de ns-3 esta funda-mentada en el conocimiento del proceso de recepcion de paquetes recogido en el anexoA.3.




La implementacion de esta caracterıstica solo necesita modificar los archivos de laclase YansWifiPhy. En el metodo StartReceivePacket comienza la recepcion deun paquete en la capa PHY de una interfaz de red. En el caso de que el estado de lacapa PHY sea ocioso, se comienza con la recepcion del paquete. En este punto se hacreado una variable local booleana en la que almacenar si la potencia de senal del paqueteque se esta recibiendo es superior al lımite que impone la modulacion con la que ha sidotransmitido. Esta variable se utiliza en el mismo bloque if que el del umbral existente.

Esta variable booleana se llama ofdmThreshold, si es igual a true indicara que elpaquete supera el umbral de potencia de senal que impone la modulacion con la que hasido transmitido, su valor sera false para el caso contrario. ofdmThreshold se iniciaa true para que, en el caso de que la modulacion con la que llega un paquete no seaalguna de las de la norma 802.11n, no se tire ningun paquete a causa de los umbralesintroducidos.

La variable ofdmThreshold va a guardar el valor devuelto por el metodo IsOfdm-Threshold de la clase YansWifiPhy. Este metodo recibe como parametros el modode transmision y la potencia con la que se esta recibiendo el paquete. Con esos dosparametros el metodo analiza el modo de transmision para determinar su ındice MCS yel ancho de banda del canal. Estos dos datos son los necesarios para determinar el valormınimo que debe de tener la potencia para que la senal pueda ser demodulada.

A este valor mınimo lo llamaremos sensibilidad de recepcion, y existe una sensibilidad dife-rente para cada par formado por ındice MCS (modulacion y tasa de codificacion) y anchode banda. Los valores de sensibilidad de recepcion forman parte de las especificacioneshardware del receptor de la interfaz de red de cualquier dispositivo. Por tanto estos valoresson dependientes del hardware, en este modelado se van a utilizar unos valores genericosobtenidos de un documento de investigacion de un fabricante de tecnologıas inalambricas[16]. Estos valores garantizan que el receptor es capaz de demodular correctamente unasenal a un mınimo nivel de potencia. La demodulacion correcta viene determinada poruna tasa de error de paquete menor del 10 %.

Tabla 4.2: Sensibilidad mınima de recepcion



El metodo IsOfdmThreshold utiliza estos valores para decidir si la potencia recibi-da es suficiente como para alcanzar la sensibilidad mınima correspondiente al modo detransmision. En caso de que no sea suficiente el metodo devuelve false, por contra si lapotencia recibida esta por encima del valor correspondiente, el metodo devuelve true.

A la clase YansWifiPhy se le ha dotado de un nuevo atributo para dar la posibilidad deconfigurar la sensibilidad mınima de recepcion desde el escenario de simulacion. De estamanera se podra bajar el nivel de sensibilidad de acuerdo con las especificaciones que sele quieran dar al dispositivo. Este parametro se llama m extraSensitivity y es utilpara ajustar los niveles de sensibilidad a los del modelado, es decir, configurar el nivel desensibilidad mınimo de acuerdo con el comportamiento del modelo de tasa de error quese este usando. Si se quieren anadir 5 dBm de sensibilidad extra al dispositivo, la tablavera sus valores modificados.

Ejemplo: m extraSensitivity = 5 dBm, MCS 0 y 20 MHz: -82 - 5 = -87 dBm.

Estas modificaciones realizadas en los archivos yans-wifi-phy.cc y yans-wifi-phy.h, se pueden ver en el anexo C, parches C.7 y C.8.

De la misma manera que se hizo en el apartado anterior, se han creado funciones denotificacion que ayuden tanto al desarrollo de la correccion del modelado como a la reco-pilacion de estadısticas. Estas funciones son muy similares a las anteriormente creadas ypor tanto se necesita de la modificacion de los archivos wifi-phy.cc y wifi-phy.h.Los parches C.9 y C.10 del anexo C, recogen la inclusion de estas funciones.


El escenario de simulacion creado para la verificacion del modelado de este apartadoes una adaptacion del escenario del apartado anterior. A continuacion se enumeran lasprincipales novedades de este escenario:

Un nuevo parametro de entrada llamado powerlimit. Este parametro se utilizapara calcular cual debe ser la distancia que separa al punto de acceso del clientepara que la potencia de senal recibida por el cliente sea la deseada. Este calcu-lo se hace en la funcion creada a tal efecto llamada powerToDist. Los datosque se utilizan para este calculo se extraen de los objetos del escenario: por unlado se extrae la potencia con la que se transmite la senal del emisor, a travesdel atributo m txPowerBaseDbm de la clase YansWifiPhy; y por otro se ex-traen los datos de propagacion del modelo de propagacion configurado por defecto,LogDistancePropagationLossModel (modelo aceptado para las perdidas porpropagacion en los ambientes tıpicos de las redes locales inalambricas).

ExtraSens: nuevo parametro de entrada que sirve para poder ejecutar simulacionescon una sensibilidad mayor a la de los valores base.

Se ha enriquecido la recopilacion de estadısticas con el uso de las funciones denotificacion creadas. Estas estadısticas aportan el nivel de detalle que se necesitapara verificar que las modificaciones introducidas cumplen con su objetivo.

El escenario resultante se puede consultar en el anexo B, escenario B.3.



Para realizar las diferentes simulaciones de verificacion se utiliza un script que realizabaterıas de 20 simulaciones para las diferentes configuraciones. Dos son las configuraciones,una para ancho de canal de 20 MHz y otra para ancho de 40 MHz. Para cada caso losvalores de sensibilidad son diferentes, ası que a cada ancho de canal le corresponde unalista de valores lımites. Los valores lımite no son mas que la potencia de senal que se desearecibir para ası comprobar que los lımites de sensibilidad se han modelado correctamente.

Dentro del script se da tambien la posibilidad de dotar al modelo con una mayor sensi-bilidad partiendo de los valores base. Logicamente este valor se anade tambien a la listade valores lımites para hacer las simulaciones a los niveles de potencia deseados en cadacaso. Para cada configuracion por tanto se realizan dos baterıas de 20 simulaciones cadauna, una baterıa de simulaciones para un tiempo de simulacion corto (20 segundos) y otrabaterıa con tiempo de simulacion largo (300 segundos) para una verificacion mas solida.A continuacion se analizan los resultados obtenidos de estas simulaciones.

Primero se realiza una ejecucion del script con los valores de sensibilidad base, es decir,con el parametro ExtraSens a cero. A priori no se sabe cual va a ser el comportamientodel modelo tras esta comprobacion previa al calculo de la tasa de error de paquete. Losdatos que arroja esta ejecucion es que el modelado esta funcionando a la perfeccion, peroque los valores de sensibilidad mınima son demasiado restrictivos puesto que nunca sellega a tirar ningun paquete debido a la tasa de error de paquete (ni siquiera con tiempode simulacion largo). Como muestra de lo que ocurre analizamos el resultado de unaconfiguracion concreta:

simtime=300 ch=false powerlimit=-66 ExtraSens=0

MCS Inicio Final Tirados Tirados(Sens) (PER)

0 15.00(0.00) 15.00(0.00) 0.00(0.00) 0.00(0.00)1 10.00(0.00) 10.00(0.00) 0.00(0.00) 0.00(0.00)2 10.00(0.00) 10.00(0.00) 0.00(0.00) 0.00(0.00)3 10.00(0.00) 10.00(0.00) 0.00(0.00) 0.00(0.00)4 10.00(0.00) 10.00(0.00) 0.00(0.00) 0.00(0.00)5 531193.00(313.97) 531193.00(313.97) 0.00(0.00) 0.00(0.00)6 53118.70(31.28) 0.00(0.00) 53118.70(31.28) 0.00(0.00)7 0.00(0.00) 0.00(0.00) 0.00(0.00) 0.00(0.00)

Si consultamos la tabla 4.2, vemos que la sensibilidad mınima para el ındice MCS 5 yancho de canal de 20 MHz es -66 dBm. Se corresponde con el valor configurado para lapotencia con la que la senal llega al receptor (powerlimit=-66). Esta correspondenciaperfecta se da en cada una de las configuraciones. Cualquier paquete que sea transmitidocon un ındice MCS superior a 5 se tira por no alcanzar el valor mınimo de potencia enel receptor. Hasta este punto el comportamiento es el deseado. Lo que no concuerda conun comportamiento real es que usando el ındice MCS en el que converge el algoritmo deseleccion de tasa no se tire ningun paquete debido a la tasa de error de paquete.

Para evitar este comportamiento erroneo del modelado se prueban varias ejecucionesdel escenario de simulacion para diferentes valores del parametro ExtraSens. De estaspequenas simulaciones se concluye que se deben anadir 6 dB extra a la sensibilidad derecepcion, lo que dejarıa la tabla de sensibilidad mınima de recepcion de la siguientemanera:



Tabla 4.3: Sensibilidad mınima de recepcion +6 dB

El analisis para estos nuevos valores de sensibilidad, se realiza escogiendo los resultadosobtenidos de la misma configuracion que el caso anterior:

simtime=300 ch=false powerlimit=-72 ExtraSens=6

MCS Inicio Final Tirados Tirados(Sens) (PER)

0 15.00(0.00) 15.00(0.00) 0.00(0.00) 0.00(0.00)1 10.00(0.00) 10.00(0.00) 0.00(0.00) 0.00(0.00)2 10.00(0.00) 10.00(0.00) 0.00(0.00) 0.00(0.00)3 10.00(0.00) 10.00(0.00) 0.00(0.00) 0.00(0.00)4 1165.30(111.87) 1165.30(111.87) 0.00(0.00) 0.00(0.00)5 530427.90(348.15) 522193.40(386.11) 0.00(0.00) 8234.50(78.38)6 49968.65(58.94) 0.00(0.00) 49968.65(58.94) 0.00(0.00)7 0.00(0.00) 0.00(0.00) 0.00(0.00) 0.00(0.00)

Ahora se observa un comportamiento mucho mas acorde a la realidad. El ındice MCS 5es al que converge el algoritmo de la seleccion de tasa pero a diferencia de los resultadosanteriores, aquı se tiran paquetes a causa de la tasa de error de paquetes. El porcentaje depaquetes tirados por la tasa de error de paquete debe ser inferior al 10 % para cumplir conla definicion de sensibilidad de recepcion. En este caso el porcentaje de paquetes tiradospor error de paquete es un 1.57 %.

El resto de resultados de las distintas configuraciones se mantienen en las cotas esperadasy con comportamientos correctos. Por tanto se da por buena la codificacion realizadade la sensibilidad mınima de recepcion. Se ha demostrado la conexion que hay entre estasensibilidad mınima y el modelo de tasa de error utilizado. Cada vez que se quiera cambiaralgo del modelo de la tasa de error, se debera calibrar los valores de sensibilidad mınimacon la ayuda del parametro ExtraSens.



4.3. Gestion de asociaciones entre APs y STAs

En este ultimo apartado lo que se quiere conseguir es modelar la gestion de asociacionesentre un punto de acceso y un cliente o estacion de la manera mas acorde al modelo real.En el apartado 4.1.2 se analizo el modelado del proceso de autenticacion y se concluyo quemodelaba con suficiente rigor el proceso de asociacion de un cliente a un punto de acceso.Por otro lado en la gestion de una asociacion entre cliente y punto de acceso se tienen quecontemplar cada uno de los casos por los que la asociacion puede terminar.

El caso que motiva este apartado es la perdida de conexion entre punto de acceso ycliente debido al movimiento de un cliente. La perdida de conexion se produce porqueen su movimiento el cliente pasa de estar en una zona cubierta por el punto de acceso aestar a una distancia a la que las senales no llegan con potencia suficiente como para serrecibidas correctamente. Es decir, como comunmente se dice: “El punto de acceso deja dever al cliente y el cliente deja de ver al punto de acceso”.

En este apartado por tanto se trata de modelar, de la manera mas fiel a la realidad,el comportamiento de un punto de acceso y un cliente en el caso de que un cliente yaasociado se salga de la zona de cobertura del punto de acceso al que esta conectado.


La solucion a esta deficiencia del modelado pasa por dotar al punto de acceso de unmecanismo que le haga detectar que un cliente conectado se sale de la zona cubierta porlas radiobalizas y por tanto pierde conexion con el mismo. No se puede conocer cual esel mecanismo utilizado por los puntos de acceso con software propietario, pero si de loscontroladores de codigo abierto. Este es el caso de los puntos de acceso con controladoresbasados en Linux, que cuentan con un software, llamado hostapd, que implementa lagestion de puntos de acceso basados en la norma 802.11.

De este software son conocidos los codigos de cada motivo por el cual un punto de accesodeja de tener a un cliente conectado/asociado/autenticado. De todos los motivos queexisten se elige el que corresponde con el error que se quiere corregir: “Desasociacion porinactividad - Tiempo de espera para sesion de cliente superado”. La desasociacion porinactividad se produce cuando el punto de acceso lleva un tiempo superior al tiempo deespera establecido sin recibir ningun paquete de la estacion en cuestion.

Se decide por tanto que la solucion sea modelar en ns-3 el mecanismo por el cual un puntode acceso desasocia a un cliente por inactividad. Para modelar esta solucion, se necesitadefinir lo que se va a considerar inactividad. El punto de acceso va a determinar que uncliente esta inactivo cuando pase un tiempo determinado sin recibir ningun paquete delcliente. Esta definicion de inactividad puede hacer que un punto de acceso determine queun cliente esta inactivo en situaciones indeseadas. Por ejemplo: en ns-3 se puede crear unescenario en el que el unico trafico existente sea un trafico de datos UDP que el puntode acceso manda al cliente. En este caso el cliente (no envıa asentimientos a los datosrecibidos) puede pasar un largo periodo de tiempo sin enviar datos al punto de acceso,tiempo en el que el punto de acceso considerarıa que el cliente esta inactivo.

Para evitar estas situaciones indeseadas se crea un nuevo paquete de gestion que losclientes podran enviar periodicamente al punto de acceso al que estan asociados. El modelo


http://w1.fi/hostapd/


contara por tanto con la posibilidad de activar el envıo de este paquete de gestion en losescenarios en los que se requiera.


El paquete de gestion que se ha creado ha sido codificado en base al paquete de ges-tion correspondiente a una radiobaliza. El primer paso para la creacion de este paquete degestion es la creacion de la cabecera de la capa MAC, la inclusion de esta cabecera en elmodelo necesita de la modificacion de los archivos mgt-headers.cc, mgt-headers.h,wifi-mac-header.cc y wifi-mac-header.h. Las modificaciones necesarias paracrear la cabecera MgtStaFeedbackHeader quedan recogidas en el anexo C, parchesC.11, C.12, C.13 y C.14. En el modelo real no existe ninguna cabecera de estas carac-terısticas en la capa MAC, en este modelo dicha cabecera se utiliza simplemente comoherramienta para modelar la gestion de asociaciones de la forma mas fiel posible.

El paquete que utiliza esta cabecera es un paquete vacıo que se crea en la capa MAC dela interfaz de red del cliente. Se decide colocar la creacion y envıo de este paquete en unafuncion que se ejecuta periodicamente en el modelado que hace ns-3 de la capa MAC dela interfaz de red de un cliente. Se trata de la funcion MissedBeacons, esta funcion seencarga de comprobar periodicamente que se reciben radiobalizas enviadas por el puntode acceso al que el cliente esta conectado. En consecuencia, se enviaran paquetes con lanueva cabecera de gestion siempre y cuando no se dejen de recibir radiobalizas enviadaspor el punto de acceso al que esta conectado dicho cliente.

Para conocer las modificaciones necesarias de los archivos sta-wifi-mac.cc y sta-wifi-mac.h para la codificacion del modelado de la capa MAC de la interfaz de red deun cliente basta con consultar los parches C.15 y C.16 del anexo C. Destacar la inclusionen la clase StaWifiMac del atributo StaFeedback que hace accesible desde el escenariola activacion o desactivacion del envıo de este nuevo tipo de trama de gestion creada. Paraactivar esta caracterıstica desde el escenario de simulacion, se configura la capa MAC dela interfaz de red del cliente de la siguiente manera:

wifiMac.SetType ("ns3::StaWifiMac","Ssid", SsidValue (Ssid ("Wi-Fi PFC")),"StaFeedback",BooleanValue (true));

El envıo de esta nueva trama de gestion por parte de un cliente tiene siempre por destino lainterfaz de red de un punto de acceso. Antes de abordar las modificaciones necesarias de laclase que modela dicha interfaz, nos detenemos en su clase padre: RegularWifiMac. Enesta parte del modelado se debe contemplar la recepcion de esta nueva trama de gestion,porque en caso de no contemplarse salta un error fatal que termina con la simulacion enproceso. En el punto en el que esta trama necesita ser contemplada no se va a incluirninguna modificacion correspondiente al modelado de la solucion que nos ocupa, por loque simplemente se ignora la trama en cuestion. Esta clase esta codificada en el archivoregular-wifi-mac.cc y la modificacion necesaria para ignorar la nueva trama quedarecogida en el anexo C, parche C.17.

El receptor del nuevo mensaje creado para esta solucion es el punto de acceso, mas concre-tamente la capa MAC de su interfaz de red. Este mensaje le sirve al punto de acceso para



detectar si un cliente ha superado el tiempo de inactividad lımite. En caso de ser superadoeste tiempo lımite, el punto de acceso borra al cliente en cuestion de la lista de estacionesconectadas. En la clase ApWifiMac se encuentra el modelado de la capa MAC de lainterfaz de red de un punto de acceso, y por tanto son los archivos ap-wifi-mac.ccy ap-wifi-mac.h los que se han modificado. Las modificaciones que a continuacion seexplican se encuentran en el anexo C, parches C.18 y C.19.

Para dotar a la clase ApWifiMac de las variables necesarias para la implementacion dela solucion adoptada, se han incluido cuatro nuevos atributos privados:

m macFrom es un vector de direcciones MAC en el que se almacenan cada una delas direcciones fısicas de la tarjeta de red de las estaciones conectadas al punto deacceso.

m feedbackTimeout es un vector de variables de tiempo que almacena, para ca-da estacion conectada, el tiempo en el que llega el ultimo paquete con cabeceraMgtStaFeedbackHeader. El ındice en el que se almacena el tiempo correspon-diente a una estacion en concreto, es el mismo ındice que en m macFrom, dondese guarda la direccion MAC de la estacion en cuestion. Este tiempo servira paracompararlo con el tiempo actual y ası determinar si la estacion muestra inactividado no.

m sessionTimeout es la variable de tiempo que almacena el tiempo de inactivi-dad lımite a partir del cual una estacion pasa a considerarse desconectada.

m feedbackEnabled variable booleana iniciada a false y que cambia a trueen caso de que el punto de acceso detecte que las estaciones estan utilizando elmecanismo creado para el modelado de la solucion de este apartado.

En el momento en el que un punto de acceso termina el proceso de asociacion de unaestacion y la considera como conectada, se crea una entrada en el vector m macFrom con ladireccion MAC de dicha estacion y otra entrada vacıa en el vector m feedbackTimeoutpara tener correspondencia entre los ındices de los vectores. Este es el momento tambien enel que se arranca la ejecucion periodica de la funcion StaFeedback. Esta es la funcionencargada de comprobar que el tiempo de inactividad de una estacion no es superioral umbral establecido (m sessionTimeout). En caso de superarse dicho umbral, elpunto de acceso elimina de los vectores las entradas correspondientes a la estacion que seregistra como desasociada. Los valores de las entradas del vector m feedbackTimeout seactualizan con cada recepcion de un paquete con la cabecera MgtStaFeedbackHeader.

El atributo SessionTimeout se ha creado para dar acceso, desde el escenario de si-mulacion, a la configuracion de su valor. En su definicion se impone que su valor seasuperior a 1500 ms puesto que cualquier valor inferior podrıa desencadenar una descone-xion indeseada de una estacion por tratarse de un valor demasiado bajo para un umbralde inactividad. A continuacion se muestra un ejemplo de como configurar este valor desdeel escenario para un tiempo umbral de 10 segundos:

wifiMac.SetType ("ns3::ApWifiMac","Ssid", SsidValue (Ssid ("Wi-Fi PFC")),"SessionTimeout", TimeValue (MilliSeconds (10000)));



Estas modificaciones de la clase ApWifiMac garantizan un correcto registro de las des-conexiones de las estaciones, pero no corrigen el hecho de que el punto de acceso continueenviando datos a la estacion como si esta estuviera aun conectada. Para corregir este com-portamiento se han hecho pequenas modificaciones en las clases DcaTxop y EdcaTxopNque son las clases que modelan el manejo de la cola de paquetes, la fragmentacion yretransmision de paquetes en la capa MAC sin soporte para calidad de servicio y consoporte para calidad de servicio respectivamente.

Lo que se ha hecho en ambos casos es condicionar el envıo de paquetes de datos al estadode la estacion a la que van a ser enviados. En caso de que la direccion MAC a la que van aser enviados los datos corresponda con una estacion registrada como conectada, se envıanlos datos con normalidad. En caso contrario, se purga la cola de transmision y se suspendetoda transmision de paquetes de datos a esa estacion. El codigo de las clases modificadasse encuentra en los archivos dca-txop.cc y edca-txop-n.cc. Las modificacionesnecesarias en estas clases quedan recogidas en los parches C.20 y C.21 del anexo C.


Para este apartado se ha creado un escenario de simulacion apropiado para la verifica-cion del correcto comportamiento del modelado de la gestion de asociaciones. La necesidadde un patron de movilidad concreto, ha obligado a crear un nuevo modelo de movilidad apartir de uno ya existente. El modelo base elegido ha sido el correspondiente a un movi-miento de velocidad constante en cada una de las tres coordenadas posibles. Su nombre esConstantVelocityMobilityModel y se ha modificado de tal manera que cuando el nodo enel cual esta instalado alcance un determinado punto, la constante de su velocidad cambiede signo y por tanto, el nodo en cuestion pase a moverse en la misma direccion pero ensentido contrario.

El escenario de simulacion cuenta con un punto de acceso con posicion fija y dos clientescon el nuevo patron de movimiento instalado. Los dos clientes se iran alejando del puntode acceso a una velocidad constante hasta alcanzar una distancia 5 metros superior ala distancia maxima a la que se pueden comunicar un cliente y un punto de acceso.Alcanzada esta distancia los dos clientes recorreran el mismo camino pero en sentidoopuesto al inicial, de esta manera, ambos volveran a entrar en la zona cubierta por elpunto de acceso, recuperando la conexion y el flujo de datos que tenıan anteriormente.

Al algoritmo de seleccion de tasa se le deben asignar unos parametros menos restrictivosque le dote de la flexibilidad necesaria para adaptar los cambios de tasa al movimiento delos clientes. Otorgando valores 10 veces superiores a los valores por defecto, se consigueque los cambios de tasa se produzcan con una frecuencia menor. Con una menor frecuenciade cambio de tasa se baja la probabilidad de que el algoritmo seleccione una tasa superiorjusto en el momento en el que el cliente se distancia lo suficiente como para no ser capazde recibir correctamente los datos transmitidos a esa nueva tasa, lo que provocarıa unaumento del numero de paquetes tirados o en el peor de los casos una perdida de laconexion.

Como ya se ha visto, ArfWifiManager es el algoritmo de seleccion de tasa por defectopara transmisiones de datos inalambricas basadas en la norma 802.11n. La asignacionde los nuevos valores para sus parametros se puede realizar de manera sencilla desde el



escenario, simplemente se deben incluir el siguiente bloque:

wifi.SetRemoteStationManager ("ns3::ArfWifiManager","TimerThreshold", UintegerValue (150),"SuccessThreshold", UintegerValue (100));

El resto de detalles del escenario se pueden consultar en el anexo B, escenario B.4.

Para verificar el correcto modelado introducido en este apartado, se prueba el compor-tamiento correcto del nuevo modelado en tres situaciones que se producen durante laejecucion del escenario descrito:

Tabla 4.4: Protocolo de verificacion del modelado de la gestion de asociaciones

Para verificar el comportamiento correcto del modelado se han realizado dos baterıas de20 simulaciones, una baterıa para un ancho de canal de 20 MHz y otra baterıa para unancho de canal de 40 MHz. Se ha seguido el protocolo de verificacion de la tabla para cadauna de las simulaciones. Son 3 las verificaciones por cada semilla, por tanto tendremos 60pruebas para cada ancho de canal.

El resultado para 20 MHz es de 59 pruebas satisfactorias y 1 fallida, mientras que para 40MHz las 60 pruebas han sido satisfactorias. La prueba fallida corresponde a la situacion dela tercera fila de la tabla, 18 ha sido la diferencia en numero de paquetes que ha provocadoeste unico fallo.

A la vista de los resultados, las modificaciones introducidas hacen un modelado correctode la gestion de la conexion entre un punto de acceso y cliente en el caso de que un clienteya asociado se salga de la zona de cobertura del punto de acceso al que esta conectado



5. Lıneas de continuacion

El correcto modelado de cualquier elemento de la vida real esta pensado para serutilizado en simulaciones que ayuden a desarrollar, de manera mas agil, elementos queseran reproducidos en la realidad. El modelado desarrollado en este proyecto fin de carreraesta pensado para que en un futuro sirva de base al diseno de un algoritmo de seleccion detasa. El diseno de este algoritmo tiene como objetivo optimizar la seleccion del ındice MCScon el fin de evitar retransmisiones excesivas o por el contrario el desaprovechamiento dela velocidad de transmision.

A continuacion se ofrece una solida base de conocimiento con la que debe partir todapersona que tenga como objetivo disenar un algoritmo de estas caracterısticas y queposteriormente quiera simular su comportamiento.

5.1. Motivacion

Las redes inalambricas han sido una de las tecnologıas que mas han evolucionado enlos ultimos tiempos, incorporando a sus sucesivas normas nuevas herramientas con lasque mejorar el rendimiento de este tipo de redes. Para que estas tecnologıas sean imple-mentadas de manera que se mantenga compatibilidad entre dispositivos, existen organi-zaciones internacionales que se encargan de definir como implementar los nuevos avancestecnologicos manteniendo la compatibilidad global. En el caso de las redes inalambricasla encargada de esta tarea es la IEEE.

Ası para las redes de area local inalambricas la IEEE publico la norma 802.11 y la revisionque nos atane la norma 802.11n[2]. En ella se recogen todas las novedades tecnologicas queofrece la norma, pero tambien se dejan sin definir algunos procedimientos de utilizacion dedichas novedades tecnologicas. A estos procedimientos sin definir los llamaremos gradosde libertad de la norma. Estos grados de libertad son los procedimientos que, respetandola compatibilidad entre dispositivos, quedan sin definir y que el fabricante o creador delcontrolador debera decidir como implementar para sacarle el mayor partido a la tecnologıa.

5.1.1. Grados de libertad de la norma

En la norma 802.11n podemos encontrar como queda abierta la eleccion de algoritmostan crıticos como el de seleccion del ındice MCS con el que un AP transmite en undeterminado momento. Asimismo se pueden elegir el numero de reintentos de una ciertaoperacion o el ındice MCS y potencia con la que un AP transmite las tramas de datos,control o gestion.



Desde la aparicion de la primera version de la norma 802.11, han sido muchas las imple-mentaciones de estos grados de libertad con el objetivo de obtener un rendimiento optimo.Muchas de las implementaciones de estos grados de libertad habıan alcanzado su madurezcon la norma 802.11g, haciendose populares por ejemplo varios algoritmos de seleccionde la tasa de datos. Lo que ha ocurrido con la llegada de la norma 802.11n es que estosalgoritmos, que se habıan hecho populares, han dejado de ser efectivos para la norma802.11n. Estos algoritmos dejan de ser efectivos por las incorporaciones tecnologicas dela norma 802.11n (MIMO, ındice MCS, ancho de banda de 20/40 MHz).

Ası que si se quiere tener un rendimiento optimo de la red Wi-Fi lo que hay que haceres implementar estos algoritmos tan crıticos adaptados al nuevo contexto tecnologico quela norma 802.11n ofrece. A continuacion queda recogida la investigacion realizada con elobjetivo de conocer en que punto de desarrollo tecnologico se encuentra la materia con laque se propone trabajar, o lo que es lo mismo, el estado del arte.

5.1.2. Estado del arte

Se pasa a describir a continuacion en que punto de desarrollo se encuentran los algo-ritmos de interes para la lınea de continuacion propuesta, haciendo hincapie unicamenteen los que en los ultimos tiempos se han hecho mas populares.

Algoritmos de seleccion de tasa de datos

Muchos son los algoritmos existentes que abordan la problematica de la seleccion dela tasa de datos con la que un punto de acceso transmite sus tramas. Como muestra detodos ellos, destacamos tres artıculos que guardan una estrecha relacion con el objetivoinicial de este proyecto.

On link rate adaptation in 802.11n WLANs [3] - este primer artıculo no presen-ta ningun algoritmo, pero su contenido proporciona una muy buena introduccion a latematica que nos ocupa. El artıculo investiga la adaptacion de enlace en sistemas 802.11npracticos a traves de experimentos fuera de la plataforma hardware. Los experimentosponen de manifiesto varias conclusiones no triviales:

1. Las sencillas expansiones de algoritmos desarrollados para 802.11g resultan en mıni-mos beneficios para sistemas 802.11n.

2. En contra de las expectativas teoricas, en la practica el hecho de tener varias antenastransmisoras no siempre resulta en un rendimiento mayor.

3. La seleccion tanto de los flujos como de las antenas es esencial para tener plenobeneficio de la tecnologıa MIMO.

Las conclusiones obtenidas por el artıculo sirven para desarrollar una nueva metrica parala seleccion de flujo. Recomiendan el uso de esta nueva metrica para el desarrollo dealgoritmos inteligentes de seleccion de tasa que pretenden alcanzar un alto rendimientocon solo cambios en el software.

MIMO Link Adaptation Algorithm [4] - propone un diseno para adaptar el enlaceMIMO (MIMO Link Adaptation(LA)) en el que las capas MAC y PHY deben trabajar



de manera conjunta para sacar el mayor partido de la tecnologıa MIMO incorporada enla norma 802.11n. El algoritmo hace uso de la informacion del estado del canal (ChannelState Information (CSI)) y trabaja con esa informacion en un bucle cerrado. Para losdiferentes modos de operacion MIMO, el algoritmo tiene en cuenta el impacto de losdiferentes entornos de radiofrecuencia.

SmartSender [5] - Se trata de un algoritmo practico de adaptacion de la tasa que utilizavalores estadısticos y el indicador de intensidad de senal recibida (RSSI - Received SignalStrength Indicator) de los paquetes con asentimientos (ACK) para determinar la tasa detransmision que maximiza el rendimiento. Este algoritmo por tanto combina metodos ba-sados en estadısticas con metodos basados en mediciones de senal para tener los beneficiosde ambos metodos. Este artıculo en su seccion “Related Work” hace un gran analisis delestado del arte de los algoritmos de seleccion de la tasa de datos. Por tanto, si se quiereampliar los conocimientos acerca del estado del arte, se recomienda encarecidamente sulectura.

Algoritmos de seleccion de potencia de transmision

Los metodos para gestionar la potencia de transmision en redes inalambricas de arealocal son muy importantes a la hora de minimizar la interferencia entre redes vecinas.Reduciendo los niveles de interferencia se consigue una mejora en el rendimiento de losenlaces de la red gracias a la consecucion de una mejor relacion senal-ruido.

El problema es que muchos de los dispositivos de red transmiten a la maxima potenciade salida de la que disponen. Transmitiendo al nivel mas alto de potencia se produceninterferencias, y por tanto, aumentara la probabilidad de que colisionen paquetes. Estohace que, en redes con varios puntos de acceso, el rendimiento global de la red se reduzcapor colisiones entre paquetes de puntos de acceso vecinos que transmiten a su maximapotencia.

Una manera de reducir las interferencias es utilizando las tecnicas de control de potenciade transmision (Transmit Power Control - TPC), que permiten a los dispositivos usarel mınimo nivel de potencia de transmision. Un ejemplo es el conjunto de metodos decontrol de potencia de transmision en 802.11 que actuando sobre cada enlace reduce lasinterferencias, aumentando la capacidad de la red y mejorando la reutilizacion del espectro.Se entiende que para minimizar la potencia de transmision y reducir las interferencias nohay que comprometer la tasa de datos que cada cliente recibe.

A continuacion se describen algunos de los mecanismos de adaptacion de la potencia detransmision que la norma 802.11 contempla. La funcionalidad de control de potencia detransmision (TPC) especificada por la IEEE en la mejora de la norma 802.11h tiene dosfunciones principales:

Limitar la potencia de transmision: El punto de acceso transmite al nivel depotencia maximo para el canal en uso. El nivel maximo de potencia es el valormınimo entre el nivel maximo de potencia permitido por la legislacion local y elnivel de potencia maximo que el dispositivo pueda ofrecer. Las estaciones en el BSSpuede utilizar cualquier nivel de potencia de transmision menor o igual que estenivel de potencia maximo fijado por el AP.



Mecanismo de notificacion de la potencia de transmision: este mecanismodefine un elemento de notificacion del control de la potencia de transmision quecontiene un campo para la potencia de transmision y otro para el margen del enlace.Este elemento se usa para minimizar el nivel de potencia de transmision de losdispositivos.

La segunda funcion se usa para determinar el nivel de potencia de transmision apro-piado para un determinado enlace inalambrico. Si un punto de acceso recibe una tramacon el elemento de notificacion TCP, incluyendo la intensidad de la senal recibida RSSI(Receiver Signal Strength Indicator - Indicador de la intensidad de senal en el receptor)y la potencia con la que el dispositivo emisor transmite, entonces el punto de accesopuede estimar la calidad del enlace (en terminos de perdidas de propagacion) realizandouna simple resta utilizando los valores proporcionados por el dispositivo conectado. Unavez que se han calculado las perdidas de propagacion, los dispositivos pueden ajustar supotencia de transmision.

Muchos son los mecanismos que se han desarrollado, la funcionalidad TPC definida enla norma 802.11h permite ajustar dinamicamente la potencia con la que transmiten losdispositivos de una WLAN. Existen algunos inconvenientes del TPC para WLANs quedeben de ser solucionados:

� Interferencias en el receptor, el problema del terminal oculto (hidden-terminal)� Acceso asimetrico al canal en sistemas MIMO

Ambos problemas desembocan en retransmisiones innecesarias de paquetes y en una dis-minucion de la tasa de datos del enlace. A continuacion se explican brevemente algunosde los metodos existentes que acometen la resolucion de estos problemas que surgen delcontrol dinamico de la potencia de transmision en una WLAN.

Miser (Minimum-energy transmission Strategy) [6] - es un algoritmo basado en elesquema de estimacion de la calidad del enlace definido por TPC en la norma 802.11h.El cliente (STA) de la WLAN estima las perdidas por propagacion entre si mismo y eltransmisor, actualiza el estado de la transmision de datos y luego elige, por inspeccion detablas creadas, la tasa y potencia de transmision adecuados para la transmision de datosen curso.

Cuanto menor es la potencia de transmision o mayor es la tasa de datos en el nivelPHY (menor tiempo de transmision), menor sera la energıa consumida por intento detransmision. A su vez, tambien sera mas probable que la transmision falle, esto derivaen retransmisiones y en un mayor consumo de energıa. La clave del algoritmo Miser esque combina TPC con la adaptacion de la tasa de datos en el nivel PHY y hace unaconstruccion previa de una tabla que relaciona tasa de datos y potencia de transmision.Esta tabla se indexa segun el estado de la tasa de datos PHY, las perdidas de propagaciony los contadores de reenvıo de tramas. Cada entrada de la tabla es la combinacion optimade tasa y potencia en terminos de maximizacion de eficiencia energetica. Las entradas dela tabla se obtienen mediante un ajuste inicial del los dispositivos transmisor y receptor,dependiendo ambos del entorno en el que estan instalados y de su localizacion fısica. Uncambio significativo de la localizacion de los dispositivos implica un nuevo ajuste inicial.

En tiempo de ejecucion, una estacion inalambrica determina tanto la mejor potencia detransmision como la mejor tasa de datos PHY para cada intento de transmitir datos en



funcion de la tabla que relaciona tasa y potencia de transmision.

Contour- Slotted power control managing [7] - el objetivo principal de este metodoes minimizar el nivel de interferencia cuando diferentes puntos de acceso y redes estantrabajando sobre la misma zona. El algoritmo define un esquema de comunicacion con-trolado para WLANs, los puntos de acceso de diferentes redes estan sincronizados conel objetivo de evitar enlaces asimetricos. Ası en cualquier instante de tiempo, todos lospuntos de acceso en la red emitiran con el mismo nivel de potencia para ası evitar enlacesasimetricos. Con el tiempo, mediante el uso de diferentes niveles de potencia, el sistemaconsigue un control de potencia por cliente para maximizar la reutilizacion espacial. Cadapunto de acceso puede transmitir, para cada uno de sus clientes, al nivel de potencia masbajo que minimiza la interferencia con las comunicaciones inalambricas de otros puntosde acceso.

Power control MAC for ad-hoc networks [8] - Este metodo define una tabla dondese consideran 10 niveles de potencia de transmision para los puntos de acceso de unaWLAN: 1 mW, 2 mW, 3.45 mW, 4.8 mW, 7.25 mW, 10.6 mW, 15 mW, 36.6 mW,75.8 mW, y 281.8 mW, que de manera aproximada corresponden respectivamente con lassiguientes distancias de alcance de transmision: 40 m, 60 m, 80 m, 90 m, 100 m, 110 m,120 m, 150 m, 180 m, y 250 m.

Dependiendo de la distancia entre el punto de acceso y el cliente asociado, el puntode acceso transmitira al nivel de potencia definido en la tabla. Una vez que el sistemaesta calibrado y desplegado, las transmisiones experimentan un aumento del rendimientoen comparacion con las transmisiones sin este metodo.

Symphonies [9] - Este metodo considera una combinacion del control del nivel de po-tencia y del ajuste de la tasa de transmision para cumplir con la calidad del enlace quese requiera. Symphonies define una interaccion con la adaptacion de tasa. En redes dearea local inalambricas (WLANs) que operan bajo las normas 802.11a/b/g, los emisoresutilizan una de las diferentes tasas de transmision para enviar paquetes. La seleccion dedicha tasa esta determinada por una estimacion de las condiciones del canal en funcion delas perdidas de paquetes, la tasa entrega, el rendimiento o la relacion senal-interferenciay ruido (Signal to Interference and Noise Ratio - SINR). Conceptualmente, se espera queun enlace tenga un buen comportamiento para una tasa si el valor de SINR en el receptoresta por encima de un umbral definido en una tabla de adaptacion. La seleccion de latasa y el control de la potencia de transmision tienen que estar relacionados, el control dela potencia sin considerar la tasa puede reducir el valor del SINR, y por tanto reducir latasa y el rendimiento del enlace y la red.

Symphonies tiene en cuenta este problema y no compromete la tasa requerida. Por ejem-plo, para transmitir a 54 Mbit/s, la potencia de transmision puede ser reducida hasta quealcance el umbral SINR lımite de 24.56 dB. Se necesita tener un valor preciso de la SINRrecibida con el fin de ajustar el nivel de potencia de transmision.

En los artıculos investigados podemos encontrar como los algoritmos se basan en carac-terısticas no obligatorias de la norma 802.11n y que por tanto la mayorıa de los dispositivosdel mercado no lo soportan. Tambien se ha visto como algunos algoritmos solo son efecti-vos si se instala un software adicional a los clientes que se encargue de recolectar y enviaral punto de acceso la informacion necesaria. En otros casos la topologıa de la red no es



la mas comun, existen algoritmos que solo son efectivos en redes ad-hoc, siendo las redesinfraestructura las populares.

Por lo tanto, desde aquı animo a cualquier persona que lea este proyecto, a utilizarlo comoherramienta tanto de simulacion como de documentacion en el desarrollo y simulacion dealgoritmos que optimicen el rendimiento de una red inalambrica de area local.



Anexos



A. Manual ns-3

A.1. Construccion del escenario para la norma 802.11n

La instalacion de una interfaz de red se hace a traves del metodo Install de la claseWifiHelper. El ejemplar se crea haciendo uso de la llamada al metodo Default de estamisma clase. Este metodo devuelve un ejemplar de esta clase con el gestor de estacionesremoto configurado para que ArfWifiManager[12] sea el algoritmo de control de latasa. En el constructor de la clase WifiHelper se configura la norma en la que se basael modelado de la capa PHY, la configuracion por defecto utiliza la norma 802.11a. Acontinuacion se presentan los tres parametros que recibe el metodo Install:

Un objeto de la clase WifiPhyHelper: sirve para crear objetos WifiPhy, estosson los que modelan en ns-3 la capa PHY.

Un Objeto de la clase WifiMacHelper: de la misma manera sirve para crearobjetos de la clase WifiMac que son los que modelan la capa MAC.

El nodo en el que se quiere instalar la interfaz Wi-Fi.

El ejemplar de la clase WifiPhyHelper se crea con el metodo Default de la cla-se YansWifiPhyHelper, clase de ayuda que sirve para hacer facil crear y gestionarobjetos PHY para el modelo yans [10]. El ejemplar devuelto por este metodo esta con-figurado para que el modelo de tasa de error sea NistErrorRateModel. El ejem-plar de la clase WifiPhyHelper es necesario que tenga asignado un objeto de la claseYansWifiChannelHelper, este objeto se crea haciendo uso del metodo Default deesta misma clase. Este metodo devuelve un ejemplar de su clase configurado para que el re-traso de propagacion este modelado por ConstantSpeedPropagationDelayModel ylas perdidas por propagacion se modelen mediante LogDistancePropagationLoss-Model.

Para crear el ejemplar de la clase WifiMacHelper se utiliza el metodo Default de laclase QosWifiMacHelper que crea el ejemplar configurado para comportarse como unaestacion StaWifiMac, con soporte para calidad de servicio activado ["QosSupported",BooleanValue (true)].

Por ultimo, para el nodo se crea una instancia de la clase NodeContainer y con ellautilizar el metodo Create con el numero de nodos a crear como unico parametro.

La configuracion del ejemplar de la clase WifiMacHelper se finaliza con el metodoSetType, con este metodo se configura el tipo de capa MAC que se usa, para el caso deun punto de acceso el tipo es ApWifiMac y para las estaciones o STA StaWifiMac. En



este mismo metodo se puede dar valor a los parametros de la clase WifiMac, para estecaso se usan los valores por defecto a excepcion del Ssid que cambiamos a “Wi-Fi PFC”tanto para la estacion como para el punto de acceso.

El codigo correspondiente se encuentra en el anexo B.1.

En resumen, la configuracion por defecto que se hace a traves de las clases Helper es lasiguiente:

Norma para el modelado de la capa PHY: 802.11a.

Algoritmo de control de tasa: ArfWifiManager[12].

Modelo de tasa de error: NistErrorRateModel[17].

Modelo de retraso de propagacion: ConstantSpeedPropagationDelayModel.

Modelo de perdidas de propagacion: LogDistancePropagationLossModel.

Existe un amplio abanico de alternativas para cada una de estas configuraciones. Laconfiguracion que se trata en este apartado es la eleccion de la norma con la que se modelala capa PHY. Para ello no hay mas que usar el metodo SetStandard del ejemplar dela clase WifiHelper. Se configura la capa PHY para la norma 802.11n trabajando a 2.4GHz:

SetStandard (WIFI_PHY_STANDARD_80211n_2_4GHZ);

La configuracion para la norma 802.11n tiene un requerimiento en ns-3, que es habi-litar el soporte para HT en la capa MAC de los dispositivos. Esto se consigue facil-mente sustituyendo el ejemplar de la clase QosWifiMacHelper por uno de la claseHtWifiMacHelper. El metodo Default de esta clase devuelve el ejemplar:

HtWifiMacHelper wifiMac = HtWifiMacHelper::Default ();

Con esto quedarıa terminado el escenario para trabajar bajo la norma 802.11n segun elmanual de ns-3.



A.2. 802.11n - Modos de transmision

El conjunto de modos de transmision con los que un dispositivo puede trabajar bajola norma 802.11n en ns-3 es configurado por el metodo Configure802.11n de la claseYansWifiPhy:

voidYansWifiPhy::Configure80211n (void){NS_LOG_FUNCTION (this);

m_deviceRateSet.push_back (WifiPhy::GetDsssRate1Mbps ());m_deviceRateSet.push_back (WifiPhy::GetDsssRate2Mbps ());m_deviceRateSet.push_back (WifiPhy::GetDsssRate5_5Mbps ());m_deviceRateSet.push_back (WifiPhy::GetErpOfdmRate6Mbps ());m_deviceRateSet.push_back (WifiPhy::GetDsssRate11Mbps ());m_deviceRateSet.push_back (WifiPhy::GetErpOfdmRate12Mbps ());m_deviceRateSet.push_back (WifiPhy::GetErpOfdmRate24Mbps ());m_bssMembershipSelectorSet.push_back(HT_PHY);

for (uint8_t i=0; i < 8; i++){

m_deviceMcsSet.push_back(i);}

}

Esta configuracion de modos soportados esta hecha en base a las directrices que la IEEEestablece en la norma 802.11n[2]. La norma dice que las tasas de datos que obligatoria-mente deben soportar los dispositivos de la norma 802.11n son las mismas que las de losdispositivos 802.11g. En la siguiente tabla se recogen las tasas de datos obligatorias yopcionales de la norma 802.11g:

Tabla A.1: Tasas de datos para la norma 802.11g



Ademas de las tasas de datos obligatorias que impone la norma tambien se anaden los 8primeros ındices MCS definidos en la norma 802.11n. En el codigo anterior podemos vercomo se anaden elementos a tres conjuntos diferentes, a continuacion se explica en queconsiste cada uno de estos tres conjuntos:

m deviceRateSet es un ejemplar de la clase WifiModeList. Consiste en unvector de objetos de la clase WifiMode, clase que modela los diferentes modosde transmision. Este vector se rellena con el conjunto de modos de transmision desoporte obligatorio por la norma que corresponda.

m bssMembershipSelectorSet es un vector de enteros en el que se almacenanlos ındices de los conjuntos de modos de transmision que los dispositivos soportan.En este caso la macro HT PHY referencia el ındice en el que se encuentra el conjuntode modos de transmision soportados para la norma 802.11n. Esta lista de modosse puede obtener a traves del metodo GetMembershipSelectorModes de laclase YansWifiPhy. Para ver cuales son estos modos podemos consultar el codigofuente:

WifiModeListYansWifiPhy::GetMembershipSelectorModes(uint32_t selector){uint32_t id=GetBssMembershipSelector(selector);WifiModeList supportedmodes;if (id == HT_PHY)

{//mandatory MCS 0 to 7supportedmodes.push_back (WifiPhy::GetOfdmRate6_5MbpsBW20MHz ());supportedmodes.push_back (WifiPhy::GetOfdmRate13MbpsBW20MHz ());supportedmodes.push_back (WifiPhy::GetOfdmRate19_5MbpsBW20MHz ());supportedmodes.push_back (WifiPhy::GetOfdmRate26MbpsBW20MHz ());supportedmodes.push_back (WifiPhy::GetOfdmRate39MbpsBW20MHz ());supportedmodes.push_back (WifiPhy::GetOfdmRate52MbpsBW20MHz ());supportedmodes.push_back (WifiPhy::GetOfdmRate58_5MbpsBW20MHz ());supportedmodes.push_back (WifiPhy::GetOfdmRate65MbpsBW20MHz ());

}return supportedmodes;

}

Se trata, como bien dice el comentario del codigo fuente, de los modos de transmisionobligatorios para la norma 802.11n. Son los modos correspondientes a los ındicesMCS del 0 al 7 para 20 MHz de canal e intervalo de guarda largo (800 ns).

Por ultimo, m deviceMcsSet es un vector de enteros en el que se guardan losındices MCS soportados por el dispositivo. Este vector esta pensado para trabajarcon el metodo McsToWifiMode de la clase YansWifiPhy, este metodo recibecomo parametro el ındice MCS y devuelve el modo de transmision correspondiente,dependiendo del canal (20 o 40 MHz) y del intervalo de guarda (corto o largo). Esdecir, es un selector del modo de operacion dentro de la tabla 2.2.

Una vez conocidos estos conjuntos y los valores que toman para la norma 802.11n esmomento de saber como son utilizados. La clase WifiRemoteStationManager esla encargada de la gestion de estos conjuntos de modos de transmision. Nos centramosunicamente en los metodos que gestionan los modos de transmision. SetupPhy es elprimer metodo en el que hay que detenerse puesto que es el metodo en el que se inicializael modo de transmision por defecto. El modo de transmision por defecto toma aquı el valor



correspondiente al modo alojado en el primer ındice del conjunto m deviceRateSet,que en este caso es el modo DsssRate1Mbps.

Para obtener el modo con el que se transmiten las tramas de control se recurre al metodoGetControlAnswerMode. Es un metodo extenso y programado de manera deficientepuesto que existen lıneas de codigo que nunca llegan a ser ejecutadas, los desarrolladoresde este metodo han intentado seguir las directrices de la norma para este aspecto pero laambiguedad de la misma ha hecho que el modelado resultante sea caotico. Tras el analisisde este metodo se concluye que el modo utilizado para transmitir las tramas de controles el modo por defecto, (DsssRate1Mbps).

Para finalizar con los metodos de interes de la clase WifiRemoteStationManager,examinamos el metodo GetSupported. Este metodo recibe como parametro el ındice delelemento deseado en el conjunto de modos de transmision de m operationalRateSet.Este conjunto contiene la lista de modos de transmision devuelto por el metodo Get-MembershipSelectorModes visto anteriormente.



A.3. Proceso de recepcion de paquetes

La recepcion de un paquete se modela en el archivo yans-wifi-phy.cc, el metodoStartReceivePacket de la clase YansWifiPhy es el primer paso. Se pueden dardos casos por los que se tire el paquete: que la capa PHY se encuentre en el proceso detransmision/recepcion de un paquete o que se este cambiando de canal. En caso de queel estado de la capa PHY sea ocioso, se continua con la recepcion del paquete.

En este punto es donde se realiza la comprobacion anteriormente comentada: verificar quela potencia con la que llega el paquete esta por encima del umbral de deteccion de unasenal. El paquete se tira en caso de que la potencia de la senal recibida sea demasiadopequena. Si por el contrario la potencia es suficiente, se cambia el estado del canal paraindicar que se esta recibiendo un paquete. Luego se encola el evento de fin de recepcion delpaquete para que sea lanzado transcurrido el tiempo que tarda el paquete en ser recibido.

El evento de fin de recepcion del paquete esta asociado al metodo EndReceive de lamisma clase YansWifiPhy. En este metodo se calcula la tasa de error de paquete paradespues compararla con una variable aleatoria y ası decidir si el paquete termina de serrecibido correctamente o si por el contrario se tira por error de paquete. En la claseYansWifiPhy, el atributo privado m interference es un puntero a un ejemplar de laclase InterferenceHelper. Esta clase se ha creado para servir de ayuda a los calculosrelacionados con las interferencias que se puedan dar en una transmision inalambrica.A traves de este ejemplar se accede al metodo CalculateSnrPer que devuelve unaestructura con dos variables tipo double, una para la tasa de error de paquete y la otrapara la tasa senal-ruido.

No entraremos en detalles de como se calculan estas dos tasas, pero lo que si se va aanalizar es la relacion entre el metodo CalculateSnrPer y la clase que modela la tasade error en ns-3:

Figura A.1: Diagrama de secuencia para el calculo de PER

El diagrama se ha simplificado para una mejor comprension, se han omitido los parame-tros de cada metodo y algunos valores de retorno. El diagrama comienza con la llamada



al metodo CalculateSnrPer de la clase InterferenceHelper desde el metodoEndReceive de la clase YansWifiPhy. Dentro de este metodo se hacen dos llamadasa metodos de la misma clase, CalculateSnr y CalculatePer. Dado que es el calculode PER es el objeto de nuestro interes, continuamos el diagrama de secuencia siguiendola llamada a este metodo.

El metodo CalculatePer contempla un gran numero de variables y casos para el calculode PER. Cualquiera que sea el caso, el calculo de la PER esta condicionado al valordevuelto por el metodo CalculateChunkSuccessRate de la misma clase. Dentro deeste metodo se hace la llamada al metodo virtual puro GetChunkSuccessRate de laclase ErrorRateModel. Este metodo tiene que ser implementado por una subclase deErrorRateModel y devuelve la probabilidad de que sean recibidos correctamente losbits con igual SNR de un paquete.

Existen dos subclases de la clase ErrorRateModel:

YansErrorRateModel se encarga de modelar la tasa de error de las modulacionesde la norma 802.11b.

NistErrorRateModel es el modelo de tasa de error por defecto en ns-3. Ademasde modelar la tasa de error de las modulaciones de la norma 802.11b, tambienmodela dicho calculo para las modulaciones OFDM.

La clase NistErrorRateModel[17] esta disenada para modelar el calculo de la tasa deerror de las modulaciones OFDM de la norma 802.11g. A pesar de eso tambien soporta elcalculo de esta tasa para la mayorıa de los modos de transmision de la norma 802.11n. Eneste modelo se quedan sin contemplar las modulaciones OFDM con tasa de codificacionde 5/6. En este proyecto no se ha abordado la solucion de esta deficiencia de ns-3porque es conocida por la comunidad de desarrolladores de ns-3. El fallo esta registradoy solucionado a la espera de la aprobacion de la comunidad [Bugzilla - Bug 1758: MissingYans and Nist error rate models for 5/6 code rate of 802.11n HT].


https://www.nsnam.org/bugzilla/show_bug.cgi?id=1758

https://www.nsnam.org/bugzilla/show_bug.cgi?id=1758


Codigo

B.1. 2.1.1. Escenario Inicial - Crear dispositivos . . . . . . . . . . . . . . . . . . 73B.2. 2.1.1. Escenario verificador . . . . . . . . . . . . . . . . . . . . . . . . . . . 74B.3. 2.1.2. Escenario verificador . . . . . . . . . . . . . . . . . . . . . . . . . . . 80B.4. 2.1.3. Escenario verificador . . . . . . . . . . . . . . . . . . . . . . . . . . . 87C.1. 2.1.1. Parche wifi-remote-station-manager.cc . . . . . . . . . . . 99C.2. 2.1.1. Parche ap-wifi-mac.cc . . . . . . . . . . . . . . . . . . . . . . . 100C.3. 2.1.1. Parche sta-wifi-mac.cc . . . . . . . . . . . . . . . . . . . . . . 101C.4. 2.1.1. Parche wifi-phy.cc . . . . . . . . . . . . . . . . . . . . . . . . . . 102C.5. 2.1.1. Parche wifi-phy.h . . . . . . . . . . . . . . . . . . . . . . . . . . 103C.6. 2.1.1. Parche yans-wifi-phy.cc . . . . . . . . . . . . . . . . . . . . . . 104C.7. 2.1.2. Parche yans-wifi-phy.cc . . . . . . . . . . . . . . . . . . . . . . 105C.8. 2.1.2. Parche yans-wifi-phy.h . . . . . . . . . . . . . . . . . . . . . . 107C.9. 2.1.2. Parche wifi-phy.cc . . . . . . . . . . . . . . . . . . . . . . . . . . 108C.10.2.1.2. Parche wifi-phy.h . . . . . . . . . . . . . . . . . . . . . . . . . . 109C.11.2.1.3. Parche mgt-headers.cc . . . . . . . . . . . . . . . . . . . . . . . 110C.12.2.1.3. Parche mgt-headers.h . . . . . . . . . . . . . . . . . . . . . . . . 111C.13.2.1.3. Parche wifi-mac-header.cc . . . . . . . . . . . . . . . . . . . . 112C.14.2.1.3. Parche wifi-mac-header.h . . . . . . . . . . . . . . . . . . . . . 113C.15.2.1.3. Parche sta-wifi-mac.cc . . . . . . . . . . . . . . . . . . . . . . 114C.16.2.1.3. Parche sta-wifi-mac.h . . . . . . . . . . . . . . . . . . . . . . . 115C.17.2.1.3. Parche regular-wifi-mac.cc . . . . . . . . . . . . . . . . . . . 116C.18.2.1.3. Parche ap-wifi-mac.cc . . . . . . . . . . . . . . . . . . . . . . . 116C.19.2.1.3. Parche ap-wifi-mac.h . . . . . . . . . . . . . . . . . . . . . . . . 117C.20.2.1.3. Parche dca-txop.cc . . . . . . . . . . . . . . . . . . . . . . . . . . 118C.21.2.1.3. Parche edca-txop-n.cc . . . . . . . . . . . . . . . . . . . . . . . 118



B. Escenarios

// ##########################NS_LOG_INFO ("Crear nodos");// ##########################

// wifiApNodeNodeContainer wifiApNodes;wifiApNodes.Create(nAp);// StaNodesNodeContainer wifiStaNodes;wifiStaNodes.Create(nSta);

WifiHelper wifi = WifiHelper::Default ();

// ############################NS_LOG_INFO ("Crear canal");// ############################

/** PHY **/YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();YansWifiChannelHelper channel = YansWifiChannelHelper::Default ();wifiPhy.SetChannel (channel.Create());

/** MAC **/QosWifiMacHelper wifiMac = QosWifiMacHelper::Default ();

// ################################NS_LOG_INFO ("Crear dispositivos");// ################################

NetDeviceContainer apDevice;wifiMac.SetType ("ns3::ApWifiMac",

"Ssid", SsidValue (Ssid ("Wi-Fi PFC")));apDevice = wifi.Install (wifiPhy, wifiMac, wifiApNodes);

NetDeviceContainer staDevice;wifiMac.SetType ("ns3::StaWifiMac",

"Ssid", SsidValue (Ssid ("Wi-Fi PFC")));staDevice = wifi.Install (wifiPhy, wifiMac, wifiStaNodes);

Codigo B.1: 2.1.1. Escenario Inicial - Crear dispositivos



#include "ns3/core-module.h"#include "ns3/network-module.h"#include "ns3/applications-module.h"#include "ns3/wifi-module.h"#include "ns3/mobility-module.h"#include "ns3/internet-module.h"#include "ns3/propagation-delay-model.h"#include "ns3/propagation-loss-model.h"

using namespace ns3;

NS_LOG_COMPONENT_DEFINE ("Scenario");

bool getGI(WifiMode m){

if (m.GetUniqueName() == "OfdmRate135MbpsBW40MHzShGi" || m.GetUniqueName() == "←↩OfdmRate65MbpsBW20MHzShGi" ){return true;

}else if(m.GetUniqueName() == "OfdmRate135MbpsBW40MHz" || m.GetUniqueName() == "←↩OfdmRate65MbpsBW20MHz" ){return false;

}switch (m.GetDataRate()) {case 6500000:case 13500000:case 13000000:case 27000000:case 19500000:case 40500000:case 26000000:case 54000000:case 39000000:case 81000000:case 52000000:case 108000000:case 58500000:case 121500000:

return false;break;

case 7200000:case 15000000:case 14400000:case 30000000:case 21700000:case 45000000:case 28900000:case 60000000:case 43300000:case 90000000:case 57800000:case 120000000:case 72200000:case 150000000:

return true;break;

}return false;

}

uint32_t PhyRxBeginMcs0, PhyRxBeginMcs1, PhyRxBeginMcs2, PhyRxBeginMcs3, PhyRxBeginMcs4, ←↩PhyRxBeginMcs5, PhyRxBeginMcs6, PhyRxBeginMcs7;

uint32_t beginsimplechannel, begindoublechannel, beginlongGI, beginshortGI;

voidPhyRxBeginMode(std::string path, Ptr<const Packet> p, WifiMode m){

Ptr<Packet> copyp = p->Copy();WifiMacHeader hdr;copyp->RemoveHeader (hdr);



if(!hdr.IsAck()){

if(m.GetBandwidth() == 20000000){beginsimplechannel++;

}else {begindoublechannel++;

}getGI(m) ? beginshortGI++ : beginlongGI++;

}

if(hdr.IsData()){

YansWifiPhy yans_wifi;uint32_t mcs = yans_wifi.WifiModeToMcs(m);switch (mcs) {

case 0:PhyRxBeginMcs0++;break;








default:break;

}}

}

uint32_t PhyRxEndMcs0, PhyRxEndMcs1, PhyRxEndMcs2, PhyRxEndMcs3, PhyRxEndMcs4, PhyRxEndMcs5,←↩PhyRxEndMcs6, PhyRxEndMcs7;

uint32_t endsimplechannel, enddoublechannel, endlongGI, endshortGI;

voidPhyRxEndMode(std::string path, Ptr<const Packet> p, WifiMode m){


if(!hdr.IsAck()){

if(m.GetBandwidth() == 20000000){endsimplechannel++;

}else {enddoublechannel++;

}getGI(m) ? endshortGI++ : endlongGI++;

}

if(hdr.IsData()){

YansWifiPhy yans_wifi;uint32_t mcs = yans_wifi.WifiModeToMcs(m);



switch (mcs) {case 0:PhyRxEndMcs0++;break;

case 1:PhyRxEndMcs1++;break;







default:break;

}}

}

uint32_t PhyRxDropMcs0, PhyRxDropMcs1, PhyRxDropMcs2, PhyRxDropMcs3, PhyRxDropMcs4, ←↩PhyRxDropMcs5, PhyRxDropMcs6, PhyRxDropMcs7;

uint32_t dropsimplechannel, dropdoublechannel, droplongGI, dropshortGI;

voidPhyRxDropMode(std::string path, Ptr<const Packet> p, WifiMode m){


if(!hdr.IsAck()){if(m.GetBandwidth() == 20000000){

dropsimplechannel++;}else {

dropdoublechannel++;}getGI(m) ? dropshortGI++ : droplongGI++;

}

if(hdr.IsData()){YansWifiPhy yans_wifi;uint32_t mcs = yans_wifi.WifiModeToMcs(m);switch (mcs) {

case 0:PhyRxDropMcs0++;break;




case 4:



PhyRxDropMcs4++;break;




default:break;

}}

}

voidPrint(){

NS_LOG_INFO ("-------------------------------");NS_LOG_INFO ("\tInicio\tFinal\tTirados");NS_LOG_INFO ("MCS 0\t" << PhyRxBeginMcs0 << "\t" << PhyRxEndMcs0 << "\t" << PhyRxDropMcs0 ←↩

<< "\tpaquetes");NS_LOG_INFO ("MCS 1\t" << PhyRxBeginMcs1 << "\t" << PhyRxEndMcs1 << "\t" << PhyRxDropMcs1 ←↩







<< "\tpaquetes");NS_LOG_INFO ("-------------------------------");NS_LOG_INFO ("20 MHz\t" << beginsimplechannel << "\t" << endsimplechannel << "\t" << ←↩

dropsimplechannel << "\tpaquetes");NS_LOG_INFO ("40 MHz\t" << begindoublechannel << "\t" << enddoublechannel << "\t" << ←↩

dropdoublechannel << "\tpaquetes");NS_LOG_INFO ("LGI\t" << beginlongGI << "\t" << endlongGI << "\t" << droplongGI << "\←↩

tpaquetes");NS_LOG_INFO ("SGI\t" << beginshortGI << "\t" << endshortGI << "\t" << dropshortGI << "\←↩

tpaquetes");NS_LOG_INFO ("-------------------------------");

}

int main (int argc, char *argv[]){

LogComponentEnable ("Scenario", LOG_LEVEL_INFO);

uint32_t simtime = 5;uint32_t seed = 1;uint32_t nAp = 1;uint32_t nSta = 1;bool ch = false;bool sge = false;

CommandLine cmd;cmd.AddValue ("simtime", "Simulation time (seconds)", simtime);cmd.AddValue ("seed", "Seed for multiple simulations", seed);cmd.AddValue ("nAp", "Number of APs", nAp);cmd.AddValue ("nSta", "Number of STAs", nSta);cmd.AddValue ("ChannelBonding", "ChannelBonding", ch);cmd.AddValue ("ShortGuardEnabled", "ShortGuardEnabled", sge);cmd.Parse (argc,argv);



NS_LOG_INFO ("SimTime: " << simtime << "\tseed: " << seed << "\tch: " << ch << "\tsgr: " ←↩<< sge);

//Set the run number to generate a different random streamSeedManager::SetRun(seed);

// ##########################//NS_LOG_INFO ("Crear nodos");// ##########################


WifiHelper wifi = WifiHelper::Default ();wifi.SetStandard (WIFI_PHY_STANDARD_80211n_2_4GHZ);

// ############################//NS_LOG_INFO ("Crear canal");// ############################


wifiPhy.Set ("GreenfieldEnabled", BooleanValue(true));


/** MAC **/HtWifiMacHelper wifiMac = HtWifiMacHelper::Default ();

// ################################//NS_LOG_INFO ("Crear dispositivos");// ################################





Ptr<ListPositionAllocator> allocator = CreateObject<ListPositionAllocator> ();allocator->Add(Vector (0.0, 0.0, 0.0)); // APallocator->Add(Vector (16.0, 16.0, 0.0)); // STA

MobilityHelper mobility;mobility.SetPositionAllocator(allocator);mobility.SetMobilityModel("ns3::ConstantPositionMobilityModel");mobility.Install (wifiApNodes);mobility.Install (wifiStaNodes);

// Pilas de protocolosInternetStackHelper stack;stack.Install (wifiApNodes);stack.Install (wifiStaNodes);

// ####################################//NS_LOG_INFO ("Asignar direcciones IP");// ####################################



Ipv4AddressHelper address;// Para los nodos STA y nodo APaddress.SetBase ("192.168.1.0", "255.255.255.0");Ipv4InterfaceContainer apInterfaces = address.Assign (apDevice);Ipv4InterfaceContainer staInterfaces = address.Assign (staDevice);

// ################################//NS_LOG_INFO ("Crear trafico");// ################################Ptr<Ipv4> ipv4Server = staDevice.Get(0)->GetNode()->GetObject<Ipv4>();Ipv4InterfaceAddress iaddrServer = ipv4Server->GetAddress(1,0);Ipv4Address ipv4AddrServer = iaddrServer.GetLocal ();

OnOffHelper onoff ("ns3::UdpSocketFactory",Address(InetSocketAddress(ipv4AddrServer,5000)));

onoff.SetAttribute ("OnTime",StringValue ("ns3::ConstantRandomVariable[Constant=1]"));

onoff.SetAttribute ("OffTime",StringValue ("ns3::ConstantRandomVariable[Constant=0]"));

onoff.SetAttribute("DataRate", StringValue("20Mbps"));onoff.SetAttribute ("PacketSize", UintegerValue (1024));

ApplicationContainer apps;apps.Add(onoff.Install (wifiApNodes.Get (0)));apps.Start (Seconds (1.5));apps.Stop (Seconds (simtime-1));

ApplicationContainer sinkApp;PacketSinkHelper sinkHelper ("ns3::UdpSocketFactory",

Address(InetSocketAddress(ipv4AddrServer,5000)));sinkApp = sinkHelper.Install (wifiStaNodes.Get (0));sinkApp.Start (Seconds (1));sinkApp.Stop (Seconds (simtime));//***********************************************************************Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxBeginMode", ←↩MakeCallback(&PhyRxBeginMode));

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxEndMode", ←↩MakeCallback(&PhyRxEndMode));

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxDropMode", ←↩MakeCallback(&PhyRxDropMode));

// ################################//NS_LOG_INFO ("Iniciar Simulacion");// ################################Simulator::Stop (Seconds (simtime));

Simulator::Run ();

Print();Simulator::Destroy ();

return 0;}

Codigo B.2: 2.1.1. Escenario verificador






double powerToDist(double power){

Ptr<YansWifiPhy> yans_wifi = CreateObject <YansWifiPhy> ();double txPower = yans_wifi->GetTxPowerStart();Ptr<LogDistancePropagationLossModel> propagation = CreateObject <←↩

LogDistancePropagationLossModel> ();DoubleValue tmp;propagation->GetAttribute("ReferenceLoss", tmp);double ReferenceLoss = tmp.Get();double exponent = propagation->GetPathLossExponent ();

return std::pow(10, (power-2-txPower+ReferenceLoss)/(-exponent*10) );}

uint32_t PhyRxEndMcs0, PhyRxEndMcs1, PhyRxEndMcs2, PhyRxEndMcs3,PhyRxEndMcs4, PhyRxEndMcs5, PhyRxEndMcs6, PhyRxEndMcs7;

uint32_t endsimplechannel, enddoublechannel;



if(hdr.IsData()){if(m.GetBandwidth() == 20000000){

endsimplechannel++;}else {

enddoublechannel++;}YansWifiPhy yans_wifi;uint32_t mcs = yans_wifi.WifiModeToMcs(m);switch (mcs) {








case 7:



PhyRxEndMcs7++;break;

default:break;

}}

}

uint32_t PhyRxDropMcs0, PhyRxDropMcs1, PhyRxDropMcs2, PhyRxDropMcs3,PhyRxDropMcs4, PhyRxDropMcs5, PhyRxDropMcs6, PhyRxDropMcs7;

uint32_t dropsimplechannel, dropdoublechannel;



if(hdr.IsData()){

if(m.GetBandwidth() == 20000000){dropsimplechannel++;

}else {dropdoublechannel++;

}YansWifiPhy yans_wifi;uint32_t mcs = yans_wifi.WifiModeToMcs(m);switch (mcs) {









default:break;

}}

}

uint32_t PhyRxBeginMcs0, PhyRxBeginMcs1, PhyRxBeginMcs2, PhyRxBeginMcs3,PhyRxBeginMcs4, PhyRxBeginMcs5, PhyRxBeginMcs6, PhyRxBeginMcs7;

uint32_t beginsimplechannel, begindoublechannel;

double last_powerMcs0, last_powerMcs1, last_powerMcs2, last_powerMcs3,last_powerMcs4, last_powerMcs5, last_powerMcs6, last_powerMcs7;

voidPhyRxBeginModePower(std::string path, Ptr<const Packet> p, WifiMode m, double dbmpower){

Ptr<Packet> copyp = p->Copy();



WifiMacHeader hdr;copyp->RemoveHeader (hdr);


beginsimplechannel++;}else {

begindoublechannel++;}










default:break;

}}

}

uint32_t PhyRxDropPowerMcs0, PhyRxDropPowerMcs1, PhyRxDropPowerMcs2, PhyRxDropPowerMcs3,PhyRxDropPowerMcs4, PhyRxDropPowerMcs5, PhyRxDropPowerMcs6, PhyRxDropPowerMcs7;

uint32_t droppowersimplechannel, droppowerdoublechannel;

voidNotifyRxDropModePower(std::string path, Ptr<const Packet> p, WifiMode m, double dbmpower){



droppowersimplechannel++;}else {

droppowerdoublechannel++;}YansWifiPhy yans_wifi;uint32_t mcs = yans_wifi.WifiModeToMcs(m);switch (mcs) {

case 0:PhyRxDropPowerMcs0++;last_powerMcs0 = dbmpower;break;

case 1:



PhyRxDropPowerMcs1++;last_powerMcs1 = dbmpower;break;







default:break;

}

}}

voidPrint(){

NS_LOG_INFO ("-------------------------------------------");NS_LOG_INFO ("\tInicio\tFinal\tTirados\tTirados");NS_LOG_INFO ("\t\t\t(Sens)\t(PER)");

NS_LOG_INFO ("MCS 0\t" << PhyRxBeginMcs0 << "\t" << PhyRxEndMcs0 << "\t"<< PhyRxDropPowerMcs0 << "\t" << PhyRxDropMcs0 << "\tpaquetes");








NS_LOG_INFO ("-------------------------------------------");NS_LOG_INFO ("20 MHz\t" << beginsimplechannel << "\t" << endsimplechannel << "\t"

<< droppowersimplechannel << "\t" << dropsimplechannel << "\←↩tpaquetes");

NS_LOG_INFO ("40 MHz\t" << begindoublechannel << "\t" << enddoublechannel << "\t"<< droppowerdoublechannel << "\t" << dropdoublechannel << "\←↩

tpaquetes");NS_LOG_INFO ("-------------------------------------------");

}





uint32_t simtime = 5;uint32_t seed = 1;uint32_t nAp = 1;uint32_t nSta = 1;double dist = 10;double powerlimit = -64;uint32_t extraSens = 0;bool ch = false;bool sge = false;

CommandLine cmd;cmd.AddValue ("simtime", "Simulation time (seconds)", simtime);cmd.AddValue ("seed", "Seed for multiple simulations", seed);cmd.AddValue ("nAp", "Number of APs", nAp);cmd.AddValue ("nSta", "Number of STAs", nSta);cmd.AddValue ("ChannelBonding", "ChannelBonding", ch);cmd.AddValue ("ShortGuardEnabled", "ShortGuardEnabled", sge);cmd.AddValue ("distance", "Distance between AP and STA (meters)", dist);cmd.AddValue ("powerlimit", "Potencia que recibe el STA", powerlimit);cmd.AddValue ("ExtraSens", "Extra sensitivity hardware specifications", extraSens);cmd.Parse (argc,argv);

dist = powerToDist(powerlimit);NS_LOG_INFO ("SimTime: " << simtime << "\tseed: " << seed << "\tRxPower(distance): "

<< powerlimit<< " dBm (" << dist << " m)"<< "\tExtraSens: " << extraSens<< "\tch: " << ch);









wifiPhy.Set ("ExtraSens", UintegerValue(extraSens));









Ptr<ListPositionAllocator> allocator = CreateObject<ListPositionAllocator> ();allocator->Add(Vector (0.0, 0.0, 0.0)); // APallocator->Add(Vector (dist, 0.0, 0.0)); // STA

MobilityHelper mobility;mobility.SetPositionAllocator(allocator);mobility.SetMobilityModel("ns3::ConstantPositionMobilityModel");mobility.Install (wifiApNodes);mobility.Install (wifiStaNodes);




// ################################//NS_LOG_INFO ("Crear trafico");// ################################Ptr<Ipv4> ipv4Server = staDevice.Get(0)->GetNode()->GetObject<Ipv4>();Ipv4InterfaceAddress iaddrServer = ipv4Server->GetAddress(1,0);Ipv4Address ipv4AddrServer = iaddrServer.GetLocal ();

OnOffHelper onoff ("ns3::UdpSocketFactory",Address(InetSocketAddress(ipv4AddrServer,5000)));

onoff.SetAttribute ("OnTime",StringValue ("ns3::ConstantRandomVariable[Constant=1]"));

onoff.SetAttribute ("OffTime",StringValue ("ns3::ConstantRandomVariable[Constant=0]"));

onoff.SetAttribute("DataRate", StringValue("20Mbps"));onoff.SetAttribute ("PacketSize", UintegerValue (1024));

ApplicationContainer apps;apps.Add(onoff.Install (wifiApNodes.Get (0)));apps.Start (Seconds (1.5));apps.Stop (Seconds (simtime-1));

ApplicationContainer sinkApp;PacketSinkHelper sinkHelper ("ns3::UdpSocketFactory",

Address(InetSocketAddress(ipv4AddrServer,5000)));sinkApp = sinkHelper.Install (wifiStaNodes.Get (0));sinkApp.Start (Seconds (1));sinkApp.Stop (Seconds (simtime));//***********************************************************************Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxBeginModePower", ←↩



MakeCallback(&PhyRxBeginModePower));Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxEndMode", ←↩

MakeCallback(&PhyRxEndMode));Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxDropMode", ←↩

MakeCallback(&PhyRxDropMode));Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxDropModePower", ←↩

MakeCallback(&NotifyRxDropModePower));

// ################################//NS_LOG_INFO ("Iniciar Simulacion");// ################################Simulator::Stop (Seconds (simtime));

Simulator::Run ();

Print();Simulator::Destroy ();

return 0;}







uint32_t simt = 0;NetDeviceContainer nap;NetDeviceContainer nsta;

UniformVariable rv (0.5,1.5);

std::vector< std::vector<bool> > installed;voidInitBoolMatrix(){

installed.resize(nap.GetN());for(uint32_t i = 0 ; i < nap.GetN() ; ++i){

installed[i].resize(nsta.GetN());}

}

voidSetCmdParams(uint32_t stime, NetDeviceContainer aps, NetDeviceContainer stas){

simt = stime;nap = aps;nsta = stas;Simulator::Schedule (MilliSeconds (0), &InitBoolMatrix);

}

intGetNodeNumber(std::string path){

int nodeindex = 0;char indexChar = 0;std::string indexString;

if(path[11]==’/’){

indexChar = path[10];nodeindex = indexChar - ’0’;

}else if(path[12]==’/’)

{indexChar = path[10];indexString += indexChar;indexChar = path[11];indexString += indexChar;nodeindex = atoi(indexString.c_str());

}else

{indexChar = path[10];indexString += indexChar;indexChar = path[11];indexString += indexChar;indexChar = path[12];indexString += indexChar;nodeindex = atoi(indexString.c_str());

}



return nodeindex;}

voidInstall_traffic(NetDeviceContainer apDevice, int ap_nodenumber, NetDeviceContainer staDevice←↩

, int sta_nodenumber){

if(!installed[ap_nodenumber-1][sta_nodenumber-nap.GetN()]){

std::cout << "INSTALAR " << ap_nodenumber << "(" << ap_nodenumber-1 << ")" << " a " ←↩<< sta_nodenumber << "(" << sta_nodenumber-nap.GetN() << ")" << std::endl;

Ptr<Ipv4> ipv4Server = staDevice.Get(sta_nodenumber-nap.GetN())->GetNode()->GetObject<←↩Ipv4>();

Ipv4InterfaceAddress iaddrServer = ipv4Server->GetAddress(1,0);Ipv4Address ipv4AddrServer = iaddrServer.GetLocal ();

OnOffHelper onoff ("ns3::UdpSocketFactory", Address(InetSocketAddress(ipv4AddrServer←↩,5000)));

onoff.SetAttribute ("OnTime", StringValue ("ns3::ConstantRandomVariable[Constant=1]"))←↩;

onoff.SetAttribute ("OffTime", StringValue ("ns3::ConstantRandomVariable[Constant=0]")←↩);

onoff.SetAttribute ("DataRate", StringValue("20Mbps"));onoff.SetAttribute ("PacketSize", UintegerValue (1024));

ApplicationContainer apps;apps.Add(onoff.Install (apDevice.Get(ap_nodenumber-1)->GetNode()));apps.Start (Simulator::Now ()+Seconds(rv.GetValue()));apps.Stop (Seconds (simt - 3));

ApplicationContainer sinkApp;PacketSinkHelper sinkHelper ("ns3::UdpSocketFactory", Address(InetSocketAddress(←↩

ipv4AddrServer,5000)));sinkApp = sinkHelper.Install (staDevice.Get(sta_nodenumber-nap.GetN())->GetNode());sinkApp.Start (Simulator::Now ()+Seconds(rv.GetValue()));sinkApp.Stop (Seconds (simt));

Ptr<WifiNetDevice> device = DynamicCast<WifiNetDevice>(staDevice.Get(sta_nodenumber-←↩nap.GetN()));

Ptr<WifiMac> mac = device->GetMac();Ptr<StaWifiMac> stamac = mac->GetObject<StaWifiMac>();

installed[ap_nodenumber-1][sta_nodenumber-nap.GetN()] = true;}

}

voidAssociate(std::string path, ns3::Mac48Address macaddr){

std::cout << GetNodeNumber(path) << " associated to " << macaddr << std::endl;int nodenumber = GetNodeNumber(path);int apnumber = 0;for(uint32_t mac = 0; mac < nap.GetN()+1; mac++){

std::ostringstream convert;convert << mac;std::string result = convert.str();std::string refmac = "00:00:00:00:00:0" + result;ns3::Mac48Address refmacaddr(refmac.c_str());

if ( operator == (refmacaddr, macaddr) ){

apnumber = mac;}

result.clear();}

// #########################################// NS_LOG_INFO ("Crear e instalar trafico");// #########################################Simulator::Schedule (Seconds (rv.GetValue()), &Install_traffic, nap, apnumber, nsta, ←↩



nodenumber);}

voidDissociate(std::string path, ns3::Mac48Address macaddr){

std::cout << GetNodeNumber(path) << " dissociated of " << macaddr << std::endl;}

uint32_t PhyRxEndMcs0, PhyRxEndMcs1, PhyRxEndMcs2, PhyRxEndMcs3,PhyRxEndMcs4, PhyRxEndMcs5, PhyRxEndMcs6, PhyRxEndMcs7;

uint32_t endsimplechannel, enddoublechannel;



if(hdr.IsData()){

if(m.GetBandwidth() == 20000000){endsimplechannel++;

}else {enddoublechannel++;










default:break;

}}

}

uint32_t PhyRxDropMcs0, PhyRxDropMcs1, PhyRxDropMcs2, PhyRxDropMcs3,PhyRxDropMcs4, PhyRxDropMcs5, PhyRxDropMcs6, PhyRxDropMcs7;

uint32_t dropsimplechannel, dropdoublechannel;






dropsimplechannel++;}else {

dropdoublechannel++;}YansWifiPhy yans_wifi;uint32_t mcs = yans_wifi.WifiModeToMcs(m);switch (mcs) {









default:break;

}}

}

uint32_t PhyRxBeginMcs0, PhyRxBeginMcs1, PhyRxBeginMcs2, PhyRxBeginMcs3,PhyRxBeginMcs4, PhyRxBeginMcs5, PhyRxBeginMcs6, PhyRxBeginMcs7;

uint32_t beginsimplechannel, begindoublechannel;

double last_powerMcs0, last_powerMcs1, last_powerMcs2, last_powerMcs3,last_powerMcs4, last_powerMcs5, last_powerMcs6, last_powerMcs7;

voidPhyRxBeginModePower(std::string path, Ptr<const Packet> p, WifiMode m, double dbmpower){



beginsimplechannel++;}else {

begindoublechannel++;}



case 1:



PhyRxBeginMcs1++;break;







default:break;

}}

}

uint32_t PhyRxDropPowerMcs0, PhyRxDropPowerMcs1, PhyRxDropPowerMcs2, PhyRxDropPowerMcs3,PhyRxDropPowerMcs4, PhyRxDropPowerMcs5, PhyRxDropPowerMcs6, PhyRxDropPowerMcs7;

uint32_t droppowersimplechannel, droppowerdoublechannel;

voidNotifyRxDropModePower(std::string path, Ptr<const Packet> p, WifiMode m, double dbmpower){


if(hdr.IsData()){

if(m.GetBandwidth() == 20000000){droppowersimplechannel++;

}else {droppowerdoublechannel++;







case 5:PhyRxDropPowerMcs5++;last_powerMcs5 = dbmpower;



break;case 6:PhyRxDropPowerMcs6++;last_powerMcs6 = dbmpower;break;


default:break;

}

}}

voidPrint(){

NS_LOG_INFO ("-------------------------------------------");NS_LOG_INFO ("\tInicio\tFinal\tTirados\tTirados");NS_LOG_INFO ("\t\t\t(Sens)\t(PER)");









NS_LOG_INFO ("-------------------------------------------");NS_LOG_INFO ("20 MHz\t" << beginsimplechannel << "\t" << endsimplechannel << "\t"

<< droppowersimplechannel << "\t" << dropsimplechannel << "\←↩tpaquetes");

NS_LOG_INFO ("40 MHz\t" << begindoublechannel << "\t" << enddoublechannel << "\t"<< droppowerdoublechannel << "\t" << dropdoublechannel << "\←↩

tpaquetes");NS_LOG_INFO ("-------------------------------------------");

}

voidSimProgress (){

Time time = Simulator::Now ();NS_LOG_INFO ("Progreso " << 100 * time.GetSeconds() / simt << "%");Simulator::Schedule (Seconds (5)-NanoSeconds(1),&SimProgress);Print();

}



uint32_t simtime = 5;uint32_t seed = 1;uint32_t nAp = 1;uint32_t nSta = 2;bool ch = false;bool sge = false;bool stafeed = false;uint32_t sessionTout = 2000;



CommandLine cmd;cmd.AddValue ("simtime", "Simulation time (seconds)", simtime);cmd.AddValue ("seed", "Seed for multiple simulations", seed);cmd.AddValue ("nAp", "Number of APs", nAp);cmd.AddValue ("nSta", "Number of STAs", nSta);cmd.AddValue ("ChannelBonding", "ChannelBonding", ch);cmd.AddValue ("ShortGuardEnabled", "ShortGuardEnabled", sge);cmd.AddValue ("StaFeedback", "StaFeedback", stafeed);cmd.AddValue ("SessionTimeout", "SessionTimeout in MilliSeconds (bigger than 1500 ms)", ←↩

sessionTout);cmd.Parse (argc,argv);

if (sessionTout >= 1500){

NS_LOG_INFO ("\nSimTime: " << simtime << "\tseed: " << seed << "\tch: " << ch<< "\tStaFeedback: " << ←↩

stafeed<< "\tSessionTimeout: " << ←↩

sessionTout << " ms\n");}else{

NS_LOG_INFO ("\nSessionTimeout must be bigger than 1500 ms\n");simtime = 0;

}





wifi.SetRemoteStationManager ("ns3::ArfWifiManager","TimerThreshold", UintegerValue (150),"SuccessThreshold", UintegerValue (100));







NetDeviceContainer apDevice;



wifiMac.SetType ("ns3::ApWifiMac","Ssid", SsidValue (Ssid ("Wi-Fi PFC")),"SessionTimeout", TimeValue (MilliSeconds (sessionTout)));

apDevice = wifi.Install (wifiPhy, wifiMac, wifiApNodes);

NetDeviceContainer staDevice;

wifiMac.SetType ("ns3::StaWifiMac","Ssid", SsidValue (Ssid ("Wi-Fi PFC")),"StaFeedback",BooleanValue (stafeed));

staDevice = wifi.Install (wifiPhy, wifiMac, wifiStaNodes);

Ptr<ListPositionAllocator> allocator = CreateObject<ListPositionAllocator> ();allocator->Add(Vector (0.0, 0.0, 0.0)); // AP 1allocator->Add(Vector (-10.0, -10.0, 0.0)); // STA 1allocator->Add(Vector (10.0, 10.0, 0.0)); // STA 2

MobilityHelper mobility;mobility.SetPositionAllocator(allocator);mobility.SetMobilityModel("ns3::ConstantPositionMobilityModel");mobility.Install (wifiApNodes);

mobility.SetMobilityModel ("ns3::ConstantVelocityMobilityModel");mobility.Install (wifiStaNodes);

Ptr<ConstantVelocityMobilityModel> mob = wifiStaNodes.Get(0)->GetObject<←↩ConstantVelocityMobilityModel>();

mob->SetVelocity(Vector(3.0, 0, 0));mob = wifiStaNodes.Get(1)->GetObject<ConstantVelocityMobilityModel>();mob->SetVelocity(Vector(-3.0, 0, 0));




Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxBeginModePower", ←↩MakeCallback(&PhyRxBeginModePower));

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxEndMode", ←↩MakeCallback(&PhyRxEndMode));

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxDropMode", ←↩MakeCallback(&PhyRxDropMode));

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxDropModePower", ←↩MakeCallback(&NotifyRxDropModePower));

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/←↩$ns3::StaWifiMac/DeAssoc", MakeCallback(&Dissociate));

Config::Connect("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/←↩$ns3::StaWifiMac/Assoc", MakeCallback(&Associate));

Simulator::Schedule (Seconds (0), &SetCmdParams, simtime, apDevice, staDevice);Simulator::Schedule (Seconds (5), &SimProgress);

// ################################//NS_LOG_INFO ("Iniciar Simulaci n");// ################################if (simtime != 0){



Simulator::Stop (Seconds (simtime));

Simulator::Run ();

//NS_LOG_INFO ("Simulaci n finalizada");Print();

}Simulator::Destroy ();

return 0;}




C. Modelado corregido

@@ -27,6 +27,7 @@#include "ns3/double.h"#include "ns3/uinteger.h"#include "ns3/wifi-phy.h"

+#include "ns3/yans-wifi-phy.h"#include "ns3/trace-source-accessor.h"#include "wifi-mac-header.h"#include "wifi-mac-trailer.h"

@@ -345,14 +346,22 @@ WifiRemoteStationManager::SetupPhy (Ptr<WifiPhy> phy)// transmit rate for automatic control responses like// acknowledgements.m_wifiPhy = phy;

- m_defaultTxMode = phy->GetMode (0);- if(HasHtSupported())+ if(DynamicCast<YansWifiPhy>(phy)->GetGreenfield())

{- m_defaultTxMcs = phy->GetMcs (0);+ m_defaultTxMode = phy->GetMembershipSelectorModes(0).at(0);+ m_defaultTxMcs = phy->GetMcs (0);

}else{

- m_defaultTxMcs = 0;+ m_defaultTxMode = phy->GetMode (0);+ if(HasHtSupported())+ {+ m_defaultTxMcs = phy->GetMcs (0);+ }+ else+ {+ m_defaultTxMcs = 0;+ }

}Reset ();

}@@ -1324,7 +1333,14 @@ WifiModeWifiRemoteStationManager::GetSupported (const WifiRemoteStation *station, uint32_t i) const{

NS_ASSERT (i < GetNSupported (station));- return station->m_state->m_operationalRateSet[i];+ if (!DynamicCast<YansWifiPhy>(m_wifiPhy)->GetGreenfield())+ {+ return station->m_state->m_operationalRateSet[i];+ }+ else+ {+ return m_wifiPhy->McsToWifiMode(i);+ }}uint8_tWifiRemoteStationManager::GetMcsSupported (const WifiRemoteStation *station, uint32_t i) ←↩

const

Codigo C.1: 2.1.1. Parche wifi-remote-station-manager.cc



@@ -30,6 +30,7 @@#include "qos-tag.h"#include "wifi-phy.h"+#include "yans-wifi-phy.h"#include "dcf-manager.h"#include "mac-rx-middle.h"#include "mac-tx-middle.h"@@ -309,10 +310,21 @@ ApWifiMac::GetSupportedRates (void) const

}// send the set of supported rates and make sure that we indicate// the Basic Rate set in this set of supported rates.

- for (uint32_t i = 0; i < m_phy->GetNModes (); i++)+ if(DynamicCast<YansWifiPhy>(m_phy)->GetGreenfield())

{- WifiMode mode = m_phy->GetMode (i);- rates.AddSupportedRate (mode.GetDataRate ());+ for (uint32_t i = 0; i < m_phy->GetMembershipSelectorModes(0).size(); i++)+ {+ WifiMode mode = m_phy->GetMembershipSelectorModes(0).at(i);+ rates.AddSupportedRate (mode.GetDataRate ());+ }+ }+ else+ {+ for (uint32_t i = 0; i < m_phy->GetNModes (); i++)+ {+ WifiMode mode = m_phy->GetMode (i);+ rates.AddSupportedRate (mode.GetDataRate ());+ }

}// set the basic ratesfor (uint32_t j = 0; j < m_stationManager->GetNBasicModes (); j++)

@@ -590,12 +602,26 @@ ApWifiMac::Receive (Ptr<Packet> packet, const WifiMacHeader *hdr){// station supports all rates in Basic Rate Set.// record all its supported modes in its associated WifiRemoteStation

- for (uint32_t j = 0; j < m_phy->GetNModes (); j++)+ if(DynamicCast<YansWifiPhy>(m_phy)->GetGreenfield())+ {+ for (uint32_t i=0;i<m_phy->GetMembershipSelectorModes(0).size();i++)+ {+ WifiMode mode = m_phy->GetMembershipSelectorModes(0).at(i);+ if (rates.IsSupportedRate (mode.GetDataRate ()))+ {+ m_stationManager->AddSupportedMode (from, mode);+ }+ }+ }+ else

{- WifiMode mode = m_phy->GetMode (j);- if (rates.IsSupportedRate (mode.GetDataRate ()))+ for (uint32_t j = 0; j < m_phy->GetNModes (); j++)

{- m_stationManager->AddSupportedMode (from, mode);+ WifiMode mode = m_phy->GetMode (j);+ if (rates.IsSupportedRate (mode.GetDataRate ()))+ {+ m_stationManager->AddSupportedMode (from, mode);+ }

}}if (m_htSupported)

Codigo C.2: 2.1.1. Parche ap-wifi-mac.cc



@@ -29,6 +29,7 @@#include "qos-tag.h"

+#include "yans-wifi-phy.h"#include "mac-low.h"#include "dcf-manager.h"

@@ -552,16 +553,29 @@ StaWifiMac::Receive (Ptr<Packet> packet, const WifiMacHeader *hdr)HtCapabilities htcapabilities = assocResp.GetHtCapabilities ();m_stationManager->AddStationHtCapabilities(hdr->GetAddr2(),htcapabilities);}

-- for (uint32_t i = 0; i < m_phy->GetNModes (); i++)+ if(DynamicCast<YansWifiPhy>(m_phy)->GetGreenfield())+ {+ for (uint32_t i=0; i<m_phy->GetMembershipSelectorModes(0).size(); i++)+ {+ WifiMode mode = m_phy->GetMembershipSelectorModes(0).at(i);+ if (rates.IsSupportedRate (mode.GetDataRate ()))+ {+ m_stationManager->AddSupportedMode (hdr->GetAddr2 (), mode);+ }+ }+ }+ else

{- WifiMode mode = m_phy->GetMode (i);- if (rates.IsSupportedRate (mode.GetDataRate ()))+ for (uint32_t i = 0; i < m_phy->GetNModes (); i++)

{- m_stationManager->AddSupportedMode (hdr->GetAddr2 (), mode);- if (rates.IsBasicRate (mode.GetDataRate ()))+ WifiMode mode = m_phy->GetMode (i);+ if (rates.IsSupportedRate (mode.GetDataRate ()))

{- m_stationManager->AddBasicMode (mode);+ m_stationManager->AddSupportedMode (hdr->GetAddr2 (), mode);+ if (rates.IsBasicRate (mode.GetDataRate ()))+ {+ m_stationManager->AddBasicMode (mode);+ }

}}

}@@ -609,10 +623,21 @@ StaWifiMac::GetSupportedRates (void) const

rates.SetBasicRate(m_phy->GetBssMembershipSelector(i));}

}- for (uint32_t i = 0; i < m_phy->GetNModes (); i++)+ if(DynamicCast<YansWifiPhy>(m_phy)->GetGreenfield())

{- WifiMode mode = m_phy->GetMode (i);- rates.AddSupportedRate (mode.GetDataRate ());+ for (uint32_t i = 0; i < m_phy->GetMembershipSelectorModes(0).size(); i++)+ {+ WifiMode mode = m_phy->GetMembershipSelectorModes(0).at(i);+ rates.AddSupportedRate (mode.GetDataRate ());+ }+ }+ else+ {+ for (uint32_t i = 0; i < m_phy->GetNModes (); i++)+ {+ WifiMode mode = m_phy->GetMode (i);+ rates.AddSupportedRate (mode.GetDataRate ());+ }

}return rates;

}

Codigo C.3: 2.1.1. Parche sta-wifi-mac.cc



@@ -68,12 +68,21 @@ WifiPhy::GetTypeId (void).AddTraceSource ("PhyRxBegin",

"Trace source indicating a packet has begun being received from the ←↩channel medium by the device",

MakeTraceSourceAccessor (&WifiPhy::m_phyRxBeginTrace))+ .AddTraceSource ("PhyRxBeginMode",+ "Trace source indicating a packet has begun being received from the ←↩

channel medium by the device (mode)",+ MakeTraceSourceAccessor (&WifiPhy::m_phyRxBeginModeTrace))

.AddTraceSource ("PhyRxEnd","Trace source indicating a packet has been completely received from ←↩

the channel medium by the device",MakeTraceSourceAccessor (&WifiPhy::m_phyRxEndTrace))

+ .AddTraceSource ("PhyRxEndMode",+ "Trace source indicating a packet has been completely received from ←↩

the channel medium by the device (mode)",+ MakeTraceSourceAccessor (&WifiPhy::m_phyRxEndModeTrace))

.AddTraceSource ("PhyRxDrop","Trace source indicating a packet has been dropped by the device ←↩

during reception",MakeTraceSourceAccessor (&WifiPhy::m_phyRxDropTrace))

+ .AddTraceSource ("PhyRxDropMode",+ "Trace source indicating a packet has been dropped by the device ←↩

during reception (mode)",+ MakeTraceSourceAccessor (&WifiPhy::m_phyRxDropModeTrace))

.AddTraceSource ("MonitorSnifferRx","Trace source simulating a wifi device in monitor mode sniffing all ←↩

received frames",MakeTraceSourceAccessor (&WifiPhy::m_phyMonitorSniffRxTrace))

@@ -475,18 +484,36 @@ WifiPhy::NotifyRxBegin (Ptr<const Packet> packet)void+WifiPhy::NotifyRxBeginMode (Ptr<const Packet> packet, WifiMode wifimode)+{+ m_phyRxBeginModeTrace (packet, wifimode);+}++voidWifiPhy::NotifyRxEnd (Ptr<const Packet> packet){

m_phyRxEndTrace (packet);}

void+WifiPhy::NotifyRxEndMode (Ptr<const Packet> packet, WifiMode wifimode)+{+ m_phyRxEndModeTrace (packet, wifimode);+}++voidWifiPhy::NotifyRxDrop (Ptr<const Packet> packet){

m_phyRxDropTrace (packet);}

void+WifiPhy::NotifyRxDropMode (Ptr<const Packet> packet, WifiMode wifimode)+{+ m_phyRxDropModeTrace (packet, wifimode);+}++voidWifiPhy::NotifyMonitorSniffRx (Ptr<const Packet> packet, uint16_t channelFreqMhz, uint16_t ←↩

channelNumber, uint32_t rate, bool isShortPreamble, double signalDbm, double noiseDbm){

m_phyMonitorSniffRxTrace (packet, channelFreqMhz, channelNumber, rate, isShortPreamble, ←↩signalDbm, noiseDbm);

Codigo C.4: 2.1.1. Parche wifi-phy.cc



@@ -921,6 +921,8 @@ public:*/void NotifyRxBegin (Ptr<const Packet> packet);

+ void NotifyRxBeginMode (Ptr<const Packet> packet, WifiMode wifimode);+

/*** Public method used to fire a PhyRxEnd trace. Implemented for encapsulation

* purposes.@@ -929,6 +931,8 @@ public:

*/void NotifyRxEnd (Ptr<const Packet> packet);

+ void NotifyRxEndMode (Ptr<const Packet> packet, WifiMode wifimode);+

/*** Public method used to fire a PhyRxDrop trace. Implemented for encapsulation

* purposes.@@ -937,6 +941,8 @@ public:

*/void NotifyRxDrop (Ptr<const Packet> packet);

+ void NotifyRxDropMode (Ptr<const Packet> packet, WifiMode wifimode);+

/**** Public method used to fire a MonitorSniffer trace for a wifi packet being received. ←↩

Implemented for encapsulation@@ -1086,6 +1092,8 @@ private:

*/TracedCallback<Ptr<const Packet> > m_phyRxBeginTrace;

+ TracedCallback<Ptr<const Packet>, WifiMode > m_phyRxBeginModeTrace;+

/*** The trace source fired when a packet ends the reception process from

* the medium.@@ -1094,6 +1102,8 @@ private:

*/TracedCallback<Ptr<const Packet> > m_phyRxEndTrace;

+ TracedCallback<Ptr<const Packet>, WifiMode > m_phyRxEndModeTrace;+

/*** The trace source fired when the phy layer drops a packet it has received.

*@@ -1101,6 +1111,8 @@ private:

*/TracedCallback<Ptr<const Packet> > m_phyRxDropTrace;

+ TracedCallback<Ptr<const Packet>, WifiMode > m_phyRxDropModeTrace;+

/*** A trace source that emulates a wifi device in monitor mode

* sniffing a packet being received.

Codigo C.5: 2.1.1. Parche wifi-phy.h



@@ -514,6 +514,7 @@ WifiMode txMode=txVector.GetMode();m_state->SwitchToRx (rxDuration);NS_ASSERT (m_endRxEvent.IsExpired ());NotifyRxBegin (packet);

+ NotifyRxBeginMode (packet, txVector.GetMode());m_interference.NotifyRxStart ();m_endRxEvent = Simulator::Schedule (rxDuration, &YansWifiPhy::EndReceive, this,

packet,@@ -800,6 +801,7 @@ YansWifiPhy::EndReceive (Ptr<Packet> packet, Ptr<InterferenceHelper::←↩

Event> evenif (m_random->GetValue () > snrPer.per)

{NotifyRxEnd (packet);

+ NotifyRxEndMode (packet, event->GetTxVector().GetMode());uint32_t dataRate500KbpsUnits = event->GetPayloadMode ().GetDataRate () * event->←↩

GetTxVector().GetNss()/ 500000;bool isShortPreamble = (WIFI_PREAMBLE_SHORT == event->GetPreambleType ());double signalDbm = RatioToDb (event->GetRxPowerW ()) + 30;

@@ -811,6 +813,7 @@ YansWifiPhy::EndReceive (Ptr<Packet> packet, Ptr<InterferenceHelper::←↩Event> even{

/* failure. */NotifyRxDrop (packet);

+ NotifyRxDropMode (packet, event->GetTxVector().GetMode());m_state->SwitchFromRxEndError (packet, snrPer.snr);

}}

Codigo C.6: 2.1.1. Parche yans-wifi-phy.cc



@@ -24,6 +24,7 @@#include "wifi-mode.h"#include "wifi-preamble.h"#include "wifi-phy-state-helper.h"

+#include "wifi-mac-header.h"#include "error-rate-model.h"#include "ns3/simulator.h"#include "ns3/packet.h"

@@ -162,8 +163,10 @@ YansWifiPhy::GetTypeId (void)MakeBooleanAccessor (&YansWifiPhy::GetChannelBonding,

&YansWifiPhy::SetChannelBonding),MakeBooleanChecker ())

--+ .AddAttribute ("ExtraSens", "Extra sensitivity hardware specifications.",+ UintegerValue (0),+ MakeUintegerAccessor (&YansWifiPhy::m_extraSensitivity),+ MakeUintegerChecker<uint32_t> ())

;return tid;

}@@ -451,6 +454,7 @@ YansWifiPhy::StartReceivePacket (Ptr<Packet> packet,

NS_LOG_FUNCTION (this << packet << rxPowerDbm << txVector.GetMode()<< preamble);rxPowerDbm += m_rxGainDb;double rxPowerW = DbmToW (rxPowerDbm);

+ bool ofdmThreshold = true;Time rxDuration = CalculateTxDuration (packet->GetSize (), txVector, preamble);

WifiMode txMode=txVector.GetMode();Time endRx = Simulator::Now () + rxDuration;

@@ -507,14 +511,23 @@ WifiMode txMode=txVector.GetMode();break;

case YansWifiPhy::CCA_BUSY:case YansWifiPhy::IDLE:

- if (rxPowerW > m_edThresholdW)++ Ptr<Packet> copyp = packet->Copy();+ WifiMacHeader hdr;+ copyp->RemoveHeader (hdr);++ if(txVector.GetMode().GetModulationClass() == WIFI_MOD_CLASS_HT)+ {+ ofdmThreshold = IsOfdmThreshold(rxPowerDbm, txVector.GetMode());+ }+ NotifyRxBeginModePower (packet, txVector.GetMode(), WToDbm(rxPowerW));+ if (rxPowerW > m_edThresholdW && ofdmThreshold)

{NS_LOG_DEBUG ("sync to signal (power=" << rxPowerW << "W)");// sync to signalm_state->SwitchToRx (rxDuration);NS_ASSERT (m_endRxEvent.IsExpired ());NotifyRxBegin (packet);

- NotifyRxBeginMode (packet, txVector.GetMode());m_interference.NotifyRxStart ();m_endRxEvent = Simulator::Schedule (rxDuration, &YansWifiPhy::EndReceive, this,

packet,@@ -522,8 +535,17 @@ WifiMode txMode=txVector.GetMode();

}else

{- NS_LOG_DEBUG ("drop packet because signal power too Small (" <<- rxPowerW << "<" << m_edThresholdW << ")");+ if(!ofdmThreshold)+ {+ NS_LOG_DEBUG ("drop packet because signal (" << rxPowerDbm <<+ ") is to small for " << txVector.GetMode());+ NotifyRxDropModePower (packet, txVector.GetMode(), WToDbm(rxPowerW));+ }+ else+ {+ NS_LOG_DEBUG ("drop packet because signal power too Small (" <<



+ rxPowerW << "<" << m_edThresholdW << ")");+ }

NotifyRxDrop (packet);goto maybeCcaBusy;

}@@ -1210,4 +1232,54 @@ YansWifiPhy::McsToWifiMode (uint8_t mcs)

}return mode;}++bool+YansWifiPhy::IsOfdmThreshold (double rxPowerDbm, WifiMode txMode)+{+ bool decition = true;+ uint32_t bw = txMode.GetBandwidth();+ uint32_t cbw = 20000000;+ rxPowerDbm += m_extraSensitivity;++ switch (WifiModeToMcs(txMode))+ {+ case 0:+ if( rxPowerDbm < ((bw == cbw) ? -82 : -79) )+ decition = false;+ break;+ case 1:+ if( rxPowerDbm < ((bw == cbw) ? -79 : -76) )+ decition = false;+ break;+ case 2:+ if( rxPowerDbm < ((bw == cbw) ? -77 : -74) )+ decition = false;+ break;+ case 3:+ if( rxPowerDbm < ((bw == cbw) ? -74 : -71) )+ decition = false;+ break;+ case 4:+ if( rxPowerDbm < ((bw == cbw) ? -70 : -67) )+ decition = false;+ break;+ case 5:+ if( rxPowerDbm < ((bw == cbw) ? -66 : -63) )+ decition = false;+ break;+ case 6:+ if( rxPowerDbm < ((bw == cbw) ? -65 : -62) )+ decition = false;+ break;+ case 7:+ if( rxPowerDbm < ((bw == cbw) ? -64 : -61) )+ decition = false;+ break;+ default:+ NS_ASSERT (false);+ break;+ }+ return decition;+}+} // namespace ns3

Codigo C.7: 2.1.2. Parche yans-wifi-phy.cc



@@ -451,6 +451,10 @@ private:* \param event the corresponding event of the first time the packet arrives

*/void EndReceive (Ptr<Packet> packet, Ptr<InterferenceHelper::Event> event);

+ /**+ *+ */+ bool IsOfdmThreshold (double rxPowerDbm, WifiMode txMode);

private:double m_edThresholdW; //!< Energy detection threshold in watts

@@ -473,6 +477,7 @@ private:bool m_greenfield; //!< Flag if GreenField format is supportedbool m_guardInterval; //!< Flag if short guard interval is usedbool m_channelBonding; //!< Flag if channel conding is used

+ uint32_t m_extraSensitivity; //!< Add extra sensitivity to hardware specifications

/**

Codigo C.8: 2.1.2. Parche yans-wifi-phy.h



@@ -68,9 +68,9 @@ WifiPhy::GetTypeId (void).AddTraceSource ("PhyRxBegin",

"Trace source indicating a packet has begun being received from the ←↩channel medium by the device",

MakeTraceSourceAccessor (&WifiPhy::m_phyRxBeginTrace))- .AddTraceSource ("PhyRxBeginMode",- "Trace source indicating a packet has begun being received from the ←↩

channel medium by the device (mode)",- MakeTraceSourceAccessor (&WifiPhy::m_phyRxBeginModeTrace))+ .AddTraceSource ("PhyRxBeginModePower",+ "Trace source indicating a packet has begun being received from the ←↩

channel medium by the device (mode and power)",+ MakeTraceSourceAccessor (&WifiPhy::m_phyRxBeginModePowerTrace))

.AddTraceSource ("PhyRxEnd","Trace source indicating a packet has been completely received from ←↩

the channel medium by the device",MakeTraceSourceAccessor (&WifiPhy::m_phyRxEndTrace))

@@ -83,6 +83,9 @@ WifiPhy::GetTypeId (void).AddTraceSource ("PhyRxDropMode",

"Trace source indicating a packet has been dropped by the device ←↩during reception (mode)",

MakeTraceSourceAccessor (&WifiPhy::m_phyRxDropModeTrace))+ .AddTraceSource ("PhyRxDropModePower",+ "Trace source indicating a packet has been dropped by the device ←↩

during reception (mode and power)",+ MakeTraceSourceAccessor (&WifiPhy::m_phyRxDropModePowerTrace))

.AddTraceSource ("MonitorSnifferRx","Trace source simulating a wifi device in monitor mode sniffing all ←↩

received frames",MakeTraceSourceAccessor (&WifiPhy::m_phyMonitorSniffRxTrace))

@@ -484,9 +487,9 @@ WifiPhy::NotifyRxBegin (Ptr<const Packet> packet)}

void-WifiPhy::NotifyRxBeginMode (Ptr<const Packet> packet, WifiMode wifimode)+WifiPhy::NotifyRxBeginModePower (Ptr<const Packet> packet, WifiMode wifimode, double power){- m_phyRxBeginModeTrace (packet, wifimode);+ m_phyRxBeginModePowerTrace (packet, wifimode, power);}

void@@ -514,6 +517,12 @@ WifiPhy::NotifyRxDropMode (Ptr<const Packet> packet, WifiMode wifimode)}

void+WifiPhy::NotifyRxDropModePower (Ptr<const Packet> packet, WifiMode wifimode, double power)+{+ m_phyRxDropModePowerTrace (packet, wifimode, power);+}++voidWifiPhy::NotifyMonitorSniffRx (Ptr<const Packet> packet, uint16_t channelFreqMhz, uint16_t ←↩

channelNumber, uint32_t rate, bool isShortPreamble, double signalDbm, double noiseDbm){

m_phyMonitorSniffRxTrace (packet, channelFreqMhz, channelNumber, rate, isShortPreamble, ←↩signalDbm, noiseDbm);

Codigo C.9: 2.1.2. Parche wifi-phy.cc



@@ -921,7 +921,7 @@ public:*/void NotifyRxBegin (Ptr<const Packet> packet);

- void NotifyRxBeginMode (Ptr<const Packet> packet, WifiMode wifimode);+ void NotifyRxBeginModePower (Ptr<const Packet> packet, WifiMode wifimode, double power);

/*** Public method used to fire a PhyRxEnd trace. Implemented for encapsulation

@@ -943,6 +943,8 @@ public:

void NotifyRxDropMode (Ptr<const Packet> packet, WifiMode wifimode);

+ void NotifyRxDropModePower (Ptr<const Packet> packet, WifiMode wifimode, double power);+

/**** Public method used to fire a MonitorSniffer trace for a wifi packet being received. ←↩

Implemented for encapsulation@@ -1092,7 +1094,7 @@ private:

*/TracedCallback<Ptr<const Packet> > m_phyRxBeginTrace;

- TracedCallback<Ptr<const Packet>, WifiMode > m_phyRxBeginModeTrace;+ TracedCallback<Ptr<const Packet>, WifiMode, double > m_phyRxBeginModePowerTrace;

/*** The trace source fired when a packet ends the reception process from

@@ -1113,6 +1115,8 @@ private:

TracedCallback<Ptr<const Packet>, WifiMode > m_phyRxDropModeTrace;

+ TracedCallback<Ptr<const Packet>, WifiMode, double > m_phyRxDropModePowerTrace;+

/*** A trace source that emulates a wifi device in monitor mode

* sniffing a packet being received.

Codigo C.10: 2.1.2. Parche wifi-phy.h



@@ -1089,4 +1089,55 @@ MgtDelBaHeader::SetParameterSet (uint16_t params)m_tid = (params >> 12) & 0x0f;

}

+/***********************************************************+ * STA Feedback+ ***********************************************************/++NS_OBJECT_ENSURE_REGISTERED (MgtStaFeedbackHeader)+ ;++MgtStaFeedbackHeader::MgtStaFeedbackHeader ()+ : m_padding (0)+{+}+MgtStaFeedbackHeader::˜MgtStaFeedbackHeader ()+{+}++TypeId+MgtStaFeedbackHeader::GetTypeId (void)+{+ static TypeId tid = TypeId ("ns3::MgtStaFeedbackHeader")+ .SetParent<Header> ()+ .AddConstructor<MgtStaFeedbackHeader> ()+ ;+ return tid;+}+TypeId+MgtStaFeedbackHeader::GetInstanceTypeId (void) const+{+ return GetTypeId ();+}+void+MgtStaFeedbackHeader::Print (std::ostream &os) const+{+}+uint32_t+MgtStaFeedbackHeader::GetSerializedSize (void) const+{+ return 1;+}+void+MgtStaFeedbackHeader::Serialize (Buffer::Iterator start) const+{+ start.WriteU8 (m_padding);+}+uint32_t+MgtStaFeedbackHeader::Deserialize (Buffer::Iterator start)+{+ Buffer::Iterator i = start;+ m_padding = i.ReadU8 ();+ return i.GetDistanceFrom (start);+}+} // namespace ns3

Codigo C.11: 2.1.3. Parche mgt-headers.cc



@@ -756,6 +756,27 @@ private:uint16_t m_reasonCode;

};

+/**+ * \ingroup wifi+ * Implement the header for management frames of sta feedback.+ */+class MgtStaFeedbackHeader : public Header+{+public:+ MgtStaFeedbackHeader ();+ ˜MgtStaFeedbackHeader ();++ static TypeId GetTypeId (void);+ virtual TypeId GetInstanceTypeId (void) const;+ virtual void Print (std::ostream &os) const;+ virtual uint32_t GetSerializedSize (void) const;+ virtual void Serialize (Buffer::Iterator start) const;+ virtual uint32_t Deserialize (Buffer::Iterator start);++private:+ uint8_t m_padding;+};+} // namespace ns3

#endif /* MGT_HEADERS_H */

Codigo C.12: 2.1.3. Parche mgt-headers.h



@@ -161,6 +161,12 @@ WifiMacHeader::SetMultihopAction (void)m_ctrlSubtype = 0x0F;

}void+WifiMacHeader::SetStaFeedback (void)+{+ m_ctrlType = TYPE_MGT;+ m_ctrlSubtype = 6;+}+voidWifiMacHeader::SetType (enum WifiMacType type){

switch (type)@@ -241,6 +247,10 @@ WifiMacHeader::SetType (enum WifiMacType type)

m_ctrlType = TYPE_MGT;m_ctrlSubtype = 15;break;

+ case WIFI_MAC_MGT_STA_FEEDBACK:+ m_ctrlType = TYPE_MGT;+ m_ctrlSubtype = 6;+ break;

case WIFI_MAC_DATA:m_ctrlType = TYPE_DATA;

@@ -460,6 +470,9 @@ WifiMacHeader::GetType (void) constcase 5:return WIFI_MAC_MGT_PROBE_RESPONSE;break;

+ case 6:+ return WIFI_MAC_MGT_STA_FEEDBACK;+ break;

case 8:return WIFI_MAC_MGT_BEACON;break;

@@ -688,6 +701,11 @@ WifiMacHeader::IsMultihopAction (void) constreturn (GetType () == WIFI_MAC_MGT_MULTIHOP_ACTION);

}bool+WifiMacHeader::IsStaFeedback (void) const+{+ return (GetType () == WIFI_MAC_MGT_STA_FEEDBACK);+}+boolWifiMacHeader::IsBlockAckReq (void) const{

return (GetType () == WIFI_MAC_CTL_BACKREQ) ? true : false;@@ -928,6 +946,7 @@ case WIFI_MAC_ ## x: \

FOO (MGT_ACTION);FOO (MGT_ACTION_NO_ACK);FOO (MGT_MULTIHOP_ACTION);

+ FOO (MGT_STA_FEEDBACK);

FOO (DATA);FOO (DATA_CFACK);

@@ -1053,6 +1072,7 @@ WifiMacHeader::Print (std::ostream &os) constos << ", FragNumber=" << std::hex << (int) m_seqFrag << std::dec

<< ", SeqNumber=" << m_seqSeq;break;

+ case WIFI_MAC_MGT_STA_FEEDBACK:case WIFI_MAC_DATA_CFACK:case WIFI_MAC_DATA_CFPOLL:case WIFI_MAC_DATA_CFACK_CFPOLL:

Codigo C.13: 2.1.3. Parche wifi-mac-header.cc



@@ -54,6 +54,7 @@ enum WifiMacTypeWIFI_MAC_MGT_ACTION,WIFI_MAC_MGT_ACTION_NO_ACK,WIFI_MAC_MGT_MULTIHOP_ACTION,

+ WIFI_MAC_MGT_STA_FEEDBACK,

WIFI_MAC_DATA,WIFI_MAC_DATA_CFACK,

@@ -154,6 +155,10 @@ public:*/void SetMultihopAction ();/**

+ * Set Type/Subtype values for sta feedback header.+ */+ void SetStaFeedback ();+ /**

* Set the From DS bit in the Frame Control field.

*/void SetDsFrom (void);

@@ -477,6 +482,13 @@ public:*/bool IsMultihopAction () const;/**

+ * Check if the header is sta feedback header.+ *+ * \return true if the header is sta feedback header,+ * false otherwise+ */+ bool IsStaFeedback () const;+ /**

* Return the raw duration from the Duration/ID field.

** \return the raw duration from the Duration/ID field

Codigo C.14: 2.1.3. Parche wifi-mac-header.h



@@ -88,6 +88,10 @@ StaWifiMac::GetTypeId (void)MakeBooleanAccessor (&StaWifiMac::SetActiveProbing),MakeBooleanChecker ())

+ .AddAttribute ("StaFeedback", "If true, we send sta feedback ",+ BooleanValue (false),+ MakeBooleanAccessor (&StaWifiMac::SetStaFeedback),+ MakeBooleanChecker ())

.AddTraceSource ("Assoc", "Associated with an access point.",MakeTraceSourceAccessor (&StaWifiMac::m_assocLogger))

.AddTraceSource ("DeAssoc", "Association with an access point lost.",@@ -100,7 +104,8 @@ StaWifiMac::StaWifiMac ()

: m_state (BEACON_MISSED),m_probeRequestEvent (),m_assocRequestEvent (),

- m_beaconWatchdogEnd (Seconds (0.0))+ m_beaconWatchdogEnd (Seconds (0.0)),+ m_tid (){

NS_LOG_FUNCTION (this);

@@ -157,6 +162,12 @@ StaWifiMac::SetActiveProbing (bool enable)}

void+StaWifiMac::SetStaFeedback (bool enable)+{+ m_staFeedback = enable;+}++voidStaWifiMac::SendProbeRequest (void){

NS_LOG_FUNCTION (this);@@ -297,6 +308,22 @@ StaWifiMac::MissedBeacons (void)

{m_beaconWatchdog.Cancel ();

}+ if(m_staFeedback)+ {+ Ptr<Packet> packet = Create<Packet> ();+ WifiMacHeader hdr;+ hdr.SetStaFeedback ();+ hdr.SetAddr1 (GetBssid ());+ hdr.SetAddr2 (GetAddress ());+ hdr.SetAddr3 (GetBssid ());+ hdr.SetDsNotFrom ();+ hdr.SetDsNotTo ();+ MgtStaFeedbackHeader stafeedback;+ packet->AddHeader (stafeedback);+ m_dca->Queue (packet, hdr);+ }

m_beaconWatchdog = Simulator::Schedule (m_beaconWatchdogEnd - Simulator::Now (),&StaWifiMac::MissedBeacons, this);

return;@@ -346,7 +373,7 @@ StaWifiMac::Enqueue (Ptr<const Packet> packet, Mac48Address to)

// If we are not a QoS AP then we definitely want to use AC_BE to// transmit the packet. A TID of zero will map to AC_BE (through \c// QosUtilsMapTidToAc()), so we use that as our default here.

- uint8_t tid = 0;+ //uint8_t tid = 0;

// For now, an AP that supports QoS does not support non-QoS// associations, and vice versa. In future the AP model should

@@ -364,15 +391,15 @@ StaWifiMac::Enqueue (Ptr<const Packet> packet, Mac48Address to)hdr.SetQosTxopLimit (0);

// Fill in the QoS control field in the MAC header- tid = QosUtilsGetTidForPacket (packet);+ m_tid = QosUtilsGetTidForPacket (packet);

// Any value greater than 7 is invalid and likely indicates that



// the packet had no QoS tag, so we revert to zero, which’ll// mean that AC_BE is used.

- if (tid >= 7)+ if (m_tid >= 7)

{- tid = 0;+ m_tid = 0;

}- hdr.SetQosTid (tid);+ hdr.SetQosTid (m_tid);

}else

@@ -392,8 +419,8 @@ if (m_htSupported)if (m_qosSupported){

// Sanity check that the TID is valid- NS_ASSERT (tid < 8);- m_edca[QosUtilsMapTidToAc (tid)]->Queue (packet, hdr);+ NS_ASSERT (m_tid < 8);+ m_edca[QosUtilsMapTidToAc (m_tid)]->Queue (packet, hdr);

}else{

@@ -667,6 +694,7 @@ StaWifiMac::SetState (MacState value)&& m_state == ASSOCIATED)

{m_deAssocLogger (GetBssid ());

+ m_edca[QosUtilsMapTidToAc (m_tid)]->NotifyChannelSwitching();}

m_state = value;}

Codigo C.15: 2.1.3. Parche sta-wifi-mac.cc

@@ -31,6 +31,9 @@#include "supported-rates.h"#include "amsdu-subframe-header.h"

+#include "ap-wifi-mac.h"+#include "ns3/wifi-module.h"+namespace ns3 {

class MgtAddBaRequestHeader;@@ -103,6 +106,12 @@ private:

*/void SetActiveProbing (bool enable);/**

+ * Enable or disable sta feedback.+ *+ * \param enable enable or disable sta feedback+ */+ void SetStaFeedback (bool enable);+ /**

* Return whether active probing is enabled.

** \return true if active probing is enabled, false otherwise

@@ -187,6 +196,8 @@ private:EventId m_beaconWatchdog;Time m_beaconWatchdogEnd;uint32_t m_maxMissedBeacons;

+ uint8_t m_tid;+ bool m_staFeedback;

TracedCallback<Mac48Address> m_assocLogger;TracedCallback<Mac48Address> m_deAssocLogger;

Codigo C.16: 2.1.3. Parche sta-wifi-mac.h



@@ -559,6 +559,11 @@ RegularWifiMac::Receive (Ptr<Packet> packet, const WifiMacHeader *hdr)return;

}}

+ else if(hdr->IsStaFeedback())+ {+ // STA feedback: ignore+ return;+ }

NS_FATAL_ERROR ("Don’t know how to handle frame (type=" << hdr->GetType ());}

Codigo C.17: 2.1.3. Parche regular-wifi-mac.cc

@@ -70,6 +70,10 @@ ApWifiMac::GetTypeId (void)MakeBooleanAccessor (&ApWifiMac::SetBeaconGeneration,

&ApWifiMac::GetBeaconGeneration),MakeBooleanChecker ())

+ .AddAttribute ("SessionTimeout", "The client inactivity time accepted (bigger than 1500←↩ms).",

+ TimeValue (MilliSeconds (2000)),+ MakeTimeAccessor (&ApWifiMac::m_sessionTimeout),+ MakeTimeChecker ())

;return tid;

}@@ -83,6 +87,7 @@ ApWifiMac::ApWifiMac ()

m_beaconDca->SetMaxCw (0);m_beaconDca->SetLow (m_low);m_beaconDca->SetManager (m_dcfManager);

+ m_feedbackEnabled = false;

// Let the lower layers know that we are acting as an AP.SetTypeOfStation (AP);

@@ -93,6 +98,8 @@ ApWifiMac::ApWifiMac ()ApWifiMac::˜ApWifiMac (){

NS_LOG_FUNCTION (this);+ m_macFrom.clear();+ m_feedbackTimeout.clear();}

void@@ -455,6 +462,10 @@ ApWifiMac::TxOk (const WifiMacHeader &hdr)

if (hdr.IsAssocResp ()&& m_stationManager->IsWaitAssocTxOk (hdr.GetAddr1 ()))

{+ m_macFrom.push_back(hdr.GetAddr1());+ m_feedbackTimeout.push_back(Seconds(0.0));+ StaFeedback(hdr.GetAddr1 ());+

NS_LOG_DEBUG ("associated with sta=" << hdr.GetAddr1 ());m_stationManager->RecordGotAssocTxOk (hdr.GetAddr1 ());

}@@ -481,6 +492,21 @@ ApWifiMac::Receive (Ptr<Packet> packet, const WifiMacHeader *hdr)

Mac48Address from = hdr->GetAddr2 ();

+ if(hdr->IsStaFeedback() && m_stationManager->IsAssociated (from))+ {+ if(m_feedbackEnabled == false)+ m_feedbackEnabled = true;++ uint32_t index = 0;+ for(uint32_t j = 0; j < m_macFrom.size(); j++)+ {+ if(m_macFrom.at(j)==from)+ index = j;+ }



+ m_feedbackTimeout.at(index) = Simulator::Now ();+ return;+ }+

if (hdr->IsData ()){

Mac48Address bssid = hdr->GetAddr1 ();@@ -706,4 +732,26 @@ ApWifiMac::DoInitialize (void)

RegularWifiMac::DoInitialize ();}

+void+ApWifiMac::StaFeedback (Mac48Address from)+{+ uint32_t index = 0;+ for(uint32_t i = 0; i < m_macFrom.size(); i++)+ {+ if(m_macFrom.at(i)==from)+ index = i;+ }+ if(Simulator::Now ().GetSeconds() - m_feedbackTimeout.at(index).GetSeconds() < ←↩

m_sessionTimeout.GetSeconds() || !m_stationManager->IsAssociated(from))+ {+ Simulator::Schedule (m_sessionTimeout, &ApWifiMac::StaFeedback, this, from);+ }+ else if(m_feedbackEnabled)+ {+ NS_LOG_DEBUG (GetAddress() << " RecordDisassociated " << from);+ m_stationManager->RecordDisassociated (from);+ m_feedbackTimeout.erase(m_feedbackTimeout.begin()+index);+ m_macFrom.erase(m_macFrom.begin()+index);+ }+}+} // namespace ns3

Codigo C.18: 2.1.3. Parche ap-wifi-mac.cc

@@ -204,12 +204,18 @@ private:virtual void DoDispose (void);virtual void DoInitialize (void);

+ void StaFeedback (Mac48Address from);+

Ptr<DcaTxop> m_beaconDca; //!< Dedicated DcaTxop for beaconsTime m_beaconInterval; //!< Interval between beaconsbool m_enableBeaconGeneration; //!< Flag if beacons are being generatedEventId m_beaconEvent; //!< Event to generate one beaconPtr<UniformRandomVariable> m_beaconJitter; //!< UniformRandomVariable used to randomize ←↩

the time of the first beaconbool m_enableBeaconJitter; //!< Flag if the first beacon should be generated at random ←↩

time+ std::vector <Time> m_feedbackTimeout;+ std::vector <Mac48Address> m_macFrom;+ bool m_feedbackEnabled;+ Time m_sessionTimeout;};

} // namespace ns3

Codigo C.19: 2.1.3. Parche ap-wifi-mac.h



@@ -481,9 +481,19 @@ DcaTxop::NotifyAccessGranted (void)params.DisableRts ();NS_LOG_DEBUG ("tx unicast");

}- params.DisableNextData ();- Low ()->StartTransmission (m_currentPacket, &m_currentHdr,- params, m_transmissionListener);++ if(m_stationManager->IsAssociated(m_currentHdr.GetAddr1 ()) || m_currentHdr.IsMgt←↩

())+ {+ params.DisableNextData ();+ Low ()->StartTransmission (m_currentPacket, &m_currentHdr,+ params, m_transmissionListener);+ }+ else+ {+ m_queue->Flush ();+ m_currentPacket = 0;+ NS_LOG_DEBUG ("tx unicast cancelled: destination device is not associated");+ }

}}

}

Codigo C.20: 2.1.3. Parche dca-txop.cc

@@ -495,9 +495,19 @@ EdcaTxopN::NotifyAccessGranted (void)NS_LOG_DEBUG ("tx unicast");

}params.DisableNextData ();

- m_low->StartTransmission (m_currentPacket, &m_currentHdr,- params, m_transmissionListener);- CompleteTx ();++ if(m_stationManager->IsAssociated(m_currentHdr.GetAddr1 ()) || m_currentHdr.←↩

IsToDs())+ {+ m_low->StartTransmission (m_currentPacket, &m_currentHdr,+ params, m_transmissionListener);+ CompleteTx ();+ }+ else+ {+ m_queue->Flush ();+ m_currentPacket = 0;+ NS_LOG_DEBUG ("tx unicast cancelled: destination device is not associated");+ }

}}

}

Codigo C.21: 2.1.3. Parche edca-txop-n.cc



Bibliografıa

[1] Wikipedia: Ieee 802.11. http://en.wikipedia.org/wiki/IEEE_802.11,Ultima modificacion: 18 de Febrero de 2014.

[2] Ieee standard for information technology–telecommunications and information ex-change between systems local and metropolitan area networks–specific requirementspart 11: Wireless lan medium access control (mac) and physical layer (phy) specifi-cations. IEEE Std 802.11-2012 (Revision of IEEE Std 802.11-2007), pages 1–2793,2012.

[3] S. Lakshmanan, S. Sanadhya, and R. Sivakumar: On link rate adaptation in 802.11nwlans. In INFOCOM, 2011 Proceedings IEEE, pages 366–370, April 2011.

[4] Weihua Helen Xi, Alistair Munro, and Michael Barton: Link adaptation algorithmfor the ieee 802.11n mimo system. In Proceedings of the 7th International IFIP-TC6Networking Conference on AdHoc and Sensor Networks, Wireless Networks, NextGeneration Internet, NETWORKING’08, pages 780–791, Berlin, Heidelberg, 2008.Springer-Verlag, ISBN 3-540-79548-0, 978-3-540-79548-3. http://dl.acm.org/citation.cfm?id=1792514.1792601.

[5] Qiuyan Xia and M. Hamdi: Smart sender: a practical rate adaptation algorithmfor multirate ieee 802.11 wlans. Wireless Communications, IEEE Transactions on,7(5):1764–1775, May 2008, ISSN 1536-1276.

[6] Daji Qiao, Sunghyun Choi, Amit Jain, and Kang G. Shin: Miser: An optimal low-energy transmission strategy for ieee 802.11a/h. In Proceedings of the 9th AnnualInternational Conference on Mobile Computing and Networking, MobiCom ’03, pages161–175, New York, NY, USA, 2003. ACM, ISBN 1-58113-753-2. http://doi.acm.org/10.1145/938985.939003.

[7] Vishnu Navda, Ravi Kokku, Samrat Ganguly, and Samir Das: Slotted symmetricpower control in managed wireless lans, 2007. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.4654&rep=rep1&type=pdf.

[8] Eun Sun Jung and Nitin H. Vaidya: A power control mac protocol for ad hoc networks.In Proceedings of the 8th Annual International Conference on Mobile Computingand Networking, MobiCom ’02, pages 36–47, New York, NY, USA, 2002. ACM,ISBN 1-58113-486-X. http://doi.acm.org/10.1145/570645.570651.

[9] Kishore Ramachandran, Ravi Kokku, Honghai Zhang, and Marco Gruteser: Sym-phony: Synchronous two-phase rate and power control in 802.11 wlans. In


http://en.wikipedia.org/wiki/IEEE_802.11

http://dl.acm.org/citation.cfm?id=1792514.1792601

http://dl.acm.org/citation.cfm?id=1792514.1792601

http://doi.acm.org/10.1145/938985.939003

http://doi.acm.org/10.1145/938985.939003

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.4654&rep=rep1&type=pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.4654&rep=rep1&type=pdf

http://doi.acm.org/10.1145/570645.570651


Proceedings of the 6th International Conference on Mobile Systems, Applica-tions, and Services, MobiSys ’08, pages 132–145, New York, NY, USA, 2008.ACM, ISBN 978-1-60558-139-2. http://doi.acm.org/10.1145/1378600.1378616.

[10] Mathieu Lacage and Thomas R. Henderson: Yet another network simulator. InProceeding from the 2006 Workshop on Ns-2: The IP Network Simulator, WNS2 ’06,New York, NY, USA, 2006. ACM, ISBN 1-59593-508-8. http://doi.acm.org/10.1145/1190455.1190467.

[11] Mathieu Lacage, Mohammad Hossein Manshaei, and Thierry Turletti: Ieee 802.11rate adaptation: A practical approach. In Proceedings of the 7th ACM InternationalSymposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems,MSWiM ’04, pages 126–134, New York, NY, USA, 2004. ACM, ISBN 1-58113-953-5.http://doi.acm.org/10.1145/1023663.1023687.

[12] Ad Kamerman and Leo Monteban: Wavelan R©-ii: a high-performance wirelesslan for the unlicensed band. Bell Labs Technical Journal, 2(3):118–133, 1997,ISSN 1538-7305. http://dx.doi.org/10.1002/bltj.2069.

[13] Jongseok Kim, Seongkwan Kim, Sunghyun Choi, and D. Qiao: Cara: Collision-awarerate adaptation for ieee 802.11 wlans. In INFOCOM 2006. 25th IEEE InternationalConference on Computer Communications. Proceedings, pages 1–11, April 2006.

[14] Starsky H. Y. Wong, Hao Yang, Songwu Lu, and Vaduvur Bharghavan: Robustrate adaptation for 802.11 wireless networks. In Proceedings of the 12th An-nual International Conference on Mobile Computing and Networking, MobiCom ’06,pages 146–157, New York, NY, USA, 2006. ACM, ISBN 1-59593-286-0. http://doi.acm.org/10.1145/1161089.1161107.

[15] Andrew Myles Brian Hart: Renewing the viability of 2.4 ghz by actively encouragingthe use of ofdm rates, 2014. https://mentor.ieee.org/802.11/dcn/14/11-14-0099-00-000m-renewing-2-4ghz-band.pptx.

[16] Rohde and Schwarz: 802.11ac technology introduction white paper,” march 2012.[online]. In M. Park, “IEEE 802.11ac: Dynamic Bandwidth Channel Access,”in Proc. of IEEE ICC, 2011. http://cdn.rohde-schwarz.com/dl_downloads/dl_application/application_notes/1ma192/1MA192_7e_80211ac_technology.pdf.

[17] G. Pei and T.R. Henderson: Validation of ofdm error rate model in ns-3. Boe-ing Research Technology, pages 1–15, 2010. http://www.nsnam.org/˜pei/80211ofdm.pdf.


http://doi.acm.org/10.1145/1378600.1378616

http://doi.acm.org/10.1145/1378600.1378616

http://doi.acm.org/10.1145/1190455.1190467

http://doi.acm.org/10.1145/1190455.1190467

http://doi.acm.org/10.1145/1023663.1023687

http://dx.doi.org/10.1002/bltj.2069

http://doi.acm.org/10.1145/1161089.1161107

http://doi.acm.org/10.1145/1161089.1161107

https://mentor.ieee.org/802.11/dcn/14/11-14-0099-00-000m-renewing-2-4ghz-band.pptx

https://mentor.ieee.org/802.11/dcn/14/11-14-0099-00-000m-renewing-2-4ghz-band.pptx

http://cdn.rohde-schwarz.com/dl_downloads/dl_application/application_notes/1ma192/1MA192_7e_80211ac_technology.pdf



http://www.nsnam.org/~pei/80211ofdm.pdf

http://www.nsnam.org/~pei/80211ofdm.pdf

MODELADO DE LA NORMA 802.11n EN NS-3bibing.us.es/proyectos/abreproy/12207/fichero/MemoriaPFC.pdf ·...

Documents

Transcript of MODELADO DE LA NORMA 802.11n EN NS-3bibing.us.es/proyectos/abreproy/12207/fichero/MemoriaPFC.pdf ·...