Análisis de Servicios Web en Redes SDN

UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS

DEPARTAMENTO DE INGENIERÍA ELÉCTRICA
ANÁLISIS DE SERVICIOS WEB EN REDES SDN
TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN INGENIERÍA DE REDES DE

COMUNICACIONES
ANDRÉS FERNANDO CÓRDOVA MOLINA
PROFESOR GUÍA:
ALBERTO CASTRO ROJAS
MIEMBROS DE LA COMISIÓN:
CÉSAR AZURDIA MEZA
JUAN PÉREZ RETAMALES
SANTIAGO DE CHILE
2017
RESUMEN DE LA TESIS PARA OPTAR
AL TÍTULO DE MAGÍSTER EN INGENIERÍA DE REDES DE COMUNICACIONES
POR: ANDRÉS FERNANDO CÓRDOVA MOLINA
FECHA: 2017
PROF. GUÍA: SR. ALBERTO CASTRO ROJAS
ANÁLISIS DE SERVICIOS WEB EN REDES SDN
El escenario actual de las redes tradicionales es que cada nodo de red tiene su propia unidad de
procesamiento y administra sus planos de control y de datos de usuarios, donde la complejidad
de la gestión de la red aumenta conforme crece su tamaño. Ante este escenario se da un
cambio importante en la manera de hacer networking, adoptándose las redes SDN, Software
Defined Networks. Esta tecnología busca mejorar los resultados globales en desempeño y
administración de las redes de comunicaciones. Paralelo a esto, el uso de servidores web se
ha ido popularizando dentro de Internet, dado que son capaces de brindar diferentes tipos
de servicios como transacciones bancarias, streaming, comunicaciones cifradas, etc.
Las redes SDN han sido desplegadas por grandes compañías como “Google” que terminó
la implementación de SDN en el año 2011. Aunque SDN está siendo globalmente adoptado,
no es utilizado masivamente por empresas de distintos tamaños y no está estandarizado en
su totalidad, por lo que es necesario desarrollar estudios que nos indiquen de manera técnica,
las diferencias, desventajas y virtudes que tienen en comparación con las tecnologías legacy.
casa
En este trabajo se desarrolla un escenario de pruebas de un servidor web sobre una red
SDN y legacy (red tradicional). Las pruebas consisten en variar la condiciones de red como:
delay y packet loss, y la tecnología de acceso entre WLAN (wireless local area network) y
LTE (long term evolution). Para construir los escenarios de pruebas se utiliza un conjunto
de herramientas de hardware y software al alcance de cualquier investigador. Se emulan
componentes de la red y se utiliza hardware especializado, generándose resultados desde el
tráfico “real” que circuló por la infraestructura de los proveedores de Internet.
Antes de la ejecución de las pruebas se determina mediante estadística descriptiva, los

niveles de delay y packet loss a usar en los experimentos. Este análisis es necesario dado
que no se desea incluir condiciones de red que interrumpan totalmente las comunicaciones o
que generen comportamientos anómalos en la red. Adicionalmente se calcula el número de
muestras necesario para determinar la veracidad de las hipótesis planteadas, con un rango
de niveles de confianza entre un 90 % y 70 %.
Para la resolución de las hipótesis se diseñan modelos estadísticos que permiten comparar
el comportamiento de SDN en el tiempo y estos modelos se usan como entradas para distintos
test estadísticos y análisis de las hipótesis planteadas. Finalmente se concluye que, aunque
una infraestructura SDN y una infraestructura legacy presentan marcadas diferencias en su
funcionamiento para soportar los servicios web, su desempeño comparando el número de
conexiones exitosas y el throughput es similar, y estadísticamente idéntico en varios casos
analizados, con un máximo de 3 % de diferencia para las conexiones exitosas y 2x10−6 para
el throughput. Se presentan pequeñas diferencias en los casos en los que no se encuentran
desempeños similares siendo estos a favor de una infraestructura legacy.
i
Agradecimientos
El principal agradecimiento es para mi familia y novia Jéssica Romero, por no permitir

que baje los brazos, estar muy pendientes de mí. A mis compañeros de maestría, en especial
a Daniel Orellana, Jhilmar Molina, Pablo Palacios, Jorge Flores, Hugo Cárdenas, Rafaela
Ortega y Lenin Vargas quienes se convirtieron en mi familia por el tiempo que estuve en
Chile. A mis primos Fernanda Cordero, David Carpio y Octavio Cordero, por estar siempre
listos a darme una mano y ayudarme en cualquier adversidad.
Al gobierno ecuatoriano por brindarme la beca de estudio.
A mis profesores que pusieron su empeño en entregarnos conocimientos de calidad.
ii
Tabla de Contenido
1. Introducción 1
2. Marco Teórico 3
2.1. Software Defined Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Funcionamiento de SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1. Interfaces Northbound y Southbound . . . . . . . . . . . . . . . . . . 4
2.2.2. Tablas de Flujo (Flow Tables) . . . . . . . . . . . . . . . . . . . . . . 4
2.2.3. Separación de planos . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.4. Dispositivo simple y control descentralizado . . . . . . . . . . . . . . 5
2.2.5. Controlador SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.6. Aplicaciones SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.7. Dispositivos SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.8. Dispositivo basado en Software . . . . . . . . . . . . . . . . . . . . . 6
2.2.9. Dispositivo basado en hardware . . . . . . . . . . . . . . . . . . . . . 7
2.2.10. Operación de SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Servidor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Desempeño de un servidor Web . . . . . . . . . . . . . . . . . . . . . 8
2.4. Balanceo de Carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Tecnologías de Acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1. IEEE 802.11n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.2. 3GPP long term evolution (LTE) . . . . . . . . . . . . . . . . . . . . 10
2.6. Métricas de Desempeño de Red . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7. Test de Normalidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8. Series de Tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.1. Modelos Lineales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.2. Modelo AR (autoregressive) . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.3. Modelo MA (moving-average) . . . . . . . . . . . . . . . . . . . . . . 13
2.8.4. Modelo ARMA (autoregressive–moving-average) . . . . . . . . . . . . 13
2.8.5. Modelo ARIMA (autoregressive integrated moving average) . . . . . 13
2.8.6. Modelo SARIMA (seasonal autoregressive integrated moving average) 14
3. Metodología 15
3.1. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1. Selección de Herramientas para la implementación . . . . . . . . . . . 15
3.2. Configuración de Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Configuración de GNS3 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
iii
3.2.2. Configuración de Mininet . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3. Configuración de HPE VAN SDN Controller . . . . . . . . . . . . . . 19
3.2.4. Configuración de Netem . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.5. Configuración de Wireshark . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.6. Configuración Funkload . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.7. Configuración Kemp Load Balancer . . . . . . . . . . . . . . . . . . . 22
3.2.8. Configuraciones Adicionales . . . . . . . . . . . . . . . . . . . . . . . 23
3.3. Cálculo del tamaño de la muestra . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4. Límites de los experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1. Análisis de Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.2. Análisis de delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.3. Medición de Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.4. Análisis Combinado de Delay y Packet Loss . . . . . . . . . . . . . . 32
3.5. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4. Análisis de Datos 34
4.1. Estadística Descriptiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.1. Grafos aplicados a Redes . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. Modelación de los datos experimentales . . . . . . . . . . . . . . . . . . . . . 41
4.2.1. Modelos propuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3. Test ANOVA (analysis of variance), Test de Hipótesis y Test de los rangos con
signo de Wilcoxon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1. Acceso WLAN con condiciones adversas de red . . . . . . . . . . . . 45
4.3.2. Acceso WLAN sin condiciones adversas de red . . . . . . . . . . . . . 47
4.3.3. Acceso LTE, con condiciones adversas de red . . . . . . . . . . . . . . 49
4.3.4. Acceso LTE sin condiciones adversas de red . . . . . . . . . . . . . . 51
5. Conclusiones 53
5.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2. Metodología y tipo de investigación . . . . . . . . . . . . . . . . . . . . . . . 54
5.3. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Bibliografía 59
Anexos 61
A. Hardware y software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1. Descripción del hardware disponible . . . . . . . . . . . . . . . . . . . 62
2. Descripción de los Simuladores de redes revisados . . . . . . . . . . . 62
3. Descripción de Controladores SDN revisados . . . . . . . . . . . . . . 63
4. Generadores de condiciones de red . . . . . . . . . . . . . . . . . . . . 64
5. Herramientas para mediciones . . . . . . . . . . . . . . . . . . . . . . 65
6. Software para Balanceo de Carga . . . . . . . . . . . . . . . . . . . . 66
7. Software para generación de tráfico . . . . . . . . . . . . . . . . . . . 66
8. Software para análisis estadístico . . . . . . . . . . . . . . . . . . . . 67
B. Código en R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
1. Estadística Descriptiva . . . . . . . . . . . . . . . . . . . . . . . . . . 68
iv
2. Código para encontrar el mejor modelo Lineal, Arima o Sarima . . . 73
3. Código para prueba Anova y Test de Hipótesis . . . . . . . . . . . . . 78
4. Código para generación de Grafos . . . . . . . . . . . . . . . . . . . . 80
C. Tipo de Modelo y parámetros de cada muestra . . . . . . . . . . . . . . . . . 84
D. Estadística Descriptiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
v
Índice de Tablas
3.1. Herramientas Seleccionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2. Direcciones IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Tamaño de la muestra para conexiones exitosas . . . . . . . . . . . . . . . . 25
3.4. Tamaño de la muestra para el throughput . . . . . . . . . . . . . . . . . . . 26
3.5. Nivel de confianza y potencia para las conexiones exitosas con 40 muestras . 26
3.6. Nivel de confianza y potencia para el throughput con 40 muestras . . . . . . 26
3.7. Análisis de Packet Loss con infraestructura SDN y acceso WLAN . . . . . . 27
3.8. Análisis de delay con infraestructura SDN y acceso WLAN . . . . . . . . . . 30
3.9. Medición de Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.10. Análisis de delay y Packet Loss combinado . . . . . . . . . . . . . . . . . . . 32
4.1. Estadística Descriptiva de las pruebas sin SDN, sin condiciones adversas de
red y acceso WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2. Correlación de pruebas sin SDN, sin condiciones adversas de red y acceso WLAN 35
4.3. Estadística Descriptiva de pruebas con SDN, con condiciones adversas de red
y acceso WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4. Correlación de pruebas con SDN, con condiciones adversas de red y acceso
WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5. Estadística Descriptiva de pruebas con SDN, sin condiciones adversas de red
y acceso LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6. Correlación de pruebas con SDN, sin condiciones adversas de red y acceso LTE 38
4.7. Estadística Descriptiva de pruebas con SDN, con condiciones adversas de red
y acceso LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.8. Correlación de pruebas con SDN, con condiciones adversas de red y acceso LTE 39
4.9. Atributos Vértices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.10. Atributo Arcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.11. Prueba Saphiro-Wilk de Normalidad . . . . . . . . . . . . . . . . . . . . . . 42
4.12. Test de normalidad de datos generados . . . . . . . . . . . . . . . . . . . . . 44
4.13. Resultado de Pruebas de Grupo 1 relacionado con Conexiones Exitosas . . . 46
4.14. Resultado de Pruebas de Grupo 1 relacionado con Throughput . . . . . . . . 46
4.15. Resultado de Pruebas de Grupo 2 relacionado a Conexiones Exitosas . . . . 48
4.16. Resultado de Pruebas de Grupo 2 relacionado a Throughput . . . . . . . . . 48
vi
6.1. Tipo de Modelo para cada repetición del grupo sin SDN, sin condiciones ad-
versas de red y acceso WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.2. Tipo de Modelo para cada repetición del grupo con SDN, sin condiciones
adversas de red y acceso WLAN . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.3. Tipo de Modelo para cada repetición del grupo sin SDN, con condiciones
6.4. Tipo de Modelo para cada repetición del grupo con SDN, con condiciones
6.5. Tipo de Modelo para cada repetición del grupo sin SDN, sin condiciones ad-
versas de red y acceso LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.6. Tipo de Modelo para cada repetición del grupo con SDN, sin condiciones
adversas de red y acceso LTE . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.7. Tipo de Modelo para cada repetición del grupo sin SDN, con condiciones
6.8. Tipo de Modelo para cada repetición del grupo con SDN, con condiciones
6.9. Estadística Descriptiva de pruebas con SDN, sin condiciones adversas de red
y acceso WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.10. Correlación de pruebas con SDN, sin condiciones adversas de red y acceso
WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.11. Estadística Descriptiva de pruebas sin SDN, con condiciones adversas de red
y acceso WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.12. Correlación de pruebas sin SDN, con condiciones adversas de red y acceso
WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.13. Estadística Descriptiva de pruebas sin SDN, sin condiciones adversas de red y
acceso LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.14. Correlación de pruebas sin SDN, sin condiciones adversas de red y acceso LTE 95
6.15. Estadística Descriptiva de pruebas sin SDN, con condiciones adversas de red
y acceso LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.16. Correlación de pruebas sin SDN, con condiciones adversas de red y acceso LTE 96
vii
Índice de Ilustraciones
2.1. Operación de SDN [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2. Métricas de Desempeño de Red citenano9 . . . . . . . . . . . . . . . . . . . 11
3.1. GNS3 con arquitectura de red basada en SDN . . . . . . . . . . . . . . . . . 17

3.2. GNS3 con arquitectura de red Legacy . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Topología creada en mininet, observada desde controlador HPE VAN SDN . 19
3.4. Opciones de configuración de Netem . . . . . . . . . . . . . . . . . . . . . . 20
3.5. Configuración del tipo de scheduler utilizado para el balanceo de carga . . . 21
3.6. Imagen de IO Graph de Wireshark . . . . . . . . . . . . . . . . . . . . . . . 21
3.7. Configuración del tipo de scheduler utilizado para el balanceo de carga . . . 23
3.8. Configuración de la conexión del balanceador de carga con el controlador SDN 23
3.9. Esquema de Port fowarding . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.10. Gráficas de pruebas con SDN, con condiciones adversas de red y acceso LTE 29
3.11. Gráfica de pruebas con SDN, con condiciones adversas de red y acceso LTE . 31
4.1. Flujo de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2. Histogramas de pruebas sin SDN, sin condiciones adversas de red y acceso
WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3. Histogramas de pruebas con SDN, con condiciones adversas de red y acceso
WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4. Histogramas de pruebas con SDN, sin condiciones adversas de red y acceso LTE 38
4.5. Histogramas de pruebas con SDN, con condiciones adversas de red y acceso LTE 39
4.6. Grafo generado en R de infraestructura SDN . . . . . . . . . . . . . . . . . . 40
6.1. Histogramas de pruebas con SDN, sin condiciones adversas de red y acceso
WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.2. Histogramas de pruebas sin SDN, con condiciones adversas de red y acceso
WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.3. Histogramas de pruebas sin SDN, sin condiciones adversas de red y acceso LTE 95
6.4. Histogramas de pruebas con SDN, sin condiciones adversas de red y acceso LTE 96
viii
Capítulo 1
Introducción
1. Antecedentes
En la primera mitad del siglo XX las comunicaciones eran principalmente telefóni-

cas y se realizaban con conmutación de circuitos también llamadas comunicaciones
orientadas a la conexión, adicionalmente utilizaban topologías centralizadas, con gran
volumen de usuarios conectados a centros de conmutación. Este tipo de topología es
muy vulnerable, dado que las comunicaciones se interrumpen al eliminar cualquier enla-
ce. Paul Baran quien trabajó en Rand Corporation en los Estados Unidos en la década
de los 60, fue quien planteó la idea de que dada la poca seguridad que este tipo de
topología brindaba, era necesario escalar a una tecnología de conmutación de paquetes,
en donde cada paquete viaja de manera autónoma por la red y la comunicación puede
“sobrevivir” ante distintas fallas.
La idea de Baran fue adoptada por el Departamento de Defensa (DOD’s) y estuvo

operativa en el año 1969, conectaba centros de investigación y dependencias militares.
Las redes descentralizadas no orientadas a la conexión tuvieron su gran despliegue para
la década de 1990, y son la base del Internet que conocemos actualmente.
En conjunto con el uso de Internet, el número de textitdata centers hospedando servido-

res web aumentó. Entonces, fue necesario replicar data centers en distintas ubicaciones
geográficas con el fin de reducir la latencia entre cliente y servidor y dotar de redun-
dancia. Esto ha generado un aumento de hosts brindando distintos servicios dentro de
un data center, por ejemplo en un data center con 120.000 servidores físicos, y con 20
máquinas virtuales cada uno, se tienen que interconectar 240.000 hosts. Dado el tamaño
de estos data centers se generan nuevos desafíos relacionados con la gestión de red. Los
sistemas utilizados para gestionar la red, no son capaces de gestionar redes de estas
magnitudes. SDN (software defined network) fue pensado y diseñado para trabajar con
estas nuevas categorías de data centers, representando un cambio drástico en la forma
de hacer la conmutación de paquetes de los planos de datos de usuarios y de control
[1].
1
2. Objetivos
2.1. Objetivo principal

Medir y analizar el desempeño de una solución de balanceo de carga de servicios
web basada en SDN frente a distintas condiciones de red y tecnologías de acceso.
2.2. Objetivos específicos
2.2.1. Estudio del marco teórico, referente a la hipótesis planteada.
2.2.2. Establecer el hardware y software necesario para el experimento.
2.2.3. Diseñar y Construir los experimentos.
2.2.4. Realizar el número de pruebas necesarias.
2.2.5. Capturar los datos resultantes.
2.2.6. Analizar con base estadística los resultados.
3. Tipo de investigación y metodología
Dada la naturaleza de las hipótesis y objetivos recién listados, se realiza una inves-
tigación correlacional ya que se busca determinar cómo y en qué medida afectan las
distintas variables el desempeño de la red. Junto con la investigación inicial se usa una
metodología experimental ya que se cambian las condiciones de los eventos medidos,
para así repetir las veces que se considere necesario los experimentos y compararlos con
un grupo de control.
A continuación, se resumen las etapas de la metodología utilizada:
Estudio del Marco Teórico: se realiza un estudio bibliográfico de los conceptos relevantes
y directamente relacionados con los experimentos.
Diseño de los experimentos: se calcula en base a un estudio estadístico, los límites de

las condiciones adversas de red que serán aplicadas, así como también el número de
muestras necesarias para evitar errores estadísticos mayores.
Análisis de Datos: para el análisis de datos se construyen modelos como por ejemplo
ARMA (autoregressive–moving-average), ARIMA (autoregressive integrated moving
average), SARIMA (seasonal autoregressive integrated moving average). Se realizan
análisis de varianzas y test de hipótesis.
2
Capítulo 2
Marco Teórico
En el presente capítulo se describen los conceptos de SDN, servidores web, balanceo de

carga, métricas del desempeño de red y las herramientas estadísticas usadas en este traba-
jo. Una vez descritos estos conceptos se proceden a diseñar los experimentos, analizar los
resultados y obtener las conclusiones.
2.1. Software Defined Network
Existen varios conceptos que describen las Redes Definidas por Software, SDN por sus
siglas en ingles, esto se debe a que la tecnología todavía se encuentra en evolución y en la
actualidad no está estandarizada en su totalidad. Sin embargo, no es un concepto nuevo ya
que varias compañías lo han implementado hace varios años, como ejemplo Google utiliza
SDN desde el año 2011 [2].
Una definición simple y global es que SDN es una nueva manera de hacer networking en
donde se ha separado el plano de datos del plano de control y este es directamente programable
[1].
2.2. Funcionamiento de SDN
Una arquitectura SDN, está formada de varias partes como son: 1) interfaces northbound
y southbound,y aplicaciones controlador, dispositivos SDN,aplicaciones, plano de control y
datos. En la Figura 2.1, se puede observar como están relacionadas las distintas partes de la
arquitectura SDN. La definición de cada parte, se discute a continuación.
3
Vista Global de la Red
App App App App
Northbound API
Data Data Data
Controlador SDN Forwarding Forwarding Forwarding
Southbound API
Data Data
Forwarding Forwarding
flows flows flows

Data Data Data
Forwarding Forwarding Forwarding Dispositivos
SDN
flows flows
Data Data
Forwarding Forwarding
Figura 2.1: Operación de SDN [1]
2.2.1. Interfaces Northbound y Southbound
Las principales interfaces del controlador SDN son la northbound API (application pro-
gramming interface) y southbound API. La interfaz northbound permite al controlador la
comunicación con un elemento de mayor nivel como por ejemplo una aplicación. La Inter-
faz southbound, permite la comunicación con un elemento de menor nivel como lo son los
dispositivos SDN que el controlador configura. La interfaz southbound, actualmente utiliza
protocolos maduros y cercanos a la estandarización como lo es OpenFlow u otros; mientras
que la interfaz northbound, presenta deficiencia en la estandarización de protocolos y se han
presentado varios alternativas variadas y dependientes al controlador que se utilice [1].
2.2.2. Tablas de Flujo (Flow Tables)
Son una parte esencial de los dispositivos SDN. Es consultada cuando ingresa un paquete
de datos para buscar una regla a la que se ajuste el paquete que ingresa y de esta manera
tomar ejecutar una acción, las cuales pueden ser: reenviar, desechar, consumir o replicar.
En una regla se puede buscar por IP, MAC, puerto UDP (user datagram protocol)/TCP
(transmission control protocol) y está permitido el uso de comodines
Una Flow Table está compuesta de regla o condición, una acción y todo esto asociado a
un número de prioridad. La regla con un número mayor de prioridad es consultada primero
[1].
4
2.2.3. Separación de planos
Una de las principales características de SDN es la separación de sus planos. El plano de

datos tiene como principal función el de reenviar, desechar, consumir o replicar los paquetes
que ingresan, basado en características como: dirección MAC (medium access control), direc-
ción IP (Internet protocol), e identificador VLAN (virtual local area network). En un proceso
simple en el plano de datos, un paquete será enviado por el puerto correspondiente luego de
una revisión en la tabla ASIC (application-specific integrated circuit) o podría ser desechado
por cumplir un parámetro de QoS (quality of service) previamente configurado [3].
Los protocolos, lógica y algoritmos utilizados para programar el plano de datos y su función
de tratamiento de paquetes residen en el plano de control. Con el networking tradicional, cada
dispositivo tiene su propio plano de control lo que deriva en la ejecución de varios algoritmos
de sincronización con el fin de que todos los dispositivos estén sincronizados y de esta manera
evitar loops [1].
2.2.4. Dispositivo simple y control descentralizado
Al separar el plano de datos del plano de control se obtienen dispositivos simples y un

plano de control centralizado. Con las siguientes ventajas directas:
1) Dispositivos económicos.
2) Una visión general del elemento que controla los dispositivos.
La principal función del controlador es la de mantener una visión global de la red, im-
plementar políticas y tomar decisiones al controlar todos los dispositivos SDN mediante
instrucciones sencillas obteniendo una respuesta rápida por parte del dispositivo SDN, adi-
cionalmente provee una interfaz northbound para aplicaciones.
En la actualidad existen varios controladores en el mercado, como por ejemplo: OpenDay-

Light, HPE VAN Controller, RYU Controller, ONOS Controller, etc [1].
2.2.5. Controlador SDN
El controlador SDN, tiene una visión general de toda la red, controla todos los dispositivos
SDN lo que le permite implementar distintas políticas para la red y proporciona una interfaz
northbound la cual es la vía de comunicación de las aplicaciones. Normalmente los controla-
dores vienen con un conjunto de aplicaciones por defecto como, por ejemplo: un switch para
el aprendizaje y descubrimiento de la red, un router, un firewall, o un balanceador de carga,
etc [3].
Existe una serie de controladores SDN en el mercado basados en C como NOX ó basados en
5
Java como Beacon o Floodlight. Existen controladores de código abierto como OpenDaylight,
el cual tiene el apoyo de varias compañías del sector de telecomunicaciones, en contraparte
existen controladores propietarios como puede ser el HPE SDN VAN Controller.
2.2.6. Aplicaciones SDN
Funcionan sobre el controlador, comunicándose con la red mediante la interfaz northbound.

Son responsables de controlar las entradas que se escriben en las Flow Tables. Son capaces
de: 1) configurar los flujos de tal manera que se obtenga el mejor camino entre dos “end
point”; 2) balancear tráfico por distintas rutas; 3) reaccionar a cambios en la red como fallas,
desconexiones o incorporación de nuevos dispositivos y; 4) redireccionar tráfico por propósitos
de inspección de paquetes. Una de las ventajas que tiene SDN es que, hasta la función
más sencilla de un switch, puede ser comandada por aplicaciones de alto nivel, esto le da
un potencian muy amplio a SDN .La principal responsabilidad de una aplicación es la de
desempeñar la función para la que fue diseñada [3].
2.2.7. Dispositivos SDN
Un dispositivo SDN está compuesto por: 1) una interfaz para la comunicación con el
controlador; 2) una capa de abstracción y; 3) una función de procesado de paquetes.
La interfaz de comunicación con el controlador es la ya mencionada northbound mientras

que la capa de abstracción la realiza el controlador SDN al abstraer la red del dispositivo
SDN. En el caso de un dispositivo SDN basado en hardware la función del procesado de
paquetes está embebido en el hardware y en el caso de virtual switch, esta función se realiza
por software [1].
2.2.8. Dispositivo basado en Software
Un dispositivo SDN basado en software es la forma más sencilla de producir un dispositivo

SDN, debido a que las Flow Tables, Flow Entries y los casos de matching son fácilmente
resueltos por software, con estructuras de datos, arreglos y “hash tables”.
Es más probable que dos dispositivos SDN basados en software, logrados por distintos
fabricantes, trabajen conjuntamente en comparación con dos dispositivos SDN basados en
hardware. Es posible utilizar lógicas más avanzadas para buscar reglas que coincidan en
una Flow Tables. Normalmente son implementados sobre un hypervisor o un sistema de
virtualización.
Una desventaja de estos dispositivos es que no cuentan con aceleración basada en hardware,
lo que los hace lentos en comparación con los dispositivos SDN basados en hardware y no
son usados en ambientes donde se necesiten muy altas velocidades de transmisión. [1].
6
2.2.9. Dispositivo basado en hardware
La principal ventaja de un dispositivo SDN basado en hardware es que trabaja a una

mayor velocidad comparado con su par basado en software y esto los hace adecuados para ser
implementados en data centers o network cores. La forma en que estos dispositivos analizan
el paquete y toman una decisión es mediante la incorporación de tablas basadas en hardware
de capa 2 y capa 3, utilizando CAMs (content-addressable memories) y TCAMs (ternary
content-addressable memories) respectivamente. Las decisiones se toman mediante hashing
basado en hardware. Los dispositivos SDN basados en hardware tienen limitaciones con
respecto al número de entradas en la Flow Tables [1].
2.2.10. Operación de SDN
Los dispositivos SDN con capaces de realizar varias funciones con los paquetes que ingre-
san, como por ejemplo: el reenvío por un puerto específico. El dispositivo SDN cuenta con
información que le permite tomar una decisión (Flow Tables). Los datos pueden ser descritos
como “Flujos” y viajan hacia distintos “end points”. Un “end point” puede ser una dirección
IP, puerto TCP/UDP, una VLAN, etc. Un “flujo” es unidirecciónal, representando un sentido
de la transmisión hacia el “end point”.
Las Flow Tables, se encuentran en los dispositivos. Cuando se recibe un paquete, se la

consulta en busca de una regla que calce para poder tomar una decisión.
El controlador es el encargado de abstraer la red de los dispositivos SDN, proveer a las

aplicaciones de una interfaz para poder informarse de eventos que suceden en la red. Al tener
una visión global de la red se toman decisiones óptimas.
Como el controlador tiene a su cargo varios dispositivos y controla la red de forma glo-
bal, comúnmente funciona sobre hardware con mejores prestaciones en comparación con el
hardware que podría tener un dispositivo SDN. Por ejemplo, un controlador podría funcio-
nar sobre un procesador de 8 núcleos a 2GHz cuando un switch suele funcionar sobre un
procesador de un núcleo a 1GHz.
Las aplicaciones SDN, configuran los dispositivos de forma proactiva y reactiva. Realizan
una configuración reactiva al iniciar las aplicaciones. Realizan una configuración reactiva en
respuesta a un evento informado por el controlador, una aplicación le indicará al controlador
como responder la próxima vez e incluso modificará la Flow Table. También se configura de
forma reactiva en respuesta a datos externos, un ejemplo de estos casos es cuando se modifica
la Flow Table por aplicaciones como IDS (Intrusion Detection Systems) [1].
7
2.3. Servidor Web
Un servidor web, es un programa que está a la escucha de un determinado puerto a la

espera de una conexión, al realizarse la conexión, el servidor web espera por una solicitud,
la cual obedece el protocolo HTTP (hypertext transfer protocol) y es generada normalmente
por un navegador web como cliente. Actualmente los servidores web, proveen autenticación
y cifrado de datos, permitiendo realizar compras o tener comunicaciones seguras [4].
2.3.1. Desempeño de un servidor Web
Es importante definir los parámetros utilizados para determinar el desempeño de un ser-

vidor web. Varias herramientas son utilizadas para este fin como Funkload, Httperf, Apache-
benchmak, Locust dando como resultados de sus pruebas el número de conexiones exitosas
entre el varios clientes simulados y un servidor web dentro de un intervalo de tiempo. An-
te esto, se puede concluir que el número de conexiones exitosas es parámetro clave para
determinar el desempeño de un servidor web.
En el presente trabajo, se medirá el número de conexiones exitosas que detecta la herra-

mienta Funkload [5] y el throughput medio (kb/s) en el punto de acceso. El throughput es
utilizado como parámetro complementario en este trabajo aunque como se evidencia en el
capítulo 2.6, un throughput grande no necesariamente significa un mejor desempeño.
Una conexión exitosa es detectada cuando dentro de la cabecera HTTP, se encuentra el

código de estado “200”, el cual indica que la solicitud ha sido atendida [6].
2.4. Balanceo de Carga
Cuando se instala un servidor web con una implementación básica, se puede manejar cierto
nivel de tráfico y solicitudes sin concurrir en una disminución de la calidad del servicio y sin
la existencia notable de errores. Cuando el número de clientes, tráfico y solicitudes aumentan,
es necesario realizar ajustes. Se puede implementar dos soluciones: a) Crecimiento vertical;
b) crecimiento horizontal [7].
El crecimiento vertical, se refiere a la adquisición de nuevo hardware, con mejores presta-

ciones. El crecimiento horizontal, se refiere al uso de equipos activos para distribuir la carga
de trabajo a más de un servidor, lo que se denomina “balanceo de carga”.
Al dividir el trabajo de un computador entre varios, se obtiene un mayor rendimiento ya

que se puede realizar el trabajo en un menor tiempo o realizar más trabajo en el mismo
tiempo.
1. Balanceo de Carga por Hardware: se realiza mediante un dispositivo como, por ejemplo,
un router balanceador. Se configuran varias rutas.
8
2. Balanceo de Carga por Software: se realiza mediante un sistema operativo o aplicación,
tiene resultados muy similares a su par basado en hardware.
Existen diferentes algoritmos de balanceo, por ejemplo, el servidor Web Apache soporta
las siguientes configuraciones:
1. Weighted Balance: se asigna más tráfico al servidor con la mejor conexión y menos al
servidor con peores capacidades.
2. Priority: se asigna tráfico al servidor por defecto mientras esté disponible.
3. Overflow: evita que el tráfico pierda velocidad, si se detecta una disminución de veloci-
dad, se deriva el tráfico hacia otro servidor.
4. Persistence: se mantiene la conexión con un servidor hasta que se finalice la sesión.
5. Least Used: se dirige el tráfico hacia el servidor más libre o con menos trabajo.
6. Roud robbin capa 4: en un conjunto de web servers, se redirige la primera conexión al

primer Web server, del conjunto, la segunda conexión al segundo web server y así suce-
sivamente hasta que se llega al último Web server; la siguiente conexión es nuevamente
dirigida al primer Web server.
7. Lowest latency: se establece conexión con el web server con menor latencia.
8. HTTP Capa 7: los balanceadores de carga de capa 7 inspección el contenido hasta capa
7, se lee la petición HTTP y analiza el URL, de esta manera se puede redirigir las
peticiones por un mismo recurso a un solo servidor.
9. SDN Adaptativo: normalmente el balanceo de carga trabaja analizando la capa 4 o capa

7 del Modelo OSI (open system interconnection). El balanceador de carga KEMP SDN
Adaptativo [8], es una aplicación SDN que se comunica con el controlador por medio de
la interfaz northbound recibiendo el estado de cada switch en relación a la congestión y
funcionamiento por puertos. Usualmente solo se tomaba en cuenta el tráfico Norte-Sur
correspondiente al de cada usuario con el servidor, pero es importante tomar en cuenta
el tráfico Este - Oeste el cual contiene la comunicación entre servidores y equipos ya
que este tráfico ha ido creciendo [8].
2.5. Tecnologías de Acceso
2.5.1. IEEE 802.11n
El estándar 802.11n, está enfocado en redes inalámbricas de área local, es sucesor de otros
estándares como 802.11b o 802.11g, fue publicado en el año 2009. Es protocolo IEEE 802.11n
tiene las siguientes características básicas [9]:
9
1. Se tiene un throughput de hasta 300 Mbps con mimo 2x2 y 600Mbps con mimo 4x4.
2. Utiliza modulación OFDMA (orthogonal frequency-fivision multiple access) con hasta

52 señales portadora y 64QAM (quadrature amplitude modulation)
3. Puede operar con una relación de carga útil de: 1/2, 3/4, 5/6.
4. Implementa tecnología MIMO (multiple-input multiple-output) de hasta 4x4
5. Maneja un intervalo de guarda de 0.4 µ sec.
En el ambiente de simulación se utiliza un access point TP-Link TL-WR841N que utiliza el

protocolo 802.11n en la banda de 2.4 Ghz [10].
2.5.2. 3GPP long term evolution (LTE)
LTE es un estándar para redes móviles sucesor del estándar HSPA+. Tiene su inicio a
partir del Realese 8 en diciembre de 2008 lanzado por la 3GPP.
El estándar LTE tiene las siguientes características básicas:
1. Se logra un throughput de hasta 100Mpbs para el downlink y 50 Mbps para el uplink

sin MIMO y con 20Mhz de espectro y modulación 64QAM.[11]
2. Utiliza OFDM con una modulación de hasta 64QAM en el downlink y SC-FDMA (single
carrier frequency divison multiple access) para el uplink.
3. Utiliza MIMO de hasta 4x4.
En el ambiente de simulación se utiliza un dongle LTE Huawei que utiliza el protocolo LTE,
en la banda 4 FDD AWS a 1700 Mhz para uplink y 2100 Mhz para downlink.
2.6. Métricas de Desempeño de Red
Cuando se desea brindar QoS en cumplimiento de un SLA (service level agreement), es

necesario conocer las métricas que definirán dichos acuerdos, en networking se utiliza las
métricas planteadas en la Figura 2.2.
10
Conectividad
Disponibilidad
Funcionalidad
En una dirección
Pérdidas
Ida y vuelta
Métricas de
Parámetros
de Red En una dirección
Retrasos Ida y vuelta (RTT)
Jitter
Capacidad
Utilización Ancho de Banda
Desempeño
Figura 2.2: Métricas de Desempeño de Red citenano9
1. Disponibilidad: se refiere puramente a la funcionalidad de la red, quiere decir si los

dispositivos de red funcionan o no.
2. Pérdida: son los paquetes que no llegan a su destino dentro de un intervalo de tiempo,
se expresa en porcentaje y puede ser de dos tipos: pérdidas de paquetes en una dirección
o perdida de paquetes en ida y vuelta.
3. Retraso: es el tiempo necesario para que un paquete viaje en una dirección o ida y
vuelta. La variación del retraso se conoce como jitter.
4. Utilización: es el rendimiento del enlace, expresado como un porcentaje de su capacidad

[12].
2.7. Test de Normalidad
Como parte de los objetivos de este trabajo, se busca realizar modelos que describan el
comportamiento de los datos, para esto debemos primero determinar si los datos siguen una
distribución normal, esto se puede lograr utilizando la prueba Shapiro-Wilk de normalidad.
La prueba Shapiro-Wilk de normalidad calcula el valor W como:
( ni=1 ai yi )2
P
W = Pn , (2.1)
( i=1 yi − ȳ)2
donde n es el tamaño de la muestra a analizar, yi es el dato de la muestra ordenada en la
posición i, ai es una constante generada en base a la media, varianza y covarianza de una
11
muestra con distribución normal del mismo tamaño de la muestra, ȳ es la media muestral.
El valor de W, varía entre 0 y 1, se plantea una hipótesis alternativa que indica que los datos
no siguen una distribución normal; si W es pequeño se rechaza la hipótesis nula.
Esta prueba tiene como lógica medir las desviaciones estadísticas de la muestra, en relación
a una muestra con distribución normal [13].
2.8. Series de Tiempo
Una serie de tiempo, es un conjunto de datos cuantificables ordenados cronológicamente

y normalmente dentro de un intervalo de tiempo discreto. Son ampliamente utilizadas en
varias ramas como economía, finanzas, medio-ambiente y medicina [14] [15].
Una serie de tiempo puede ser descompuesta en 4 componentes:
1. Tendencia: movimientos a largo plazo
2. Efecto estacional: fluctuaciones cíclicas, relacionadas al calendario.
3. Cíclico: otras fluctuaciones cíclicas.
4. Residual: fluctuaciones aleatorias.
2.8.1. Modelos Lineales
2.8.2. Modelo AR (autoregressive)
Un modelo es AR, cuando la variable dependiente con un tiempo discreto t, es explicada

por un número de observaciones de periodos pasados de ella mismo más un término de error.
Su notación es con la abreviatura AR combinado con el número de observaciones pasadas
que son utilizadas en el modelo [16] [15].
Un modelo AR(p) tiene la siguiente expresión:
z̃t = φ1 z̃t−1 + φ2 z̃t−2 + · · · + φp z̃t− + at ,

p
X (2.2)
z̃t = φk zt−k + at ,
k=1
donde z̃t , es el valor de la variable dependiente en el tiempo discreto t, φk corresponde a un

factor escalar y at es ruido de media cero y varianza σa2 AWGN (additive white Gaussian
noise) y p el número de observaciones pasadas.
12
2.8.3. Modelo MA (moving-average)
Un modelo de media móvil explica la variable dependiente de tiempo discreto t como la

sumatoria de valores pasados de ruido blanco. Un modelo de media móvil tiene de anotación la
palabra MA. [16]. En el caso de MA(q), la variable dependiente se encuentra con la siguiente
ecuación:
z̃t = at − θ1 at−1 − θ2 at−2 − · · · − θq at−q .
q
X (2.3)
z̃t = θk at−k + at ,
k=1
donde z̃t , es el valor de la variable dependiente en el tiempo discreto t, θk corresponde a

un factor escalar y at es ruido de media cero y varianza σa2 (AWGN) y q el número de
observaciones pasadas.
2.8.4. Modelo ARMA (autoregressive–moving-average)
Los modelos ARMA combinan los conceptos de los modelos AR y MA. Por ejemplo, un
modelo ARMA(p, q), está definido por la siguiente ecuación [17] [16] [14]:
p q
X X
z̃t = φk zt−k + θk at−k + at , (2.4)
k=1 k=1
donde la parte de la izquierda corresponde a AR y la de la derecha a MA, z̃t es el valor de la

variable dependiente en el tiempo discreto t, φk corresponde a un factor escalar de la parte
AR, θk corresponde a un factor escalar de la parte MA, p es el número de observaciones
pasadas de la parte AR, q es el número de observaciones pasadas de la parte MA y at es
ruido de media cero y varianza σa2 (AWGN).
2.8.5. Modelo ARIMA (autoregressive integrated moving average)
En la mayoría de los casos, los datos presentan homogeneidad más no estacionalidad [18].
La estacionalidad es un requisito para los modelos vistos anteriormente. Para poder generar
estacionalidad, realizamos un proceso de diferenciación [14] [15]. Por lo que la nueva variable
a modelar es:
Con d = 0 : zt = zt,
Con d = 1 : zt = zt − zt−1 , (2.5)
Con d = 2 : zt = (zt − zt−1 ) − (zt−1 − zt−2 ) = zt − 2zt−1 + zt−2,
donde d, es el número de veces que se diferencia cada dato y z̃t , es el valor de la variable
dependiente en el tiempo discreto t.
Un operador Lag, expresa los siguiente
B z̃t = z̃t−1 ; B d z̃t = z̃t−d (2.6)
13
La expresión base de un modelo ARIMA(p, d, q) es:
φ(B)(1 − B)d z̃t = θ(B)at , (2.7)
donde
φ(B) = 1 − φ1 B − · · · − φp B p ,
(2.8)
θ(B) = 1 + θ1 B + · · · + θq B q ,
z̃t , es el valor de la variable dependiente en el tiempo discreto t, p es el número de observa-
ciones pasadas de la parte AR, q es el número de observaciones pasadas de la parte MA, φp
corresponde a un factor escalar de la parte AR, θq corresponde a un factor escalar de la parte
MA y at es ruido de media cero y varianza σa2 (AWGN).
2.8.6. Modelo SARIMA (seasonal autoregressive integrated moving

average)
Cuando los datos tienen variaciones estacionales, es decir son afectados por el calendario,
se puede incluir un componente de estacionalidad a la serie [14]. La formulación de un modelo
SARIMA(p, d, q)(P, D, Q), en donde los parámetros P,D y Q definen la parte estacional está
dada por:
φ(B)Φ(B s )(1 − B)d (1 − B s )D z̃t = θ(B)Θ(B s )at , (2.9)
donde
φ(B) = 1 − φ(1)B − · · · − φ1 B p ,
θ(B) = 1 + θ(1)B + · · · + θ1 B q ,
(2.10)
Φ(B s ) = 1 − Φ(1)B − · · · − Φ1 B P ,
Θ(B s ) = 1 + Θ(1)B + · · · + Θ1 B Q ,
z̃t , es el valor de la variable dependiente en el tiempo discreto t, p es el número de observaciones
pasadas de la parte AR, q es el número de observaciones pasadas de la parte MA, P es el
número de observaciones pasadas de la parte AR estacional, Q es el número de observaciones
pasadas de la parte MA estacional, φp corresponde a un factor escalar de la parte AR, θq
corresponde a un factor escalar de la parte MA, Φp corresponde a un factor escalar de la
parte AR estacional, Θq corresponde a un factor escalar de la parte MA estacional y at es
ruido de media cero y varianza σa2 (AWGN).
14
Capítulo 3
Metodología
En el presente capítulo se describen las condiciones sobre las cuales se ejecutan los ex-
perimentos, las topologías utilizadas, se describen las herramientas de hardware y software
usadas, los límites relacionados con las condiciones de red aplicadas y los tamaños de la
muestras o número de repeticiones realizadas.
3.1. Implementación
En esta sección, se indica las herramientas de software y hardware seleccionadas para el

presente trabajo. Para la selección de estas herramientas se consideró varias alternativas, el
detalle de las alternativas consideradas, y su apreciación se encuentra en el Anexo A.
3.1.1. Selección de Herramientas para la implementación
Para el desarrollo del presente trabajo, es necesario emular, simular o implementar: 1) un

acceso LTE, acceso Wireless LAN 802.11n; 2) dispositivos de SDN (Switch); 3) un controlador
SDN; 4) manipular las condiciones de red (delay, packet loss, throughput); 5) una aplicación
SDN que realice balanceo de carga de servidores web; 6) servidores web; 7) generador de
tráfico web. Al tener todo lo antes mencionado, es necesario realizar distintas pruebas y
capturar datos.
Si consideramos como opción a NS3 [19], se puede cumplir todos los requisitos en un único
ambiente o en conjunto con GNS3 [20], pero presenta complejidad en su implementación,
debiendo desarrollar código para cumplir con cada requisito.
Para cumplir con el punto 1 de los requisitos, al no utilizar NS3 la alternativa adoptada
es implementar un acceso LTE y Wireless LAN Real, utilizando un dongle LTE conectado a
la red móvil de la compañía WOM y la tarjeta Wireless LAN de una computadora conectada
a un access point 802.11n.
15
Para suplir el punto 2, se utiliza el software Mininet [21] el cual es el emulador de dispo-
sitivos SDN, ampliamente utilizado en experimentos y desarrollo de proyectos relacionados
con SDN.
El controlador que se ha elegido para completar el punto 3, es HPE VAN SDN Con-
troller [22] debido a que maneja una interfaz más completa en comparación con las demás
alternativas y tiene instalado varias aplicaciones por defecto permitiendo un uso sencillo.
Para satisfacer el punto 4, se utiliza Netem [23] como complemento en GNS3, permitiendo
modificar delay y packet loss de cualquier enlace.
La única aplicación encontrada que realiza balanceo de carga de servidores web y compa-
tible con el controlador HPE SDN VAN CONTROLLER es Kemp Load Balancer, al utilizar
la versión gratuita, posee ciertas limitantes las cuales son: 5000 Mbps and 10,000 SSL TPS,
pero estas no han influido en el desarrollo del experimento al no acercarnos a esos límites.[8]
Para el punto 6, se utiliza el servidor web Nginx [24], se pudo utilizar un servidor web
Apache u otro de similares características [4].
Para el punto 7, se utiliza Funkload [5], cuya función es generar tráfico web simulando
varios usuarios y peticiones de tipo HTTP registrando el número de conexiones exitosas y
fallidas.
Si consideramos para la captura de datos el protocolo Netflow, obtendremos información

del tamaño de paquetes enviado, dirección IP de origen y destino de los flujos; sin embargo
hace falta un número de secuencia para poder calcular correctamente delay e información
adicional que permita un mejor análisis, por lo que para la medición y captura de datos, se
usará Wireshark ya que esta herramienta al ser un sniffers, puede capturar paquetes brin-
dándonos información de las cabeceras, la cual nos permite analizar secuencias de paquetes
y de esta manera calcular el delay. El resumen de la selección de herramientas se encuentra
en la siguiente tabla:
Tabla 3.1: Herramientas Seleccionadas
Requisito Herramienta
Acceso Dongle LTE / Access Point 802.11n
Condiciones Adversas de Red Netem
Dispositivos SDN Mininet
Controlador SDN HP SDN VAN Controller
Balanceador de Carga Kemp Load Balancer
Servidor Web Nginx
Recolección de Datos Wireshark
Análisis Estadístico Lenguaje R
16
3.2. Configuración de Herramientas
3.2.1. Configuración de GNS3
GNS3, funciona como herramienta en donde se consolidan las distintas partes del proyecto,
proveyendo de funciones de networking a las máquinas virtuales que se ha utilizado. Como
se ve en la Figura 3.1, se incorpora las siguientes máquinas virtuales sobre GNS3:
1. Servidor Web 1: Lubuntu 14.10 virtualizado con VirtualBox, donde se ejecuta el servidor
web Nginx, con el número [1] en la Figura 3.1.
2. Servidor Web 2: Lubuntu 14.10 virtualizado con VirtualBox, donde se ejecuta el servidor
web Nginx [2].
3. Balanceador de Carga: máquina virtualizada con el software VirtualBox, donde se eje-

cuta el Balanceador de Carga KEMP LOAD BALANCER [3].
4. Mininet: máquina virtualizada con VirtualBox donde se ejecuta Mininet [4].
5. Netem: máquina virtualizada con VirtualBox donde se ejecuta Netem [5].
Figura 3.1: GNS3 con arquitectura de red basada en SDN
Es necesario proveer funciones de red a las máquinas virtuales implementadas, para lo que
se añade a GNS3 elementos de networking mostrados en la Figura 3.2. La Tabla 3.2, detalla
las direcciones IP configuradas.
1. Router Cisco C7200: realiza Nateo y enrutamiento, con el número [6] en la Figura 3.2.
2. Switch legacy: utilizados cuando en el escenario con una arquitectura de Red legacy [7].
3. Salida a Internet: conectada directamente con la interfaz loopback de la máquina Host

[8].
17
Figura 3.2: GNS3 con arquitectura de red Legacy
Tabla 3.2: Direcciones IP
Dispositivo Interfaz Dirección IP

Router 1 FastEthernet 0/0 192.168.137.10
PC Loopback 192.168.137.1
Mininet eth0 192.168.50.10
Kemp Load Balancer eth0 10.0.0.20
Servidor Web 1 eth0 10.0.0.10
Servidor Web 2 eth0 10.0.0.60
Kemp Load Balancer Web Server 10.0.0.40
3.2.2. Configuración de Mininet
Mininet se encuentra instalado sobre una máquina virtual en VirtualBox. Es necesario

indicar, la dirección IP del controlador, tipo de topología, número de dispositivos SDN, tipo
de switch y protocolo a ser utilizados. Para la investigación se ha utilizado una topología
lineal con dos switch SDN del tipo Open vSwitch [25] y con el protocolo Openflow [26] para
la interfaz southbound. Esto se ha realizado con el siguiente comando de configuración en el
terminal de Linux:
"sudo mn –controller=remote,ip=45.79.10.37 –topo=linear,2 –switch=ovsk,

protocols=OpenFlow13 –mac"
La topología resultante, vista desde el controlador SDN, es la siguiente:
18
Figura 3.3: Topología creada en mininet, observada desde controlador HPE VAN SDN
1. Switch SDN
2. Servidor Web 1
3. Servidor Web 2
4. Balanceador de Carga
5. Router Cisco C7200
Adicionalmente, es necesario vincular las interfaces de los switches SDN emulados con las
interfaces de la máquina virtual en donde se ejecuta Mininet. Para lograr esto, se ha utilizado
el siguiente comando: "sudo ovs-vsctl add-port s1 eth1 && sudo ovs-vsctl add-port s1 eth2
&& sudo ovs-vsctl add-port s2 eth3 && sudo ovs-vsctl add-port s12 eth4"
3.2.3. Configuración de HPE VAN SDN Controller
El controlador funciona sobre un VPS (virtual private server) contratado por el autor.
No se realiza una configuración adicional dado que por defecto en el controlador se incluyen
aplicaciones que nos permiten descubrir los dispositivos conectados.
3.2.4. Configuración de Netem
Netem es una herramienta diseñada para trabajar sobre GNS3 una vez cargada como
máquina virtual, se configura añadiendo delay, jitter, packet loss y limitaciones de throughput.
Todas estas limitaciones pueden configurarse con distintos valores para cada sentido de la
comunicación o configurarse de manera simétrica. En la siguiente figura se observa la interfaz
de configuración:
19
Figura 3.4: Opciones de configuración de Netem
3.2.5. Configuración de Wireshark
Se realiza mediciones en el punto “A” de la Figura 3.1, se utiliza la integración de GNS3

con Wireshark a través de un punto de captura.
Se realiza capturas durante 10 minutos que es el tiempo que dura la simulación de usuarios
concurrentes al servidor web. Una vez obtenido los datos, se utiliza los siguientes filtros con el
fin de obtener la información referente a throughput, delay, packet loss y conexiones exitosas.
1. Delay:
tcp.port == 80 and tcp.time_delta > 0 and tcp.flags.fin == 0 and tcp.flags.reset == 0
and !http and !tcp.analysis.keep_alive and !tcp.analysis.retransmission and (tcp.flags.syn
== 1 and tcp.flags.ack == 1) and !tcp.analysis.out_of_order
Como se observa en la Figura 3.6, dentro de I/O Graph, en intervalos de 1 segundo
se visualiza el promedio del dato tcp.time_delta, y se exporta a un archivo de datos
separados por comas.
2. Throughput: para el throughput, se analizan los paquetes TCP con número de puerto
80, esto se ha conseguido con el siguiente filtro:
((ip.src==192.168.137.10 and ip.dst==192.168.137.1) or (ip.src==192.168.137.1 and
ip.dst==192.168.137.10)) and tcp.port==80
Dentro de I/O Graph, se exporta a un archivo de datos separados por comas.
20
Figura 3.5: Configuración del tipo de scheduler utilizado para el balanceo de carga
Figura 3.6: Imagen de IO Graph de Wireshark
3.2.6. Configuración Funkload
Dado que la página web alojada en los servidores Web, es de contenido simple, lo único
que se necesita simular, son solicitudes de tipo GET de usuarios concurrentes. El número
de usuarios concurrentes que se simula es de 300, basados en pruebas de estrés de usuarios
bajo una topología SDN, con condiciones adversas de red y acceso LTE. Para lo cual se ha
utilizado, el demo de un test simple incluido en Funkload. Donde se configura, dirección a
donde se apunta, número de usuarios, tiempo máximo de espera, duración del test, códigos
HTTP aceptados como solicitudes exitosamente atendidas. El código utilizado es el siguiente:
1 # ------------------------------------------------------------
2 # Configuration for bench mode fl - run - bench
3 #
21
4 [ bench ]
5
6 # cycles = Numero de Usuarios Concurrentes .

7 cycles = 350
8
9 # duration = Duracion de la prueba

10 duration = 615
11
12 # startup _ delay = Tiempo de espera entre la inicializacion de cada

usuario
13 startup _ delay = 0.05
14
15 # sleep _ time = Tiempo entre cada solicitud

16 sleep _ time = 0.01
17
18 # cycle _ time = Tiempo de espera entre cada ciclo

19 cycle _ time = 10
20
21 # same keys as in [ ftest ] section - see descriptions above

22 log _ to =
23 log _ path = simple - bench . log
24 result _ path = simple - bench . xml
25 # Codigos HTTP STATUS aceptados como conexiones exitosas
26 ok _ codes = 200:301:302
27 # Tiempo minimo y maximo de espera por usuario
28 sleep _ time _ min = 0
29 sleep _ time _ max = 30
3.2.7. Configuración Kemp Load Balancer
La configuración del Balanceador de Carga, depende del tipo de infraestructura de red que
se esté utilizando, en el caso de utilizar una red legacy, se configura en modo “Round Robin”,
y en el caso de ser una infraestructura del tipo SDN, se configura en modo “SDN Adaptative”
tal como se puede observar en la Figura 3.7. Adicionalmente, es necesario configurar la
conexión con la interfaz northbound del controlador, esto se realiza ingresando la dirección
IP y credenciales del controlador, esto se observa en la Figura 3.8.
22
Figura 3.7: Configuración del tipo de scheduler utilizado para el balanceo de carga
Figura 3.8: Configuración de la conexión del balanceador de carga con el controlador SDN
3.2.8. Configuraciones Adicionales
Para lograr acceder a los servidores web alojados dentro de GNS3, dentro de la compu-
tadora host y a su vez, dentro de la red de la Universidad de Chile, es necesario realizar
varios procesos de port fowarding, tanto internamente en la máquina host Windows, como
en el router Cisco C7200 en GNS3; adicionalmente para acceder desde cualquier lugar a tra-
vés de Internet y dado la imposibilidad por permisos administrativos de poder realizar port
fowarding sobre los equipos de la Universidad de Chile, fue necesario realizar port fowarding
invertido vía ssh teniendo como servidor un VPS [27].
23
Al realizar port fowarding vía ssh, se crea una conexión entre dos equipos, uno local y
otro remoto, entre los cuales se puede enlazar cualquier servicio manteniendo una conexión
y transmisión de datos cifrada. Código ssh port fowarding a través de VPS:
ssh -p 22 -R 45.79.10.37:8000:192.168.137.10:80 [email protected]
El comando anterior, se ingresa en la ventana de comandos de Windows, es necesario tener
instalado Openssh. El comando indica que toda comunicación con el destino 45.79.10.34:8000,
será reenviada a través de la conexión ssh, hacia la dirección 192.168.137.10:80. Se puede
verificar las direcciones IP en la Tabla 3.2.
Código port fowarding en router Cisco:
ip nat inside source static tcp 10.0.0.40 80 192.168.137.10 80 extendable
En el comando anterior, se indica que toda comunicación con destino 192.168.137.10:80, sea
reenviada hacia la dirección 10.0.0.40:80.
En la siguiente Figura 3.9 se puede observar el esquema completo del port fowarding realizado:
GNS3
VPS IP: 45.79.10.37 Router Interfaz de entrada Balanceador de Carga

Cliente Internet IP: 10.0.0.40
IP:192.168.137.10
Port fowarding hacia:

10.0.0.40:80
Solicitud hacia: Ssh invertido port fowarding
45.79.10.37:8000 hacia 192.168.137.10:80
Figura 3.9: Esquema de Port fowarding
3.3. Cálculo del tamaño de la muestra
Para definir el tamaño de la muestra en un diseño experimental es necesario tomar en

consideración los siguientes factores:
1. Nivel de confianza: sirve para minimizar el error de Tipo I, que es rechazar la hipótesis
nula, siendo está verdadera. Normalmente se adopta un valor de 0.05 indicando que
aceptamos un 5 % de probabilidad de cometer el error de Tipo I.
2. Potencia de la prueba: sirve para minimizar el error de Tipo II, que es no rechazar la
hipótesis nula, cuando debimos rechazarla, esta probabilidad se simboliza como β y la
potencia 1 − β normalmente la potencia adopta un valor de 0.80.
3. Magnitud de la diferencia: es una medida a dimensional que indica la efectividad de

una acción sobre un grupo de control en una comparación [28].
|M edia del Grupo Experimental| − |M edia del Grupo de Control|

ME = . (3.1)
Desviación Estándar
24
4. La varianza de la población: si dos sujetos son muy iguales en un grupo, necesitamos
un tamaño de muestra mayor para identificar las diferencias. Si sucede lo contrario y
los sujetos son muy distintos, es posible contar con un tamaño de muestra pequeño.
Es importante mencionar que normalmente se busca trabajar con errores pequeños del
tipo I, por ese motivo se suele adoptar valores de 0.10, 0.05 ó 0.01 y para errores del
Tipo II, se adopta un valor más amplio [29] [30].
Con la siguiente fórmula basada en la prueba t estadística, se calcula el tamaño de la

muestra [31].
1 1
A=( + ), (3.2)
q1 q0
B = (Zα + Zβ)2 , (3.3)
A∗B
N= ,
M E2 (3.4)
donde q0 = proporción sujetos grupo 1, q1 = 1 − q0 , M E = Magnitud de la diferencia

y N = Tamaño de la muestra.
Con el objetivo de demostrar las hipótesis planteadas, es necesario contrastar el grupo

de datos con tecnología legacy y SDN. En la Tabla 3.3, se indican los valores calculados
del tamaño de la muestra N tomando como valor comparado las conexiones exitosas
para cada tecnología de acceso en condiciones normales y adversas de red, para esto
se utiliza la Ecuación 3.4. Existen valores constantes para todos casos como q0 = 0,5,
q1 = 0,5, dado que la proporción del grupo de muestra es igual a la proporción del grupo
de control y Zα = 1,960, Zβ = 0,842 obtenidos de la tabla z de distribución normal
para un α = 0,05 y β = 0,2. Los datos fueron obtenidos utilizando las topologías de la
Figura 3.2 y Figura 3.1 y las herramientas descritas en el capítulo 3.1.1.
Tabla 3.3: Tamaño de la muestra para conexiones exitosas

Media Media Desviación
Hipótesis Diferencia ME N
Grupo (SSDN) Grupo (CSDN) Estándar
Tecnología de acceso WLAN,
13675.3 13631.16 106.45 120.26 0.38 117
sin condiciones adversas de red.
11989.95 11883.5 44.14 172.03 0.62 82
con condiciones adversas de red.
Tecnología de acceso LTE,
13451.2 13474 22.8 112 0.203 378
11883.85 11818.15 65.7 118 0.56 101
En la Tabla 3.4, se realiza un contraste similar al efectuado en la Tabla 3.3, con la única
diferencia que el valor comparado es el throughput. Los datos fueron obtenidos utilizando las
topologías de la Figura 3.2 y Figura 3.1 y las herramientas descritas en el capítulo 3.1.1.
25
Tabla 3.4: Tamaño de la muestra para el throughput
Media Media Desviación
Hipótesis Diferencia ME N
Grupo (SSDN) Grupo (CSDN) Estándar
266.68 267.73 1.05 3.71 0.28 393
268.33 268.46 0.13 1.79 0.07 6172
264.11 264.38 0.27 1.92 0.14 1584
263.57 264.02 0.45 2.08 0.22 667
Cómo podemos observar, en todos los casos para poder determinar las diferencias plantea-
das con un nivel de confianza de 0.5 y potencia de 0.8; es recomendable un número elevado
de muestras. Dado que en el proyecto se tiene tiempo y recursos limitados, el número de
muestras que se utiliza para cada contraste es de 40, variando el nivel de confianza y poten-
cia de la prueba de acuerdo a las tablas 3.5 y 3.6. Los valores son encontrados utilizando la
Ecuación 3.4 y las pruebas realizadas sobre las topologías de la Figura 3.2 y Figura 3.1.
Tabla 3.5: Nivel de confianza y potencia para las conexiones exitosas con 40 muestras
Media Media Nivel de
Hipótesis Potencia N
Grupo (SSDN) Grupo (CSDN) Confianza
11989.95 11883.5 0.09 0.72 40
13675.3 13631.1579 0.21 0.63 40
13451.2 13474 0.33 0.58 40
11883.85 11818.15 0.11 0.70 40
Tabla 3.6: Nivel de confianza y potencia para el throughput con 40 muestras

Media Media Nivel de
Hipótesis Potencia N
Grupo (SSDN) Grupo (CSDN) Confianza
Tecnología de acceso Wireless Lan,
266.68 267.73 0.27 0.60 40
Tecnología de acceso Wireless Lan,
268.33 268.46 0.44 0.52 40
264.11 264.38 0.38 0.55 40
263.57 264.02 0.32 0.58 40
3.4. Límites de los experimentos
Como parte del estudio es necesario incluir condiciones desfavorables de la red en la

infraestructura sobre la cual funcionará el servidor web. Por lo que se suman como factores
26
de degradación de la calidad de la red el delay y el packet loss, ya que como se mencionó en
el capítulo 2.6, estos forman parte de las principales métricas de la red.
Una vez seleccionado los factores a considerar, se realiza un análisis estadístico para de-
terminar su magnitud. El análisis estudia la respuesta en el punto de acceso punto “A” de
la Figura 3.1, la cuál representa una topología basada en SDN construida en GNS3. Para
generar solicitudes concurrentes se usa la herramienta Funkload; para la recolección de datos
se utiliza la herramienta de software Wireshark [32]. El software seleccionado, se discuten en
el capítulo 3.1.1. Es importante aclarar que los límites fueron encontrados en único escenario
(infraestructura SDN con tecnología de acceso LTE) debido a que las mismas condiciones de
red se aplican para el acceso WLAN.
3.4.1. Análisis de Packet Loss
Como parte del análisis se plantea conocer el comportamiento del servidor web ante un
incremento simétrico controlado de packet loss. Simétrico hace referencia a que existe el
mismo porcentaje de packet loss para los paquetes que viajan hacia el servidor web y desde
el servidor web. Esto se logra utilizando la herramienta Netem [23], sobre el escenario y demás
software mencionado en el capítulo 3.4. Lo resultados se encuentran en la siguiente tabla:
Tabla 3.7: Análisis de Packet Loss con infraestructura SDN y acceso WLAN
Packet Loss Retransmisiones throughput Conexiones Conexiones
delay (ms) Solicitudes
Añadido( %) ( %) (kbps) Exitosas Fallidas
0 0 24.62 266.71 13598 0 13598
6 3.2 98.50 270.48 13341 169 13510
12 6.50 176.15 279.08 12665 906 13571
18 10.50 252.47 301.01 12246 1899 14145
24 14.40 348.46 332.70 11433 3610 15043
30 19.00 557.08 303.62 5841 21564 27405
36 23.40 885.29 375.67 5006 29132 34138
42 27.40 1144.55 457.99 5524 35720 41244
48 30.90 1306.58 469.84 3979 48396 52375
54 35.00 2199.95 294.27 876 53374 54250
60 38.70 1535.38 287.92 104 58354 58458
66 41.60 3186.08 111.33 93 81323 81416
72 0 0 0 0 410929 410929
Basados en la Tabla 3.7 se obtienen las siguientes observaciones:
1. El throughput tiene una tendencia al alza conforme se incrementa el packet loss, hasta un
punto (aproximadamente 45 % de packet loss) en el que desciende rápidamente Figura
3.10 a).
2. El delay en el acceso aumenta conforme se incremente el packet loss Figura 3.10 c).
3. El número de conexiones exitosas disminuye conforme aumenta la perdida de paquetes

Figura 3.10 b).
27
4. El número de conexiones fallidas aumenta, conforme se incrementa el packet loss Figura
3.10 d).
5. El número de solicitudes aumenta conforme se incrementa el packet loss Figura 3.10 e).
Al llegar al 18 % de packet loss añadido, se presenta un comportamiento anómalo por parte

del simulador Funkload dado que el número de solicitudes supera el que se daría en una
situación sin condiciones adversas de red. El valor de solicitudes es aproximadamente de
13500.
En el presente experimento evitaremos llegar a esta zona de inestabilidad por lo que

debemos seleccionar un valor de packet loss por debajo del 18 %.
28
Throughput 13500 Conexiones Exitosas
450
12000
400
Conexiones Exitosas
Throughput [Kbps] 10500
350 9000
300 7500
6000
250
4500
200 3000
150 1500
SD = 93.87 SD = 5328.77
100 0
0 5 10 20 30 40 50 60 0 5 10 20 30 40 50 60
Packet Loss [%] Packet Loss [%]
(a) Throughput en Relación a Packet Loss (b) Conexiones Exitosas en Relación a Packet Loss
80000 SD = 27790.5
3000 SD = 965.26
70000
2500
Conexiones Fallidas
60000
2000
Delay [ms]
50000
1500 40000
30000
1000
20000
500 10000
0 Delay 0 Conexiones Fallidas
0 5 10 20 30 40 50 60 0 5 10 20 30 40 50 60
Packet Loss [%] Packet Loss [%]
(c) Delay en Relación a Packet Loss (d) Conexiones Fallidas en Relación a Packet Loss
83000
78000 SD = 22737.26
73000
68000
63000
58000
Solicitudes
53000
48000
43000
38000
33000
28000
23000
18000
13000 Solicitudes
0 5 10 20 30 40 50 60
Packet Loss [%]
(e) Solicitudes en Relación a Packet Loss
Figura 3.10: Gráficas de pruebas con SDN, con condiciones adversas de red y acceso LTE
3.4.2. Análisis de delay
Con un planteamiento similar en relación a escenario y herramientas utilizadas en el

análisis de packet loss del capítulo 3.4.1, se plantea conocer el comportamiento del servidor
web ante un incremento controlado de delay. Los resultados se encuentran en la Tabla 3.8.
29
Tabla 3.8: Análisis de delay con infraestructura SDN y acceso WLAN
delay delay throughput Conexiones Conexiones
Solicitudes
Añadido(ms) Medido (ms) (kbps) Exitosas Fallidas
0 24.62 266.71 13598 0 13598
150 179.09 262.08 13399 0 13399
300 329.21 257.88 13165 0 13165
450 475.22 254.11 12964 0 12964
600 622.51 247.48 12625 0 12625
750 773.96 243.83 12359 0 12359
900 929.27 240.63 12242 0 12242
1200 1231.19 239.80 11797 0 11797
1500 1535.12 240.15 11418 0 11418
1900 1938.75 241.24 10807 432 11239
2075 2111.39 234.05 10601 462 11063
2100 2128.72 239.43 10498 918 11416
2125 2159.94 242.58 10544 959 11503
2150 2178.05 237.09 10588 543 11131
2175 2234.12 643.36 2016 74545 76561
2250 2306.01 823.43 17 107904 107921
2300 2335.82 793.09 0 106771 106771
2500 2495.93 795.98 0 110410 110410
Basados en la Tabla 3.8 se desarrollan las siguientes observaciones:
1. El throughput tiene una tendencia a disminuir conforme se incrementa el delay, hasta

un punto (aproximadamente 2200 ms) en el throughput aumenta rápidamente, Figura
3.11 a).
2. Las conexiones exitosas tienen una tendencia a disminuir conforme se incrementa el

delay, hasta un punto (aproximadamente 2200 ms) en el que disminuyen notablemente,
Figura 3.11 b).
3. El número de conexiones fallidas se mantiene en cero y empieza a aumentar aproxima-

damente con un delay de 1900 ms hasta obtener únicamente conexiones fallidas cuando
se incrementa el delay, Figura 3.11 c).
4. El número de solicitudes empieza a disminuir conforme se incrementa el delay hasta un

punto (aproximadamente 2200 ms) en el número de solicitudes aumenta rápidamente,
Figura 3.11 d).
Por lo antes descrito, se ha evitado llegar a niveles de inestabilidad, en el que se pro-

duzcan altos incrementos de solicitudes o conexiones fallidas. Debemos aplicar un delay
inferior a 2200 ms dado que el número de solicitudes con un delay superior es muy dis-
tinto al número de solicitudes generados al que se daría en una situación sin condiciones
adversas de delay, indicando un comportamiento anómalo por parte del simulador.
30
800 Throughput 13090
750 12090
700 SD = 224.3 11090
Conexiones Exitosas
Throughput [kbps] 10090
650 9090
600 8090
550 7090
500 6090
450 5090
400 4090
350 3090
2090 SD = 4995.04
300 1090
250 90 Conexiones Exitosas
0 500 1000 1500 2000 2500 0 500 1000 1500 2000 2500
Delay [ms] Delay [ms]
(a) Throughput en Relación con delay (b) Conexiones Exitosas en Relación con delay
13090
12090
11090 114000
Conexiones Exitosas
10090 106000 Solicitudes

9090 98000 SD = 38364.52
8090 90000
Solicitudes
82000
7090 74000
6090 66000
5090 58000
50000
4090 42000
3090 34000
2090 SD = 4995.04 26000
1090 18000
Conexiones Exitosas 10000
90
0 500 1000 1500 2000 2500
0 500 1000 1500 2000 2500
Delay (ms)
Delay [ms]
(c) Conexiones Fallidas en Relación con delay (d) Solicitudes en Relación con delay
Figura 3.11: Gráfica de pruebas con SDN, con condiciones adversas de red y acceso LTE
3.4.3. Medición de Packet Loss
Una de las métricas de desempeño de red que se manipula en el presente trabajo, es

el packet loss. Esto se logra al utilizar la herramienta de software Netem sin embargo; en
el trabajo no se realizan mediciones de packet loss, debido a que para tener una medición
precisa de cuantos paquetes se han perdido, necesitamos realizar mediciones en dos puntos,
antes y después de la herramienta Netem (puntos “A” y “B” de la Figura 3.1), duplicando
el número de mediciones. La Figura 3.1 representa una topología basada en SDN construida
en GNS3. Otro motivo es que el porcentaje de packet loss es muy similar al configurado en
Netem, esto se puede afirmar dado que se ha realizado una medición al añadir un packet loss
del 18 %, obteniendo los resultados mostrados en la Tabla 3.9:
31
Tabla 3.9: Medición de Packet Loss
A B Diferencia % Packet Loss

Tráfico hacia
91721 75197 16524 18.02
Servidor Web
Tráfico desde
70021 85544 15523 18.15
Servidor Web
3.4.4. Análisis Combinado de Delay y Packet Loss
Una vez realizado el análisis individual de la respuesta del servidor web ante los distintos
valores de delay y packet loss añadidos de manera controlada, podemos usar los resultados
como base para encontrar una de las varias combinaciones de delay y packet loss que aseguren
una degradación en la red, sin llegar a tocar los límites de comportamiento no esperado.
Tabla 3.10: Análisis de delay y Packet Loss combinado

Packet Loss delay delay throughput Conexiones Conexiones
Solicitudes
Añadido Añadido (ms) Medido (ms) (kbps) Exitosas Fallidas
24 2150 2266.61 330.28 236 59204 59440
24 1900 2114.22 342.27 1075 55643 56718
18 1500 4024.48 317.19 2769 39125 41894
18 900 1241.35 290.78 4333 27546 31879
18 750 1026.98 293.65 6783 16997 23780
12 600 757.35 249.80 9421 7992 17413
10 500 692.47 269.23 9825 8549 18374
8 400 536.43 263.38 11671 2082 13753
10 400 545.03 263.03 11924 1110 13034
Se decidió añadir un 10 % de packet loss y 400ms de delay, teniendo un delay medido

de aproximadamente 545ms, estos valores evitan los rangos de comportamiento anómalo en
el que se genera muchas más solicitudes que un comportamiento regular y a su vez estos
valores presentan una evidente degradación de las condiciones de red, dado la disminución
de conexiones exitosas y aumento de conexiones fallidas.
3.5. Hipótesis
Uno de los objetivos fundamentales de cualquier investigación científica es la comprobación

de una hipótesis. Una hipótesis es una expresión en forma afirmativa acerca de la relación
general o específica entre dos o más variables, debiendo expresar relaciones entre variables
y ser inferencias comprobables y medibles. Las hipótesis de investigación para el presente
trabajo son:
1. “El throughput y número de conexiones establecidas por un servidor web sobre una red
SDN , es superior que sobre una Red Legacy con tecnología de acceso Wireless Lan
32
802.11n o LTE”
2. “El throughput y número de conexiones establecidas por un servidor web sobre una red
SDN en situaciones adversas de red (delay y Packet loss), es superior a una Red Legacy
con tecnología de acceso Wireless Lan 802.11n o LTE ”
Una hipótesis complementaria o nula es la que rechaza la hipótesis de investigación.[33] Las

hipótesis planteadas se aceptan o rechazan a través de dos pruebas: 1) Prueba ANOVA [34]
y test t-Student de medias [35].
33
Capítulo 4
Análisis de Datos
En este capítulo se realiza un análisis estadístico de los datos obtenidos al variar las distin-
tas configuraciones y ejecutar las repeticiones de los experimentos. A estos datos se les aplica
estadística descriptiva para caracterizarlos, posteriormente se utiliza una prueba de varianza
y una prueba de hipótesis de medias para determinar si los valores de los grupos comparados
tienen diferencias significativas aceptando o descartando las hipótesis de comparación del
desempeño de los servicios web en redes con y sin SDN. Para esto se sigue el siguiente flujo
de trabajo:
Figura 4.1: Flujo de Trabajo
4.1. Estadística Descriptiva
Para realizar la estadística descriptiva de los datos, se ha utilizado el ambiente de trabajo

y lenguaje R, el script utilizado se encuentra en el Anexo B. A continuación, se presentan
el mejor y peor escenario tanto para el análisis con acceso WLAN como con acceso LTE.
Entiéndase mejor y peor caso como aquel que contenga el número más alto y menor de cone-
xiones exitosas. La información que se detalla en las Tablas 4.1, 4.3 corresponde a la media,
desviación estándar, rango interquartil, correlación e histogramas. Los datos correspondientes
a los casos restantes se encuentran en el Anexo D [36].
34
Tabla 4.1: Estadística Descriptiva de las pruebas sin SDN, sin condiciones adversas de red y
acceso WLAN
Desviación Rango
Media 0% 25 % 50 % 75 % 100 % n
Estándar Interquartil
Conexiones
13675.3 67.01 83.75 13573 13635.25 13671.5 13719 13809 20
Exitosas
Conexiones
4.45 19.9 0 0 0 0 0 89 20
Fallidas
Throuhput (kbps) 268.33 1.44 1.98 266.04 267.24 268.39 269.22 271.59 20
Delay (ms) 21.27 3.82 4.6 17.98 18.71 19.41 23.32 30.37 20
Como parte de la estadística descriptiva, se analiza la correlación de los datos para cada
grupo. Un valor cercano a 1 en la tabla, indica una alta correlación entre las variables. Si el
valor es cercano a 0, indica una correlación baja; finalmente si el valor es negativo, indica una
correlación inversa. Para esto se ha utilizado el ambiente de trabajo y lenguaje R, se analiza
la correlación entre todos los datos, mediante el método de “Pearson” [3]. Los resultados se
pueden observar en las Tablas 4.2 y 6.12. Los datos correspondientes a los casos restantes se
encuentran en el Anexo D.
Tabla 4.2: Correlación de pruebas sin SDN, sin condiciones adversas de red y acceso WLAN
Conexiones Conexiones
Throughput Delay
Exitosas Fallidas
Conexiones
1.00 -0.04 0.80 -0.59
Exitosas
Conexiones
-0.04 1.00 0.34 0.12
Fallidas
Throughput 0.80 0.34 1.00 -0.31
Delay -0.59 0.12 -0.31 1.00
Los datos correspondientes a los casos restantes se encuentran en el Anexo D.
Las Figuras 4.2 y 4.3 caracterizan los datos en relación a la frecuencia con que se repiten
ciertos valores o rangos de valores, se crea histogramas por cada grupo y tipo de datos,
entiéndase un grupo de datos como la división más general como por ejemplo datos con
acceso LTE con infraestructura basada en SDN y con condiciones adversas de red, un tipo
de datos sería conexiones exitosas, delay, etc.
35
6
5
15
Frecuencia
Frecuencia
4
10
3
2
5
1
0
0
13550 13600 13650 13700 13750 13800 13850 0 20 40 60 80 100
Conexiones Exitosas Conexiones Fallidas
(a) (b)
6
10
5
8
Frecuencia
Frecuencia
4
6
3
4
2
2
1
0
266 267 268 269 270 271 272 20 25 30
Throughput [kbps] Delay[ms]
(c) (d)
Figura 4.2: Histogramas de pruebas sin SDN, sin condiciones adversas de red y acceso
WLAN
Los histogramas correspondientes a los casos restantes se encuentran en el Anexo D.
Tabla 4.3: Estadística Descriptiva de pruebas con SDN, con condiciones adversas de red y
acceso WLAN
Desviación Rango
Media 0% 25 % 50 % 75 % 100 % n
Conexiones
11883.5 141.39 170.75 11612 11812.25 11915.5 11983 12107 20
Exitosas
Conexiones
1301.9 283.56 415.5 990 1069.25 1193.5 1484.75 1882 20
Fallidas
Throuhput (kbps) 267.73 3.71 6.22 262.91 264.62 266.14 270.85 274.89 20
Delay (ms) 558.69 8.52 6.91 546.4 553.83 557.22 560.75 583.64 20
36
Tabla 4.4: Correlación de pruebas con SDN, con condiciones adversas de red y acceso
WLAN
Throughput Delay
Exitosas Fallidas
Conexiones
1.00 -0.94 -0.70 -0.32
Exitosas
Conexiones
-0.94 1.00 0.70 0.35
Fallidas
Throughput -0.70 0.70 1.00 0.64
Delay -0.32 0.35 0.64 1.00
8
8
Frecuencia
Frecuencia
6
6
4
4
2
2
0
11600 11700 11800 11900 12000 12100 12200 800 1000 1200 1400 1600 1800 2000
(a) (b)
0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7
Frecuencia
Frecuencia
262 264 266 268 270 272 274 276 550 560 570 580
Throughput [kbps] Delay [ms]
(c) (d)
Figura 4.3: Histogramas de pruebas con SDN, con condiciones adversas de red y acceso
WLAN
37
Tabla 4.5: Estadística Descriptiva de pruebas con SDN, sin condiciones adversas de red y
acceso LTE
Desviación Rango
Media 0% 25 % 50 % 75 % 100 % n
Conexiones
13474 112 113 13147 13416.5 13490 13529.5 13668 20
Exitosas
Conexiones
16.05 55.43 0 0 0 0 0 238 20
Fallidas
Throuhput (kbps) 264.38 1.92 2.18 259.97 263.44 264.41 265.62 268.15 20
Delay (ms) 21 4.19 0.85 18.72 19.07 19.2 19.92 31.86 20
Tabla 4.6: Correlación de pruebas con SDN, sin condiciones adversas de red y acceso LTE
Throughput Delay
Exitosas Fallidas
Conexiones
1.00 -0.72 0.79 -0.54
Exitosas
Conexiones
-0.72 1.00 -0.50 0.58
Fallidas
Throughput 0.79 -0.50 1.00 -0.28
Delay -0.54 0.58 -0.28 1.00
8
15
6
Frecuencia
Frecuencia
10
4
5
2
0
13100 13200 13300 13400 13500 13600 13700 0 50 100 150 200 250
(a) (b)
5
15
4
Frecuencia
Frecuencia
10
3
2
5
1
0
260 262 264 266 268 18 20 22 24 26 28 30 32
(c) (d)
Figura 4.4: Histogramas de pruebas con SDN, sin condiciones adversas de red y acceso LTE
38
Tabla 4.7: Estadística Descriptiva de pruebas con SDN, con condiciones adversas de red y
acceso LTE
Desviación Rango
Media 0% 25 % 50 % 75 % 100 % n
Conexiones
11818.15 117.98 179 11625 11715 11840 11894 11986 20
Exitosas
Conexiones
1220.1 160.98 170.5 1043 1117.25 1160.5 1287.75 1625 20
Fallidas
Throuhput (kbps) 264.02 2.08 1.63 261.39 262.98 263.49 264.61 270.39 20
Delay (ms) 555.04 10.2 15.4 539.56 546.98 555.71 562.38 573.42 20
Tabla 4.8: Correlación de pruebas con SDN, con condiciones adversas de red y acceso LTE
Throughput Delay
Exitosas Fallidas
Conexiones
1.00 -0.88 -0.42 -0.63
Exitosas
Conexiones
-0.88 1.00 0.77 0.74
Fallidas
Throughput -0.42 0.77 1.00 0.63
Delay -0.63 0.74 0.63 1.00
4
8
3
6
Frecuencia
Frecuencia
2
4
1
2
0
11600 11700 11800 11900 12000 1000 1100 1200 1300 1400 1500 1600 1700
(a) (b)
10
5
8
4
Frecuencia
Frecuencia
6
3
4
2
2
1
0
260 262 264 266 268 270 272 540 550 560 570
(c) (d)
Figura 4.5: Histogramas de pruebas con SDN, con condiciones adversas de red y acceso LTE
39
4.1.1. Grafos aplicados a Redes
Una alternativa para presentar el escenario estudiado y realizar distintos análisis descrip-
tivos es a través de grafos, los cuales están compuestos de vértices y arcos [37]. A los vértices
y arcos se les puede colocar una serie de atributos como, por ejemplo: tipo, capacidad (kbps),
delay (ms), packet loss ( %), etc. En la siguiente figura se observa un escenario con infra-
estructura SDN en el cuál los arcos tienen la propiedad de cambiar su ancho de banda en
Red representada con Vértices y Arcos
función a la cantidad de tráfico que circula por ese arco.
Internet Router
● 1 E1 ● 2
E2
Balanceador de Carga
Switch SDN 1 Switch SDN 2
4
E3 ● 3
E4 ● 5
E5 E6
Web Server 1 Web Server 2
Máquinas Virtualizadas
● Dispositivos de Red 6 7
Figura 4.6: Grafo generado en R de infraestructura SDN
Para este ejemplo se han agregado los siguientes atributos:
40
Tabla 4.9: Atributos Vértices
Vértice Nombre Tipo

Dispositivos
1 Internet
de Red
Dispositivos
2 Router
de Red
Switch Dispositivos
3
SDN 1 de Red
Balanceador Máquina
4
de Carga Virtualizada
Switch Dispositivos
5
SDN 2 de Red
Web Máquina
6
Server 1 Virtualizada
Web Máquina
7
Server 2 Virtualizada
Tabla 4.10: Atributo Arcos

Vértice Nombre Tipo Throughput [kbps] Delay [ms] Packet Loss [ %]
1 E1 Enlace 271 550 18.01
2 E2 Enlace 268 560 18.05
3 E3 Enlace 270 500 18.02
4 E4 Enlace 130 570 18.07
5 E5 Enlace 132 510 18.10
6 E6 Enlace 135 540 18.13
El código utilizado para generar este grafo se encuentra en el Anexo B.
4.2. Modelación de los datos experimentales
Normalidad de los Datos
Con el fin de identificar qué modelo describe con mayor exactitud los datos de throughput
y delay se comprueba si los datos siguen una distribución normal, para esto se ha utilizado
como herramienta la prueba de Saphiro-Wilk [38], obteniendo como resultado los valores
observados en la Tabla 4.11. El test de normalidad Saphiro-Wilk es explicado en el capítulo
2.7
41
Tabla 4.11: Prueba Saphiro-Wilk de Normalidad
Throughput Delay
Throughput W Delay W
p-value p-value
Tecnología de acceso
WLAN, sin SDN y 0.99583 0.1106 0.76503 <2.2e-16
sin condiciones adversas de red
WLAN, con SDN y 0.98684 3.055e-05 0.96843 4.417e-10
WLAN, sin SDN y 0.99226 0.003247 0.95287 6.249e-13
con condiciones adversas de red
WLAN, con SDN y 0.98755 5.347e-05 0.94157 1.258e-14
sin SDN y 0.99529 0.06508 0.76503 <2.2e-16
con SDN y 0.98684 3.055e-05 0.96843 4.417e-10
sin SDN y 0.9842 4.266e-06 0.95287 6.249e-13
con SDN y 0.98755 5.347e-05 0.94157 1.258e-14
Dado que el test de normalidad Saphiro-Wilk se basa en la hipótesis alternativa de que el

conjunto de datos analizados no sigue una distribución normal, se ha obtenido como resultado
que para los casos: 1) Throughput con acceso WLAN, sin SDN y sin condiciones adversas de
red; 2) throughput con acceso LTE, sin SDN y sin condiciones adversas de red, un p-value
mayor a 0.05, en consecuencia se acepta la hipótesis nula. Para el resto de los casos el valor
de p-value es menor a 0.05, concluyendo con un nivel de confianza del 95 % de que los datos
analizados no siguen una distribución normal.
42
4.2.1. Modelos propuestos
Se ha planteado comparar el desempeño de un servidor web en relación a su throughput y

conexiones exitosas. Para el caso de throughput, se realiza un modelo que describa el compor-
tamiento de los datos. Para esto a través de un script utilizando el lenguaje de programación
y ambiente de trabajo R se ha comparado distintas series de tiempo como son: 1) Modelo
lineal; 2) modelo ARMA; 3) modelo ARIMA y; 3) modelo SARIMA. El script varia los va-
lores de “p”, “q”, “d” y en el caso de sarima los valores de “P”, “Q” y “D”. Las distintas series
de tiempo se describen en el capítulo 2.8.1. Cómo se analizó en el capítulo anterior, en los
casos en los que los datos obedecen una distribución normal, se generará datos a partir de
un modelo lineal. Los modelos encontrados son utilizados para generar datos que sirven de
entrada para construir dos modelos lineales cuya función es explicar los parámetros a com-
parar (conexiones exitosas y throughput) en función de los demás parámetros. Estos nuevos
modelos son utilizados en las pruebas ANOVA, test de hipótesis y prueba de los rangos con
signo de Wicoxon. En el Anexo C, se encuentran los valores de los parámetros y tipo de serie
de tiempo encontrados, en el Anexo B se encuentra el script del lenguaje R.
4.3. Test ANOVA (analysis of variance), Test de Hipóte-

sis y Test de los rangos con signo de Wilcoxon
Para el análisis de varianza se genera un nuevo modelo por cada grupo de datos a comparar,
utilizando como entrada los datos generados por los modelos de series de tiempo anteriores
descritos en el capítulo 4.2.1, el nuevo modelo es lineal teniendo como variable dependiente
las conexiones exitosas o el throughput dependiendo del análisis que se esté realizando y
como factores que explican esta variable, el delay y throughput o delay y conexiones exitosas,
nuevamente dependiendo del análisis que se esté realizando. Para esto, se utiliza el ambiente
de trabajo y lenguaje R. La prueba plantea como hipótesis alternativa que las varianzas
son significativamente diferentes. El valor de p es el que definirá si se aprueba o rechaza la
hipótesis alternativa, siendo esta aceptada cuando p es menor a 0.05.[34]
Se realizan las siguientes comparaciones de grupos:
1. Acceso WLAN, sin SDN y sin condiciones adversas de red comparado con su par con
SDN.
2. Acceso WLAN, sin SDN y con condiciones adversas de red comparado con su par con
SDN.
3. Acceso LTE, sin SDN y sin condiciones adversas de red comparado con su par con SDN.
4. Acceso LTE, sin SDN y con condiciones adversas de red comparado con su par con
SDN.
En el caso del test de hipótesis se compara las medias de los mismos datos generados para
el test ANOVA. Se realiza tres tipos de comparación: 1) Two-sided; 2) greater y; 3) less,
43
con el fin de determinar una diferencia y cuál de las medias es mayor o menor comparado
con la otra. El test de hipótesis se realiza en el ambiente de trabajo y lenguaje R, el código
utilizado se encuentra en el anexo B. El tipo de prueba Two-sided que se configura con el
valor “t”, plantea como hipótesis alternativa que existen diferencias significativas entre los
grupos a comparar. El tipo de prueba Greater que se configura con el valor “g”, plantea
como hipótesis alternativa que la media del grupo 1 es significativamente mayor a la media
del grupo 2. Finalmente, el tipo de prueba Less plantea como hipótesis alternativa que la
media del grupo 1 es significativamente menor a la media del grupo 2. Con valores de p
menores a 0.05 se acepta la hipótesis alternativa.
La prueba de los rangos con signo de Wilcoxon [39] [36], es una prueba no paramétrica
enfocada en comparar medias cuando los datos no siguen una distribución normal. Se basa en
la hipótesis alternativa de que las medias de los grupos comparados son diferentes. La Tabla
4.12 contiene el resultado de la prueba Saphiro-Wilk de normalidad de los datos generados
por el modelo lineal. En la Figura 4.1, se puede observa el flujo de trabajo y momento en el
que se genera datos a través de este modelo. En este estudio el resultado de test de hipótesis
de media y la prueba de los rangos con signo de Wilcoxon son coincidentes.
Tabla 4.12: Test de normalidad de datos generados

Grupo 1 (Legacy) Grupo 2 (SDN)
Throughput Throughput
Exitosas Exitosas
Acceso WLAN, p = 1.396E-6 p = 0.1169 p = 0.2784 p = 9.238E-7
con condiciones adversas de red. w = 0.66218 w = 0.9237 w = 0.9434 w = 0.5496
Acceso WLAN, p = 0.5631 p = 0.0192 p = 0.0039 p = 0.8071
sin condiciones adversas de red. w = 0.9609 w = 0.8819 w = 0.8423 w = 0.9725
Acceso LTE, p = 0.7615 p = 0.1114 p = 0.1107 p = 0.848
con condiciones adversas de red. w = 0.9703 w = 0.9226 w = 0.9224 w = 0.9746
Acceso LTE, p = 0.7923 p = 0.0574 p = 0.1034 p = 0.7691
sin condiciones adversas de red. w = 0.9718 w = 0.9076 w = 0.8668 w = 0.9706
Los datos con negrita son los que obedecen una distribución normal, dado que el valor de
p es superior a 0.05.
44
4.3.1.
Delay [ms] Throughput [kbps] Conexiones Exitosas
540 550 560 570 580 264 268 272 276 11500 11700 11900 12100
LEGACY
LEGACY
LEGACY
(c)
(a)
(b)
45
SDN
SDN
SDN
Acceso WLAN con condiciones adversas de red
Tabla 4.13: Resultado de Pruebas de Grupo 1 relacionado con Conexiones Exitosas
Prueba Resultado Observación

Se rechaza H0, por lo que se puede afirmar
Anova p = 0.00662 que existe alguna diferencia significativa entre
las varianzas de los dos grupos.
Test de Hipótesis Media
p = 0.006874 que existe alguna diferencia significativa entre
"Two-sided"
las medias de los dos grupos.
p = 0.03437 que la media del grupo A (Legacy) es
"Greater"
mayor a la media del grupo B (SDN).
Se acepta H0, por lo que se puede afirmar
p = 0.9966 que la media del grupo A (Legacy) no es
"Less"
menor a la media del grupo B (SDN).
Prueba de los rangos
con signo de Wilcoxon
Tabla 4.14: Resultado de Pruebas de Grupo 1 relacionado con Throughput

Anova p = 0.615 que las varianzas son iguales entre
los dos grupos.
p = 0.6151 que las medias son iguales entre
"Two-sided"
los dos grupos.
p = 0.3076 que la media del grupo A (Legacy) no es mayor
"Greater"
a la media del grupo B (SDN).
p = 0.6924 que la media del grupo A (Legacy) no es menor
"Less"
los dos grupos.
46
4.3.2.
15 20 25 30 267 268 269 270 271 13600 13700 13800
LEGACY
LEGACY
LEGACY
(f)
(e)
(d)
47
SDN
SDN
SDN
Acceso WLAN sin condiciones adversas de red
Tabla 4.15: Resultado de Pruebas de Grupo 2 relacionado a Conexiones Exitosas

"Two-sided"
p = 0.01932 que la media del grupo A (Legacy) es
"Greater"
p = 0.9807 que la media del grupo A (Legacy) no es
"Less"
Tabla 4.16: Resultado de Pruebas de Grupo 2 relacionado a Throughput

Anova p = 7.33E-10 que existe alguna diferencia significativa entre
p = 2.032E-8 que existe alguna diferencia significativa entre
"Two-sided"
p = 1.016E-8 que la media del grupo A (Legacy) es
"Greater"
p=1 que la media del grupo A (Legacy) no es
"Less"
48
4.3.3.
530 540 550 560 570 264 265 266 267 268 11750 11850 11950
LEGACY
LEGACY
LEGACY
(i)
(g)
(h)
49
SDN
SDN
SDN
Acceso LTE, con condiciones adversas de red

"Two-sided"
p = 0.01315 que la media del grupo A (Legacy) es mayor
"Greater"
"Less"

Anova p = 0.166 que las varianzas son iguales entre
los dos grupos.
"Two-sided"
los dos grupos.
p = 0.8465 que la media del grupo A (Legacy) no es mayor
"Greater"
"Less"
los dos grupos.
50
4.3.4. Acceso LTE sin condiciones adversas de red
13500
Conexiones Exitosas
13400
13300
LEGACY SDN
(j)
268
Throughput [kbps]
266
264
262
LEGACY SDN
(k)
30
Delay [ms]
26
22
18
LEGACY SDN
(l)
51

Se acepta H0, no existe alguna diferencia
Anova p = 0.31 considerable entre las varianzas
de los dos grupos.
p = 0.3104 Se acepta H0, las medias son iguales
"Two-sided"
Se acepta H0, no se puede afirmar
p = 0.8448 que la media del grupo A (Legacy)
"Greater"
es mayor a la media del grupo B.
Se acepta H0, no se puede afirmar
p = 0.1552 que la media del grupo A (Legacy)
"Less"
es menor a la media del grupo B.
los dos grupos.

Anova p = 1.93E-6 que existe alguna diferencia significativa entre
"Two-sided"
p = 1.052E-6 que la media del grupo A (Legacy) es
"Greater"
p=1 que la media del grupo A (Legacy) no es
"Less"
52
Capítulo 5
Conclusiones
En el presente capítulo se describen los resultados del trabajo de comparación del desem-
peño de los servicios web en redes con y sin funcionalidades SDN. Se revisa el logro de los
objetivos del trabajo y si la metodología planteada es útil para alcanzar resultados de inte-
rés. Se sintetizan y discuten los resultados del trabajo, complementándolos con ideas para
trabajos futuros y que continúen de esta forma con la investigación aquí desarrollada.
5.1. Objetivos
El objetivo principal del trabajo consiste en: Medir y analizar el desempeño de una solución
de balanceo de carga de servicios web basada en SDN frente a distintas condiciones de red y
tecnologías de acceso. Complementario a este objetivo se plantean varias hipótesis que nos
permiten evaluar y analizar los objetivos inicialmente propuestos. Las hipótesis se listan en
la sección 3.5 del capítulo de introducción.
Como resultado general se puede afirmar que se logra el objetivo principal, dado que
primero se definen las métricas que se traducen en las mediciones de desempeño de un servidor
web, se desarrolla un escenario experimental con todos los elementos necesarios para las
pruebas: 1) dispositivos SDN, 2) balanceador de carga, 3) servidor web, etc. Los escenarios de
pruebas también permiten utilizar y comparar distintas tecnologías de acceso como Wireless
LAN 802.11n y LTE. El análisis estadístico vía test de hipótesis permite aceptar o rechazar
los supuestos bajo prueba, en cuanto a un mejor desempeño de los servicios web en redes con
arquitectura SDN. Los objetivos secundarios planteados en el punto 2.1. de la introducción
están estrechamente relacionados con la metodología y los procedimientos para cumplir con
el objetivo principal, por lo que al haber cubierto el objetivo principal se logran también los
objetivos secundarios.
53
5.2. Metodología y tipo de investigación
La descripción de la metodología utilizada se encuentra en punto 3 de la introducción.

Esta metodología puede ser usada como base para proyectos similares ya que es elástica y
depende de los objetivos y recursos de los que consta el investigador. Por ejemplo, es posible
aumentar o disminuir el número de dispositivos SDN, servidores Web y tráfico simulado.
Así como realizar distintos tipos de análisis al modificar condiciones de red en uno o varios
puntos. Está metodología se basa en el análisis inicial estadístico de límites experimentales y
número de repeticiones permitiendo al investigador tener un marco de trabajo sobre el cuál
se desarrollan los experimentos.
5.3. Resultados
Tomando como base el análisis de datos expuesto en el capítulo 4.3 se pueden realizar las
siguientes afirmaciones.
1. La hipótesis “El throughput y número de conexiones establecidas por un servidor web

sobre una red SDN, es superior que sobre una Red Legacy con tecnología de acceso
Wireless Lan 802.11n” consta de varias partes, con respecto a las conexiones exitosas se
puede afirmar en base a los resultados que existe una diferencia en la varianza y media
de los dos grupos; siendo superior la media con tecnología legacy. Con respecto al
throughput medido, podemos afirmar en base a las diferencias de varianza y de medias,
que el throughput logrado por una infraestructura de red legacy es superior al logrado
por una infraestructura SDN. Es importante mencionar que esta diferencia de medias
en el caso de los datos originales es de 0.1279 kbps con 44.14 conexiones exitosas. Y
en el caso de los modelos generados a partir de los datos de las pruebas, se tienen
38.85 conexiones exitosas con un throughput de 2.33 kbps. Aunque las diferencias son
pequeñas, se rechaza la hipótesis planteada.

sobre una red SDN, es superior que sobre una Red Legacy con tecnología de acceso LTE”
consta de varias partes, con respecto a las conexiones exitosas, se puede afirmar en base a
los resultados que tanto la varianza como la media es similar en las dos tecnologías. Con
respecto al throughput medido, podemos afirmar en base a las diferencias de varianza y
de medias, que el throughput logrado por una infraestructura de red legacy es superior al
logrado por una infraestructura SDN. Es importante mencionar que esta diferencia de
medias en el caso de los datos originales es de 0.2705 kbps con 22.8 conexiones exitosas.
Y en el caso de los modelos generados a partir de los datos, se tienen 38.85 conexiones
exitosas para un throughput de 2.33 kbps. Ante estos resultados y dado que el número
de conexiones exitosas es una métrica directamente relacionada con el desempeño del
servidor web, se rechaza la hipótesis planteada, es decir no hay diferencia estadística
debido al uso o no de una arquitectura SDN.
54
sobre una red SDN en situaciones adversas de red (altos delay y packet loss), es superior
que sobre una Red Legacy con tecnología de acceso Wireless Lan 802.11n”, consta
de varias partes, con respecto a las conexiones exitosas se puede afirmar en base a
los resultados que existe una diferencia en la varianza y media de los dos grupos;
siendo superior la media con tecnología legacy. Con respecto al throughput medido,
podemos afirmar que tanto la varianza como la media es similar en ambos grupos. Es
importante mencionar que esta diferencia de medias en el caso de los datos originales
es de 106.45 conexiones exitosas con un throughput de 1.05 kbps. Y en el caso de los
modelos generados desde los datos de pruebas, se tienen 106.45 conexiones exitosas para
un throughput de 0.48 kbps. Ante estos resultados y dado que el número de conexiones
exitosas es una métrica directamente relacionada con el desempeño del servidor web,
se rechaza la hipótesis planteada.

sobre una red SDN en situaciones adversas de red (altos delay y packet loss), es superior
que sobre una Red Legacy con tecnología de acceso LTE” consta de varias partes, con
respecto a las conexiones exitosas se puede afirmar en base a los resultados que existe
una diferencia en la varianza y media de los dos grupos, siendo superior la media con
tecnología legacy. Con respecto al throughput medido, podemos afirmar que tanto la
varianza como la media es similar en ambos grupos. Es importante mencionar que esta
diferencia de medias en el caso de los datos originales es de 65.7 conexiones exitosas
con un throughput de 0.45 kbps. Y en el caso de los modelos generados a partir de
los datos medidos, se tienen 65.7 conexiones exitosas para un throughput de 0.52 kbps.
Ante estos resultados y dado que el número de conexiones exitosas es una métrica
directamente relacionada con el desempeño del servidor web, se rechaza nuevamente la
hipótesis planteada.
5. Basándonos en lo expuesto en el capítulo 3.4.3, la tecnología usada (SDN o legacy) no

influye en el packet loss presente en las infraestructura de red de ninguno de los casos
estudiados.
6. Finalmente se concluye que, aunque una infraestructura SDN y una infraestructura

legacy presentan marcadas diferencias en su funcionamiento para soportar los servicios
web, su desempeño comparando el número de conexiones exitosas y el throughput es
similar, y estadísticamente idéntico en varios casos analizados, con un máximo de 3 %
de diferencia para las conexiones exitosas y para el throughput. Se presentan pequeñas
diferencias en los casos en los que no se encuentran desempeños similares siendo estos
a favor de una infraestructura legacy.
5.4. Trabajos Futuros
Como se menciona en este capítulo, la metodología utilizada es replicable y elástica en el

sentido de que se puede adaptar a los objetivos y recursos del investigador. Como trabajo
futuro se puede repetir este proyecto utilizando nuevos recursos de hardware y de esta manera
simular un mayor número de clientes y dispositivos SDN. Realizar un mayor número de
55
pruebas mejorando los intervalos de confianza. Analizar diferentes servicios como VOIP (voice
over IP), sobre una red SDN y estudiar nuevas métricas como el MOS (mean opinion score),
jitter y delay.
56
Acrónimos
ANOVA analysis of variance.
API application programming interface.
AR autoregressive.
ARIMA autoregressive integrated moving average.
ARMA autoregressive–moving-average.
ASIC application-specific integrated circuit.
AWGN additive white Gaussian noise.
GNS3 Graphical network simulator 3.
HTTP hypertext transfer protocol.
IP Internet protocol.
LAN local area network.
LTE long term evolution.
MA moving-average.
MAC medium access control.
MIMO multiple-input multiple-output.
MOS mean opinion score.
OFDM orthogonal frequency division multiplexing.
OFDMA orthogonal frequency-fivision multiple access.
57
OSI open system interconnection.
QAM quadrature amplitude modulation.
QoS quality of service.
SARIMA seasonal autoregressive integrated moving average.
SC-FDMA single carrier frequency divison multiple access.
SDN software defined network.
SLA service level agreement.
TCP transmission control protocol.
UDP user datagram protocol.
VLAN virtual local area network.
VOIP voice over IP.
VPS virtual private server.
WLAN wireless local area network.
58
Bibliografía
[1] M. Jarschel, T. Zinner, T. Hossfeld, P. Tran-Gia, and W. Kellerer, “Interfaces, attributes,

and use cases: A compass for sdn,” IEEE Communications Magazine, vol. 52, no. 6, 2014.
[2] B. Koley, Software Defined Networking At Scale, 2014, visitado: 2016-08-11. [Online].
Available: https://static.googleusercontent.com/media/research.google.com/en//pubs/
archive/42948.pdf
[3] J. Cohen, P. Cohen, S. G. West, and L. S. Aiken, Applied multiple regression/correlation

analysis for the behavioral sciences. Routledge, 2013.
[4] L. Martino and E. Bertino, “Security for web services: Standards and research issues,” in
Innovations, Standards and Practices of Web Services: Emerging Research Topics. IGI
Global, 2012.
[5] FunkLoad 1.17.1 documentation, 2011, visitado: 2016-07-15. [Online]. Available:

https://funkload.nuxeo.org/funkload.pdf
[6] IETF, Hypertext Transfer Protocol (HTTP/1.1).
[7] M. Nitika, M. Shaveta, and M. G. Raj, “Comparative analysis of load balancing algo-
rithms in cloud computing,” International Journal of Advanced Research in Computer
Engineering and Technology, vol. 1, no. 3, 2012.
[8] K. Technologies, KEMP SDN Adaptive, Powered By The HP VAN SDN Controller
The Changing Nature Of Networks, visitado: 2016-08-25. [Online]. Available:
https://kemptechnologies.com/sdn-adaptive-load-balancing/
[9] C. Johnson, Long term evolution in bullets. Johnson, 2012.
[10] R. Perahia, EldadStacey, Next generation wireless LANs, 1st ed. Cambridge University
Press, 2013.
[11] J. S. Roessler, “Lte-advanced (3gpp rel. 12) technology introduction white pa-
per.” https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_application/application_
notes/1ma252/1MA252_2e_LTE_Rel12_technology.pdf, 2015, [online],Visitado: 2016-
12-11.
[12] IETF, “Reporting ip network performance metrics: Different points of view,” https://
59
tools.ietf.org/html/rfc6703, 2012, [online] Visitado: 2016-06-01.
[13] M. B. SHAPIRO, S. S.WILK, “An analysis of variance test for normality (complete
samples),” Biometrika, vol. 52, no. 3-4, pp. 591–611, 1965.
[14] C. Chatfield, The analysis of time series: an introduction. CRC press, 2016.
[15] G. M. Box, George E. PJenkins, Time series analysis, 5th ed. Wiley, 2016.
[16] C. W. J. Granger and P. Newbold, Forecasting economic time series. Academic Press,
2014.
[17] J. M. Morreale, Patricia Anderson, Software defined networking. CRC Press, 2015.
[18] R. Nau, Introduction to ARIMA models, 2014, visitado: 2016-12-08. [On-

line]. Available: http://people.duke.edu/~rnau/Notes_on_nonseasonal_ARIMA_
models--Robert_Nau.pdf
[19] ns-3 Model Library, Release ns-3.23, Aug. 2015, visitado: 2016-07-19. [Online]. Available:
https://www.nsnam.org/docs/release/3.23/models/ns-3-model-library.pdf
[20] The official guide and reference for GNS3, visitado: 2016-05-16. [Online]. Available:
https://docs.gns3.com/
[21] Mininet Walkthrough, visitado: 2016-05-14. [Online]. Available: http://mininet.org/

walkthrough/
[22] HPE VAN SDN Controller 2.7 Installation Guide, visitado: 2015-10-10. [Online].
Available: http://h20566.www2.hpe.com/hpsc/doc/public/display?docId=c05028139
[23] B. Ehlers, NETem - Network Link Emulator for GNS3, visitado: 2016-11-24. [Online].
Available: http://www.bernhard-ehlers.de/projects/netem/index.html
[24] Nginx Community Resources, visitado: 2016-04-15. [Online]. Available: https:

//nginx.org/en/docs/
[25] Open vSwitch Documentation, 2017. [Online]. Available: https://media.readthedocs.

org/pdf/openvswitch/latest/openvswitch.pdf
[26] OpenFlow, visitado: 2016-06-11. [Online]. Available: http://archive.openflow.org/

documents/openflow-spec-v1.1.0.pdf
[27] IETF, “The secure shell (ssh) protocol architecture,” https://tools.ietf.org/html/rfc4251.

html, 2006, visitado: 2016-06-01.
[28] G. M. Sullivan and R. Feinn, “Using effect size—or why the p value is not enough,”
Journal of graduate medical education, vol. 4, no. 3, pp. 279–282, 2012.
[29] P. Morales Vallejo, “Tamaño necesario de la muestra: ¿cuántos sujetos necesita-

mos?” http://web.upcomillas.es/personal/peter/investigacion/Tama%f1oMuestra.pdf,
60
2011, universidad Pontificia Comillas, Visitado: 2016-06-25.
[30] R. E. Wyllys, Stastical Hypotheses. [Online]. Available: https://www.ischool.utexas.

edu/~wyllys/IRLISMaterials/stathyp.pdf
[31] S. B. Hulley, S. R. Cummings, W. S. Browner, D. G. Grady, and T. B. Newman, De-

signing Clinical Research, 1st ed. Wolters Kluwer, Lippincott Williams and Wilkins,
2013.
[32] Wireshark Docs, 2004, visitado: 2016-05-23, Last Revision:2014. [Online]. Available:
https://www.wireshark.org/download/docs/user-guide-us.pdf
[33] T. Dickhaus and J. Stange, “Multiple point hypothesis test problems and effective num-
bers of tests for control of the family-wise error rate,” Calcutta Statistical Association
Bulletin, vol. 65, no. 1-4, 2013.
[34] Anova / Manova, visitado el: 2016-10-20. [Online]. Available: http://www.statmethods.

net/stats/anova.html
[35] Prueba de la t de Student R, visitado: 2016-10-19. [Online]. Available: https:

//rpro.wikispaces.com/Prueba+de+la+t+de+Student
[36] E. Acuña, “Pruebas no paramétricas,” http://academic.uprm.edu/eacuna/miniman11sl.

pdf, universidad de Puerto Rico Recinto Universitario de Mayaguez, Visitado el: 2017-
01-22.
[37] G. Kolaczyk, Eric Csárdi, Statistical analysis of network data with R. Springer, 2014.
[38] P. Royston, R: Shapiro-Wilk Normality Test, visitado: 2016-11-16. [Online]. Available:

https://stat.ethz.ch/R-manual/R-devel/library/stats/html/shapiro.test.html
[39] Rpro-R, Prueba de los rangos con signo de Wilcoxon, 2015. [Online]. Available:
https://rpro.wikispaces.com/Prueba+de+los+rangos+con+signo+de+Wilcoxon
[40] R. R. Villafranca and L. R. Z. Ramajo, Métodos estadísticos para Ingenieros. Editorial

Universitat Politècnica de València, 2013.
61
Anexos
A. Hardware y software
1. Descripción del hardware disponible
Para el desarrollo del presente trabajo se han utilizado los siguientes dispositivos de hard-
ware los cuales son propiedad del autor, y cuyas principales características se describen a
continuación:
1. Computadora: ASUS MODELO:K451LA, Procesador i5, 6Gb de Ram.
2. Computadora de Escritorio: Procesador i5, 4Gb de Ram
3. VPS: LINODE VPS, Procesador 1 Core, 1 Gb de Ram.
4. Dongle LTE: Huawei Mobile Wifi E5573, FDD LTE Cat4:150/50Mbps @20M.
5. Access Point: Tp-Link TL-WR841N protocolo: 802.11n, banda: 2.4 Ghz, Velocidad
máxima teórica: 300Mbps.
2. Descripción de los Simuladores de redes revisados
NS3 3.25 (Network Simulator 3)
• Distribuidor: Nsnam.
• Sitio Web: https://www.nsnam.org/
• Licencia: Gratuita - Open Source.
• Apreciación: Utiliza lenguaje C++, contiene módulos para simular y emular distintos
tipos de acceso, contiene modulo para simular un switch SDN.
62
GNS3 1.4.6 (Graphical Network Simulator 3)
• Distribuidor: GNS3.
• Sitio Web: https://www.gns3.com/
• Apreciación: Maneja una interfaz gráfica donde se permite emular varios dispositivos
de red, es posible emular routers CISCO con su respectivo sistema operativo. No simula
ni emula ningún tipo de acceso inalámbrico. Es posible utilizar la interfaz Wireless o
utilizar un dongle LTE conectado al host sobre el cual se ejecuta GNS3.
Mininet 2.2.1
• Distribuidor: Mininet.
• Sitio Web: http://mininet.org/
• Apreciación: Permite emular Dispositivos SDN basados en Software, controlador SDN

y hosts basados en linux. Los dispositivos SDN que emula pueden utilizar distintos
protocolos en la interfaz southbound, además es compatible con varios controladores
externos.
3. Descripción de Controladores SDN revisados
OpenDayLight Beryllium-SR2
• Distribuidor: The Linux Foundation
• Sitio Web: https://www.opendaylight.org/
• Apreciación: Uno de los controladores más populares con varias organizaciones respal-
dándolo. Al probarlo presentó inconvenientes al crear nuevas entradas en las flow tables,
las que se ingresaron ’manualmente’.
HPE VAN SDNLTE Controller 2.5.20.1227
• Distribuidor: Hewlett Packard.
63
• Sitio Web:
https://h10145.www1.hp.com/downloads/SoftwareReleases.aspx?ProductNumber=
J9863AAE
• Licencia: Propietaria.
• Apreciación: Aunque es software propietario, se puede descargar, instalar e usar sin

ninguna restricción. Tiene varias aplicaciones gratuitas y de pago disponibles e incluso
algunas ya instaladas, al probarlo no presentó ningún inconveniente.
4. Generadores de condiciones de red
Clumsy 0.2
• Distribuidor: Usuario jagt.
• Sitio Web:https://jagt.github.io/
• Apreciación: Es una herramienta que funciona sobre el sistema operativo Windows,

permite crear malas condiciones de red, agregando de manera controlada: delay, packet
loss, etc.
Comcast
• Distribuidor: Usuario tylertreat.
• Sitio Web:https://github.com/tylertreat/comcast
• Apreciación: Esta herramienta funciona sobre el sistema operativo Linux, permite crear
malas condiciones de Red, agregando de manera controlada: delay, packet loss y con-
trolando el throughput. Se basa en los programas de linux: Iptables y TC.
Netem
• Distribuidor: http://www.bernhard-ehlers.de/
• Sitio Web:http://www.bernhard-ehlers.de/projects/netem/index.html
• Licencia: No está especificada.
64
• Apreciación: Netem es una herramienta de software creada para funcionar en conjunto
con GNS3, puede ser incluida como complemento en GNS3 o cómo una máquina vir-
tual. Contiene una interfaz gráfica que permite configurar delay, packet loss, jitter y
throughput. Se basa en los programas para linux: Iptables y TC.
5. Herramientas para mediciones
Wireshark 2.0.3
• Distribuidor: Wireshark Foundation.
• Sitio Web:https://www.wireshark.org/
• Apreciación: Es un sniffer que se basa en capturar paquetes a través de una interfaz de

red, contiene varias herramientas para el filtrado y análisis de datos.
Netflow V5
• Distribuidor: Cisco Systems
• Sitio Web:
https://www.cisco.com/c/en/us/products/ios-nx-os-software/ios-netflow/index.html
• Licencia: Propietaria
• Apreciación: Es de gran utilidad dado que se implementa directamente en los dis-

positivos de red como routers. Consume pocos recursos de hardware. Existen varias
herramientas para análisis de flujo que lo soportan, como es el caso de NFDUMP, el
cual se puede implementar sobre una máquina linux con la función de sonda. No provee
tanta información como un sniffer en una interfaz de red.
Nfdump/Nfsen
• Distribuidor: Usuario phaag
• Sitio Web:https://github.com/phaag/nfdump
• Licencia: BSD
• Apreciación: Junto con Netflow, se puede obtener información de los flujos capturados
de manera sencilla e incluso exportarlos a un formato separado por comas para futuro
65
análisis, con NFSEN, es el gestor web que permite obtener gráficas de los flujos en
tiempo real.
SilK
• Distribuidor: CERT Network Situational Awareness (CERT NetSA)
• Sitio Web:https://tools.netsa.cert.org/silk/
• Licencia: GNU General Public License
• Apreciación: Permite recolectar, almacenar y analizar información generada a través

de Netflow.
6. Software para Balanceo de Carga
KEMP Load Balancer
• Distribuidor: Kemp Technologies
• Sitio Web:https://kemptechnologies.com/load-balancer/
• Licencia: Propietaria
• Apreciación: Es compatible con los controladores: OpenDayLight y HP SDN VAN

Controller. Utiliza la información del controlador para determinar hacia que servidor
redirigir el tráfico.
7. Software para generación de tráfico
Iperf3
• Distribuidor: ESnet / Lawrence Berkeley National Laboratory.
• Sitio Web:https://github.com/tylertreat/comcast
• Apreciación: Trabaja en modo cliente-servidor, soporta varios parámetros y distintos

protocolos, entrega reportes del ancho de banda, pérdidas de paquetes y otros paráme-
tros.
66
Locust
• Sitio Web:http://locust.io/
• Apreciación: Puede generar varias solicitudes a servidores Web, iniciar sesiones y simu-
lar navegación.
Funkload
• Sitio Web:http://locust.io/
• Apreciación: Puede generar varias solicitudes a servidores Web, iniciar sesiones y simu-
lar navegación registrando el número de solicitudes exitosas y fallidas.
8. Software para análisis estadístico
• Distribuidor: The R Project for Statistical Computing
• Sitio Web:https://www.r-project.org/
• Apreciación: Es un ambiente de programación y lenguaje enfocado al análisis estadís-

tico.
67
B. Código en R
1. Estadística Descriptiva
1 # ######
2 # Script para Estadistica Descriptiva de datos
3 # Autor : Andres Cordova
4 # Fecha :24 / 01 / 2017
5 # ######
6 # #######
7 library ( Rcmdr )
8 # ### WLAN ####
9 # ### SSDN SCR ####
10 # # Estadistica Descriptiva ##
11 ED _ WL _ SSDN _ SCR <- read . csv ( " C : / Users / andresc / Desktop / Pruebas
Tesis / Wifi / Muestreo
SSDN _ WL _ SCR / estadistica _ descriptiva _ SSDN _ WL _ SCR . csv " , sep = " ; " )
12 temp = numSummary ( ED _ WL _ SSDN _ SCR ) ;
13 write . csv ( temp $ table , " ED _ WL _ SSDN _ SCR . csv " ) ;
14 # # Histogramas ##
15 pdf ( " ED _ WL _ SSDN _ SCR _ ce . pdf " , width = 6 , height = 4 , paper = ’ special ’)
16 hist ( ED _ WL _ SSDN _ SCR $ ce , col = rainbow (12) , main = " " , xlab = " Conexiones
Exitosas " , ylab = " Frecuencia " )
17 dev . off ()
18 pdf ( " ED _ WL _ SSDN _ SCR _ cf . pdf " , width = 6 , height = 4 , paper = ’ special ’)
19 hist ( ED _ WL _ SSDN _ SCR $ cf , col = rainbow (12) , main = " " , xlab = " Conexiones
Fallidas " , ylab = " Frecuencia " )
20 dev . off ()
21 pdf ( " ED _ WL _ SSDN _ SCR _ thr . pdf " , width = 6 , height = 4 , paper = ’ special ’)
22 hist ( ED _ WL _ SSDN _ SCR $ thr , col = rainbow (12) , main = " " , xlab =
" Throughput " , ylab = " Frecuencia " )
23 dev . off ()
24 pdf ( " ED _ WL _ SSDN _ SCR _ dl . pdf " , width = 6 , height = 4 , paper = ’ special ’)
25 hist ( ED _ WL _ SSDN _ SCR $ dl , col = rainbow (12) , main = " " , xlab = " Delay " , ylab
= " Frecuencia " )
26 dev . off ()
27 # # Correlacion ##
28 correlacion = cor ( ED _ WL _ SSDN _ SCR , use = " complete " )
29 write . csv ( correlacion , " CR _ WL _ SSDN _ SCR . csv " ) ;
30 # ### CSDN SCR ####
31 # # Estadistica Descriptiva ##
32 ED _ WL _ CSDN _ SCR <- read . csv ( " C : / Users / andresc / Desktop / Pruebas
CSDN _ WL _ SCR / estadistica _ descriptiva _ CSDN _ WL _ SCR . csv " , sep = " ; " )
33 temp = numSummary ( ED _ WL _ CSDN _ SCR ) ;
34 write . csv ( temp $ table , " ED _ WL _ CSDN _ SCR . csv " ) ;
36 pdf ( " ED _ WL _ CSDN _ SCR _ ce . pdf " , width = 6 , height = 4 , paper = ’ special ’)
68
37 hist ( ED _ WL _ CSDN _ SCR $ ce , col = rainbow (12) , main = " " , xlab = " Conexiones
38 dev . off ()
39 pdf ( " ED _ WL _ CSDN _ SCR _ cf . pdf " , width = 6 , height = 4 , paper = ’ special ’)
40 hist ( ED _ WL _ CSDN _ SCR $ cf , col = rainbow (12) , main = " " , xlab = " Conexiones
41 dev . off ()
42 pdf ( " ED _ WL _ CSDN _ SCR _ thr . pdf " , width = 6 , height = 4 , paper = ’ special ’)
43 hist ( ED _ WL _ CSDN _ SCR $ thr , col = rainbow (12) , main = " " , xlab =
44 dev . off ()
45 pdf ( " ED _ WL _ CSDN _ SCR _ dl . pdf " , width = 6 , height = 4 , paper = ’ special ’)
46 hist ( ED _ WL _ CSDN _ SCR $ dl , col = rainbow (12) , main = " " , xlab = " Delay " , ylab
= " Frecuencia " )
47 dev . off ()
49 correlacion = cor ( ED _ WL _ CSDN _ SCR , use = " complete " )
50 write . csv ( correlacion , " CR _ WL _ CSDN _ SCR . csv " ) ;
51 # #### SSDN CCR ####
52 # # Estadistica Descriptiva
53 ED _ WL _ SSDN _ CCR <- read . csv ( " C : / Users / andresc / Desktop / Pruebas
SSDN _ WL _ CCR / estadistica _ descriptiva _ SSDN _ WL _ CCR . csv " , sep = " ; " )
54 temp = numSummary ( ED _ WL _ SSDN _ CCR ) ;
55 write . csv ( temp $ table , " ED _ WL _ SSDN _ CCR . csv " ) ;
57 pdf ( " ED _ WL _ SSDN _ CCR _ ce . pdf " , width = 6 , height = 4 , paper = ’ special ’)
58 hist ( ED _ WL _ SSDN _ CCR $ ce , col = rainbow (12) , main = " " , xlab = " Conexiones
59 dev . off ()
60 pdf ( " ED _ WL _ SSDN _ CCR _ cf . pdf " , width = 6 , height = 4 , paper = ’ special ’)
61 hist ( ED _ WL _ SSDN _ CCR $ cf , col = rainbow (12) , main = " " , xlab = " Conexiones
62 dev . off ()
63 pdf ( " ED _ WL _ SSDN _ CCR _ thr . pdf " , width = 6 , height = 4 , paper = ’ special ’)
64 hist ( ED _ WL _ SSDN _ CCR $ thr , col = rainbow (12) , main = " " , xlab =
65 dev . off ()
66 pdf ( " ED _ WL _ SSDN _ CCR _ dl . pdf " , width = 6 , height = 4 , paper = ’ special ’)
67 hist ( ED _ WL _ SSDN _ CCR $ dl , col = rainbow (12) , main = " " , xlab = " Delay " , ylab
= " Frecuencia " )
68 dev . off ()
70 correlacion = cor ( ED _ WL _ SSDN _ CCR , use = " complete " )
71 write . csv ( correlacion , " CR _ WL _ SSDN _ CCR . csv " ) ;
72 # ### CSDN CCR ####
73 ED _ WL _ CSDN _ CCR <- read . csv ( " C : / Users / andresc / Desktop / Pruebas
CSDN _ WL _ CCR / estadistica _ descriptiva _ CSDN _ WL _ CCR . csv " , sep = " ; " )
74 temp = numSummary ( ED _ WL _ CSDN _ CCR ) ;
69
75 write . csv ( temp $ table , " ED _ WL _ CSDN _ CCR . csv " ) ;
76 pdf ( " ED _ WL _ CSDN _ CCR _ ce . pdf " , width = 6 , height = 4 , paper = ’ special ’)
77 hist ( ED _ WL _ CSDN _ CCR $ ce , col = rainbow (12) , main = " " , xlab = " Conexiones
78 dev . off ()
79 pdf ( " ED _ WL _ CSDN _ CCR _ cf . pdf " , width = 6 , height = 4 , paper = ’ special ’)
80 hist ( ED _ WL _ CSDN _ CCR $ cf , col = rainbow (12) , main = " " , xlab = " Conexiones
81 dev . off ()
82 pdf ( " ED _ WL _ CSDN _ CCR _ thr . pdf " , width = 6 , height = 4 , paper = ’ special ’)
83 hist ( ED _ WL _ CSDN _ CCR $ thr , col = rainbow (12) , main = " " , xlab =
84 dev . off ()
85 pdf ( " ED _ WL _ CSDN _ CCR _ dl . pdf " , width = 6 , height = 4 , paper = ’ special ’)
86 hist ( ED _ WL _ CSDN _ CCR $ dl , col = rainbow (12) , main = " " , xlab = " Delay " , ylab
= " Frecuencia " )
87 dev . off ()
88 # Correlacion
89 correlacion = cor ( ED _ WL _ CSDN _ CCR , use = " complete " )
90 write . csv ( correlacion , " CR _ WL _ CSDN _ CCR . csv " ) ;
91 # ### LTE ####
92
93 # ### SSDN SCR ####

95 ED _ LTE _ SSDN _ SCR <- read . csv ( " C : / Users / andresc / Desktop / Pruebas
Tesis / LTE / Muestreo
SSDN _ LTE _ SCR / estadistica _ descriptiva _ SSDN _ LTE _ SCR . csv " , sep = " ; " )
96 temp = numSummary ( ED _ LTE _ SSDN _ SCR ) ;
97 write . csv ( temp $ table , " ED _ LTE _ SSDN _ SCR . csv " ) ;
99 pdf ( " ED _ LTE _ SSDN _ SCR _ ce . pdf " , width = 6 , height = 4 , paper = ’ special ’)
100 hist ( ED _ LTE _ SSDN _ SCR $ ce , col = rainbow (12) , main = " " , xlab = " Conexiones
101 dev . off ()
102 pdf ( " ED _ LTE _ SSDN _ SCR _ cf . pdf " , width = 6 , height = 4 , paper = ’ special ’)
103 hist ( ED _ LTE _ SSDN _ SCR $ cf , col = rainbow (12) , main = " " , xlab = " Conexiones
104 dev . off ()
105 pdf ( " ED _ LTE _ SSDN _ SCR _ thr . pdf " , width = 6 , height = 4 ,
paper = ’ special ’)
106 hist ( ED _ LTE _ SSDN _ SCR $ thr , col = rainbow (12) , main = " " , xlab =
107 dev . off ()
108 pdf ( " ED _ LTE _ SSDN _ SCR _ dl . pdf " , width = 6 , height = 4 , paper = ’ special ’)
109 hist ( ED _ LTE _ SSDN _ SCR $ dl , col = rainbow (12) , main = " " , xlab =
" Delay " , ylab = " Frecuencia " )
110 dev . off ()
112 correlacion = cor ( ED _ LTE _ SSDN _ SCR , use = " complete " )
113 write . csv ( correlacion , " CR _ LTE _ SSDN _ SCR . csv " )
70
114 # ### CSDN SCR ####
115 # Estadistica Descriptiva
116 ED _ LTE _ CSDN _ SCR <- read . csv ( " C : / Users / andresc / Desktop / Pruebas
CSDN _ LTE _ SCR / estadistica _ descriptiva _ CSDN _ LTE _ SCR . csv " , sep = " ; " )
117 temp = numSummary ( ED _ LTE _ CSDN _ SCR ) ;
118 write . csv ( temp $ table , " ED _ LTE _ CSDN _ SCR . csv " ) ;
120 pdf ( " ED _ LTE _ CSDN _ SCR _ ce . pdf " , width = 6 , height = 4 , paper = ’ special ’)
121 hist ( ED _ LTE _ CSDN _ SCR $ ce , col = rainbow (12) , main = " " , xlab = " Conexiones
122 dev . off ()
123 pdf ( " ED _ LTE _ CSDN _ SCR _ cf . pdf " , width = 6 , height = 4 , paper = ’ special ’)
124 hist ( ED _ LTE _ CSDN _ SCR $ cf , col = rainbow (12) , main = " " , xlab = " Conexiones
125 dev . off ()
126 pdf ( " ED _ LTE _ CSDN _ SCR _ thr . pdf " , width = 6 , height = 4 ,
127 hist ( ED _ LTE _ CSDN _ SCR $ thr , col = rainbow (12) , main = " " , xlab =
128 dev . off ()
129 pdf ( " ED _ LTE _ CSDN _ SCR _ dl . pdf " , width = 6 , height = 4 , paper = ’ special ’)
130 hist ( ED _ LTE _ CSDN _ SCR $ dl , col = rainbow (12) , main = " " , xlab =
131 dev . off ()
132 # # Correlacion
133 correlacion = cor ( ED _ LTE _ CSDN _ SCR , use = " complete " )
134 write . csv ( correlacion , " CR _ LTE _ CSDN _ SCR . csv " )
135 # #### SSDN CCR ####
137 ED _ LTE _ SSDN _ CCR <- read . csv ( " C : / Users / andresc / Desktop / Pruebas
SSDN _ LTE _ CCR / estadistica _ descriptiva _ SSDN _ LTE _ CCR . csv " , sep = " ; " )
138 temp = numSummary ( ED _ LTE _ SSDN _ CCR ) ;
139 write . csv ( temp $ table , " ED _ LTE _ SSDN _ CCR . csv " ) ;
141 pdf ( " ED _ LTE _ SSDN _ CCR _ ce . pdf " , width = 6 , height = 4 , paper = ’ special ’)
142 hist ( ED _ LTE _ SSDN _ CCR $ ce , col = rainbow (12) , main = " " , xlab = " Conexiones
143 dev . off ()
144 pdf ( " ED _ LTE _ SSDN _ CCR _ cf . pdf " , width = 6 , height = 4 , paper = ’ special ’)
145 hist ( ED _ LTE _ SSDN _ CCR $ cf , col = rainbow (12) , main = " " , xlab = " Conexiones
146 dev . off ()
147 pdf ( " ED _ LTE _ SSDN _ CCR _ thr . pdf " , width = 6 , height = 4 ,
148 hist ( ED _ LTE _ SSDN _ CCR $ thr , col = rainbow (12) , main = " " , xlab =
149 dev . off ()
150 pdf ( " ED _ LTE _ SSDN _ CCR _ dl . pdf " , width = 6 , height = 4 , paper = ’ special ’)
71
151 hist ( ED _ LTE _ SSDN _ CCR $ dl , col = rainbow (12) , main = " " , xlab =
152 dev . off ()
153 # # Correlacion
154 correlacion = cor ( ED _ LTE _ SSDN _ CCR , use = " complete " )
155 write . csv ( correlacion , " CR _ LTE _ SSDN _ CCR . csv " )
156 # ### CSDN CCR ####
158 ED _ LTE _ CSDN _ CCR <- read . csv ( " C : / Users / andresc / Desktop / Pruebas
CSDN _ LTE _ CCR / estadistica _ descriptiva _ CSDN _ LTE _ CCR . csv " , sep = " ; " )
159 temp = numSummary ( ED _ LTE _ CSDN _ CCR ) ;
160 write . csv ( temp $ table , " ED _ LTE _ CSDN _ CCR . csv " ) ;
162 pdf ( " ED _ LTE _ CSDN _ CCR _ ce . pdf " , width = 6 , height = 4 , paper = ’ special ’)
163 hist ( ED _ LTE _ CSDN _ CCR $ ce , col = rainbow (12) , main = " " , xlab = " Conexiones
164 dev . off ()
165 pdf ( " ED _ LTE _ CSDN _ CCR _ cf . pdf " , width = 6 , height = 4 , paper = ’ special ’)
166 hist ( ED _ LTE _ CSDN _ CCR $ cf , col = rainbow (12) , main = " " , xlab = " Conexiones
167 dev . off ()
168 pdf ( " ED _ LTE _ CSDN _ CCR _ thr . pdf " , width = 6 , height = 4 ,
169 hist ( ED _ LTE _ CSDN _ CCR $ thr , col = rainbow (12) , main = " " , xlab =
170 dev . off ()
171 pdf ( " ED _ LTE _ CSDN _ CCR _ dl . pdf " , width = 6 , height = 4 , paper = ’ special ’)
172 hist ( ED _ LTE _ CSDN _ CCR $ dl , col = rainbow (12) , main = " " , xlab =
173 dev . off ()
174 # # Correlacion
175 correlacion = cor ( ED _ LTE _ CSDN _ CCR , use = " complete " )
176 write . csv ( correlacion , " CR _ LTE _ CSDN _ CCR . csv " )
codigo/3.R
72
2. Código para encontrar el mejor modelo Lineal, Arima o Sarima
1 # ######
2 # Script para construccion de modelos Lineales , Arima y Sarima ##
4 # Fecha :24 / 01 / 2017
5 # ######
6
7 rm ( list = ls () )
8 library ( mvnormtest )
9 # Inicio de cronometro para medir demora del proceso
10 ptm <- proc . time ()
11 # ## Carga de Datos ####
12 # La carga de archivos se realiza de forma manual , uno por una en
cada caso
13 # input <- read . csv (" C : / Users / andresc / Desktop / Pruebas
Tesis / Wifi / Muestreo CSDN _ WL _ CCR / Consolidado _ WL _ CSDN _ CCR . csv " ,
header = FALSE , sep =";")
Tesis / Wifi / Muestreo SSDN _ WL _ CCR / Consolidado _ WL _ SSDN _ CCR . csv " ,
Tesis / Wifi / Muestreo CSDN _ WL _ SCR / Consolidado _ WL _ CSDN _ SCR . csv " ,
Tesis / Wifi / Muestreo SSDN _ WL _ SCR / Consolidado _ WL _ SSDN _ SCR . csv " ,
Tesis / LTE / Muestreo CSDN _ LTE _ CCR / Consolidado _ LTE _ CSDN _ CCR . csv " ,
Tesis / LTE / Muestreo CSDN _ LTE _ SCR / Consolidado _ LTE _ CSDN _ SCR . csv " ,
Tesis / LTE / Muestreo SSDN _ LTE _ CCR / Consolidado _ LTE _ SSDN _ CCR . csv " ,
20 input <- read . csv ( " C : / Users / andresc / Desktop / Pruebas
Tesis / LTE / Muestreo SSDN _ LTE _ SCR / Consolidado _ LTE _ SSDN _ SCR . csv " ,
header = FALSE , sep = " ; " )
21 input = as . matrix ( input )
22
23 # ### Valores Iniciales ####

24 periodo =1
25 col =1
26 # ### Matrices Iniciales ####
27 maics = matrix ( NaN , nrow = 50 , ncol = 4) ; # Matriz de aics Arima
28 maics2 = matrix ( NaN , nrow = 50 , ncol = 4) ; # Matriz de aics Sarima
29 data = matrix ( NaN , nrow = 20 , ncol = 2) ; # Matriz de valores generados a
partir de modelos
73
30 resultado = matrix ( NaN , nrow = 40 , ncol = 8) ; # Parametros del modelos
seleccinado
31 # ### Calcular mejor modelo para cada muestra ####
32 for ( k in seq (1 ,40 ,1) ) {
33 maics = matrix ( NaN , nrow = 50 , ncol = 4) ;
34 maics2 = matrix ( NaN , nrow = 50 , ncol = 4) ;
35 n =1
36 # k =1 ## prueba
37 # ### Lineal ####
38 mlineal = lm ( input [ , k ] ~ seq (1 ,601 ,1) )
39 laic = AIC ( mlineal )
40
41 # ### ARIMA ####

42 for ( d in seq (0 ,2 ,1) )
43 {
44 for ( p in seq (0 ,5 ,1) )
45 {
46 for ( q in seq (0 ,5 ,1) )
47 {
48 tryCatch ({
49 modelo = arima ( input [ , k ] , xreg = seq (1 ,601 ,1) , order =
c (p ,d , q ) , include . mean = FALSE ) ;
50 maics [n ,1]= AIC ( modelo ) ;
51 maics [n ,2]= p ;
52 maics [n ,3]= d ;
53 maics [n ,4]= q ;
54 n = n +1
55 } , error = function ( e ) { cat ( " ERROR : " , conditionMessage ( e ) ,
" \ n " ) })
56 }
57 }
58 }
59 valoresa = which ( maics == maics [ which . min ( maics [ ,1]) ] , arr . ind =
TRUE )
60 valoresa = valoresa [1 ,1]
61 # ## Modelo menor AIC ARIMA ####
62 arimodelo = arima ( input [ , k ] , xreg = seq (1 ,601 ,1) , order
= c ( maics [ valoresa ,2] , maics [ valoresa ,3] , maics [ valoresa ,4]) ,
include . mean = FALSE ) ;
63 ariaic = AIC ( arimodelo )
64 # ### SARIMA ####
65 n =1
66 for ( d in seq (0 ,2 ,1) ) {
67
68 for ( i in seq (0 ,5 ,1) )

69 {
70
71 for ( j in seq (0 ,5 ,1) )

72 {
73 tryCatch ({
74
74 modelo = arima ( input [ , k ] , xreg = seq (1 ,601 ,1) , order =
c ( maics [ valoresa ,2] , maics [ valoresa ,3] , maics [ valoresa ,4]) ,
include . mean = FALSE , seasonal = list ( order = c (i ,d , j ) ,
period = periodo ) )
75 maics2 [n ,1]= AIC ( modelo ) ;
76 maics2 [n ,2]= i ;
77 maics2 [n ,3]= d ;
78 maics2 [n ,4]= j ;
79 n = n +1
80 } , error = function ( e ) { cat ( " ERROR : " , conditionMessage ( e ) ,
" \ n " ) })
81 }
82 }
83 }
84
85 valoresa2 = which ( maics2 == maics2 [ which . min ( maics2 [ ,1]) ] , arr . ind =
TRUE )
86 valoresa2 = valoresa2 [1 ,1]
87 # ## Modelo menor AIC SARIMA ####
88 sarimodelo = arima ( input [ , k ] , xreg = seq (1 ,601 ,1) , order =
c ( maics [ valoresa ,2] , maics [ valoresa ,3] , maics [ valoresa ,4]) ,
include . mean = FALSE , seasonal = list ( order =
c ( maics2 [ valoresa2 ,2] , maics2 [ valoresa2 ,3] , maics2 [ valoresa2 ,4]) ,
period = periodo ) )
89 sariaic = AIC ( sarimodelo )
90 laic
91 sariaic
92 ariaic
93 if ( laic < ariaic & & laic < sariaic ) {
94 ajuste = mlineal $ fitted . values
95 a =1
96 } else { if ( ariaic < laic & & ariaic < sariaic ) {
97 ajuste = input [ , k ] - arimodelo $ residuals
98 a =2
99 } else { if ( sariaic < laic & & sariaic < ariaic ) {
100 ajuste = input [ , k ] - sarimodelo $ residuals
101 a =3
102 } else { ajuste = input [ , k ] - arimodelo $ residuals
103 a =2
104 }}}
105
106 data [ floor ( k / 2+0.5) , col ]= mean ( ajuste , na . rm = TRUE )

107
108 if ( col == 1) {
109 col = 2
110
111 } else {
112 col = 1
113 }
114 resultado [k ,1] = a
75
115
116 if ( a == 1) {
117 resultado [k ,2] = 0
123 resultado [k ,8] = laic
124 } else {
125 if ( a == 2) {
126 resultado [k ,2] = maics [ valoresa ,2]
132 resultado [k ,8] = ariaic
133 } else {
134 if ( a == 3) {
138 resultado [k ,5] = maics2 [ valoresa2 ,2]
141 resultado [k ,8] = sariaic
142 }
143 }
144 }
145 }
146
147 proc . time () - ptm # Se detiene cronometro del proceso

148 # Escritura de resultados en archivo separado por comas .
149 write . csv ( resultado , " resultado _ LTE _ SSDN _ SCR . csv " )
150 write . csv ( data , " data _ LTE _ SSDN _ SCR . csv " )
151
152 # Se analiza normalidad con cada conjunto de datos #

153 # ## Shapiro Test ###
154 Saphiro _ test _ Data <- read . csv ( " C : / Users / andresc / Desktop / Pruebas
Tesis / Saphiro _ test _ Data . csv " , sep = " ; " )
155 # WIFI #
156
157 temp = Saphiro _ test _ Data $ ssdn _ scr _ thr

158 shapiro . test ( temp )
159
160 temp = Saphiro _ test _ Data $ lte _ ssdn _ scr _ dl

162
163 temp = Saphiro _ test _ Data $ lte _ csdn _ scr _ thr
76
165
166 temp = Saphiro _ test _ Data $ lte _ csdn _ scr _ dl

168 ##
169 temp = Saphiro _ test _ Data $ ssdn _ ccr _ thr
171
172 temp = Saphiro _ test _ Data $ lte _ ssdn _ ccr _ dl

174
175 temp = Saphiro _ test _ Data $ lte _ csdn _ ccr _ thr

177
178 temp = Saphiro _ test _ Data $ lte _ csdn _ ccr _ dl

180 # ##### LTE ######
181 temp = Saphiro _ test _ Data $ lte _ ssdn _ scr _ thr
183
184 temp = Saphiro _ test _ Data $ lte _ ssdn _ scr _ dl

186
187 temp = Saphiro _ test _ Data $ lte _ csdn _ scr _ thr

189
190 temp = Saphiro _ test _ Data $ lte _ csdn _ scr _ dl

192
193 temp = Saphiro _ test _ Data $ lte _ ssdn _ ccr _ thr

195
196 temp = Saphiro _ test _ Data $ lte _ ssdn _ ccr _ dl

198
199 temp = Saphiro _ test _ Data $ lte _ csdn _ ccr _ thr

201
202 temp = Saphiro _ test _ Data $ lte _ csdn _ ccr _ dl

204
205 # ### Modelos Lineales para casos normales WL SSDN y SCR / LTE SSDN y
SCR ####
206 data = matrix ( NaN , nrow = 20 , ncol = 2)
207 c =1
208 for ( k in seq (1 ,39 ,2) ) {
209 mlineal = lm ( input [ , k ] ~ seq (1 ,601 ,1) )
210 laic = AIC ( mlineal )
211 ajuste = mlineal $ fitted . values
212 data [c ,1]= mean ( ajuste , na . rm = TRUE )
77
213 data [c ,2]= laic
214 c = c +1
215 }
216 # Grabar resultado en archivo separado por comas .
217 write . csv ( data , " lineal _ LTE _ SSDN _ SCR . csv " )
codigo/1.R
3. Código para prueba Anova y Test de Hipótesis

1 # ######
2 # Script para test Anova y test de hipotesis de medias
4 # Fecha :24 / 01 / 2017
5 # ######
6
7 # ### ####
8 # M4 SIN SDN
9 # M5 CON SDN
10 # Hipotesis 1. En condiciones normales de red es mejor el desempeno
de SW con SDN o SIN SDN .
11 # # Carga de Datos
12 rm ( list = ls () )
13 # Se selecciona el caso a estudiar y se ejecuta el script
14 # Caso 1 / Wireless LAN , con condiciones adversas de Red
15 # data _ 1 <- read . csv (" C : / Users / andresc / Desktop / Pruebas
Tesis / Datos _ Generados / WIFI / CCR / data _ WL _ SSDN _ CCR . csv " , sep =";")
Tesis / Datos _ Generados / WIFI / CCR / data _ WL _ CSDN _ CCR . csv " , sep =";")
17 # data _ Consolidado <- read . csv (" C : / Users / andresc / Desktop / Pruebas
Tesis / Datos _ Generados / WIFI / CCR / data _ Consolidado . csv " , sep =";")
18 # Caso 2 / Wireless LAN , sin condiciones adversas de Red
Tesis / Datos _ Generados / WIFI / SCR / data _ WL _ SSDN _ SCR . csv " , sep =";")
Tesis / Datos _ Generados / WIFI / SCR / data _ WL _ CSDN _ SCR . csv " , sep =";")
Tesis / Datos _ Generados / WIFI / SCR / data _ Consolidado . csv " , sep =";")
22 # Caso 3 / LTE , con condiciones adversas de Red
Tesis / Datos _ Generados / LTE / CCR / data _ LTE _ SSDN _ CCR . csv " , sep =";")
Tesis / Datos _ Generados / LTE / CCR / data _ LTE _ CSDN _ CCR . csv " , sep =";")
Tesis / Datos _ Generados / LTE / CCR / data _ Consolidado . csv " , sep =";")
26 # Caso 4 / LTE , sin condiciones adversas de Red
Tesis / Datos _ Generados / LTE / SCR / data _ LTE _ SSDN _ SCR . csv " , sep =";")
78
Tesis / Datos _ Generados / LTE / SCR / data _ LTE _ CSDN _ SCR . csv " , sep =";")
Tesis / Datos _ Generados / LTE / SCR / data _ Consolidado . csv " , sep =";")
30 # ## Grafica Conexiones CSDN y SSDN
31 pdf ( " Caso _ 4 _ Dl . pdf " , width = 6 , height = 4 , paper = ’ special ’)
32 par ( family = " serif " )
33 plot ( data _ Consolidado $ Dl ~
as . factor ( data _ Consolidado $ TECNOLOGIA ) , col = " green " , ylab = " Delay
[ ms ] " , xlab = " " )
34 dev . off ()
35 pdf ( " Caso _ 4 _ CE . pdf " , width = 6 , height = 4 , paper = ’ special ’)
37 plot ( data _ anova $ conexiones ~
as . factor ( data _ anova $ tecnologia ) , col = " green " , ylab = " Conexiones
Exitosas " , xlab = " " )
38 dev . off ()
39 pdf ( " Caso _ 4 _ Thr . pdf " , width = 6 , height = 4 , paper = ’ special ’)
41 plot ( data _ anova $ thr ~
as . factor ( data _ anova $ tecnologia ) , col = " green " , ylab = " Throughput
[ kbps ] " , xlab = " " )
42 dev . off ()
43 # ### M4 , M5 Conexiones Exitosas ####
44 m4 = lm ( data _ 1 $ V3 ~ data _ 1 $ V1 + data _ 1 $ V2 )
46 # # Anova Test ###
47 conexiones = c ( m4 $ fitted . values )
48 conexiones = append ( x = conexiones , values = m5 $ fitted . values , after =
length ( m4 $ fitted . values ) )
49 conexiones = as . matrix ( conexiones )
50 tecnologia = c ( rep ( " LEGACY " ,20) , rep ( " SDN " ,20) )
51 data _ anova = data . frame ( conexiones , tecnologia )
52 res _ anova = aov ( conexiones ~ tecnologia , data = data _ anova ) # H0 = medias
son iguales H1 = alguna diferencia . p <0.05 se acepta H1
53 summary ( res _ anova )
54 # ## Test de Hipotesis medias ###
55 t . test ( m4 $ fitted . values , m5 $ fitted . values , alternative = " t " ) # H1 / Son
diferentes si p < 0.05 se acepta H1 .
56 t . test ( m4 $ fitted . values , m5 $ fitted . values , alternative = " g " ) # H1 / a )
es mayor si p < 0.05 se acepta H1 .
57 t . test ( m4 $ fitted . values , m5 $ fitted . values , alternative = " l " ) # H1 / a )
es menor si p < 0.05 se acepta H1 .
58 # ### Prueba de los rangos con signo de Wilcoxon ####
59 # ## Conexiones Exitosas ###
60 wilcox . test ( m4 $ fitted . values , m5 $ fitted . values )
61 # #### Normalidad Datos ####
62 # ## Conexiones Exitosas ###
63 shapiro . test ( m4 $ fitted . values )
79
65 # ### M4 , M5 THR ####
68 # # Anova Test ###
69 thr = c ( m4 $ fitted . values )
70 thr = append ( x = thr , values = m5 $ fitted . values , after =
length ( m4 $ fitted . values ) )
71 thr = as . matrix ( thr )
72 tecnologia = c ( rep ( " LEGACY " ,20) , rep ( " SDN " ,20) )
73 data _ anova = data . frame ( thr , tecnologia )
74 res _ anova = aov ( thr ~ tecnologia , data = data _ anova ) # H0 = medias son
iguales H1 = alguna diferencia . p <0.05 se acepta H1
75 summary ( res _ anova )
76 # ## Test de Hipotesis medias ###
77 t . test ( m4 $ fitted . values , m5 $ fitted . values , alternative = " t " ) # H1 / Son
diferentes si p < 0.05 se acepta H1 .
78 t . test ( m4 $ fitted . values , m5 $ fitted . values , alternative = " g " ) # H1 / a )
es mayor si p < 0.05 se acepta H1 .
79 t . test ( m4 $ fitted . values , m5 $ fitted . values , alternative = " l " ) # H1 / a )
es menor si p < 0.05 se acepta H1 .
80 # ### Prueba de los rangos con signo de Wilcoxon ####
81 # ## Throughput ###
82 wilcox . test ( m4 $ fitted . values , m5 $ fitted . values )
83 # #### Normalidad Datos ####
84 # ## Throughput ###
codigo/2.R
4. Código para generación de Grafos

1 # ######
2 # Script para generacion de Grafos
4 # Fecha :24 / 01 / 2017
5 # ######
6 # Carga de Librerias
7 library ( igraph )
8 rm ( list = ls () )
9 # Se crea Vertices y arcos
10 net <- graph . formula (1 -2 , 2 -4 , 3 -4 , 4 -5 , 4 -6 , 7 -5)
11 # Se coloca nombres a los Vertices
12 V ( net ) [ c (1 ,2 ,3 ,4 ,5 ,6 ,7) ] $ name <- c ( " Internet " , " Router " ," Switch SDN
1 " , " Balanceador de Carga " , " Switch SDN 2 " ," Web Server 1 " , " Web
Server 2 " )
13 # Se da atributos a Vertices
14 V ( net ) $ type = " Dispositivos de Red "
80
15 V ( net ) [ c ( " Switch SDN 2 " , " Switch SDN 1 " ) ] $ type = " Switch SDN "
16 V ( net ) [ c ( " Router " ) ] $ type = " Router "
17 V ( net ) [ c ( " Balanceador de Carga " , " Web Server 1 " ," Web Server
2 " ) ] $ type = " Maquina Virtualizada "
18 V ( net ) $ type
19 # Se da atributos a Arcos
20 E ( net ) $ name = c ( " e1 " ," e2 " ," e3 " ," e4 " ," e5 " ," e6 " )
21 E ( net ) $ type = " enlace "
22 E ( net ) [ c ( " e1 " ) ] $ thr =271
23 E ( net ) [ c ( " e2 " ) ] $ thr =268
24 E ( net ) [ c ( " e3 " ) ] $ thr =270
25 E ( net ) [ c ( " e4 " ) ] $ thr =130
26 E ( net ) [ c ( " e5 " ) ] $ thr =132
27 E ( net ) [ c ( " e6 " ) ] $ thr =135
28 E ( net ) $ thr
29 E ( net ) [ c ( " e1 " ) ] $ dl =550
30 E ( net ) [ c ( " e2 " ) ] $ dl =560
31 E ( net ) [ c ( " e3 " ) ] $ dl =500
32 E ( net ) [ c ( " e4 " ) ] $ dl =570
33 E ( net ) [ c ( " e5 " ) ] $ dl =510
34 E ( net ) [ c ( " e6 " ) ] $ dl =540
35 E ( net ) $ dl
36 E ( net ) [ c ( " e1 " ) ] $ pl =18.01
37 E ( net ) [ c ( " e2 " ) ] $ pl =18.05
38 E ( net ) [ c ( " e3 " ) ] $ pl =18.02
39 E ( net ) [ c ( " e4 " ) ] $ pl =18.07
40 E ( net ) [ c ( " e5 " ) ] $ pl =18.10
41 E ( net ) [ c ( " e6 " ) ] $ pl =18.13
42 E ( net ) $ pl
43 V ( net ) $ shape = " square "
44 V ( net ) $ color = " green "
45 V ( net ) [ c ( " Internet " ," Router " ," Switch SDN 2 " , " Switch SDN 1 " ) ] $ shape
= " circle "
46 V ( net ) [ c ( " Internet " ," Router " ," Switch SDN 2 " , " Switch SDN 1 " ) ] $ color
= " tomato "
47 V ( net ) $ size = 30
48 V ( net ) $ size2 = 30
49
50 plot ( net )
51 l = matrix ( c (15 ,60 ,60 ,15 ,90 ,60 ,90 ,90 ,90 ,45 ,45 ,45 ,0 ,0) , ncol = 2)
52 l
53 colrs <- c ( " green " , " tomato " )
54 # Ancho de arco en funcion de Throughput #
55 E ( net ) $ width = floor (3 * as . numeric ( E ( net ) $ thr ) / 271)
56 E ( net ) $ width
57 # Generar grafico
58 pdf ( " Grafo . pdf " , width = 6 , height = 4 , paper = ’ special ’)
60 plot ( net , layout =l , main = " Red representada con Vertices y
Arcos " , vertex . label . color = " black " , vertex . label . cex =0.65 ,
81
edge . color = " black " , vertex . label . dist =2)
61 legend ( x = -1.5 , y = -1 , c ( " Maquinas Virtualizadas " ," Dispositivos de
Red " ) , pch = c (22 ,21) , col = " #777777 " , pt . bg = colrs , pt . cex =1 ,
cex =0.6 , bty = " n " , ncol =1)
62 dev . off ()
codigo/4.R
82
83
C. Tipo de Modelo y parámetros de cada muestra
Tabla 6.1: Tipo de Modelo para cada repetición del grupo sin SDN, sin condiciones
adversas de red y acceso WLAN
# Tipo de Serie de
p d q P D Q AIC
de prueba Prueba Tiempo
1.1 Throughput SARIMA 0 1 2 4 0 5 6561
1.2 Delay SARIMA 0 1 4 3 0 2 2572.27
2.1 Throughput SARIMA 1 1 2 4 0 5 6566.09
2.2 Delay SARIMA 2 1 2 0 0 3 2626.17
3.2 Delay ARIMA 1 1 1 0 0 0 2445.52
4.2 Delay ARIMA 1 1 1 0 0 0 2558.41
5.2 Delay ARIMA 1 1 2 0 0 0 2503.62
6.2 Delay LINEAL 0 0 0 0 0 0 2708.33
7.2 Delay SARIMA 3 0 4 0 1 5 5409.61
8.2 Delay ARIMA 1 1 5 0 0 0 3115.43
9.2 Delay ARIMA 1 1 2 0 0 0 2579.14
10.2 Delay ARIMA 1 1 3 0 0 0 3579.06
11.2 Delay LINEAL 0 0 0 0 0 0 2963.94
12.1 Throughput ARIMA 2 1 1 0 0 0 6655.11
12.2 Delay SARIMA 5 0 5 0 1 5 3143.54
13.2 Delay SARIMA 1 1 4 2 0 5 2751.02
14.2 Delay ARIMA 1 1 4 0 0 0 3451.56
15.2 Delay SARIMA 1 1 1 4 0 5 2880.96
16.2 Delay SARIMA 1 1 1 5 0 5 3914.6
17.2 Delay SARIMA 1 1 5 2 0 2 4507.65
18.2 Delay ARIMA 1 1 1 0 0 0 4373.98
19.2 Delay SARIMA 2 1 1 4 0 3 4775.69
20.2 Delay SARIMA 1 1 2 3 0 3 4129.75
84
Tabla 6.2: Tipo de Modelo para cada repetición del grupo con SDN, sin condiciones
# Tipo de Serie de
p d q P D Q AIC
1.2 Delay SARIMA 1 1 2 3 0 4 3258.73
2.2 Delay SARIMA 3 0 3 4 0 5 2905.98
3.2 Delay ARIMA 0 1 3 0 0 0 2708.67
4.2 Delay ARIMA 1 1 2 0 0 0 3002.46
5.2 Delay LINEAL 0 0 0 0 0 0 2639.29
6.2 Delay SARIMA 0 1 4 4 0 0 2523.9
7.2 Delay SARIMA 0 1 5 3 0 2 2554.55
8.2 Delay SARIMA 0 1 1 3 0 5 2681.83
9.2 Delay LINEAL 0 0 0 0 0 0 2387.92
10.2 Delay SARIMA 1 1 3 4 0 1 2905.32
11.2 Delay SARIMA 2 1 1 3 0 5 3295.63
12.2 Delay LINEAL 0 0 0 0 0 0 2993.36
13.2 Delay LINEAL 0 0 0 0 0 0 3263.59
14.2 Delay SARIMA 1 1 4 4 0 0 3107.98
15.2 Delay ARIMA 0 1 5 0 0 0 4132.62
16.2 Delay SARIMA 2 1 3 1 0 5 3962.51
17.2 Delay ARIMA 2 1 1 0 0 0 3963.3
18.2 Delay ARIMA 0 1 2 0 0 0 4230.62
19.2 Delay SARIMA 0 1 3 3 0 0 4262.96
20.2 Delay ARIMA 0 1 2 0 0 0 4765.94
85
Tabla 6.3: Tipo de Modelo para cada repetición del grupo sin SDN, con condiciones
# Tipo de Serie de
p d q P D Q AIC
1.2 Delay ARIMA 0 1 1 0 0 0 7112.81
2.2 Delay ARIMA 0 1 1 0 0 0 7114.68
3.2 Delay SARIMA 0 1 1 2 0 3 7062.3
4.2 Delay ARIMA 0 1 1 0 0 0 7114.59
5.2 Delay ARIMA 0 1 1 0 0 0 7063.83
6.2 Delay SARIMA 0 1 1 1 0 1 7107.59
7.2 Delay SARIMA 0 1 1 1 0 1 7182.04
8.2 Delay ARIMA 0 1 1 0 0 0 7073.54
9.2 Delay SARIMA 0 1 1 3 0 3 7008.14
10.2 Delay ARIMA 0 1 1 0 0 0 7115.35
11.2 Delay SARIMA 1 1 4 3 0 3 7326.96
12.2 Delay ARIMA 0 1 1 0 0 0 7168.18
13.2 Delay SARIMA 0 1 1 1 0 1 7134.93
14.2 Delay SARIMA 0 1 2 2 0 3 7133.37
15.2 Delay ARIMA 0 1 1 0 0 0 7165.84
16.2 Delay SARIMA 0 1 1 2 0 3 7086.67
17.2 Delay ARIMA 0 1 1 0 0 0 7106.85
18.2 Delay ARIMA 1 1 2 0 0 0 7079.09
19.2 Delay ARIMA 0 1 1 0 0 0 7061.68
20.2 Delay ARIMA 0 1 1 0 0 0 7140.28
86
Tabla 6.4: Tipo de Modelo para cada repetición del grupo con SDN, con condiciones
# Tipo de Serie de
p d q P D Q AIC
1.2 Delay ARIMA 0 1 1 0 0 0 7111.49
2.2 Delay ARIMA 1 1 5 0 0 0 7288.5
3.2 Delay ARIMA 0 1 5 0 0 0 7698.81
4.2 Delay SARIMA 0 1 3 3 0 4 7623.41
5.2 Delay SARIMA 0 1 3 2 0 0 7376.71
6.2 Delay ARIMA 0 1 4 0 0 0 8097.04
7.2 Delay ARIMA 1 1 3 0 0 0 7531.05
8.2 Delay ARIMA 0 1 1 0 0 0 7445.08
9.2 Delay SARIMA 0 1 4 4 0 5 7483.61
10.2 Delay ARIMA 0 1 4 0 0 0 7316.46
11.2 Delay SARIMA 0 1 1 3 0 4 7107.39
12.2 Delay SARIMA 0 1 5 3 0 1 7327.89
13.2 Delay SARIMA 0 1 1 2 0 4 7058.21
14.2 Delay ARIMA 0 1 1 0 0 0 7132.45
15.2 Delay ARIMA 1 1 3 0 0 0 7176.04
16.2 Delay ARIMA 0 1 1 0 0 0 7116.52
17.2 Delay SARIMA 0 1 1 3 0 3 7136.49
18.2 Delay SARIMA 0 1 1 1 0 1 7091.41
19.2 Delay ARIMA 0 1 1 0 0 0 7112.69
20.2 Delay SARIMA 0 1 3 3 0 1 7053.08
87
Tabla 6.5: Tipo de Modelo para cada repetición del grupo sin SDN, sin condiciones
adversas de red y acceso LTE
# Tipo de Serie de
p d q P D Q AIC
1.2 Delay ARIMA 2 1 1 0 0 0 3951.59
2.2 Delay SARIMA 1 1 2 3 0 2 3626.74
3.2 Delay ARIMA 1 1 1 0 0 0 3575.4
4.2 Delay ARIMA 2 1 1 0 0 0 3721.53
5.2 Delay SARIMA 1 1 1 3 0 4 4564.68
6.2 Delay ARIMA 1 1 4 0 0 0 5670.91
7.2 Delay SARIMA 1 1 2 3 0 3 4602.45
8.2 Delay ARIMA 2 1 1 0 0 0 4331.69
9.2 Delay SARIMA 0 1 3 1 0 3 3139.76
10.2 Delay SARIMA 2 1 1 4 0 0 3267.72
11.2 Delay ARIMA 1 1 2 0 0 0 3370.3
12.2 Delay ARIMA 0 1 2 0 0 0 5333.71
13.2 Delay ARIMA 1 1 1 0 0 0 3598.47
14.2 Delay ARIMA 2 1 1 0 0 0 2768.24
15.2 Delay LINEAL 0 0 0 0 0 0 2716.87
16.2 Delay LINEAL 0 0 0 0 0 0 2706.31
17.2 Delay LINEAL 0 0 0 0 0 0 2759.11
18.2 Delay ARIMA 1 1 2 0 0 0 2856.05
19.2 Delay ARIMA 2 1 1 0 0 0 2619.35
20.2 Delay LINEAL 0 0 0 0 0 0 2551.41
88
Tabla 6.6: Tipo de Modelo para cada repetición del grupo con SDN, sin condiciones
# Tipo de Serie de
p d q P D Q AIC
1.2 Delay SARIMA 1 1 2 5 0 5 3785.36
2.2 Delay LINEAL 0 0 0 0 0 0 2337.38
3.2 Delay LINEAL 0 0 0 0 0 0 2236.3
4.2 Delay SARIMA 0 1 3 0 0 4 4751.36
5.2 Delay SARIMA 1 1 2 4 0 4 2506.34
6.2 Delay SARIMA 0 1 4 2 0 0 2418.69
7.2 Delay ARIMA 1 1 2 0 0 0 4833.79
8.2 Delay SARIMA 5 0 4 0 1 0 4605.24
9.2 Delay LINEAL 0 0 0 0 0 0 2364.34
10.2 Delay SARIMA 2 1 1 0 0 1 2206.06
11.2 Delay LINEAL 0 0 0 0 0 0 2422.22
12.2 Delay LINEAL 0 0 0 0 0 0 2399.32
13.2 Delay LINEAL 0 0 0 0 0 0 2353.33
14.2 Delay LINEAL 0 0 0 0 0 0 2534.29
15.2 Delay SARIMA 1 1 2 2 0 3 2521.66
16.2 Delay SARIMA 0 1 4 2 0 0 2323.84
17.2 Delay SARIMA 1 1 1 5 0 4 2388.03
18.2 Delay SARIMA 1 1 1 4 0 4 2832.92
19.2 Delay SARIMA 3 0 4 1 1 0 2546.81
20.2 Delay LINEAL 0 0 0 0 0 0 2613.77
89
Tabla 6.7: Tipo de Modelo para cada repetición del grupo sin SDN, con condiciones
# Tipo de Serie de
p d q P D Q AIC
1.2 Delay SARIMA 0 1 1 4 0 3 7027.79
2.2 Delay ARIMA 1 1 1 0 0 0 7135.02
3.2 Delay ARIMA 0 1 1 0 0 0 7120.59
4.2 Delay ARIMA 0 1 1 0 0 0 7085.44
5.2 Delay ARIMA 1 1 5 0 0 0 7100.83
6.2 Delay SARIMA 0 1 1 1 0 1 7074.95
7.2 Delay SARIMA 0 1 1 2 0 3 7049.35
8.2 Delay ARIMA 1 1 2 0 0 0 7100.48
9.2 Delay ARIMA 0 1 1 0 0 0 7123.87
10.2 Delay SARIMA 0 1 2 5 0 5 7050.81
11.2 Delay ARIMA 0 1 1 0 0 0 7038.92
12.2 Delay SARIMA 0 1 1 1 0 1 7056.18
13.2 Delay ARIMA 0 1 1 0 0 0 7087.78
14.2 Delay ARIMA 0 1 1 0 0 0 7066.03
15.2 Delay ARIMA 0 1 1 0 0 0 7149.79
16.2 Delay ARIMA 0 1 5 0 0 0 7078.63
17.2 Delay ARIMA 0 1 1 0 0 0 7137.49
18.2 Delay ARIMA 0 1 1 0 0 0 7101.92
19.2 Delay ARIMA 0 1 1 0 0 0 7092.54
20.2 Delay SARIMA 0 1 3 4 0 2 7089.05
90
Tabla 6.8: Tipo de Modelo para cada repetición del grupo con SDN, con condiciones
# Tipo de Serie de
p d q P D Q AIC
1.2 Delay ARIMA 0 1 1 0 0 0 7123.12
2.2 Delay SARIMA 0 1 1 1 0 1 7081.62
3.2 Delay SARIMA 0 1 1 4 0 5 7151.16
4.2 Delay SARIMA 0 1 3 4 0 0 7078.38
5.2 Delay ARIMA 0 1 1 0 0 0 7143.3
6.2 Delay ARIMA 0 1 1 0 0 0 7082.82
7.2 Delay SARIMA 0 1 1 5 0 3 7107.49
8.2 Delay ARIMA 0 1 1 0 0 0 7064.04
9.2 Delay SARIMA 0 1 1 3 0 3 7188.07
10.2 Delay ARIMA 0 1 1 0 0 0 7041.29
11.2 Delay ARIMA 0 1 1 0 0 0 7072.53
12.2 Delay SARIMA 2 1 1 4 0 1 7119.21
13.2 Delay SARIMA 1 1 5 4 0 2 7008.49
14.2 Delay ARIMA 0 1 1 0 0 0 7194.55
15.2 Delay ARIMA 0 1 1 0 0 0 7105.74
16.2 Delay SARIMA 1 1 3 1 0 0 7229.36
17.2 Delay SARIMA 0 1 1 3 0 3 7220.78
18.2 Delay SARIMA 0 1 1 5 0 5 7108.13
19.2 Delay ARIMA 0 1 2 0 0 0 7187.1
20.2 Delay ARIMA 0 1 1 0 0 0 7149.23
91
D. Estadística Descriptiva
Tabla 6.9: Estadística Descriptiva de pruebas con SDN, sin condiciones adversas de red y
acceso WLAN
Desviación Rango
Media 0% 25 % 50 % 75 % 100 % n
Conexiones
13631.16 120.26 187.5 13411 13521.5 13657 13709 13782 20
Exitosas
Conexiones
33.21 66.92 38 0 0 0 38 257 20
Fallidas
Throuhput (kbps) 268.46 1.79 1.85 264.36 267.83 269.01 269.68 270.72 20
Delay (ms) 20.1 2.71 2.62 10.94 18.97 20.2 21.59 23.27 20
Tabla 6.10: Correlación de pruebas con SDN, sin condiciones adversas de red y acceso
WLAN
Throughput Delay
Exitosas Fallidas
Conexiones
1 -0.79 0.54 -0.53
Exitosas
Conexiones
-0.79 1 -0.23 0.52
Fallidas
Throughput 0.54 -0.23 1 -0.16
Delay -0.53 0.52 -0.16 1
92
14
5
4
0 2 4 6 8 10
Frecuencia
Frecuencia
3
2
1
0
13400 13500 13600 13700 13800 0 50 100 150 200 250 300
(a) (b)
8
8
6
6
Frecuencia
Frecuencia
4
4
2
2
0
264 265 266 267 268 269 270 271 10 12 14 16 18 20 22 24
(c) (d)
Figura 6.1: Histogramas de pruebas con SDN, sin condiciones adversas de red y acceso
WLAN
Tabla 6.11: Estadística Descriptiva de pruebas sin SDN, con condiciones adversas de red y
acceso WLAN
Desviación Rango
Media 0% 25 % 50 % 75 % 100 % n
Conexiones
11989.95 172.03 51.5 11303 11996.25 12031 12047.75 12148 20
Exitosas
Conexiones
1157 244.93 75.25 1008 1067 1116 1142.25 2171 20
Fallidas
Throuhput (kbps) 266.68 2.62 2.08 263.9 265.31 266.02 267.38 276.12 20
Delay (ms) 543.18 3.99 4.29 535.87 540.64 543.28 544.93 550.24 20
93
Tabla 6.12: Correlación de pruebas sin SDN, con condiciones adversas de red y acceso
WLAN
Throughput Delay
Exitosas Fallidas
Conexiones
1.00 -0.95 -0.70 -0.01
Exitosas
Conexiones
-0.95 1.00 0.88 -0.02
Fallidas
Throughput -0.70 0.88 1.00 -0.05
Delay -0.01 -0.02 -0.05 1.00
15
15
Frecuencia
Frecuencia
10
10
5
5
0
11200 11400 11600 11800 12000 12200 1000 1200 1400 1600 1800 2000 2200
(a) (b)
8
0 1 2 3 4 5 6 7
6
Frecuencia
Frecuencia
4
2
0
265 270 275 535 540 545 550
(c) (d)
Figura 6.2: Histogramas de pruebas sin SDN, con condiciones adversas de red y acceso
WLAN
94
Tabla 6.13: Estadística Descriptiva de pruebas sin SDN, sin condiciones adversas de red y
acceso LTE
Desviación Rango
Media 0% 25 % 50 % 75 % 100 % n
Conexiones
13451.2 71.17 93.75 13316 13398 13437 13491.75 13584 20
Exitosas
Conexiones
2.75 12.3 0 0 0 0 0 55 20
Fallidas
Throuhput (kbps) 264.11 1.18 1.41 262 263.32 264.19 264.73 266.19 20
Delay (ms) 20.94 3.05 4.15 18.08 18.45 19.57 22.6 26.94 20
Tabla 6.14: Correlación de pruebas sin SDN, sin condiciones adversas de red y acceso LTE
Troughput Delay
Exitosas Fallidas
Conexiones
1.00 -0.45 0.90 -0.60
Exitosas
Conexiones
-0.45 1.00 -0.41 0.42
Fallidas
Throughput 0.90 -0.41 1.00 -0.56
Delay -0.60 0.42 -0.56 1.00
6
5
15
Frecuencia
Frecuencia
4
10
3
2
5
1
0
13300 13350 13400 13450 13500 13550 13600 0 10 20 30 40 50 60
(a) (b)
8 10 12
5
4
Frecuencia
Frecuencia
3
6
2
4
1
2
0
262 263 264 265 266 18 20 22 24 26 28
(c) (d)
Figura 6.3: Histogramas de pruebas sin SDN, sin condiciones adversas de red y acceso LTE
95
Tabla 6.15: Estadística Descriptiva de pruebas sin SDN, con condiciones adversas de red y
acceso LTE
Desviación Rango
Media 0% 25 % 50 % 75 % 100 % n
Conexiones
11883.85 74 66.75 11727 11859 11877.5 11925.75 12034 20
Exitosas
Conexiones
1136.05 55.98 60.75 1026 1105.5 1146 1166.25 1222 20
Fallidas
Throuhput (kbps) 263.57 1.17 1.7 261.74 262.68 263.53 264.38 265.82 20
Delay (ms) 539.48 4.75 5.52 529.57 537.08 539.88 542.6 550.31 20
Tabla 6.16: Correlación de pruebas sin SDN, con condiciones adversas de red y acceso LTE
Troughput Delay
Exitosas Fallidas
Conexiones
1.00 -0.49 0.68 -0.42
Exitosas
Conexiones
-0.49 1.00 0.19 0.63
Fallidas
Throughput 0.68 0.19 1.00 0.09
Delay -0.42 0.63 0.09 1.00
0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7
Frecuencia
Frecuencia
11700 11750 11800 11850 11900 11950 12000 12050 1000 1050 1100 1150 1200 1250
(a) (b)
4
8
3
Frecuencia
Frecuencia
6
2
4
1
2
0
262 263 264 265 266 525 530 535 540 545 550 555
(c) (d)
Figura 6.4: Histogramas de pruebas con SDN, sin condiciones adversas de red y acceso LTE
96
97

Análisis de Servicios Web en Redes SDN

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Análisis de Servicios Web en Redes SDN

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE CHILE

FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS

ANÁLISIS DE SERVICIOS WEB EN REDES SDN

TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN INGENIERÍA DE REDES DE

ANDRÉS FERNANDO CÓRDOVA MOLINA

ANÁLISIS DE SERVICIOS WEB EN REDES SDN

Antes de la ejecución de las pruebas se determina mediante estadística descriptiva, los

El principal agradecimiento es para mi familia y novia Jéssica Romero, por no permitir

Al gobierno ecuatoriano por brindarme la beca de estudio.

A mis profesores que pusieron su empeño en entregarnos conocimientos de calidad.

3.1. Herramientas Seleccionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1. Operación de SDN [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1. GNS3 con arquitectura de red basada en SDN . . . . . . . . . . . . . . . . . 17

4.1. Flujo de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

En la primera mitad del siglo XX las comunicaciones eran principalmente telefóni-

La idea de Baran fue adoptada por el Departamento de Defensa (DOD’s) y estuvo

En conjunto con el uso de Internet, el número de textitdata centers hospedando servido-

2.1. Objetivo principal

2.2. Objetivos específicos

2.2.1. Estudio del marco teórico, referente a la hipótesis planteada.

2.2.2. Establecer el hardware y software necesario para el experimento.

2.2.3. Diseñar y Construir los experimentos.

2.2.4. Realizar el número de pruebas necesarias.

2.2.5. Capturar los datos resultantes.

2.2.6. Analizar con base estadística los resultados.

3. Tipo de investigación y metodología

A continuación, se resumen las etapas de la metodología utilizada:

Diseño de los experimentos: se calcula en base a un estudio estadístico, los límites de

En el presente capítulo se describen los conceptos de SDN, servidores web, balanceo de

2.1. Software Defined Network

2.2. Funcionamiento de SDN

flows flows flows

Figura 2.1: Operación de SDN [1]

2.2.1. Interfaces Northbound y Southbound

2.2.2. Tablas de Flujo (Flow Tables)

Una de las principales características de SDN es la separación de sus planos. El plano de

2.2.4. Dispositivo simple y control descentralizado

Al separar el plano de datos del plano de control se obtienen dispositivos simples y un

En la actualidad existen varios controladores en el mercado, como por ejemplo: OpenDay-

2.2.5. Controlador SDN

2.2.6. Aplicaciones SDN

Funcionan sobre el controlador, comunicándose con la red mediante la interfaz northbound.

2.2.7. Dispositivos SDN

La interfaz de comunicación con el controlador es la ya mencionada northbound mientras

2.2.8. Dispositivo basado en Software

Un dispositivo SDN basado en software es la forma más sencilla de producir un dispositivo

La principal ventaja de un dispositivo SDN basado en hardware es que trabaja a una

2.2.10. Operación de SDN

Las Flow Tables, se encuentran en los dispositivos. Cuando se recibe un paquete, se la

El controlador es el encargado de abstraer la red de los dispositivos SDN, proveer a las

Un servidor web, es un programa que está a la escucha de un determinado puerto a la

2.3.1. Desempeño de un servidor Web

Es importante definir los parámetros utilizados para determinar el desempeño de un ser-

En el presente trabajo, se medirá el número de conexiones exitosas que detecta la herra-

Una conexión exitosa es detectada cuando dentro de la cabecera HTTP, se encuentra el

2.4. Balanceo de Carga

El crecimiento vertical, se refiere a la adquisición de nuevo hardware, con mejores presta-

Al dividir el trabajo de un computador entre varios, se obtiene un mayor rendimiento ya

2. Priority: se asigna tráfico al servidor por defecto mientras esté disponible.

4. Persistence: se mantiene la conexión con un servidor hasta que se finalice la sesión.

6. Roud robbin capa 4: en un conjunto de web servers, se redirige la primera conexión al

9. SDN Adaptativo: normalmente el balanceo de carga trabaja analizando la capa 4 o capa

2.5. Tecnologías de Acceso