Teoría de la Señal, Telemática y Comunicaciones: Una aproximación al conocimiento a través de los Trabajos Fin de Grado y Máster

Teoría de la Señal, Telemática y Comunicaciones: Una aproximación al conocimiento a través de los Trabajos Fin de Grado y Máster Curso 2014/2015 Luz García Martínez Jorge Navarro Ortiz Editores Teoría de la Señal, Telemática y Comunicaciones: Una aproximación al conocimiento a través de los Trabajos Fin de Grado y Máster Curso 2014 / 2015 Editores: Luz García Martínez Jorge Navarro Ortiz Departamento de Teoría de la Señal, Telemática y Comunicaciones ISBN-13: 978-84-617-5449-6 Editores: Luz García Martínez y Jorge Navarro Ortiz (Dpto. Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada) El contenido de los trabajos que componen este libro es propiedad de los autores de los mismos y está protegido por los derechos que se recogen en la Ley de Propiedad Intelectual. Los autores autorizan la edición de este libro y su distribución, sin que esto, en ningún caso, implique una cesión a favor de la Universidad de Granada de cualesquiera derechos de propiedad intelectual sobre los contenidos de los trabajos. Ni la Universidad de Granada, ni los editores, serán responsables de aquellos actos que vulneren los derechos de propiedad intelectual sobre estos trabajos. © 2016, los autores Portada: Pilar Andrés Maldonado Maquetación: Luz García Martínez y Jorge Navarro Ortiz Presentación El Real Decreto (RD 1393/2007) que regula la ordenación de las enseñanzas oficiales, establece que tanto el Trabajo Fin de Grado (TFG) como el Trabajo Fin de Máster (TFM) deben de estar orientados a la evaluación de competencias asociadas al título. Para cubrir la oferta formativa, el Dpto. de Teoría de la Señal, Telemática y Comunicaciones, que imparte docencia en el grado de Ingeniería de Tecnologías de Telecomunicación y en el máster de Ingeniería de Telecomunicación, oferta cada año a los alumnos un considerable número de posibles trabajos en los campos del procesado de señal, redes, telemática o comunicaciones. En esta línea, y con el objetivo de motivar al alumnado el Dpto. creó los premios a los TFG y TFM para aquellos proyectos que se realizan y se presentan en el seno del Dpto. Este libro, titulado “Teoría de la Señal, Telemática y Comunicaciones: una aproximación al conocimiento a través de los Trabajos Fin de Grado y Fin de Máster”, recoge los resúmenes de los mejores TFG y TFM presentados a la tercera convocatoria de los premios correspondiente al curso 2014-2015. Para esta edición, se han seleccionado un total de 13 trabajos que abarcan el campo del procesado de señal, las comunicaciones móviles, las redes de ordenadores y la ciberseguridad; estos trabajos constituyen un buen ejemplo del desempeño realizado por los alumnos que cursan sus estudios de Ingeniería de Telecomunicación en la Universidad de Granada. Para finalizar, sirvan también estas líneas para agradecer a los alumnos participantes y a los profesores la labor que realizan que nos permite seguir avanzando con el objetivo de mejorar la sociedad. M. Carmen Benítez Ortúzar Directora del Dpto. de Teoría de la Señal, Telemática y Comunicaciones ETS Ingenierías Informática y de Telecomunicación Universidad Granada Índice de contribuciones Áreas de Teoría de la Señal y Comunicaciones e Ingeniería Telemática Comunicaciones móviles Prototipo de estación base GSM haciendo uso de OpenBTS .................................... 3 A. González Garrido (tutores J. Navarro Ortiz y J.C. Segura Luna) Área de Teoría de la Señal y Comunicaciones Procesado de señales bioquímicas Clasificación de proteínas representadas mediante señales extraídas de índices bioquímicos .............................................................................................................. 11 A.O. Villegas Morcillo (tutores V. Sánchez Calle y A.M. Peinado Herreros) Procesado de señales sísmicas Application of the method of instantaneous power in automatic picking of synthetic explosions in the experiment TOMO-ETNA ............................................................. 17 F.J. Cuberos Muñoz (tutoras M.C. Benítez Ortúzar y L. García Martínez) Picking de terremotos sismo-volcánicos y su aplicación a la tomografía computerizada en el experimento TOMO-ETNA ...................................................... 23 D. García Sánchez (tutoras M.C. Benítez Ortúzar y L. García Martínez) Uso de métodos de polarización instantánea avanzados para la mejora de la fase de llegada de señales sísmicas .................................................................................... 29 I. Vico Triviño (tutoras M.C. Benítez Ortúzar y L. García Martínez) Área de Ingeniería Telemática Aplicaciones en red Diseño de un juego con requisitos de tiempo real para redes móviles..................... 37 P. Peña Martínez (tutores J.J. Ramos Muñoz y J.M. López Soler) Implementación de una aplicación cliente para Chromecast ................................... 43 I. Herrera López (tutor J. Navarro Ortiz) Redes definidas por software Análisis de redes SDN utilizando Mininet e implementación de un Deep Packet Inspector .................................................................................................................. 49 M. Sánchez López (tutor J. Navarro Ortiz) Diseño y evaluación de un servicio OpenFlow de provisión de Calidad de Experiencia sobre Mininet ........................................................................................ 55 C.A. Prieto Sánchez (tutor J.J. Ramos Muñoz) Redes móviles Soporte para comunicaciones máquina a máquina en sistemas 5G ........................ 61 P. Andrés Maldonado (tutor P. Ameigeiras Gutiérrez) Seguridad en redes Análisis de malware en Smart TV: ataques y defensas ........................................... 67 J. López Arredondo (tutor P. García Teodoro) Diseño e implementación de retos de seguridad en redes de telecomunicación en el laboratorio 3.7 con fines docentes ........................................................................... 73 F. López Pérez (tutor R.A. Rodríguez Gómez) MEDA-toolbox: interfaz gráfica en MATLAB para la detección de anomalías en red ............................................................................................................................ 79 P. Sánchez Robles (tutor J. Camacho Páez) uso de los protocolos RTP (Real Time Protocol) para la transmisión del audio de las llamadas y del protocolo SIP (Session Initiation Protocol) para los mensajes entre los diferentes elementos de la red. En nuestro caso, se incluye en el paquete de OpenBTS de forma que su configuración sea mucho más sencilla. Asterisk está basada en dos planos, los usuarios y los planes de llamadas. La gestión de usuarios se definen los usuarios que tienen permiso de acceso así como las necesidades de cada uno dentro de la centralita de llamadas. En nuestro caso, el servicio OpenBTS es un usuario más de la centralita, de forma que tiene que estar dicho usuario configurado en el archivo de usuarios. Otro usuario que se ha configurado, aunque no es obligatorio disponer de él, es el acceso a la red pública de telefonía mediante un servicio troncal de VoIP, dicho servicio contratado con la empresa Netelip, es un usuario más en nuestra central de conmutación y nos permite realizar llamadas con nuestros teléfonos móviles a teléfonos fuera de nuestra red. La gestión de los planes de llamadas se organizan en lo que se llaman “contextos”. Cada usuario dispone de un contexto asignado, y es dicho contexto el que determina qué hacer cuando el usuario realiza una llamada, en otras palabras, los contextos indican de forma secuencial las acciones de la centralita cuando el usuario marca una extensión determinada. E. Análisis del intercambio de mensajes gracias a OsmocomBB El sistema OsmocomBB es un conjunto de software, firmware y hardware con la capacidad de crear un teléfono móvil virtual. Hace uso de un teléfono móvil modelo Motorola C123 al cual se le ha modificado el firmware para transmitir las tramas directamente al ordenador, de forma que sea el software instalado en el ordenador, el que realiza todo el procesado de la señal. De esta forma, al controlar todo el sistema mediante el software, se puede generar un archivo con el intercambio de mensajes entre una estación base GSM y un teléfono móvil para analizarlos a posteriori. IV. RESULTADOS OBTENIDOS En este apartado se van a mostrar los resultados obtenidos tras el desarrollo del prototipo de estación base. Comenzaremos con el análisis de los posibles canales libres en nuestra zona de pruebas, seguiremos con las diferentes medidas RF realizadas al prototipo, para finalizar con el análisis de los mensajes intercambiados entre los diferentes elementos de la red. A. Canales libres en la zona de test. Antes de comenzar a radiar en la banda GSM, se ha realizado un análisis de los canales que se encuentran libres en nuestra zona de test, en el edificio del CITIC (Centro de Investigación de Tecnologías de la Información y Comunicaciones). Para ello se ha buscado la información de la localización de las antenas, y sus características para los diferentes operadores de telecomunicaciones en la zona. Dicha información se encuentra en la web: https://geoportal.minetur.gob.es/VCTEL/vcne.do Tras analizar la información publicada en dicha web, concluimos que la zona de baja frecuencia en la banda GSM es la que se encuentra más libre de señal. Decidimos utilizar el canal 2 para GSM900 y el canal 512 para DCS1800. B. Medidas RF Para las medidas de RF se ha hecho uso de un analizador vectorial modelo EXA del fabricante Agilent. Dispone de un ancho de banda de 3.6GHz, suficiente para cubrir las bandas GSM de nuestro interés. Las medidas tomadas para ambas bandas son: Potencia del canal: Se mide la potencia de un slot temporal para un transmisor que emita el canal lógico de difusión o BCCH. Potencia en canales adyacentes: La finalidad de este test es la de asegurar que para un transmisor no interfiere ni introduce ruido por encima de un nivel máximo permitido. Ancho de banda ocupado: Devuelve en qué ancho de banda se concentra el 99% de la potencia de transmisión. Mascara de espectro de emisión: El objetivo de esta medida consiste en verificar si la potencia de cualquier emisión del transmisor no excede los niveles específicos. Los resultados de las medidas se pueden encontrar en la memoria completa, con mucho más detalle, aquí solo comentar que las medidas son acordes al estándar GSM, según están definidos los test en [1]. C. Análisis de los mensajes intercambiados en diferentes escenarios. El análisis de los mensajes intercambiados entre los diferentes elementos de la red se ha realizado con la herramienta Wireshark, ya que los archivos con las trazas de los mensajes añaden una cabecera a los mismos llamada GSMTAP, que es capaz de interpretar Wireshark. A continuación mostraremos algunos escenarios en los que se han analizado los mensajes. Comenzamos por analizar los mensajes que emite la estación base de forma periódica, en el diagrama 8 vemos un ejemplo de los mismos: Diagrama 8 Mensajes periódicos de OpenBTS 6 A. González Garrido (tutores J. Navarro Ortiz y J.C. Segura Luna): Prototipo de estación base GSM haciendo uso de OpenBTS Estos mensajes incluyen información acerca de la red, el número de secuencia del resto de mensajes para poder ordenarlos y parámetros necesarios para la correcta operación del teléfono móvil. El siguiente escenario se presenta cuando un teléfono móvil se registra en la red, para ello envía un mensaje de actualización de la localización y espera hasta recibir la aceptación de dicha actualización. Los mensajes intercambiados se muestran en el diagrama 9: Diagrama 9. Mensajes intercambiados durante la conexión de un móvil a la red En este caso entra en juego otro elemento de la red, el servicio de seguridad y autenticación, ya que se necesita saber si el abonado dispone de permiso para acceder a la red. El siguiente escenario se produce cuando se envía un SMS por parte del abonado, y después éste recibe un SMS. Los mensajes en este caso corresponden al diagrama 10: Diagrama 10. Mensajes intercambiados al enviar y recibir un SMS En este caso entra en juego el servicio SMQueue, encargado de la gestión de los SMS. No se comunica directamente con el móvil, puesto que no puede acceder a la red GSM directamente, para ello hace uso de la pasarela OpenBTS. V. APLICACIONES En este apartado se va a hacer un breve resumen de las aplicaciones que actualmente se están desarrollando gracias al empleo de este proyecto. El detalle del presupuesto de una instalación de una sola celda de cobertura se puede ver en la memoria del proyecto, aquí nos quedaremos con el total del mismo, 3096.96 euros. Gracias a este bajo coste, la red puede ser desplegada en multitud de situaciones. La principal aplicación está en el área de la docencia de redes inalámbricas y rede móviles, ya que los alumnos podrán realizar prácticas en un entorno real de comunicaciones móviles. Otra aplicación del mismo es la telefonía en zonas donde no llega la cobertura de las grandes operadoras, ya que el despliegue del equipamiento de éstas tiene un coste muy alto para la poca densidad de población de estas zonas. Y por último, siguiendo el ejemplo anterior, otra aplicación reside en el restablecimiento de las comunicaciones tras desastres naturales, ya que pueden verse afectadas las redes principales, y los equipos de emergencia necesitan un buen servicio de comunicaciones para ser lo más eficaces posibles. El diagrama 11 muestra un ejemplo de una instalación para casos de emergencia. Diagrama 11. Ejemplo de instalación de una estación base en un entorno rural VI. CONCLUSIONES A modo de resumen se van a enumerar las lecciones aprendidas gracias al desarrollo del proyecto: - Modulación y constelación GMSK. Espectro de la misma. - Codificación del canal en GSM. - Uso eficiente del espectro con la combinación FDD/FDMA/TDMA para que múltiples usuarios puedan comunicarse de forma simultánea. - Estudio de los canales lógicos de GSM, tanto los de control por parte de la BTS, como los de señalización y tráfico del abonado. - Estudio del intercambio de mensajes SIP en una red VoIP. - Configuración de un plan de llamadas para una centralita VoIP Asterisk. - Contratación de un servicio troncal SIP para la realización de llamadas fuera de la red privada. 7 TSC e IT / Comunicaciones móviles Como siguientes pasos para continuar la línea del estudio de las redes celulares se han identificado las siguientes ramas: - Desplegar más de una celda GSM y ver uno de los mecanismos más importantes en las redes celulares, como es el traspaso de una llamada que esté en curso. Para ello será necesario: el uso de varios equipos SDR; configurar la potencia en ambos equipos para que tengan un área de cobertura común pequeño; configurar los diferentes elementos de la red, OpenBTS y Asterisk, para poder realizar el traspaso de llamadas correctamente. - La otra posibilidad es la evolución del sistema GSM+GPRS a la tercera generación de comunicaciones móviles, 3G o UMTS. Para ello el proyecto OpenBTS dispone de una versión del sistema OpenBTS para 3G que todavía está en fase de pruebas. Este paso nos permitiría estudiar en profundidad una red más actual a la GSM pero con funcionalidades similares. REFERENCIAS [1]TS 51.021, "Base Station System (BSS) equipment specification ," 3GPP [2]TS 45.005, "Radio transmission and reception ," 3GPP [3]TS 45.004, "Technical Specification Group GSM/EDGE Radio Access Network; Modulation ," 3GPPP [4]TS 45.001, "Physical layer on the radio path; General description ," 3GPP 8 A. González Garrido (tutores J. Navarro Ortiz y J.C. Segura Luna): Prototipo de estación base GSM haciendo uso de OpenBTS Teoría de la Señal y Comunicaciones Resumen—Durante las últimas décadas, la clasificación de proteínas se ha convertido en una tarea sustancial en el ámbito científico, debido a que una eficiente determinación de la función que realizan facilita el diseño de nuevos fármacos y vacunas para combatir distintas enfermedades humanas. Las proteínas están compuestas por una secuencia variable de aminoácidos. La disposición de estas pequeñas moléculas es lo que determina la estructura y función de cada proteína en particular. Frente a las tradicionales técnicas de comparación de cadenas simbólicas, recientemente se han desarrollado representaciones numéricas a partir de distintas propiedades bioquímicas, permitiendo la aplicación de técnicas de procesado de señal. Por tanto, el principal propósito de este trabajo es obtener una predicción de la función que realiza una proteína determinada, comparándola con otras ya conocidas. Palabras clave—AMDF, célula, cepstrum, clasificación, discriminante covariante, distancia euclídea, enzima, índice de aminoácido, kernel, porcentaje de aciertos, procesado de señal, proteína, ProtLock, PseAAC, secuencia de aminoácidos, SVM, test de Jackknife. I. INTRODUCCIÓN OS avances recientes han permitido conocer el conjunto de miles de genes que constituyen la vida. Así, la información genética de los seres vivos se transmite de manera codificada a través de moléculas de ADN, la cual es transcrita en otro tipo de moléculas, el ARN, que, a su vez, se traduce en las proteínas. Por tanto, las proteínas desempeñan un papel fundamental en la vida realizando diversas funciones biológicas importantes. Las macromoléculas que forman las proteínas se caracterizan por una estructura tridimensional o conformación, así como por una secuencia específica de un número variable de aminoácidos, pequeñas moléculas con propiedades físico-químicas propias que las diferencian entre sí. La cadena lineal de aminoácidos es la que controla la estructura tridimensional de una proteína y, en consecuencia, la función que realiza. La necesidad de encontrar una manera rápida y eficaz de predecir la función de nuevas proteínas es cada vez más notable, debido a que el número de proteínas desconocidas que entran en los bancos de datos crece de manera exponencial con los años. La clasificación de nuevas proteínas en los bancos de datos se realiza a partir de las similitudes existentes con las secuencias de aminoácidos de proteínas que ya se conocen. Tradicionalmente, esta clasificación se ha efectuado por medio de técnicas de comparación de cadenas, como Programación Dinámica, la cual se basa en determinar el coste de alineamiento de dos secuencias. En estos casos, el procesamiento se ha realizado a partir de la cadena simbólica de aminoácidos, donde cada uno se representa con una letra extraída de un alfabeto de 20 elementos (Tabla I). TABLA I NOMBRES Y ABREVIACIONES DE LOS 20 AMINOÁCIDOS MÁS COMUNES [1] Aminoácido Código de tres letras Código de una letra Aminoácido Código de tres letras Código de una letra Alanina Ala A Leucina Leu L Arginina Arg R Lisina Lys K Asparagina Asn N Metionina Met M Ácido Aspártico Asp D Fenilalanina Phe F Cisteína Cys C Prolina Pro P Glutamina Gln Q Serina Ser S Ácido Glutámico Glu E Treonina Thr T Glicina Gly G Triptófano Trp W Histidina His H Tirosina Tyr Y De manera reciente, se han comenzado a aplicar técnicas de procesado de señal, cuyas herramientas pueden ser destinadas al análisis y caracterización de las proteínas, mejorando la extracción de propiedades difícilmente detectables al trabajar con cadenas simbólicas. Para ello la proteína ha de ser representada como señal previamente, convirtiendo la cadena simbólica en otra numérica a partir de medidas bioquímicas de cada aminoácido (índices de aminoácido). Los objetivos previstos para el trabajo se muestran en el esquema de la Fig. 1, en el cual se pueden ver los diferentes pasos a seguir para clasificar un conjunto de proteínas así como las interdependencias entre las distintas fases. Fig. 1. Diagrama de flujo del trabajo realizado. Tutores: Victoria Sánchez Calle; e-mail: victori[email protected] Antonio Miguel Peinado Herreros; e-mail: [email protected] Titulación: Grado en Ingeniería de Tecnologías de Telecomunicación Departamento de Teoría de la Señal, Telemática y Comunicaciones Universidad de Granada Autor: Amelia Otilia Villegas Morcillo, e-mail: [email protected] Clasificación de proteínas representadas mediante señales extraídas de índices bioquímicos L Teoría de la Señal, Telemática y Comunicaciones, 2016, ISBN-13 978-84-617-5449-6, páginas 11-16 II. BASES DE DATOS DE PROTEÍNAS En este trabajo se han considerado dos bases de datos de las muchas existentes: una con clases de enzimas, y otra basada en localización subcelular. Además, se presenta el porcentaje de identidad promedio de cada una de las clases, el cual viene definido como el promedio entre el máximo número de componentes que encajan al comparar dos secuencias. A. Predicción basada en clases de enzimas Las enzimas se encuentran relacionadas a la familia o subfamilia a la que pertenecen debido a su función, y su especificidad [2]. Este conjunto está centrado en la familia de oxidorreductasas, contiene un total de 2513 proteínas clasificadas en 16 subfamilias (Tabla II). TABLA II CLASES EN LA BASE DE DATOS DE ENZIMAS Y SU IDENTIDAD PROMEDIO [2] Clase Nombre Nº de secuencias Identidad promedio (%) 1 Grupo CH-OH 297 13.16 2 Grupo aldehído/oxo 201 17.27 3 Grupo CH-CH 180 12.89 4 Grupo CH-NH2 122 13.94 5 Grupo CH-NH 105 13.47 6 NADH/NADPH 285 11.71 7 Otros compuestos nitrogenados 61 13.69 8 Grupo azufre 56 19.70 9 Grupo hemo 248 21.32 10 Difenoles y sustancias relacionadas 94 12.71 11 Peróxido 149 19.01 12 Donadores individuales 90 13.66 13 Donadores por parejas 255 15.71 14 Radicales superóxido 144 26.92 15 Grupos -CH2 82 18.55 16 Ferredoxina reducida 144 16.99 B. Predicción basada en localización subcelular De acuerdo a la localización en una célula, las proteínas se clasifican generalmente en 14 categorías [3]. En este caso se han escogido dos subconjuntos de datos independientes de trabajo, uno de entrenamiento, con 3587 proteínas y otro de test, con 4362 (Tabla III). TABLA III CLASES EN LA BASE DE DATOS DE LOCALIZACIÓN SUBCELULAR Y SU IDENTIDAD PROMEDIO (SUBCONJUNTOS DE ENTRENAMIENTO Y TEST) [3] Clase Nombre Nº sec. train Identidad promedio train (%) Nº sec. test Identidad promedio test (%) 1 Pared celular 69 10.31 34 9.86 2 Centriolo 64 18.62 4 29.67 3 Cloroplasto 303 7.90 819 8.59 4 Citoplasma 991 7.24 171 6.76 5 Citoesqueleto 241 11.03 128 8.93 6 Retículo endoplasmático 288 11.28 136 9.04 7 Extracelular 381 7.60 1213 6.67 8 Aparato de Golgi 70 7.83 41 6.54 9 Lisosoma 123 8.66 57 6.72 10 Mitocondria 379 7.76 743 9.29 11 Núcleo 386 7.66 892 8.14 12 Peroxisoma 145 9.57 84 6.91 13 Membrana de plasma 65 13.07 24 9.67 14 Vacuola 82 13.19 16 8.32 III. GENERACIÓN DE LA SEÑAL En este apartado se presentan los índices bioquímicos a considerar para cada aminoácido y la construcción de la señal completa a partir de la normalización previa de los mismos. A. Representación con 3 índices En [4] se emplean tres propiedades bioquímicas para interpretar cada aminoácido: hidrofobicidad, hidrofilicidad y masa. Estos índices son bastante utilizados ya que informan de la masa molecular de cada aminoácido y de la tendencia de las moléculas a formar enlaces de hidrógeno. Los valores numéricos de estas propiedades se incluyen en una matriz 𝐑 y, en particular, cada una de sus filas 𝐲𝑖 constituye un atributo: 𝑦𝑖(𝑗)=𝑅(𝑖,𝑗) 𝑖=1,…,3; 𝑗=1,…,20 (1) B. Representación con 531 índices En [5] la representación numérica de la cadena de aminoácidos se realiza empleando una base de datos, la AAIndex (Amino Acid Index). En concreto, la primera sección de la versión 9, AAIndex1, la cual posee 531 índices de aminoácido después de eliminar los índices incompletos. Por tanto, la matriz de índices 𝐑 contendrá 531 filas. C. Construcción de la señal En primer lugar se realiza una normalización en media y varianza de cada una de las señales contenidas en la matriz 𝐑 de la siguiente manera [4] [5]: 𝑅(𝑖,𝑗)=𝑅0(𝑖,𝑗)−∑𝑅0(𝑖,𝑛) 20 20 𝑛=1 √∑[𝑅0(𝑖,𝑛)−∑𝑅0(𝑖,𝑚) 20 20 𝑚=1 ] 20 𝑛=1 2 20 (2) Con 𝑖=1,…,𝑀, donde 𝑀 es el número de señales (3 o 531). Por otro lado, si denominamos 𝑎(𝑛) a la cadena de aminoácidos para la proteína, cada una de las secuencias numéricas (señales) 𝑠𝑖(𝑛) se construye sustituyendo cada aminoácido por su valor correspondiente: 𝑠𝑖(𝑛)=𝑦𝑖(𝑎(𝑛))=𝑅(𝑖,𝑎(𝑛)) 𝑛=1,…,𝐿 (3) Donde 𝐿 es el número total de aminoácidos. IV. REPRESENTACIÓN EN LONGITUD FIJA En esta parte se presentan las transformaciones que se aplicarán a las secuencias numéricas de proteína para convertirlas en cadenas de longitud fija. A. Composición Pseudo-Aminoácida (PseAAC) La composición aminoácida (Amino Acid Composition, AAC) es una representación basada en la frecuencia de aparición de cada uno de los 20 aminoácidos comunes en la secuencia [4]. Con objeto de incluir información acerca de las relaciones que puedan existir entre las posiciones que ocupan los aminoácidos en la cadena se ha desarrollado la composición pseudo-aminoácida (Pseudo-Amino Acid Composition, PseAAC) [4]. En esta representación se mantiene el vector de AAC y se añaden los factores de correlación: 𝜃𝑘=1 𝐿−𝑘∑𝛩(𝑛,𝑛+𝑘) 𝐿−𝑘 𝑛=1 , 𝑘=1,…,𝜆 (4) 12 A.O. Villegas Morcillo (tutores V. Sánchez Calle y A.M. Peinado Herreros): Clasificación de proteínas representadas mediante señales extraídas de índices bioquímicos Donde 𝑘 indica el número de posiciones que separan los aminoácidos a comparar, y 𝜆 es la distancia de correlación máxima. Por otro lado, la función de correlación entre los aminoácidos de las posiciones 𝑛 y 𝑛+𝑘 se obtiene como: Θ(𝑛,𝑛+𝑘)=1 𝑀∑[𝑠𝑖(𝑛+𝑘)−𝑠𝑖(𝑛)]2 𝑀 𝑖=1 (5) Por tanto, una vez obtenidos los factores de correlación se puede formar el vector 𝐗 de 20+𝜆 dimensiones para representar una proteína, cuyas componentes toman los siguientes valores: 𝑥𝑢={ 𝑓𝑢 ∑𝑓𝑖 20 𝑖=1 +𝑤∑𝜃𝑘 𝜆𝑘=1 , (1≤𝑢≤20) 𝑤𝜃𝑢−20 ∑𝑓𝑖 20 𝑖=1 +𝑤∑𝜃𝑘 𝜆𝑘=1 , (21≤𝑢≤20+𝜆) (6) Donde 𝑓𝑢 es la frecuencia de aparición del aminoácido 𝑢 (de entre los 20 que ocupan la proteína 𝐗) y 𝑤 es el factor de ponderación elegido (en este caso 𝑤=0.05). B. Función AMDF En [5] se propone una representación parecida a PseAAC, en la cual únicamente se introducen los efectos del orden en la secuencia concatenando las diferencias cuadráticas para cada uno de los índices de aminoácido: 𝜕𝑘𝑖=1 𝐿−𝑘∑𝐷𝑖(𝑛,𝑛+𝑘) 𝐿−𝑘 𝑛=1 𝑖=1,…,𝑀; 𝑘=1,…,𝜆 (7) 𝐷𝑖(𝑛,𝑛+𝑘)=[𝑠𝑖(𝑛+𝑘)−𝑠𝑖(𝑛)]2(8) En este caso el vector de características es 𝑀 veces más largo. Las ecuaciones anteriores definen una autocorrelación de tipo aditiva entre los valores de la secuencia numérica 𝐬𝑖. En concreto, se trata de una versión cuadrática de la función AMDF (Average Magnitude Difference Function) [6], comúnmente empleada en la estimación del pitch o frecuencia fundamental de una señal de voz. C. Cepstrum El cepstrum [7] de una señal discreta 𝑥(𝑛) con espectro 𝑋(𝜔) se define como la transformada inversa de Fourier del espectro logarítmico: 𝑥(𝑛)=ℱ−1[log𝑋(𝜔)]=1 2𝜋∫log𝑋(𝜔)𝑒𝑗𝜔𝑛𝑑𝜔 𝜋 −𝜋 (9) Donde 𝑛 es un índice temporal denominado cuefrencia. A esta transformación se la suele llamar cepstrum complejo a pesar de que la secuencia resultante es real. Por tanto, el cepstrum complejo poseerá también información acerca de la fase de la transformada de Fourier. Por otro lado, si aplicamos el logaritmo sobre el módulo de la transformada, el resultado es el denominado cepstrum real: 𝑐𝑥(𝑛)=ℱ−1[log|𝑋(𝜔)|]=1 2𝜋∫log|𝑋(𝜔)|𝑒𝑗𝜔𝑛𝑑𝜔 𝜋 −𝜋 (10) Además, considerando formas rápidas para el cálculo de la transformada de Fourier, como la FFT (Fast Fourier Transform): 𝑥(𝑛)=IFFT[logFFT[𝑥(𝑛)]] (11) 𝑐𝑥(𝑛)=IFFT[log|FFT[𝑥(𝑛)]|](12) Es posible medir la distancia euclídea entre los espectros logarítmicos de dos señales 𝑥(𝑛) e 𝑦(𝑛). En términos de cepstrum: 𝑑(𝑥,𝑦)=‖𝐱−𝐲‖2=∑(𝑥(𝑛)−𝑦(𝑛))2 𝐿𝑛=−𝐿 = =∑(𝑥(𝑛)−𝑦(𝑛))2 −1 𝑛=−𝐿 +(𝑥(0)−𝑦(0))2+∑(𝑥(𝑛)−𝑦(𝑛))2 𝐿𝑛=1 (13) El término de cuefrencia 0 se suele ignorar cuando se pretende que la distancia no dependa de la potencia de las señales. En el caso del cepstrum real, al poseer simetría par: 𝑑(𝑥,𝑦)=‖𝐜𝑥−𝐜𝑦‖2=(𝑐𝑥(0)−𝑐𝑦(0))2+2∑(𝑐𝑥(𝑛)−𝑐𝑦(𝑛))2 𝐿𝑛=1 (14) Normalmente se suele limitar la longitud del cepstrum aplicando una ventana de liftering, descartando así las cuefrencias superiores y suavizando el espectro. V. ALGORITMOS DE CLASIFICACIÓN En este apartado se exponen los distintos algoritmos considerados en este estudio para la clasificación de proteínas. A. Clasificación basada en mínima distancia euclídea Este es uno de los algoritmos más básicos utilizados para la clasificación con AAC y PseAAC, empleado en sustitución de la distancia de Hamming [4]. La medida de similitud entre la proteína 𝐗 y cada uno de los centroides de las clases 𝐗𝜉 se define como: 𝐷𝐸2(𝐗,𝐗𝜉)=∑(𝑥𝑖−𝑥𝑖𝜉)2 𝑛𝑠 𝑖=1 =(𝐗−𝐗𝜉)𝑇(𝐗−𝐗𝜉) (15) Donde 𝑛𝑠 es la longitud de la secuencia numérica y 𝜉=1,2,3,…,𝑚 es cada una de las clases del conjunto. La regla de predicción viene dada por: 𝐷𝐸2(𝐗,𝐗𝜇)=𝐌𝐢𝐧{𝐷𝐸2(𝐗,𝐗1), 𝐷𝐸2(𝐗,𝐗2),…, 𝐷𝐸2(𝐗,𝐗𝑚)} (16) Donde 𝜇 define la clase en la cual se ha clasificado la proteína 𝐗. B. Algoritmo de clasificación ProtLock Este algoritmo está basado en la distancia de Mahalanobis, la cual es una extensión de la distancia euclídea entre dos variables aleatorias teniendo en cuenta la correlación existente entre ambas [4]. La medida de similitud entre la proteína 𝐗 y cada uno de los centroides de las clases 𝐗𝜉 se define como: 𝐷𝑃2(𝐗,𝐗𝜉)=(𝐗−𝐗𝜉)𝑇𝐂𝜉−1(𝐗−𝐗𝜉)(17) Los elementos de la matriz de covarianzas para cada clase 𝐂𝜉 se obtienen como: 𝑐𝑖,𝑗 𝜉=1 𝑛𝜉−1∑[𝑥𝑘,𝑖 𝜉−𝑥𝑖𝜉][𝑥𝑘,𝑗 𝜉−𝑥𝑗𝜉] 𝑛𝜉 𝑘=1 (𝑖,𝑗=1,2,…,𝑛𝑠) (18) Donde 𝑛𝜉 es el número de secuencias pertenecientes a la clase 𝜉. Luego, la regla de predicción viene dada por: 𝐷𝑃2(𝐗,𝐗𝜇)=𝐌𝐢𝐧{𝐷𝑃2(𝐗,𝐗1),𝐷𝑃2(𝐗,𝐗2),,…,𝐷𝑃2(𝐗,𝐗𝑚)} (19) C. Algoritmo del discriminante covariante Este algoritmo se basa en la regla de decisión MAP (Maximum a Posteriori) aplicada sobre una distribución Normal multivariada [4] [8]. La medida de similitud entre la proteína 𝐗 y cada uno de los centroides de las clases 𝐗𝜉 se define como: 𝐹(𝐗,𝐗𝜉)=𝐷𝑃2(𝐗,𝐗𝜉)+ln|𝐂𝜉|(20) 13 TSC / Procesado de señales bioquímicas Donde 𝐷𝑃2(𝐗,𝐗𝜉) es la distancia cuadrática de Mahalanobis y |𝐂𝜉| es el determinante de la matriz de covarianzas para la clase 𝜉. Luego, la regla de predicción viene dada por: 𝐹(𝐗,𝐗𝜇)=𝐌𝐢𝐧{𝐹(𝐗,𝐗1),𝐹(𝐗,𝐗2),…,𝐹(𝐗,𝐗𝑚)} (21) D. Máquinas de vectores de soporte (SVM) Las máquinas de vectores de soporte (SVM, Support Vector Machines) son un tipo de algoritmo de aprendizaje supervisado [9]. El algoritmo emplea un conjunto de datos de entrenamiento para aprender una frontera de decisión lineal que separa dos clases. Dicha frontera es la que utiliza posteriormente para clasificar el conjunto de datos de test. Cuando las fronteras de decisión no son lineales, SVM emplea funciones tipo kernel (Tabla IV) para mapear los datos a un espacio de orden superior donde se pueda encontrar una frontera óptima. TABLA IV KERNELS EMPLEADOS EN SVM Producto escalar Polinómico de orden 𝒅 Función base radial (RBF, Radial Basis Function) Gaussiana 𝑘(𝑥,𝑥′)=〈𝐱,𝐱′〉 𝑘(𝑥,𝑥′)=〈𝐱,𝐱′〉𝑑 𝑘(𝑥,𝑥′)=exp(−‖𝐱−𝐱′‖2 2𝜎2) Por otra parte, la clasificación binaria propia de las SVM se puede extender a 𝑀 clases mediante dos técnicas distintas. La primera se denomina “SVM uno contra el resto” y consiste en construir un clasificador para cada clase separándola de todas las restantes, por lo que se entrenan un total de 𝑀 clasificadores binarios. La segunda técnica es denominada “SVM por pares” y consiste en construir clasificadores cada par de clases, generando un total de (𝑀−1)𝑀/2 clasificadores binarios. VI. RESULTADOS El marco de experimentación realizado consta de las cuatro variables estudiadas: conjunto de proteínas, representación en longitud fija, clasificador y tipo de test. En cuanto al tipo de test se han considerado dos distintos: test de Jackknife, también conocido como leave-one-out, que consiste en entrenar el clasificador con todas las secuencias del conjunto menos la que se va a clasificar, y experimento basado entrenamiento y test con dos conjuntos distintos. Todas las representaciones, clasificadores y test han sido implementados con el software de Matlab© excepto las SVM, para las cuales se ha utilizado el paquete Gist 2.3 [10]. A continuación se muestra un estudio previo realizado sobre cada representación para determinar la longitud apropiada del vector resultante. A. Estudio previo: AAC y PseAAC En el caso de AAC, los vectores son de 20 elementos y para PseAAC se ha utilizado una distancia de correlación máxima 𝜆=9 [4], por lo que los vectores serán de 29 elementos tanto para 3 como para 531 índices. Sin embargo, solo 20+𝜆−1 son independientes debido a la normalización realizada, por lo que se eliminará una componente cualquiera del vector. B. Estudio previo: función AMDF La distancia de correlación máxima viene determinada por la longitud de la secuencia más corta en los conjuntos de proteínas considerados (que en este caso es 41). Por tanto, para pruebas con el test de Jackknife sobre la base de datos de enzimas, con 𝜆=[8,20,40] tanto para 3 como para 531 índices, los porcentajes de aciertos con el clasificador de distancia euclídea se muestran en la Tabla V. TABLA V PORCENTAJE DE ACIERTOS (%) PARA AMDF CON 3 Y 531 ÍNDICES, Y DISTINTAS DISTANCIAS DE CORRELACIÓN Componentes AMDF 3x8 3x20 3x40 531x8 531x20 531x40 Porcentaje de aciertos (%) 28.85 31.44 31.48 45.76 46.12 45.68 Se observa que con 531 índices los resultados son mejores, mientras que el hecho de aumentar el valor de 𝜆 no incrementa los aciertos de manera considerable. Por tanto, las pruebas se realizarán con 𝜆=8 y 531 índices, proporcionando vectores de 4248 elementos. C. Estudio previo: cepstrum El orden de la FFT a aplicar viene dado por la longitud de la secuencia más larga en los conjuntos (que es de 4687), por lo que se ha utilizado la potencia de dos siguiente a este valor (8192) y se ha aplicado una ventana de liftering rectangular sobre el resultado. En este punto se han realizado pruebas con los dos subconjuntos de entrenamiento y test de la base de datos de localización subcelular, con el índice de hidrofobicidad y se han obtenido los porcentajes de aciertos para el clasificador de distancia euclídea en función de la longitud de la ventana para el cepstrum real y complejo, considerando o no el coeficiente de cuefrencia 0 (Fig. 2). Fig. 2. Porcentaje de aciertos (%) en función del tamaño de ventana para cepstrum real y complejo considerando o no el coeficiente de cuefrencia 0. Se observa que el porcentaje de aciertos mejora conforme se aumenta el tamaño de la ventana hasta llegar un punto en el que se satura. En el caso del cepstrum real, dicha saturación se aprecia en torno a los 500-1000 coeficientes cepstrales y el porcentaje de aciertos es superior cuando se elimina el 𝑐𝑥(0) (40% frente a 28%). En cuanto al cepstrum complejo, la saturación se produce entre los 1000 y 2000 coeficientes, y el porcentaje de aciertos también es superior cuando se elimina el 𝑥(0) (52% frente a 42%). Por tanto, se obtienen mejores resultados con el cepstrum complejo sin considerar el coeficiente de cuefrencia 0. Ahora se selecciona el número de índices y el de coeficientes cepstrales, para lo cual se ha realizado un estudio con 3 índices y 1500 coeficientes, 531 índices y [8,40,1500] coeficientes (Tabla VI). 01000 2000 3000 4000 5000 6000 7000 8000 9000 0 10 20 30 40 50 60 Distancia euclídea. Cepstrum real y complejo longitud ventana %aciertos CepsReal con c(0) CepsReal sin c(0) CepsComp con x(0) CepsComp sin x(0) 14 A.O. Villegas Morcillo (tutores V. Sánchez Calle y A.M. Peinado Herreros): Clasificación de proteínas representadas mediante señales extraídas de índices bioquímicos TABLA VI PORCENTAJE DE ACIERTOS (%) PARA CEPSTRUM COMPLEJO CON 3 Y 531 ÍNDICES, Y DISTINTOS TAMAÑOS DE VENTANA DE LIFTERING Componentes cepstrum complejo 3x1500 531x8 531x40 531x1500 Porcentaje de aciertos (%) 58.46 33.31 53.99 64.19 Se observa que con el clasificador de distancia euclídea y 1500 coeficientes se obtiene un 58% para 3 índices y un 64% para 531. Sin embargo, el tamaño de los vectores resultantes en este último caso es notable, por lo que las siguientes pruebas se realizarán con 3x1500 (vectores de 4500 componentes) y 531 índices con 8 coeficientes, proporcionando 4248 elementos como en AMDF. D. Discusión de los resultados Con estas consideraciones se ha redefinido el marco de pruebas a realizar, las cuales se dividen en los dos tipos de test considerados. El test de Jackknife se realizará para el conjunto de enzimas y el subconjunto de entrenamiento de localización subcelular. Para las representaciones AAC/PseAAC se utilizarán los clasificadores basados en distancia y probabilidad, mientras que para la función AMDF y el cepstrum complejo solo se podrá utilizar el clasificador de distancia euclídea, ya que los otros implican la inversión de una matriz de covarianzas singular en este caso. Para el otro experimento basado en entrenamiento y test se utilizarán los dos subconjuntos de localización subcelular y se añadirá el clasificador SVM a todas las representaciones, considerando los dos tipos de clasificación multiclase. En primer lugar, en la Tabla VII se muestran los resultados de los clasificadores basados en distancia y probabilidad para los tres test realizados. En el caso de distancia euclídea, las cuatro primeras representaciones muestran un comportamiento parecido para los tres test, mientras que para el cepstrum complejo con 3x1500 el porcentaje aumenta hasta el 53-58%. Por otro lado, los algoritmos ProtLock y discriminante covariante aumentan los porcentajes de aciertos de las representaciones AAC y PseAAC con 3 y 531 índices, consiguiendo un máximo de 72% con el algoritmo del discriminante covariante y 531 índices. Por otra parte, en la Tabla VIII se muestran los resultados obtenidos con SVM para los dos clasificadores multiclase, los tres kernels y las seis representaciones consideradas. Se observa que el porcentaje aciertos para el caso de SVM uno contra al resto obtiene mejores resultados que el caso de SVM por pares, siendo RBF el mejor kernel en prácticamente todas las representaciones. Los mejores resultados se obtienen con AAC y PseAAC, así como con la función AMDF, la cual alcanza el 87% de aciertos. VII. CONCLUSIONES En el presente trabajo se ha realizado un estudio sobre distintos métodos de clasificación de proteínas tratadas como señales numéricas. A pesar de que los porcentajes de identidad promedio para cada clase de las bases de datos escogidas eran bajos, se han conseguido predecir las clases originales de cada proteína con un porcentaje de aciertos bastante elevado en algunos casos. TABLA VII PORCENTAJE DE ACIERTOS (%) CLASIFICADORES DE DISTANCIA EUCLÍDEA, PROTLOCK Y DISCRIMINANTE COVARIANTE Tipo de test Clasificador Representación AAC PseAAC 3 índices PseAAC 531 índices AMDF 531x8 Cepstrum complejo 3x1500 Cepstrum complejo 531x8 Test de Jackknife (Base de datos de enzimas) Distancia euclídea 46.32 47.47 47.39 45.76 53.64 39.20 Algoritmo de Protlock 51.01 53.88 53.44 --- --- --- Discriminante covariante 63.59 69.88 72.03 --- --- --- Test de Jackknife (Base de datos de localización subcelular) Distancia euclídea 34.10 35.24 36.02 33.65 53.19 34.04 Algoritmo de Protlock 39.03 34.68 37.22 --- --- --- Discriminante covariante 61.30 67.19 67.94 --- --- --- Entrenamiento y test (Base de datos de localización subcelular) Distancia euclídea 29.76 31.93 31.73 30.35 58.46 33.31 Algoritmo de Protlock 57.59 56.79 58.16 --- --- --- Discriminante covariante 61.62 68.80 69.21 --- --- --- TABLA VIII PORCENTAJE DE ACIERTOS (%) CLASIFICADORES SVM MULTICLASE Tipo de test Clasificador Kernel Representación AAC PseAAC 3 índices PseAAC 531 índices AMDF 531x8 Cepstrum complejo 3x1500 Cepstrum complejo 531x8 Entrenamiento y test (Base de datos de localización subcelular) SVM uno contra el resto Producto escalar 85.88 76.07 85.21 84.20 61.90 76.00 Cuadrático 73.41 76.89 75.52 79.02 60.50 73.84 Función base radial 85.10 85.99 85.51 87.21 61.21 72.44 SVM por pares Producto escalar 44.02 44.38 43.33 40.67 66.32 67.42 Cuadrático 46.47 46.68 45.12 46.52 66.71 71.32 Función base radial 75.26 76.25 75.79 81.02 66.76 70.13 15 TSC / Procesado de señales bioquímicas It can be observed how the orange graphic (signs with power applied) presents a higher number of signals with higher values of the confidence parameter, i.e., there is a large number of signals whose picking time can be considered reliable. On the other hand, if we see the histogram of the original signals (blue graphic), we observe that there is a large number of signals with a low quality parameter value, which means that there are more signals whose picking time is unreliable. In this way, can be appreciated the improvement produced by the application of the method of instantaneous power in seismic signals in the detection of P waves arrival time to perform the tomography. Therefore, the application of this method to recorded seismic signals improves the reliability of P wave arrival time. Which means that the resulting tomography will be more precise. IX. CONCLUSIONS In the present end of degree project it has performed the automatic processing of a large amount of data recorded by the network of seismic stations in the experiment TOMO-ETNA [5]. This processing has include the application of the method of the specific instantaneous power to seismic signals recorded by the seismic stations, in order to improve the their SNR. In addition, due to the magnitud of the data base it was necessary to implement an automatization process to apply this method to all signals stored in the data base. After that, it applies the picking algorithm AMPA [8] to these improved signals. In this way, the improvement of the SNR of the signals also causes an improvement in the detection of P wave arrival time. From these times it obtains the compatible files with the tomography program. This programa will use these files as input data in order to perform a better and more precise tomography of the Etna volcano. ACKNOWLEDGMENTS I would like to thank Prof. Carmen Ben´ ıtez and Prof. Luz Garc´ ıa for giving me the oportunity to do this project under his guidance. In addition, also thank Prof. Gerardo Alguacil for the helpful discussions during the development of the project and the great research moments as well as the knowledge that he has transmitted to me which have been very helpful. I also want to thank my friends, which I have met during these years of career, their constant support. Finally, I would like to thank my parents the oportunity they gave me to study an university degree because without their help I would not have been able to realize it. I also want to mention my sister for their constant support and all my family because they have always believed in me. Thanks to all. REFERENCES [1] Instituto Nacional de Prevenci´ on S´ ısmica. Available from: http://www.inpres.gov.ar/docentes/docentes.html . [2] ”Monte Etna: erupciones, ubicaci´ on, altura y caracter´ ısticas”. Available from: http://historiaybiografias.com/etna/ . [3] M. A. Garc´ ıa, ”Estudio de heterogeneidades laterales de volcanes activos: tomograf´ ıa s´ ısmica de alta resoluci´ on de la isla de Tenerife, anomal´ ıas de propagaci´ on de ondas s´ ısmicas de la isla Decepci´ on y otros efectos”. [4] E. S. Lira, ”Estudio de sismicidad, tomograf´ ıa s´ ısmica y modelo de f´ ısica de rocas: potencial sistema geotermal asociado al complejo volc´ anico Tinguiririca”. Universidad de chile, facultad de ciencias f´ ısicas y matem´ aticas, departamento de geof´ ısica, August 2011. [5] J. M. Iba˜ nez, J. Prudencio, O. Cocina, L. Zuccarello and A. D´ ıaz-Moreno, ”Report on the TOMO-Etna experiment”. MEDiterranean SUpersite Volcanoes (MED-SUV). [6] R. Allen, ”Automatic phase pickers: Their present use and future prospects”. Bulletin of the Seismological Society of America, Vol. 72, No. 6 pp.S225-S242, December 1982. [7] A. Trnkoczy, ”Understanding and parameter setting of STA/LTA trigger algorithm”. September 1999. [8] I. ´ Alvarez, L. Garc´ ıa, S. Mota, G. Cort´ es, C. Ben´ ıtez and ´ A. de la Torre, ”An Automatic P-Phase Picking Algorithm Based on Adaptive Multiband Processing”. IEEE geoscience and remote sensing letters, vol. 10, No. 6, November 2013. [9] B. Olea, G. Alguacil, F. Vidal and M. Feriche, ”Par´ ametros de movimiento intenso y su relaci´ on con la intensidad macros´ ısmica en el ´ area euro-mediterr´ anea”. Instituto Andaluz de Geof´ ısica, Universidad de Granada, Espa˜ na, May 2011. [10] G. Alguacil and F. Vidal, ”Medidas instrumentales de la intensidad del movimiento del suelo. Aplicaci´ on a terremotos europeos”. Instituto Andaluz de Geof´ ısica y Departamento de F´ ısica Te´ orica y del Cosmos, Universidad de Granada, Espa˜ na. [11] ”Interpolaci´ on con funciones splines”. Available from: http://www4.ujaen.es/ angelcid/Archivos/An_Met_Num_ INFORMATICA/Splines.pdf . Francisco Jos´ e Cuberos Mu˜ noz was born in Granada on January 14th, 1992. He was graduated and received a Degree in Telecommunications Technologies Engineering with specialization in Telecommunications Systems from University of Granada in 2015. Nowadays, he courses the oficial master of Telecommunications Engineering given in the Telecommunication and Computing Engineerings High School from the University of Granada. 22 F.J. Cuberos Muñoz (tutoras M.C. Benítez Ortúzar y L. García Martínez): Application of the method of instantaneous power in automatic picking of synthetic explosions in the experiment TOMO-ETNA Resumen— El objetivo principal de este proyecto es minimizar los efectos de los desastres naturales en el mundo, en este caso, los terremotos. Para ello, se ha llevado a cabo en el marco del Proyecto Europeo MED-SUV [1] un experimento denominado TOMO ETNA. Este experimento consistirá en realizar un gran número de explosiones controladas para realizar una tomografía del volcán Etna (Italia). Además de las explosiones controladas, la red de sismógrafos extendida capturará también los terremotos volcano-tectónicos ocurridos durante la realización del experimento y medirá los tiempos de llegada de las mismas a una red de estaciones sísmicas alrededor del volcán Etna. Dicho en otras palabras, este proyecto se propone estudiar determinadas estrategias para detectar de manera automática los tiempos de llegada de las ondas sísmicas generadas por los terremotos volcano-tectónicos y detectadas por la red de estaciones sísmicas instaladas. Palabras clave—Terremoto, sismómetro, picking, AMPA, onda sísmica, tomografía, polarización, Etna, volcán. I. INTRODUCCIÓN n el mundo de la sismología volcánica, es de especial importancia conocer una serie de conceptos para comprender mejor los resultados obtenidos al final de este experimento. A. Ondas sísmicas Las ondas sísmicas son un tipo de onda elástica fuerte en la propagación de perturbaciones temporales del campo de tensiones, los cuales pueden generar pequeños movimientos en las placas tectónicas. Estas ondas tienen su origen en movimientos tectónicos naturales, aunque también puede ser provocada por acciones humanas; por ejemplo, explosiones. Existen dos tipos de ondas sísmicas: ondas internas y ondas superficiales. Las ondas internas se caracterizan por describir caminos curvos, debido a la variada densidad y composición del interior de la Tierra, las cuales se clasifican en ondas primarias (P) y ondas secundarias (S). Las ondas superficiales son ondas internas que logran llegar a la superficie. Estas ondas se clasifican en: - Oscilaciones libres. - Ondas Love. - Ondas Rayleigh. B. Tipos y fuente de señales sismo-volcánicas Existen muchos términos diferentes usados para la clasificación de los eventos volcánicos. Para ello, se realizará una clasificación en la que se dividirá las señales conocidas en dos tipos de señales: transitorias y continuas. Las señales transitorias hacen referencia a señales cuya fuente actúa en un tiempo relativamente corto y posteriormente se generarán las ondas de los diversos eventos: - Eventos sismo-volcánicos (profundos y superficiales). - Eventos de baja frecuencia. - Eventos híbridos, eventos multifase. Las señales continuas en volcanes activos demuestra la profunda diferencia entre un terremoto tectónico y la sismología del volcán: - Temblor volcánico (baja y alta viscosidad). - Procesos superficiales. II. ¿QUÉ ES LA TOMOGRAFÍA? La tomografía sísmica es una potente herramienta, la cual permite al usuario representar, tanto en 2D como en 3D, la estructura interna de la Tierra en base a sus propiedades, a partir de los datos de las ondas sísmicas analizadas. Estas propiedades suelen ser la velocidad de las ondas P y S, usando el factor de calidad Q. Titulación: Grado en Ingeniería de Tecnologías de Telecomunicación Universidad de Granada Departamento de Teoría de la Señal, Telemática y Comunicaciones Picking de terremotos sismo-volcánicos y su aplicación a la tomografía computerizada en el experimento TOMO-ETNA Autor: Diego García Sánchez, e-mail: [email protected] Tutores: Carmen Benítez Ortúzar; e-mail: [email protected] Luz García Martínez; e-mail: [email protected] E Teoría de la Señal, Telemática y Comunicaciones, 2016, ISBN-13 978-84-617-5449-6, páginas 23-28 Fig. 1. Artículo [2]. Tomografía de ondas P del manto realizado por el investigador Zhao (2009). Sin embargo, para hablar de la tomografía sísmica de un volcán es necesario saber qué es un volcán. Un volcán es una estructura geológica en el cual, a través de una caldera o cráter, efectúa la emisión de magma volcánico (roca fundida), acompañado de gases. El ascenso de magma ocurre en diversos episodios de actividad violenta (erupciones volcánicas) que pueden variar en intensidad, duración y frecuencia. En función de esto se puede clasificar un volcán como peligroso o no, ya que no todos los volcanes son iguales debido a sus estructuras heterogéneas y complejas, tanto por sus características morfológicas como geológicas. Cuando una onda sísmica o un disparo atraviesa un volcán, hasta llegar a un sismógrafo, el tiempo de llegada a éste puede variar, debido a que, dentro de un volcán podemos encontrar materiales sólidos (materiales vítreos), líquidos (magma, agua) y gaseosos. Todo ello provocará un cambio en la estructura interna del volcán, lo que provocará la producción de distintos tipos de erupciones. Fig. 2. Estructura de un volcán III. DESCRIPCIÓN DEL ENTORNO DE EXPERIMENTACIÓN Nuestro experimento se realizará en los alrededores del Etna, un volcán activo situado en la costa este de Sicilia (Italia). Tiene alrededor de 3.322 metros de altura (valor variable debido a las constantes erupciones) y es considerado el volcán activo de mayor altura de la placa Euroasiática, la cual cubre una superficie de 1.190 km2, con una circunferencia basal de 140 kilómetros. Fig. 3. Volcán Etna visto desde Catania. Este volcán es uno de los volcanes más activos del mundo, estando casi siempre en constante erupción. Sin embargo, no está considerado como volcán peligroso, viviendo en sus alrededores miles de personas. A. Localización de los terremotos Un terremoto es un fenómeno que ejecuta una sacudida brusca y pasajera de la corteza terrestre, debido a la liberación de energía que ha sido acumulada en forma de ondas sísmicas. Los terremotos más comunes son los producidos por la ruptura de fallas geológicas (Fig. 4). Fig. 4. Esquema de un terremoto y sus partes principales. Como pueden verse en la imagen anterior, la ruptura de una falla da lugar a un terremoto, en la cual hay que destacar los siguientes puntos: -Hipocentro o foco: es la zona en el interior de la Tierra donde se inicia la ruptura de la falla geográfica. En dicho punto es donde se inicia la propagación de las ondas sísmicas. 24 D. García Sánchez (tutoras M.C. Benítez Ortúzar y L. García Martínez): Picking de terremotos sismo-volcánicos y su aplicación a la tomografía computerizada en el experimento TOMO-ETNA -Epicentro: se trata de un punto de la superficie terrestre, el cual está situado directamente encima del hipocentro. Con ambos puntos se puede determinar la profundidad exacta del origen del seísmo (hipocentro). B. Estudio de los sismómetros y el catálogo En el estudio de los seísmos es de gran importancia conocer de antemano el instrumento con el cual se realizará la recogida de estas señales: el sismómetro. Un sismógrafo o sismómetro es un instrumento cuya función es medir terremotos o pequeños temblores, los cuales han sido provocados por el movimiento de las placas litosféricas. En este experimento se emplearán diversos tipos de sismómetros con el fin de registrar un determinado tipo de onda. Entre ellos se deberán de destacar: -Cubos: El primer tipo de estaciones que vamos a describir son las denominadas estaciones portátiles de bajo coste. Estas estaciones se utilizan para representar los datos a lo largo de una cierta medida de interés. Estos datos pueden estar representados en 2D o 3D, incluso en más dimensiones, donde cada dimensión representa algún atributo de la base de datos. -Estaciones fijas: Las estaciones fijas son pertenecientes al Istituto Nazionale di Geofisica e Meteorologia (INGV) [3]. Se caracterizan simplemente por usar unos sensores Nanometrics Trillium de 40 segundos. -Estaciones de banda ancha: Estas estaciones, al igual que las estaciones fijas, llevan sismómetros Nanometrics Trillium Compact. Estas estaciones se caracterizan por registrar señales con gran ancho de banda, de ahí su nombre. Con los sismómetros colocados en los alrededores del Etna, se podrá realizar un estudio detallado de varios aspectos, entre los cuales hay que destacar: magnitud del seísmo, latitud y longitud, tiempo de llegada... Según este tiempo de llegada, si la onda sísmica atraviesa el volcán hasta llegar a un determinado sismómetro, puede ser de mayor o menor magnitud, en función del estado del interior del volcán. De esta forma, se podrá deducir si el volcán trae consigo lava o no, una bolsa de gas,… Toda esta información, la cual es muy importante para poder realizar el estudio de los seísmos, es recogida en un catálogo proveniente del INGV, el cual va actualizándose día a día. Dicho catálogo está disponible a todo el mundo en la página web citada en [3]. IV. DETECCIÓN DEL TIEMPO DE LLEGADA: MÉTODOS DE PICKING Unos de los objetivos primordiales de este proyecto, junto con la colaboración de otros compañeros que abarcarán distintas partes de éste, es la detección de los terremotos registrados en las distintas estaciones, clasificarlos según una estructura dada y hallar el momento exacto del momento de llegada del terremoto (picking), siendo la onda P la primera en llegar a una estación sismológica, con el fin de realizar una tomografía de la zona. Una medición exacta del tiempo de llegada de la onda sísmica es de gran importancia en muchas aplicaciones sismológicas, como puede ser la tomografía de la velocidad. A. STA/LTA El método STA/LTA [4] fue uno de los primeros algoritmos de detección automática, cuyo objetivo es registrar los eventos sísmicos de la forma más precisa posible. Este algoritmo de detección mejorará significativamente el registro de los terremotos débiles en comparación con otros algoritmos de detección automática. Al mismo tiempo, disminuirá el número de registros falsos provocados por el ruido sísmico natural y artificial. Este algoritmo es más beneficioso en sitios sísmicamente más tranquilos, donde el ruido natural sísmico (por ejemplo, el ruido marino) es el ruido sísmico dominante. El algoritmo STA/LTA tiene como objetivo realizar una serie de cambios en la amplitud del ruido sísmico, con el fin de ajustar el momento exacto de la onda sísmica. Estos cálculos serán realizados repetidamente en tiempo real, obteniéndose un considerable número de periodos. El algoritmo STA/LTA filtra las señales sísmicas en dos ventanas de tiempo móviles: STA, que significa “ventana promedio de corto plazo”, mide la amplitud instantánea de la señal sísmica y visual para terremotos; mientras tanto LTA, que significa “ventana promedio de largo plazo”, cuida el promedio actual de la amplitud del ruido sísmico. Primero, calculamos la amplitud absoluta de cada muestra de datos de una señal de entrada. Después, el promedio de las amplitudes absolutas de ambas ventanas. En un paso más, un radio de ambos valores (relación STA/LTA) se calcula. Esta proporción se comparará continuamente con un valor umbral seleccionado de STA/LTA. Si la proporción es superior a este valor umbral, se declara un disparo del canal. Además de los datos adquiridos durante el periodo de detección, las redes y registros sísmicos deberán añadir una cierta cantidad de datos sísmicos en el archivo del evento antes del registro. B. STA/LTA+TAK En el campo de la sismología, algunos modelos autorregresivos han sido ampliados, como pueden ser el método propuesto por Takanami y Kitagawa. Este método se encarga de proporcionar resultados más precisos que 25 TSC / Procesado de señales sísmicas STA/LTA. Sin embargo, si a priori la estimación de la hora de llegada no es precisa, la búsqueda del límite para los modelos autorregresivos debe cubrir un extenso intervalo de tiempo, dando lugar a una limitación computacional muy compleja. Por otro lado, el intervalo de confianza de la hora estimada de llegada depende no sólo de la relación señal ruido, sino también de las diferencias espectrales de la señal sísmica y ruido de fondo. C. AMPA El método AMPA [5] (algoritmo de selección multibanda adaptativa) está enfocado a determinar el tiempo de llegada de aquellas señales que están afectadas por el ruido, el cual es más exacto que el método STA/LTA y menos costoso computacionalmente que el método STA/LTA+TAK. El algoritmo AMPA propone dos importantes contribuciones a la detección del instante de llegada de la fase P: 1) una etapa de reducción de ruido de fondo basado en un proceso multibanda adaptativo, y 2) una etapa de filtrado que realza la llegada del terremoto, minimizando la respuesta a éste, tales como otros tipos de señales naturales o humanas inducida por ruidos. El AMPA (solo y en combinación con el algoritmo Takanami) ha sido comparado con el STA/LTA convencional (también solo y en combinación con el algoritmo Takanami) usando los tiempos de picking obtenidos. Los resultados confirman la utilidad de poder elegir el algoritmo para la identificación precisa de la llegada de la fase P. Por otra parte, cuando los algoritmos AMPA y Takanami se combinan, los resultados de cada algoritmo mejoran significativamente. La combinación de ambos algoritmos también reduce la complejidad computacional del algoritmo Takanami. Una de las principales limitaciones de elegir entre estos algoritmos es el ruido que se puede apreciar en los sismogramas. Este ruido presenta un comportamiento muy variado desde las perspectivas de tiempo y frecuencia. Sin embargo, el problema se complica porque las señales sísmicas tienen una frecuencia de tiempo y una distribución variable. Usando el algoritmo AMPA, la señal es procesada para minimizar los efectos de contaminación acústica y mejorar la respuesta a un evento sísmico. El algoritmo realizará un análisis de adaptación multibanda incluyendo una detección de envolvente y una reducción de ruido para cada banda y, para finalizar, un filtrado que mejorará la respuesta a la llegada de un terremoto. Fig. 5. Diagrama de bloques completo del proceso de adaptación multibanda V. IMPLEMENTACIÓN PRÁCTICA DE LA PROPUESTA Una vez conocida la teoría necesaria para la realización del siguiente experimento, se procederá a seguir cada uno de los pasos del diagrama de bloques expuesto en la figura 6: Fig. 6. Diagrama de bloques de la programación a realizar. A. Procesado de los registros sísmicos Tal y como se ha comentado anteriormente, hay disponible un catálogo en el cual viene recogida toda la información disponible para la localización de los seísmos registrados. Junto con este catálogo, también se tendrá una serie de ficheros de las diferentes estaciones, almacenados en diversos días. Cada uno de esos ficheros es un registro de 24 horas (es decir, cada archivo corresponde a un día en concreto), en el que viene almacenado la grabación/registro de los terremotos de dicho día. Sin embargo, esto no quiere decir que todos los archivos tenga un terremoto registrado, ya que puede ser que dicho día contenga uno, dos, varios terremotos o ninguno. En el momento de grabación de los terremotos, estos han sido registrados en tres tipos de estaciones: cubos, fijas (INGV) y banda ancha (BroadBand). Por lo tanto, el paso importante es el siguiente: almacenar la información más 26 D. García Sánchez (tutoras M.C. Benítez Ortúzar y L. García Martínez): Picking de terremotos sismo-volcánicos y su aplicación a la tomografía computerizada en el experimento TOMO-ETNA relevante de cada día y clasificar según sea la estación en la que ha sido registrada. A través de un código programado, se crearán unos archivos que corresponderán a un día en concreto, en un sismógrafo concreto y en un tipo de estación concreta. Finalmente se obtendrá los ficheros .mat con la información más importante para la compilación en los siguientes códigos. Fig. 7. Datos de un archivo .mat Por lo tanto, está será la información definitiva que tendrá los archivos creados. B. Implementación del picking con AMPA En este momento tendremos tres carpetas con los ficheros anteriores creados con sus tres componentes (z,n,e). Digamos que, según el diagrama de bloques Fig. 6, el proceso de programación va por el segundo nivel. El siguiente paso será pasar al tercer nivel: aplicación del AMPA. La función de este método es muy simple: consiste en encontrar el instante exacto de llegada de la onda sísmica generada por el terremoto a la estación. En este proceso se empleará la función AMPA creada y nos ofrecerá, entre otros muchos valores, el tiempo de llegada de la onda sísmica. Este proceso se realizará para los tres tipos de estaciones y en sus tres componentes. 050 100 150 200 250 -30 -20 -10 0 10 20 30 40 50 60 Fig. 8. Momento de llegada de un terremoto en 175 estaciones, ordenadas de menos a mayor distancia al hipocentro del terremoto. Se puede apreciar en la Fig. 8 como el momento exacto de llegada de la onda sísmica (cruces rojas) es muy exacto y lineal. Esto es debido a que este terremoto presenta una magnitud elevada y alcanza un rango mayor. Para un terremoto con magnitud menor, la señal registrada será más paupérrima y el picking menos exacto y lineal. C. Resultado final Únicamente quedaría el último y definitivo nivel: la creación de un fichero de texto llamado formato Lotos_Atom. ¿Qué contiene ese archivo? Ahora mismo, tras la aplicación del AMPA, se tiene un archivo el cual contiene todos los terremotos de todas las estaciones. Sin embargo, tal y como se pudo comprobar, habrá terremotos con excelente calidad y otros pésimos. El objetivo primordial será aplicar una serie de condiciones tales que tengamos los resultados definitivos para la creación de la tomografía. El resultado final será un archivo de texto con todos los terremotos en todas las estaciones con la calidad más óptima, aplicando para ello unas condiciones de calidad necesarias. Con estos datos se procederá a la realización de la tomografía. D. Implementación del picking con AMPA con técnicas de polarización La idea principal de la aplicación de un filtrado de polarización consiste en conseguir un tiempo de picking más exacto utilizando el conocimiento de la polarización de la onda sísmica. Cuando la señal buscada y el ruido tienen características similares de energía, amplitud y frecuencia este método puede ser muy útil. Para ello, se necesitará usar las tres componentes de cada tipo de estación de forma simultánea. Para nuestro experimento hemos diseñado un filtro de polarización basado en la idea clásica de Vidale (1986, [6]). La filosofía de la técnica consiste en definir ventanas temporales a lo largo de todo el registro sísmico, en las que se analiza la matriz de covarianzas de las 3 componentes de señal registradas. Usando dicha matriz de covarianzas y mediante el análisis de componentes principales, se detecta la dirección de máxima energía de la señal. Cada una de las 3 componentes originales registradas se proyecta sobre dicha dirección de máxima energía. La suma de todas las proyecciones es la señal polarizada a la que le aplicaremos el algoritmo de picking. E. Comparación de resultados A continuación se procederá a realizar una comparación visual de los tiempos de picking y se observará como han sido mejorados sus valores. Para ello, se comparará resultados sin polarizar con los polarizados. Además del tiempo de picking, también podrá apreciarse un aumento de la calidad de la señal, obteniéndose una SNR considerablemente alta. 27 TSC / Procesado de señales sísmicas Fig. 9. Valores INGV sin polarización y con polarización. 9.6 9.8 10 10.2 10.4 10.6 10.8 11 11.2 9 9.5 10 10.5 11 11.5 12 12.5 13 9.4 9.6 9.8 10 10.2 10.4 10.6 10.8 11 11.2 9.5 10 10.5 11 11.5 12 Fig. 10. Arriba: terremoto con picking no mejorado. Abajo: terremoto con picking mejorado. La Fig. 9 muestra una comparativa de los resultados obtenidos sin polarizar y polarizados. Se puede apreciar como varían los valores de traveltime (picking) de manera positiva, ajustándose al tiempo exacto de llegada. De esta forma, la calidad de los resultados obtenidos también mejorará significativamente en la tomografía. En la Fig. 10 podemos ver con claridad el momento exacto del inicio del terremoto en ambas gráficas, verificando con total seguridad la mejoría del método de AMPA con la polarización en la segunda imagen. Se puede apreciar en la segunda imagen como el momento de picking (cruz roja) está situado en el momento de mayor amplitud, correspondiente a la llegada de la onda P, mientras que en la primera imagen ese tiempo de picking está situado ligeramente antes de la llegada de la onda P. VI. CONCLUSIONES Y VÍAS FUTURAS El objetivo de este proyecto era obtener unos valores de picking más óptimos para poder realizar la tomografía. Para ello se ha debido de cumplir los siguientes objetivos: -Procesado automático de los datos brutos registrados por la red de estaciones sísmicas. - Creación de los ficheros formato .dat con toda la información necesaria. - Aplicación de la polarización. - Creación de los ficheros compatibles con el formato de entrada del programa de tomografía (Lotos_Atom). Todo el mundo sabe que un trabajo nunca está perfecto. Siempre existirá un margen de mejora y así poder seguir dando un paso adelante en la investigación. Estás mejoras no tiene porque ser introducir pasos nuevos y ajenos a lo realizado. Pueden ser una versión sobre los códigos ya programados: una ejecución más rápida, un nuevo proceso de análisis,… Algunas de estas mejoras pueden ser las siguientes: -Mayor número de estaciones. - Mejorar la función AMPA. - Usar ordenadores más potentes. REFERENCIAS [1] MED-SUV, “MEDiterranean SUpersite Volcanoes”. Available from: http://med-suv.eu/ [2] M. A. García, “Estudio de heterogeneidades laterales de volcanes activos: tomografía sísmica de alta resolución de la isla de Tenerife, anomalías de propagación de ondas sísmicas de la isla decepción y otros efectos”,2010. Available from: http://hera.ugr.es/tesisugr/18972809.pdf [3] INGV, “Istituto Nazionale di Geofísica e Vulcanologia”. Catálogo de los terremotos en el este de Sicilia - Sur de Calabria (1999-2015). Available from: http://www.ct.ingv.it/ufs/analisti/catalogolist.php [4] A. Trnkoczy, “Understanding and parameter setting of STA/LTA trigger algorithm, September 1990. Available from: http://gfzpublic.gfzpotsdam.de/pubman/item/escidoc:4097:3/component/escidoc:4098/IS_ 8.1_rev1.pdf [5] I. Álvarez, L. García, S. Mota, G. Cortés, C. Benítez, Á. De la Torre, “ An Automatic P-Phase Picking Algorithm Based on Adaptive Multiband Processing”, IEEE GEOSCIENCE AND REMOTE SENSING LETTERS, VOL. 10, NO. 6, November 2013. [6] J. E. Vidale, “Complex Polarization Analysis of Particle Motion”, Bulletin of the Seismological Society of America, Vol. 76, No. 5, pp. 1393-1405, October 1986. Diego García Sánchez, 4 de marzo de 1991, Jaén. Graduado en Ingeniería de Tecnologías de Telecomunicación en la Universidad de Granada con mención en sistemas de telecomunicación y alumno del máster oficial de Ingeniería de Telecomunicación de la Universidad de Granada. 28 D. García Sánchez (tutoras M.C. Benítez Ortúzar y L. García Martínez): Picking de terremotos sismo-volcánicos y su aplicación a la tomografía computerizada en el experimento TOMO-ETNA Uso de m´etodos de polarizaci´on instant´anea avanzados para la mejora de la fase de llegada de se˜nales s´ısmicas Autor: Ismael Vico Trivi˜no, e-mail: [email protected] Tutoras: María del Carmen Ben´ıtez Ort´uzar, e-mail: [email protected] Luz Garc´ıa Mart´ınez, e-mail: [email protected] Titulaci´on: Grado en Ingenier´ıa en Tecnolog´ıas de Telecomunicaci´on Departamento de Teor´ıa de la Se˜nal, Telem´atica y Comunicaciones Universidad de Granada Resumen—Una de las mayores dificultades en el an´ alisis de se˜ nales s´ ısmicas es encontrar el evento de inter´ es dentro de una se˜ nal ruidosa. Esto se convierte en una tarea tediosa y a veces impracticable cuando intentamos procesar el gran volumen de informaci´ on generado en una estaci´ on s´ ısmica que registra continuamente la actividad terrestre. En esta disertaci´ on se propone un algoritmo de polarizaci´ on instant´ anea capaz de maximizar la relaci´ on se˜ nal ruido de dichas se˜ nales s´ ısmicas. El procedimiento comienza con el c´ alculo del semieje mayor de la trayectoria el´ ıptica de las part´ ıculas del suelo para cada componente de la se˜ nal, que se encuentra dispuesta en un espacio tridimensional. Teniendo en cuenta que el ruido mantiene una amplitud constante en todas las direcciones de polarizaci´ on, la proyecci´ on de dicha se˜ nal s´ ısmica sobre los semiejes mayores de tal elipse resulta en un considerable incremento de la se˜ nal de inter´ es frente al ruido. Asimismo, la se˜ nal tambi´ en se mejora mediante un filtro de polarizaci´ on muestra a muestra usando la relaci´ on entre las tres componentes de las medidas correspondientes a las tres direcciones espaciales para estimar el grado de polarizaci´ on. Este procedimiento permite utilizar algoritmos b´ asicos de detecci´ on, ampliamente conocidos en el an´ alisis de se˜ nales s´ ısmicas, aumentando su robustez y fiabilidad gracias al an´ alisis de polarizaci´ on. Tambi´ en agiliza considerablemente el procesado de la informaci´ on, as´ ı como reduce el volumen de datos almacenado, ya que selecciona ´ unicamente el terremoto dentro de todo el registro de muestras y elimina aquellas que carecen de inter´ es. En definitiva, se optimiza la eficiencia en el procesado de las se˜ nales s´ ısmicas. Palabras clave—polarizaci´ on, instant´ anea, se˜ nal s´ ısmica, terremoto, mejora detecci´ on I. INTRODUCCI ´ ON La necesidad de la mejora en la robustez en el instante de llegada de una onda s´ ısmica a un sensor determinado, radica en el experimento de realizaci´ on de una tomograf´ ıa inversa en el volc´ an Etna, en Italia. Este proyecto recibe el nombre de Tomo-Etna. Existen una serie de sensores ubicados alrededor del volc´ an, realizando medidas registradas en las tres componentes cartesianas del espacio (ver figura 1). Las ondas s´ ısmicas que se registran son disparos controlados realizados desde barcos alrededor de la isla. De esta forma, podemos realizar un an´ alisis de los tiempos de llegada y el retardo que presenta la onda tras atravesar el volc´ an, para caracterizar el estado del interior del mismo. Dado el ruido que aparecer´ a en los registros de los sensores que puede llegar da˜ nar el instante de llegada, es muy conveniente mejorar la detecci´ on. Figura 1. Distribuci´ on de sensores alrededor del volc´ an Etna. Imagen obtenida de [1]. Para realizar el an´ alisis de la polarizaci´ on de las ondas s´ ısmicas que tenemos registradas usamos la herramienta Matlab, implementando el desarrollo matem´ atico necesario para optimizar la orientaci´ on de los ejes de los sensores y adecuarla a la direcci´ on de m´ axima energ´ ıa de la onda. II. MARCO TE ´ ORICO A. Ondas s´ ısmicas Una onda s´ ısmica es una perturbaci´ on del medio material que se genera en un punto fuente (hipocentro), y que se extiende omnidireccionalmente. La vibraci´ on que se propaga por el interior de la corteza terrestre se llama onda de cuerpo, mientras que las que lo hacen a trav´ es de la superficie terrestre desde el epicentro son las llamadas ondas superficiales. Existen dos tipos de onda, seg´ un la forma en la que act´ uan perturbando el medio: ondas P y ondas S. Las P son las m´ as r´ apidas y las primeras que se registran en un sismograma. Son ondas de presi´ on, y act´ uan sobre la direcci´ on de propagaci´ on. Por otro lado, las ondas S, torsionan el medio de forma Teoría de la Señal, Telemática y Comunicaciones, 2016, ISBN-13 978-84-617-5449-6, páginas 29-34 Figura 2. Polarizaci´ on el´ ıptica. Obtenida de [2] esf´ erica desde el hipocentro. ´ Estas ´ ultimas tambi´ en suelen llamarse ondas secundarias o ondas de corte. B. Polarizaci´ on de una onda Las ondas s´ ısmicas est´ an polarizadas en una elipse en el espacio tridimensional. Se dice que una onda est´ a polarizada cuando su evoluci´ on espacial describe un lugar geom´ etrico determinado, a saber, lineal, circular o el´ ıptico (ver Figura 2). La polarizaci´ on el´ ıptica se produce cuando las distintas componentes espaciales de la onda tienen distintas amplitudes o distintas fases. Las ecuaciones (1) describen una polarizaci´ on el´ ıptica bidimensional. Ex(z, t) = Ex0sen(ωt −kz ±ξx)i Ey(z, t) = Ey0sen(ωt −kz ±ξy)j(1) Cuando trabajamos con sensores que est´ an orientados sobre una determinada direcci´ on de polarizaci´ on, si ´ esta y la de la onda que se pretende registrar no est´ an perfectamente alineadas se producir´ a una p´ erdida de energ´ ıa recibida. En el caso de la medida de una onda polarizada el´ ıpticamente, la direcci´ on de m´ axima recepci´ on de energ´ ıa se encuentra sobre el semieje mayor de la elipse (ver Figura 2). III. METODOLOG´ IA E IMPLEMENTACI ´ ON El m´ etodo utilizado est´ a basado en el enfoque de Gallart et al. en [3] ampliado con el de Morozov et al. en [4]. Pretendemos realizar la mejora de la se˜ nal usando filtros de polarizaci´ on en el dominio del tiempo usando sistemas de datos con tres ejes. En determinados puntos el filtro puede implementar coherencia en la polarizaci´ on de forma espacial (con otras componentes), de manera que puede mejorar la eliminaci´ on del ruido. En definitiva, el problema es la eliminaci´ on de reflexiones de la se˜ nal, ya que son similares entre s´ ı y m´ as dif´ ıciles que detectar que un ruido con distinta frecuencia o potencia. Para ello, haremos uso de medidas direccionales coherentes, y con ello podremos atenuar el ruido por completo, incluyendo estas se˜ nales nocivas. A. Medidas y estructura de los datos Este procedimiento de polarizaci´ on instant´ anea utiliza una estructura de se˜ nales con tres componentes espaciales, a trav´ es de las cuales comprueba el nivel de amplitud de una se˜ nal en una ´ unica componente, y si se encuentra tambi´ en en las dem´ as. Si es as´ ı, la se˜ nal estar´ a poco polarizada y el algoritmo la minimizar´ a. B. An´ alisis matem´ atico de la onda s´ ısmica Primero observaremos la se˜ nal anal´ ıtica y su utilidad para determinar los vectores de polarizaci´ on instant´ aneos para se˜ nales s´ ısmicas tridimensionales. Los vectores de polarizaci´ on llevan la orientaci´ on instant´ anea de los semiejes mayor y menor de una elipse que representa el movimiento de la se˜ nal en un espacio tridimensional. Podremos usar esos ejes para observar el grado de polarizaci´ on y para poder as´ ı eliminar las se˜ nales menos polarizadas. La se˜ nal anal´ ıtica de u(t)es de tipo complejo, y se define s´ olo con una se˜ nal real y su transformada de Hilbert. uc(t) = u(t) + iH[u(t)] (2) La se˜ nal anal´ ıtica permite descomponer una se˜ nal como una envolvente real (la amplitud C(t)) y una fase instant´ anea real (φ(t)), dependientes del tiempo (ver ecuaci´ on 3). uc(t) = C(t)e[iφ(t)] (3) La ventaja de la se˜ nal anal´ ıtica es que factoriza la se˜ nal como una funci´ on de baja frecuencia (envolvente, C(t)) y otra de alta frecuencia (fase, φ(t)). Ya sabemos que la transformada de Hilbert introduce un desfase de −π/2, de hecho su forma temporal es 1 iπt , para obtener la parte compleja ortogonal de la se˜ nal anal´ ıtica. La se˜ nal anal´ ıtica permite determinar atributos directamente de la se˜ nal en un an´ alisis muestra por muestra. As´ ı que gracias a eso podemos determinar la polarizaci´ on instant´ anea de la se˜ nal tridimensional. Este m´ etodo puede mejorar se˜ nales con movimientos el´ ıpticos y lineales sin necesidad de tener una polarizaci´ on predefinida. Las se˜ nales con polarizaci´ on lineal se proyectar´ an sobre su direcci´ on principal y las el´ ıpticas sobre dos direcciones (una sobre la direcci´ on del eje mayor), otra por ortogonalidad sobre el eje menor y otra sobre otra direcci´ on ortogonal a ambas. 1) Medida del grado de polarizaci´ on: Las se˜ nales polarizadas son aquellas cuyas caracter´ ısticas no cambian su polarizaci´ on en toda la se˜ nal (en el tiempo). Para realizar una ponderaci´ on de lo polarizada que est´ a una se˜ nal en cada muestra, se utiliza el que llamaremos grado de polarizaci´ on oc(t)y que queda definido en la ecuaci´ on (4). c(t) =   1 Long + 1 t+Long/2 X τ=t−Long/2 m(t) |m(t)| a(τ) |a(τ)| µ1  µ2 (4) Long es una ventana corta de Long + 1 muestras y m(t) es el vector de medias de polarizaci´ on de la ventana de datos. a(t)es el semieje mayor de la elipse. Las Long + 1 proyecciones de los vectores unitarios de polarizaci´ on se suman al vector unitario medio. Debido a la incertidumbre de fase, los valores absolutos se usan para evitar interferencias destructivas en los cambios de fase. La transici´ on entre grados de polarizaci´ on altos y bajos se controla con los super´ ındices µ1yµ2. Esto hace que se aten´ ue m´ as el ruido cuando las diferencias entre las se˜ nales m´ as y menos polarizadas son peque˜ nas, es decir, va convergiendo. µ1yµ2act´ uan sobre las proyecciones individuales y su suma, respectivamente. 30 I. Vico Triviño (tutoras M.C. Benítez Ortúzar y L. García Martínez): Uso de métodos de polarización instantánea avanzados para la mejora de la fase de llegada de señales sísmicas Figura 3. Elipse. Obtenida de [2] En nuestro caso, usaremos un valor µ´ unico para ambos exponentes. c(t)es una funci´ on escalar que se mueve entre 0 y 1 indicando c´ omo de polarizada homog´ eneamente est´ a la se˜ nal a lo largo de una ventana Long.c(t)es igual para las tres direcciones del espacio en las que queda registrado el se´ ısmo. Si la direcci´ on del semieje mayor var´ ıa demasiado, las proyecciones en el vector de medias m(t)se hacen m´ as peque˜ nas y el factor de polarizaci´ on disminuir´ a. El vector m(t)es un vector de medias que caracteriza la polarizaci´ on en la ventana de datos. Puede adaptarse para diferentes aplicaciones y estad´ ısticas. m(t) = 1 Long + 1 t+Long/2 X τ=t−Long/2 a(τ) |a(τ)|(5) Usaremos la segunda aproximaci´ on para calcular la media, ya que es independiente de la amplitud al ser una relaci´ on entre amplitudes y no una media directa. Definiremos tambi´ en un vector auxiliar para el caso en el que el semieje mayor y el semieje menor sean pr´ acticamente iguales. Si esto sucede, se pueden confundir los ejes y realizarse mal la polarizaci´ on. Para ello, definimos el vector de planaridad (ver ecuaci´ on 6) como el producto vectorial de los dos semiejes, es decir, un nuevo vector ortogonal a ambos, con lo cual se solventa el problema de la confusi´ on de los semiejes. p(t) = a(t)×b(t)(6) 2) Deducci´ on matem´ atica de la maximizaci´ on de la fase: Necesitaremos entonces maximizar la ecuaci´ on 7 para poder calcular la fase que optimiza la polarizaci´ on. Para ello, separamos los t´ erminos de la ecuaci´ on y los desarrollamos para encontrar una forma m´ as compacta de la fase (ecuaci´ on 8). Φr(e−iψuc(t)) = PiRe[e−iψuc i(t)]2 +PiRe[e−iψuc i(t)]2(7) X i (Re(uc i(t)e−iψ))2(8) La exponencial e−iψ se descompondr´ a en senos y cosenos gracias a la identidad de Euler (9) e−iψ =cos(ψ) + isen(ψ)(9) Simplificamos la expresi´ on 8 X i Re uc i+uc∗ i 2+iuc i+uc∗ i 2(cos(ψ)−isin(ψ))2 (10) si desarrollamos, finalmente obtenemos la expresi´ on simplificada X i (Re(uc ie−iψ))2=1 4X iuc ieiψ +uc∗ ie−iψ2 (11) Una vez deducido el primer sumando, desarrollaremos el segundo:  X i (Re(uc ie−iψ))!2 (12) Si desarrollamos el cuadrado y agrupamos sumatorias:  4 X i uc i 2e−2iψ +X i uc∗ i 2e2iψ +X i uc iuc∗ i!(13) Definimos unos nuevos par´ ametros auxiliares para no recargar la notaci´ on: A=1 2X i uc i 2(14) B=1 2 X i uc i!2 (15) Para calcular la maximizaci´ on de la fase de la polarizaci´ on el´ ıptica, compactamos la ecuaci´ on 7, adem´ as de sustituir A+ B por Z para simplificar. Derivamos 0 = −2iZe−2iψ0= 2iZ∗e−2iψ0=(16) =−2iZ (cos(2ψ0)−isin(2ψ0)) + 2iZ∗(cos(2ψ0)−isin(2ψ0)) = =−2iZ cos(2ψ0)+2zsin(2ψ0) + 2iZ∗cos(2ψ0)−2Zsin 2ψ0 donde es un factor de regularizaci´ on de B. Si desarrollamos, tenemos finalmente: ψ0=1 2arg (A+B) + kπ (17) con k∈Z Y esta es la fase que utilizaremos para calcular la polarizaci´ on. El factor kπ se debe a la periodicidad de la arcotangente, cuyo periodo es π, con lo cual, se introduce incertidumbre de un n´ umero entero de veces π. 31 TSC / Procesado de señales sísmicas RFC 3545-, a continuación se multiplexan varios paquetes en uno mediante PPPMux (Point-to-Point Protocol Multiplexing) –RFC 3153para finalmente ser enviado extremo a extremo mediante un túnel L2TP (Layer 2 Tunneling Protocol) –RFC 2661-. Fig. 1. Tunelado, compresión y multiplexación Kahawai: Esta tecnología ha sido implementada por investigadores de la Universidad de Duke y de Microsoft Research [3]. Está orientada a reducir el ancho de banda consumido en juegos de streaming hasta en una sexta parte usando, para ello, a los clientes en el proceso de renderizado de los contenidos en lugar de dejar todo el proceso al servidor. Es decir, los recursos se comparten entre el servidor remoto y la GPU del cliente. Ello permite que Kahawai (stream en hawaiano) pueda usarse en dispositivos que tengan una conexión a Internet más limitada, proporcionando mayor calidad al haber liberado parte del ancho de banda. En la figura 2, el servidor renderiza las versiones altas (“Hi Detail”) y bajas (“Lo Detail”) de cada frame y calcula la diferencia visual en un delta frame (“Delta”) para codificar un video, usando H264, de todos los delta frames. El cliente decodifica el video y cada frame (“Patch”) lo añade a la versión baja (“Lo Detail”) generada por la GPU del cliente obteniendo así la versión alta (“Hi Detail”). Por último, el cliente informa al servidor de que ha sido capaz de generar esta versión. Fig. 2. Técnica Kahawai III. TEMPORIZACIÓN Y COSTES Las fases en las que se divide el proyecto y su coste (Tabla I) se describen a continuación: establecer los objetivos del proyecto, análisis de juegos de similares características, estimar los costes asociados a la ejecución del proyecto, diseñar el videojuego, implementar el videojuego, realizar las pruebas y analizar los resultados, elaborar la documentación del proyecto. IV. DISEÑO A continuación se establece el diseño que debe tener el videojuego y el protocolo adaptativo. A. Descripción general del juego El videojuego diseñado es un simulador de naves que compiten entre sí por llegar a la meta y obtener el máximo número de puntos. La puntuación aumentará cada vez que el disparo realizado por una nave alcance a otra y también aumentará en función del orden de llegada de cada nave a la línea de meta. En el transcurso de la partida irán apareciendo cajas que permitirán al jugador tener algún tipo de bonificación: las cajas azules aumentarán la velocidad de disparo durante cuatro segundos y las cajas naranjas aumentarán la velocidad de movimiento durante dos segundos. El videojuego permite que hasta 4 jugadores jueguen de forma simultánea y compitan entre sí por un circuito, en un juego de carreras de naves. Para ello se hace uso de un servidor que coordinará las funciones básicas del juego y un cliente por cada jugador que interpretará los mensajes que envíe el servidor. TABLA I ESTIMACIÓN DE COSTES Recurso Cantidad Coste unitario(€) Recursos humanos horas €/hora Juan José Ramos Muñoz 60 30 Pablo Peña Martínez 318 30 Recursos materiales Ordenador con Windows 10 1 600 Ordenadores para pruebas 3 500 Router 1 35 Cables Ethernet 4 2 Herramientas ofimáticas 1 70 Entorno Unity 3D 1 0 Network Emulator Client 1 0 Analizador Wireshark 1 0 COSTE TOTAL: 13553 B. Características y requisitos del juego Las características del juego son las siguientes: Todos los eventos deben quedar validados por el servidor: cuando un jugador cambie su posición, además de moverse de forma local, éste se lo comunicará al servidor quien variará la posición de ese cliente en su propio escenario y le responderá con la ubicación en la que debe estar para que, en caso de ser diferente a la que tiene el cliente, sea corregida. De igual forma, cuando un usuario realice un disparo, éste se lo comunicará al servidor quien se encargará de comunicar al resto de usuarios que esa nave ha disparado. Por último, los disparos que acierten a otras naves sólo puntuarán si en el servidor ha ocurrido esa colisión. Será necesario un equipo que haga las funciones de servidor con el que se comunicaran los equipos de los clientes. Se hará uso de un servidor centralizado para que los clientes estén actualizados de todo lo que ocurre en el juego. Dado que servidor y cliente son entidades diferentes, cada uno tendrá su propia ventana de inicio: el servidor dispondrá de la opción de iniciarse quedando a la espera 38 P. Peña Martínez (tutores J.J. Ramos Muñoz y J.M. López Soler): Diseño de un juego con requisitos de tiempo real para redes móviles de que lleguen los jugadores, mientras que el cliente tendrá la opción de ver instrucciones básicas del juego, introducir un nombre de usuario e iniciar la partida. Las bonificaciones que van apareciendo por el circuito serán acumulables entre sí siempre que sean del mismo tipo, en caso contrario se perderá la bonificación actual y se activará la que se acaba de coger. Puesto que al finalizar el circuito las naves que han llegado a la línea de meta no se pueden mover, hay que evitar que los disparos de otras naves que les alcancen sumen puntuación. Cuando todos los jugadores hayan llegado a la línea de meta se dará opción a los jugadores de salir de la partida. C. Esquema de ejecución del videojuego En la figura 3 se muestra la ejecución del juego, tanto si es se trata de un cliente como del servidor. Fig. 3. Esquema de ejecución del juego Inicio: En el entorno de desarrollo de Unity 3D habrá una variable booleana para establecer qué versión exportada del videojuego actuará como servidor y cuál actuará como cliente. En esta pantalla de inicio se leerá esa variable para mostrar una pantalla u otra. Pantalla servidor: En esta pantalla está la opción de lanzar el servidor quien se encargará, en primera instancia, de asignar el identificador de usuario a cada cliente nuevo. Pantalla cliente: En la pantalla destinada al cliente habrá un menú para poder leer las instrucciones básicas del juego, indicar su nombre de usuario e iniciar el juego. Juego: A esta pantalla irán accediendo los jugadores con un identificador válido para poder jugar. Puesto que el número máximo de jugadores es cuatro, los identificadores permitidos para poder jugar serán el 0, 1, 2 y 3. Cuando se alcance el número máximo de jugadores el juego comenzará. Pantalla de máximo número de jugadores: Esta pantalla se mostrará cuando, habiéndose alcanzado el número máximo de jugadores para comenzar la partida, entre un nuevo jugador con la intención de unirse a ella. Salir: La opción de salir del juego se mostrará cuando todos los jugadores hayan llegado a la línea de meta (tanto en el servidor como en los clientes) o cuando un jugador quiera unirse a la partida estando ya el cupo completo. TABLA II TIPOS Y SUBTIPOS DE MENSAJES Tipo Subtipo solicitarID noSubtipo asignarID idPosible, idImposible posicionJugadores noSubtipo, masPosicion, menosPosicion rotacionJugadores noSubtipo saltar noSubtipo mover noSubtipo disparar noSubtipo puntuacion noSubtipo, puntuacionFinal, puntuacionPerdida boostVelocidad noSubtipo boostDisparo noSubtipo circuito circuitoIniciado, circuitoAcabado D. Comunicación entre servidor y cliente En el diseño del videojuego, el servidor controlará todos los eventos que ocurran en el desarrollo del juego (movimiento de las naves, disparos, incremento de la puntuación,…) e informará de ello a los clientes. La función del servidor a implementar es la de un servidor autorizado, es decir, todos los mensajes generados por los clientes deben ser enviados al servidor y será éste quien se encargue de validarlos y de enviar la información correspondiente al resto de clientes. Los clientes, por su parte, enviarán al servidor los eventos que afecten al movimiento y a la generación de disparos, además de interpretar los mensajes recibidos por parte éste. La comunicación entre servidor y cliente se harán mediante UDP (User Datagram Protocol). Para tal fin se diseñará un protocolo capaz de transmitir cualquier tipo de mensaje y con las opciones que requiera cada uno de ellos. Para el desarrollo del proyecto se ha tenido en cuenta que los mensajes más importantes para obtener una buena experiencia de juego (mensaje de posición y mensaje de rotación) sean periódicos, evitando así que la pérdida de un paquete afecte a la totalidad de la partida. E. Formato de los mensajes La estructura del mensaje a enviar se detalla en la figura 4. Se ha considerado que el mensaje periódico fundamental para que el juego se desarrolle con normalidad es el mensaje de posición de los jugadores. Durante la ejecución del videojuego, tanto servidor como cliente intercambiarán mensajes de distintos tipos (Tabla II). Por parte del servidor: asignación de identificador, posición de los jugadores, rotación de los jugadores, generación de disparo, envío de la puntuación, bonificación de velocidad y bonificación de disparo. Por parte del cliente: petición de identificador, saltar, mover, disparar, reenvío de la puntuación, inicio/fin del circuito y cambio en la periodicidad de los mensajes. F. Descripción del algoritmo adaptativo El esquema de adaptación (figura 5) que se ha diseñado en este proyecto consiste en modificar el periodo de envío 𝑡𝑝𝑖 de la información del servidor al cliente i-ésimo. De esta manera, cuando el cliente i-ésimo detecte que varía el ancho 39 IT / Aplicaciones en red de banda disponible, también variará la tasa de envío a ese cliente. Para ello se tendrán en cuenta dos factores: El primero es identificar si el periodo de envío es mayor que la tasa de bits disponible o no. Para ello se hará un estudio del tiempo transcurrido entre los mensajes recibidos y los esperados. En caso de que esta diferencia de tiempo sea positiva se solicitarán menos mensajes, en caso contrario se solicitarán más. El segundo es limitar esa diferencia de tiempo a un valor umbral para el que, al sobrepasarse, se envíe la solicitud de cambiar la periodicidad de los mensajes. Fig. 5. Esquema de funcionamiento del protocolo G. Estimación de cambio en la tasa de bits disponible En cada frame, cada cliente calcula la secuencia del mensaje que espera recibir, 𝑠𝑒, siguiendo la siguiente fórmula: 𝑠𝑒= 𝑡𝑎−𝑡0 𝑡𝑝𝑖+ 𝑠𝑎(1) -𝑡𝑎 es el instante del frame actual. -𝑡0 es el instante en el que comienza a ejecutarse el juego. -𝑡𝑝𝑖 es el periodo de envío del paquete del servidor al cliente i. -𝑠𝑎 es la secuencia anterior al cambio de 𝑡𝑝𝑖 (inicialmente tiene valor 0). Posteriormente se calcula el retardo entre la secuencia recibida y la esperada. Este retardo puede ser positivo o negativo, en el primer caso se detecta un aumento de la tasa de bits disponible y en el segundo, una disminución de la tasa de bits disponible. Si este retardo supera un determinado valor umbral, , tanto por exceso como por defecto, para un determinado número de secuencias  en un periodo de tiempo , el cliente i solicitará al servidor una variación en el periodo de envío del paquete 𝑡𝑝𝑖. V. IMPLEMENTACIÓN A. Implementación de la interfaz Unity 3D facilita la creación de las distintas escenas entre las que se irá navegando: Menú: En esta escena se indica si la aplicación ejecutada es el servidor o el cliente. Menú Servidor: Escena destinada al servidor y cuya única función es iniciar el servidor. Menú Cliente: Escena que se ejecuta en cada uno de los clientes donde se puede consultar las instrucciones del juego, elegir un nombre de usuario y ejecutar el juego. Instrucciones: Escena con los controles y el funcionamiento del juego. Escena: Se trata del circuito donde se desarrolla la competición. Salir sin ID: Escena que se muestra en caso de que un nuevo usuario quiera unirse a la partida habiéndose alcanzado el número máximo de jugadores. B. Implementación del protocolo adaptativo Para poder enviar el tipo y el subtipo dentro del mismo byte, se hace uso de 4 bits para identificar al tipo y otros 4 bits para el subtipo (declarados como constantes en hexadecimal). El proceso se detalla a continuación: Emisor del mensaje: Se realiza la operación “OR” tipo|subtipo. Receptor del mensaje: Se realiza la operación “AND” recibido&F0 para obtener el tipo y recibido&0F para el subtipo. VI. ESTUDIO DEL TRÁFICO DE RED Y EVALUACIÓN DEL PROTOCOLO ADAPTATIVO Para evaluar el diseño del juego y del protocolo adaptativo se hará uso del programa Network Emulator Client [4] para limitar la red y del capturador de paquetes Wireshark [5] para analizar el tráfico generado. A. Análisis para un jugador A continuación se muestran los resultados obtenidos cuando existe un único jugador. Las gráficas representan el número de secuencia frente al tiempo, tanto para los mensajes recibidos (rojo) como los esperados (verde). Sin limitación de ancho de banda: Fig. 6. Sin limitación 40 P. Peña Martínez (tutores J.J. Ramos Muñoz y J.M. López Soler): Diseño de un juego con requisitos de tiempo real para redes móviles Con limitación a 2.2kbps: Fig. 7. Con 2.2kbps de limitación Con limitación a 1.6kbps: Fig. 8. Con 1.6kbps de limitación A medida que se limita el ancho de banda el retardo se hace cada vez más notorio. B. Análisis para un jugador con protocolo adaptativo Se analizan los resultados obtenidos con el protocolo adaptativo cuando hay un jugador activo. Sin limitación de ancho de banda: Fig. 9. Sin limitación con protocolo adaptativo Con limitación a 2.2kbps: Fig. 10. Con 2.2kbps de limitación con protocolo adaptativo Con limitación a 1.6kbps: Fig. 11. Con 1.6kbps de limitación con protocolo adaptativo Se puede apreciar que, a medida que se ejecuta el juego, el protocolo va adaptando la frecuencia de los mensajes para que el retardo obtenido sea el mínimo. C. Evaluación del retardo medio En la figura 12 se representa el retardo medio asociado a los mensajes de posición para el caso de un jugador tanto sin técnica (rojo) como con ella (verde). Fig. 12. Retardo medio para un jugador 41 IT / Aplicaciones en red Como puede observarse, al aplicar el algoritmo adaptativo, siempre se reduce el retardo, funcionando mejor cuando hay más limitación de ancho de banda. Concretamente, se reduce de 27.83 a 3.73 (7.76 veces menos) en el caso de la limitación de 1.2kbps. D. Evaluación de las bonificaciones obtenidas En la figura 13 se evalúa el resultado que experimentaría un usuario de forma numérica. Cada nave está programada para ir recogiendo todas cajas de bonificación. Fig. 13. Bonificaciones obtenidas para un jugador VII. CONCLUSIONES A. Conclusiones generales En el proyecto se ha desarrollado un juego multijugador en línea con hasta 4 jugadores jugando de forma simultánea y un protocolo adaptativo que mitiga los efectos del retardo asociado a la limitación del ancho de banda, mejorando la calidad de experiencia de los usuarios. B. Trabajo futuro y mejoras Pese a que el juego cumple las funciones establecidas, se enumeran a continuación una serie de mejoras que podrían añadirse: Añadir más circuitos permitiendo a los jugadores realizar una clasificación global tras haberlos recorrido todos y no siempre dar vueltas sobre el mismo circuito. Añadir objetos o enemigos (ajenos a los jugadores) que pretendan colisionar con nosotros para hacer que perdamos puntuación o ralentizarnos. Adaptar los controles para poder ejecutarse en smartphones y tablets (pantalla táctil, uso del giroscopio,…). El protocolo adaptativo puede mejorarse en los siguientes puntos: Evaluar el retardo en los mensajes de información secundaria y decidir también para ellos cuándo es necesario aumentar o disminuir la frecuencia de los mismos, ya que en esta versión los mensajes de posición son los más importantes. Calcular la distancia entre las naves y, si es superior a un valor, no enviar mensajes referentes a ese jugador para ahorrar ancho de banda. Diseñar un mecanismo de control que detecte la pérdida de paquetes y permita el reenvío de los que se han perdido. Tipo|Subtipo (4bits|4bits) ID (1B) Número Secuencia (2B) Posición (12B) Rotación (16B) Puntuación (4B) Bonificación (12B) Número Caracteres Usuario (1B) Primer Carácter Usuario (1B) … (nB) Último Carácter Usuario (1B) Fig. 4. Estructura general del mensaje AGRADECIMIENTOS Agradezco a mi familia el apoyo y ánimo recibidos durante todos estos años que ha durado esta etapa de mi vida. Gracias también a los profesores Juan José Ramos Muñoz y Juan Manuel López Soler por la dedicación y aporte de conocimientos para que la realización de este proyecto haya sido posible. REFERENCIAS [1] Asociación Española de Videojuegos. Ranking General, abril 2016: http://www.aevi.org.es/la-industria-del-videojuego/los-videojuegosmas-vendidos/ [2] José Mª Saldaña, Julián Fernández Navajas, José Ruiz Mas, José I. Aznar, Eduardo Viruete Navarro, Luis Casadesus. Ahorro de Ancho de Banda en Juegos Online Mediante el uso de Técnicas de Tunelado, Compresión y Multiplexación: http://diec.unizar.es/~jsaldana/personal/juegos_jitel_2011_in_proc.pdf [3] Eduardo Cuervo, Alec Wolman, Landon P. Cox, Kiron Lebeck, Ali Razeen, Stefan Saroiu, Madanlal Musuvathi. Kahawai: High-Quality Mobile Gaming Using GPU Offload: http://research.microsoft.com/enus/people/cuervo/mobi093f-cuervoA.pdf [4] Network Emulator Client: https://blog.mrpol.nl/2010/01/14/networkemulator-toolkit/ [5] Web de Wireshark: https://www.wireshark.org/ Pablo Peña Martínez nacido el 22 de Octubre de 1988 en Granada. Ingeniero de Telecomunicación por la Universidad de Granada desde Junio de 2016. Disfrutó de una beca ERASMUS en l’École Polytechnique d’Ingénieurs de l’Université de NiceSophia Antipolis (Francia). 42 P. Peña Martínez (tutores J.J. Ramos Muñoz y J.M. López Soler): Diseño de un juego con requisitos de tiempo real para redes móviles Implementaci´ on de una aplicaci´ on cliente para Chromecast Autor: Irene Herrera L´ opez, e-mail: [email protected] Tutor: Jorge Navarro Ortiz, e-mail: [email protected] Titulaci´ on: Grado en Ingenier´ ıa de Tecnolog´ ıas de Telecomunicaci´ on Departamento de Teor´ ıa de la Se˜ nal, Telem´ atica y Comunicaciones Universidad de Granada Resumen—El proceso evolutivo del ser humano y sus etapas han estado marcadas por avances significativos que han tenido lugar en diferentes ´ ambitos de la sociedad. Durante los ´ ultimos a˜ nos, la vida del ser humano ha estado ligada a la evoluci´ on tecnol´ ogica, aprovechando sus ventajas y permaneciendo en una continua b´ usqueda de nuevas funcionalidades innovadoras que incorporar a su vida diaria. As´ ı, se han ido insertando dispositivos tecnol´ ogicos, cada vez m´ as inteligentes, en el ´ ambito profesional. En este Trabajo Fin de Grado se pretende aprovechar esta tendencia para hacer del proceso de proyecci´ on de material docente una tarea que proporcione al ponente de una mayor libertad frente a las limitaciones que suponen los sistemas cableados actuales. Para ello, se aunar´ an las ventajas que presentan los dispositivos de transmisi´ on y reproducci´ on de contenido multimedia, m´ as concretamente, las ventajas de Chromecast, junto a la utilidad de los dispositivos m´ oviles inteligentes o smartphones. La conjunci´ on de ambos elementos supondr´ a ua pieza clave para la obtenci´ on de una soluci´ on software que permita al docente o estudiante de la Universidad de Granada proyectar material, con fines educativos, desde su smartphone a una pantalla secundaria o panel de proyecci´ on de manera inal´ ambrica, simple y sencilla. Palabras clave—Android, Chromecast, docencia, Google Cast. I. INTRODUCCI ´ ON ESTE proyecto puede considerarse como un estudio de investigaci´ on en el ´ ambito de la tecnolog´ ıa educativa, por lo que en un primer lugar se proceder´ a con una introducci´ on sobre el uso innovador de las TICs (Tecnolog´ ıas de la Informaci´ on y Comunicaci´ on) en la docencia universitaria. La ense˜ nanza ha sido, y sigue siendo, un proceso interactivo, por lo que consideraremos la tecnolog´ ıa como una herramienta personal m´ as que como un medio para educar. La tecnolog´ ıa no pretende reemplazar el valor humano, sino servir como una extensi´ on de ´ este [1]: A continuaci´ on se van a describir algunas de las ventajas m´ as significativas que supone el uso de la tecnolog´ ıa con fines docentes [2]. •Aumentar la atenci´ on, la motivaci´ on y la participaci´ on del alumnado. •Facilitar la ense˜ nanza, el aprendizaje, la comprensi´ on de los temas y la consecuci´ on de objetivos marcados. •Favorecer la renovaci´ on metodol´ ogica del docente o ponente. •Aumentar la satisfacci´ on, la motivaci´ on y la autoestima del docente. II. MOTIVACI ´ ON La sociedad se ha acostumbrado a tener acceso permanente y ubicuo a la comunicaci´ on e informaci´ on. Ello ha supuesto un giro en el concepto de percepci´ on de la realidad y en los h´ abitos de la comunidad y, por supuesto, tambi´ en en las aulas y la docencia. Y no es s´ olo la sofisticaci´ on tecnol´ ogica lo que nos interesa, sino tambi´ en la revoluci´ on creativa que todo ello supone. Desde las reuniones en las ´ agoras de la Antigua Grecia hasta los proyectores multimedia inal´ ambricos, pasando por pizarras convencionales y transparencias de acetato, han sido m´ ultiples vicisitudes las que se han superado. Pero, ¿cu´ al es el estado actual de los sistemas de proyecci´ on de material de apoyo a la docencia? La mayor´ ıa se rigen por dos configuraciones, una primera en la que el aula dispone de un proyector y un ordenador conectado a ´ este, a disposici´ on de estudiantes y profesorado, para que puedan introducir en ´ el sus dispositivos de almacenamiento y memoria externa. El segundo escenario m´ as com´ un depende de la disponibilidad de un ordenador port´ atil personal, y sus correspondientes adaptadores, por parte del ponente que va a realizar su clase magistral. A diferencia de otras TICs, los smartphones ya est´ an en las manos de alumnos y profesores, ya que son casi universalmente accesibles. Este hecho representa un menor coste que el equipamiento de las aulas con ordenadores y proyectores inal´ ambricos. Aunque no est´ a ampliamente extendido dentro de los sistemas de proyecci´ on de material docente, prodr´ ıa suponer un aspecto a tener en cuenta gracias, entre otras ventajas, a la movilidad y flexibilidad que estos aportan. Y es por esto por lo que se ha pretendido encontrar una soluci´ on que aunara la comodidad de las tecnolog´ ıas inal´ ambricas y m´ oviles junto al equilibrio calidad-precio. III. REQUISITOS La idea principal de este estudio es desarrollar una aplicaci´ on cliente para el dispositivo Chromecast [3], que permita a los usuarios enviar contenido multimedia (con fines docentes) a una pantalla secundaria. Se pretende que ese proceso sea sencillo y transparente para el docente o ponente. Buscando la comodidad de ´ este, se procurar´ an reducir las conexiones cableadas para as´ ı dotar al usuario de una mayor movilidad. Adem´ as, se definir´ a un sistema de control de sesiones y un gestor de archivos que facilite al usuario la b´ usqueda y proyecci´ on del material deseado. Junto a los Teoría de la Señal, Telemática y Comunicaciones, 2016, ISBN-13 978-84-617-5449-6, páginas 43-48 anteriormente definidos requisitos funcionales, pasaremos a describir los requisitos no funcionales. El primero de ellos, y el m´ as restrictivo, es el uso del dispositivo Chromecast. Este peque˜ no, pero a la vez potente, dispositivo fue presentado en el anteproyecto por el tutor como una condici´ on o cl´ ausula indispensable para la obtenci´ on de la soluci´ on final. Como motivaci´ on adyacente, el coste econ´ omico y las diferentes posibilidades que presentan las APIs (Application Programming Interface) de Google suponen una gran ventaja frente a otros dispositivos similares presentes en el mercado como pueden ser Apple TV [4], productos de la familia Roku [5] y la m´ as reciente incorporaci´ on a este mercado, el MatchStick [6] de Firefox. Otro requisito no funcional ser´ a el uso del sistema operativo Android para desarrollar la aplicaci´ on m´ ovil, ya que al estar desarrollado por Google, al igual que Chromecast, existe una amplia variedad de recursos y librer´ ıas disponibles para estas herramientas. IV. CHROMECAST En este apartado vamos a presentar al principal protagonista de este trabajo. Chromecast es un dispositivo con formato de stick o pincho que presenta un puerto HDMI (High-Definition Multimedia Interface) a trav´ es del cual se conecta a la pantalla secundaria en la que queramos realizar la proyecci´ on. Su principal prop´ osito es la transmisi´ on y reproducci´ on de contenido multimedia. Dise˜ nado y distribuido por Google, entre sus caracter´ ısticas m´ as importantes podemos destacar que soporta el est´ andar IEEE 802.11b/g/n aunque s´ olo en la banda de 2,4 GHz, presenta un s´ olo n´ ucleo o core y es necesario conectarlo a una fuente de corriente haciendo uso del puerto USB (Universal Serial Bus) que presenta. Aunque se ha realizado una investigaci´ on m´ as amplia sobre el funcionamiento del dispositivo, a manera de resumen, procederemos a listar los protocolos m´ as significativos que toman parte en las comunicaciones durante una sesi´ on con Chromecast. •El dispositivo Chromecast opera con el protocolo DIAL (Discovery And Launch) [7], que habilita al cliente a descubrir al servidor DIAL (Chromecast) en su red local y, as´ ı, obtener acceso a los servicios DIAL. •El protocolo RAMP (Remote Application Media Protocol) es propietario de Google y se usa para enviar mensajes de control de contenido multimedia al dispositivo. Estos comandos se env´ ıan a trav´ es de un websocket en formato JSON, siendo un websocket una tecnolog´ ıa que proporciona un canal de comunicaci´ on bidireccional y full-d´ uplex sobre un ´ unico socket TCP. •Para enviar contenido al dispositivo existen dos alternativas principales. La primera de ellas es enviar la pantalla que estemos visualizando desde nuestro navegador web Google Chrome. Para ello, necesitaremos la extensi´ on Google Cast y el Chromecast cargar´ a la p´ agina web actual haciendo uso de WebRTC (Web Real Time Communication). La otra alternativa, y la que emplearemos en este estudio, es enviar el contenido multimedia desde una aplicaci´ on cliente. Al realizar el env´ ıo, el dispositivo cargar´ a un p´ agina web ligera usando los protocolos, HTML5 (HyperText Markup Language, versi´ on 5), JavaScript y CSS (Cascading Style Sheets), entre otros. V. DISE ˜ NO E IMPLEMENTACI ´ ON En esta secci´ on centraremos nuestra atenci´ on en el dise˜ no e implementaci´ on de la aplicaci´ on para Android que se ha desarrollado como soluci´ on a este proyecto. Esta soluci´ on software se puede dividir en diferentes bloques, que iremos abordando de manera individual a continuaci´ on. A. Autenticaci´ on y autorizaci´ on Antes de proceder con la implementaci´ on de este bloque, vamos a definir los conceptos de autenticaci´ on y autorizaci´ on. La autenticaci´ on no determina qu´ e tareas puede llevar a cabo el usuario o qu´ e datos puede visualizar, ya que s´ olo identifica y verifica al usuario. Por otro lado, la autorizaci´ on consiste en dar acceso a una serie de recursos al usuario, previamente autenticado. En nuestro caso, podemos tomar ambos conceptos como un solo bloque, debido a que el usuario que se autentique correctamente tendr´ a acceso a la aplicaci´ on en su totalidad. Para la implementaci´ on del presente bloque se ha recurrido a las siguientes herramientas: •PHP (Hypertext Preprocessor) [8]. Lenguaje de programaci´ on utilizado para definir los archivos de configuraci´ on y las tareas que se van a llevar a cabo en el sistema de autenticaci´ on (acceso, alta y baja de usuarios, comprobaci´ on de credenciales...) •HTML (HyperText Markup Language). Utilizaremos este lenguaje para crear una simple p´ agina web que recoja el formulario para el alta de nuevos usuarios. En este formulario, el usuario podr´ a definir la combinaci´ on ´ unica de nombre de usuario y contrase˜ na que lo identificar´ a posteriormente en el sistema. •Base de datos, MySQL. Gestor de la base de datos en la que almacenaremos toda la informaci´ on referente a los usuarios. Ser´ a consultada para discernir si la autenticaci´ on es correcta o no. En la figura 1 podemos observar el diagrama de estados que seguir´ a la actividad de Android correspondiente a este bloque. Esta ser´ a la primera actividad que se ejecutar´ a al lanzar nuestra aplicaci´ on y se encargar´ a de recoger los datos introducidos por el usuario (nombre de usuario y contrase˜ na). Tambi´ en contiene el m´ etodo que realiza la validaci´ on del usuario con los datos dados. Dichos datos ser´ an enviados al sistema de autenticaci´ on, siendo la respuesta a la validaci´ on un objeto con formato JSON (JavaScript Object Notation). Si la autenticaci´ on tiene ´ exito, se invocar´ a la siguiente actividad. B. Sistema de archivos El material docente que se pretende proyectar ser´ a almacenado en la memoria externa del dispositivo (en la tarjeta de memoria SD Secure Digital). Para tener acceso a dicho directorio, haremos uso de la clase Enviroment [9] de Android, que proporciona acceso a distintas variables del entorno y, m´ as concretamente, usaremos el m´ etodo getExternalStorageDirectory de dicha clase. Este m´ etodo devuelve el directorio ra´ ız del almacenamiento externo del dispositivo m´ ovil (e.g. /storage/emulated/0/). A grosso modo, primero comprobaremos que esa ruta devuelta exista. En caso afirmativo, crearemos una lista en la que iremos almacenando los distintos directorios a los que se 44 I. Herrera López (tutor J. Navarro Ortiz): Implementación de una aplicación cliente para Chromecast van accediendo, con el fin de conseguir la ruta completa del archivo final que seleccionemos. Se ha habilitado la opci´ on de navegaci´ on hacia atr´ as, con lo que se eliminar´ a el ´ ultimo directorio a˜ nadido de la lista mencionada anteriormente. Adem´ as de la ruta, debemos obtener el nombre y la extensi´ on del archivo deseado. La extensi´ on ser´ a un par´ ametro muy importante, clave para discernir el siguiente paso de nuestra aplicaci´ on. El dispositivo Chromecast presenta una serie de limitaciones en cuanto a formatos de archivos que soporta se refiere. Es por ello por lo que se ha decidido limitar los formatos soportados en nuestra aplicaci´ on a las extensiones de im´ agenes PNG (Portable Network Graphics), GIF (Graphics Interchange Format) y JPG/JPEG (Joint Photographic Experts Group). Cualquier otro tipo de im´ agenes lanzar´ a un mensaje de error. Tambi´ en se aceptar´ an los archivos de tipo PDF (Portable Document Format) que, aunque no es un formato soportado directamente por Chromecast, es el principal objetivo de esta soluci´ on software. En la figura 2 podemos ver de manera m´ as gr´ afica el proceso descrito anteriormente. C. Conversi´ on de PDF Para solventar las limitaciones mencionadas en el apartado anterior de la SDK (Software Development Kit)Google Cast [10] que rige el comportamiento del dispositivo Chromecast, se ha optado por convertir el archivo de tipo PDF que se desea enviar al Chromecast en im´ agenes, es decir, obtener una imagen por cada una de las p´ aginas que conformen el archivo PDF. En la figura 3 se detalla el proceso para realizar dicha conversi´ on. En ella, se muestran dos procesos paralelos para el tratamiento de las im´ agenes y ello se debe a que, adem´ as de visualizar el documento en una pantalla secundaria, queremos que tambi´ en se muestre en la pantalla de nuestro smartphone. As´ ı, utilizaremos un objeto de tipo WebView [11] en Android, que se encarga de mostrar p´ aginas web ligeras. A continuaci´ on vamos a resumir el proceso llevado a cabo para lograr esta tarea. Primeramente obtendremos un objeto de tipo PDFFile a partir de un buffer de bytes que conforman el documento PDF seleccionado. Una vez hecho esto, debemos extraer la Fig. 1. Diagrama de estados del sistema de autenticaci´ on. primera p´ agina del documento. Despu´ es, obtendremos una escala a partir del ancho del elemento WebView y posteriormente convertiremos la p´ agina en una imagen de tipo bitmap en funci´ on de esa escala obtenida. Esa imagen obtenida debemos guardarla como un array o cadena de bytes para codificar dicha cadena en base 64. As´ ı obtenemos una cadena de caracteres que conformar´ an un objeto de tipo HTML, al que iremos a˜ nadiendo consecutivamente el resto de im´ agenes tratadas siguiendo este mismo proceso. Para proyectar las im´ agenes con Chromecast podr´ ıamos reutilizar el resultado de la codificaci´ on en base 64 para enviar cada una de las im´ agenes, codificadas como una cadena de caracteres, con el m´ etodo sendMessage disponible en la SDK Google Cast, para posteriormente decodificarlas usando una aplicaci´ on receptora de tipo Custom Receiver [12]. Sin embargo, no es recomendable usar dicho m´ etodo para enviar grandes cantidades de datos, ya que ese canal est´ a indicado para ser usado como canal de control y no para enviar datos. Por esta raz´ on, se ha optado por una alternativa m´ as robusta que consiste en empotrar o implementar un servidor web en nuestra aplicaci´ on local, es decir, en el tel´ efono m´ ovil que realizar´ a las funciones de emisor. As´ ı, ”serviremos” las im´ agenes obtenidas de cada una de las p´ aginas del archivo PDF (convertidas previamente a un formato de imagen compatible) al Chromecast haciendo uso del Styled Media Receiver [13] que hemos adaptado para que muestre el logotipo y nombre de esta aplicaci´ on durante los tiempos de espera. Como servidor web hemos elegido la herramienta NanoHTTPD [14], de c´ odigo abierto y f´ acil de configurar. D. Conexi´ on y env´ ıo de im´ agenes La API (Application Programming Interface)Media Router [15] habilita las conexiones entre los dispositivos Android y Fig. 2. Diagrama de estados del sistema de archivos. 45 IT / Aplicaciones en red Chromecast para poder reproducir contenido multimedia. En la figura 4 se visualiza el esquema de funcionamiento de la mencionada API. Tambi´ en debemos a˜ nadir a nuestro proyecto la librer´ ıa de los servicios de Google Play para el correcto funcionamiento de la SDK de Google Cast. En la figura 5 se muestran los botones que se han habilitado en la cabecera de la aplicaci´ on para facilitar el proceso de reproducci´ on de contenido multimedia. •El primer bot´ on que se muestra es el denominado bot´ on Cast. Informa del estado de la conexi´ on con el dispositivo Chromecast en funci´ on de su color. •El segundo bot´ on sirve para lanzar el proceso de env´ ıo de material. Haremos uso de la clase MediaInfo de la SDK Google Cast, que agrega informaci´ on sobre el elemento multimedia que pretendemos enviar. Crearemos una instancia de esta clase mediante un constructor, que ser´ a usado por la clase RemoteMediaPlayer para cargar el contenido multimedia en la aplicaci´ on receptora. •Por ´ ultimo, se pueden apreciar dos botones con forma de flechas cuya funci´ on es avanzar y retroceder las p´ aginas que conforman el documento PDF. Cada vez que pulsemos alguno de estos botones, obtendremos la direcci´ on IP del dispositivo m´ ovil (aquella que Fig. 3. Diagrama de estados del sistema de conversi´ on de archivos PDF. Fig. 4. Diagrama del uso de clases de la API Media Router. apunta a la imagen que queremos visualizar con Chromecast y que ha sido servida por medio del servidor web embebido, junto al puerto en el que ´ este est´ a disponible). Adem´ as, a˜ nadiremos al final de esta direcci´ on la hora actual en milisegundos con el m´ etodo System.currentTimeMillis(). Si no incluy´ esemos esta marca temporal, el receptor siempre estar´ ıa almacenando en la cach´ e la misma imagen, ya que la URL (Uniform Resource Locator) que estamos pasando es siempre la misma para todas las im´ agenes. Por ello, hay que forzar al receptor a recargar la imagen a˜ nadiendo dicha marca temporal (o timestamp) o cualquier otro marcador a la URL, para que el navegador la reconozca como un nuevo recurso. Cabe destacar que en el caso de que se desee enviar una sola imagen permanecer´ an desactivados estos dos ´ ultimos botones ya que no existen p´ aginas que avanzar o retroceder. E. Otros aspectos de la implementaci´ on A continuacion vamos a mencionar otros aspectos referentes a la implementaci´ on. Se trata de funcionalidades secundarias que tienen como principal objetivo facilitar el uso de la aplicaci´ on por parte del usuario. •Se ha dise˜ nado un men´ u desplegable, accesible en el lateral de la aplicaci´ on, en el que se muestran las diferentes opciones de navegaci´ on. Para ello se ha elegido Navigation Drawer [16] de Android. •Perfil de usuario. Es uno de los apartados disponibles en el men´ u, en el que se muestra informaci´ on referente a la red a la que estamos conectados. Tambi´ en se han habilitados dos botones, uno de ellos para cerrar la sesi´ on y el otro permite dar de baja a nuestro usuario. El proceso de dar de baja la cuenta de un usuario significa la eliminaci´ on de sus credenciales de nuestra base de datos. •Sugerencias. Otro apartado disponible en el men´ u. En ´ este se muestra informaci´ on sobre la aplicaci´ on y un bot´ on que permite elegir un cliente de correo electr´ onico para enviar un email con sugerencias o reportes. Por defecto, se rellenar´ a el campo To con el correo de la autora de este estudio. Por ´ ultimo, y para finalizar esta secci´ on, en la figura 6 se muestran algunos ejemplos de la interfaz de usuario de la aplicaci´ on implementada. VI. RESULTADOS Y PRUEBAS La metodolog´ ıa que se ha seguido para completar la primera versi´ on totalmente funcional de esta aplicaci´ on ha sido un modelo de desarrollo en espiral, en el que se ha alcanzado la soluci´ on a partir de distintas iteraciones. Cada una de ellas ha ido aportamdo funcionalidades al sistema dise˜ nado y se han podido aislar los problemas mediante la realizaci´ on de Fig. 5. Botones disponibles en la cabecera de la aplicaci´ on. 46 I. Herrera López (tutor J. Navarro Ortiz): Implementación de una aplicación cliente para Chromecast pruebas unitarias. Todo ello ha facilitado la validaci´ on de la aplicaci´ on completa. La fase de an´ alisis y control de calidad podr´ ıa definirse como una de las etapas cr´ ıticas en el ciclo de vida del desarrollo de un producto software. •Pruebas de rendimiento. En este bloque se han realizado una serie de pruebas en las que se han analizado estad´ ısticas de red, informaci´ on del sistema y memoria ocupada. Se ha comprobado, entre otros aspectos, que la cantidad de datos que se consumen durante una sesi´ on de proyecci´ on es ligeramente superior al tama˜ no total del archivo transmitido. El excedente se debe a los mensajes de control que se intercambian en la comunicaci´ on. En cuanto al procentaje de uso de la CPU (Central Processing Unit), ´ esta no supone una gran carga para el dispositivo smartphone. Tambi´ en se ha analizado la memoria din´ amica, donde el t´ ermino heap hace referencia a un espacio de memoria en tiempo de ejecuci´ on que se usa para almacenar las instancias de clases, objetos y arrays [17]. Esto resulta relevante para controlar el uso de la pila de un proceso. Durante el proceso de proyecci´ on, el tama˜ no de la pila crece desordenadamente. Si el usuario realiza una pausa entre pases de diapositivas, podemos percibir como el tama˜ no de la pila se estabiliza. Fig. 6. Capturas de pantalla de la interfaz de usuario de diferentes apartados de la aplicaci´ on. •Pruebas de compatibilidad. Se ha comprobado el correcto funcionamiento de la aplicaci´ on bajo diferentes configuraciones de hardware y diferentes versiones del sistema operativo Android. Se ha establecido como versi´ on m´ ınima soportada de Android la versi´ on 4.0 (Ice Cream Sandwich), que corresponde con el nivel 15 de la API. Al establecer este m´ ınimo, se asegura alcanzar hasta al 94% de los dispositivos Android registrados. Para esta versi´ on m´ ınima, se ha detectado que no se visualiza el icono de la aplicaci´ on dispuesto en la cabecera de la misma. Exceptuando ese aspecto, el comportamiento y los tiempos de espera son similares en los distintos casos de uso y se consideran aceptables. •Pruebas de mantenimiento y uso. Esta soluci´ on software se ha dise˜ nado siguiendo un esquema modular, de tal manera que pueda ajustarse a posibles cambios en los requerimientos de la misma en un futuro. Por otro lado, esta herramienta puede ser usada f´ acilmente por los usuarios para los que ha sido dise˜ nada, con el apoyo de la documentaci´ on disponible. VII. CONCLUSIONES Y V´ IAS FUTURAS En resumen, se ha incorporado la versatilidad del dispositivo Chromecast en el ´ ambito docente, rompiendo las limitaciones que las conexiones cableadas impon´ ıan en el ponente o usuario final de esta aplicaci´ on. Por otro lado, debemos recordar que la incorporaci´ on del Chromecast a la infraestructura del aula supondr´ ıa una reducci´ on en el presupuesto que se destinar´ ıa a los ordenadores, cuya funci´ on ser´ ıa equivalente. Aunque se han alcanzado los objetivos que se propusieron en un principio, presentaremos una serie de mejoras o funcionalidades adicionales que pueden ser objeto de l´ ıneas futuras de trabajo: •Soporte para otros sistemas operativos m´ oviles como iOS oWindows Phone. •Integraci´ on con el sistema de autenticaci´ on de la Universidad de Granada. Este aspecto es actualmente incompatible con la tecnolog´ ıa del dispositivo Chromecast. •Sistema de recordatorio de contrase˜ na. •Compatibilidad con otros formatos como Powerpoint, Word de Microsoft Office o sus equivalentes para otros paquetes ofim´ aticos. •Conexi´ on con la nube. Se plantea la posibilidad de habilitar la conectividad con plataformas de almacenamiento en la nube como Google Drive oDropbox. En este apartado no s´ olo se quiere hacer referencia a la soluci´ on software alcanzada y su efectividad, sino que se pretenden recuperar los aspectos referentes a la tecnolog´ ıa y su implicaci´ on tanto en la sociedad en general, como en la educaci´ on en particular, que se introdujeron al principio de este escrito. Durante el desarrollo de este estudio ha surgido la reflexi´ on sobre los l´ ımites de los avances de la tecnolog´ ıa, ¿cu´ ales ser´ an las tendencias educativas del futuro? Es imposible predecir las tecnolog´ ıas que existir´ an dentro de veinte o treinta a˜ nos, pero s´ ı se pueden observar las tendencias, sin olvidar que la clave es pensar c´ omo queremos que sea la educaci´ on de ese futuro y, llegado ese momento, emplear la tecnolog´ ıa existente 47 IT / Aplicaciones en red Como vemos, los videos se están reproduciendo al mismo tiempo por lo que debería haber añadido cuatro flujos al menos referentes a dichos flujos. En efecto, al comprobar los flujos instalados, se corrobora que se han instalado estos cuatro flujos con el ToS cambiado para las direcciones IP de los servidores de vídeo. Además se incluyen otros flujos que no son propiamente del vídeo en sí pero que tienen que ver con el servidor de vídeo. En las siguientes figuras mostramos cada uno de los cuatro flujos instalados que presumiblemente transportan el vídeo por la red: Fig. 5. Flujos de vídeos de YouTube correspondientes a cada host. El sistema, pese a estar ejecutado en un entorno bastante limitado ya que se dispone únicamente de un portátil con tres máquinas virtuales corriendo en él, ha respondido ante cuatro equipos diferentes solicitando vídeos de YouTube. Además de los flujos referentes a YouTube se han añadido multitud de flujos de otro tipo al mismo tiempo. Con esta prueba se trata de acercar el concepto de integrar nuestro DPI en una red real de forma flexible. Para realizar pruebas de carga habría que tener acceso a una red donde haya carga real como, por ejemplo, la red de la UGR. No obstante estas pruebas están más allá del ámbito de este proyecto. V. CONCLUSIONES En el presente Trabajo de Fin de Grado se ha diseñado un Deep Packet Inspector haciendo uso de Mininet y gracias a otra serie de herramientas que se han ido acoplando en diferentes partes del proyecto. De esta forma se ha conseguido detectar, entre otros, el tráfico generado por YouTube dentro de una red emulada SDN. Una vez realizada esta detección hemos podido modificar dicho tráfico de tal forma que se añadiese una acción a la tabla de flujo capaz de modificar el ToS de los paquetes y propiciar así la posibilidad de ofrecer una Calidad de Servicio (QoS) en la red. Además, se ha experimentado con la implementación para comprobar el correcto funcionamiento del sistema desarrollado. Las principales contribuciones que nuestro proyecto ofrece son: - Ofrecer una gran recopilación de información en lo referente a este tipo de redes emergentes como son las SDN en cuanto a diferentes aspectos como son la gestión de red, monitorización o calidad de servicio. - Se ha experimentado con Mininet y OpenDayLight de manera que se aporta una gran fuente de información para comenzar a trabajar con estas herramientas. - El DPI desarrollado permite la detección precisa de los paquetes del servidor de vídeo YouTube. Para ello se ha realizado previamente un análisis exhaustivo de paquetes DNS necesario para obtener la dirección IP del servidor, a parte de un procedimiento posterior para detectar dicha IP tras la llegada de paquetes. Lo que nos permite este DPI por tanto será dar los medios (a través del campo ToS) para que la red proporcione calidad de servicio a ciertas aplicaciones o servicios, como en este caso el servicio de vídeo de YouTube. - En cuanto al análisis de paquetes DNS, una aportación importante es el desarrollo de un analizador de este tipo de paquetes, el cual no estaba implementado hasta el momento en OpenDayLight. - Otra aportación importante es la posibilidad de implementar a partir del DPI la detección de una gran multitud de tráfico referente a otras aplicaciones o servicios, ya que es un DPI modular y flexible en su desarrollo. REFERENCIAS [1] Cisco Corporation, «The Zettabyte Era—Trends and Analysis,» [En línea]. Available: http://www.cisco.com/c/en/us/solutions/collateral/serviceprovider/visual-networking-indexvni/VNI_Hyperconnectivity_WP.html. [2] YouTube, «Estadísticas oficiales de YouTube,» [En línea]. Available: http://www.ciscopress.com/articles/article.asp?p=170743. [3] CISCO, «CCNP Self-Study: Understanding and Implementing Quality of Service in Cisco Multilayer Switched Networks,» [En línea]. Available: http://www.ciscopress.com/articles/article.asp?p=170743. [4] ntop, «nDPI,» [En línea]. Available: http://www.ntop.org/products/deep-packetinspection/ndpi/. [5] BRO, «The Bro Network Security Monitor,» [En línea]. Available: https://www.bro.org/. [6] The fast mode, «Deep Packet Inspection Vendors & Products,» [En línea]. Available: http://www.thefastmode.com/deep-packet-inspectionvendors. [7] F5, «Policy Enforcement Manager,» [En línea]. Available: https://f5.com/products/service-provider-products/policyenforcement-manager. [8] Alcatel-lucent, «7750 Service Router - Mobile Gateway,» [En línea]. Available: https://www.alcatellucent.com/products/7750-service-router-mobile-gateway. [9] Bivio, «Bivio products,» [En línea]. Available: http://www.bivio.net/products/b7000/. [10] ORACLE, «VirtualBox,» [En línea]. Available: https://www.virtualbox.org/. [11] SNORT, «SNORT,» [En línea]. Available: https://www.snort.org/. 54 M. Sánchez López (tutor J. Navarro Ortiz): Análisis de redes SDN utilizando Mininet e implementación de un Deep Packet Inspector Resumen—Las redes definidas por software suponen una revolución tecnológica que se prevé domine el mercado de las redes de datos en el futuro, debido a la innegable necesidad de evolución de las redes actuales. Este nuevo paradigma de red presenta enormes ventajas teóricas frente a las redes tradicionales, y será objeto de este trabajo el estudio y explotación de estas nuevas capacidades. Las enormes ventajas que presenta este nuevo paradigma, han atraído la atención de grandes compañías de la industria, que no han tardado en diseñar y lanzar al mercado sus propias soluciones. La expectación generada en torno a las redes definidas por software no es más que otro indicador de su potencial. En este trabajo se realiza un amplio estudio que pretende desgranar los aspectos más técnicos de esta nueva arquitectura de red, confirmar todos los beneficios que proporcionan, y por último desarrollar servicios sobre la arquitectura Software Defined Networking para la provisión de calidad de experiencia. La solución final propuesta pretende aprovechar las características principales de SDN, centradas sobre tráfico multimedia. Para ello es necesario el diseño de un protocolo capaz de realizar diferenciación de tráfico, y además, reaccionar rápidamente ante cambios de red. Palabras clave—Controlador, Dijkstra, Java, Mininet, OpenDayLight, OpenFlow, QoE, QoS, Redes, Routing, SDN. I. INTRODUCCIÓN L crecimiento del tráfico multimedia experimentado en los últimos años, unido al crecimiento exponencial esperado (como las previsiones realizadas por cisco en [1]), ahondan en la necesidad de diseñar una arquitectura de red capaz de soportar y cumplir los requisitos para soportar tal cantidad de tráfico. Por otro lado, es recurrente la búsqueda de técnicas o arquitecturas de red capaces de reducir costes y aumentar capacidades sobre las que ofrecer nuevos servicios a los usuarios, por parte de operadores de red. Estas dos necesidades básicas en la industria han impulsado la adopción de redes definidas por software (Software Defined Networking) como solución con mayor aceptación, dadas las ventajas en las se hará hincapié a continuación. A. Motivación Para justificar este trabajo atendemos a los dos conceptos ya presentados. Por un lado la necesidad de responder ante las demandas de tráfico de manera flexible y rápida, mejorando la gestión y automatización de redes. Por otro, el tráfico multimedia precisa unos fuertes requisitos para su correcta transmisión. Esto lleva a las grandes compañías del sector a buscar nuevas fórmulas y modelos que permitan satisfacer las demandas para satisfacer los conceptos que se presentan a continuación. QoS. Definimos QoS como el rendimiento promedio de una red telemática. Cuantitativamente mide la calidad de los servicios en base a varios aspectos del servicio de red, tales como tasa de errores, ancho de banda, rendimiento, etc. QoE. Cuando se trata el término QoE se hace referencia a la calidad subjetiva que es percibida por un usuario final al disfrutar de un servicio ofrecido sobre una red telemática. Es una medida que se ve afectada por todos los elementos de la red extremo a extremo, que repercute en la percepción final por parte del usuario. B. Objetivos Los objetivos que a continuación se describen, pretenden sentar las bases sobre las cuales apoyar el resto del trabajo: Revisar el estado de la técnica sobre redes SDN, protocolo OpenFlow y principales controladores. Revisar el estado de la técnica sobre emulación de redes SDN, Mininet. Diseñar una solución capaz de proveer QoE en redes SDN. Implementar y evaluar dicha solución. II. REVISIÓN DEL ESTADO DEL ARTE A fin de sentar las bases sobre las que se desarrolle la solución que se propondrá, es necesario realizar un estudio previo sobre los principales conceptos de la arquitectura SDN, así como estudiar las principales tecnologías para el desarrollo de la solución. A. Arquitectura Software Defined NetWorking Las redes definidas por software se apoyan en la estructura que se muestra en la imagen 1, donde se aprecia con claridad la separación entre planos de control y datos. Esta separación supone un cambio respecto a las tecnologías que hasta ahora han dominado el sector. Se pretende que la toma de decisiones (plano de control) esté separada de las funciones de reenvío de paquetes (plano de datos). Tutor: Juan José Ramos Muñoz; e-mail: [email protected] Titulación: Grado en Ingeniería de tecnologías de Telecomunicación Departamento de Teoría de la Señal, Telemática y Comunicaciones Universidad de Granada Diseño y evaluación de un servicio OpenFlow de provisión de Calidad de Experiencia sobre Mininet Autor: Cristian Alfonso Prieto Sánchez, e-mail: cristia[email protected] E Teoría de la Señal, Telemática y Comunicaciones, 2016, ISBN-13 978-84-617-5449-6, páginas 55-60 Fig. 1. Arquitectura para la separación de planos de control y datos. Gracias a esta interpretación de red se consigue que todo el proceso de toma de decisiones se produzca en un solo plano, permitiendo la centralización de red. Ésta se verá reflejada en un elemento central, controlador, que será el encargado de la toma de decisiones en la red. De este modo se consigue: Beneficios técnicos. Mejora en la toma de decisiones. Mayor agilidad en la transmisión de órdenes a los elementos de red. Mayor agilidad en la convergencia de red, al mantener una visión global en un único elemento. Reducción de la complejidad de los elementos de red. Beneficios económicos. Reducción de CAPEX (CAPital EXpenditure). Gasto asociado a la inversión inicial. La reducción de la complejidad se traduce en equipos con menor coste. Reducción de OPEX (OPerational EXpenditure). Gasto asociado a los costes de operación. Mantener una visión global y centralizada de red, facilita el trabajo de los administradores de red.  Esta arquitectura está apoyada en los elementos que se definen a continuación. Controlador SDN. Elemento central que se encarga de aplicar la lógica definida (aplicaciones NorthBound) con los elementos de red (southBound). En la figura 2 se encuentra reflejada la comunicación entre controlador y el resto de elementos de la arquitectura, mediante el uso de APIs. Uno de los aspectos más interesantes de la arquitectura SDN, es que pretende aprovechar protocolos de red tradicionales (OSPF (Open Shortest Path First), BGP (Border Gateway Protocol), etc), aumentando de este modo la compatibilidad con los equipos de transporte. APIs (Application Programming Interface). Son las interfaces encargadas de permitir al controlador la comunicación con las aplicaciones SDN y con los elementos de red. Fig. 2. Visión esquemática de la estructura SDN. NorthBound API. Interfaz usada para facilitar la comunicación de aplicaciones con el controlador SDN. Esta API es crítica debido a la variedad de aplicaciones que pueden comunicarse con el controlador SDN, y que pueden provocar incompatibilidades siempre que no se respecto el modelo definido en cada caso. Para evitar problemas de este tipo, la Open Networking Foundation (https://www.opennetworking.org/index.php) crea un grupo de trabajo centrado en la definición de esta API, y el desarrollo de prototipos que ilustren las posibilidades de uso de ésta. SouthBound API. Es la interfaz encargada de posibilitar la comunicación del controlador con los elementos de red. Permite hacer cambios dinámicos en los elementos para adecuarse a las necesidades de cada elemento. Al adaptarse a los elementos subyacentes, se obtiene independencia de fabricantes, favoreciendo la visión abierta de la arquitectura. Existen diferentes implementaciones de esta API, donde la más extendida (a día de hoy) es OpenFlow. B. OpenFlow OpenFlow [2] es la primera interfaz de comunicaciones entre las capas de control y transporte en una arquitectura SDN. Permite el acceso directo y la manipulación de los elementos del plano de control. Las tecnologías SDN basadas en OpenFlow están capacitadas para abordar el gran ancho de banda y la naturaleza dinámica de las aplicaciones actuales. OpenFlow surge como solución para separar distintos tipos de tráfico dentro de switches y routers pensados solo para el transporte de datos. Uno de los objetivos es poder utilizar las tablas de flujo que ya implementan los switches para conseguir el objetivo de separación de tráfico. En el estándar OpenFlow se definen dos elementos principales. 56 C.A. Prieto Sánchez (tutor J.J. Ramos Muñoz): Diseño y evaluación de un servicio OpenFlow de provisión de Calidad de Experiencia sobre Mininet Fig. 3. Procesamiento de paquetes a través del proceso pipeline. Switch. Encargado del procesamiento de paquetes de acuerdo a las reglas instaladas previamente por el controlador. Estas reglas son instaladas en tablas de flujos del switch. Controlador. Elemento central de una red SDN y OpenFlow, capaz de evaluar el estado de red y añadir o eliminar entradas de flujo en los switches OpenFlow, de acuerdo a las aplicaciones instaladas en el controlador. El controlador puede ser una simple aplicación instalada en un PC, que instale flujos de forma sistemática, o por otro lado, puede ser un elemento dedicado a reaccionar de forma dinámica al estado de red. El funcionamiento de OpenFlow está basado en la definición de flujos e instalación en los switches. Una vez se definen los flujos, cada paquete que llega a un switch, es procesado por el proceso pipeline, resumido en la figura 3. Este esquema indica el camino a seguir por cada paquete que llega al switch. Normalmente los paquetes encontrarán coincidencias a través del procesamiento y se les aplicarán las acciones asociadas. Sin embargo puede darse el caso de no encontrar match (emparejamiento) alguno. En este segundo caso, los switches tienen varias acciones disponibles, la más común suele ser reenviar el paquete al controlador, el cual analizará el paquete e instalará los flujos pertinentes. C. OpenDayLight. Entre los controladores disponibles para SDN (y que hagan uso de OpenFlow), OpenDayLight (https://www.opendaylight.org/ es el más destacado. Es un proyecto de tipo abierto bajo la Linux Foundation, y que además, cuenta con el apoyo de muchas de las empresas dominantes en la industria. OpenDayLight cuenta con unas características que en el posterior desarrollo nos serán muy útiles. Entre ellas destacar que el desarrollo de aplicaciones se realiza en JAVA y, que cuenta con una estructura modular como la de la figura 4. Esta estructura está organizada en tres capas. Aplicaciones de red. En la capa superior se encuentran las aplicaciones diseñadas para encargarse del control y monitorización de red. Controlador. Es la capa central donde se manifiestan las abstracciones de SDN. El controlador OpenDayLight cuenta con una serie de módulos implementados que permiten a las aplicaciones de la capa superior obtener datos e información sobre el estado de red. Además cuenta con una serie de APIs que permiten el desarrollo de las aplicaciones superiores (API REST, JAVA API, DOM API). Además se implementan protocolos para la comunicación con elementos inferiores. Elementos de red físicos y virtuales. La capa inferior está constituida por aquellos elementos de red que son programables mediante los protocolos implementados por el controlador. Gracias a la capa de abstracción del controlador se consigue que los elementos sean compatibles con este. Apoyándonos en OpenFlow y el controlador OpenDayLight, diseñaremos una solución capaz de cumplir los objetivos propuestos. 57 IT / Redes definidas por software Fig. 4. Vista técnica del controlador OpenDayLight. Versión Helium. III. DISEÑO DE LA SOLUCIÓN A. Introducción. La solución diseñada en este proyecto se basa en aprovechar la potencia de un controlador SDN centralizado, para poder satisfacer los requisitos de calidad de varios flujos multimedia. Con este motivo, ha sido diseñado un protocolo de encaminamiento de estado de enlace para generar rutas óptimas por flujo multimedia. Este protocolo toma como costes distintas métricas que dependen del tipo de flujo para el que se crea la ruta. La solución se divide en 4 elementos diferenciados. B. Elementos. Clasificación de flujos de paquetes. A fin de escoger rutas óptimas para cada flujo, es necesario identificar y analizar a qué tipo de flujo corresponden los paquetes. En la solución se proponen cuatro tipos de tráfico para analizar. Tráfico ICMP (Internet Control Message Protocol), tráfico TCP, tráfico RTP (Real Time-Transport Protocol) audio y tráfico RTP Vídeo. Algoritmo de encaminamiento. Una vez reconocido el tipo de flujo, se requiere la obtención de la mejor ruta en la red según el destino del flujo. Los parámetros de QoS de los enlaces que componen dicha ruta, deben maximizar la calidad que perciba el usuario final. Para aplicar el algoritmo de encaminamiento, previamente es necesario estimar un coste asociado para cada enlace. Finalmente se aplicará el algoritmo de encaminamiento Dijkstra [3] y [4]. Definición de matriz de costes por enlace. La matriz de costes permite realizar una rápida asociación entre cada enlace y el coste asociado a este (para cada tipo de flujo). Para construir esta matriz de costes se definen varias funciones de calidad, y según el tipo de tráfico, se asignan unos pesos a cada función de calidad. Se definen cuatro funciones de coste: Latencia y jitter, pérdida de paquetes y carga en los enlaces. Estimación de parámetros de calidad. En función del tipo de flujo se ha de realizar una estimación sobre el peso de cada una de las funciones definidas para las matrices de costes. Como por ejemplo, la asignación realizada para RTP vídeo, donde la latencia tiene un peso menor a las pérdidas del enlace de transmisión. Recuperación de enlaces. Como método adicional a la provisión de calidad de experiencia, se ha previsto la inclusión de métodos de recuperación de enlaces. Este método (más propia de implementación) es el encargado de detección de cambios en la topología y eliminación de flujos obsoletos, que provocarían pérdidas de paquetes. Este método pretende ser capaz de detectar una caída de enlace y encaminar el tráfico por otra ruta del modo más rápido posible. Con estos elementos se ha realizado la implementación de la solución, la cual no tiene cabida en este resumen. A continuación se presentan los resultados y conclusiones obtenidas. IV. EVALUACIÓN DE LA SOLUCIÓN Para llevar a cabo una correcta evaluación sobre la solución propuesta, se ha decidido realizar una evaluación gradual, donde cada fase del diseño e implementación se evaluada de forma individualizada y posteriormente se evalúe el sistema completo. Se definen las siguientes evaluaciones. Evaluación sobre recolección de parámetros de red. Esta primera fase está dedicada a comprobar la validez de los datos recogidos sobre la red, estadísticas de enlaces y latencias de estos. Evaluación del cálculo de costes por enlace. A lo largo de esta fase se ajustarán los parámetros (pesos) asociados a las funciones de coste en función de flujo. Una vez ajustados los pesos, se evaluará la idoneidad de estos. Evaluación sobre el algoritmo de encaminamiento. Una vez diseñadas las funciones de coste y ajustados los parámetros, se evaluará la obtención de caminos, a fin de cerciorar que gracias a las evaluaciones anteriores, se escoge el camino óptimo en cada caso. Evaluación sobre la solución. Por último se proponen diferentes situaciones para comprobar la validez de la solución propuesta en diferentes ámbitos. En estas situaciones, a partir de datos como la latencia de paquetes o los paquetes perdidos se realizará una estimación de la escala MOS gracias a los modelos estándares. MOS significa Medium Opinion Score, y hace referencia a la percepción que tendría un cliente usando el servicio, dando una valoración subjetiva del funcionamiento de éste. A fin de centrar este resumen en los datos de mayor relevancia, se presentan los resultados sobre la solución final. V. RESULTADOS En esta sección se incluyen los resultados obtenidos para cada tipo de evaluación, sin embargo, a continuación solo se muestran aquellos sobre la solución final. Gracias al emulador de redes Mininet (http://mininet.org/) ha sido posible emular un entorno de red donde comprobar la validez de la solución propuesta. Para dicha evaluación se proponen los siguientes escenarios. 58 C.A. Prieto Sánchez (tutor J.J. Ramos Muñoz): Diseño y evaluación de un servicio OpenFlow de provisión de Calidad de Experiencia sobre Mininet Fig. 5. Primer escenario para evaluación de la solución. Para obtener la calidad de experiencia obtenida por un usuario, a partir de resultados objetivos (como latencia o pérdida de paquetes) se ha decidido hacer uso de la recomendación G. 107 de la ITU [5] y la recomendación G. 1070 de la ITU [6]. De este modo, a partir de datos objetivos, se obtendrán valores de la escala MOS. Fig. 6. Segundo escenario para la evaluación de la solución. MOS Calidad Percepción de Problemas 5 Excelente Imperceptibles 4 Buena Algunos pero sin provocar descontento 3 Regular Descontento aceptable 2 Mediocre Descontento 1 Mala Imposible usar Tabla 1. Escala de valores MOS. A continuación se presentan los valores medios obtenidos para las evaluaciones de audio y vídeo. En el caso de audio se ha transmitido audio con el códec G. 711 durante 90 segundos en cada escenario y se han provocado 2 caídas de enlace durante este tiempo. Además se debe destacar que la red se encontraba en fase inicial, sin ningún tipo de memoria. RTP audio MOS Medio MOS Ideal Escenario 1 3.8 4.10 Escenario 2 3.65 4.07 Tabla 2. Valores MOS Medios para transmisión de audio. En vídeo se ha realizado una prueba sobre el primer escenario enviando 3 tipos de vídeo diferentes, con las siguientes características. Vídeo 1 Vídeo 2 Vídeo 3 Duración 52 s 5 min 58 s 2 min 28 s Resolución 400 x 226 1280 x 720 1920 x 1080 Códec H.264 H.264 H.264 Fps 30 24 25 Tasa de bits 248 + 96 kbps 1529 + 191 kbps 2013 + 125 kbps Tabla 3. Tabla de características de vídeo. Los resultados obtenidos son los siguientes: RTP vídeo Caídas de enlace MOS Medio MOS Ideal Vídeo 1 1 3.45 5 Vídeo 2 4 3.30 5 Vídeo 3 2 3.37 5 Tabla 4. Valores MOS Medios para transmisión de vídeo. Además, a partir de los datos relacionados con la pérdida de paquetes se puede obtener el tiempo medio sin servicio en cada caso: RTP audio Tiempo sin servicio medio Escenario 1 0.74 s Escenario 2 1.17 s Tabla 5. Tiempo medio sin servicio para transmisión de audio. RTP vídeo Tiempo sin servicio medio Vídeo 1 0.48 s Vídeo 2 0.72 s Vídeo 3 0.58 s Tabla 6. Tiempo medio sin servicio para transmisión de vídeo. A partir de estos resultados, y de la realización de todo el trabajo en su conjunto, se extraen las conclusiones que se presentan en el siguiente apartado. VI. CONCLUSIONES Y LÍNEAS FUTURAS A. Conclusiones. SDN es una arquitectura de red que promete grandes ventajas sobre redes tradicionales. Se ha desarrollado una aplicación para el controlador OpenDayLight que explota las capacidades de las redes SDN. Se ha diseñado una solución capaz de realizar diferenciación de tráfico, cálculo de camino óptimo y recuperación de enlaces. Se ha comprobado el correcto funcionamiento de la solución diseñada a tenor de los resultados. Se ha optimizado la elección de caminos en función del tipo de tráfico. Se ha implementado recuperación de enlaces tras caída. 59 IT / Redes definidas por software Se obtienen resultados MOS aceptables de calidad de vídeo y voz. B. Líneas futuras. Integrar la solución en las nuevas versiones del controlador. Mejorar la eficiencia y tiempos sin servicio obtenidos por la solución propuesta. Realizar un estudio sobra la QoE percibida por los usuarios, obviando el uso de modelos. Implementación de métodos de protección frente a errores de ráfaga. Separación de la solución en diferentes aplicaciones para aumentar la eficiencia. AGRADECIMIENTOS Dedicado a cada persona que me ha apoyado a sacar adelante este trabajo, y que gracias a todos ha tenido tanto éxito. Que nunca han dejado que me rinda. Como no a Manu, el apoyo de todos estos meses y en especial a ella que siempre está y siempre saca lo mejor de mí. A mi tutor, Don Juan José Ramos Muñoz quiero agradecer en especial su gran apoyo para que este trabajo tenga la calidad que merecía. No cambies nunca Juanjo. Muchas gracias! REFERENCIAS [1] C. V. Networking. (2014) “Cisco visual Networking index: Forecast and methodology”, 2013-2018. Disponible: http://www.cisco.com/c/en/us/solutions/collateral/service-provider/ipngn-ip-next-generation-network/whitepaperc11-481360.html [2] O. N. Foundation (2015). Openflow definition by onf. Disponible: https://www.opennetworking.org/sdn-resources/openflow [3] Algoritmo dijkstra [4] SourceForge. (2009) Aplicación algoritmo Dijkstra para Java. Disponible: http://jung.sourceforge.net/doc/api/edu/uci/ics/jung/algorithms/shortest path/DijkstraShortestPath.html [5] REC, I. T. U. T. G. 107. The E-model, a computational model for use in transmission planning,” March, 2005. [6] ITU, “Opinion model for video-telephony applications,”July,2012. [Online]. Available: http://www.igut.int/rec/T-REG-G.1070-201207I/en Cristian Alfonso Prieto Sánchez (25 de Junio de 1992, Olivares (Granada)) es graduado en Ingeniería de Tecnologías de Telecomunicación con mención Telemática por la Universidad e Granada en 2015. 60 C.A. Prieto Sánchez (tutor J.J. Ramos Muñoz): Diseño y evaluación de un servicio OpenFlow de provisión de Calidad de Experiencia sobre Mininet Soporte para comunicaciones m´ aquina a m´ aquina en sistemas 5G Autor: Pilar Andr´ es Maldonado, e-mail: [email protected].es Tutor: Pablo Ameigeiras Guti´ errez, e-mail: [email protected] Titulaci´ on: Ingenier´ ıa de Telecomunicaci´ on Departamento de Teor´ ıa de la Se˜ nal, Telem´ atica y Comunicaciones Universidad de Granada Resumen—El incremento de las comunicaciones m´ aquina a m´ aquina (M2M) sobre las redes m´ oviles impone nuevos requisitos y la aparici´ on de nuevos desaf´ ıos en las redes, como son el crecimiento exponencial del n´ umero de M2M UEs (User Equipment) conectados, o caracter´ ısticas de tr´ afico ´ unicas. Muchos M2M UEs realizar´ an peque˜ nas y poco frecuentes transmisiones de datos, lo que supone un desaf´ ıo para las redes m´ oviles actuales no dise˜ nadas para este tipo de tr´ afico, donde la carga de se˜ nalizaci´ on puede incrementarse significativamente y causar congesti´ on en la red. El objetivo del proyecto es la propuesta y evaluaci´ on de nuevos procedimientos de control mejor adaptados a las comunicaciones M2M dise˜ nados para una arquitectura 5G basada en Software Defined Networking, con respecto al esquema actual de las redes Long Term Evolution (LTE), centr´ andose para su dise˜ no en la reducci´ on de la se˜ nalizaci´ on. Palabras clave—M2M, LTE, Small Data Transmissions, SDT, SDN. I. INTRODUCCI ´ ON M´ AQUINA a m´ aquina es un t´ ermino que puede ser usado para describir cualquier tecnolog´ ıa que permita a los dispositivos conectados a la red compartir informaci´ on y realizar acciones sin interacci´ on humana. Aunque hay muchos escenarios M2M, la mayor´ ıa de las comunicaciones M2M involucra una gran cantidad de dispositivos que desean comunicarse con sus aplicaciones en un corto periodo tiempo. Las caracter´ ısticas de tr´ afico M2M son muy diferentes de las comunicaciones entre personas (H2H) tenidas en cuenta hasta ahora para el dise˜ no de las redes m´ oviles. Normalmente, las comunicaciones M2M est´ an relacionadas con muchos dispositivos de bajo consumo que solicitar´ an peque˜ nas transmisiones de datos [1], [2]. Estas nuevas caracter´ ısticas de tr´ afico dan lugar a limitaciones en las redes m´ oviles para conseguir una implementaci´ on eficiente de las comunicaciones M2M. En los primeros despliegues de servicios M2M se ha usado GPRS (General Packet Radio Service), ya que proporciona una gran cobertura, y el costo de los m´ odems GPRS es lo suficientemente bajo para permitir modelos de negocio M2M viables [3]. Sin embargo, GPRS tiene algunas desventajas para M2M, que limitan la capacidad de GPRS para soportar las aplicaciones M2M, lo que ha hecho que el sector se fije en la siguiente generaci´ on de red m´ ovil, LTE, para conseguir mayor capacidad para las comunicaciones M2M. Actualmente, los M2M UEs se comunican con la red de la misma forma que lo hacen los H2H UEs, pero a diferencia de ellos, muchas aplicaciones M2M solo necesitan intercambiar una peque˜ na cantidad de datos, como por ejemplo, las aplicaciones relacionadas con telemetr´ ıa. A pesar del peque˜ no tama˜ no de estas transmisiones, activan los mismos procedimientos de control para reserva de recursos, reduciendo el soporte eficiente de los servicios M2M en la red. Un ejemplo de ello es la red convencional de LTE del 3GPP, donde se requiere la realizaci´ on del procedimiento de acceso aleatorio (RA) y la configuraci´ on de los portadores radio antes de la transmisi´ on de los datos. Si el M2M UE s´ olo quiere enviar un peque˜ no paquete IP, la carga de se˜ nalizaci´ on generada es excesiva comparada con los datos a transmitir. Esta cantidad de se˜ nalizaci´ on y el gran n´ umero de M2M UEs que iniciar´ ıan casi simult´ aneamente la solicitud podr´ ıa ser una importante causa de congesti´ on en el plano de control y un generador de cuellos de botella en los limitados recursos radio disponibles [4]. Esta situaci´ on junto con el incremento actual del tr´ afico de se˜ nalizaci´ on H2H en las redes LTE, que crece m´ as r´ apido que el tr´ afico de datos, generar´ a una tormenta de se˜ nalizaci´ on que podr´ ıa paralizar la red. Para superar los desaf´ ıos previstos, el grupo 3GPP ha propuesto mejoras dentro de LTE que permitan un soporte eficiente de las comunicaciones M2M, LTE para Machine Type Communications (LTE-M), donde se quieren proporcionar servicios M2M a bajo coste y bajo consumo energ´ etico con alta disponibilidad. Este resumen se centrar´ a en los aspectos y resultados m´ as importantes del proyecto, enviados al ACM Symposium on Applied Computing (SAC 2016), que son: el estudio de los esquemas actuales de peque˜ nas transmisiones M2M, la propuesta de un nuevo procedimiento para una arquitectura de sistema 5G basada en Software Defined Networking (SDN), y la evaluaci´ on de las diferentes alternativas estudiadas. Tras las simulaciones, se muestra que el esquema convencional de LTE no es eficiente para los M2M UEs que soliciten peque˜ nas transmisiones, y que nuevas soluciones como LTE-M o el procedimiento propuesto pueden reducir significativamente la carga de se˜ nalizaci´ on generada. II. CONOCIMIENTOS PREVIOS A. LTE LTE fue dise˜ nado para aplicaciones de banda ancha, naci´ o para cubrir la necesidad de mayores velocidades de env´ ıo, menor latencia y una red m´ as sencilla con la que operar comparada con sus antecesores. Algunos de los requisitos de LTE son [5]: velocidades de pico de 100 Mbps de bajada y 50 Mbps de subida, latencia en el plano de usuario de menos de 5ms y en el plano de control de menos de 100ms desde el Teoría de la Señal, Telemática y Comunicaciones, 2016, ISBN-13 978-84-617-5449-6, páginas 61-66 estado idle aactive. LTE ha sido dise˜ nado para soportar solo servicios de conmutaci´ on de paquetes, donde cada transmisi´ on de datos se basa en un portador para proporcionar QoS. Cuando un UE, registrado en la red, est´ a inactivo porque no est´ a usando ning´ un servicio, la red libera algunos de los recursos asignados al UE como los recursos radio e informaci´ on relacionada, realizando el procedimiento de control S1 release, mostrado en la Fig. 1. Este procedimiento es utilizado por el eNB (E-UTRAN Node B) para liberar recursos, cambiando el UE de estado connected aidle. Cuando un UE en estado idle quiere enviar un paquete de datos, tiene que realizar primero el procedimiento de control service request para volver a activar y reasignar los recursos, en la Fig. 2 se puede ver la secuencia de mensajes del procedimiento. Por lo tanto, cada transmisi´ on de datos desde el estado idle por parte del UE implica la reactivaci´ on de los portadores de datos liberados anteriormente. El despliegue de las comunicaciones M2M sobre LTE impone ciertos desaf´ ıos en LTE, como la congesti´ on causada por el gran n´ umero de M2M UEs conectados y sus caracter´ ısticas de tr´ afico. Esta congesti´ on puede ocurrir en diferentes nodos de la red, por ejemplo en el eNB, debido al alto n´ umero de M2M UEs intentando conectar a la red casi simult´ aneamente, o en la parte troncal, cuando esta gran cantidad de M2M UEs se conectan a la red desde diferentes celdas, pero comparten el mismo Mobility Management Entity (MME). Otro de los desaf´ ıos clave que impone M2M es la gesti´ on eficiente de los limitados recursos radio. En LTE, un UE tiene que realizar el procedimiento de acceso aleatorio (RA) en diferentes situaciones, como por ejemplo para recibir o enviar nuevos paquetes de datos cuando el UE no est´ a sincronizado 1. S1-AP: S1 UE Context Release Request MME 5. RRC Connection Release UE eNodeB Serving GW 2. Release Access Bearers Request 3. Release Access Bearers Response 4. S1-AP: S1 UE Context Release Command 6. S1-AP: S1 UE Context Release Complete 1. RRC Connection Release Fig. 1. Secuencia del procedimiento S1 Release [9]. MME Serving GW PDN GW 2. NAS: Service Request 1. NAS: Service Request 7. S1 - AP: Initial Context Setup Complete 3. Authentication/Security HSS 4. S1-AP: Initial Context Setup Request 5. Radio Bearer Establishment 6. Uplink Data 8. Modify Bearer Request 12. Modify Bearer Response UE eNodeB 11. Modify Bearer Response PCRF (A) 10. PCEF Initiated IP-CAN Session Modification 9. Modify Bearer Request Fig. 2. Secuencia del procedimiento Service request [9]. Fig. 3. Procedimiento de acceso aleatorio en LTE. con el eNB, o no tiene recursos configurados [5]. Hay dos variantes del procedimiento RA en LTE, acceso basado en contenci´ on o no basado en contenci´ on. La variante de inter´ es en este proyecto es el basado en contenci´ on, donde la red no tiene un pre´ ambulo reservado para el UE, como es normal para el establecimiento de una conexi´ on Radio Resource Control (RRC). El procedimiento RA basado en contenci´ on est´ a compuesto por 4 pasos, mostrados en la Fig. 3. El procedimiento comienza con el UE enviando un pre´ ambulo al eNB (Msg1), si el eNB recibe el pre´ ambulo, responde con un mensaje ”Random Access Response” (RAR, Msg2) donde se indican los recursos radio en los que el UE puede enviar el Msg3. Tras la recepci´ on del Msg3, el eNB contesta al UE con el Msg4, este mensaje contiene la resoluci´ on de la contenci´ on del UE. Los mensajes 3 y 4 normalmente son usados como parte del procedimiento de establecimiento de la conexi´ on RRC, como mensajes ”RRC Connection Request” y”RRC Connection Setup”, donde el UE solicita la conexi´ on RRC y la red establece los portadores radios bas´ andose en la causa del establecimiento, respectivamente. B. LTE-M Para resolver las ineficiencias de LTE con MTC (Machine Type Communications), el grupo 3GPP ha introducido varias soluciones para optimizar la implementaci´ on de MTC en LTE, LTE-M. La Release 10 a˜ nadi´ o funcionalidades para la congesti´ on de la se˜ nalizaci´ on y el control de sobrecarga. La Release 11 se centr´ o en el direccionamiento IP, identificadores y activaci´ on de dispositivos MTC, y la actual Release 12 se ha centrado en la transmisi´ on de peque˜ nos paquetes, mejoras en la activaci´ on de dispositivos, monitorizaci´ on, optimizaci´ on del consumo energ´ etico del UE y funcionalidades basadas en grupos. Algunos nuevos requisitos de servicio para MTC implican una evoluci´ on en la arquitectura de red para incluir nuevas entidades funcionales con nuevos servicios, como por ejemplo, el Services Capability Server (SCS) o la MTCInterWorking Function (MTC-IWF) [6]. C. Arquitectura 5G basada en SDN Todos estos cambios propuestos por el 3GPP podr´ ıan ser insuficientes para una implementaci´ on eficiente de las comunicaciones M2M. Por ejemplo, la capacidad fija de la red troncal de LTE pordr´ ıa saturarse con una tormenta de se˜ nalizaci´ on NAS (Non Access Stratum). En [7] se observ´ o que la m´ axima capacidad de gesti´ on de un MME era alrededor de 80.000 solicitudes en 5 min. Si millones de M2M UEs conectados reinician su operaci´ on, la capacidad del MME ser´ a un cuello de botella y los enlaces entre el Home Subscriber Server 62 P. Andrés Maldonado (tutor P. Ameigeiras Gutiérrez): Soporte para comunicaciones máquina a máquina en sistemas 5G (HSS) y el MME estar´ an tambi´ en congestionados debido a la gran cantidad de mensajes de autenticaci´ on. Para el proyecto, se ha supuesto una red 5G para superar las posibles limitaciones de LTE como la mencionada anteriormente. Se ha usado la nueva arquitectura de red explicada en [8], donde se propone una arquitectura de alto nivel para un sistema 5G basado en SDN, computaci´ on en la nube y Network Functions Virtualisation (NFV), con tres niveles de jeraqu´ ıa de controladores SDN. NFV desacopla las funciones de la red del hardware dedicado, pudiendo ejecutarse estas funciones en software. SDN permite una nueva arquitectura de red donde el plano de control y el de datos est´ an separados, la inteligencia de la red y el estado est´ an l´ ogicamente centralizados, y la infraestructura de red se abstrae de las aplicaciones finales, consiguiendo con ello la creaci´ on de nuevas redes inteligentes programables. NFV ejecuta un MME virtualizado, donde los cambios de la red solicitados son realizados por el controlador SDN. Con esta nueva arquitectura, en este proyecto se han redise˜ nado los procedimientos de control principales de LTE [9], y se ha propuesto uno nuevo para reducir la se˜ nalizaci´ on y mejorar la eficiencia de la red en el env´ ıo de peque˜ nas transmisiones M2M. Para ello, se propone la eliminaci´ on del uso de portadores en 5G para la gesti´ on de las diferentes QoS, eliminando as´ ı la distinci´ on de los diferentes flujos seg´ un su QoS y el usuario que los gener´ o, y la unificaci´ on de los estratos de seguridad NAS y AS (Access Stratum), para eliminar redundancia. Los procedimientos redise˜ nados no incluidos en este resumen, pero que se pueden ver en la memoria del proyecto son: Attach,S1 Release,UE Triggered Service Request,Tracking Area Update yDetach. III. PROCEDIMIENTOS DE SE ˜ NALIZACI ´ ON REDUCIDOS PARA M2M La inclusi´ on de las comunicaciones M2M, y en especial para este proyecto las peque˜ nas transmisiones de datos, pueden dar lugar a una sobrecarga de se˜ nalizaci´ on si no se gestionan eficientemente [10], [11]. En esta secci´ on se explicar´ an los dos principales trabajos en los que se ha basado este proyecto para el dise˜ no del nuevo procedimiento de control propuesto para M2M. A. Procedimiento SDT del 3GPP Tras el reconocimiento por parte del 3GPP de la caracter´ ıstica de peque˜ nas transmisiones en las comunicaciones M2M (Small Data Transmissions, SDT) [1]. El 3GPP ha propuesto varias soluciones para optimizar el env´ ıo o recepci´ on de estas peque˜ nas transmisiones [12]. Dentro de las soluciones propuestas, este proyecto se basa en una de ellas donde se propone un nuevo procedimiento para optimizar la transferencia de un paquete IP y su respuesta, al que llamaremos procedimiento SDT. Este nuevo procedimiento SDT optimiza la secuencia de mensajes cuando el M2M UE est´ a en estado idle, usando para ello el contexto de seguridad NAS preestablecido para enviar los datos como se˜ nalizaci´ on NAS [12]. Cuando el M2M UE quiere enviar un paquete IP, solicita el establecimiento de una conexi´ on RRC con la causa de establecimiento fijada a ”low priority small data” o ”small data”. Estos valores en la causa del establecimiento RRC permiten al eNB detectar que es un procedimiento de se˜ nalizaci´ on corto. Tras completar el procedimiento RA y el establecimiento de la conexi´ on RRC, el M2M UE env´ ıa un mensaje NAS con el paquete de datos IP al MME, en la Fig. 4 se puede ver el procedimiento completo. Para la transferencia del peque˜ no paquete de datos IP, el procedimiento SDT hace uso del plano de control para evitar el establecimiento de la seguridad RRC y los portadores de datos. Esta soluci´ on incluye el paquete de datos en el mensaje inicial NAS y la transmisi´ on recae en la capa RRC, sin ninguna confirmaci´ on de capas superiores a la RRC. Para la evaluaci´ on de este procedimiento, se ha asumido que el MME libera inmediatamente la conexi´ on RRC despu´ es de completar la transmisi´ on del paquete IP (denominada como ”alt. A” en la Fig. 4). B. Hybrid Random Access and Data Transmission Protocol Para reducir la se˜ nalizaci´ on excesiva en las comunicaciones M2M, en [13] se propone un nuevo dise˜ no de un protocolo para el acceso aleatorio y la transmisi´ on de datos. La soluci´ on permite enviar paquetes de datos a un M2M UE en estado idle despu´ es de la transmisi´ on del pre´ ambulo en el procedimiento RA, por lo tanto, no es necesario el establecimiento de una conexi´ on RRC. La soluci´ on combina una asignaci´ on din´ amica de canales de datos M2M en los recursos radio por la estaci´ on base, y un esquema de clases de restricci´ on para reducir la sobrecarga en la red de acceso radio. El procedimiento tiene 6 pasos, resumidos en: 1) Planificaci´ on PRACH: La estaci´ on base estima el n´ umero de M2M UEs activos para decidir la posible configuraci´ on. 2) Restricci´ on de acceso: Un M2M UE activo participa en el mecanismo de clases de restricci´ on para iniciar el procedimiento RA. 3) Transmisi´ on del pre´ ambulo: Como en el procedimiento RA normal de LTE, el M2M UE transmite un pre´ ambulo a la estaci´ on base. 4) Planificaci´ on de canales de datos: En este paso la estaci´ on base detecta todos los pre´ ambulos transmitidos, planifica los recursos para los M2M UEs e informa de los resultados de la planificaci´ on a los M2M UEs. eNB MME UE S-GW/ P-GW b) RRC Connection Request (S-TMSI, small data indicator ) RRC Connection Setup c) RRC Connection Setup Complete (NAS PDU, release ind) d) Initial UE message (NAS PDU, release ind ) g) Downlink Data Notification (Bearer ID , UDP/IP response packet) h) Downlink Information Transfer (NAS PDU) f) UE Context Release e)GTP-U(TEID,UDP/IPpacket) small data indicator inhibits eNB sending Measurment Configuration to the UE h) Downlink NAS Transport (NAS PDU) f) RRC Connection Release alt. A alt. B a) small data capability exchange l)DownlinkDataNotificationAck Fig. 4. Procedimiento SDT [12]. 63 IT / Redes móviles Además, para aprovechar la petición GET al máximo, se envían dos variables de texto (que podrían ser el usuario y contraseña del usuario) junto con el mensaje de que el usuario ha reproducido un vídeo, camuflando así los datos. B. Implementación interna La aplicación cliente, tal y como indica el desarrollo de Samsung Smart TV [8], aúna varios archivos CSS, Javascript y HTML. El CSS funciona como marcador de estilo, imágenes, colores. Por su parte, el HTML muestra la estructura de la aplicación, es decir, se crean los ID que hemos indicado anteriormente, los distintos vídeos que se van a utilizar y las anclas, referencias a los elementos definidos para que sea mucho más sencillo referenciarlos posteriormente en el código. Por último, se encuentra el lenguaje JavaScript como elemento de unión donde se utilizan librerías tan típicas como jQuery y se define el propio funcionamiento de la aplicación. En total existen cuatro archivos Javascript: Data, para enviar el mensaje HTTP al servidor; File, que almacena los métodos destinados a manejar los archivos de texto y directorios; GetPath, para obtener y devolver el valor absoluto de la ruta donde se encuentra los archivos; y Main, el archivo principal que define el funcionamiento de la aplicación, sobre todo en lo que respecta a la interacción del usuario y a la reproducción de los vídeos. En este archivo se detallan métodos para recoger la tecla pulsada del mando y realizar la tarea asignada a cada uno de ellos dependiendo de dónde se encuentre el usuario a cada momento, es decir, comprobando donde se encuentra el foco de la aplicación y los índices index e index_contenido para, por ejemplo, reproducir el vídeo exacto que el usuario desea o pasar de una a otra categoría cuando pulsamos la flecha hacia abajo del mando, marcándose el menú con los recuadros de color rosa como se vio en la Figura 4. Con el fin de comprender cómo funcionan los distintos métodos, la Figura 5 muestra un diagrama de flujo con las distintas opciones disponibles para el usuario cuando se encuentra reproduciendo un vídeo. Así, en este caso, puede pulsar tres teclas: Return, que detiene la reproducción y devuelve el foco al contenido, es decir, se vuelve a la pantalla anterior teniendo en cuenta qué vídeo se ha reproducido; Stop, para detener la reproducción; y Play, para reproducir el vídeo. Cualquiera de las demás teclas que se pulsen no tendrán consecuencia alguna en la aplicación, asegurando así su buen funcionamiento. Por su parte, el servidor Apache [9] se encarga de recoger los mensajes enviados por el cliente y servir los vídeos reproducidos. Principalmente se compone de cuatro Fig 5. Diagrama resumen del funcionamiento del método Main . reproductor . keyDown() elementos: el archivo que define su comportamiento llamado proxy-img.php, una carpeta “imágenes” en la que se encuentran los distintos vídeos y sus respectivas miniaturas, un archivo de texto llamado “archivoSalida.txt” que guarda en un registro la hora y la IP desde la que se ha contactado con el servidor y el access.log de Apache con el que se pueden comprobar las operaciones y las peticiones realizadas por los usuarios. VI. EVALUACIÓN Y PRUEBAS Tras desarrollar la aplicación al completo, se puso a disposición de los usuarios a través de Internet con una guía de instalación tanto en modo root como por USB, por si no estaba disponible el servidor en ese momento, en la página web http://appssamsungsmarttv.blogspot.com.es/. En lo que a nuestras pruebas respecta, el funcionamiento de la aplicación es el correcto, sirviendo los vídeos de una forma sencilla y rápida y obteniendo los mensajes en el servidor. Primero se realizaron pruebas en un emulador a través de Virtualbox [10] y luego en un televisor real tal y como se comprueba en la Figura 6. Por otra parte, los objetivos del trabajo se han cumplido en su totalidad ya que se ha investigado el Software Development Kit de la plataforma de Smart TV Samsung, se han conocido a fondo las API y el emulador que ofrece la compañía, se ha estudiado cómo afecta el malware a un televisor inteligente con una aplicación con varias características interesantes y, además, se ha demostrado su funcionamiento en un dispositivo real. El servidor, por su parte, también funciona correctamente, actualizándose sin problema con cada una de las visitas, de las reproducciones realizadas por los usuarios y de las descargas y ejecuciones de la aplicación como se muestra en la Figura 7. Por otra parte, tal y como indicamos en el apartado anterior, aparece un registro similar pero que guarda la hora y la IP de los clientes conectados. Figura 6. Demostración de PelisSeriesGratis en un Smart TV real Inicio Main.reproductor.keyDown() Tecla pulsada Detiene la reproducción y devuelve el foco al contenido Reproduce el vídeoPlayReturn Stop Detiene la reproducción TABLA II IDENTIFICADORES (ID) ASOCIADOS CON LAS CATEGORÍAS, EL CONTENIDO Y SUS ÍNDICES ID Categoría Index Contenido Index_contenido 0_0 Películas 0 Primer vídeo 0 0_1 Películas 0 Segundo vídeo 1 1_0 Series 1 Primer vídeo 0 1_1 Series 1 Segundo vídeo 1 70 J. López Arredondo (tutor P. García Teodoro): Análisis de malware en Smart TV: ataques y defensas Fig 7. Registro del servidor Fig 8. Estadísticas extraídas de la página web VII. CONCLUSIONES Como se comentó anteriormente, se ha estudiado cómo funciona el SDK y su complejidad en lo que a términos temporales se refiere para el desarrollo de aplicaciones. Además, se ha desarrollado una aplicación con una interfaz sencilla y auto-actualizable que pone de manifiesto el riesgo para la seguridad gracias a la ingeniería social ya que, como se indicó, cualquier usuario malintencionado podría recoger los datos introducidos por los usuarios. Asimismo, el código de los distintos archivos ha sido suficientemente comentado para posibles futuros proyectos. Por último, tras la investigación realizada durante estos meses, se ha llegado a la conclusión de que los electrodomésticos conectados a Internet y, en concreto, los televisores inteligentes, pueden resultar un grave problema para la privacidad y seguridad de los datos de los usuarios si estos instalan aplicaciones no verificadas y alojadas en tiendas y servidores diferentes a los oficiales. En definitiva, se demuestra que, al igual que ocurre con los smartphones, las tablets e incluso los ordenadores, un dispositivo capaz de conectarse a la red de redes es una amenaza potencial si este no se utiliza correctamente y no se tienen en cuenta las medidas de seguridad oportunas. Todas estas conclusiones han sido propuestas, en parte, gracias a los resultados obtenidos en las pruebas reales. El feedback ha sido bastante positivo puesto que la web se ha visitado en varias ocasiones y ha habido usuarios que han utilizado la aplicación de forma continuada para ver películas y series como se muestra en la Figura 8, incluyendo aquellos que han colaborado “prestando” sus televisores para realizar las pruebas y los diversos vídeos que se grabaron, indicando que les gustaría que la aplicación siguiera desarrollándose para ser más completa y poder ver películas gratis en su televisor sin depender de servidores multimedia en su hogar u otros servicios en línea. VIII. LÍNEAS FUTURAS Aun habiendo cumplido la gran mayoría de los objetivos establecidos al inicio, aún quedan abiertas las siguientes líneas de trabajo futuras: • Monitorización del usuario y del televisor: Algunas de las clases y métodos más interesantes que se pueden encontrar en el SDK no pueden utilizarse, o más bien comprobarse, en el emulador, ya que se necesita un televisor compatible. Por ello, si es posible trabajar con uno de estos dispositivos, sería muy interesante obtener las listas de canales, cierta información del televisor como modelo, firmware que utiliza (para, por ejemplo, introducir un firmware con malware como actualización), identificador, etc., e incluso tomar el control de la cámara para grabar imágenes y enviarlas al servidor •Reproducción en streaming de plataformas conocidas: La clase Player es capaz de reproducir vídeos en formato MP4 de forma remota mediante su URL, por lo que se ha utilizado un servidor para alojar algunos vídeos de demostración. No obstante, también es posible trabajar con alguna de las API desarrolladas por la comunidad, diseñadas para reproducir de forma más sencilla vídeos de YouTube y otras plataformas, lo que facilitaría la reproducción de otras películas y series. •Ampliación de catálogo: A modo de prueba, la aplicación incluye cuatro vídeos en total, aunque lo más importante es que se amplíe el catálogo y ofrecer las mejores películas y series para aumentar el interés del usuario. • Mecanismos de defensa: Una de las líneas de investigación más prometedoras sería la relacionada con la monitorización de los distintos elementos internos del televisor inteligente. Por ejemplo, podría crearse un sistema de detección de intrusos capaz de alertar al usuario si se detecta actividad sospechosa -por ejemplo, un aumento de temperatura del procesador sin que el propio usuario esté realizando ninguna actividad a priori exigente para el Smart TV, o el uso excesivo de la conectividad Ethernet o WiFi sin que ninguna aplicación esté siendo utilizada o actualizada-. Además, podría comprobarse si la cámara integrada o el micrófono están encendidos, lo que podría considerarse una amenaza para el usuario. AGRADECIMIENTOS Agradezco a toda mi familia los grandes esfuerzos de todo tipo que han realizado para que yo, finalmente, llegara a estudiar lo que quería, a mis padres y a mis hermanos. Un enorme y tremendamente cariñoso gracias a mi abuelo Alfonso que lamentablemente no podrá ver, al menos desde aquí, cómo su nieto ha conseguido graduarse. ¡Va por ti, abuelo! Y gracias a vosotros, que desde Úbeda, Jaén, Málaga y otros lugares de España me habéis apoyado: gente del Interrail, Laura, Sofía y todas aquellas personas importantes en mi vida. REFERENCIAS [1] Google, «Chromecast,» Disponible: https://www.google.es/chrome/devices/chromecast/ [2] Strategy Analytics, «Global Connected TV Device Ownership Passes 1 Billion Units,», 2014. Disponible: https://www.strategyanalytics.com/strategy-analytics/news/strategyanalyticspress-releases/strategy-analytics-pressrelease/2014/12/09/global-connected-tvdevice-ownership-passes-1billion-units-says-strategy-analytics#.VWpcHc_tmko [3] Economics Computer, «2007 Malware Report: The Economic Impact of Viruses, Spyware, and Other Malicious Code,» 2007. Disponible: http:// www.computereconomics.com/page.cfm?name=malware%20report. [4] RedesZone, «Samsung: sus Smart TV tienen un problema de seguridad,» 2012. 71 IT / Seguridad en redes Disponible: http://www.redeszone.net/2012/12/12/samsung-sus-smarttv-tienenun-problema-de-seguridad/ [5] Strategy Analytics, «Samsung Reasserts Smart TV Dominance,» 2014. Disponible: https://www.strategyanalytics.com/strategy-analytics/news/strategyanalyticspress-releases/strategy-analytics-pressrelease/2014/05/19/samsung-reassertssmart-tv-dominance-saysstrategy-analytics#.VWpcQ8_tmko. [6] Tomorrow Focus Media, «Smart TV Effects 2014-1,» 2014. Disponible: http://www.tomorrow-focusmedia.de/uploads/tx_mjstudien/TFM_SmartTVEffects_2014-I.pdf [7] Samsung, «Samsung D Forum,» Disponible: http://www.samsungdforum.com/ [8] Samsung, «Development Guide,» Disponible: http://www.samsungdforum.com/Guide/ [9] Apache Friends, «XAMPP Installers and Downloads,» Disponible: https://www.apachefriends.org/es/index.html [10] Oracle, «VirtualBox,» Disponible: https://www.virtualbox.org/ Jose López Arredondo (22 de Agosto de 1991, Úbeda, Jaén) es Graduado en Ingeniería de Tecnologías de Telecomunicación con mención en Telemática por la Universidad de Granada en 2015. Adicionalmente, ejerce como periodista en varios medios digitales como el diario económico Cinco Días, en su sección de tecnología Smartlife. Pedro García Teodoro es Catedrático de Universidad del área de Ingeniería Telemática de la Universidad de Granada. Tanto su labor docente como su labor investigadora se desarrollan en el campo de las redes de comunicación e Internet, en el cual ha realizado numerosas contribuciones en forma de libros, artículos en revista y ponencias en congresos, tesis y proyectos y contratos. 72 J. López Arredondo (tutor P. García Teodoro): Análisis de malware en Smart TV: ataques y defensas Los laboratorios de red dentro del ámbito docente constituyen hoy en día una de las herramientas de mayor utilidad para el trabajo práctico de los alumnos en diversas materias. No obstante, se requiere una evolución permanente dentro de los mismos asociada a una mayor flexibilidad en factores como el número de equipos de trabajo, la configuración en red, el equipamiento software o el sistema operativo. La idea es buscar una solución que permita a su vez a los alumnos desplegar, desarrollar y simular retos relacionados con la seguridad en red. En base a las limitaciones de sus antecedentes, el Proyecto de Innovación Docente 014-54 sobre el que trabaja el Departamento de Teoría de la Señal y Telemática y Comunicaciones de la Universidad de Granada trabaja para alcanzar ese modelo de laboratorio completo del que pueda hacer uso docente y alumno. El uso conjunto de virtualización y live-USB personalizados constituye una alternativa de trabajo con la que el docente puede personalizar sus propias máquinas virtuales según sus necesidades, así como la capacidad de acceder a máquinas internas o externas de la red física mediantes configuraciones adecuadas. Dentro de este contexto, la herramienta Systemback permite crear imágenes copiando el estado vigente de sistemas operativos Ubuntu y que éstas puedan ser exportadas como live-USB. Palabras clave: laboratorio de red, live-USB, innovación docente, seguridad, virtualización. I. INTRODUCCIÓN Hoy en día, los laboratorios de redes dedicados a la enseñanza son sin duda uno de los recursos docentes de mayor importancia para el desarrollo práctico de asignaturas relacionadas con la informática y las telecomunicaciones. Cada día, decenas de equipos son arrancados por los alumnos en estas instalaciones con el objetivo de simular de manera controlada escenarios de red sobre los que afianzar conceptos teóricos de estas asignaturas. Debido a la importancia que confiere, no sólo a los procedimientos de enseñanza de los docentes sino al aprendizaje de alumnado, es de vital importancia contribuir al asentamiento de estos entornos de trabajo. Un problema muy presente dentro de estos laboratorios es la limitación física de los mismos, ya que cuenta con un número fijo de equipos que puede resultar pequeño para el desarrollo de ciertas temáticas. Esto hace necesario la búsqueda de alternativas y tecnologías que permitan explotar el equipamiento físico de los mismos en busca de satisfacer ejemplos prácticos que requieran el uso de más de un equipo por alumno. Este hecho también se considera dentro del proyecto de innovación docente (PID 014-54) en el que la Escuela Superior de Ingeniería Informática y Telecomunicaciones ya pretende afrontar esa problemática mediante la implementación de un laboratorio virtual de seguridad en redes. Consecuencia de ello, se ha continuado la línea de trabajo planteada en esta investigación mediante la propuesta de un modelo de laboratorio docente basado en la evolución de un laboratorio de red convencional, cuyo objetivo a corto medio plazo es que forme parte de las clases prácticas. Para ello, se ha hecho necesaria la incorporación de herramientas de inicio llamadas live-USB o USB de arranque. Estos dispositivos, previamente configurados, permiten arrancar un sistema operativo plenamente funcional para trabajar a nivel de red a través de unas máquinas virtuales. El empleo de máquinas virtuales busca desarrollar distintas vías de trabajo preconfiguradas en una misma máquina física. La motivación de esta idea radica en la búsqueda de un entorno funcional y versátil en el que el alumno disponga del material necesario para trabajar en las prácticas de laboratorio sin preocuparse por el número de equipos o sistemas operativos requeridos para la experimentación. La idea principal es que a larga sea posible plasmar esta experimentación en entornos de pruebas con ataques mediante las máquinas virtuales albergadas en los live-USB, de modo que únicamente sea necesario arrancar los dispositivos USBs de inicio en las máquinas físicas para poder acceder a un escenario de red de interés. Para ello, se pretenden alcanzar los siguientes objetivos: Herramienta de virtualización en live-USB: propuesta de una herramienta de trabajo basada en virtualización con live-USB como solución de modo que pueda ser personalizada por el usuario, incluyendo tanto las máquinas virtuales deseadas como la configuración de red adecuada. En este punto es importante familiarizarse con el empleo de herramientas que generan imágenes de sistemas operativos en vivo. Funcionamiento de la herramienta en equipos físicos: el objetivo es acoplar esta herramienta en equipos físicos con objeto de poder simular esquemas de red basados en virtualización pura que permitan la comunicación entre máquinas virtuales. Posteriormente, este trabajo es extrapolado al Tutor: Rafael Alejandro Rodríguez Gómez; e-mail: rodg[email protected] Departamento de Teoría de la Señal, Telemática y Comunicaciones Universidad de Granada Autor: Francisco López Pérez, e-mail: [email protected] Diseño e implementación de retos de seguridad en redes de telecomunicación en el laboratorio 3.7 con fines docentes Titulación: Grado en Ingeniería de Tecnonologías de la Telecomunicación Teoría de la Señal, Telemática y Comunicaciones, 2016, ISBN-13 978-84-617-5449-6, páginas 73-78 laboratorio de red docente configurado en el aula 3.7 de la Escuela Técnica Superior de Ingeniería Informática y Telecomunicaciones. Casos prácticos: una vez adecuados los hosts y configurados los sistemas operativos guests, se desarrollan casos prácticos sobre los que puede trabajar el alumnado, ya sea a nivel distribuido entre equipos de la red o a nivel local entre las máquinas virtuales de una misma máquina física. . II. ESTADO DEL ARTE El modelo de trabajo propuesto se presenta como alternativa a otras propuestas anteriores, que si bien son capaces de mejorar la calidad y funcionalidad de los laboratorios de redes en distintos aspectos, no se afianzan como una solución definitiva a adoptar de manera genérica. A. Laboratorios remotos. El acceso remoto a los laboratorios de red físicos ha sido una utilidad bastante incorporada en muchas redes físicas del mundo para permitir el trabajo simultáneo en el mismo equipamiento físico. Este esquema de trabajo se basa en el concepto VPN, que permite el acceso a recursos alejados físicamente de nuestro equipo. Mediante el empleo de comunicaciones punto a punto de manera segura y privada a través de una infraestructura de red pública como es Internet, se logra que la información intercambiada no sea vista a través de la red compartida. Esto se consigue mediante el encapsulamiento de los paquetes a través de la inclusión de cabeceras que generan lo que se conoce como túnel. Esta tecnología es bastante sencilla de acoplar y no supone ningún consumo excesivo de los recursos del laboratorio. A su vez, la implantación de esta tecnología a nivel docente ha permitido, entre otras ventajas, solucionar el problema de sobrecarga en las aulas físicas de trabajo, posibilitando a su vez que todos los alumnos puedan interactuar de manera directa con la red sin encontrarse físicamente trabajando en la misma. Sin embargo, la implementación de esta técnica requiere una planificación temporal de acceso al servidor VPN, para evitar conexiones simultáneas de demasiados usuarios que puedan entorpecen entre sí sus desarrollos prácticos. B. Sistema Rembo Esta herramienta se fundamenta también en acceso remoto a servicios pero con un enfoque distinto. Esta arquitectura de red permite concentrar los recursos de sistemas operativos en una máquina centralizada, a la que se accede a través de la red. El sistema Rembo se invoca durante el proceso inicial de arranque de los equipos antes de cargar cualquier sistema operativo del disco duro. Este servidor con una configuración de red adecuada por medio de DHCP y con suficiente almacenamiento para albergar distintas imágenes de sistemas operativos, debe permitir que los equipos arranquen de manera remota la imagen de cualquier sistema operativo que contenga a través de una arquitectura PXE (Preboot eXecution Environment), siendo capaz de usar la red gracias a un entorno programado proporcionado por un chip situado en la tarjeta de red. Figura 1. Arquitectura PXE para un servidor Rembo La principal ventaja que aporta esta arquitectura es que permite concentrar los recursos de sistemas operativos en una máquina centralizada, permitiendo optimizar el tamaño de memoria disponible en los discos duros de las máquinas residentes en la red. Unido a ello, es posible establecer configuraciones previas en los sistemas operativos cargados en el servidor y conservar dichas imágenes intactas tras su uso por cualquier cliente. Entre las limitaciones que presentan dichos laboratorios, cabe resaltar la lentitud que tienen las máquinas para cambiar su aspecto puesto que no pueden reconfigurarse como cualquier equipo que tiene instalados varios sistemas operativos en distintas particiones. C. Redes VLAN La introducción de redes virtuales de área local en los laboratorios físicos es otra propuesta generalizada en las clases prácticas. Por lo general, las redes VLAN permiten comunicar entre sí conjuntos de equipos que no tienen ninguna relación física entre sí, pero que requieren abstraer su comunicación del resto de los equipos. Figura 2. Esquema de red de varias VLAN Esta tecnología suponen una nueva alternativa para evitar tiempos innecesarios en la reconfiguracion de la red, puesto que permiten la compartición de los mismos medios físicos entre distintas redes lógicas, cada una con su extensión y dominio de difusión. Además, la adición de estas vías de comunicación suponen no sólo el afianzamiento de la conexión física de los equipos en red, sino que se pueden añadir tantas VLAN como se quieran sin minar los recursos en red. No obstante, existe el problema de que el alumno no puede trabajar con este concepto fuera del laboratorio, ya que este concepto es introducido por los switches físicos del laboratorio y requiere de simuladores de red bastante avanzados como OPNET. Además, la flexibilidad de las configuraciones de red es menor y la optimización del tiempo 74 F. López Pérez (tutor R.A. Rodríguez Gómez): Diseño e implementación de retos de seguridad en redes de telecomunicación en el laboratorio 3.7 con fines docentes empleado para ello han llevado a la búsqueda de la abstracción de lo propiamente físico. D. Virtualización El empleo de técnicas de virtualización en la actualidad está bastante popularizado, puesto que permiten emular con gran realismo un sistema operativo como si se estuviera instalado en el disco duro de una máquina física, con unas prestaciones bastantes similares. El empleo de máquinas virtuales permite establecer diferentes configuraciones de un mismo sistema operativo sin ocupar demasiado espacio, o incluso almacenar distintos sistemas operativos. El hecho de poder trabajar con varios sistemas operativos dentro un misma máquina física proporciona una gran versatilidad a la hora de realizar prácticas de red, tanto en modo local como en modo distribuido combinando la red física con la virtual. La gestión de varios sistemas operativos conectados en la red se podrá realizar de forma simultánea, pudiéndose modificar de forma paralela e incluso añadir o eliminar máquinas virtuales de manera rápida, lo que se traduce en un gran escalabilidad. Además, el empleo de elementos virtuales nos permite optimizar recursos y reducir gastos mediante la sustitución de ordenadores y equipos de interconexión físicos por máquinas virtuales dentro de las subredes que se puede interconectar dentro de un mismo equipo físico. El principal inconveniente que presenta esta solución es que se reducen las prestaciones de los sistemas operativos virtualizados debido a la compartición de recursos como RAM, procesador o memoria entre todas las máquinas virtuales residentes en el equipo físico y el propio sistema operativo host. . E. Laboratorio virtual basado en live-USB con máquinas virtuales La base de esta idea de laboratorio va ligada a extender el concepto de virtualización a un nivel mayor de abstración, de modo que los equipos del laboratorio no requieran la instalación previa de ninguna herramienta o sistema operativo que vaya a ser utilizado. Aquí es donde entra en juego la idea de generar live-USB personalizados. Estos dispositivos permiten arrancar un sistema operativo albergado en su interior desde cualquier máquina física, sin necesidad de instalarlo en el disco duro de la máquina que lo ejecuta. El hecho de que los live-USB sean compatibles con cualquier equipo de una red física hace que sea factible su integración en cualquier arquitectura de laboratorio. La idea consiste en crear live-USB específicos para cada práctica en concreto, de modo que los alumnos tenga todo lo necesario para trabajar dentro de unas máquinas virtuales previamente configuradas. Este propósito se consigue combinando estos dos conceptos (live-USB y virtualización), de modo que al arrancarse el dispositivo USB, se incluya dentro de su sistema host un software de virtualización con dichas máquinas virtuales disponibles para ejecutarse. De este modo, se puede establecer cualquier configuración de red entre las máquinas virtuales de los liveUSB, con una escalabilidad y flexibilidad mayor de las que ofrece el equipamiento físico de red y con las herramientas y características que se requieran incorporadas para el trabajo práctico de los alumnos en las sesiones de laboratorio. A diferencia de lo que pueda parecer, el procedimiento para generar live-USB personalizados con máquinas virtuales es bastante sencillo e intuitivo, factor que también a tener en cuenta en comparación con otras soluciones que requieren no sólo complejas configuraciones, sino conocimiento especializado de redes de telecomunicaciones. Unido a las ventajas que ya ofrecía el empleo de virtualización por sí solo, la inclusión de un live-USB a esta filosofía ofrece las siguientes ventajas: Aporta portabilidad al material de trabajo, permitiendo al alumno no sólo emplear el dispositivo dentro de cualquier equipo del laboratorio de redes, sino en cualquier máquina. Esto permite que el alumno pueda familiarizarse con el entorno de trabajo de manera local desde su propio portátil o desde los equipos que pone a disposición la universidad. Posibilidad de incluir la configuración software necesaria para una práctica en un formato no sólo reducido y fácil de utilizar, sino que permite ser clonado en otro dispositivo para configuraciones iguales o similares. De este modo, el proceso de generación anterior sólo se repite si se requiere un despliegue de máquinas virtuales completamente distinto. Adicionalmente, la configuración por defecto establecida en el sistema host permanece invariable cada vez que se arranca el dispositivo USB, independientemente de lo que contenga el disco duro de la máquina que lo inicia. Así, los cambios que se realicen en la configuración del sistema operativo host o en las máquinas virtuales desaparecerán al cerrar sesión. Los tiempos de arranque y reconfiguración del software necesarios quedan sensiblemente reducidos, ya que no se requiere el reinicio de la máquina física ni la instalación de nuevos elementos; todo está predeterminado en las máquinas virtuales del live-USB. Permite la reutilización de los recursos del laboratorio físico para otras aplicaciones dentro del ámbito docente. La utilización de los recursos y las máquinas es principalmente virtual, de manera que los cambios que se realicen afectan muy poco a la composición física de la red. III. DESCRIPCIÓN DEL LABORATORIO DE SEGURIDAD El despliegue y configuración del modelo de laboratorio docente escogido tiene como principal objetivo mostrar la evolución de un laboratorio físico en base a la tecnología adoptada, con objeto de solucionar sus carencias. El diseño genérico que se plantea para este laboratorio va enfocado a continuar la experimentación ya iniciada en el Proyecto Final de Carrera de Anabel Reyes Maldonado dentro de su trabajo sobre herramientas de detección de intrusos para entorno docente. El objetivo de su proyecto consistía en la instauración de un laboratorio virtual de seguridad basado en máquinas virtuales sobre el que realizar 75 IT / Seguridad en redes experimentación basada en esta temática. La base de su trabajo de experimentación partía de la inclusión del software de virtualización por emulación Oracle VM VirtualBox dentro de una máquina física, con objeto de proporcionar escalabilidad hacia un número de máquinas superior al disponible con los equipos físicos. Sin embargo, en el planteamiento de Anabel, se deja entrever la posibilidad de evolucionar en el futuro esta propuesta de red con máquinas virtuales hacia un enfoque más flexible; una solución intermedia entre laboratorio físico y real y entornos de virtualización. Los live-USB personalizados permiten completar la idea de laboratorio de seguridad combinando los conceptos de liveUSB y virtualización. El objetivo es hacer posible el cambio de configuración y aspecto de los PCs del laboratorio de manera rápida y sencilla en función del trabajo a realizar. Gracias a esto, se puede desarrollar un laboratorio docente completo compuesto por una parte física convencional según la topología de red del laboratorio y una parte virtual que contribuye a extender el dimensionado de la red a un número de máquinas superior mediante el uso de redes internas adheridas a las anteriores. Figura 3. Ejemplo de red con live-USB de virtualización en una isla del laboratorio 3.7 de la ETSIIT La arquitectura de red física del laboratorio permanece inalterada de modo que los hosts siguen manteniendo los mismos dominios de colisión y difusión. El cambio se produce con la incorporación de redes internas a través de las interfaces de red que proporciona el software de virtualización. Esto hace que el host actúe como intermediario entre la red local de máquinas virtuales de cada equipo y la red distribuida del laboratorio. Para que las máquinas virtuales sean accesibles desde el resto de la red y puedan comunicarse unas con otras, es necesario especificar un redireccionamiento de puertos entre la máquina host y sus guests correspondientes. De este modo, se podrán reenviar conexiones entrantes desde la máquina anfitrión a puertos internos de las máquinas virtuales. Esta configuración red se conoce como NAT, y hace que la máquina física actúe a modo de router, traduciendo las conexiones que tienen su destino en equipos de la red interna virtual. El mecanismo de trabajo es bastante sencillo una vez configurado todo. Una vez que el docente tiene generados los live-USB, cada alumno puede hacer uso de él para seguir el transcurso de la explicación práctica. La idea es que al arrancar el dispositivo en un equipo, se cargue el sistema operativo del host que incluya distintas máquinas virtuales con la configuración necesaria para desenvolverse en el desarrollo de la práctica. Una vez acabada la sesión y apagados los equipos, todos los cambios realizados a nivel virtual no serán permanentes y desaparecen una vez que se vuelva a iniciar el sistema. IV. EMPLEO DEL LIVE-USB La inclusión de este complemento al modelo de laboratorio virtual contribuye a permutar más fácilmente el aspecto de los equipos del laboratorio y de manera totalmente planificada. Este resultado, unido al hecho de que ninguno de los cambios que se realicen en la apariencia de los equipos será permanente debido a la propia naturaleza del live-USB, proporciona un modelo de trabajo bastante completo. Para poder generar live-USB existen una gran cantidad de herramientas preparadas para este propósito. No obstante, no todas son las más adecuadas para este cometido. Systemback es un programa presente en las últimas distribuciones de Ubuntu que hace posible la tarea de crear copias de seguridad del sistema y de los archivos de configuración de los usuarios. Incluye características adicionales como la copia del sistema, la instalación del sistema y la creación del sistema en vivo. Sin embargo, lo más interesante para el propósito propuesto es la creación de un live-USB instalable tomando como base el sistema host. En la página oficial de Systemback, se proporcionan los comandos necesarios para su instalación, como adición de la descripción PPA en los repositorios del sistema. sudo add-apt-repository ppa:nemh/systemback sudo apt-get update sudo apt-get install systemback La interfaz del programa es bastante intuitiva, en la que las acciones a realizar se especifican en cada uno de los botones visibles. Figura 4. Interfaz gráfica de Systemback Por tanto, para generar una imagen de sistema operativo basta con seleccionar crear Sistema Live. Una vez dentro, hay que declarar el directorio de trabajo del sistema que es replicado en la imagen y si deseamos incluir los archivos de datos en la copia que se genera. Pulsando en crear nuevo, se inicia la generación de la imagen. Este proceso, dependiendo del peso del sistema, tardará alrededor de una hora y hora y media para completarse. 76 F. López Pérez (tutor R.A. Rodríguez Gómez): Diseño e implementación de retos de seguridad en redes de telecomunicación en el laboratorio 3.7 con fines docentes .Tras su finalización, resulta un archivo de formato .sblive que bien podrá convertirse en formato .iso si su tamaño es menor de 4 GB, o bien se puede cargar directamente en el dispositivo USB para conformar el dispositivo de arranque, seleccionando para ello escribir en USB. Este proceso no conlleva más de 20 minutos. Como resultado se crea un live-USB que, una vez iniciado en cualquier equipo, carga un menú de inicio de Systemback donde se puede seleccionar el arranque del sistema Ubuntu como Live o instalarlo en el disco duro de la máquina donde se arranca. En definitiva, se comporta como una distribución oficial. V. ENTORNO EXPERIMENTAL El objetivo principal de esta experimentación es demostrar que se puede extrapolar cualquier esquema de red sencillo presente en una arquitectura de red física a una arquitectura mixta que combine conexiones físicas y virtuales. Para ejemplificar su funcionalidad, se diferencian dos partes en la experimentación. La primera va a enfocada al rendimiento de la herramienta live-USB en base al tiempo empleado para su generación. La segunda práctica de ámbito más práctico, se vale de Hadoop como herramienta de trabajo. A partir de su instalación y configuración, el enfoque de la experimentación va ligado al planteamiento de ejercicios sencillos con los que se puede comprobar el funcionamiento y adaptabilidad de un clúster a la nueva configuración de equipos. A. Tiempo de trabajo de Systemback Esta parte de la experimentación atiende a las prestaciones obtenidas por la herramienta Systemback. Este software exclusivo de Ubuntu logra generar copias en vivo del sistema operativo en imágenes que pueden ser montadas en dispositivos USB para que trabajen como liveUSB. Partiendo de su funcionamiento, puede ser interesante para el docente tener una estimación aproximada del tiempo que necesita para confeccionar distintos live-USB para una clase práctica. Para clarificar esta idea, han sido configurados con cierto criterio distintos conjuntos de máquinas virtuales que contienen Lubuntu con la herramienta Hadoop y otros sistemas operativos de interés para el desarrollo práctico en las clases de docencia. El objetivo es plasmar el tiempo que tarda la herramienta Systemback en generar las imágenes .sblive en función de las máquinas guest de VirtualBox, así como el tiempo que la herramienta emplea para la generación del live-USB a partir de dicha imagen. Tabla 1. Tabla de tiempos con las distintas máquinas guest Guests incluidos Tamaño(GB) T.imagen(min) T.LiveUSB(min) 4 Lubuntus 2 XP y 1 Cloudera 21,16 95 24 6 Lubuntus 25,38 81 19 2 Lubuntus 2 Ubuntus 17,3 89 25 2 Cloudera VM 15,62 65 23 3 Lubuntus y 1 Cloudera VM 19,99 69 17 4 Lubuntus con Hadoop 16,92 51 15 B. Experimentación con Hadoop El principal objetivo de estas pruebas es no sólo proporcionar información de interés sobre la generación de los live-USB y el trabajo en un clúster, sino también demostrar la funcionalidad que de esta herramienta se presume. Para ello, se vale de una arquitectura de trabajo concreta basada en la exclusividad de máquinas Lubuntu con Hadoop. El primer objetivo es comprobar las prestaciones a la hora de iniciar un clúster Hadoop con distinto número de datanode. Para ello, se configuran varias máquinas virtuales de un mismo live-USB, de modo que haya un namenode y varios datanodes. Con las diferentes arquitecturas, se mide el tiempo transcurrido desde que se introduce la orden startall.sh por terminal. El rango de experimentación va desde un datanode hasta cuatro en el mismo clúster. Tabla 2. Tiempos de arranque del clúster en función del número de datanodes. Nº Datanodes p1(s) p2(s) p3(s) Media(s) 4 92,58 98,81 96,47 95,95 3 83,29 79,25 77,92 80,15 2 65,3 67,12 69,87 67,43 1 60,25 63,8 67,89 63,98 En segundo lugar y como fin a este análisis de rendimiento de un live-USB, se comprueba el funcionamiento del clúster generado mediante peticiones de cliente al namenode. Hadoop ofrece en su configuración por defecto ejemplos de tareas que permiten analizar el comportamiento del clúster lanzado. Para este ejemplo práctico, se utiliza la tarea que permite calcular el número pi. En la declaración para realizar la petición de esa tarea, se especifica tanto el número de maps como de reduce que se pide realizar a los datanodes. Manejar estos valores en función del número de nodos en el clúster puede hacer variar el tiempo de ejecución hacia valores óptimos; en nuestro caso, se le han dado valores 10 y 2 respectivamente. Tabla 3. Tiempos de ejecución de la tarea pi Nº Datanodes p1(s) p2(s) p3(s) Media(s) 4 25.56 24.12 25.72 25.13 3 24.89 24.01 23.67 24.19 2 23.85 21.38 21.78 22.34 1 22.74 20.68 21.07 21.50 C. Análisis de los resultados En primer lugar, se ha comprobado la gran inversión temporal que requiere generar un live-USB. El tamaño del sistema operativo en conjunto a los guests que contiene, unido al tipo de sistema operativo escogido en cada máquina virtual, infiere de gran manera en el tiempo de ejecución de Systemback, tanto para la generación de la imagen copia del sistema en vivo como para su montaje en el dispositivo USB. En este punto, se aconseja que el docente ofrezca una organización de máquinas virtuales para cada sesión única, 77 IT / Seguridad en redes de modo que el tiempo de trabajo consista en mayor medida en volcar la misma imagen tantas veces como sea necesaria. No obstante, es una tarea previa a la sesión práctica y además puede ser realizada de manera sistemática y en paralelo con otras obligaciones. En comparativa con la planificación actual que puede conllevar incluso un día completo de configuración de equipos, la comparativa de tiempo invertido es positiva. Posteriormente, se ha realizado una experimentación más específica ligada a estimar los tiempos de arranque de clúster Hadoop sobre distinto número de datanodes. Se aprecia una relación entre ese número de nodos y el tiempo invertido en su funcionamiento, de modo que se puede preveer el tiempo empleado para un número cualquier de nodos. Sin embargo, la limitación de los live-USB en términos sobre todo de memoria RAM, limita la ejecución en paralelo a cuatro nodos. Siguiendo también el modelo de trabajo propuesto por Hadoop, se han realizado tareas sencillas para calcular el valor del número pi atendiendo a los parámetros introducidos para el proceso mapreduce y también considerando los datanodes presentes en el clúster. Gracias a estas simulaciones, se ha demostrado que un mayor número de procesos de reducción por cada mapeo realizado contribuye a proporcionar una mayor utilidad de los datanodes del clúster así como obtener unos resultados más precisos. VI. CONCLUSIONES Y TRABAJO FUTURO En este trabajo se ha logrado implementar con éxito una solución a la problemática de flexibilidad presente en los laboratorios de red docente. Para lograr este objetivo, se ha buscado continuar la idea de trabajo docente introducida en proyectos anteriores, donde se proponía la necesidad de encontrar una solución que hiciera posible realizar pruebas de seguridad enfocadas al ámbito docente. Consecuencia de ello, ha resultado la generación de la herramienta live-USB que engloba las ventajas de la virtualización y la tecnología Live en una solución completa, personalizada y flexible. Este hecho ha sido evidenciado en su buen funcionamiento en equipos físicos, donde se han realizado diferentes pruebas y casos prácticos con los que se ha apreciado, en base a la experimentación realizada, una gran similitud al despliegue de red física que plantea. Los resultados obtenidos dan buena idea de que es una solución a tener en cuenta para el trabajo de los docentes en el desarrollo y planificación de las clases prácticas en los laboratorios de red; no sólo con temática de seguridad, sino de cualquier otro tipo que involucre el empleo de redes. La investigación desarrollada durante este trabajo no termina aquí. En paralelo a esta investigación , el proyecto de innovación docente PID 014-54 dentro del grupo de investigación NESG busca mejorar esta herramienta de manera que pueda ser utilizada en futuras clases prácticas de la Escuela Técnica Superior de Ingeniería Informática. Para ello, los planes previstos para el futuro son los siguientes. Afianzamiento de esta solución en entornos distribuidos que permita la comunicación fluida entre máquinas virtuales de distintos equipos físicos de un laboratorio. Adicción de herramientas de medición complementarias en los sistemas operativos de los live-USB enfocadas a la temática de seguridad con las que puedan trabajar los alumnos. Búsqueda de alternativas más veloces para generar los live-USB. Exclusivizar los sistemas operativos guests empleados a máquinas Lubuntu. Planteamiento de temáticas trabajo originales destinadas a comprobar la funcionalidad específica de los live-USB como soluciones. VII. PLANIFICACIÓN Y COSTES En la siguiente figura, se muestra mediante un diagrama de Gantt la evolución temporal seguida en cada una de las fases principales del trabajo. Figura 5. Planificación temporal del trabajo El desembolso total que engloba recursos humanos, hardware y software viene desglosado en la tabla adjunta. Tabla 4. Costes totales de recursos Recursos Coste (€) Humanos 24240 Hardware 10952 Software 250 Total 35424 VIII. REFERENCIAS BIBLIOGRAFICAS Diseño e Implantación de un Laboratorio para la Docencia de RedesTelemáticas para la ETSIIT. http://dtstc.ugr.es/~gmacia/papers/Jitel07_LabDocencia.pdf. Ejemplo de la filosofía live-USB con virtualización. https://www.dtic.ua.es/grupoM/recursos/articulos/JDARE-06-G.pdf. Gómez Muñoz, A. "Clustering en Big Data. Aplicación en Seguridaden Red." 2014. Laboratorio de redes virtuales en la Universidad de Málaga. http://upcommons.upc.edu/revistes/bitstream/2099/12001/1/a40.pdf. PFC de Eugenio Villar Fernández: Virtualización de servidores de telefoníaIP en GNU/Linux (Universidad de Almería) . http://www.adminso.es/images/d/dc/PFC_eugenio.pdf. Reyes Maldonado, A. "Herramientas Big Data de detección de intrusiones para entorno docente y de investigación en Seguridad en Redesde Computadores". 2014. Systemback o cómo crear puntos de restauración en Linux. http://blog.desdelinux.net/ systemback-o-como-crear-puntos-de-restauracion-en-linux/. Universidad de Caracas - Virtualizacion en el ámbito educativo http://tecnologiaedu.us.es/cuestionario/bibliovir/La_virtualizacion_univ.pdf. (Visitedon 06/26/2015). 78 F. López Pérez (tutor R.A. Rodríguez Gómez): Diseño e implementación de retos de seguridad en redes de telecomunicación en el laboratorio 3.7 con fines docentes detecci´on de anomal´ıas en red Autor: Pablo S´anchez Robles, e-mail: [email protected] Tutor: Jos´e Camacho P´aez, e-mail: [email protected] Titulaci´on: Ingenier´ıa Inform´atica Departamento de Teor´ıa de la Se˜nal, Telem´atica y Comunicaciones Universidad de Granada Resumen—El objetivo del documento es el desarrollo de una interfaz gr´ afica para an´ alisis de BIG DATA haciendo uso de la Toolbox MEDA, herramienta de software libre desarrollada en la Universidad de Granada, y orientar dicha interfaz a la detecci´ on de anomal´ ıas en redes de computadores con un amplio n´ umero de conexiones y usuarios finales. El objetivo principal es simplificar el manejo de MEDA-Toolbox, mediante la interfaz gr´ afica y conseguir que sea utilizada por un mayor n´ umero de usuarios. Parte fundamental del trabajo de fin de grado ha sido la revisi´ on de las distintas herramientas y visualizaciones que incorpora MEDA-Toolbox. Dichas herramientas y visualizaciones se basan en el an´ alisis multivariante de datos, destacando el An´ alisis por Componentes Principales para la reducci´ on de la dimensionalidad del problema, y el Clustering para la reducci´ on del volumen de datos. Finalmente, el trabajo estudia la aplicabilidad de la herramienta, de prop´ osito general, en problemas de seguridad en red. Palabras clave—An´ alisis de componentes principales (PCA), An´ alisis exploratorio de datos(AED), Big Data, datos de seguridad en red, detecci´ on de anomal´ ıas en red, GUIDE, MEDATooblox. I. INTRODUCCI ´ ON Y OBJETIVOS El documento que aqu´ ı se resume viene motivado por las crecientes amenazas a la seguridad de los procesos inform´ aticos y la necesidad que ello genera de una detecci´ on a tiempo real de los mismos para evitarlos. En este texto se pretende crear una interfaz gr´ afica que facilite el uso de la Toolbox MEDA desarrollada por la UGR, mas concrecatemente facilitar el uso de las funciones relacionadas con el an´ alisis de Big Data. Otro objetivo a cumplir es el aprendizaje de las herramientas te´ oricas estad´ ısticas que utiliza MEDA Toolbox para su funcionamiento en el an´ alisis de grandes conjuntos de datos. A lo largo del documento se exponen las fases de an´ alisis, dise˜ no y desarrollo del software, tambi´ en se trata un tema sobre la extracci´ on de datos en red mediante la captura de paqutes o de flujos de tr´ afico. Por ´ ultimo se prueba el funcionamiento del software mediante un ejemplo pr´ actico con datos reales de una red corporativa anonimizada. II. CONCEPTOS TE ´ ORICOS [1] [2][3] [4] En los primeros temas se tratan las t´ ecnicas estad´ ısticas del an´ alisis exploratorio de datos o EDA, que utiliza las t´ ecnicas de proyecci´ on de An´ alisis de componentes principales o PCA y M´ ınimos Cuadrados Parciales o PLS. Dichas t´ ecnicas de proyecci´ on se utilizan para la disminuci´ on del tama˜ no del problema. En el caso de PCA se dispone de una matriz de datos Xde Nobservaciones y Mvariables y mediante la generaci´ on de variables latentes se reduce el tama˜ no del problema de las Miniciales al n´ umero de variables latentes seleccionadas. En el caso de PCA las variables latentes se denominan componentes principales y se calculan como combinaciones lineales de las variables originales siendo la primera componente principal la recta que maximiza la varianza, como se puede apreciar en la Fig. 1. Por otra parte PLS funciona de forma similar, con la diferencia de que en este caso se tiene informaci´ on sobre las relaciones entre variables en una segunda matriz, Y, que se utiliza para realizar el an´ alisis. En estos primeros temas tambi´ en se tratan los mecanismos de visualizaci´ on que tiene la Toolbox MEDA para entender las correlaciones que existen entre variables(Fig. 4), las relaciones entre observaciones(Fig. 2), y las relaciones dobles entre variables y observaciones(Fig. 3). Fig. 1: Ejemplo de componentes principales En estos primeros cap´ ıtulos tambi´ en se explican las t´ ecnicas de tratamiento de grandes conjuntos de datos de MEDAToolbox. III. EXTRACI ´ ON DE DATOS DE SEGURIDAD EN RED [5] [6][7] En el documento se presenta un cap´ ıtulo hablando sobre la extracci´ on de datos en red necesarios para llevar a cabo el an´ alisis de la seguridad en la misma. Se habla sobre los datos est´ aticos y las series temporales, as´ ı como los flujos de datos y el an´ alisis de paquetes de datos. Se comenta tambi´ en la informaci´ on de relevancia que se encuentra en los ficheros de registro de las aplicaciones, sistemas operativos, firewalls, antivirus etc. Y de c´ omo sacar partido de ella para detectar fallas en la seguridad. Tambi´ en se habla sobre los sistemas de detecci´ on y prevenci´ on de intrusiones y sobre los test de penetraci´ on para analizar y encontrar fallos en la red. Teoría de la Señal, Telemática y Comunicaciones, 2016, ISBN-13 978-84-617-5449-6, páginas 79-82 MEDA-Toolbox: interfaz gr´afica en Matlab para la ISBN-13: 978-84-617-5449-6