Diseño, Implementaci Ón y Prueba de Un Mecanismo de Gesti Ón de Ancho de Banda para Flujos TCP en Redes 802.16

Proyecto de Grado
Presentado ante la ilustre Universidad de Los Andes como requisito final para
obtener el Ttulo de Ingeniero de Sistemas
o, implementacio
n y prueba de un mecanismo
Disen
n de ancho de banda para flujos TCP
de gestio
en Redes 802.16
Por
Br. Diego Alexander Uzcategui Jota

Tutor: Prof. Andres Arcia Moret
Mayo 2012
c
2012
Universidad de Los Andes Merida, Venezuela
Dise
no, implementaci
on y prueba de un mecanismo de gesti
on
de ancho de banda para flujos TCP en Redes 802.16
Br. Diego Alexander Uzcategui Jota
Proyecto de Grado Sistemas Computacionales, 90 paginas
Resumen: WiMAX es uno de los sistemas de acceso inalambrico hacia la Internet
que constantemente ha estado evolucionando con el fin de prestar mejores servicios
de transmisiones de datos, voz y video en redes de alcance metropolitano. En las
redes WiMAX una Estacion de Base se encarga de administrar el ancho de banda
entre las Estaciones Suscriptoras, para trafico en las dos direcciones, de la Estacion
Base a Estaciones Suscriptoras (enlace de bajada), y viceversa (enlace de subida).
Especficamente, en la asignacion de ancho de banda para transmisiones de data
en el enlace de subida, la Estacion Base debe realizar una estimacion del ancho de
banda requerido por las Estaciones Suscriptoras. Para facilitar esto, se dispone de
un perodo de contencion en cada trama en el que las Estaciones Suscriptoras envan
peque
nos paquetes a la Estacion Base indicando el ancho de banda requerido. A partir
del procesamiento de estos paquetes, la Estacion Base puede hacer una planificacion
adecuada del uso de la subtrama de subida. En este trabajo se presenta un modelo para
el procesamiento de las solicitudes de ancho de banda denominado Gestion del Ancho
de Banda con Retardo Aleatorio, que mejora el rendimiento de redes WiMAX cuando
se transmite trafico TCP. Mediante pruebas de simulacion, se compara su desempe
no
con otras polticas y se eval
ua en varios escenarios.
Palabras clave: Redes inalambricas, Norma 802.16, Sistema de solicitud y gestion de
ancho de banda, Flujos transporte
A Jehov
a Dios, a Jesucristo,
a mis padres David y Gregoriana,
a mis hermanos Leopoldo y Nathaly,
a mis amigos, y a todas aquellas personas
que de cualquier manera contribuyeron
a que fuera posible este logro.
Indice
Indice de Tablas
ix
Indice de Figuras
Indice de Algoritmos
xiii
Agradecimientos
xiv
1 Introducci
on
1.1
Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1
Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2
Objetivos Especficos . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6
Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7
Distribucion del documento . . . . . . . . . . . . . . . . . . . . . . . .
1.8
Cronograma de Actividades . . . . . . . . . . . . . . . . . . . . . . . .
10
1.9
Cronograma de Evaluacion . . . . . . . . . . . . . . . . . . . . . . . . .
10
2 Marco Te
orico
11
2.1
Red
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Redes Inalambricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.1
12
Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
2.2.2
Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.3
Clasificacion de las redes inalambricas seg

un su cobertura . . . .
12
2.3
Funcionamiento de las redes inalambricas . . . . . . . . . . . . . . . . .
13
2.4
Multiplexacion por Division de Frecuencias Ortogonales (Orthogonal

Frequency Division Multiplexing u OFDM) . . . . . . . . . . . . . . . .
16
2.4.1
Descripcion del Smbolo OFDM en el dominio del tiempo . . . .
17
2.5
Calidad de servicio (Quality of Service o QoS) . . . . . . . . . . . . . .
18
2.6
WiMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.6.1
Tipos de QoS en WiMAX (IEEE 802.16) . . . . . . . . . . . . .
21
Estructura de la trama OFDM - TDD en WiMAX . . . . . . . . . . . .
22
2.7.1
Estructura de la Subtrama para el Enlace de Bajada . . . . . .
23
2.7.2
Estructura de la Subtrama para el Enlace de Subida
. . . . . .
24
Paquetes para solicitud de Ancho de Banda en WiMAX . . . . . . . . .
24
2.8.1
Tipos de BwReqs . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.8.1.1
Agregado . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.8.1.2
Incremental . . . . . . . . . . . . . . . . . . . . . . . .
25
Timer T16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Polticas que pueden ser utilizadas en el Sistema MSOAB de WiMAX .
26
2.9.1
RPG (Reset per Grant)
. . . . . . . . . . . . . . . . . . . . . .
27
2.9.2
DPG (Decrease per Grant) . . . . . . . . . . . . . . . . . . . . .
27
2.9.3
DDA (Decrease at Data Arrival ) . . . . . . . . . . . . . . . . .
27
2.7
2.8
2.8.2
2.9
2.9.3.1
iDDA (Decrease at Data Arrival with immediate BwReq

handling) . . . . . . . . . . . . . . . . . . . . . . . . .
2.9.3.2
dDDA (Decrease at Data Arrival with delayed BwReq

handling) . . . . . . . . . . . . . . . . . . . . . . . . .
2.10 Modelo
27
Interconexion
de
Sistemas
Abiertos
(Open
27
System
Interconnection u OSI) . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.11 Protocolo de Control de Transmision (Transmission Control Protocol o

TCP)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.11.1 Caractersticas del protocolo . . . . . . . . . . . . . . . . . . . .
32
2.11.2 Segmento TCP . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2.11.3 Detalles del funcionamiento de las conexiones TCP . . . . . . .
33
2.11.3.1 Apertura de la conexion . . . . . . . . . . . . . . . . .
34
2.11.3.2 Transferencia de datos . . . . . . . . . . . . . . . . . .
35
2.11.3.3 Cierre de la conexion . . . . . . . . . . . . . . . . . . .
36
2.11.4 Control de Congestion en TCP . . . . . . . . . . . . . . . . . .
36
2.11.5 Control de flujo . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3 Dise
no
40
3.1
Modelo de Gestion de Ancho de Banda con Retardo Aleatorio . . . . .
40
3.2
La poltica rDDA en funcionamiento . . . . . . . . . . . . . . . . . . .
41
3.2.1
Efecto de la poltica rDDA sobre el RTT de TCP . . . . . . . .
42
Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.3.1
Atributos de la clase . . . . . . . . . . . . . . . . . . . . . . . .
44
3.3.1.1
Parametro
. . . . . . . . . . . . . . . . . . . . . . .
44
3.3.1.2
Lista circular de Colas de BwReqs . . . . . . . . . . .
44
3.3.1.3
Valor i . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.3.1.4
Trama Actual . . . . . . . . . . . . . . . . . . . . . . .
45
Metodos de la clase . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.3.2.1
Metodo NuevoBwReqRecibido (BwReq) . . . . . . . . .
48
3.3.2.2
Metodo ObtenerAdBSolicitadoPorSS (IDcSS) . . . . .
48
3.3.2.3
Metodo ActualizarPercepcionAdB (IDcSS, AdBTransmit) 48
3.3.2.4
Metodo ActualizarTrama () . . . . . . . . . . . . . . .
51
3.3.2.5
Metodo InicilizarParametros(Tao) . . . . . . . . . . .
52
Planificacion del uso de ancho de banda de la trama . . . . . . . . . . .
52
3.4.1
Subtrama DL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.4.2
Subtrama UL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Discusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
3.3
3.3.2
3.4
3.5
4 Simulaciones y An
alisis de Resultados
4.1
57
Pruebas Realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.1.1
Entorno de Simulacion . . . . . . . . . . . . . . . . . . . . . . .
57
4.1.2
Parametros utilizados . . . . . . . . . . . . . . . . . . . . . . . .
58
4.1.3
4.1.4
Escenarios considerados . . . . . . . . . . . . . . . . . . . . . .
60
4.1.3.1
DATA solo modo Descarga . . . . . . . . . . . . . . .
60
4.1.3.2
DATA solo modo Carga . . . . . . . . . . . . . . . . .
60
4.1.3.3
Trafico de DATA en ambas direcciones . . . . . . . . .
61
Metricas observadas . . . . . . . . . . . . . . . . . . . . . . . .
61
4.1.4.1
61
4.1.4.2
Rendimiento Agregado . . . . . . . . . . . . . . . . . .
Indice de justicia de Jain . . . . . . . . . . . . . . . . .
61
4.1.4.3
Proporcion del Ancho de Banda utilizado del DL . . .
62
4.1.4.4
Proporcion del Ancho de Banda utilizado en el UL . .
62
4.1.4.5
Tasa de Envo de BwReqs . . . . . . . . . . . . . . . .
63
4.1.4.6
Proporcion BwReqs entregados . . . . . . . . . . . . .
63
4.1.4.7
Tasa de Colision de BwReqs . . . . . . . . . . . . . . .
63
4.1.4.8
Probabilidad de Colision de BwReqs . . . . . . . . . .
63
4.1.4.9
Tasa Agregada de Expiraciones del T16 . . . . . . . .
64
4.1.4.10 Tasa Media de Expiraciones del T16 . . . . . . . . . .
64
4.1.4.11 Promedio de Timeouts . . . . . . . . . . . . . . . . . .
64
4.1.4.12 Promedio de Paquetes Retransmitidos . . . . . . . . .
64
4.1.4.13 Promedio de BwReqs en Cola . . . . . . . . . . . . . .
65
4.1.4.14 Histograma de Frecuencia de la Cantidad de BwReqs

4.2
en Cola al momento de procesarla . . . . . . . . . . . .
65
Analisis de metricas y graficas obtenidas . . . . . . . . . . . . . . . . .
65
4.2.1
Escenario trafico de data en modo Descarga . . . . . . . . . . .
65
4.2.2
Escenario trafico de data en modo Carga . . . . . . . . . . . . .
71
4.2.3
Escenario Trafico Cruzado . . . . . . . . . . . . . . . . . . . . .
76
5 Conclusiones y Trabajos Futuros
81
5.1
Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.2
Beneficios con la implementacion de esta poltica en Redes WiMAX . .
82
5.3
Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
A Correcci
on en m
etrica de M
odulo MSOAB de WiMAX
84
Bibliografa
87
Indice de Tablas
2.1
Caractersticas de WiMAX . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.1
Parametros de la Simulacion . . . . . . . . . . . . . . . . . . . . . . . .
59
A.1 Datos de BwReqs en Escenario Descarga para la Poltica dDDA . . . .
86
ix
Indice de Figuras
1.1
Topologa de las Redes WiMAX . . . . . . . . . . . . . . . . . . . . . .
1.2
Metodologa en Cascada con Prototipos Evolutivos . . . . . . . . . . .
2.1
Clasificacion de las Redes Inalambricas seg

un su cobertura . . . . . . .
13
2.2
Conversiones bit a se
nal y luego de se
nal a bit, para transmision de datos
en redes inalambricas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
14
Comparacion entre FDM y OFDM respecto al uso del espectro de

frecuencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4
Prefijo cclico, en el tiempo de smbolo . . . . . . . . . . . . . . . . . .
18
2.5
Efecto de los esquemas de codificacion en el ancho de banda bruto

ofrecido en WiMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.6
Estructura de la trama en TDD . . . . . . . . . . . . . . . . . . . . . .
22
2.7
Espacios de tiempo entre subtramas: TTG y RTG . . . . . . . . . . . .
23
2.8
Estructura de la subtrama para el DL . . . . . . . . . . . . . . . . . . .
24
2.9
Estructura de la subtrama para el UL . . . . . . . . . . . . . . . . . . .
25
2.10 Polticas para el Manejo de la percepcion de Ancho de Banda . . . . .
28
2.11 Diagrama de Estados de la trama, polticas para el MPAB y sus

interacciones con la Tabla de Percepcion . . . . . . . . . . . . . . . . .
29
2.12 Capas seg

un modelo de referencia OSI . . . . . . . . . . . . . . . . . .
30
2.13 Fases de una conexion TCP . . . . . . . . . . . . . . . . . . . . . . . .
34
2.14 Slow Start Vs Congestion Avoidance . . . . . . . . . . . . . . . . . . .
37
2.15 Emision de paquetes en el tiempo con Slow Start y Congestion Avoidance 38

3.1
Funcionamiento de la poltica rDDA
. . . . . . . . . . . . . . . . . . .
42
3.2
Duracion de RTT y tiempo procesamiento de BwReq mnimos en rDDA
43
3.3
Atributos de la clase para rDDA . . . . . . . . . . . . . . . . . . . . . .
3.4
Diagrama de Secuencias: Metodos usados en el camino de un BwReq
45
con poltica rDDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.5
Diagrama de Actividades: Algoritmos descritos en este captulo . . . .
49
4.1
Topologa de WiMAX simulada . . . . . . . . . . . . . . . . . . . . . .
58
4.2
Comportamiento de la Ventana de Congestion para los nodos de la red

simulada de WiMAX con 3 SSs . . . . . . . . . . . . . . . . . . . . . .
60
4.3
Colisiones de BwReqs y Probabilidad de Colision . . . . . . . . . . . .
64
4.4
Graficas Escenario Descarga: Rendimiento, Fairness, y Proporcion de

Uso del Ancho de Banda . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.5
Ampliacion de Grafica de Rendimiento Agregado en Escenario Descarga
67
4.6
Graficas Escenario Descarga: Tasa de Envo y de Colision, Proporcion

BwReqs Entregados y Probabilidad de Colision . . . . . . . . . . . . .
4.7
Graficas Escenario Descarga: Expiraciones de T16, Paquetes TCP

Perdidos, Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8
69
Graficas Escenario Descarga: Cantidad de BwReqs en la Cola Actual al

Momento de Procesarla . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.9
68
70
Graficas Escenario Carga: Rendimiento, Fairness, y Proporcion de Uso

del Ancho de Banda . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.10 Graficas Escenario Carga: Tasa de Envo y de Colision, Proporcion

BwReqs Entregados y Probabilidad de Colision . . . . . . . . . . . . .
4.11 Graficas Escenario Carga:
73
Expiraciones de T16, Paquetes TCP
Perdidos, Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.12 Graficas Escenario Carga: Cantidad de BwReqs en la Cola Actual al

Momento de Procesarla . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.13 Graficas Escenario Trafico Cruzado:
Rendimiento,
Fairness,
75
Proporcion de Uso del Ancho de Banda . . . . . . . . . . . . . . . . . .
77
4.14 Graficas Escenario Trafico Cruzado: Tasa de Envo y de Colision,

Proporcion BwReqs Entregados y Probabilidad de Colision . . . . . . .
78
4.15 Graficas Escenario Trafico Cruzado: Expiraciones de T16, Paquetes

TCP Perdidos, Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.16 Graficas Escenario Trafico Cruzado: Cantidad de BwReqs en la Cola
5.1
Actual al Momento de Procesarla . . . . . . . . . . . . . . . . . . . . .
80
Uso del ancho de banda por UGS, rtPS y nrtPS . . . . . . . . . . . . .
83
Indice de Algoritmos
1
Recepcion de BwReq . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Procesamiento de cola actual, y Obtencion de AdB requerido por una SS
50
Actualizacion de la Tabla de Percepcion . . . . . . . . . . . . . . . . . .
51
Actualizacion de la trama . . . . . . . . . . . . . . . . . . . . . . . . . .
51
Inicializacion del parametro Tao . . . . . . . . . . . . . . . . . . . . . .
52
Planificacion de la subtrama DL . . . . . . . . . . . . . . . . . . . . . .
54
Planificacion de la subtrama UL . . . . . . . . . . . . . . . . . . . . . .
55
xiii
Agradecimientos
Principalmente, le doy gracias a Jehova Dios por cada da de vida que me regala,
por permitirme continuamente aprender muchas cosas, por su gua en el camino
de la vida, por la motivacion para continuar siguiendo adelante y por tantas cosas
que me provee (Hechos 17:24,28; Revelacion [o Apocalipsis] 4:11). Y tambien, a su
Hijo Jesucristo, que por medio de su sacrificio abrio el camino para una multitud de
bendiciones ahora y en el futuro, y que dejo un modelo perfecto junto con grandes
ense
nanzas que a
un hoy da siguen siendo provechosas y u
tiles para la vida (Juan 3:16).
Gracias a mis padres, David y Gregoriana, por sus ense
nanzas y correcciones
oportunas, que sin duda me han beneficiado muchsimo. Y tambien, por siempre
haber estado presente y apoyarme no solo durante la carrera, sino desde los primeros
pasos de mi vida, animandome constantemente para cumplir mis metas.
Gracias a mis queridos hermanos, Leopoldo y Nathaly, que me han apoyado a lo
largo de mis metas, incluso en esta. Indudablemente, su compa
na y consejos han
enriquecido mi vida.
Gracias al Profesor Andres Arcia por aceptarme para realizar esta tesis bajo su
tutora, por sus sugerencias, correcciones y disponibilidad para el avance de este
trabajo, y por su paciencia a lo largo del desarrollo de este.
Gracias al Profesor Demian Gutierrez por las sugerencias ofrecidas tanto para
algunos diagramas de este documento como para las laminas de la presentacion.
xiv
Gracias al Profesor Armando Borrero y al Profesor Gilberto Daz por las

correcciones dadas para la version final de este documento.
Gracias a mis amigos y compa
neros de Ingeniera, especialmente a los de sistemas,
que he conocido durante el camino hacia esta meta, por el tiempo y las experiencias
compartidas.
Gracias a los profesores que a lo largo de la carrera, han compartido sus
conocimientos en las distintas especialidades, y han ofrecido su ayuda con el fin de
facilitar el aprendizaje de sus respectivas areas.
Gracias a la Universidad de Los Andes por abrirme las puertas durante
aproximadamente siete a
nos.
Gracias a las personas relacionadas con la bibliografa de este documento, ya que
al hacer disponibles sus trabajos me facilitaron la comprension de los temas en los que
se baso este proyecto.
Y gracias a aquellas personas, que aunque no las mencione directamente aqu, me
apoyaron de alguna u otra forma en la trayectoria de la carrera universitaria.
Gracias a todos!
Captulo 1
Introducci
on
Cada vez crece mas la cantidad de usuarios que requiere comunicarse por medio de
Internet desde diversos lugares. Esta creciente necesidad ha hecho que los sistemas
de comunicacion digital evolucionen para prestar mejores servicios en transmisiones
de datos y para tener mayor alcance geografico. Actualmente, el servicio inalambrico
de gran alcance es cubierto por las redes celulares, las cuales transmiten sus datos a
bajas velocidades (no mas de 1 Mbps para tecnologas 3G), y a altos costos economicos.
Hoy da existen tecnologas que pretenden aumentar la velocidad de transmision
de los datos y a la vez tener celdas inalambricas de gran alcance, como es el caso
de las redes Worldwide Interoperability for Microwave Access (WiMAX) que tienen
mayor amplitud que otras redes de alta velocidad (como por ejemplo, WiFi) y que
son factibles para zonas de difcil acceso (como las zonas rurales), ya que los costos de
instalacion y mantenimiento all son menores en comparacion con las redes cableadas.
WiMAX es una tecnologa para el acceso inalambrico a la Internet de u
ltima milla,
con una cobertura de Area

Metropolitana (Wireless Metropolitan Access Network o
WMAN), definida bajo el Estandar IEEE 802.16 [1]. Dicho estandar establece las
condiciones de trabajo sobre una topologa punto a multipunto, donde una Estacion
Base (Base Station o BS) administra el recurso de ancho de banda para distribuirlo
entre Estaciones Suscriptoras (Subscriber Stations o SSs), a veces referidas tambien
n
1 Introduccio
como nodos (Vease la Figura 1.1). Los datos en estas redes se transmiten utilizando la
tecnica de propagacion OFDM (Orthogonal Frequency Division Multiplexing), tecnica
que permite hacer un mejor uso del espectro electromagnetico.
Figura 1.1: Topologa de las Redes WiMAX

WiMAX utiliza el concepto de Calidad de Servicio (Quality of Service o QoS),
que consiste en un trato especial que se le da a determinados flujo de paquetes,
otorgandole mayor prioridad o reservandole el enlace a dichos flujos, con el fin de
garantizar un servicio adecuado. En el Estandar IEEE 802.16a (WiMAX fijo), se
definen 4 niveles de QoS para estas redes: Unsolicited Grant Service (UGS), Realtime Polling Service (rtPS), Non-real-time Polling Service (nrtPS), y Best Effort (BE).
Para soportar servicios donde se requiere transmitir datos en ambas direcciones,
como los que utilizan la clase de servicio BE (por ejemplo, el de la Internet),
cada trama es dividida en dos partes: una para las transmisiones en el Enlace de
Bajada (DownLink o DL), el trafico que va de la BS a las SSs; y otra para las
transmisiones en el Enlace de Subida (UpLink o UL), el trafico que va de las SSs
a la BS. El trafico que circula en ambas subtramas es controlado y planificado por la BS.
1.1 Antecedentes
La asignacion de ancho de banda para el DL, es realizada en funcion de la llegada

de los paquetes a la BS, es decir, seg
un el trafico en las colas de la BS. La asignacion
para el UL, es realizada utilizando un sistema de gestion colaborativa de ancho de
banda (Mecanismo de Solicitud y Otorgamiento de Ancho de Banda o MSOAB), en
el que las SSs envan peque
nos paquetes de solicitud de ancho de banda (Bandwidth
Requests o BwReqs) a la BS, que luego son procesados por la BS para estimar las
necesidades de ancho de banda de las SSs en el UL, con lo cual se planifica el uso de
este enlace.
En base a lo anterior, la propuesta como proyecto de tesis consiste en un modelo
que mejore el rendimiento del trafico TCP que es transmitido usando la clase de
servicio BE en redes WiMAX. Se espera que este modelo maneje un mecanismo un
poco mas inteligente al actual (especialmente en la gestion del ancho de banda en el
UL), y mejor organizado en funcion de la cantidad de nodos conectados, de tal manera
que maximice el rendimiento global del sistema.
1.1
Antecedentes
WiMAX esta definido bajo la norma IEEE 802.16 [1] siguiendo el modelo de referencia
Interconexion de Sistemas Abiertos (Open System Interconnection u OSI )1 . En el
Estandar de WiMAX se definen los parametros, las tecnicas de control de acceso al
medio y las caractersticas de la capa fsica, que describen el funcionamiento de estas
redes inalambricas. Esta norma fue publicada inicialmente el 8 de abril de 2002, y
desde entonces se han a
nadido varias extensiones para abarcar nuevas caractersticas
(como por ejemplo, la movilidad en IEEE 802.16e).
Como se menciono anteriormente, WiMAX utiliza el MSOAB para la asignacion
del ancho de banda en el UL. En este sistema, las SSs solicitan ancho de banda para
1
El modelo OSI se explicar

a en la Seccion 2.10
1.1 Antecedentes
transmitir datos a traves de BwReqs, que son enviados a la BS durante un perodo de

contencion; luego, la BS procesa estos paquetes para estimar la cantidad de ancho de
banda que necesitan, y planifica el uso del UL de acuerdo a la demanda percibida de
las SSs. La gestion de los BwReqs se puede realizar de diferentes formas.
En [17], Arcia y otros consiguieron que las transmisiones de datos en Redes
WiMAX se pueden mejorar concentrandose en el sistema de manejo de la percepcion
de las necesidades de ancho de banda. Ellos observaron la existencia de algunos
problemas en la gestion de ancho de banda, relacionados con la administracion de
BwReqs. Mediante simulacion, evaluaron el desempe
no de varias polticas para el
manejo de los BwReqs y observaron una notable reduccion en probabilidad de colision
de los BwReqs, y una mejora en el rendimiento agregado de los flujos transporte.
Algunas de las polticas evaluadas fueron iDDA y dDDA2 . Los investigadores se
enfocaron en la clase de servicio BE para trafico TCP.
Por otra parte, respecto al tama
no del perodo de contencion, Cho y otros [21]
muestran en su estudio que el rendimiento maximo para un n
umero N de conexiones
BE en el UL, se alcanza cuando el tama
no de la ventana de contencion (n
umero
de slots) es igual a N. Tambien, Ni y otros [27] estudiaron el n
umero promedio de
slots necesarios para enviar exitosamente BwReqs, usando perodo de contencion o
unicast polling. Ellos obtuvieron, que para un tama
no de ventana de contencion
fijo, el uso del perodo de contencion (multicast) es mas eficiente que unicast polling
(unidifusion) cuando la tasa de envo de BwReqs es baja; mientras que cuando
el canal esta congestionado el rendimiento se degrada, por lo que es mas eficiente
multicast/broadcast cuando la tasa de envo de BwReqs es alta [17].
Vinel [30], propone agrupar las conexiones de las necesidades de ancho de
banda por SSs para reducir el n
umero total de BwReqs, y para mejorar el delay
promedio utilizado para transmitir exitosamente BwReqs. Igualmente Delicado [22],
ha encontrado que esta optimizacion mejora el rendimiento del UL, a cambio de
2
Estas polticas se describen en la Seccion 2.9
1.2 Planteamiento del Problema
informacion detallada de las conexiones individuales. En [24] los autores proponen

dividir el perodo de contencion en dos subconjuntos que no se superponen. El primer
perodo se utiliza para enviar nuevos BwReq, y el segundo para resolver colisiones. Con
esto se puede disminuir el delay promedio para transmitir BwReqs, en comparacion
con BEB (Binary Exponential Backoff ) [17].
Con el objetivo de reducir el jitter y delay indeseados (por perdidas de BwReqs)
producido por el sistema MSOAB, Mojdeh y otros [25] proponen un metodo de
prevision basado en minera de datos para mejorar el rendimiento del UL para trafico
en tiempo real. Sin embargo, existe el riesgo de sobreestimar el ancho de banda
necesario, lo que produce una subutilizacion del UL [17].
Este trabajo refleja la continuacion de lo reportado por Arcia y otros [17] [29] [26]
[31]. Esta tesis trabaja sobre el mecanismo de gestion de la percepcion del ancho de
banda, el cual ha sido muy poco estudiado en la bibliografa relacionada. Mucho se
ha dicho sobre los planificadores o el calculo del perodo de contencion, pero no sobre
la gestion de la percepcion. En resumen, nos concentramos en puntos relevantes del
complicado sistema de gestion de la percepcion de consumo de ancho de banda y como
fue implementado.
1.2
Planteamiento del Problema
Al aumentar la cantidad de nodos conectados a una red, se aumenta la demanda de

los recursos que esta provee (como el ancho de banda), lo que hace que la asignacion
de recursos sea complicada, y que por ende, el rendimiento del sistema se vea
comprometido [26].
1.3 Objetivos
1.3
Objetivos
1.3.1
Objetivo General
Dise
nar e implementar un modelo para mejorar la gestion de recursos de ancho de
banda en Redes WiMAX.
1.3.2
Objetivos Especficos
Comprender y desarrollar la representacion de la capa fsica OFDM en el marco

del modelo de referencia OSI.
Comprender la transmision de trafico Best Effort en Redes WiMAX.
Desarrollar un modelo de gestion de ancho de banda.
1.4
Justificaci
on
El interes en redes inalambricas de mayor velocidad y mayor alcance geografico para

el acceso a la Internet. De ah que, con la implementacion de este sistema, se espera
prestar un mejor servicio de Redes 802.16 al atender las necesidades de un mayor
n
umero de usuarios de trafico TCP, el cual representa el grueso de las transmisiones
de datos en la Internet (aproximadamente 90%) [19].
1.5
Metodologa
Los sistemas de redes TCP/IP estan orientados al modelo OSI de referencia compuesto
por 7 capas: aplicacion, sesion, presentacion, transporte, red, enlace y fsica. El
sistema desarrollado se enfoco principalmente en las dos primeras capas de dicho
modelo, es decir, la capa fsica y la capa de enlace. Esta aproximacion a la solucion
del problema, se enmarca dentro de un enfoque de abajo hacia arriba (o bottom-up)
para la construccion del modelo simulado. Debido a la independencia de las capas y
a la funcionalidad requerida del sistema, este enfoque facilito la implementacion del
nuevo mecanismo de gestion de ancho de banda que, tambien puede ser visto como un
1.5 Metodologa
mecanismo de administracion de la capa fsica.

Para la consecucion del objetivo final, se realizaron las siguientes tareas previamente
al desarrollo del software:
Lecturas de material del estado del arte en Redes 802.16 (WiMAX). Revision
bibliografica de las capas fsicas disponibles para Redes WiMAX (OFDM y
OFDMA).
Familiarizacion con el simulador de redes. Comprension del modelo existente para
Redes WiMAX fijo (802.16a). Uso del modelo de simulacion para transmision de
datos: TCP-LAB.
Para el desarrollo del software se tomo como referencia el modelo en cascada3
basado en prototipos evolutivos, con realimentaciones cuando fue necesario (Vease
la Figura 1.2).
Entre las fases resaltantes de esta metodologa de desarrollo de software resaltan:
An
alisis de requerimientos:
En esta parte inicial de la implementacion del software, se discutieron y plantearon
tanto las caractersticas que deba poseer el modelo de simulacion como las necesidades
que deba satisfacer, con el fin de que representara adecuadamente las Redes WiMAX.
Dise
no del sistema:
Seguidamente, se planteo la estructura del modelo de simulacion, identificando las
clases principales y observando la relacion entre ellas. En esta parte fue necesario
hacer ingeniera inversa para comprender mejor el modelo del Mecanismo de Solicitud
y Otorgamiento de Ancho de Banda de WiMAX implementado por Paltrinieri [29], que
sirvio como soporte de la nueva poltica implementada.
3
El origen del modelo en cascada se atribuye a Winston W. Royce por realizar la primera descripci
on
formal de este modelo en el artculo Managing the Development of Large Software Systems [2]
publicado en 1970 [3]
1.5 Metodologa
Figura 1.2: Metodologa en Cascada con Prototipos Evolutivos
Codificaci
on:
Luego de obtener el dise
no, se implemento en codigo fuente C++ y como scripts en
TCL el modelo obtenido, con el objetivo de utilizarlos en la herramienta de simulacion
de redes Network Simulator 2 (NS2 ) [4].
Pruebas:
Teniendo el modelo ya implementado, se realizaron varias pruebas. Inicialmente, se
realizaron nuevamente las simulaciones ya obtenidas por Arcia y otros [17] [29] [26],
para verificar que las modificaciones y el anexo del nuevo codigo no afectara el
correcto funcionamiento del modulo MSOAB de WiMAX. Luego de ello, se realizaron
propiamente las pruebas del modelo implementado, pasandole los parametros definidos
para la topologa simulada y para los casos de estudio (escenarios de prueba). Esta
parte se detallara mas en la Seccion 4.1, y los resultados obtenidos se mostraran en la
Seccion 4.2.
1.6 Alcance
Para todas las fases, incluyendo las anteriores al desarrollo del modelo, se realizaron
reuniones regulares sobre el avance del proyecto para la crtica colectiva dentro del
grupo de investigacion.
1.6
Alcance
Se dise
no e implemento un modelo de simulacion en Network Simulator 2 (NS2 ),
que gestiona de ancho de banda en Redes WiMAX, enfocandose principalmente en la
administracion y percepcion de la necesidad de este recurso en el UL. Se centro en la
clase de servicio Best Effort para el manejo de trafico TCP.
1.7
Distribuci
on del documento
En el captulo 2 se define el Marco Teorico, donde se explican algunos conceptos

teoricos relevantes y necesarios para situar al lector en el contexto del tema del
proyecto de grado. Se consideran detalles sobre el Estandar de WiMAX, el protocolo
TCP, entre otros puntos principales de las redes inalambricas.
El Dise
no se presenta en el captulo 3, donde se define y especifica la nueva poltica
para gestion del ancho de banda en WiMAX, que es el modelo presentado en esta
tesis. Se describen las clases implementadas, los algoritmos usados, y la interaccion
entre estos para mostrar el funcionamiento de la nueva poltica, para ello se usan
diferentes diagramas.
En el captulo 4 se muestran las Simulaciones y el Analisis, donde se dan detalles
acerca de los parametros definidos para la topologa y para los casos de prueba, as
como las metricas consideradas para el estudio. Tambien se exponen los resultados
obtenidos de las simulaciones, y sus respectivos analisis.
Finalmente, se presentan las Conclusiones extradas del estudio presentado en este
proyecto, y algunos Trabajos Futuros que se pueden realizar para darle continuidad al
1.8 Cronograma de Actividades
10
mismo.
1.8
Cronograma de Actividades
Introduccion a la simulacion de redes a eventos discretos con NS-2 (2 semanas).

Ingeniera en reversa del sistema de gestion de solicitud/otorgamiento de ancho
de banda (modulo MSOAB) de WiMAX (3 semanas).
Modelado y ampliacion del sistema MSOAB de WiMAX (3 semanas).
Implementacion del subsistema de demora aleatoria de solicitudes para manejo
de alto trafico TCP (3 semanas).
Construccion del escenario de prueba (2 semanas).
Evaluacion del desempe
no del subsistema de demora aleatoria (1 semana).
Redaccion del manuscrito (4 semanas).
1.9
Cronograma de Evaluaci
on
1. Reuniones semanales de avance con el Tutor.

2. Reportes cortos semanales sobre avances de la tesis (Total: 18 reportes).
3. Avance del proyecto a los jurados (semana 9).
4. Entrega de la primera version del proyecto de grado (semana 15) para el semestre
B-2011.
5. Entrega final del proyecto de grado en la semana 18.
6. Defensa del proyecto de grado.
Captulo 2
Marco Te
orico
2.1
Red
Una red es un conjunto de dos o mas nodos (computadores) conectados entre s, con
el fin de compartir informacion y/o recursos entre ellos. La conexion entre los nodos,
puede ser por medio de cables (redes cableadas) o por medio de ondas de radio (redes
inalambricas) [5].
Las redes de computadores son el resultado de la evolucion de dos ramas cientficas
y tecnologicas: la computacion y las telecomunicaciones. Esto, debido a que pueden
considerarse como un sistema particular de computo distribuido, en el que los nodos
que componen la red realizan tareas interrelacionadas por medio de intercambio de
datos, y a la vez, estas redes pueden verse como un medio de transferir datos entre
grandes distancias [35].
2.2
Redes Inal
ambricas
Las redes inalambricas presentan caractersticas relevantes, que son u

tiles evaluarlas
para ver su factibilidad a la hora de implementar redes de computadores.
continuacion se mencionan las ventajas y las desventajas mas resaltantes que
mbricas
2.2 Redes Inala
12
presentan estas redes en comparacion con las cableadas:
2.2.1
Ventajas
Movilidad
Facilidad en la instalacion
Escalabilidad
Poca Complejidad en su Administracion
Adaptabilidad a casi cualquier estructura
2.2.2
Desventajas
Menor velocidad
Menor seguridad (si no se configuran bien)
Sensibilidad a interferencias
2.2.3
Clasificaci
on
de
las
redes
inal
ambricas
seg
un
su
cobertura
Seg
un el area de cobertura en la que un usuario puede estar conectado, las redes
inalambricas se pueden clasificar en cuatro tipos principales (Vease la Figura 2.1) [6]:
Redes Inal
ambricas de Area
Personal (WPAN): Son redes de corto alcance
que cubren pocas decenas de metros. Generalmente son usadas para conectar
dispositivos perifericos en oficinas (como impresoras, telefonos moviles, etc.).
Entre las tecnologas de este tipo estan: Bluetooth, HomeRF, Zigbee y conexiones
Infrarrojas.
mbricas
2.3 Funcionamiento de las redes inala
13
Figura 2.1: Clasificacion de las Redes Inalambricas seg

un su cobertura
Redes Inal
ambricas de Area
Local (WLAN): Estas redes cubren el
equivalente a la red local de una empresa, tienen un alcance aproximado de
100 metros. Las tecnologas de este tipo son: WiFi y HiperLAN2.
Redes Inal
ambricas de Area
Metropolitana (WMAN): Estas redes
cuentan con un alcance de 4 a 10 km, y son muy u
tiles para las empresas de
telecomunicaciones. Ejemplo de este tipo de redes: WiMAX.
Redes Inal
ambricas de Area
Extensa (WWAN): Estas redes tienen el
alcance mas amplio de todas las redes inalambricas, razon por la cual los telefonos
celulares utilizan estas redes. Ejemplos: GSM, GPRS, UMTS (3G).
2.3
Funcionamiento de las redes inal

ambricas
En las computadoras la informacion se maneja usando una forma logica (es decir,
a nivel de software), que para facilitar la representacion son las secuencias de bits
(combinaciones de 0s y 1s). Sin embargo, cuando se desea compartir la informacion
entre al menos dos nodos, es necesario utilizar una representacion que se pueda
transmitir en un canal, que en el caso de las redes inalambricas, ese canal es el aire.
La forma fsica que se utiliza transmitir datos por medio del aire, es a traves de las
mbricas
14
se
nales de ondas electromagneticas.
El emisor debe convertir la informacion a algo fsico, transformar los bit a se
nales
utilizando alg
un tipo de equivalencia, y colocarla en el canal para su envo; luego el
receptor, debe tomarla del canal, y convertirla nuevamente a la forma logica, haciendo
una transformacion (inversa) de se
nales a bits (Vease la Figura 2.2).
Figura 2.2: Conversiones bit a se

nal y luego de se
nal a bit, para transmision de datos
en redes inalambricas
En las redes inalambricas se transmite la informacion entre sus nodos utilizando
ondas electromagneticas, que dependiendo de la frecuencia que utilicen, pueden ser
opticas, de microondas o de radio [6] [7]. Las ondas electromagneticas se generan
mediante la aplicacion de corriente alterna a una antena. Estas redes utilizan una
parte del espectro electromagnetico para transmitir sus se
nales a una frecuencia
determinada. Las distintas tecnologas inalambricas se diferencian por la frecuencia
de transmision que utilizan, y por el alcance y la velocidad de sus transmisiones [6].
Mas especficamente, la informacion se transmite sobre ondas portadoras de
radio a traves del aire. El emisor agrega la informacion (previamente transformada,
codificada) a una onda de radio. El receptor analiza las ondas recibidas y extrae los
datos u
tiles que le permiten reconstruir la informacion que fue enviada.
Una analoga para entender el concepto de frecuencia portadora se muestra en
Reid [34, pag.
45], donde dice que si uno estuviera usando una impresora, la
mbricas
15
frecuencia portadora seria el papel y la informacion modulada seran las letras en

el papel. En otras palabras, la frecuencia portadora de onda no transporta por s
misma la informacion, sino que esta viaja a traves de la frecuencia portadora, de ah
el significado de su nombre.
Antes de ser colocada sobre el canal, la informacion es transformada en algo que
se pueda transmitir y recibir a traves de una frecuencia portadora de onda para poder
ser enviada por el canal de transmision, a esto se le llama modulacion (o esquema
de modulacion) [34]. Esto a su vez permite un mejor aprovechamiento del canal de
comunicacion, y una minimizacion de las interferencias y el ruido [8].
La modulacion se hace variando la forma de onda de una se
nal, con cambiar al
menos una de las 3 principales caractersticas de las ondas, como lo son: la amplitud,
la frecuencia y la fase.
Los flujos de datos pueden ser modulados de distintas formas, que dependera de la
robustez, la perdida de datos y la simplicidad del esquema para poder tener una mayor
tasa de transmision. Los esquemas de modulacion mas comunes son: BPSK (Binary
Phase Shift Keying), QPSK (Quadrature Phase Shift Keying) y QAM (Quadrature
amplitude modulation).
Es necesario tambien, seleccionar una tecnica de propagacion de las ondas, para
transmitir la informacion (se
nales moduladas) entre una variedad de canales [34, pag
50].
Las tecnicas de propagacion de las ondas mas comunes son: el Espectro
Extendido de Secuencia Directa (Direct-Sequence Spread Spectrum o DSSS ), El

Espectro Extendido de Saltos de Frecuencia (Frequency Hopping Spread Spectrum o
FHSS ), el Acceso Multiplexado de Division de Codigos (Code Division Multiple Access
o CDMA), y la Multiplexacion por Division de Frecuencias Ortogonales (Orthogonal
Frequency Division Multiplexing o OFDM ) [34].
n por Divisio
n de Frecuencias Ortogonales (Orthogonal Frequency
2.4 Multiplexacio
Division Multiplexing u OFDM)
2.4
16
Multiplexaci
on por Divisi
on de Frecuencias
Ortogonales (Orthogonal Frequency Division
Multiplexing u OFDM)
OFDM fue patentado en 1970, por los Laboratorios Bell. El principio fundamental
de esta tecnica es descomponer la tasa del flujo completo de datos en N flujos de
datos mas peque
nos para transmitirlos simultaneamente en N subportadoras. Para
ello, se divide un canal de frecuencias en N bandas de frecuencias de igual espacio,
lo que permite tener varias bandas transmitiendo simultaneamente a diferentes
frecuencias. En cada banda se transmite una subportadora que transporta una parte
de la informacion previamente modulada [9] [33].
Esta basada en FDM (Frequency Division Multiplexing), pero OFDM aprovecha las
ventajas de las ondas ortogonales. En el dominio de la frecuencia, las subportadoras
son ortogonales entre si, es decir, cada subportadora es ortogonal a las subportadoras
adyacentes, lo que permite el solapamiento entre subportadoras sin afectarse los
datos transportados por ellas debido a interferencias. Esa ortogonalidad se basa en
una relacion matematica precisa entre las frecuencias de las subportadoras, lo que
garantiza la separacion entre subportadoras en el extremo receptor, y lleva a una mejor
aprovechando del espectro al reducir el ancho de banda necesario para transmitir los
datos en comparacion con FDM [10] [33].
En la Figura 2.3, se puede observar la comparacion entre el uso del espectro
con FDM y con OFDM. Se puede apreciar que OFDM aprovecha mejor el espacio
del espectro teniendo un mayor n
umero de subportadoras para un mismo rango de
frecuencias. En las graficas se puede observar la ventaja dada por la ortogonalidad
de las subportadoras de OFDM, donde la frecuencia central de cada una de las
subportadoras no recibe interferencia de otros canales adyacentes [33].
Debido a estas caractersticas de OFDM, se pueden tener enlaces de transmision de
n por Divisio
n de Frecuencias Ortogonales (Orthogonal Frequency
2.4 Multiplexacio
Division Multiplexing u OFDM)
17
Figura 2.3: Comparacion entre FDM y OFDM respecto al uso del espectro de
frecuencias
datos a altas velocidades, recuperacion de la informacion entre las distintas se
nales con
diferentes retardos y amplitudes con resistencia a interferencias y a desvanecimientos
por multicaminos [10].
Algunas tecnologas que utilizan esta tecnica de propagacion de las ondas por el
canal son: DSL (Digital Subscriber Line), HIPERLAN 2, Wi-Fi (Estandar 802.11a y
802.11g), WiMAX (Estandar 802.16).
2.4.1
Descripci
on del Smbolo OFDM en el dominio del
tiempo
La forma de onda en el dominio del tiempo de OFDM es originada por la Transformada

Inversa de Fourier; esa relacion de tiempo obtenida, equivale al tiempo u
til de smbolo
T b. Para eliminar la interferencia multicamino se establece el uso de un Prefijo Cclico
(Cyclic Prefix o CP ), el cual corresponde a la u
ltima parte del simbolo u
til OFDM, que
2.5 Calidad de servicio (Quality of Service o QoS)
18
se antepone al comienzo del smbolo transmitido. Este intervalo que se agrega, es una
muestra de duracion T g del perodo u
til del smbolo, que ayuda con la preservacion
de la ortogonalidad entre las subportadoras moduladas, y por ende, ayuda a evitar las
interferencias [9] [33] (Vease la Figura 2.4).
Figura 2.4: Prefijo cclico, en el tiempo de smbolo
2.5
Calidad de servicio (Quality of Service o QoS)
La Calidad de Servicio (QoS) es un trato especial que se le da a determinados flujos

de paquetes, con el fin de garantizar que el servicio que esos flujos soportan, pueda
cumplir con los requerimientos mnimos de funcionamiento, como por ejemplo cierto
nivel de latencia. Para ello, los flujos de datos, pueden recibir prioridad en el uso del
enlace, o exclusividad (reservacion del enlace). Esta caracterstica se establece en la
capa 2 (capa de enlace de datos) del modelo de referencia OSI [11] [12].
Cuando la red trasporta diferentes tipos de trafico, es necesario realizar esta
diferenciacion de flujos para proveerles un mejor servicio a las distintas aplicaciones.
Por ejemplo, para garantizar el buen funcionamiento de una aplicacion de video
conferencia se le debe dar mayor prioridad al trafico que transporta sus flujos de datos,
en comparacion con la prioridad que se le dara a los flujos de datos de una aplicacion
de correo electronico.
2.6 WiMAX
2.6
19
WiMAX
WiMAX (Worldwide Interoperability for Microwave Access) significa Interoperabilidad

Mundial para Acceso por Microondas. Es una tecnologa para el acceso inalambrico
a la Internet de u
ltima milla con una cobertura de area metropolitana (WMAN). Fue
creado por las empresas Intel y Alvarion en 2002 y ratificado por el IEEE (Instituto
de Ingenieros Electricos y Electronicos). El estandar que lo define, IEEE 802.16 [1],
ha sido trabajado constantemente. Entre algunas de las extensiones hechas a este
estandar destacan, la 802.16a para WiMAX fijo y la 802.16e que ofrece movilidad. En
mayo de 2009 se aprobo una revision al Estandar publicado en 2004 [13], que dejo
obsoleta esa version.
La topologa fsica de WiMAX es punto a multipunto, en la cual una BS es
la responsable de la asignacion y distribucion del ancho de banda entre diversas
SSs.
Cada trama puede ser individualmente dividida para trafico bidireccional,
sea por tiempo (Time Division Duplexing o TDD) o por frecuencia (Frequency
Division Duplexing o FDD). Una de las subtramas obtenidas es para uso del DL, que
corresponde a las transmisiones que van desde la BS hacia las SSs; y la otra subtrama
para el UL, para el trafico de datos que va de las SSs a la BS1 .
Para cada conexion unidireccional entre SS y BS, y viceversa, se asignan
identificadores (IDcSS) que sirven como una direccion temporal y permiten darles
tratos particulares a dichas conexiones. Entre las caractersticas que estan asociada a
los IDcSS, estan: el nivel de calidad de servicio (QoS), la modulacion, entre otros. El
estandar soporta cuatro esquemas de modulacion: BPSK, QPSK, 16-QAM y 64-QAM
(Vease la Figura 2.5). WiMAX utiliza la tecnica de propagacion OFDM, con el fin de
utilizar mejor el espectro electromagnetico. En la Tabla 2.1 se resumen estas y otras
caractersticas2 de WiMAX [1] [23].
1
2
En la Secci
on 2.7 se muestra c
omo esta conformada cada subtrama para TDD
Los valores de frecuencia, velocidad y rango son tomados de [12]
2.6 WiMAX
20
Figura 2.5: Efecto de los esquemas de codificacion en el ancho de banda bruto ofrecido
en WiMAX
Caracterstica
Nombre
WiMAX (Worldwide Interoperability for

Microwave Access)
Estandar
IEEE 802.16
Inicio del Estandar

Tipo de cobertura
A
no 2002
Area
metropolitana
Topologa fsica
Punto - Multipunto (Vease la Figura 1.1)
Frecuencia
2-11 GHz (3.5 GHz en Europa)
Velocidad aproximada
75 Mbps
Rango cobertura
10 kilometros
Niveles
de
Calidad
de
Servicio (QoS)
Unsolicited Grant Services (UGS), RealTime Polling Service (rtPS), Non Real-Time
Polling Service (nrtPS), Best Effort (BE),
Extended Real-Time Polling Service (ErtPS)
Tecnicas
de
modulacion
BPSK, QPSK, 16-QAM, 64-QAM
soportadas
Tecnicas de propagacion
OFDM
Formas
TDD, FDD
de
transmision
d
uplex soportadas
Tabla 2.1: Caractersticas de WiMAX
2.6 WiMAX
2.6.1
21
Tipos de QoS en WiMAX (IEEE 802.16)
WiMAX tiene la capacidad de ofrecer distintos niveles de calidad de servicio para

soportar diferentes tipos de aplicaciones. Seg
un lo especificado en el Estandar 802.16
[1], para las Redes WiMAX se definen cinco niveles de QoS [20] [28] [23]:
Unsolicited Grant Service (UGS): Se provee ancho de banda sin solicitarlo
y de forma regular. Este servicio esta dise
nado para soportar aplicaciones en
tiempo real con generacion de flujos de datos constante, con paquetes de tama
no
fijo emitidos a intervalos periodicos de tiempo. Algunos ejemplos son Voz IP y
E1/T1.
Real-Time Polling Service (rtPS): Se provee ancho de banda bajo solicitud
de la SS corriendo aplicaciones en tiempo real, en cuyo caso el planificador
de la BS respeta ciertas restricciones de tiempo. Este servicio esta dise
nado
para soportar flujos de datos con velocidad variable, que llevan paquetes de
tama
no variable emitidos a intervalos periodicos de tiempo. Como ejemplos de
aplicaciones que usan este servicio estan: Video MPEG y Streaming Audio/Video.
Non-Real-Time Polling Service (nrtPS): A diferencia del anterior las
condiciones de cumplimiento de la asignacion del ancho de banda se relajan un
poco. Este servicio esta dise
nado para soportar flujos de datos con tolerancia
a retrasos, y con tama
no de paquetes variables, para los que se requiere una
velocidad mnima de transmision.
En algunos casos es deseable limitar la
velocidad maxima para los flujos que utilizan este servicio. Un ejemplo de ello es
FTP.
Best Effort (BE): No se ofrece ning
un tipo de garanta y por lo general se
utiliza el ancho de banda que dejan disponible las otras clases de servicio. Este
servicio esta dise
nado para soportar flujos de datos para los que no cuentan
con requisitos estrictos para el servicio y pueden ser manejados en funcion de
los recursos disponibles. Con este nivel de servicio se transmite el trafico de la
Internet (Aplicaciones HTTP ).
2.7 Estructura de la trama OFDM - TDD en WiMAX
22
Extended Real-Time Polling Service (ErtPS): Combina las eficiencias de

los servicios UGS y rtPS, y sirve para procesos de aplicacion con requerimientos
de ancho de banda que pueden cambiar con el tiempo. Este servicio esta dise
nado
para las aplicaciones en tiempo real con flujo de datos de velocidad variable, que
tiene requisitos mnimos en ancho de banda y demora. Esta definido para el
estandar 802.16e-2005 (WiMAX movil). Una aplicacion que puede usar este
servicio es Voz IP con supresion de silencios.
2.7
Estructura de la trama OFDM - TDD en

WiMAX
Uno de los esquemas de duplexacion que soporta WiMAX es el TDD (Time Division
Duplex ), que consiste en dividir cada trama en dos partes, una para las transmisiones
en el DL y otra para las transmisiones en el UL, ambas transmitiendo a la misma
frecuencia pero en diferentes tiempos (Vease la Figura 2.6). La duracion de la trama
es de tama
no fijo, y la distribucion de esta para cada subtrama puede ser adaptada
por la BS dependiendo de la demanda de los recursos, es decir, seg
un la necesidad de
ancho de banda requerida por la red [1].
Figura 2.6: Estructura de la trama en TDD

Al final de cada subtrama, existen espacios de tiempo que sirven para que la BS
2.7 Estructura de la trama OFDM - TDD en WiMAX
23
y las SSs cambien de direccion en la transmision, es decir, para que las que esten
recibiendo datos pasen a transmitir, y las que esten transmitiendo pasen a recibir.
Estos intervalos son: el TTG (Base Station Transmit/Receive Transition Gap) que
es cuando se cambia de la subtrama DL a la UL, lo que lleva a que la BS pase
de transmitir a recibir y las SSs de recibir a transmitir; y el RTG (Base Station
Receive/Transmit Transition Gap) que es cuando se cambia de la subtrama UL a la
subtrama DL, lo que ahora implica que la BS pasa de recibir a transmitir y las SSs de
transmitir a recibir (Vease la Figura 2.7) [1].
Figura 2.7: Espacios de tiempo entre subtramas: TTG y RTG

Cada subtrama, tanto la del DL como la del UL, se subdivide adicionalmente
en intervalos mas peque
nos para separar los envos seg
un los tipos de paquetes. A
continuacion, veamos la conformacion de cada una de esas subtramas.
2.7.1
Estructura de la Subtrama para el Enlace de Bajada
La subtrama del DL, inicia con un intervalo de preambulo que utiliza la capa fsica
(capa 1 seg
un modelo OSI) para sincronizacion y ecualizacion. Luego, le sigue la
seccion de control, la cual contiene los mensajes DL MAP y UL MAP que seran
enviados a todas las SSs que pertenecen a la red. Estos paquetes indican donde
comienzan los flujos particulares tanto para el DL como para el UL. Continua con un
perodo distribuido en TDM (Time Division Multiplexing) para la data que va de la
BS hacia las distintas SSs. Esta parte de la subtrama esta organizada en rafagas de
forma decreciente seg
un la robustez indicada en el respectivo perfil. De forma que se
transmiten primero las que indican codificacion QPSK, luego los de 16-QAM, despues
2.8 Paquetes para solicitud de Ancho de Banda en WiMAX
24
64-QAM, etc. La subtrama DL finaliza con el TTG (Vease la Figura 2.8) [1].
Figura 2.8: Estructura de la subtrama para el DL
2.7.2
Estructura de la Subtrama para el Enlace de Subida
La subtrama UL es utilizada por las SSs para transmitir mensajes a la BS. En esta
subtrama encontramos tres partes para los principales tres tipos de paquetes. La
subtrama comienza con un perodo inicial de registro (Initial Ranging), en el que
nuevas SSs solicitan unirse a la red. Luego continua con un perodo de contencion
(Request Contention), en el que las SSs que ya estan registradas, solicitan ancho
de banda para el uso del UL. Despues de ello, viene el perodo dividido para
transmisiones de paquetes de data o de ACKs de las SSs (Scheduled Data), donde
estos nodos hacen uso del ancho de banda seg
un lo informado a las SSs mediante
el UL-MAP (donde se indica la previa planificacion del UL realizado por la BS).
Entre cada una de esas transmisiones de las SSs, se colocan peque
nos espacios de
tiempo llamados SSTG (Subscriber Station Transition Gap), para sincronizar las
SSs y evitar interferencias. Esta subtrama finaliza con el RTG (Vease la Figura 2.9) [1].
2.8
Paquetes para solicitud de Ancho de Banda en

WiMAX
WiMAX posee un mecanismo que le permite a las SSs indicarle a la BS la cantidad de

ancho de banda que necesitan para transmitir paquetes de datos o de ACKs en el UL.
2.8 Paquetes para solicitud de Ancho de Banda en WiMAX
25
Figura 2.9: Estructura de la subtrama para el UL

Para ello durante un perodo de contencion disponible en cada trama, las SSs pueden
enviar peque
nos paquetes llamados Bandwidth Requests o BwReqs, para pedir ancho
de banda en terminos de la cantidad de bytes que requiere la SS para este enlace [1].
2.8.1
Tipos de BwReqs
Seg
un la forma como se expresa la cantidad de ancho de banda que necesita la SS en
el BwReqs, se pueden definir dos tipos de BwReqs: Agregado o Incremental.
2.8.1.1
Agregado
El BwReq indica la cantidad de ancho de banda total que requiere la SS, lo que hace
que la BS sustituya el valor de la tabla por que indica el BwReq.
2.8.1.2
Incremental
El BwReq indica la cantidad de ancho de banda que la SS necesita para transmitir

en ese momento, lo que hace que la BS sume esta cantidad a la percepcion que esta
actualmente en la tabla.
2.8.2
Timer T16
Es un parametro de WiMAX que indica el tiempo que debe esperar una SS por la
respuesta de un BwReq enviado a la BS, antes de dar por perdido ese paquete. Al
expirar este Timer, la SS puede realizar la solicitud de ancho de banda nuevamente,
enviando otro BwReq. Seg
un el Estandar de WiMAX el valor mnimo para este timer
2.9 Polticas que pueden ser utilizadas en el Sistema MSOAB de WiMAX
26
es de 10 ms [1].
De manera analoga al T16, para el perodo inicial de registro esta el timer T3, el
cual es el tiempo de espera de las SSs para dar por perdida una solicitud de registro
en la red. En el Estandar 802.16 se establece este valor por omision en 200 ms [1].
2.9
Polticas que pueden ser utilizadas en el

Sistema MSOAB de WiMAX
El Mecanismo de Solicitud y Otorgamiento de Ancho de Banda (MSOAB) es un

sistema de gestion colaborativa para la administracion del uso del UL, que la BS
utiliza para realizar una planificacion adecuada de ese enlace en funcion de la cantidad
de datos que requieren transmitir las SSs.
Los principales componentes de este
sistema son: las polticas para el Manejo de Percepcion de necesidades de Ancho de

Banda (MPAB), la Tabla de Percepcion, y otros atributos caractersticos de la poltica
empleada (como sistema de colas, cursores, parametros, etc).
Debido a que la BS no conoce exactamente cuanto ancho de banda requieren
las SSs para transmitir datos, la BS realiza una estimacion de ello a partir del
procesamiento de los BwReqs. De manera que el ancho de banda otorgado a las SSs
para uso del UL, corresponde a la percepcion que tiene la BS sobre las necesidades de
ancho de banda (reflejada en la Tabla de Percepcion).
Las polticas para MPAB, se encargan principalmente del manejo de los BwReqs.
Esas polticas, indican en que momento se procesan estos paquetes (sumando o
sustituyendo la cantidad que indica el BwReq a la Tabla de Percepcion), y en que
momentos se considera que la necesidad de ancho de banda de la SS fue satisfecha
(restando cierta cantidad al valor de la Tabla de Percepcion). La tabla de Percepcion
mantiene un estado de la estimacion de ancho de banda que requieren las SSs. Esta
tabla es usada para la construccion del UL-MAP en cada subtrama.
2.9 Polticas que pueden ser utilizadas en el Sistema MSOAB de WiMAX
27
Arcia y otros [17] presentaron varias polticas para el MPAB que afectan al sistema
MSOAB, entre ellas estan:
2.9.1
RPG (Reset per Grant)
La BS luego de asignar ancho de banda a una SS, coloca en 0 el valor de la percepcion

de ancho de banda en la tabla, incluso cuando no fue otorgado todo el ancho de banda
requerido. Se puede utilizar cuando la tasa de perdidas se incrementa.
2.9.2
DPG (Decrease per Grant)
La BS actualiza la percepcion de ancho de banda en la tabla, en el momento que el

planificador otorga ancho de banda a la SS.
2.9.3
DDA (Decrease at Data Arrival )
La BS actualiza la percepcion de ancho de banda en la tabla cuando los paquetes de

data llegan al servidor. La poltica DDA basandose en el momento que procesa el
BwReq, puede ser dividida a su vez en dos tipos adicionales: iDDA y dDDA.
2.9.3.1
iDDA
(Decrease
at
Data
Arrival
with
immediate
BwReq
handling )
DDA con manejo inmediato de BwReqs. La BS procesa el BwReq y actualiza la tabla
de percepcion al instante que este paquete llega.
2.9.3.2
dDDA (Decrease at Data Arrival with delayed BwReq handling )
DDA con demora en el manejo de BwReqs. La BS coloca en una cola cada BwReq
que llega durante un perodo de contencion, y al final de este perodo los procesa y
actualiza la tabla de percepcion.
En este trabajo, nos concentramos en una ampliacion de esta poltica, que consiste
n de Sistemas Abiertos (Open System Interconnection u OSI) 28

2.10 Modelo Interconexio
en demorar el procesamiento de los BwReqs de forma aleatoria3 .
Figura 2.10: Polticas para el Manejo de la percepcion de Ancho de Banda

En la Figura 2.10 se pueden observar las polticas para el MPAB seg
un la gerarquia
de clases. En el primer nivel (RPG, DPG, y DDA) se caracterizan las polticas por
como y en que momentos se realiza el descuento del ancho de banda en la Tabla de
Percepcion; mientras que en el segundo nivel (iDDA, dDDA y rDDA) por los momentos
en que se procesan los BwReqs. En la Figura 2.11 se puede ver el diagrama de estados
de la trama, que muestra en que partes de ella se utilizan las polticas MPAB para
actualizar la Tabla de Percepcion y donde se realizan las consultas a esa Tabla.
2.10
Modelo Interconexi
on de Sistemas Abiertos
(Open System Interconnection u OSI)
El modelo OSI surgio a principios de la decada de 1980 como resultado del dise
no
que realizaron varias organizaciones de estandares, entre ellas la ISO (Organizacion
Internacional de Estandarizacion) y la ITU-T (Sector de Estandarizacion de las
Telecomunicaciones del ITU), para proporcionar una descripcion generalizada de
las herramientas para la conectividad de redes [35]. La esencia de este modelo de
referencia se encuentra especificada en el Estandar Internacional 7498 de la ISO, el
3
Esta nueva poltica se describe con detalle a partir de la Seccion 3.1

Figura 2.11: Diagrama de Estados de la trama, polticas para el MPAB y sus

interacciones con la Tabla de Percepcion
cual establece un marco para el dise
no de todos los estandares relacionados con la
comunicacion de datos [16].
El modelo de referencia OSI pretende ordenar y estandarizar todos los aspectos
relacionados con las trasmisiones de datos.
OSI intenta solucionar los problemas
relacionados con la comunicacion de computadores, valiendose de una aproximacion

por niveles (o capas), donde cada capa tiene que ver con un aspecto de conectividad
de redes [16].
Adicionalmente, cada capa contiene dos tipos de interfaces: una
para las capas superiores e inferiores que permiten realizar sus tareas, y otra con
las funciones de la misma capa que corren en el nodo remoto (llamados protocolos) [35].
La division por capas provee varias ventajas, entre ellas resaltan las que se

mencionan a continuacion [14]:

Favorece la interoperabilidad de las interfaces de diferentes tecnologas.
Permite la simplificacion de los sistemas para trabajarlos con menor complejidad.
Facilita las fases de ense
nanza y aprendizaje por la simplicidad que provee.
El modelo OSI se divide en 7 capas: Aplicacion, Presentacion, Sesion, Transporte,
Red, Enlace de datos, y Fsica [16] [14] (Vease la Figura 2.12).
Figura 2.12: Capas seg

un modelo de referencia OSI
Capa Aplicaci
on (capa n
umero 7): Proporciona servicios de red a procesos
de aplicacion, como correo electronico, transferencias de archivos, entre otros
servicios.
Capa Presentaci
on (capa n
umero 6): Facilita el intercambio de formatos
estructuras complejas de datos por la red, conservando su significado aun cuando
vara su representacion interna y garantizando que sean legibles por el sistema
receptor.
Capa Sesi
on (capa n
umero 5):
Aporta un mecanismo de control y
sincronizacion sobre el canal libre de errores. Se encarga de las comunicaciones

entre hosts: establece, administra y termina las sesiones entre las aplicaciones.
n (Transmission Control Protocol o TCP)

2.11 Protocolo de Control de Transmisio
31
Capa Transporte (capa n

umero 4): Ofrece un sistema de transferencia de
datos fiable y homogeneo entre dos procesos en dos maquinas remotas. Para ello
presta servicios de control de flujo de datos, deteccion de fallas y recuperacion,
confiabilidad en el transporte de los datos, entre otros.
Capa Red (capa n
umero 3): Tiene la responsabilidad de transferir los datos
entre dos maquinas utilizando enlaces de la capa 2. Proporciona la conectividad
entre dos nodos, es decir, la ruta por donde se transmitiran los paquetes.
Capa Enlace de datos (capa n
umero 2 o capa MAC): Agrupa bits
para enviarlos por un enlace que comunica dos maquinas por un medio fsico.
Administra el acceso al enlace cuando lo comparten varios sistemas, y controla
el flujo y los errores del mismo, con el fin de ofrecer transferencias confiables de
los datos a traves del medio.
Capa Fsica (capa n
umero 1): Responsable de la interfaz electrica y mecanica
entre una maquina y el medio fsico que ofrece la capacidad de intercambio de
bits, de como son enviados los bits de un nodo a otro. Esta relacionado con los
cables, conectores, voltajes, velocidad de los datos, etc.
De estas capas, nos interesan principalmente tres:
La capa Fsica, porque
consideramos OFDM, que es la tecnica que utiliza WiMAX para transmitir los datos;
las capas Fsica y Enlace, porque son las que se especifican en el Estandar 802.16 sobre
el funcionamiento de estas redes; y la capa Transporte, porque vamos a considerar el
trafico que circula usando TCP.
2.11
Protocolo
de
Control
de
Transmisi
on
(Transmission Control Protocol o TCP)

TCP es un protocolo de la capa transporte (seg
un modelo OSI) orientado a conexion.
Esta definido en el RFC-793, donde se dan sugerencias acerca de la interfaz entre TCP
y sus usuarios. La tarea principal de este protocolo es proporcionar conexiones entre

32
dos procesos utilizando una red soportada en IP (una red no confiable) y asegurar la
entrega confiable de los datos [16] [35].
La identificacion del proceso de una aplicacion dentro de una red, esta dada
directamente por el par direccion IP y puerto TCP (par socket TCP). Una conexion
TCP esta definida por los sockets comunicados. TCP establece conexiones logicas
(o sesiones) para resolver el problema de la entrega confiable. Al inicio de la conexion,
se negocian los parametros que se utilizaran en la transmision de los datos (como el
tama
no maximo de segmentos, n
umero de secuencia, entre otros) [35].
Esta y otra informacion relevante (como identificadores de sockets), debe ser
almacenada en recursos TCB (Transmission Control Block ) que son asignados a la
conexion. Durante la transmision se actualizan algunos de estos valores, como por
ejemplo el del n
umero de secuencia. El hecho de que TCP sea un protocolo orientado
a conexion implica que el tratamiento de cada paquete nuevo que llega depende
inmediatamente de la historia de la conexion, es decir, del conjunto de paquetes
transmitidos durante la sesion. Por ejemplo, si se nota que se han perdido varios
paquetes emitidos recientemente, se podra reducir la tasa de envo de paquetes para
la transmision de los proximos paquetes [16] [35].
2.11.1
Caractersticas del protocolo
TCP tiene las siguientes caractersticas [15]

Garantiza la entrega de la informacion.
Provee transmisiones libres de error.
Realiza la entrega de los paquetes en orden.
Elimina los paquetes de datos que estan duplicados.
Utiliza algoritmos para el control de la congestion.

2.11.2
33
Segmento TCP
Los flujos de datos proporcionados a TCP por los protocolos de capa superior son
considerados no estructurados, y almacenados en b
uferes (colas). TCP recorta de
esos flujos de datos continuos, segmentos de tama
no prefijado y le anexa un encabezado,
para luego entregar ese segmento a la capa red [35]. De los campos mas importantes
que contiene el encabezado se encuentran:
El puerto fuente, que identifica al proceso que emite el paquete;
El puerto destino, que identifica al proceso al que se enva el paquete;
N
umero de secuencia, identifica el segmento que corresponde del flujo de datos,
indica el n
umero de primer byte de ese segmento respecto al flujo de datos total;
N
umero de reconocimiento, indica el n
umero de bytes que se han recibido mas 1,
indicandole al receptor que le enve el segmento que inicia en ese valor de byte;
Longitud de encabezado, que indica que cantidad de bytes corresponden al
encabezado agregado por TCP;
Bits de codificacion, para informacion adicional sobre el tipo de segmento,
como los bits de datos urgentes, ACK, SYN (sincronizar contadores de datos
transmitidos al se establecerse la conexion), FIN (para indicarle al otro extremo
que el u
ltimo byte en el flujo de datos se ha transmitido);
Suma de verificacion (checksum).
2.11.3
Detalles del funcionamiento de las conexiones TCP
Como TCP usa un servicio de baja calidad y no fiable para realizar las transmisiones
(el servicio de IP), se requiere emplear mecanismos complejos para la apertura y para el
cierre de las conexiones con el objetivo de evitar que algo pueda fallar [16]. De all que
las conexiones de TCP se compongan en 3 fases: Primero, una fase para la apertura de
la conexion; luego, viene propiamente la fase de transferencia de los datos; y finalmente,
la fase de cierre de la conexion (Vease la Figura 2.13). Para explicar el funcionamiento

34
de una conexion TCP, vamos a utilizar el esquema Cliente-Servidor. Este modelo

consta de dos nodos participantes, un nodo activo (el cliente) que enva solicitudes a
nodo un pasivo (el servidor), el cual esta a la espera de atender las solicitudes que le
llegan.
Figura 2.13: Fases de una conexion TCP
2.11.3.1
Apertura de la conexi
on
En esta fase inicial se trabaja con el protocolo three-way handshake, donde en tres
pasos (mediante 3 segmentos TCP) se logra establecer la conexion entre los dos nodos
[15]. A continuacion se explican estos pasos.

35
1. Petici
on de la conexi
on: El cliente enva un segmento de peticion de conexion
(segmento SYN) al servidor.
2. Confirmaci
on de la conexi
on:
El servidor enva una respuesta (con
un segmento SYN) con el n

umero de secuencia inicial que utilizara, y el
reconocimiento ACK con el n
umero de secuencia inicial que envio el cliente mas
1 [15].
3. Reconocimiento de la conexi
on: El cliente reconoce el SYN y responde con
un segmento ACK.
Los dos paquetes SYN emitidos (en los pasos 1 y 2), son para que ambos extremos se
pongan de acuerdo en cuanto a los n
umeros de secuencia iniciales para la transmision de
los datos, uno para cada direccion en el canal. Estos n
umeros se asignan aleatoriamente,
no reutilizandose durante un tiempo adecuado, con el fin de evitar que se confundan
segmentos de otras conexiones [16]. Luego de estos 3 pasos se puede decir que la
conexion ya se ha establecido (Vease la Figura 2.13).
2.11.3.2
Transferencia de datos
Despues de que la conexion es establecida, ya se pueden comenzar a realizar

la transferencia de los flujos de datos.
Para garantizar la fiabilidad se utilizan
mecanismos de retransmision de paquetes (en caso de da

nados o perdidos), y de
verificacion de segmentos duplicados. Cuando se recibe un segmento con errores, TCP
lo descarta y enva un ACK con el mismo n
umero que haban enviado anteriormente
(ACK duplicado) para indicarle al emisor que le vuelva a transmitir ese segmento. Si
los segmentos llegan desordenados TCP los ordena para entregarselos a la aplicacion.
En caso de que haya paquetes duplicados, los elimina [15].
Para facilitar todo esto, cada vez que TCP enva un segmento, le coloca el n
umero
del primer byte (respecto al flujo completo) del segmento en el encabezado, el cual le
permite al receptor identificar el segmento recibido. Luego de enviar cierta cantidad
de paquetes, el emisor espera un acuse de recibo (un ACK), el cual le indica que todos
los paquetes reconocidos por el n
umero de ACK ya fueron recibidos correctamente

36
(principio de reconocimiento acumulativo). No se envan reconocimientos negativos,

de forma que si el ACK no llega durante cierto tiempo prefijado, puede indicar al
emisor que se perdio el segmento o el ACK, o que el segmento se da
no durante la
transmision, en cuyo caso el emisor retransmite los segmentos [35] [16].
En la Figura 2.13, se muestra la transferencia de datos, en el caso que el cliente este
descargando un archivo del servidor, por ello los paquetes de data van en direccion
Servidor-Cliente, mientras que los ACKs van en la direccion opuesta.
2.11.3.3
Cierre de la conexi
on
Al terminar la transferencia de la informacion, TCP utiliza otro protocolo para el

cierre de la conexion. Este protocolo es muy cuidadoso, ya que es necesario asegurarse
que la conexion se cierre completamente (en ambos extremos) para evitar que se
desperdicien recursos de la red, como memoria por TCBs ocupados innecesariamente.
Aun as, existe el riesgo de que las conexiones queden medio abiertas, por lo que
TCP utiliza temporizadores, que le indican a cada nodo que si no recibe un segmento
durante un tiempo establecido, la conexion se cierra en ese extremo [16].
El cierre de la conexion comienza cuando el cliente enva un segmento con el campo
FIN activado, y con un n
umero de secuencia (x). El servidor enva una confirmacion
con el n
umero de secuencia recibido del cliente mas uno (x+1). El servidor enva al
cliente un segmento TCP con el campo FIN activado y con otro n
umero de secuencia.
El cliente enva un ACK como confirmacion, con el n
umero de secuencia recibido mas
1 [15].
2.11.4
Control de Congesti
on en TCP
El objetivo de TCP es transmitir lo mas rapido posible sin congestionar la red. Por
ello, con el fin de controlar la congestion, TCP utiliza alternamente dos algoritmos
que determinan la tasa de emision de los paquetes: el Slow Start y el Congestion

37
Avoidance [18].
En Slow Start: Se incrementa la tasa de emision rapidamente al inicio de la
conexion o despues de un timeout. Ese incremento se realiza de forma exponencial.
En Congestion Avoidance: Se incrementa la emision de los paquetes de datos
mas lentamente en comparacion con el algoritmo anterior. De una forma pseudo-lineal.
Figura 2.14: Slow Start Vs Congestion Avoidance

En la Figura 2.14 se muestra como se alterna el uso de estos algoritmos durante
una transmision de TCP. All se puede ver la variacion de la ventana de congestion a
medida que avanza el tiempo en unidades de RTTs (Round Trip Time). La ventana
de congestion es una variable que indica la cantidad de paquetes de data que puede
enviar sin recibir el ACK correspondiente teniendo en cuenta la congestion de la red
percibida. Un RTT es el tiempo transcurrido desde que se enva un segmento hasta
que llega su reconocimiento.
La diferencia en el crecimiento de la tasa emision de paquetes durante el uso de
estos algoritmos, se puede ver claramente en la Figura 2.15, donde la zona sombreada

38
en verde es el perodo donde esta activado el algoritmo Slow Start (crecimiento de

tasa de envo exponencial) y la zona sombreada en amarillo es el perodo donde esta
activado el algoritmo Congestion Avoidance (crecimiento de tasa se envo lineal).
Figura 2.15: Emision de paquetes en el tiempo con Slow Start y Congestion Avoidance
2.11.5
Control de flujo
TCP es un protocolo d
uplex, donde los extremos trabajan como receptor y emisor
de forma simultanea. Cada uno de ellos tiene 2 b
uferes con espacio limitado para
los paquetes principales (uno para los segmentos que llegan, y otro para los que
esperan ser enviados) y otro b
ufer para colocar copias de los segmentos que se han
enviado pero no se ha recibido su respectivo ACK. Es por ello, que TCP provee este
mecanismo, en el que el nodo receptor le indica al nodo emisor la cantidad de datos
que puede enviarle dependiendo de su disponibilidad en las colas. La idea es que
cada extremo pueda controlar la cantidad de datos que le enva el extremo contrario.
En cada paquete enviado, el nodo informa el tama
no de su ventana (en bytes) en un
campo del encabezado segmento [16] [35] [15].

39
El tama
no real de la ventana, la tasa de envo, se define como el menor valor de
ventana entre el percibido por la congestion de la red (conseguida por el control de
congestion) y el anunciado por el receptor (obtenida por el control de flujo).
Captulo 3
Dise
no
El modelo que se desarrollo tuvo como base la poltica dDDA, explicada en la
Seccion 2.9.3.2. El nombre asignado a esta nueva poltica fue rDDA (random delayed
BwReq handling - DDA). El dise
no de esta estructura fue concebido con dos premisas.
La primera es que, mediante una estructura de lista circular de colas se requiere dar
adaptabilidad al sistema para repartir adecuadamente el procesamiento de los BwReqs
a lo largo de las tramas tanto para inducir una demora beneficiosa como para hacerlo
escalable. La segunda, es que se introduce la posibilidad del manejo de la prioridad en
la gestion de BwReqs mientras se respeta la equidad entre los flujos. A continuacion
se detalla mejor esta nueva poltica.
3.1
Modelo de Gesti
on de Ancho de Banda con
Retardo Aleatorio
Este modelo consiste en hacer que la demora del procesamiento de BwReqs definido
en la poltica dDDA, sea variable y aleatoria. De esta manera, los BwReqs deberan
esperar ser procesados dentro de un n
umero de tramas dado por un valor aleatorio
(i ), que es generado al momento de llegar este paquete a la BS. El procesamiento
consta de obtener el valor de la cantidad de ancho de banda (AdB) solicitado en el
BwReq, para actualizar la tabla de percepcion en la entrada correspondiente a la SS
3.2 La poltica rDDA en funcionamiento
41
que envio ese paquete.

El n
umero aleatorio que se asocia a cada BwReq, i , esta restringido entre 1 y
el valor de un parametro , el cual indica el n
umero maximo de tramas que puede
esperar un BwReq para ser procesado. Este parametro , debe asignarse tomando en
cuenta que esta estrechamente relacionado con el valor del timer T16 y con la duracion
de la trama. Si se selecciona mayor que la relacion T16/Tama
nodeTrama, entonces
la probabilidad que expiren los T16 aumentara, y por ende, tendra que consumir
mas ancho de banda y slots en el perodo de contencion para enviar mas BwReqs.
3.2
La poltica rDDA en funcionamiento
Para comprender mejor la poltica rDDA observemos la Figura 3.1, donde se realiza
la solicitud y asignacion de ancho de banda cuando esta puesta en marcha esta nueva
poltica. En la lnea de tiempo se ha colocado adicionalmente, la distribucion de las
tramas para observar mejor los instantes en que ocurren los eventos. Tambien se hace
una ampliacion de la tabla de percepcion de la BS, y el trafico en las colas de la SS,
para ver los cambios en estas estructuras.
En T 1 la SS solicita ancho de banda a traves de un BwReq para transmitir 100
bytes. Luego el BwReq es recibido por la BS y reservado para ser procesado 1 tramas
despues, que en este caso 1 tiene el valor de 2. En T 2, transcurridas 1 tramas,
la BS procesa el BwReq, percibe que la SS necesita 100 bytes, actualiza la tabla de
percepcion de ancho de banda y otorga esos 100 bytes solicitados para que la SS pueda
transmitir en la proxima subtrama UL. En T 3, luego de la aprobacion de la BS, la SS
puede transmitir 100 bytes de data. Estos al llegar a la BS (en T 4), son descontados
de la percepcion de esa SS reflejada en la tabla.
Como una restriccion del modelo, se establecio que durante las 1 tramas no
pueden ser enviados otros BwReqs. Si la SS necesita pedir mas ancho de banda, debe
42
Figura 3.1: Funcionamiento de la poltica rDDA

esperar a que se le otorgue el que solicito en el tiempo T 1 o esperar a que expire el
timer T16 asociado a ese BwReq.
3.2.1
Efecto de la poltica rDDA sobre el RTT de TCP
La demora inducida por el mecanismo de asignacion de ancho de banda de la BS para el

uso del UL, y la demora hecha por la poltica rDDA, afectan el valor del RTT de TCP.
Cuando la trama esta dividida en proporcion 1:1 (igual duracion para cada subtrama),
el RTT obtenido en promedio esta dado por la siguiente formula. Donde RT T deT CP ,
es el tiempo que tarda desde que un segmento TCP es enviado hasta que se recibe su
reconocimiento.
43
DuracionRT T = SolicyAsigAdB + duracionT rama + RT T deT CP

Mientras que el tiempo de solicitud y asignacion de ancho de banda para el UL
(SolicyAsigAdB) esta definido por la formula que se muestra a continuacion. Donde i
es el n
umero de tramas que se demorara el BwReq para ser procesado, producto de la
poltica rDDA.
SolicyAsigAdB =
duracionT rama
+ ((i ) (duracionT rama))
2
Figura 3.2: Duracion de RTT y tiempo procesamiento de BwReq mnimos en rDDA

Un ejemplo de ello, lo vemos en la Figura 3.2, donde se muestran las acciones que
realiza una SS cuando se esta descargando un archivo seg
un el modelo cliente-servidor.
En ese escenario la duracion de la trama es 5 ms, y su distribucion es equitativa entre
las subtramas (2.5 ms para cada una). All podemos ver que el tiempo mnimo de
procesamiento del BwReq, que ocurre cuando el 1 es igual a cero, es aproximadamente
2.5 ms, ya que debido a la aleatoriedad se espera que en promedio la SS transmita el
BwReq en un slot central del perodo de contencion. En el caso del RTT, podemos ver
que es aproximadamente 7.5 ms, ya que se espera (tambien por la aleatoriedad) que
n
3.3 Implementacio
44
los datos lleguen en una porcion TDM ubicada en la mitad del DL, y que los ACKs
se transmitan en un slot medio de la subtrama UL. Esto sin incluir el valor del RTT
dado por TCP (RT T deT CP ).
3.3
Implementaci
on
Para satisfacer los requisitos del modelo se dise

no la clase BwReq Manager rDDA,
implementada en codigo cpp, y como extension del modulo MSOAB de WiMAX
desarrollado por Paltrinieni [29].
3.3.1
Atributos de la clase
Con el objetivo de expresar los diferentes estados y caractersticas requeridas por esta
nueva poltica, se crearon los atributos: parametro , lista circular de colas, valor i ,
y cursor T ramaActual. A continuacion se describe cada uno de ellos.
3.3.1.1
Par
ametro
Este es un parametro que indica el n

umero maximo de tramas que puede ser demorado
un BwReq para ser procesado. Determina el tama
no de la lista de colas, el cual es
igual a este valor. Y como se menciono al final de la Seccion 3.1, debe ser asignado
considerando los valores del timer T16 y del tama
no de la trama, ya que depende de
estos.
3.3.1.2
Lista circular de Colas de BwReqs
Es una estructura sencilla que facilita el manejo de la planificacion de los BwReqs que
se procesaran en las diferentes tramas. Cada una de estas colas, esta asociada a una
trama.
n
3.3 Implementacio
45
Note que si esta lista se crea con un elemento ( = 1), la poltica rDDA tendra
el comportamiento de la poltica dDDA, donde los BwReqs u
nicamente se podran
postergar para procesarse la proxima trama.
3.3.1.3
Valor i
Este es el valor aleatorio que se genera al momento en que llega un BwReq a la BS.
Indica el n
umero de cola en el que se va a colocar ese BwReq, contado a partir de la
cola con valor T rama Actual, y por ende determina la cantidad de tramas que va a
esperar para ser procesado.
3.3.1.4
Trama Actual
Es un cursor (o ndice) sobre la lista de colas, que indica la cola de BwReqs que
esta proxima a ser procesada. Cada vez que concluye una trama, este cursor es
actualizado a la posicion de la siguiente cola. Sirve ademas, para calcular la cola donde
se coloca cada BwReq que llega a la BS, a partir del valor del i asignado a ese paquete.
(a) Cuando llega un BwReq
(b) Cuando procesa Cola de BwReqs
Figura 3.3: Atributos de la clase para rDDA

La Figura 3.3 muestra dos momentos en que se usan los atributos de la clase. En
la parte a, se muestra el uso de i cuando llega un BwReq. En la parte b, se observa
n
3.3 Implementacio
46
el uso de T ramaActual para indicar que cola de BwReqs se va a procesar en ese

momento, y como relaciona esto con la actualizacion de la tabla de percepcion. En
ambas partes, se puede ver que el valor de , que all es 5, determina el comportamiento
de la poltica rDDA y define el tama
no de la lista de cola.
3.3.2
M
etodos de la clase
Con el fin de facilitar cada uno de los procesos de gestion de los BwReqs se
implementaron diversos metodos. La interaccion de estos metodos se puede observar
en la Figura 3.4, donde usando un diagrama de secuencias de UML, se muestra el
camino de un BwReq desde que es generado en la SS hasta la actualizacion de la tabla
de percepcion en la BS, incluyendo el momento en que la SS utiliza el ancho de banda
solicitado. A la izquierda del diagrama se puede ver la descripcion de cada parte del
mismo.
Para comprender mejor la actividad realizada por los metodos se incluyen los
algoritmos expresados en seudocodigo, y el diagrama de actividades que indica en que
partes de la trama se ejecuta cada uno de esos algoritmos (Vease la Figura 3.5).
Figura 3.4: Diagrama de Secuencias: Metodos usados en el camino de un BwReq con poltica rDDA
n
3.3 Implementacio
47
n
3.3 Implementacio
3.3.2.1
48
M
etodo NuevoBwReqRecibido (BwReq)
Se llama al momento en que llega un BwReq a la BS, pasandole como parametro el

propio BwReq. Este metodo se encarga de la generacion del i asociado al BwReq, y
de colocar ese paquete en la respectiva cola (Vease el Algoritmo 1).
Algoritmo 1: Recepcion de BwReq
Entrada: BwReq
Salida : Colocacion de BwReq en Cola
/* generar i
*/
Landa i = rand()%(T ao);

/* colocar BwReq en cola respectiva
*/
ListaDeColasDeBwreqs[Landa i].push back(BwReq);

Retornar 0;
3.3.2.2
M
etodo ObtenerAdBSolicitadoPorSS (IDcSS)
Se llama en el momento en que se van a preparar el UL-MAP, es decir, cuando se va a

realizar la planificacion de la subtrama UL1 . Este metodo tiene dos tareas principales:
Primero, procesa los BwReqs que hayan en la cola actual, esto es que, analiza cada
BwReq de la cola y refleja su solicitud en la tabla de percepcion, ya sea sustituyendo el
valor de la entrada para esa conexion (si el BwReq es Agregado) o sumando ese valor
al que ya se encuentra en la tabla (si el BwReq es Incremental); Y segundo, consulta
la tabla de percepcion para obtener la necesidad de ancho de banda del nodo cuyo
identificador de conexion es recibido como parametro, y retorna este valor (Vease el
Algoritmo 2).
3.3.2.3
M
etodo ActualizarPercepcionAdB (IDcSS, AdBTransmit)
De acuerdo con la poltica DDA, explicada en el captulo anterior (Seccion 2.9.3), este
metodo actualiza la necesidad de ancho de banda de la tabla de percepcion cuando la
1
M
as detalles de esto se muestran en la Subseccion 3.4.2
n
3.3 Implementacio
Figura 3.5: Diagrama de Actividades: Algoritmos descritos en este captulo
49
n
3.3 Implementacio
50
Algoritmo 2: Procesamiento de cola actual, y Obtencion de AdB requerido por

una SS
Entrada: IDcSS (ID de conexion de la SS)
Salida : Cantidad de AdB necesitado por la SS seg
un Tabla de Percepcion
/* procesar los BwReqs de la cola actual
*/
Si !ListaDeColasDeBwreqs[TramaActual].empty() entonces
/* si hay BwReqs en cola
*/
Para itbwreq ListaDeColasDeBwreqs[T ramaActual].begin() hasta

ListaDeColasDeBwreqs[T ramaActual].end() hacer
Si (itbwreq.type & 0x7) == 0x001 entonces
/* es Agregado
*/
TabladePercepcionAdB[itbwreq.cid] = (itbwreq.br & 0x7FFFF);

Sino Si (itbwreq.type & 0x7) == 0x000 entonces
/* es Incremental
*/
TabladePercepcionAdB[itbwreq.cid] += (itbwreq.br & 0x7FFFF);

ListaDeColasDeBwreqs[TramaActual].clear();
/* Obtener la necesidad de AdB del nodo SS
NecesidadAdBdelaSS = TabladePercepcionAdB[idcSS];
Retornar NecesidadAdBdelaSS;
*/
n
3.3 Implementacio
51
BS recibe paquetes de data, es decir, la BS descuenta el ancho de banda luego que la

SS lo haya utilizado (Vease el Algoritmo 3).
Algoritmo 3: Actualizacion de la Tabla de Percepcion

Entrada: IDcSS, Cantidad de AdB transmitido
Salida : Tabla de Percepcion actualizada
/* Descontar en la Tabla de Percepci
on la cantidad de AdB utilizada
por la SS
*/
TabladePercepcionAdB[IDcSS] -= CantidadABTransmitido;
/* verificar integridad
*/
Si TabladePercepcionAdB[IDcSS] < 0 entonces

TabladePercepcionAdB[IDcSS]=0;
Retornar 0;
3.3.2.4
M
etodo ActualizarTrama ()
Se encarga de mover el cursor T rama Actual cada vez que comienza una nueva
subtrama DL. En caso de que la cola que sigue no contenga BwReqs, este metodo
busca entre las demas colas, aquella que contenga al menos un elemento si la hay
(Vease el Algoritmo 4).
Algoritmo 4: Actualizacion de la trama

Entrada: Cursor T ramaActual
Salida : Actualiza el valor del cursor T ramaActual
Para i 0 hasta Tao hacer
/* buscar una cola no vac
a
TramaActual=(TramaActual+1)%(Tao);
Si ListaDeColasDeBwreqs[TramaActual].size() > 0 entonces break;
Retornar 0;
*/
n del uso de ancho de banda de la trama

3.4 Planificacio
3.3.2.5
52
M
etodo InicilizarParametros(Tao)
Se ejecuta con el constructor de la clase, y como su nombre indica, su objetivo

es establecer el valor de , y as definir el tama
no de la lista de colas (Vease el
Algoritmo 5). Cumple una funcion sencilla pero importante ya que determina el
comportamiento de la poltica rDDA.
Algoritmo 5: Inicializacion del parametro Tao

Entrada: ValorTao
Salida : ValorTao asignado para poltica rDDA
/* verificar que el valor recibido este en el rango valido
*/
Si (valorTao > 0)&&(valorTao < maximo Tao) entonces

/* Inicializar con valor recibido
*/
Tao = valorTao;
Sino
/* Inicializar con valor por omisi
on
*/
Tao = 3;
Retornar 0;
3.4
Planificaci
on del uso de ancho de banda de la
trama
La asignacion de ancho de banda de las subtramas que realiza la BS en la poltica

rDDA, corresponde a la misma implementada por Paltrinieri [29] para las polticas
iDDA y dDDA. En ella, se realiza la asignacion del ancho de banda de ambos subtramas
siguiendo el esquema Round Robin, con el objetivo de dar un trato equitativo en la
utilizacion del enlace a todas las SSs. Particularmente, si una SS necesita mas ancho de
banda del que esta disponible para la subtrama UL, el planificador de la BS le asigna
todo el ancho de banda disponible para esa subtrama, y pasa el cursor que controla el
Round Robin a la proxima SS, para evitar que una sola SS ocupe el enlace.

3.4 Planificacio
53
Luego de tener la planificacion de la trama en el DL-MAP y en el UL-MAP, la

BS enva estos paquetes a todas las SSs, para que cada una de ellas pueda ver en que
momento va a recibir datos, si es el caso; y/o en que instante pueden transferir sus
paquetes seg
un el slot del UL y la cantidad de ancho de banda que se le hayan otorgado.
3.4.1
Subtrama DL
El metodo planificarDL() se encarga de la preparacion del DL-MAP, es decir, del

paquete que contiene especificamente como se distribuye la subtrama DL en una
trama particular. Para ello utiliza la informacion contenida en las colas de DATA
de la BS y el cursor que lleva el control del esquema Round Robin. El Algoritmo 6
muestra algunos puntos principales que ejecuta este metodo. Se han omitido varias
validaciones (como la de verificar que no exceda el ancho de banda disponible, y la
de no exceder el n
umero maximo de slots, entre otras) y acciones que no son tan
relevantes, con fin de no sobrecargar la legibilidad del algoritmo.
3.4.2
Subtrama UL
De forma equivalente para la subtrama UL, el metodo planificarUL() construye el

UL-MAP, que es el paquete que indica detalladamente la distribucion de la subtrama
UL de la proxima trama. En este metodo, se usa la informacion contenida en la
tabla de percepcion y el cursor que lleva el control para garantizar el uso equitativo
del UL (igual a traves del esquema Round Robin).
El Algoritmo 7 muestra el
funcionamiento de este metodo. Al igual que el algoritmo anterior, se han omitido

algunas instrucciones con el mismo objetivo, hacer que el algoritmo se mantenga lo
mas legible posible, sin que pierda los puntos esenciales.

3.4 Planificacio
54
Algoritmo 6: Planificacion de la subtrama DL

Entrada: Colas de trafico de data de la BS
Salida : DL MAP
maxDuracionDL = NumSimbolosTotalporTrama * dlradio;
duracionDL = PreambuloDL;
crear burst mensajesBroadcast();
tiempotx = CalcularTiempoEnviarDLMAPyULMAP();
tiempotxSimbolo = tiempotx / tiempoSimbolo;
duracionDL += tiempotx simbolo + 1;
/* iniciar algoritmo Round Robin para asignar los slot en DL, hasta
que se acabe el AdB disponible para esta subtrama
*/
nodoSS = obtenerNodo(proximoDL);
Para i 0 hasta N umN odosSS hacer
/* chequear colas de la SS, siguiendo el orden:
B
asica,
Primaria, Segundaria, DATA

Si nodoSS cantBytesColaBasica() > 0 entonces
duracionDL = agregarDLBurst (nbdlbursts++, nodoSS
cantBytesColaBasica(), dlduration, maxdlduration);
Si nodoSS cantBytesColaPrimaria() > 0 entonces
cantBytesColaPrimaria(), dlduration, maxdlduration);
Si nodoSS cantBytesColaSegundaria() > 0 entonces
cantBytesColaSegundaria(), dlduration, maxdlduration);
Si nodoSS cantBytesColaDATA() > 0 entonces
cantBytesColaDATA(), dlduration, maxdlduration);
nodoSS = nodoSS prox entrada();
agregarFinalDLMAP();
Retornar 0;
*/

3.4 Planificacio
55
Algoritmo 7: Planificacion de la subtrama UL

Entrada: Tabla de Percepcion de necesidades de AdB de las SSs
Salida : UL MAP
maxDuracionUL = NumSimbolosTotal - maxDuracionDL;
duracionUL = 0;
duracionUL += duracionPeriodoInicialReg + 1;
duracionUL += duracionPeriodoContencion + 1;
/* iniciar algoritmo Round Robin para asignar los slot en UL, hasta
que se acabe el AdB disponible para esta subtrama
*/
nodoSS = obtenerNodo(proximoUL);
Para i 0 hasta N umN odosSS hacer
/* en esta parte se utiliza la informaci
on de la Tabla de
Percepci
on
*/
AdBNecesitadoPorNodo = ObtenerAdBSolicitadoPorSS(nodoSS.idcSS);
Si AdBNecesitadoPorNodo > 0 entonces
Si AdBNecesitadoPorNodo > maxDuracionUL - duracionUL entonces
TamAsignado = maxDuracionUL - duracionUL - 1;
Sino
TamAsignado = AdBNecesitadoPorNodo;
duracionUL += agregarULBurst (nbulbursts++, TamAsignado,
duracionUL, maxDuracionUL) + 1;
nodoSS = nodoSS prox entrada();
agregarFinalULMAP();
Retornar 0;
n
3.5 Discusio
3.5
56
Discusi
on
En este captulo se muestra el resultado de la ingeniera en reversa que se realizo

al modulo MSOAB de WiMAX para NS2 utilizado para los trabajos de Arcia y
otros [17] [29] [26]. Esta tarea previa al desarrollo del modelo, constituyo una de las
partes mas importantes para el avance del proyecto, ya que dicha tarea sirvio como
base para el correcto acoplamiento de la nueva poltica.
Adicionalmente se puedo comprender mejor el funcionamiento de las polticas
iDDA y dDDA, y su comportamiento cuando la BS administra el ancho de banda del
UL haciendo uso de la tabla de percepcion de la BS.
Captulo 4
Simulaciones y An
alisis de
Resultados
En este captulo se describe el estudio realizado a la poltica rDDA y se muestran
los resultados obtenidos. Para esta evaluacion se considero esta nueva poltica con los
valores para = {3, 5, 7}, y se comparo su desempe
no con las polticas iDDA y dDDA,
que fueron descritas en la Seccion 2.9, y estudiadas por Arcia y otros [17] [29].
4.1
Pruebas Realizadas
4.1.1
Entorno de Simulaci
on
Las pruebas se realizaron usando la herramienta de simulacion de redes Network

Simulator 2 (NS2 ) [4] Version 2.34. Este simulador, esta basado en eventos discretos
y fue desarrollado en lenguaje C++. El usuario puede definir la topologa a simular
especificando los parametros y caractersticas de la red en scripts en lenguaje OTCL.
Este es el simulador mas utilizado en el area de redes de computadores.
Tambien se utilizo la biblioteca TCPLAB para facilitar la captura de algunas
metricas que se utilizaron para el estudio asociadas a TCP (como el Rendimiento), y
para la elaboracion rapida de scripts OTCL reutilizando codigos estables.
4.1 Pruebas Realizadas
58
Adicionalmente, se trabajo sobre el Modulo MSOAB de WiMAX implementado

por Paltrinieri [29], en el cual se representa el funcionamiento de las capas fsica y
enlace de las Redes 802.16, considerando especialmente la estructura de las tramas en
la gestion del ancho de banda. Este modulo se utilizo como base para la puesta en
marcha de la poltica rDDA.
4.1.2
Par
ametros utilizados
La topologa representada en las simulaciones es la que se encuentra en la Figura 4.1,

donde la BS esta conectada de forma cableada con un Servidor por un enlace de 100
Mbps y una demora de 2 ms. A su vez, la BS esta conectada inalambricamente con
n nodos SS, ubicados a la misma distancia. Cada SS tiene una transferencia de datos
con el servidor mediante una aplicacion FTP (la cual esta basada en el protocolo
TCP), sea descargando un archivo o cargandolo, seg
un sea el escenario. Los paquetes
de data transmitidos fueron de tama
no 960 Bytes. Para cada una de las pruebas se
simulo durante 1000 segundos.
Figura 4.1: Topologa de WiMAX simulada

Para ver el comportamiento del sistema con diferentes tama
nos de la red, se
realizaron las pruebas variando la cantidad de SSs desde 2 hasta 32. Las transmisiones
de los paquetes se realizaron utilizando el esquema de modulacion 16 QAM 3/4. Para
las peticiones de ancho de banda de parte de las SSs, se utilizo BwReqs de tipo
Agregado. La duracion de la trama fue de 5 ms, distribuyendo la mitad para el DL y
59
la otra mitad para el UL. El tama

no de las colas en a BS se limito a 50 paquetes, con
algoritmo drop-tail, que consiste en descartar los paquetes que llegan cuando la cola
esta llena. Un resumen de estos y otros parametros usados en la simulacion se pueden
ver en la Tabla 4.1.
Par
ametros WiMAX
Frecuencia Portadora
3.5 Ghz
Ancho de Banda del Canal
7 MHz
Modulacion y Codificacion
64 QAM 3/4
Relacion DL:UL
1:1
Tipo de cola BS
Drop-Tail
Tama
no de cola BS
50
Duracion de la trama
0.005 seg (200 tramas/seg)
Tipos de BwReqs
Agregado
Tama
no del Perodo de Contencion
10 slots
Par
ametros de tr
afico y otros
Aplicacion
FTP
Version de TCP
New Reno
Tama
no del segmento TCP
960 bytes
Esquema ACK
Del-ACK
Duracion de la simulacion
1000 segundos
Tabla 4.1: Parametros de la Simulacion

En la Figura 4.2, se muestra el comportamiento de la ventana de congestion
durante los primeros 100 segundos de simulacion, para una red con 3 SSs creada con
los parametros mencionados anteriormente y usando la poltica rDDA con =1 para
el manejo de la precepcion de AdB1 . En la parte a de la grafica, se puede ver el uso
de los algoritmos de control de congestion (Slow Start y Congestion Avoidance) y los
momentos en que se descubre la red para una de las SSs, y en la parte b como esta
relacionado ese comportamiento con el de las otras 2 SSs.
1
La poltica rDDA con = 1 tiene un comportamiento equivalente al de la poltica dDDA, por lo

explicado en la Subsecci
on 3.3.1.2
(a) Cwnd para una de las SSs
60
(b) Cwnd para las 3 SSs
Figura 4.2: Comportamiento de la Ventana de Congestion para los nodos de la red

simulada de WiMAX con 3 SSs
4.1.3
Escenarios considerados
Todos estos escenarios corresponden a la topologa mostrada en la Figura 4.1, pero lo

que los diferencia es la direccion de las transmisiones, si la DATA va de la BS a las SSs
o viceversa. Esto a su vez, influye en la cantidad de ancho de banda que van a solicitar
las SS para el UL, si es para paquetes de DATA o para paquetes ACKs.
4.1.3.1
DATA solo modo Descarga
Todas y cada una de las SSs realiza una descarga de un archivo ubicado en un servidor.
De manera que las SS, solicitaran ancho de banda solo para transmitir peque
nos
paquetes, los ACKs.
4.1.3.2
DATA solo modo Carga
Todas y cada una de las SSs colocan un archivo en el servidor. En este caso, el ancho de
banda solicitado es para transmisiones de paquetes de DATA, por lo que la demanda de
uso de ancho de banda en el UL sera mucho mayor en este escenario que en el escenario
anterior.
4.1.3.3
61
Tr
afico de DATA en ambas direcciones
Representa una combinacion de los escenarios anteriores. La mitad de las SSs descargan
un archivo del servidor, y la otra mitad lo colocan en el. En este escenario, los BwReqs
estaran compitiendo para porciones de ancho de banda grandes y peque
nas a la vez,
para transmitir paquetes de DATA y paquetes ACKs, respectivamente.
4.1.4
M
etricas observadas
Para evaluar el comportamiento de la red cuando se emplearon las diferentes polticas,

se midieron diferentes caractersticas, entre ellas: el rendimiento, la equitatividad en
distribucion de ancho de banda, la perdida de BwReqs, el n
umero de expiraciones de
T16, el estado de las colas de procesamiento, y otras. Cada una de estas metricas es
descrita a continuacion.
4.1.4.1
Rendimiento Agregado
Corresponde a la cantidad total de paquetes de datos que son transferidos exitosamente

en la red por unidad de tiempo (segundos). Esta metrica define que tan eficiente es la
red transmitiendo los datos.
4.1.4.2
Indice de justicia de Jain
El ndice de justicia de Jain [32] se utiliza para indicar la igualdad en la distribucion

de un recurso del sistema, que en nuestro caso particular es el ancho de banda. Es
com
un utilizar esta medida para ver el consumo equitativo de ancho de banda cuando
se analiza trafico TCP.
X
2
n
(Ri )
J(R1 , R2 , .., Rn ) =
i=1
n
X
(Ri )2
i=1
Dadas n conexiones, Ri corresponde al rendimiento de la i-esima conexion.

Esta formula obtiene el valor maximo cuando todas las conexiones tienen el mismo
62
rendimiento, de manera que, mientras mas cercano a 1 es este ndice, mas justa fue la
reparticion del ancho de banda entre las SSs.
Para el escenario de trafico cruzado, esta metrica se eval
ua por separado para cada
direccion de transmision, para las Descargas de archivo por un lado y para las Cargas
por otro.
4.1.4.3
Proporci
on del Ancho de Banda utilizado del DL
Es la relacion entre el ancho de banda utilizado por la subtrama DL, y el ancho de

banda que la BS asigna a esta subtrama. Mientras mas cercano a 1 se encuentre este
valor, mejor se aprovecho el ancho de banda en el DL. Durante cada trama se calcula
este valor, y al final de la simulacion se promedia. La formula utilizada es:
P roporcionAdBusadodelDL =
AdBdelDLutilizado
AdBasignadoalDL
El valor mnimo es 0.13, que es lo que corresponde a la cantidad de ancho de banda

utilizado para la transmision del UL-MAP y del DL-MAP, y espacio reservado como
preambulo al inicio de la subtrama para evitar interferencia con las transmisiones de
la trama anterior.
4.1.4.4
Proporci
on del Ancho de Banda utilizado en el UL
De forma analoga a la anterior, esta metrica mide la relacion entre el ancho de banda
utilizado por la subtrama UL, y el ancho de banda asignado por la BS a esta subtrama.
Igualmente, mientras mas cercano a 1 este, mas se uso el ancho de banda dispuesto
para el UL. Durante cada trama se calcula el valor dado por la siguiente formula, y se
calcula el promedio al final de la simulacion.
P roporcionAdBusadodelU L =
AdBdelU Lutilizado
AdBasignadoalU L
Como valor mnimo se obtuvo 0.26, que corresponde a la cantidad de ancho de

banda reservado para el perodo de contencion y para el perodo de initial ranging.
4.1.4.5
63
Tasa de Envo de BwReqs
Muestra el n
umero promedio de BwReqs enviados por cada SS, por unidad de tiempo
(segundo).
4.1.4.6
Proporci
on BwReqs entregados
Calcula la relacion entre todos los BwReqs que fueron recibidos en la BS, y todos los
BwReqs emitidos por todas las SSs. Al finalizar la simulacion, se utiliza la siguiente
formula sustituyendo los respectivos contadores del sistema.
P roporcBwreqEntreg =
4.1.4.7
numBwreqRecibidos
numBwreqEnviados
Tasa de Colisi
on de BwReqs
Esta metrica muestra el promedio de colisiones que ocurren en el sistema por unidad
de tiempo (segundo). Una colision ocurre cuando dos o mas BwReqs coinciden en ser
enviados en un mismo slot del perodo de contencion de una misma trama.
4.1.4.8
Probabilidad de Colisi
on de BwReqs
Expresa la frecuencia con la que un BwReq podra colisionar al ser enviado durante el
perodo de contencion. Se basa en el n
umero de paquetes que se han perdido producto
de las colisiones que ocurrieron. Para realizar su calculo se usa la formula:
P robColision =
N umBwreqsColisionaron
N umBwreqsEnviados
Para ver la relacion entre la tasa de colision de BwReqs (compuesta por el n

umero
de colisiones por unidad de tiempo) y la Probabilidad de Colision de BwReqs, veamos el
ejemplo de la Figura 4.3 donde se muestra que ocurrieron 2 colisiones que ocasionaron
la perdida de 5 BwReqs. All el n
umero de colisiones de BwReqs es 2, mientras que la
probabilidad de colision es 5/8.
64
Figura 4.3: Colisiones de BwReqs y Probabilidad de Colision

4.1.4.9
Tasa Agregada de Expiraciones del T16
Determina el n
umero promedio de expiraciones del timer T16 en el sistema por unidad
de tiempo (segundo). Recordemos que T16 expira cuando un BwReq no se ha atendido
antes de T16 o cuando se ha perdido producto de una colision (que corresponde a la
gran mayora de nuestros escenarios).
4.1.4.10
Tasa Media de Expiraciones del T16
A partir de la metrica anterior, calcula en promedio cuantas expiraciones corresponden

a cada SS por unidad de tiempo.
4.1.4.11
Promedio de Timeouts
Corresponde a los Timeouts de TCP que expiran en promedio por cada SS por unidad
de tiempo (segundo).
4.1.4.12
Promedio de Paquetes Retransmitidos
Esta metrica es similar a la anterior, pero muestra es el n

umero de paquetes TCP que
en promedio son perdidos y retransmitidos por cada SS por unidad de tiempo.
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
4.1.4.13
65
Promedio de BwReqs en Cola
Refleja la cantidad promedio de BwReqs que se procesaron en cada trama. De la

grafica obtenida aqu, se puede deducir el promedio de BwReqs que fueron enviados
por trama, el cual es aproximadamente igual.
4.1.4.14
Histograma de Frecuencia de la Cantidad de BwReqs en Cola al

momento de procesarla
Esta metrica sirve para detallar el comportamiento y la ocupacion de la cola de BwReqs

que se procesaba durante cada trama. Para ello muestra en un histograma cuantas veces
hubo cierta cantidad de BwReqs en esa cola. Por ejemplo, cuantas veces estuvo la cola
vaca, cuantas veces hubo 1 BwReqs en cola, cuantas veces hubo 2, y as sucesivamente.
4.2
An
alisis de m
etricas y gr
aficas obtenidas
Los resultados de las graficas analizados aqu, corresponden a muestras obtenidas de

trasmisiones de datos de larga duracion, ocurridas en una red WiMAX simulada seg
un
la topologa mostrada en la Figura 4.1 y funcionando con los parametros mostrados
en la Tabla 4.1, tal como se menciono en la Seccion 4.1. Para los tres escenarios que
se van a detallar por separado en esta seccion, se configuro la red con cantidades de
SSs que van desde 2 hasta 32. Cada punto de cada grafica, corresponde al promedio
de la metrica conseguido luego de transcurrir 1000 segundos en tiempo de simulacion,
con un previo perodo de calentamiento donde se espera que la fase inicial de TCP
(descubierta del ancho de banda con slow start) no muestre su impacto. Pues, esta
etapa por si sola puede tratarse en un trabajo aparte.
4.2.1
Escenario tr
afico de data en modo Descarga
En este escenario las SSs obtienen un archivo localizado en el servidor, lo que

implica que los flujos TCP solo llevan los datos desde la BS hasta los nodos SS,
mientras que los ACK circulan u
nicamente por el enlace en direccion opuesta, en el UL.
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
66
(a) Rendimiento Agregado
(b) Indice de Fairness de Jain
(c) Proporci
on utilizada de Subtrama DL
(d) Proporci
on utilizada de Subtrama UL
Figura 4.4: Graficas Escenario Descarga: Rendimiento, Fairness, y Proporcion de Uso

del Ancho de Banda
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
67
Figura 4.5: Ampliacion de Grafica de Rendimiento Agregado en Escenario Descarga

En la Figura 4.4.a se puede observar a modo de corroboracion, que la poltica rDDA
presenta un rendimiento similar a la dDDA para las diferentes instanciaciones de (
= {3, 5, 7}). Sin embargo, haciendo un acercamiento a esta grafica se puede ver que en
algunos puntos rDDA presenta cierta mejora en rendimiento respecto a dDDA (Vease
la Figura 4.5). De aqu vemos, que la implementacion de la demora aleatoria para el
tratamiento de los BwReqs, no afecta el rendimiento de la conexiones TCP en escenario
de Descarga; ni tampoco es afectada la justicia en la asignacion equitativa de ancho de
banda entre las SSs, seg
un lo muestra la grafica del ndice de Fairness de la Figura 4.4.b.
Ahora observando la grafica de la proporcion del ancho de banda utilizado
en el DL, vemos que este enlace esta siendo utilizado al maximo y que tiene un
comportamiento similar al de la grafica del rendimiento, lo que nos indica que
esta subtrama es la que esta limitando el rendimiento de las conexiones (Vease
la Figura 4.4.c).
En la subtrama UL, se puede notar que en promedio no se
utiliza todo el ancho de banda asignado, a

un as la poltica rDDA aprovecha mejor el
ancho de banda de este enlace cada vez mas cuando es mayor (Vease la Figura 4.4.d).
En la Figura 4.6.a se muestra que para las poltica rDDA y dDDA, la cantidad
promedio de BwReqs que emiten cada SS, baja a medida que aumenta la cantidad de
SSs. Esto es debido a que el uso ancho de banda se limita mas y por ello cada SS
tiene menos oportunidades para transmitir. La Figura 4.6.b que muestra en promedio
la proporcion de entrega de los BwReqs, nos dice que la poltica rDDA tiene mayor
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
68
(a) Tasa de Envo de BwReqs
(b) Proporci
on de BwReqs Entregados
(c) Tasa de Colisiones de BwReqs
(d) Probabilidad de Colisi

on de BwReqs
Figura 4.6: Graficas Escenario Descarga: Tasa de Envo y de Colision, Proporcion

BwReqs Entregados y Probabilidad de Colision
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
69
(a) Tasa Agregada de Expiraciones de T16
(b) Tasa Media de Expiraciones de T16
(c) Tasa Promedio de Timeouts
(d) Tasa Promedio de Paquetes Perdidos
Figura 4.7:
Graficas Escenario Descarga:
Expiraciones de T16, Paquetes TCP
Perdidos, Timeouts
porcentaje de entrega de estos paquetes, y esto es mas notable a partir de 23 SSs,
donde la mejora esta en un 3% del total.
La tasa de Colision mostrada en la grafica de la Figura 4.6.c, expresa la ventaja de
la poltica rDDA respecto a la poltica dDDA, donde esta tasa se reduce en un 22%.
As mismo, la probabilidad de que un paquete colisione tambien se ve reducida como
se puede ver en la Figura 4.6.d. En las graficas mostradas en la Figura 4.6 resalta
que a partir de 23 SSs, ocurre un cambio en el comportamiento de sistema, donde se
comienzan a enviar mas BwReqs, posiblemente debido al n
umero de slot del perodo
de contencion, y a los valores de T16 y del tama
no de la trama2 .
2
Seg
un los resultados de trabajos previos mostrados en Seccion 1.1, y seg
un lo referenciado por
Paltrinieri [29]
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
70
(a) Promedio de BwReqs en la Cola Actual
(b) Histograma de Frecuencia para 8 SSs
(c) Histograma de Frecuencia para 17 SSs
(d) Histograma de Frecuencia para 26 SSs
Figura 4.8: Graficas Escenario Descarga: Cantidad de BwReqs en la Cola Actual al

Momento de Procesarla
Seg
un la grafica mostrada en la Figura 4.7.a, con el uso de la poltica rDDA la
tasa de expiraciones de T16 en el sistema disminuye en un 20% respecto a la poltica
dDDA para altas cargas de nodos (mas de 22 SSs). Un efecto similar se puede ver
para la tasa de expiraciones media de T16 (Vease la Figura 4.7.b).
Ahora viendo el comportamiento a nivel transporte, observamos en las graficas
de la Figura 4.7.c y la Figura 4.7.d, la tasa de Timeouts y perdida de paquetes
respectivamente, donde rDDA tiene inferior valor para estas tasas promedio cuando
hay peque
nas cantidades de SSs (menos de 8 nodos SS).
En la Figura 4.8.a se muestra que con el uso de la poltica rDDA, en promedio
hay un menor n
umero de BwReqs en cola al momento en que esta se procesa, y ello
disminuye mas cuando el valor de es mayor. De esta misma grafica se puede deducir
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
71
que con el uso de la poltica rDDA se reduce la cantidad de BwReqs que las SSs
emiten en comparacion con el uso de la poltica dDDA, sin afectar el rendimiento como
anteriormente se mostro en la Figura 4.4.a. Cuando hay pocas SSs (8 y 17 SSs, veanse
las Figuras 4.8.b y 4.8.c respectivamente), el uso de rDDA hace que hayan mas colas
vacas que con dDDA. En cambio, cuando hay mas de 20 SSs se puede ver que rDDA
tiene un n
umero inferior de colas vacas, como se puede ver en el comportamiento para
26 SSs mostrado en la Figura 4.8.d.
4.2.2
Escenario tr
afico de data en modo Carga
Ahora veamos el escenario en el que todas las SSs estan cargando un archivo a un
servidor. De esta manera, los paquetes de data van a estar transmitiendose de los
nodos SS pasando por la BS (en el UL) hasta el servidor, y los ACKs en direccion
contraria (en el DL).
En la Figura 4.9.a vemos que para las diferentes cantidades de SSs se obtiene un
rendimiento similar entre las polticas rDDA y dDDA. Esto, sin afectar la distribucion
justa del ancho de banda entre las distintas SSs como lo muestra la grafica de la
Figura 4.9.b. En la Figura 4.9.c se puede observar que el ancho de banda en el DL no
se esta usando completamente, y que en promedio se utiliza de forma similar entre las
polticas comparadas. Sin embargo, seg
un la grafica de la Figura 4.9.d notamos que
el UL si se esta usando mas completamente cuando se emplean las diversas polticas
(aproximadamente 99%), lo que indica que esta subtrama es la que esta restringiendo
el rendimiento del sistema.
En las graficas mostradas en la Figura 4.10, vemos que en lneas generales la poltica
rDDA refleja un comportamiento similar a iDDA y a dDDA para diferentes cantidades
de SSs, en cuanto a tasa de envo y entrega de BwReqs, tasa de colision y probabilidad
de colision de BwReqs. Este mismo comportamiento se puede ver en las graficas de las
expiraciones de T16, Timeouts y perdida de paquetes TCP mostradas en la Figura 4.11.
En la Figura 4.12.a se puede ver que la cantidad de BwReqs que en promedio hubo
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
72
(b) Indice de Fairness de Jain
(c) Proporci
(d) Proporci
Figura 4.9: Graficas Escenario Carga: Rendimiento, Fairness, y Proporcion de Uso del
Ancho de Banda
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
73
(b) Proporci

on de BwReqs
Figura 4.10: Graficas Escenario Carga: Tasa de Envo y de Colision, Proporcion

BwReqs Entregados y Probabilidad de Colision
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
74
Figura 4.11: Graficas Escenario Carga: Expiraciones de T16, Paquetes TCP Perdidos,
Timeouts
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
75
Figura 4.12: Graficas Escenario Carga: Cantidad de BwReqs en la Cola Actual al

Momento de Procesarla
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
76
en cola al momento de procesar es similar entre las polticas rDDA, iDDA y dDDA.
De all mismo, es deducible que en promedio las SSs emiten las mismas cantidades de
BwReqs por tramas en todas las polticas, a diferencia del escenario anterior donde
se emitan menos BwReqs con rDDA. Cuando hay pocas SSs (como 8 y 17 SSs) el
procesamiento de los BwReqs se efect
ua casi con las misma distribucion (Veanse las
Figuras 4.12.b y 4.12.c). Sin embargo, cuando hay mayores cantidades de SSs (como
26), es observable que la distribucion de los BwReqs es mejor la poltica rDDA, donde
aprovecha los momentos cuando hay colas vacas para procesar BwReqs de proximas
tramas, en comparacion con la poltica dDDA que presenta cierto n
umero de colas
vacas (Vease la Figura 4.12.d).
4.2.3
Escenario Tr
afico Cruzado
En este escenario se considera una red con caractersticas mas de acuerdo a las que
funcionan en la Internet, donde las trasmisiones de datos van en ambas direcciones
de forma simultanea. Este escenario es una combinacion de los escenarios anteriores,
donde la mitad de las SSs solo estan cargando un archivo en un servidor, y la otra
mitad solo lo esta descargando. De esta manera, los BwReqs van a solicitar AdB para
trasmitir ACKs en algunos casos y en otros DATA. Se puede ver tambien, la mezcla
de paquetes de datos y ACKs en una misma subtrama.
En este escenario observamos las ventajas que ofrece la poltica rDDA respecto a
la poltica dDDA. Para pocas SSs (menos de 18) vemos que rDDA presenta mejor
rendimiento que dDDA y que iDDA, principalmente con ={5,7}, y para mayores
cantidades tiene un comportamiento similar (Vease la Figura 4.13.a).
Los ACKs compitiendo por recursos en la direccion BS-SS tienen un impacto en
el aprovechamiento equitativo del ancho de banda de descarga. Esto se puede ver en
la Figura 4.13.b donde notamos que la distribucion equitativa para la asignacion de
ancho de banda en Descargas se ve afectada. No obstante, rDDA con = 3 presenta
un ndice de justica promedio de 0.95, mayor que la poltica dDDA cuyo ndice
promedio es 0.9. De aqu vemos que distribuir los BwReqs para tratarlos a posteriori,
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
77
(b1) Indice de Fairness de Jain para Descargas
(b2) Indice de Fairness de Jain para Cargas
(c) Proporci
(d) Proporci
Figura 4.13: Graficas Escenario Trafico Cruzado: Rendimiento, Fairness, y Proporcion

de Uso del Ancho de Banda
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
78
(b) Proporci

on de BwReqs
Figura 4.14: Graficas Escenario Trafico Cruzado: Tasa de Envo y de Colision,

Proporcion BwReqs Entregados y Probabilidad de Colision
trae beneficios en el uso equitativo del ancho de banda entre los flujos. En el caso del
UL, el ndice de justicia se mantiene muy parecido con las polticas evaluadas, como
lo muestra la grafica en la Figura 4.13.c.
Dado que el UL esta siendo usado casi en su totalidad y de igual forma por todas
las polticas durante las transferencias (Vease la Figura 4.13.e), y que la grafica del
rendimiento tiene una forma similar a la del uso del ancho de banda del DL (Vease la
Figura 4.13.d.), podemos decir que la mejora en el rendimiento por parte de rDDA, se
debe a un mejor uso del DL que realiza esta poltica.
En el caso de los BwReqs, se puede ver que las polticas rDDA y dDDA tienen un
comportamiento muy parecido (Veanse las grafica de la Figura 4.14). No obstante,
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
79
Figura 4.15: Graficas Escenario Trafico Cruzado: Expiraciones de T16, Paquetes TCP
Perdidos, Timeouts
ambas polticas tienen una menor tasa de entrega de BwReqs que la poltica iDDA
(Figura 4.14.b) y una mayor tasa y probabilidad de colisiones (Figuras 4.14.c y 4.14.d).
En la tasa de envo de BwReqs, iDDA presenta menor emision de estos paquetes
en comparacion con las polticas dDDA y rDDA cuando hay pocas SSs (Vease la
Figura 4.14.a).
En la Figura 4.15.a y en la Figura 4.15.b se puede apreciar una reduccion de las
expiraciones de T16 utilizando la poltica rDDA comparada con la dDDA cuando hay
menos de 18 SSs. Tambien, en la tasa de Timeouts TCP se puede ver disminucion
de expiraciones con el uso de rDDA, entre 5 y 18 SSs (Figura 4.15.c). En cambio, en
la Figura 4.15.d no se muestra una mejora entre alguna de las dos polticas (rDDA
y dDDA), ya que en algunos puntos rDDA tiene menor tasa de perdida de paquetes
lisis de me
tricas y gra
ficas obtenidas
4.2 Ana
80
Figura 4.16: Graficas Escenario Trafico Cruzado: Cantidad de BwReqs en la Cola

Actual al Momento de Procesarla
TCP, y en otros puntos es mejor dDDA.
En la Figura 4.16.a resaltan tres rangos: para menos de 12 SSs se presenta
un comportamiento similar entre las polticas. Entre 12 y 20 SSs, rDDA tiene un
mayor promedio de envo y procesamiento de BwReqs que dDDA. Y para mas
de 20 SSs dDDA procesa en promedio mayor n
umero de BwReqs, por lo que se
puede decir que tiene una mayor tasa de envo. Las Figuras 4.16.b, 4.16.c, y 4.16.d
muestran que hubo menos colas vacas con la poltica rDDA, que con la poltica dDDA.
Captulo 5
Conclusiones y Trabajos Futuros
En este trabajo se dise
no, implemento, y estudio, una nueva poltica para la gestion
del ancho de banda de flujos TCP en Redes 802.16 (WiMAX), llamada Gestion
del Ancho de Banda con Retardo Aleatorio (rDDA o randon delay DDA). En tres
escenarios principales, se comparo su desempe
no con dos polticas de administracion
de ancho de banda similares, iDDA y dDDA. Para ello se usaron diversas metricas
de evaluacion de redes como lo son el Rendimiento, la Probabilidad de Colision de
BwReqs, la Tasa de Expiracion de T16s, entre otras.
5.1
Conclusiones
En este estudio, observamos que rDDA es capaz de distribuir mas eficientemente el

ancho de banda en descargas, en escenarios de trafico en el que los nodos SS solo
realizan descargas y tambien en escenario de trafico cruzado (descargas y cargas
simultaneamente). Esto representa una ventaja para lo correspondiente al uso com
un
de la Internet, donde los usuarios son principalmente consumidores de la informacion.
Se obtuvo tambien, un trato equitativo en los flujos, una caracterstica deseable en el
dise
no de redes.
La reduccion en la tasa de envo de BwReqs que produce el uso de la poltica rDDA
n de esta poltica en Redes WiMAX

5.2 Beneficios con la implementacio
82
respecto a dDDA, sobretodo cuando hay mas de 20 SSs en escenarios de descarga y

de trafico cruzado, no afecta en rendimiento del sistema como se puede observar en
las respectivas graficas del escenario de descarga (Figura 4.8.a y Figura 4.4.a), y del
escenario de trafico cruzado (Figura 4.16.a y Figura 4.13.a).
El ancho de banda puede ser utilizado mejor si prestamos atencion al valor adecuado
para el timer T16 y para el tama
no de la trama (duracion). Ademas es necesario
considerar el tama
no del perodo de contencion (n
umero de slots), para evitar aumento
de emision brusca de BwReqs (como las ocurridas a partir de 20 SSs en las graficas
de Figura 4.6), y por ende de colisiones y expiraciones de T16s.
5.2
Beneficios con la implementaci

on de esta
poltica en Redes WiMAX
Debido a la ventaja ofrecida con el uso de la nueva poltica, a saber, reduccion de

colisiones y de expiraciones de T16 para escenarios de solo descarga, y mejora de
rendimiento en escenarios de trafico cruzado, se espera que pueda ofrecerse un mejor
servicio al atender mas solicitudes de ancho de banda para el UL y aprovechar mejor
ese recurso en el uso de los enlaces. Esto supondra una mejora en la transmisiones de
datos de la Internet en estas redes, ya que la mayor parte de ese trafico es transmitido
usando TCP, el trafico considerado en las pruebas realizadas.
5.3
Trabajos Futuros
Realizar un modelo para que la distribucion de ancho de banda entre las subtramas
sea autoajustable, dependiendo de la demanda de ese en los enlaces. De manera que
se pueda reducir la subutilizacion del ancho de banda previsto para las subtramas
en escenarios de solo descarga (Figuras 4.4.c y 4.4.d) y solo carga (Figuras 4.9.c y 4.9.d).
Analizar con mas a detalle la ganancia obtenida en el rendimiento agregado para
Trafico Cruzado, cuando hay pocas SSs (menos de 20) (Figura 4.13.a).
5.3 Trabajos Futuros
83
Estudiar con mas detalle el impacto de la demora generada por la poltica rDDA
en retransmisiones de TCP, como se pudo observar en la Figura 3.2.
Figura 5.1: Uso del ancho de banda por UGS, rtPS y nrtPS
Considerar el uso de ancho de banda de otras clases de servicio (UGS rtPS, y
nrtPS), para la administracion de BE. Por ejemplo, en la Figura 5.1 se muestra como
podra ser un escenario en el que esten otras clases de servicio consumiendo ancho
de banda, lo que limita la cantidad de ese recurso que se va a utilizar para trafico
con BE, por lo que el sistema MSOAB pudiera requerir algunas polticas extras para
poder satisfacer las necesidades de ancho de banda.
Ap
endice A
Correcci
on en m
etrica de M
odulo
MSOAB de WiMAX
La cantidad de BwReqs enviados en el sistema fue recalculado, contando ahora estos
paquetes en el metodo transmitir de las SSs (funcion transmitirSS()). Adicionalmente,
fueron contados los BwReqs que llegaron a la BS en el metodo recibirBS(). Sin
embargo, la cantidad obtenida en el contador de BwReqs enviados no coincida con el
contador que usaba anteriormente el modulo para obtener las metricas.
Para comprobar cual de los dos contadores tena el valor correcto, se aplico la
formula sencilla que se muestra mas adelante, donde a la cantidad de enviados se le
resta la cantidad de BwReqs perdidos (que en el caso del escenario simulado fueron
por colision). Este resultado debe dar el n
umero de paquetes entregados, que fue
obtenido al contarlos en el metodo de recibir de la BS. Y a su vez, este valor debe ser
igual o muy parecido al de los BwReqs que fueron procesados.
EntregadosCalculado = EnviadosSS P erdidos
En la Tabla A.1 se muestran los valores obtenidos del escenario de descarga para
n en me
trica de Mo
dulo MSOAB de WiMAX
A Correccio
85
la poltica dDDA. All, se puede observar en la segunda fila (datos para 2 SSs), que
el calculo realizado a partir del contador en el metodo transmitir de las SS (contador
nuevo) corresponde con la cantidad contada en el metodo RecibirBS() y con la
cantidad contada en el momento de procesar los BwReqs. En las columnas F, G y H,
se puede ver que los valores corresponden en casi todas las filas, y en las demas son
muy aproximados.
198198
199347
200263
198886
201049
201749
259564
264311
265149
267938
11
14
17
20
23
26
29
32
anterior)
190616
TransmitSS())
(contador
SSs
(contador en
Enviados
Num
57832
57564
57850
48822
2432
2275
1925
926
1216
1418
782
Perdidos
Calculo
[F]
Calculo
210106
207585
206461
210742
199317
198774
196961
199337
198131
196780
189834
(con [B]-[D])
265304
262500
261794
257672
201250
200613
198572
200053
199178
198073
190591
(con [C]-[D])
265304
262500
261794
257672
201251
200614
198573
200053
199178
198073
190591
RecibirBS())
(contador en
265304
262500
261794
257671
201251
200613
198573
200053
199177
198073
190591
Procesados
[G] Cantidad [H] Cantidad
Entregados 1 Entregados 2 Entregado
[D] Cantidad [E]
Tabla A.1: Datos de BwReqs en Escenario Descarga para la Poltica dDDA
323136
320064
319644
306494
203682
202888
200497
200979
200394
199491
191373
Enviados
[B] Cantidad [C] Cantidad
[A]
n en me
trica de Mo
dulo MSOAB de WiMAX
A Correccio
86
Bibliografa
[1] IEEE Computer Society, and the IEEE Microwave Theory and Techniques Society,
(29 Mayo de 2009). IEEE Standard for Local and metropolitan area networks.
Part 16: Air Interface for Broadband Wireless Access Systems. Consultado el
8 de Noviembre de 2011, de URL http://standards.ieee.org/getieee802/
download/802.16-2009.pdf.
[2] Dr. Winston W. Royce, (1970).
Software Systems.
Managing the Development of Large
Consultado el 15 de Abril de 2012,
de URL
http://leadinganswers.typepad.com/leading_answers/files/original_
waterfall_paper_winston_royce.pdf.
[3] Laboratorio Nacional de Calidad del Software de INTECO, (Marzo de 2009).
Modelo en cascada por Guia de Ingeniera Del Software.
Consultado el
15 de Abril de 2012, de URL http://es.scribd.com/doc/62931905/15/

Modelo-en-cascada.
[4] NSnam, (28 de Diciembre de 2011). The Network Simulator - ns-2. Consultado
el 08 de Marzo de 2012, de URL http://www.isi.edu/nsnam/ns/.
[5] Red sin Fronteras, (14 de Septiembre de 2009). Captulo 1: Redes Inalambricas.
Consultado el 26 de Noviembre de 2010, de URL http://www.redsinfronteras.
org/pdf/redes_wireless.pdf.
[6] Kioskea.net, (16 de Octubre de 2008). Redes Inalambricas. Consultado el 11
de Noviembre de 2010, de URL http://es.kioskea.net/contents/wireless/
wlintro.php3.
BIBLIOGRAFIA
88
[7] Jonathan Chavarria, (14 de Agosto de 2008).

Fsica (Capa 1).
Redes de datos:
Capa
de URL http://jonachavarria.blogspot.com/2008/08/
la-capa-fsica-del-modelo-de-referencia.html.
[8] WikiLibros, (8 de Octubre de 2010).
de modulacion.
Electronica de Comunicaciones/Tipos
Consultado el 27 de noviembre de 2010,
de URL
http://es.wikibooks.org/wiki/Electr%C3%B3nica_de_Comunicaciones/
Tipos_de_modulaci%C3%B3n.
[9] toip.uchile.cl. Anexos F y G - F. OFDM. Consultado el Noviembre de 2010, de
URL
http://toip.uchile.cl/mediawiki/upload/e/e5/AnexoFG-Marcomun.
pdf.
[10] Ruben Torres Mu
noz, (9 de Diciembre de 2009). COFDM MODULACION Wikitel. Consultado el Octubre de 2010, de URL http://wikitel.info/wiki/
COFDM_MODULACION.
[11] Rede Nacional de Ensino e Pesquisa, (28 de Enero de 2004).
Sobre QoS.
Consultado el 11 de Enero de 2011, de URL http://www.rnp.br/es/qos/sobre.

html.
[12] Kioskea.net, (16 de Octubre de 2008).
WiMAX - 802.16 - Interoperabilidad
mundial para acceso por micro. Consultado el 11 de Noviembre de 2010, de URL

http://es.kioskea.net/contents/wimax/wimax-intro.php3.
[13] The IEEE 802.16 Working Group, (1 Octubre de 2004). Standart IEEE 802.162004. Consultado el 8 de Noviembre de 2011, de URL http://standards.ieee.
org/getieee802/download/802.16-2004.pdf.
[14] Ing. William Marn Moreno, (5 de Octubre de 2005). Modelo OSI. Consultado
el Noviembre de 2010, de URL http://www.ie.itcr.ac.cr/marin/mpc/redes/
Modelo_osi_tcp_ip(oficial).pdf.
[15] Jose Mara Barcelo Ordinas, Jordi I
nigo Griera, Ramon Mart Escale, Enric Peig
Olive, Xavier Perramon Tornil, (6 de Febrero de 2008). Redes de Computadores.
de URL http://www.uoc.edu/masters/oficiales/img/922.pdf.
BIBLIOGRAFIA
[16] Jose Miguel Alonso.
89
Protocolos de comunicaciones para sistemas abiertos.
Addison-Wesley Iberoamericana, 1995.

[17] A. Arcia; N. Montavont; A. Paltrinieri; and D Ros. Improving uplink bandwidth
management in 802.16 networks. In Proceedings of IEEE Local Computer Networks
(LCN), Octubre 2009.
[18] Andres Arcia. Captulo 3 control de congestion, Junio 2010.
[19] Andres Arcia. Modifying the TCP Acknowledgement Mechanism: An Evaluation
and Application to Wired and Wireless Networks. LAP LAMBERT Academic
Publishing, Enero 2011.
[20] L. Lenzini E. Mingozzi C. Cicconetti and C. Eklund. Quality of service support in
ieee 802.16 networks. In Proceedings of IEEE Local Computer Networks (LCN),
Marzo 2006.
[21] D.-H. Cho; J.-H. Song; M.-S. Kim; and K.-J. Han. Performance analysis of the ieee
802.16 wireless metropolitan area network. Proceedings of the 1st International
Conference on Distributed Frameworks for Multimedia Applications (DFMA 05),

pages 130136, Febrero 2005.
[22] J. Delicado; F. M. Delicado; and L. Orozco-Barbosa. Study of the ieee 802.16
contention-based request mechanism. Telecommunication Systems, 38(1-2), Junio
2008.
[23] Arunabha Ghosh y Rias Muhamed Jeffrey G. Andrews. Fundamentals of WiMAX
Understanding broadband Wirelwss Networking. Prentice Hall, 2007.
[24] V. Kobliakov; A. Turlikov; and A. Vinel. Distributed queue random multiple access
algorithm for centralized data networks. IEEE Tenth International Symposium on
2006.
Consumer Electronics (ISCE 06),
[25] M. Mojdeh; H. Alavi; N. Yazdani; and C. Lucas.
An adaptive bandwidth
reservation method for ieee 802.16 bwa system: Using data mining techniques.
BIBLIOGRAFIA
90
14th IST Mobile & Wireless Communications Summit, 2005. URL http://www.
eurasip.org/Proceedings/Ext/IST05/papers/473.pdf.
[26] Andres Arcia Moret; Yubo Yang; Nicolas Montavon; and David Ros. A study of
bandwidth-perception management mechanisms in ieee 802.16 networks. Technical
Report, arXiv.org, Abril 2010. URL http://arxiv.org/pdf/1004.0050v1.
[27] Q. Ni; A. Vinel; Y. Xiao; A. Turlikov; and T. Jiang. Investigation of bandwidth
request mechanisms under point-to-multipoint mode of wimax networks. IEEE
Communications Magazine, 45(5):132138, 2007. URL http://bura.brunel.ac.
uk/handle/2438/2544.
[28] Loutfi Nuaymi. WiMAX technology for Broadband Wireless Access. Wiley, 2007.
[29] Alejandro Paltrinieri. Improving TCP performance on 802.16 networks. Masters
thesis, Universidad de Buenos Aires, 2009.
[30] A. Vinel; Y. Zhang; Q. Ni; and A. Lyakhov. Efficient request mechanism usage
in ieee 802.16. Proceedings of IEEE GLOBECOM, Noviembre 2006. URL http:
//bura.brunel.ac.uk/handle/2438/3603.
[31] Yubo Yang; Andres Arcia; Nicolas Montavont; y David Ros. On the impact of
ieee 802.16 bandwidth request-grant mechanisms on tcp. In Proceedings of Global
Communications Conference, Exhibition and Industry (GLOBECOM), Diciembre
2010.
[32] Dah Ming Chiu y Raj Jain. Analysis of the increase and decrease algorithms
for congestion avoidance in computer networks.
Computer Networks and
ISDN System, 1989. URL http://www.cs.rice.edu/~eugeneng/teaching/f05/

comp529/papers/cj89.pdf.
[33] Uma Shanker Jha y Ramjee Prasad. OFDM towards fixed and mobile broadband
wireless access. Artech House, 2007.
[34] Neil Reid y Ron Seide. 802.11 (Wi-Fi). McGraw-Hill Iteramericana, 2003.
[35] Natalia Olifer y Victor Olifer. Redes de Computadoras. Mc Graw Hill, 2009.

Diseño, Implementaci Ón y Prueba de Un Mecanismo de Gesti Ón de Ancho de Banda para Flujos TCP en Redes 802.16

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diseño, Implementaci Ón y Prueba de Un Mecanismo de Gesti Ón de Ancho de Banda para Flujos TCP en Redes 802.16

Hochgeladen von

Copyright:

Verfügbare Formate

Proyecto de Grado

Br. Diego Alexander Uzcategui Jota

Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . .

Distribucion del documento . . . . . . . . . . . . . . . . . . . . . . . .

Clasificacion de las redes inalambricas seg

Funcionamiento de las redes inalambricas . . . . . . . . . . . . . . . . .

Multiplexacion por Division de Frecuencias Ortogonales (Orthogonal

Descripcion del Smbolo OFDM en el dominio del tiempo . . . .

Calidad de servicio (Quality of Service o QoS) . . . . . . . . . . . . . .

Tipos de QoS en WiMAX (IEEE 802.16) . . . . . . . . . . . . .

Estructura de la trama OFDM - TDD en WiMAX . . . . . . . . . . . .

Estructura de la Subtrama para el Enlace de Bajada . . . . . .

Estructura de la Subtrama para el Enlace de Subida

Paquetes para solicitud de Ancho de Banda en WiMAX . . . . . . . . .

Polticas que pueden ser utilizadas en el Sistema MSOAB de WiMAX .

RPG (Reset per Grant)

DPG (Decrease per Grant) . . . . . . . . . . . . . . . . . . . . .

DDA (Decrease at Data Arrival ) . . . . . . . . . . . . . . . . .

iDDA (Decrease at Data Arrival with immediate BwReq

dDDA (Decrease at Data Arrival with delayed BwReq

2.11 Protocolo de Control de Transmision (Transmission Control Protocol o

2.11.1 Caractersticas del protocolo . . . . . . . . . . . . . . . . . . . .

2.11.2 Segmento TCP . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.11.3 Detalles del funcionamiento de las conexiones TCP . . . . . . .

2.11.3.1 Apertura de la conexion . . . . . . . . . . . . . . . . .

2.11.3.2 Transferencia de datos . . . . . . . . . . . . . . . . . .

2.11.3.3 Cierre de la conexion . . . . . . . . . . . . . . . . . . .

2.11.4 Control de Congestion en TCP . . . . . . . . . . . . . . . . . .

2.11.5 Control de flujo . . . . . . . . . . . . . . . . . . . . . . . . . . .

Modelo de Gestion de Ancho de Banda con Retardo Aleatorio . . . . .

La poltica rDDA en funcionamiento . . . . . . . . . . . . . . . . . . .

Efecto de la poltica rDDA sobre el RTT de TCP . . . . . . . .

Lista circular de Colas de BwReqs . . . . . . . . . . .

Metodo NuevoBwReqRecibido (BwReq) . . . . . . . . .

Metodo ObtenerAdBSolicitadoPorSS (IDcSS) . . . . .

Metodo ActualizarPercepcionAdB (IDcSS, AdBTransmit) 48

Planificacion del uso de ancho de banda de la trama . . . . . . . . . . .

DATA solo modo Descarga . . . . . . . . . . . . . . .

DATA solo modo Carga . . . . . . . . . . . . . . . . .

Trafico de DATA en ambas direcciones . . . . . . . . .

Proporcion del Ancho de Banda utilizado del DL . . .

Proporcion del Ancho de Banda utilizado en el UL . .

Tasa de Envo de BwReqs . . . . . . . . . . . . . . . .

Proporcion BwReqs entregados . . . . . . . . . . . . .

Tasa de Colision de BwReqs . . . . . . . . . . . . . . .

Probabilidad de Colision de BwReqs . . . . . . . . . .

Tasa Agregada de Expiraciones del T16 . . . . . . . .

4.1.4.10 Tasa Media de Expiraciones del T16 . . . . . . . . . .

4.1.4.11 Promedio de Timeouts . . . . . . . . . . . . . . . . . .

4.1.4.12 Promedio de Paquetes Retransmitidos . . . . . . . . .

4.1.4.13 Promedio de BwReqs en Cola . . . . . . . . . . . . . .

4.1.4.14 Histograma de Frecuencia de la Cantidad de BwReqs

en Cola al momento de procesarla . . . . . . . . . . . .

Analisis de metricas y graficas obtenidas . . . . . . . . . . . . . . . . .

Escenario trafico de data en modo Descarga . . . . . . . . . . .

Escenario trafico de data en modo Carga . . . . . . . . . . . . .

Escenario Trafico Cruzado . . . . . . . . . . . . . . . . . . . . .

5 Conclusiones y Trabajos Futuros

Beneficios con la implementacion de esta poltica en Redes WiMAX . .

A.1 Datos de BwReqs en Escenario Descarga para la Poltica dDDA . . . .

Topologa de las Redes WiMAX . . . . . . . . . . . . . . . . . . . . . .

Metodologa en Cascada con Prototipos Evolutivos . . . . . . . . . . .

Clasificacion de las Redes Inalambricas seg